The golden rules of PLM

Alec Cassells has worked for IBM for 33 years. Now a PLM (product lifecycle management) Solutions executive consultant, Cassells specialises in providing IT and management consultancy services to manufacturing and engineering companies throughout the UK and Northern Europe. Back in the 1970s, he spent his first ten years at IBM working in NC machining software development, CAD software, shopfloor automation and data collection (SFDC). Then he moved on to work for IBM’s Global Services division. His most recent work has been as a consultant on major PDM (product data management) and PLM projects for the likes of BAE Systems, Volvo, Airbus, ABB, Bombardier, TRW Aeronautical, Panasonic UK and Daimler-Chrysler. “Most of my work to date has centred around consulting on product development and PDM software for manufacturing firms,” said Cassells. “Most are medium to large organisations with a mixture of different PDM systems – legacy systems, bill of material [BOM] management systems and one or more vendor-specific PDM solutions. The companies want to integrate these systems into one central database to help them better manage and control product information throughout the entire lifecycle.” According to Cassells, PLM is simply the bigger brother of PDM and offers productivity improvements in many areas. Engineering change workload can be reduced, there’s better access to product information including 3D solid models and related technical data, through document management and better management of BOMs. It spans changing design requirements, option elimination, process planning, supplier changes, late design changes, substitutions, inspection data, product trials, final settings, repairs, retrofit, refurbishment and disposal. But Cassells warned: “Fundamental changes in process and organisation are required. A key factor in reducing lead time is replacing physical prototypes and testing with digital mock-up and simulation. “PDM has been around for more than 15 years now. Although PDM’s origins are in engineering and the sources of product data, the reach of a PDM system must be much greater if it is to deliver its maximum benefit,” he added. “This is particularly the case in engineer-to-order industries with long product lifecycles. “My first project was back in 1990. I built up a list of issues during the PDM implementation which to this day hasn’t changed all that much. The software and technology has moved on considerably, but the management and cultural problems are still more or less the same. He went on to suggest that companies today are further behind technology than they’ve ever been. “It’s time to catch up. There’s still so much capacity for change out there. Even the much-publicised successful PDM projects we all get to hear about are often just small ones, sometimes only involving eight people within a large company. The company as a whole still continues to use its original systems and processes. Some carry on using 2D software and retrieving product information from micro-fiche film,” he added. He said that in the aerospace industry, typically large manufacturing firms that have a new aircraft project coming up, will want to deploy the latest software in a pilot project. “If it’s a project that might happen or might not, then there’s little capital available for new software. But once the company gets the green light for the project and funds start to become available, the chief engineer is unlikely to want to risk new technology or software – he will often want to stick with the existing tried and trusted technology to get the job done. Almost overnight, the company can switch from being too early with the latest technology to being too late now for any new software. That’s why many companies are now five years into a three-year project. Cassells believes PLM is not that well understood by industry and is often poorly defined by software vendors. “To me, it’s about managing product development through the entire lifecycle of your products. You’ve got all your operational and transactional software out there – ERP systems, CRM [customer relationship management] and the like – it’s not core information to an engineering business though. The core data for these types of companies is product definition data and the use of this through a product’s lifecycle, including after-sales servicing, spares and maintenance.” He continued: “The need for traceability in many industries is driving the adoption of PLM. Although for many firms, ordering spare parts was a task for an ERP system, knowing exactly which spare part to order because your design department has recently modified the gearbox design on the engine, is a problem that PDM or PLM systems can resolve.” Cassells cited an example of this where one UK-based engine overhaul company he consulted for, actually flew some of its engineers out to Brazil to see what spares the end-user actually needed. “That is simply a waste of resources and money,” he said. Cassells says that manufacturing companies often have two key business drivers before considering adopting PLM. “They always look for between 30 and 50% reductions in costs and time-to-market. With the telecoms companies, it’s all about getting to full production in as quick a time as possible. For the majority of manufacturers though, it’s about cutting costs from the bottom line.” For long lifecycle product manufacturers, Cassells says companies are having to become more service-oriented rather than product-focused. “Margins are very small on selling an engine or train for example. But the margin on spares for that train is usually very good. Contracts now are being drawn up where the manufacturer agrees to be liable for the reliability of its end product. In the case of an engine, every hour that engine is out of service due to a fault or missing spare part, the manufacturer takes the hit. 15 years ago, if you shipped the wrong engine spare to a customer it was just ‘bad luck’ and a quick apology over the telephone. Now, if you’re charging your customer on a ‘power by the hour’ basis, you’re going to lose money.” Cassells also sees supplier participation as a key driver. “It used to be the case that the OEM designed a product in-house then gave a ‘build to print’ order to his supplier to manufacture the product. That meant there were CAD data translation issues because the OEM really didn’t mind what software package the suppliers were using, so long as they received the work back in a certain format on time. Now, OEMs are involving their suppliers at the design concept stage. Spaces, work envelopes or build packages are given to the suppliers to work to. And they’re being told what the preferred software will be for that project. “But this means suppliers are sometimes having to work with and train their staff to use two or three different CAD software packages depending on how many OEMs they want to do business with. That has resulted in an explosion in data translation requirements and this can be a real inhibitor for many suppliers today. The cost of this is crippling some of them.” But what about managing change and cultural issues associated with PLM, Eureka asked? He replied: “Having a receptive culture is important. In a design office, staff are often resistant to new software because they become familiar with a certain CAD package. They also fear losing their job if the time to market for new products is halved. “Middle management also fear change for the same reasons. They worry that they may lose their jobs if the office becomes more efficient. For Board-level staff, they need to focus on sustained sponsorship of the project. If the MD loses sight of what the new software or technology is capable of, or the engineering director loses sight of the business issues and drivers, the project is likely to fail.” But irrespective of the project, he said firms always find there are two people in a company that are needed to make a project succeed. “The problem is, the best people are usually constantly in demand in their day jobs.” He went on to explain that skills and resources must be made available and committed from the business as well as from the IT department. “Business improvement projects such as PLM require people from the business as well as software vendors and consultants. PLM demands the people who are most valuable and this may well limit the rate at which the business can change. So a phased approach is often the best way forward.” “A successful project requires a combination of factors in addition to new technology. The company must have a clear understanding of the business requirements and benefits. The business purpose of PLM must be clearly established and areas of benefit identified. Without these, it will not be clear what business process changes will be necessary and it will not be possible to construct the business case. You may get a long way without this, but the project may collapse when things get difficult.” He continued: “And all business units must buy-in to the idea. In the early stages of the project, the focus should be on the technology. However, PDM or PLM relies on early cross-functional (manufacturing, test and suppliers) involvement and co-operation, so without the support of these groups, the project will not get very far. “Expectations must be carefully managed too,” explained Cassells. “Executive management, users and IT staff often have very different or unclear ideas about what PLM will look like when its delivered. Don’t exaggerate the benefits to make the business case more robust. If it is worth doing, the business case will not need this.” And he said a balance is needed between volume and sophistication of the PDM system. “PDM projects can sometimes focus on maximising the use of the complex capabilities that exist in such products. This can be very beneficial to the user groups who need this function, but this can lead to the system managing a relatively small amount of data and thus having little perceived impact. The system may be perceived as being more useful if a larger volume of data were managed in a less sophisticated manner.” He pointed to systems with larger user populations and large data volumes as tending to have a longer life and more likely to become central to many business processes. According to Cassells, outsourcing, globalisation, mergers and acquisitions are all driving PLM adoption. “Sometimes PDM implementations fail or go over budget simply because the team tries to over-complicate what it wants to achieve. You have to have frequent milestones and realistic targets. Often, just giving 100 people across a company access to all the product information can be enough to make efficiency savings and reduce time to market.” And BOM management is also a big issue. Out-of-date parts lists, multiple BOM versions, poor version control and incorrect access rights are a problem. Also, exchange of data with suppliers is done infrequently because it’s labour intensive, time consuming and costly. “People and departments work in functional silos. The engineering director makes the business case but other departments are likely to get knock-on benefits from the project if completed successfully. Problem is, disruption is seen at the lower echelons. You have to build multi-disciplinary, cross-functional teams. And concurrent engineering is still an issue for many manufacturers. Individuals feel threatened by it because of a ‘blame culture’ within the company.” IBM PLM Solutions successes Five golden rules of PLM Never introduce PLM into a “process vacuum” Use the PLM software’s function as a model to fill the “vacuum” Define the deliverables, the don’t let the project scope ‘creep’ Do not underestimate the cultural and organisational issues Continuously refer back to the business need and justification