erp and plm integration considerations by richard bourke

An Introduction – for manufacturers of complex products

Maximizing the Value of Product Lifecycle Management and

Enterprise Resource Planning: Integration and Collaboration

August 2011

TABLE OF CONTENTS Part 1: Introduction ....................................................................................................................................... 1 Part 2: Product Lifecycle Management and Enterprise Resource Planning ................................................. 3 Part 3: Collaboration and Integration – Overview ........................................................................................ 5 Part 4: Collaborative Product Development and Configurability ................................................................. 7 Part 5: Collaborative Product Development and Enterprise Resource Planning .......................................... 9 Part 6: Integration – The Quest Continues ................................................................................................. 10 Part 7: Some Questions – Some Answers ................................................................................................... 12 Part 8: Introduction to Product Lifecycle Management as the System of Record ..................................... 14 Part 9: Manufacturing Process Management Explored .............................................................................. 16 Part 10: Manufacturing Execution System Added to Foundation .............................................................. 18 Part 11: Final Thoughts ............................................................................................................................... 20 APPENDIX Additional Sources of Information .............................................................................................................. 22 About the Author ........................................................................................................................................ 23

Maximizing the Value of PLM/ERP: Integration and Collaboration Discussion Notes

©Bourke Consulting Associates, 2011 Reproduction allowed provided attribution is retained Page 1

Part 1: Introduction

Prologue As the economy recovers from the recent tough and turbulent economic climate, manufacturers of complex products, such as Industrial Equipment and High Tech, are still coping with many unrelenting challenges. These challenges include increasingly complex supply chains, numerous regulatory and compliance directives and heightened customer demands. Some companies have been in a “survival mode,” often seeking immediate, short-term cost reductions, possibly sacrificing product innovation in the frantic quest to save money. Yet, as the economy improves, longer-term product innovation initiatives are crucial to ensure future competitiveness. Cost reduction alone cannot ensure a competitive market posture. Recent surveys show that companies are willing to invest in Information Technology (IT); some of the motivation for IT expenditures for application systems, however, appears to be cost containment, particularly, personnel. The Foundation Systems Two application systems are commonly recognized as the indispensable foundation for an enterprises IT infrastructure:

Product lifecycle management (PLM)

Enterprise resource planning (ERP) One of the common dimensions in these systems is Time: cut, shrink and slash. Successful users of PLM systems cite “Time-to-Market” as a strategic value for implementing PLM. Yet, also achieving “Time-to-Volume” and “Time-to-Profitability,” highlights the need for effective and efficient PLM/ERP integration and collaboration. And, Time is a key focus for any discussion of “lean.” About Lean Lean for manufacturing has long been a proven strategy. Now, some companies and several product development (PD) consultants recognize that applying lean principles to PD activities is essential. The values of lean, such as eliminate waste, improve flow, and many more apply. Yet, the application of lean must accommodate the differences in the PD environment (less structured) as compared to manufacturing and supply chain activities (more structured). Thus, the proven philosophy and techniques of lean manufacturing cannot be applied “as-is” to lean product development (LPD); rethinking the application of the methods is an absolute necessity. For instance, the role of Six Sigma to reduce variability in manufacturing processes is vital. In product development, conversely, not so, accommodating variability in the processes is more important.



What’s more, be aware, lean PD consultants may tout different emphasis for applying the various Lean methods. Practitioners and LPD consultants are re-examining systems to manage PD, such as Stage-Gate. For example, at a recent conference, a recurring theme was “the best results come, from bending the rules some.” Lean concepts and methods have proven to increase the value of PLM and ERP systems – when properly applied and efficiently deployed. Incorporating Lean in these systems is a requirement for success, not an option. A Core Theme The following discussions are based on the decade’s old, classic paradigm stated by Peter Drucker, “Efficiency is doing things right and Effectiveness is doing right things.” The interpretation is:

Effectiveness – invest in appropriate IT tools when they will facilitate the corporate strategy and justified. Within this key assertion, software is only part of the answer to successful systems; it is only an enabler, a facilitator, no more, no less.

Efficiency – gain the greatest value from the IT investment. Successful systems are crafted on a foundation of best practice business processes supported by proven IT. Cultural aspects, moreover, will be an important consideration for successful implementation of powerful, software-based systems.

What’s Next The next parts will focus first on maximizing the value of two foundation systems – PLM and ERP – with collaboration and integration processes and IT support. Later, as an additional building block for a comprehensive system foundation, manufacturing execution systems (MES) will be examined. These systems are rapidly gaining adherents in many industry sectors, particularly when regulations and complex shop floor environments require detailed work-in-process management and reporting. A Reading Note This paper is an introduction to the concepts of PLM/ERP systems and collaboration and integration for those readers needing just the highlights. To gain more detail and further understanding of these vast subjects, see “Additional Sources” in the Appendix that provide you numerous, easily obtainable articles and books. Several professional organizations are also identified.



Part 2: Product Lifecycle Management and Enterprise Resource Planning

