Product lifecycle management (PLM) promises significant benefits to manufacturers, and the market is full of vendors claiming to provide faster new product introductions, reduced product costs, reduced product development costs, increased revenue, better quality products, enhanced product innovation, and other valuable benefits. Because of the high appeal of these benefits and their associated return on investment (ROI), PLM has become one of the fastest growing categories of enterprise applications.
The PLM market today consists of vendors offering a variety of solutions that in some way offer value to the product life cycle, but there is no single vendor that is supplying all of the solutions required to support a full PLM program (please see The PLM Program). Many PLM solutions have their roots in the engineering department, but make no mistake—PLM is an enterprise application suite, and it has all of the additional requirements that come with enterprise-class applications.
The PLM concept pulls together information and business processes from multiple disciplines within the enterprise and across enterprises. While product design plays a crucial role in the product life cycle, PLM is not just a series of add-on tools for computer-aided engineering (CAE) and product data management (PDM). PLM is a suite of applications that can be used by a company to get the highest value from its products to improve its business results. And like any other new suite of enterprise applications, as learned from supply chain management (SCM) and customer relationship management (CRM), companies may have to choose between the potential tradeoffs of best-of-breed solutions and solutions from their enterprise resource planning (ERP) vendors.
Innovation Is King
PLM is not just another module of the ERP system. At the risk of simplifying things too much, PLM enables innovation and relies on flexibility and loosely structured information, while ERP enables control and relies on discipline and structure.
Without getting into a philosophical debate, let's examine what that means in practical terms by looking at an example. During the process of developing a new product, companies typically go through multiple iterations of the design. The designers may procure or produce component materials to use in the product and go through many different sets of specifications before delivering the final design. In addition to the product design, information about internal design reviews, market analysis, customer preferences, supplier input, pricing, and other documentation is generated. Many finished designs will never see production, however, let alone the components, ingredients, or specifications.
ERP applications supply the discipline to control these materials on a large scale from an inventory, costing, and regulatory view. This level of control, which is required to plan and execute a global supply chain, may not be appropriate for the product innovation environment. In addition to avoiding too much "ERP overhead" in the design process, we also don't want to pollute the ERP system with a lot of experimental material definitions and documentation that may never be used again.
Integration Might Be Queen
If innovation is the highest priority, then integration is not far behind. Integrating the business processes and information flow across the enterprise and the supply chain is a key component of enabling PLM. Many of the benefits from a PLM implementation come from better communication between departments and trading partners, and the integration of different people and perspectives on the new product introduction processes. An enterprise-level view of the design process promises to result in a design that takes into account the strengths and possibilities of all departments and business partners involved, and a design that can be efficiently and effectively introduced into current operations.
While some business processes rely solely on the PLM system, others cross the line between innovation and execution. Let's explore the engineering change process, for example. Assuming that some simple file transfers between ERP and PLM are in place, it is a relatively easy task to populate the PLM system with the current bill of material (BOM) or recipe, if it is not already there. As the new design is developed, many tools provide a compare utility that will show the net change between the new and old structure. That defines one important aspect of the engineering change: the changes in materials used in production.
The next aspect of change is the timing of when the change should be implemented. In order to plan the execution of the engineering change, information about levels and locations of inventory, costs, planned production, planned purchases, and current demands for the product must be taken into account. This information resides in the ERP application, and is critical to making the optimal decision on when to introduce an engineering change. Without that information, the impact of making this change based on a set date—the date when existing inventory is consumed or for a particular production run—cannot be understood.
A Failure to Communicate?
Integration is more than just transferring data between two systems. Integration requires that both information and business processes be supported across multiple systems (see What's Wrong with Applications: Business Processes Cross Application Boundaries). One of the key challenges of integrating PLM with other enterprise applications is semantics. "Semantics" is a term that is sometimes not very well understood, but a semantics problem could be summarized by the phrase "It's not that I didn't hear the words that you spoke. I just don't understand what you meant." Different systems have different ways of representing concepts and associate different meaning with their data. In order to integrate systems, you have to know more than how the data are stored; you have to know what it means. While standards efforts, like RosettaNet for the discrete industries and ISA S95 for the process industries, have helped to standardize data structures, they still do not guarantee semantic compatibility.
This is part one of a two-part article. Click here to read part two, which provides examples of conceptual and semantic alignment between PLM and ERP, discusses the ability for ERP and PLM vendors to provide solutions that meet user needs, and offers
About the Author
Jim Brown has almost 20 years of experience in application software, management consulting, and research focused on the manufacturing industries. Brown is a recognized expert in software solutions for manufacturing, and has broad knowledge of applying product lifecycle management, enterprise resource planning, supply chain planning, supply chain execution, and e-business applications to improve business performance. He served as an executive for software companies specializing in PLM and other enterprise solutions before starting his consulting firm, Tech-Clarity Associates. Brown can be reached at firstname.lastname@example.org.