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

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.

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

Discussion Notes

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.


Discussion Notes

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.


Discussion Notes

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.


Discussion Notes

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.


Discussion Notes

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.


Discussion Notes

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.


Discussion Notes

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.


Discussion Notes

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.”


Discussion Notes

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.


Discussion Notes

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.


Discussion Notes

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.


Discussion Notes

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.


Discussion Notes

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.


Discussion Notes

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.


Discussion Notes

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.


Discussion Notes

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.


Discussion Notes

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.


Discussion Notes

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 Julie.Fraser@cambashi.com.


Discussion Notes

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.


Discussion Notes

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).



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.



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 dickb@bourkeconsulting.com.

www.bourkeconsulting.com 1.888.461.0068

22 C Avenida Castilla
Laguna Woods, CA 92637


ERP and PLM Integration Considerations by Richard Bourke

More Related Content

What's hot

Viewers also liked

Similar to ERP and PLM Integration Considerations by Richard Bourke

More from Amplephi

Recently uploaded

ERP and PLM Integration Considerations by Richard Bourke