Preface A basic premise: PLM and ERP are both powerful systems with unique purposes and functions. Both systems are required to manage “product definition”1 over the total lifecycle of a product. It’s not an either/or situation. Product Lifecycle Management A product’s lifecycle may start with the “first cocktail napkin” ideation, or more formal methods, and continues until the product is retired, which for many companies could occur decades later. Definitions of PLM abound; my definition is that a PLM system is an astute blend of processes (best practices), people (roles and responsibilities) and programs (PLM application elements) to facilitate product development and to manage product knowledge. In other words, as stated earlier – software is just an enabler. When forging a company’s tailored definition, potential users should consider:

There is little agreement on the definition of PLM

The scope of PLM is constantly expanding PLM systems have two basic purposes: (with the functions to support them): 1. To facilitate product development using product design tools, often called

authoring or creation tools, such as Computer Aided Engineering and related development software.

2. To manage product knowledge over the product lifecycle using a selected range of PLM applications.

Product data management (PDM) is the base PLM application that typically includes capabilities to store, secure, share and distribute all electronic forms of product knowledge for new and existing products. PDM applications share and distribute product knowledge with electronic workflow tools with capabilities for eliminating paper documents and manual workflows. A key function of PDM is to manage the engineering bill of material (eBOM) and related change information in a timely, accurate and properly structured manner for use by other systems, including ERP and MES.

1 The term “product definition” spans a wide range of data elements and/or files including: engineering Bill of Material (eBOM),

manufacturing Bill of Material (mBOM), lifecycle stages of released BOMs, routings, assembly instructions, part specifications, costs, sources, quality plans, and more. During the design process, engineers create a design-oriented parts list, i.e., eBOM, which represents how engineering views the product. Manufacturing engineers will restructure the eBOM into a process-oriented mBOM (commonly known as a Bill of Process - BOP). It will show how the product will be made, and simultaneously create the sequence of steps to produce a part and the required resources - work centers, tools and skills.



The importance of properly structured and accurate product data cannot be overstated. Several major organizational entities – in addition to product development – rely heavily on PLM applications for accurate product knowledge:

Management – Portfolio and Project Management, for new product introduction

Operations – supported also by ERP and MES

Vendors – Component & Supplier Management, often identified in supply chain management (SCM) systems

Customer – Requirements Management, often identified in customer relationship management (CRM) systems

Enterprise Resource Planning The purpose of an integrated ERP system is to optimize the management of manufacturing to meet customer needs for high quality products with competitive pricing and delivery. The functions ERP span an extensive range of applications for master scheduling, material and resource planning, order entry, shop floor scheduling, costing and financial reporting. Most ERP systems provide some of the product definition functions for the management of mBOMs, Routings/Work Centers and Engineering Change. ERP systems, however, may not provide adequate detail to manage work-in-process; hence, the rising interest in MES systems for more detailed information for managing work-in-process, including detailed reporting of activity. ERP’s definitions are more mature compared with PLM; however, ERP is occasionally incorrectly postured as a financial system. Not so, though most ERP systems include substantial accounting capabilities. For Your Consideration Understanding the differences and objectives between PLM and ERP systems is critical. What’s more, coping with the cultural aspects – diverse users’ attitudes and values – may be as important as technical issues. The respective systems are different. Yet, both contribute to the objectives stated earlier, achieving reduction of all three “Times to Market, Volume and Profitability,” more so when properly integrated. Nevertheless, companies must recognize the unique functions and processes of PLM and ERP. Also, the individual needs of users as they move forward to gain the benefits of integration and collaborative environments.



Part 3: Collaboration and Integration – Overview

Preface As an extension of Peter Drucker’s perspective (“do the right thing and do it right”) stated in the first part, consider his corollary as a starting point:

“The most efficient way to produce anything is to bring together under one management as many as possible of the activities needed to turn out the product.”

In that spirit, let’s examine two key elements:

Integration – unifying related systems to facilitate timely exchange of data

Collaboration – working together to achieve economic manufacturing and supply chain management, and efficient product development. . . our focus now

Introducing Collaborative Product Development (CPD) One of the motivations for CPD is ever-increasing outsourcing of the design and manufacturing functions throughout a company’s virtual enterprise. Outsourcing recognizes that innovative product ideas come from not only the company’s internal functions – but also from customers, partners and suppliers. All parties can contribute expertise working together to develop a higher quality product, while reducing time and costs – if given the opportunity. CPD eliminates many of the problems caused by serial design processing, the often cited . . . throwing the prints over the wall to manufacturing after an engineering design is supposedly complete. CPD is an approach in which design and manufacturing engineers and others work together in parallel before engineering releases the product to the virtual enterprise. An efficient CPD relationship, therefore, provides an excellent opportunity to consider all elements of a product’s lifecycle in the early design stages, such as requirements, quality, cost, maintainability, to cite a few. CPD helps companies to deal with two widely accepted axioms:

The early stages of product development account for 70-80% of committed product cost

Engineering changes later in the product lifecycle become exponentially more expensive to incorporate, that is, after a product has taken physical form in manufacturing or at supplier facilities

Resolving product design issues and developing improvements while a product is still in a digital state is clearly a desired best practice. Thus, the values gained with efficient CPD will be higher quality product at a lower cost and a speedier release to the virtual enterprise.



