T he drivers and factors i nfl ue n c i n g P L M
a dopti o n a n d s e l e c t i o n
Council for Scientific and Industrial Research, Integrative Systems Group
Copyright © 2015 by M Jacob and J Erasmus. Published and used by INCOSE with permission.
Abstract. Product Lifecycle Management (PLM) combines enterprise-wide product and
process innovation improving the manufacturing industry’s ability to meet the need for shorter
product lifecycles, satisfying customers’ expectations and adhere to stricter regulatory,
environmental and safety requirements. Unfortunately, despite its global success, the adoption
of PLM is struggling to gain traction in South Africa. This makes it difficult for local
engineering and manufacturing firms to compete in the global market and maintain proper
control of their products as they progress through the different life stages. This paper presents
the drivers and factors to consider during selection and implementation of a PLM business
Product lifecycle management enables an enterprise to be in control of its products regardless of
the lifecycle phase and current ownership of the product. PLM addresses and improves the
activities of product portfolio management, development, realization and support, to enable a
company to reduce product-related costs, engineering changes, product recalls, warranty and
recycling costs. It shares many of the objectives of systems engineering, but extends some of
the methodologies and processes to industries where the product is not typically a system
consisting of many parts, such as fashion, food and beverage production (Grieves, 2012).
Though those products certainly adhere to the definition of system, systems engineering as a
discipline is less relevant due to the simplistic nature of the products (INCOSE, 2011).
However, the technical management processes and lifecycle considerations of systems
engineering are as relevant as with more complicated product systems.
Thus, as an enabler for engineering and manufacturing of most products, PLM is becoming
essential for enterprises to be competitive in a rapidly globalising world of more customised
products (Kroes et al., 2009). This article provides a guide for the planning and implementation
of the PLM business approach. It starts with a brief overview of the definition and scope of
PLM, followed by the typical goals of adoption and implementation. With the goals in mind,
PLM solution selection and implementation strategies are discussed. The typical capabilities
offered by PLM solutions are listed, to allow practitioners to perform a comprehensive
evaluation of the most suitable solution.
PLM as a business approach and the associated enterprise solution implementation represents a
significant organisational change endeavour. As with most such large changes, it is critical that
the objectives and expectations are properly determined and documented, the programme is
formally managed and the potential impact on the operations is well understood. Thus, it
becomes an enterprise engineering endeavour. To account for this, the widely used Open Group
Architecture Framework (The Open Group Architecture Forum et al., 2011) will be used to
explain some of the concepts to consider during selection and implementation.
Enterprise engineering as an enabler of change
Enterprise engineering as a discipline was born from the need to design enterprises as a
comprehensive and coherent system, instead of allowing the continued ad-hoc emergence of
enterprises (de Vries et al., 2013). Martin (1995) stated that “Enterprise Engineering is an
integrated set of disciplines for building or changing an enterprise, its process and systems.”
Hoogervorst (2009) argues that good enterprise design is essential for high performance and
that enterprise engineering is underpinned by the fields of enterprise ontology and architecture.
The Open Group defines an enterprise as the highest level of organisation currently under
consideration and typically includes all missions and functions (The Open Group Architecture
Forum et al., 2011). Thus, enterprise in this sense is the equivalent of the system-of-interest of
the current endeavour. By considering it as a system, an enterprise is composed of system
elements which can roughly be categorised into people, processes or tools. The Open Group
Architecture Framework (TOGAF) considers 35 element types (meta-objects), divided into
architecture domains, as shown in
Figure 1: Representation of the TOGAF9 Content Metamodel (The Open Group Architecture
Forum et al., 2011)
Even though the enterprise is composed of physical elements, the enterprise itself is not a
physical entity. The elements that the system consists of, are in most cases independent, but
brought together to achieve a specific goal. Therefore, an enterprise is a complex system,
consisting of many interrelated elements with nonlinear relationships (Bennet, 2011).
However, an enterprise consumes, produces and incorporates many other systems, making it a
system of systems. Harmon (2005) argues that an enterprise is best described as an intelligent
complex adaptive system of systems (ICASOS).
Ontology only allows for description and definition of the elements of the enterprise. By its
nature though, a system’s behaviour is not only a result of its components, but also emerges
from the relationships between those components (Green and Bossomaier, 1993). The term
“system” covers a very wide spectrum though, from tiny biological systems to galaxies, or even
abstract systems such as mathematical models. Most systems share some common
characteristics, including the following (Baianu, 2011):
Systems are abstracts of reality;
Systems have structures, defined by its parts;
Systems have behaviour, such as the processing of material, information or energy;
The parts of the system have functional and structural relationships.
Enterprise architecture is a way of depicting the current or desired elements of the enterprise
system and the relationships between those elements. Zachman (1987) stated that such
architecture descriptions are created to manage complexity and change. TOGAF provides a
meta-model that shows the standard relationships between its 32 meta-objects (The Open
Group Architecture Forum et al., 2011). This meta-model is the starting point for creating
catalogues, matrices and models of an enterprise, to ensure that relationships between
enterprise elements are captured according to the framework principles.
PLM definition and scope
Product lifecycle management is a means for enterprises to keep control of its products from the
initial idea, through development, realisation and utilisation, until the eventual end-of-life. This
approach calls for planning of the entire life of the product, by already considering during
development how the product will be produced, supported and retired (Grieves and Tanniru,
2008). Thus, PLM brings together and aligns the domains of innovation management,
engineering, technical management, manufacturing and logistics. It should be noted that
product lifecycle management is not only the implementation of a software layer that integrates
the product data from various business applications. Although data integration is essential,
PLM is a business approach and philosophy that affects the core business, from ideation to
after-sales support of products (CIMdata, Inc., 2012). The scope of PLM includes the following
Managing a well-structured and valuable product portfolio;
Improving the financial return from the product portfolio;
Providing control and visibility over products throughout the lifecycle;
Managing product development, support and disposal projects effectively;
Managing feedback about products from customers, products, field engineers and the
Enabling collaborative work with design and supply chain partners, and with customers;
Managing product-related processes so that they are coherent, joined-up, effective and
Capturing, securely managing, and maintaining the integrity of product definition
information. Making it available where it’s needed, when it’s needed;
Knowing the exact characteristics, both technical and financial, of a product throughout
As explained, product lifecycle management is not only a software tool. It is a complete
business approach and thus will have an impact on all enterprise domains. This is not to say that
it will affect all business units, but rather that it will change the following elements in the
chosen sphere of business:
Applications and software tools;
Information management tools;
People and roles;
Special techniques and methods;
Equipment and facilities;
Measurement and metrics;
Structure of the PLM organisation;
Enterprise change management.
Strategic business objectives driving PLM adoption
Product lifecycle management not only brings together all the parties involved with the
realisation of the product, but it also offers the producer of the product the opportunity to
provide its customers with after-sales services. By capturing the original expectations and
linking those expectations with specific characteristics of the product, the organisation can
respond to changes in the market much faster and more effectively.
Apart from the improved product control, the implementation of product lifecycle management
also presents the following potential benefits (Stark, 2011):
Reduce product related costs;
Improves the ability to manage and utilise multi-disciplinary engineering data
Increased ability to capture and manage intellectual property;
Reduce risk throughout the product lifecycle;
Improves innovation and time-to-market;
Enables collaboration across the design chain and supply chain;
Assists compliance with regulations;
Provides one version of the truth about a product;
With accurate, consolidated information about mature products available, low-cost ways
can be found to extend their revenue-generating lifetimes;
Typical current targets for PLM are to increase product revenues by 30% and decrease
product maintenance costs by 50%.
PLM implementation strategies
Due to the scope of product lifecycle management, implementation represents a major business
change and should be managed accordingly. Therefore, the implementation should be
supported by executive management, planned properly and the objectives, scope and strategy
should be clearly defined. Table 1 shows different implementation approaches and typical
Table 1: Different implementation approaches (Stark, 2011)
Uncoordinated cherry-picking and
A short-term plan
A three-year strategy and plan
Integrated vision, strategy and plan
It is shown that a three to five year implementation, with proper planning, typically results in
significant improvements in productivity, time to market and cost reduction. Stark (2011)
advocates a five-step strategy for PLM implementation:
1. Collect and assemble the information with which the strategy will be developed;
2. Formulate and describe alternative strategies for implementation and identify the
resources and policies to be applied;
3. Evaluate the potential strategies and select the most appropriate;
4. Communicate the selected strategy to everyone who will be affected; and
5. Implement the implementation plan.
However, PLM implementation is often very disruptive to the operations of the enterprise, like
most large change management endeavours. Furthermore, it is often very difficult to convince
all parties involved and affected that the change will be beneficial to them. An option is to
gradually introduce PLM into the business, by implementing on a specific project or
organisational unit first, then expanding to a single programme or additional units, before
finally rolling it out to the entire enterprise. Garetti et al. (2005) recommends this approach, to
benefit from the following:
Experimental learning first, in order to push users to modify their working attitudes
towards the new reengineered processes;
Training on the use of software tools, together with practical use cases derived from the
To focus efforts on those business units that will give the most benefit, it is useful to make use
of the concept of core versus non-core business competencies. Business competencies are the
groups, teams or units in the organisation that perform one or more functions and deliver
outputs by performing business processes. Non-core competencies are typically those functions
performed by most enterprises. These competencies usually support the core business and do
not deliver any special value. It has been shown that non-core competencies typically comprise
approximately 80% of the business competencies, but also represent the greatest cost saving
opportunity. Core competencies only comprise about 20% of the business and represent
opportunities for innovation and growth (LEADing Practice, 2013).
Core competencies are those functions that directly contribute to the primary output of the
business and are further categorised according to the value of the competencies. Core
competencies are further divided into two classes. Core-competitive competencies are those
that are done by all competitors in a specific market, and do not give any one of them a distinct
competitive advantage. Core-differentiating competencies are those functions that give an
organisation its competitive advantage.
By combining the approach suggested by Stark (2011) with the recommendation of Garetti et
al. (2005) an enhanced implementation strategy can be formulated:
1. Determine requirements; perform evaluation and select a single software suite that will
determine all future engineering software acquisitions. This software selection should
support the type of research and development that the company wants to do in the
2. Purchase the collaborative product data management module of this suite and the bare
minimum modules that will form a good starting point.
3. Develop the business and value model, based on the company business plan and
objectives, showing the targeted product, service and operation transformation.
4. Develop the core-differentiating business processes necessary to realise this business
5. Implement and deliver training on the out-of-the-box processes and software tools for the
6. Adopt, standardise and implement the core-competitive business processes across the
7. Adapt and implement the core differentiating business processes and determine impact of
possible configuration and customisation requirements on engineering software.
PLM solution selection
Product lifecycle management comprises the processes and practices associated with managing
a product throughout its lifecycle, from its conception through design and manufacturing
stages, to service and decommission. Product lifecycle management software provides a central
repository for all data and assets that enables workers to collaborate on products in real time.
When effectively implemented, PLM software can merge business systems, people and data
processes to facilitate a streamlined approach to product development.
Today’s top-rated PLM software solutions are both comprehensive and collaborative; such as
software that tracks and records information from various sources and departments, making
that information available to suppliers, engineers, marketing teams and other departments that
are vital to product development. Product lifecycle management software is also able to manage
product design (both 2D and 3D design elements), oversee the production pipeline, work in real
time and significantly reduce the costs associated with regulatory compliance. PLM software
should also effectively manage bill of materials (BOMs) (Top 10 Product Lifecycle
Management Software Report, 2015). The top three PLM solutions hold approximately 57% of
the global market and an even higher portion of the South African market (Slansky, 2014).
As mentioned, the selection of a PLM software suite should be a long-term decision and be
based on the functionality required by the business. Table 2 shows the typical functionality
offered by the large PLM software suites. This table can be used to determine what
functionality is required by the enterprise, to ensure an informed decision is taken, which will
serve the enterprise well even with future expansion. These functionalities can be evaluated
according to a value matrix, similar to what is proposed by Erasmus (2014).
Table 2: Typical functionality offered by PLM solutions
Level 1 Functionality Level 2 Functionality Level 3 Functionality
Parametric Parametric solid modeling
2D design, layout, drafting, annotation and
Class A shape design
Advanced surface modeling Reverse engineering and surface reuse
3D electrical design
Systems generative 3D electrical
Wire harness documentation and
Technical communication for energy,
process and utilities
Nuclear, offshore, power generation, wind
Generative piping and tubing
Piping and tubing design
Body in white modeling
Generative shape optimizer
Mechanical surface design
Aerospace and defence
Aeroengines, aerostructures, avionics,
ballistics and blast, composite structures,
landing gear, space systems
Transportation and mobility
Body in white, brake systems, chassis,
crashworthiness, ground vehicles, interiors,
mechanisms, powertrains, tires
3D tolerancing and annotation
Drafting and annotation
Aerospace Sheet Metal Design
Cast and Forged Part Design
Composites Fiber Modeler
Composites Manufacturing Preparation
Fabricated Part Design
Plastic Part Design
Structure Detailed Design
Structure Functional Design
Model Based Definition
Ship Structures, Marine Structures,
Technical Communication for Marine and
Marine and offshore
Energy, process and utilities
Fluid systems design
Electrical and fluid system
Structural part and assembly design
Modelica Systems Simulation
Systems Safety Analysis
Flexible Circuit Board
Electro-Mechanical Circuit Board
Transportation and Mobility Electronics
Acoustics, Circuit Boards, Computers &
Peripherals, Hand-held Devices,
Microelectro-mechanical Systems, Paper
Technical Communication for High Tech
Robotics Arc Welding, Robotics Offline
Programming, Robotics Spot Welding, Robot
Task Definition, Robotics Virtual
Jigs and Tooling Design
Mold Tooling Design
Thermal Transient and Steady-state
Fluid Fluid Flow and Heat Transfer
Numerical Control NC Programming
Part Modeling, Tool Design, Inspection
Analysis Modeling Stress Analysis/Finite Element Method
Multidiscipline Simulation and
Structural, thermal, flow, motion,
optimization and multiphysics analyses
Systems Level Modeling and
Build and manage large analysis model
Injection molded parts Plastic Filling Process
Weight of Moving Components
There are increasing advantages to product lifecycle management and although implementation
of PLM is not easy and can be time consuming, companies must meet the increasing demands
of their customers. They need to rapidly and continually improve their products and services
and to achieve this they will turn to PLM. By using the software functionality table presented in
this article, enterprises will be able to choose a suitable vendor according to the specific
requirements of their company. With the selection made, it is crucial that all further business
process development and software acquisitions should be done with this selection in mind. The
value of PLM lies in the ability to integrate the work of multiple disciplines and functions of the
enterprise, enable collaboration across the supply chain and to streamline the management of
the product throughout its lifecycle. It is essential that all product information is available to all
parties who should have access to it.
Collaboration across the supply chain is rapidly increasing in importance. For this reason,
regardless of the specific capabilities desired within the enterprise, the determining factor
during PLM software suite selection may be the industry the enterprise operates in. If the
majority of suppliers use a specific PLM or CAD solution, it makes sense to opt for that same
one, to facilitate product information exchange. If the enterprise is a tier two or three supplier
itself, the PLM solution of its clients should be the main factor to consider during PLM
selection. Once implementation starts, it is advisable to start small and expand as success if
achieved and value is shown. This allows for minimal disruption to the operations of the
enterprise and to create change champions along the implementation project.
Baianu, P.D.I.C., 2011. Complex Systems Theory and Biodynamics, in: Baianu, P.D.I.C. (Ed.),
Complexity, Emergent Systems and Complex Biological Systems. PediaPress: Mainz, Germany.
Bennet, A., 2011. Organizational survival in the new world: the intelligent complex adaptive system,
First. ed, KMCI Press. Routledge, Amsterdam ; Boston.
CIMdata, Inc., 2012. Application Migration & Application Integration - New strategies for PLM
deployments (Research). CIMdata, Inc., Ann Arbor, Michigan.
de Vries, M., van der Merwe, A., Gerber, A., 2013. Towards an enterprise evolution contextualisation
model, in: Enterprise Systems Conference (ES), 2013. Presented at the ES2013, IEEE, Cape Town,
South Africa, pp. 1–12. doi:10.1109/ES.2013.6690078
Erasmus, J., 2014. Requirements engineering for human activity systems, in: EMEASEC 2014
Proceedings. Presented at the INCOSE EMEA Sector 2014 Systems Engineering Conference,
INCOSE, Cape Town, South Africa. doi:10.13140/RG.2.1.2329.8085
Garetti, M., Terzi, S., Bertacci, N., Brianza, M., 2005. Organisational change and knowledge
management in PLM implementation. International Journal of Product Lifecycle Management 1, 43–51.
Green, D.G., Bossomaier, T.R.J. (Eds.), 1993. Complex systems: from biology to computation. IOS
Grieves, M.W., 2012. Virtually Indistinguishable, in: Rivest, L., Bouras, A., Louhichi, B. (Eds.), Product
Lifecycle Management. Towards Knowledge-Rich Enterprises. Springer Berlin Heidelberg, Berlin,
Heidelberg, pp. 226–242.
Grieves, M.W., Tanniru, M., 2008. PLM, process, practice and provenance: knowledge provenance in
support of business practices in Product Lifecycle Management. International Journal of Product
Lifecycle Management 3, 37. doi:10.1504/IJPLM.2008.019969
Harmon, K., 2005. The “systems” nature of enterprise architecture, in: Systems, Man and Cybernetics,
2005 IEEE International Conference on. Presented at the SMC2005, IEEE, Waikoloa, HI, USA, pp.
78–85 Vol. 1. doi:10.1109/ICSMC.2005.1571125
Hoogervorst, J.A.P., 2009. Enterprise Governance and Enterprise Engineering, 2009th ed, The
Enterprise Engineering Series. Springer Science & Business Media, Diemen, The Netherlands.
INCOSE, 2011. Systems engineering handbook: a guide for system life cycle processes and activities,
3.2.2 ed. International Council of Systems Engineering, San Diego, CA.
Kroes, P., Light, A., Moore, S.A., Vermaas, P.E., 2009. Towards an Integrated Philosophical
Understanding, in: Philosophy and Design: From Engineering to Architecture. Springer, Dordrecht, pp.
LEADing Practice, 2013. Growth: Core Differentiating & Core Competitive Reference Content
(Reference content No. LEAD-ES10002BC), Value Architecture. LEADing Practice.
Martin, J., 1995. The great transition: using the seven disciplines of enterprise engineering to align
people, technology, and strategy. AMACOM, New York.
Slansky, D., 2014. Product Lifecycle Management - Global Market Research Study (Market research).
ARC Advisory Group, Dedham, MA, USA.
Stark, J., 2011. Product lifecycle management: 21st century paradigm for product realisation, 2nd ed.
ed, Decision engineering. Springer, London ; New York.
The Open Group Architecture Forum, Dave Hornford, Tara Paider, Chris Forde, Andrew Josey, Garr y
Doherty, Cathy Fox, 2011. TOGAF Version 9.1, Open Group Standard. The Open Group, USA.
Top 10 Product Lifecycle Management Software Report, 2015.
Zachman, J.A., 1987. A framework for information systems architecture. IBM Systems Journal 26,
Jonnro Erasmus has worked as an industrial and systems engineer in the electricity, transport
and manufacturing industries. He has also had the responsibility of managing interdependent
risks between major construction projects of both public and private enterprises. He specialises
in the use of requirements and functional analysis to identify risks and opportunities in business
systems and engineering organisations. Jonnro holds a bachelor of engineering from the
University of Pretoria and a master of engineering from the University of Johannesburg. He is
also a registered professional engineer with the Engineering Council of South Africa.
Merin Jacob is a student at the University of Pretoria and has worked as a systems engineer in
training. Her responsibilities included the initial documentation regarding product life-cycle
management, design improvements of the freight rail wagon system, and initial documentation
for the mining, manufacturing and transport industries. Merin is specializing in design of
mechanical systems and is currently working towards a bachelor’s degree in mechanical and
aeronautical engineering from the University of Pretoria.