Software Enablers An abundance of proven, commercially available software is now available. Software enables efficient coordination and selective sharing of product information throughout the virtual enterprise. For collaboration, choices range from e-mail and other asynchronous methods to more interactive (synchronous) methods. For instance, using PLM capabilities for automated workflow routing, visualization and markup of 3D CAD models to achieve timely product design reviews among geographically dispersed design teams. Therefore, selecting and using the right software is a step to gain the values of efficient collaborative relationships, be it group or global. A company might acquire highly capable software, but still not achieve a high level of efficiency, i.e., value, without a constant devotion to best practices and processes. Improving practices and processes should be a prime motivation to develop these relationships and to gain the values for your company’s efforts, for example:

Cost reduction – save travel time and cost by eliminating on-site meetings; i.e., virtual co-location. Some physical co-location, nevertheless, may still be advisable for individual circumstances

New product introduction – cut engineering change order processing by over 50% to support the key strategic objective to reduce Time-to-Market

It Takes More than Software Many factors – both technical and cultural – affect attaining a high degree of efficiency in any collaborative relationships, be it group or global. A key to achieve true efficiency is user’s confidence in the quality of data flowing through the systems. Lack of confidence among team members may cause continual questioning and correcting data, wasting time, money and user’s patience. Trustworthy, continuous communication in an environment of widely diverse personnel with differing motivations, values and attitudes is mandatory. Cultural aspects will be (not, may be) as significant as the technical (software) capabilities to gain efficient collaboration and integration. Validation? Just ask any experienced user. What’s Next The next parts of this paper will examine integration and collaboration in more detail. A continuing focus will be the eBOM-mBOM life cycle and processes.



Part 4: Collaborative Product Development and Configurability

Preface Today’s competitive environment – and highly likely for the future – demands the ability to produce and sell complex, configured products. Customers in both the B2B and B2C sectors expect customized products to match their unique needs – but with lower prices, higher quality and faster delivery. The Need of Configurable Product Manufacturers To meet these customer demands, some companies are pursuing mass customization: “The development, production, marketing and delivery of customized products and services on a mass basis.” 2 Embodied within this strategy is the need for “configurability,” i.e., optimizing customer choices by providing more options with less, or more efficient use of resources. The essence of a configurability strategy is to take advantage of proven methods of product development to achieve greater customer satisfaction at lower costs.3 A few of these methods include:

Platform planning – designing parts and assemblies to be widely shared by product families

Design reuse/parts standardization – capitalizing on tested designs

Product modularization – developing smaller sub-systems that will be able to function properly when assembled and tested as an end item

Introduction to Configurators A comprehensive configurability strategy requires an enabling IT-based capability, i.e., configurator software – tools to create, maintain and use electronic product models to identify available options and variations to define a unique end-item. For many products in complex industrial equipment manufacturing, product modularization is a prerequisite step to gain efficient use of configurator software. It eliminates predefining all possible combinations with individual part numbers and bills of material (BOMs) – an impossible task. Configurator capabilities come in all sizes and shapes from PLM, ERP and third party sources, the simplest are rules-based (If-Then-Else logic); the more sophisticated software includes constraint logic and handling spatial and visualization.

2 Pine, B. J., PhD, Mass Customization: The New Frontier in Business, Harvard Business School Press, 1993.

3 For more detail, refer to the author’s white papers titled “Configurability Strategy: A Competitive Advantage,” “Optimizing the Lead-to-Order Process” and “Top Ten Risks to a Configuration Project and How to Avoid Them.” Though written for Access Commerce, a configurator vendor,

the information is generic and suitable for general education.

http://www.bourkeconsulting.com/Internal.aspx?path=Publications&objId=86






A robust configurator is one that automatically and seamlessly meets all configuration needs – marketing, sales, engineering and manufacturing – across the company’s product lines and for its competitive environment. Individual manufacturing environments require different methodologies; case in point:

Manufacturer of dimensional, cut-to-order products bought a Features/Options software package from a vendor all too willing to sell the mismatch. Didn’t work. . . company returned software. . . vendor sued for breach of contract. . . vendor admitted error of its way and settled in favor of manufacturer.

In this case, the need was for a configurator integrated with CAD software to develop unique configurations at order entry time that are not pre-defined. The moral? Know your requirements before selecting software. Benefits of Using Configurator Software One of the values of efficient processes built with configurator software is to wipe out the inefficiencies commonly found in non-integrated, manual processes. These inefficiencies include, extended quotation lead-times resulting in excessive costs and time to validate configurations. Eliminating these inefficiencies will result in significant cost reductions, for example, order entry expenses down between 50 and 70%. On the other side of the benefits equation, revenue enhancements include increased sales and improved customer satisfaction, to cite a few. Configurability and Collaborative Product Development Thus, for manufacturers of products with options and variations, developing configurability must be inherent in CPD activities.4 Product definition – as defined in an earlier footnote – now includes “model building,” a common term identifying the core activity of planning and implementing a configurability strategy. Model building is more than a trivial task; users report that it can take months, and requires a multi-disciplinary approach. What’s more, to ensure integrity of this additional form of product definition, model building must integrate with engineering change management processes. And An efficient CPD with an embedded configurability strategy also extends well into the realm of ERP processes – briefly described in the next part.

4 Salvador, F., Martin de Holan, and Salvador, F., Martin de Hohan, P. and Piller, F., Cracking the Code of Mass

Customization, MIT Sloan Management Review, Spring 2009. See also Frank Piller’s www.mass-customization.de.

http://www.mass-customization.de/



Part 5: Collaborative Product Development and Enterprise Resource Planning

Preface As stated in the Introduction, “Successful users of PLM systems cite “Time-to-Market” as a strategic value for implementing PLM. However, achieving “Time-to-Volume” and “Time-to-Profitability,” highlights the need for effective PLM/ERP integration and collaboration.” ERP Collaboration with CPD No finer example of CPD and ERP working together exists than the top management process called Sales & Operations Planning (S&OP)5. One of its prime purposes is to coordinate the new product introduction (NPI) activities of CPD to ensure optimum use of enterprise resources from product launch, manufacturing, delivery and on-site maintenance of the product. The key is balancing the forecasted demands for new products with the available resources to get products to market. For configurable products, identifying product modules for S&OP planning purposes is vital. The goal is to meet the demands for innumerable unique configurations, delivered in a timely manner, with just the right mix of these building block modules in the supply pipeline to protect lead times. Numerous software capabilities support S&OP processes, some quite sophisticated, for instance, providing continuous simulation of alternate plans. However, a recent survey by AMR Research (now a part of Gartner) highlighted again that software is not the only critical factor.

Achieving efficiency with the S&OP process is critical – but dependent on trust among enterprise personnel with different attitudes, values and conflicting objectives. For instance, product development personnel may not have the same outlook on desirable new product features as marketing. Cultural aspects will be as significant as software capabilities in supporting enterprise-wide collaboration.

Conclusion The need to compress product development, and delivery lead times and costs remains a major competitive consideration. Collaboration in its many modes, such as CPD and S&OP, has rightfully sparked a great deal of attention.

5 According to the APICS Dictionary, 13th Edition: “A decision-making activity involving the leader of the business, his or her staff, and a number

of middle managers and specialists. Its mission is to balance demand and supply at the aggregate level, to align operational planning with financial planning, and to link strategic planning with day-to-day sales and operational activities.”



Part 6: Integration – The Quest Continues

Preface The need to unify the flow of product data throughout the engineering–manufacturing continuum is more critical than ever. The motivation is fundamental: Continuing and unrelenting competitive pressures to reduce non value-added times and costs. Introduction The basic purpose of software integration is to unify related systems to make possible the timely exchange of trustworthy data. Successful software integration eliminates the inefficiencies of manual tasks, semi-automated processes and disconnected systems. Such inefficiencies obstruct the flow of data and frustrate system users struggling to meet job expectations. These conditions, unfortunately, often encourage inappropriate use of Excel spreadsheets. In the past, custom coding of software integration offered a company the allure of a fully tailored solution to meet its specific needs; the custom code, however, also brought greater risk and a high price tag. This is because it required special maintenance and on-going support, due to subsequent releases of related software application systems. Custom coding for systems integration is no longer the preferred tactic. Continuing advances in software provide capabilities to unify interrelated systems – with reasonable expenditures. Sources of this software include PLM/ ERP vendors as well as numerous third party firms. Nowadays, a faster, more cost-effective approach is to start with commercially available software as a base, and then add custom code – only if necessary – to achieve the desired level of systems integration. Integration of PLM/ERP Systems Unifying PLM/ERP is one of the most critical integrations for a manufacturing company to implement. These two foundation systems – working together – are indispensable for total management of a product’s lifecycle. In the engineering – manufacturing continuum, coping with massive amounts of frequently changing product data is a constant challenge. Manual and semi-automated processes for exchanging data are error prone and time consuming. Interfacing or loose coupling methods, such as use of Excel spreadsheets, have not proven adequate to cope with the challenges to manage product data.



Worse yet, product configuration integrity is at risk; discovering the true configuration during final assembly haunts companies with inadequate configuration management. Therefore, to attain a timely and smooth flow of trustworthy product data the complete electronic integration of PLM/ERP is mandatory.

Best practice integration methods take advantage of software capabilities for seamless, real-time, bi-directional exchange of synchronized product data between PLM/ERP systems. This level of integration makes possible the automated transfer of engineering bills of material (eBOMs) to the ERP processes for managing manufacturing bills of material (mBOMs) and related planning, such as bills of process (BOPs). What’s more, they nourish the timely return of accurate data, such as part attributes and status, from ERP back to PLM. Using Web-based technologies, PLM/ERP integration gives all virtual enterprise users the ability to view, revise and make the most of product information for astute decision-making. Joint decisions are facilitated, such as planning new product introductions and managing engineering changes. After successful implementation of best practice systems integration, companies should look to the range of results such as those cited by CIMdata:6

BOM – 75% reduction in errors due to more consistent management

BOM – 75% reduction in time and cost due to eliminating duplicated effort

Inventory – 15% reduction as a result of improved design re-use These day-to-day operational savings contribute directly to attaining strategic benefits, such as reduced Time to Market. Nevertheless, there is a continuing quest for even more productive means of unifying these systems. Coming Up Soon An emerging approach to unifying PLM/ERP has been gaining attention. Identified as “PLM as the System of Record,” some view this unifying approach as a step to a “Single source of truth” – but not all agree. Later, I will examine this subject in depth later. What’s Next Before moving on, a pause to answer some common questions about PLM and ERP systems.

6 CIMdata, “PLM and ERP Integration: Business Efficiency and Value,” 2007.



Part 7: Some Questions – Some Answers

Preface In various discussions about these topics, some common questions frequently arise. Here they are with answers. Some Questions and Answers 1. Question: There are more differences between product lifecycle

management (PLM) and enterprise resource planning (ERP) systems than you have cited. Don’t we need to know more about them before starting down the integration path?

Answer: Definitely. My point was to sensitize your antenna, pique your curiosity and encourage you to take advantage of the many references identified in the “Additional Sources of Information.” Hence, it was a start to a fuller understanding of each systems functions and capabilities. Such understanding has proven to be a pre-requisite to gaining the benefits of the PLM/ERP bi-directional integration, previously described.

2. Question: You identified PLM and ERP as the two mandatory foundation

systems for management of the entire product lifecycle. Don’t some companies also want more detailed information from work-in-process (WIP) than most ERP systems provide?

Answer: Yes, I agree. So, let me expand on this subject. For some industry sectors, three systems should comprise the indispensable foundation: PLM, ERP and MES. Any company requiring detailed information to manage WIP, or to cope with industry regulations, should consider an MES. Prime examples include those companies in aerospace and defense, automotive and medical product industries. Moreover, even if regulations do not drive the necessity a company still might choose to gain more efficient WIP management by implementing an MES system.

The above question triggers a comment about any differences between integration methods for PLM/ERP/MES. At a general level, the characteristics of best practice integrations of MES are about the same as for PLM/ERP, as described in Part 5. In any of the possible combinations of systems integration, one of the essential tasks, of course, will be comprehensive, up-front planning, sometimes called a “vision.” And, as tempting as it is to secure fast benefits, moving ahead on a piece-meal basis is not recommended.



3. Question: You didn’t comment on the highly likely company cultural issues inherent when integrating PLM/ERP. Isn’t that a consideration?

Answer: Yes, certainly, I’ll stress it now with a direct suggestion. Ask any experienced systems implementer about the relative importance of technology – and of sensitivity to company cultural issues. Technology is necessary, certainly. Invariably, however, their responses will be to urge you to address the likely cultural issues when planning systems integration. Planning for a new system demands a process orientation that includes defining workflow and identifying appropriate user roles and responsibilities.

Unfortunately, expect heated discussions, such as “Who owns the bill of material?” Another reason to understand PLM vis-à-vis ERP capabilities is to minimize the potential hassle encouraged by parochial system diehards. Thus, as mentioned earlier, one of the objectives of up-front planning should be to eliminate the “we-they” cultural syndrome of these and other entrenched organizational attitudes. My axiom: Management commitment – by itself – will not put an end to cultural resistance to accepting new software-based processes. Consequently, the project team cannot be passive, hoping that time will deal with the resistance risks, or that momentum will sweep along any dissenters. It will take a proactive approach by a project team to win user acceptance of new processes and responsibilities.

4. Question: After a best practice PLM/ERP integration, is there a next step?

Answer: Yes, briefly stated, consolidating in PLM all functions for the creation and management of bills of material (BOM) and bills of process (BOP). Some view this unifying approach as a significant step to a "Single source of truth" – but not all agree. I will examine this subject over the next parts of this paper.



Part 8: Introduction to Product Lifecycle Management as the System of Record

Preface Even with the economy rebounding, cost reduction is still a high priority. So is coping with relentless competitive pressures, such as the need to reduce Time-to-Market that fuels the need for more efficient collaborative product development (CPD) processes. Now is the time, therefore, to explore using PLM as the system of record (SoR). It is an expanded vision for unifying PLM/ERP – plus MES in some industry sectors. SoR is based on manufacturing process management (MPM) processes aided by software capabilities. PLM as the System of Record – An Overview At this time, there is no known industry-wide accepted definition/scope of PLM as the SoR. For our purposes, an SoR is the authoritative data source for a given data element. It is also known as the “single source of truth,” storing the authorized version only once for use by all systems and all users. The scope of SoR implementation, however, must be clarified appropriate to a company’s individual needs and ambitions. The scope could include many data elements/files of product definition: lifecycle stages, parts, routings, assembly instructions, labor and equipment resources, specifications, costs, quality, computer-aided-design (CAD) data and more. When did the quest for PLM as the SoR begin? Since the days when engineering parts lists (EPL) on blueprints were “thrown over the wall” to manufacturing. One aspect has been the constant concern to maintain product configuration integrity – acutely painful to achieve with non-integrated software systems and processes. Also, manufacturing had to restructure the EPL to meet its requirements for ERP processing, often different from the engineering view of the product structure. Alas, data “silos” were created, and the heated discussions began, “Who owns the BOM?” Collaborative Product Development Associates (CPDA) nailed the issue in 1997, “But, the right way to approach the PLM/ERP integration problem is not to write costly integrations – the right way is “to change the way the product is represented, until it is represented in a form that an ERP system can interpret easily.” In other words – use MPM processes.



MPM in PLM as the System of Record: Introduction MPM is the heart of PLM as the SoR concept. It is the collection of processes and technologies used to define how products are to be manufactured and delivered. It is an approach for unifying the eBOM/mBOM processes, and creating and maintaining the related information for bill-of-processes (BOP) for making parts. Currently, both PLM and ERP systems have product definition functions – some similar by name, but not by capability. Both PLM and ERP have bill-of-material (BOM) management capabilities, yet with distinct differences:

The engineering version (eBOM) is the “As-Designed” view, as the engineer sees the product structure.

The manufacturing version (mBOM) is the “As-Planned” view, the way manufacturing needs to structure the product for ERP in order to plan material requirements.

What’s more, the differences between the two versions must be recognized and accounted for to achieve complete product configuration integrity over the lifecycle of the product. As CPDA pointed out years ago, the key thought is to create the mBOM in PLM. Then it is passed to ERP and is useful without further restructuring. Final Thought The potential strategic value of PLM as the SoR, with MPM processes, suggests a thoughtful evaluation of its use to boost a company’s CPD environment. Some consulting firms, e.g., Gartner/AMR and CIMdata, among others, have endorsed the SoR vision. But, not all PLM/ERP system users see eye to eye on this issue.



Part 9: Manufacturing Process Management Explored

Preface The previous part introduced manufacturing process management (MPM) as a significant step to make product lifecycle management (PLM) the System of Record (SoR) - and its potential to help boost the efficiency of a company's CPD effort. My definition is straightforward, "A collection of technologies and processes to define how products are to be manufactured." Nevertheless, the scope of applications involved can vary because companies will interpret the scope - narrow or broad - to match their unique requirements. In some large, complex companies, such as automotive, taking a broad scope of MPM applications is valid and justified. It could include plant design layout, simulations, ergonomics, computer-aided-manufacturing (CAM) and more. Software providers such as Dassault with its DELMIA suite and Siemens with Technomatix present this broader scope as "digital manufacturing." Regardless of a company's MPM application scope, a core software-supported process is required. The Core of MPM The core of MPM is the capability to unify the creation and management of the engineering bill-of-material (eBOM), manufacturing bill-of-material (mBOM) and the Bill of Process (BOP). This capability is essential to realize PLM as the "single source of the truth" and to maintain configuration integrity over the product lifecycle. A key point: The capabilities of MPM functionality in PLM allow PLM software to assume the mBOM functions now in ERP. It recognizes that the mBOM must be synchronized with the eBOM for traceability of changes in order to maintain configuration integrity. Furthermore, in some multi-plant environments, multiple versions of the mBOM may be necessary to accommodate differences for individual plant methods in each plant's version of the mBOM. The "desired" MPM technology is to link eBOM/mBOM data in a bi-directional manner. Tight linking of this data provides detailed information to personnel who interact with the PLM/ERP systems. When an update is in process, the MPM system immediately alerts responsible personnel for possible action in the event the pending update affects any other linked data.



As Gartner has recognized7, however, this "desirable" technology is sophisticated and powerful; yet, it is not widely used in all software packages. As a result, when evaluating MPM software be alert to the differences in terminology and capabilities. Gartner calls linking "BOM synchronization." In PTC's MPMLink, the technology is "associative." SAP calls it "Guided Structure Synchronization." New MPM processes and software must meet the exacting needs of both engineering and manufacturing to promote acceptance of MPM. Numerous PLM software alternatives exist to accomplish this. For example, Microsoft has strategic partnerships with PTC and Siemens to support its Dynamic AX (ERP) customers with PLM and MPM capabilities. The reality is that not all companies can justify the "desired" PLM/MPM technology, referenced above. For those companies, some alternatives are available. In addition to the vendors mentioned above, other vendor offerings may be feasible to consider. Aras and Omnify, both PLM-only vendors, offer mBOM functionality without all of the "desired" technology. Other vendors offer some mBOM functionality in their PLM modules provided with their ERP system: IFS and Infor are two of them. The approach to help users keep the eBOM and mBOM in synchronization would rely on alerts, flags and change processes. Value of MPM MPM is starting to be recognized as a key module in PLM systems; it facilitates CPD. MPM should help to negate the "over the wall with the prints" mentality; no more serial processing, thus cutting non-value added time throughout the engineering- manufacturing continuum. Ultimately, the true value of using MPM is if it contributes to reducing "Times-to-Market, Volume and Profitability.” Time-to-Market is in PLM's sphere of influence; Times-to-Volume and Profitability are the domain of ERP (in some companies, MES). These Time metrics are clearly at the strategic level; furthermore, identifying operational (day-to-day) metrics should help to make a business case for moving forward with MPM, for instance, to reduce scrap/rework and increase quality. And, after all, true value has to be the prime criteria for deciding on MPM.

7 Gartner, “Hype Cycle for Manufacturing Product Life Cycle Management and Production,” 2010.



Part 10: Manufacturing Execution System Added to Foundation

Preface Now, let’s explore MES as another major foundation system in the continuing quest for competitive excellence. Introduction An MES is the IT capability to help manage manufacturing operations; the term manufacturing operations management (MOM) is also used to identify these applications. The depth and scope of MES/MOM applications vary broadly, but its core is the detailed management and execution functions for work-in-process – defining bills of processes (BOP) and data collecting and reporting, including for product genealogy and lifecycle status. Extended capabilities add visual work instructions, quality criteria and connectivity to production equipment for real time monitoring, to cite a few. MES Arises Why the increasing interest in MES? The consensus of opinions and surveys indicates two general reasons: 1) continuing competitive pressures driving the call for more efficient operations management, such as reducing scrap and rework, and 2) more MES software with expanded functions. In the past, large companies with demanding requirements for detailed work-in-process information usually energized the need for comprehensive MES, e.g., in highly complex and regulated companies, for instance, aerospace/defense, automotive, medical and semiconductor. ERP systems didn’t provide sufficient detail to help manage these complex operations efficiently. “Do It Yourself” (DIY) extensions to ERP were the expensive solution because comprehensive MES software was not available. Now, more commercially available MES software negates the DIY approach. The recent Logica MES Product Survey identified about sixty packages from PLM, ERP and MES software vendors, with wide ranges of industry focus, capabilities and costs. In addition, acquisitions and partnerships are a sourcing factor to consider, for instance, Dassault (PLM vendor) just acquired Intercim (MES vendor). What’s more, MES software vendors Apriso, iBaset and CIMx report rising interest for this software in other sectors, such as industrial equipment, and by small/medium businesses. With the escalating interest in MES, however, may come “turf wars.” Avoiding potentially devastating turf wars calls for comprehensive implementation planning that embraces healthy doses of cultural change management.



Implementation Planning An essential step is to gain a fresh – and objective – understanding of the current and probable future roles of each of the three inter-related systems in the total corporate vision: PLM for product innovation, MES for detailed operations management and execution, and ERP for high-level operations management. Additionally, all of the elements of comprehensive planning apply, particularly the prerequisite to link the MES vision to corporate goals, as stated in the MESA report “MESA Metrics that Matter Revisited.”8 Two other significant planning considerations include:

Achieving product configuration integrity by integrating the total product life cycle “As” statuses: Designed, Planned, Built and Maintained. Presently, neither PLM nor ERP individually can completely meet this need, just pieces. Therefore, integration with MES functions will be required for total integrity.

Designating the system of record (SoR), discussed in previous columns regarding PLM and manufacturing process management (MPM). In some circumstances, MES is considered for this purpose, as recognized by Julie Fraser, industry analyst and president of Cambashi Inc.:9 “As-Built is a critical phase of the lifecycle, particularly for products that may require maintenance or have safety implications requiring a recall. MES is usually the system of record for this phase.”

Furthermore, planning must be comprehensive; Julie Fraser cautions us about one of the pitfalls of improper planning:

“To speed up implementations, some companies try to focus only on the plant’s needs and treat integration as a second step. Because MES/MOM systems often have capabilities that ERP and PLM do also, it is important to decide which system will be the master of which data and have a vision. Conducting integration with implementation is the safest approach.”

Final Thought For a significant advance in the quest for competitive excellence, MES can be a major contributor – when properly unified with PLM and ERP.

8 Manufacturing Enterprise Solutions Association, www.mesa.org.

9 Contact Julie at [email protected].

mailto:[email protected]



Part 11: Final Thoughts

Preface The future is now; i.e., the past is only prologue. The future cannot be ignored, despite the current economic malaise. A recognized strategy is to use IT smartly to reduce the complexity of the virtual enterprise’s infrastructure and to increase its flexibility to meet changing conditions. Application Systems and Processes When planning for implementation, users should be aware of the current status and future trends. A few to keep in the radar scopes include the following.

Continuing development of “cloud” (also known as SaaS, Software-as-a-Service) alternatives to provide application functionality and avoid the costs of internal IT departments. The advantages and disadvantages have been under scrutiny for quite a while. One of the major issues is security.

Ongoing development of the major systems described in this document, specifically: o Product Lifecycle Management – not as mature as ERP systems, and

still expanding its application scope far beyond the original focus on PDM Note: Some perceive PLM as only for large companies. This impression is fostered by the lack of agreement on the definition and scope of PLM and lack of understanding. The rationale for investing in PLM – however defined – should based on the urgency to efficiently manage the engineering-manufacturing continuum.

o Enterprise Resource Planning – the general consensus appears that enhancements will be more in the delivery mode, e.g. SaaS, rather than application functionality Note: Many ERP vendors also offer PLM systems, either theirs or through acquisitions and alliances.

o Manufacturing Execution System – some say that this application is the last major frontier for achieving competitive excellence Note: See comment under PLM.

ERP systems have proven their values . . . and PLM systems have proven their values – when properly planned and implemented. Business literature is chock full of insight and inspiration regarding successful implementation and avoiding failure with these systems. Nevertheless, a few final comments are still appropriate. Planning and Successful Implementation Companies achieve successful PLM/ERP system implementations when the company has a clearly articulated vision, secures unwavering top management commitment, selects the appropriate software and commits adequate implementation resources. These are all significant issues to consider when selecting and implementing a PLM system.



There is no single “magic” path to successful implementation. Each company’s strategic priorities, business process needs and current system conditions differ and must be considered to develop its unique implementation strategy. With a precise definition of business process needs, a multi-disciplinary project team can identify the necessary PLM capabilities and determine the optimum implementation sequence that will gain the expected benefits. The industry axiom is “plan totally, increment in small steps, gain benefits as you go.” A Final Word on Cultural Aspects Finally, and most importantly, take into account that software is an enabler – only one factor in the system success equation. Experienced companies frequently refer to cultural risks as one of the foremost reasons for project failures. Technical reasons have rarely been the cause.

The implementation risks are often subtle – like an iceberg. The obvious, formal policies and processes exist above the waterline. Beneath it may be the informal attitudes, values, norms and fears of disparate teams and members that endanger the project. For instance, users may perceive a change in roles and responsibilities as a loss of status, power and job.

Management commitment, by itself, does not solve cultural resistance to accepting new processes. But, as the advertising slogan stated, “Don’t leave home without it.” What’s more, a project team cannot be passive, hoping that time will cure the resistance risks, or that momentum will sweep along any dissenters. It will take a continual, proactive approach by the project team to gain user acceptance of new processes and responsibilities. In fact, the project team must relentlessly work to eliminate any potential organizational potholes and landmines that can undermine expected project benefits.

Conclusion Remember that efficiency (do the right thing) is only one-half of the classic paradigm; the other is effective (do it rightly).

Maximizing the Value of PLM/ERP: Integration and Collaboration


Additional Sources of Information

There is a wealth of information available from many sources. The following is a representative list. In addition, most software vendors also provide generic literature as well as product specific documentation.

1. Aberdeen Group, Integrating the PLM Ecosystem, April 2008. 2. AMR Research, Multi-Enterprise, Are You Creating Collaborative Relationships and Developing

Collaborative Practices?, December 2007. 3. APICS – The Association for Operations Management, www.apics.org. 4. CIMdata, The Value of Unified Architecture for PLM, August 2008, www.cimdata.com. 5. Collaborative Product Development Associates, www.cpd-associates.com. 6. Fulcher, Jim, “Product Development in 3D – Integrating PLM and manufacturing solutions speeds

time-to-market by building production plans into product design,” Manufacturing Business Technology, January/February 2009.

7. Gardner, David J., Mass Customization, HappyAbout, 2009. 8. Gray, Christopher, and Dougherty, John, Sales & Operations Planning Best Practices, 2006,

www.grayresearch.com. 9. Harvard Business Review, “Closing the Gap: How Companies Achieve Smarter Product

Development and Make Better Decisions with Technology,” 2011. 10. Institute of Configuration Management, www.icmhq.com. 11. International Institute on Mass Customization & Personalization, www.iimcp.org. 12. Kegan, Tom, “Reconnecting Design & Manufacturing,” Desktop Engineering, June 2010. 13. Kennedy, Michael N., Product Development for the Lean Enterprise – Why Toyota’s System is Four

Times More Productive and How You Can Implement It, 2008. 14. Mass Customization & Open Innovation News, mass-customization.blogs.com. 15. Mint Jutras (Enterprise Systems Research), www.mintjutras.com. 16. PLM Glossary and Acronyms, www.product-lifecycle-management.com. 17. Product Development Management Association, www.pdma.org. 18. Radeka, K., and Sutton, T., “What is “lean” product development,” PDMA Visions magazine, June

2007, Volume XXXI, pages 11-16. 19. Reinertsen, Donald G., The Principles of Product Development Flow – Second Generation Lean

Product Development, 2009. 20. Society of Concurrent Product Development, www.scpdnet.org. 21. Smith, Preston G., Flexible Product Development – Building Agility for Changing Markets, 2008. 22. Stark, John, Product Lifecycle Management: 21st century Paradigm for Product Realisation, 2006. 23. Tech-Clarity Insight: The Evolving Roles of ERP and PLM, 2009, www.tech-clarity.com. 24. Tech-Clarity Insight: Integrating PLM and MES, 2011, www.tech-clarity.com. 25. Time Compression magazine, www.timecompression.com. 26. Wallace, Thomas and Stahl, Robert, “Building to Customer Demand,” 2006. 27. Watts, Frank B., Engineering Documentation Control Handbook, Third Edition, 2008. 28. Whittier Consulting Group, www.leantechnologydevelopment.com.

http://www.apics.org/

http://www.cimdata.com/

http://www.cpd-associates.com/

http://www.grayresearch.com/

http://www.icmhq.com/

http://www.iimcp.org/

http://www.mintjutras.com/

http://www.product-lifecycle-management.com/

http://www.pdma.org/

http://www.scpdnet.org/

http://www.tech-clarity.com/

http://www.tech-clarity.com/

http://www.timecompression.com/

http://www.leantechnologydevelopment.com/

Maximizing the Value of PLM/ERP: Integration and Collaboration


About the Author

Richard W. Bourke is the founder and principal consultant of Bourke Consulting Associates. His long-established firm is dedicated to assisting manufacturing companies to gain the benefits of Information Technology based solutions that span the engineering to manufacturing continuum. His extensive consulting experience spans discrete, process and repetitive manufacturing companies — ranging from Fortune 100 companies to small firms. His prior industry experience included material and IT management responsibilities. He earned a BS in Chemistry and MBA from UCLA.

To comment on this publication, contact the author at [email protected].

www.bourkeconsulting.com 1.888.461.0068

22 C Avenida Castilla Laguna Woods, CA 92637

http://www.bourkeconsulting.com/

mailto:[email protected]

http://www.bourkeconsulting.com/