# A Reference Model for PLM in the Area of Digitization

Felix Nyffenegger, Roman Hänggi, Adrian Reisch

## ► To cite this version:

Felix Nyffenegger, Roman Hänggi, Adrian Reisch. A Reference Model for PLM in the Area of Digitization. 15th IFIP International Conference on Product Lifecycle Management (PLM), Jul 2018, Turin, Italy. pp.358-366, 10.1007/978-3-030-01614-2_33. hal-02075549

HAL Id: hal-02075549

https://inria.hal.science/hal-02075549

Submitted on 21 Mar 2019

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# A Reference Model for PLM in the Area of Digitization

Felix Nyffenegger¹,
Roman Hänggi¹,
Adrian Reisch²

¹University of Applied Sciences HSR, Rapperswil, Switzerland

²Ernst & Young GmbH, Berlin, Germany

felix.nyffenegger@hsr.ch
roman.haenggi@hsr.ch
adrian.reisch@ey.com

**Abstract.** With the uprising discussion around digitization, the value of product data has reached a new level. Product Lifecycle Management aims to play a core role in enabling the digital transformation in industry. The focus of PLM has traditionally been on the management of processes and data to define product types while many concepts of digitization rest upon individual product instances. In the context of current PLM implementations, this new perspective is not yet widely understood. A model that explains the interaction of product type and its instances along the business processes is missing. This essay suggests a PLM reference model that separates the lifecycles of product types and product instance. Four phases in a closed loop process explain the interaction between type and instance and how they are connected to the business processes of a company. The model results from a series of workshops with industrial experts and was applied in several industrial projects.

**Keywords:** Product Lifecycle Management, Reference Model, Closed Loop PLM, Digitization

## 1 Introduction

During the past two decades the importance and value of product lifecycle management (PLM) has been continuously rising. Many companies today consider PLM as a core strategic topic. During this period, the scope of PLM and its impact on business processes has been growing. Today it is understood as a business activity to efficiently manage products and its digital representation along the complete lifecycle [1]. Typically, PLM emphasizes multiple processes inside and outside of a company.

Along with the expansion of PLM, its complexity has been growing a lot. To understand the impact of PLM in a company we need to understand many aspects such as interdisciplinary design processes, change management, sales configuration, global supply chain management, the role of variants in product structures, installed base and service subjects, and many more [2], [3]. In other words, establishing value adding and
sustain-able PLM concepts involves collaboration between experts from various disci-
plines inside and outside a company. Each of them has its own technical language and
its own specific models to explain his domain. However, cross-functional discussions
turn out to be difficult, since a common language is missing. Even the term "product"
is often discussed controversially.

The presented reference model intends to add a new perspective to explain the role of product lifecycle management on both sides: the product type and the product instances. We aim to give experts from different domains such as designers, supply-chain planners, service suppliers, IT-specialists, or PLM vendors a common and understandable framework to discuss PLM topics. In terms of education it helps to give PLM a novel, holistic structure. Eventually, it might contribute to shape the profile of PLM in the area of digitization and hopefully foster the discussion in research.

## 2 Related Research

Current reference models for product lifecycles can be divided in models suggested by researches, vendors of PLM solutions, and models from reference architectures suggested by standards. Also, they can be classified into linear approaches (birth to death) or circular approaches.

Eigner, one of the PLM pioneers in Europe, describes PLM as a holistic approach to enable information access and decision support throughout the complete lifecycle of a product [4]. He points out, that PLM must sup-port collaboration in business processes (e.g. design, sourcing and production) along the supply chain. In his reference model, the lifecycle stages of a product are: requirements, product-planning, development, pro-cess-planning, production, operation, and recycling. Many authors [5], [6] and system vendors describe similar linear models of the product lifecycle in order to address ca-pabilities, concepts, or concerns in the implementation of PLM systems.

Kiritsis et al. suggest an easy-to-use model defined by three main phases [7]: Beginning-of-life (BOL) including design and manufacturing, Middle-of-life (MOL) including distribution use and support in terms of repair and maintenance, and End-of-life (EOL) where products are retired. He intro-duces the term “closed loop lifecycle” and points out the lack of information flow between EOL and BOL. Later in [8] he proposes an ontology that is able to map all phases into one sematic model that supports both, the evolvement of the design of a product type as well as optimization in the MOL phase.

Porter and Heppelmann address a shift of paradigm in PLM in the area of smart, connected products [9] focusing on a business perspective. They show the immense power of closed loop information systems to gain competitive advantage. Additionally, they call attention to the necessary in-vestment in connected product capabilities in order to achieve long-term success of such an approach. From this perspective, the scope of PLM includes the “IoT technology stack” and the integration of filed product data into business systems.

Silventoinen, Pels, Kärkkäinen and Lampela [2] describe a holistic PLM model em-
phasizing different aspects that need to be addressed: strategy, culture and people,
processes, product structures, and IT architecture. PLM in their view is a holistic busi-
ness concept that requires balanced actions in all these aspects.

Terzi et al. summed up the history of PLM and set a reference for many PLM publi-
cations in research [3]. The authors, knowing the research community very well, agree
on three major phases suggested by Kiritsis et al. and define three fundamental elements
of PLM: processes, methodologies, and ICT (information and communication technol-
ogy). They point out that every phase can gain substantial value from information pro-
vided by the other two phases, but the information loops need to be closed. The authors
assign PLM a central role to close these loops with all its elements.

The community of industry 4.0 in Germany describes a reference model for the lifecycle of a product called RAMI 4.0 [10]. The model has three dimensions: layers (from asset to business), hierarchical levels (from product to work-center to connected world), and the lifecycle value stream. In the third dimension, the lifecycle value stream is separated into two subsequent sections: the lifecycle of the type (as designed) and the lifecycle of the instances (as produced).

However, none of the models mentioned above separates the lifecycle of a product type and the lifecycles of its instances. Although the phases of operation and recycling clearly belong to the product instances and every instance has a different life. Especially for digitized or connected products, it is interesting to include the aspects of these individual lives into the PLM thinking. Production by its nature forms the transition from type to in-stance and therefore plays a key role in this thinking pattern. Closing the loop from EOL to BOL in that sense then must be the opposite to production.

Complementary to the literature mentioned above, that strongly influenced the pre-
sented work, we would like to share the following thoughts.

3 Description of the Reference Model

3.1 Overview

The general reference model, illustrated in Fig. 1, can be divided into two main areas. The lower area shows the scope of the product types, while the upper area represents the scope of the product instances. The separation of type and instance is a fundamental concept in the presented model and probably the most relevant difference to traditional models.

The product type is the concept of a product. It is the offering presented on the mar-
ket. The description of a product type includes everything that is needed to promote,
sell, build, operate, servitize [11], [12], and recycle product instances. Examples of in-
formation describing a type are product requirements, master data for production such
as drawings, BOMs, operation plans, and manufacturing methods, or recycling instruc-
tions. Also, configuration knowledge for the sales process or instructions and tools to
fulfill a service are typical items that describe a product type.

The product instance, on the other hand, represents a single physical or logical object that was produced based on a certain type. The instance is what we buy and consume as customers or users. The design of a type might include many variants while each
instance represents an individual configuration of that product type. Even due to envi-
ronmental conditions and the spectrum in tolerances every instance is as slightly differ-
ent. Instances are individuals. Instance-related information documents the history of
that instance and includes: "as built", and "as maintained" BOMs, serial numbers, test
certificates, information about its customer, and ultimately sensor data measured by the
product, its component, or its environment.

Ever since ERP world separates master data from transaction data. Similarly, we can
separate type and instance, but not just in terms of data. In the perspective of closed
loop lifecycle management, the complete life of a product type and all its instances must
be in focus. This includes master data, transaction data, the physical products and all
their components, data produced by the product instances during their life – often re-
ferred to as the “digital twin” [13] – but also the knowledge we gain from observing the
product instances and the people around them.

<figure><img src="image_2.png" /><figcaption>**Fig. 1.** The essence of product type and product instance and the 4 processes of interaction be-
tween them</figcaption></figure>
## 3.2 Two Lifecycles for Type and Instance and how they Interact

Looking more closely on the concept of type and instance leads to the conclusions that type and instance must have different lifecycles. Unlike traditional models that describe the lifecycle of a product from idea to re-cycling, the life of the type starts with a market opportunity or idea and ends with the phase-out of this type. A type will never be recycled, since it is just the concept of product. Whereas the life of an instance starts with the need to produce it e.g. due to planned manufacturing or due to a sales activity. The life of an instance ends with recycling or disposal. At this point, we need very accurate information about exactly this individual instance and its life.

The examples given for the lifecycles in Fig. 1. are just for illustration. Of course, the states of these lifecycles must be aligned with the product strategy, the processes, and organization of the companies involved in delivering these products.

On the timeline, the life of a type can be a lot shorter than the life of its instance, as shown in the case study of plant engineering below. Vice versa in the case of consumables the life of the instance is usually shorter than its type. While we continuously change and improve the definition of our product types, the instances follow their own lifecycle and might or might not be affected by changes of their types.

Essentially, the two lifecycles are not independent. There are four core processes linking them together.

**Definition.** The process of designing and maintaining the product types and their services. The definition of a product type encompasses all the information needed, to promote, sell, build, deliver, and serve its instances. In other words, the scope of the definition process is much wider than just the engineering of a product. It is the generic description of the instances along all steps of its lifecycle. In terms of digitization, the scope of definition needs an additional dimension. We are not just designing the physical, typically mechatronic system, and its supply chain. Also, the design of IT solutions for all future instances (IoT Hubs, Cloud services, etc....) must be considered. Particularly in terms of change management, this adds new complexity since the technology lifecycle of an IT platform is different from the lifecycle of the product instances. Yet, compatibility among both must be maintained.

**Instantiation.** The process of creating a product instance, based on the current state of its type. While creation of course comprises some way of manufacturing the product, the complete procedure from sales to delivery must be considered in this context. The instantiation process not only includes the creation of a physical product, but also its digital representation, the “digital twin”. From the perspective of digitization and industry 4.0 new approaches (such as smart factories) help us to efficiently acquire accurate information about the “birth” of a product instance. Therefore, the more traditional aspects of PLM and integrated product data currently experience a renaissance.

**Usage.** The process of using, servicing, and maintaining a product instance. During this process, the product instances can collect data about its behavior and the conditions or events around it. In this phase, the aspects of digitization seem to have one of the strongest leverage potentials. With the help of IoT or similar concepts product instances are able to continuously communicate to centralized data hubs and provide the instances with generalized knowledge (e.g. for predictive maintenance or decision support based
on artificial intelligence). This offers potential for new services or even new business models.

**Generalization.** The process of learning from the product instances and the data they collected. One key concept in this process is the aggregation of information acquired from many instances. This knowledge can be applied for both sides. It can improve the quality of service on existing instances and might lead to a better understanding of the market needs. Eventually, it leads to an improved design of the next generation product type or to the development of new services for the existing products. Again, in terms of digitization new technologies such as big data, machine learning, etc. are available to execute the generalization on a new level.

<figure><img src="image_3.png" /><figcaption>Fig. 2. - Business processes along the reference model</figcaption></figure>

These four core processes are of a very generic nature but help to characterize the
processes along the lifecycles of product type and instances on a holistic level. In
reality, these processes are described by a variety of sequential and parallel business
processes. Every organization looks different, however Fig. 2 pictures a common un-
derstanding of this process landscape. In the area of digitization, new aspects need to
be considered along these processes as briefly discussed in the sections above.

3.3 The boundaries of Company, Field, Customer, and Market

There is another interesting aspect to the four processes. As illustrated in Fig. 2, they
form two diagonals across the complete picture. These diagonals help to understand the
focus of the different processes.

The diagonal from top left to bottom right characterizes a boundary between the focus on customers and the focus on markets. Instantiation and usage are usually processes with one specific customer in focus. Particularly, the instantiation process is about breaking down the product type to the need of one specific customer. To achieve this in an efficient way, various concepts such as “assemble to order” strategies and configurators have become state of the art. On the other side, generalization and definition aim to understand and serve the need of a complete market. As mentioned above, generalization is about generating knowledge from many instances and other sources to understand the needs and behavior of a market. Definition then is the process of defining a product to be placed on that market. Thus, customer specific engineering is not part of the definition process, it’s rather a sub-process of the instantiation. To separate these two sides of engineering or design is crucial in the sustainable success of many companies.

The second diagonal from top right to bottom left separates the view on mainly in-
ternal processes from what happens outside of a company and its supply chain. Defini-
tion and instantiation are processes that are typically managed inside a company, while
usage and data acquisition for generalization take place where the products are being
used. Even if manufacturing is outsourced, the management of the supply chain will
usually be controlled inside the company that delivers the instance and is heavily fo-
cused on matching the internal processes. Innovation management on the other side is
of course organized inside a company, but the focus of these processes is clearly on the
field. The more we learn from product instances in the field and how customers interact
with them, the clearer market requirements can be formulated. Crossing the barrier from
the field back into the company and its definition process is a challenge [14]. New
technologies such as IoT, big data, and artificial intelligence might add substantial value
to fulfill this task in a more connected and analytical way.

4 Application in Industry

This reference model was the base for 13 workshops and 3 specific implementation
projects of the aspects of the model in industrial companies between June 2016 and
December 2018. The companies range from CHF 50 Mio up to CHF 2'000 Mio turnover.
The majority of the companies are privately owned, two companies are listed on
the stock market. The participants of the workshops have been the Top Management of
the companies.

The findings on these projects can be summarized as follows:

* In particular, the model has proven to be helpful to explain the value of PLM and integrated information flows on C-level. This is a major accomplishment in light of the difficulties aligning all different aspects and complexity that digitalization brings to the industrial companies.

* The model seems to be capable to represent and align the views of the different organizational functions (product management, design disciplines, manufacturing, sales or service management).

* The complexity of the model and the generic terms for definition and instantiation is rather high. Often in workshops, definition and instantiation were replaced by “design phase” and “the factory”. While this clearly is a simplification of the original intention, it still helps the understanding.

* Interesting discussions resulted with several engineer-to-order (ETO) companies. It is agreed that the design effort of ETO is part of the instantiation.

* Since design effort only scales on the definition side more focus must be spent on the definition of ETO products. This finding resulted in the “ETO-corner” shown in Figure 2.

* During usage phase, change management of the instances does matter for services, but also affects the generalization of knowledge, particularly on long living product instances.

* Digitization of products (smart, connected products and new digital services) heavily relay on the provided quality of definition and instantiation data. PLM initiatives are no longer pushed by engineering departments but rather pulled by service or even new business model initiatives.

This model has been proven as the base for many digitalization strategies:

* The understanding of the importance of the definition phase as the base for the implementation of digital services in the usage phase is widely shared and owned by Top Management. This focus resulted often directly in an increase of budgets for this phase to drive the digital transformation.

* The generalization phase has today an increasing importance through the focus on learning from collected data. This requires a structured process based on this model.

# 5 Conclusion and Outlook

The presented reference model results from the learnings of long term experience in PLM implementations and a series of projects to create smart, connected products, that focus on the usage phase. Digitization requires a holistic understanding on product data, how it is created, and how physical product instances are connected to the digital world. In that sense, the presented reference model was helpful to start the discussion and add
"PLM thinking", particular in the ideation phase of new product concepts or business models in a wide range of applications.

Feedback from industry as well as two mapping case studies that are currently in
work indicate that the phases of definition, instantiation, and usage are well understood
and can be easily mapped to the process landscape of a company. The generalization
phase is discussed controversially and offers potential for further research. Generaliza-
tion of data from many product instances starts to be a common strategy to develop new
service products (e.g. predictive maintenance) or even new business models. Yet, only
few understand generalization as a tool to better understand the behavior of a product,
its users, and its environment in the market.

In academic education, the authors use the reference model to give courses a struc-
ture. It acts as a leitmotiv to put the various topics of PLM into context.

6 References

1. J. Stark, "Product Lifecycle Management," in Product Lifecycle Management, 2011, pp. 1-16.

2. A. Silventoinen, H. J. Pels, H. Kärkkäinen, and H. Lampela, "Towards future PLM maturity assessment dimensions," Proc. 8th Int. Conf. Prod. Lifecycle Manag., pp. 480-492, 2011.

3. Terzi, A. Bouras, D. Dutta, M. Garetti, and D. Kiritsis, "Product lifecycle management – from its history to its new role," Int. J. Prod. Lifecycle Manag., vol. 4, no. 4, p. 360, 2010.

4. M. Eigner and R. Stelzer, "Produktdaten-Management und Product Lifecycle Management," in Product Lifecycle Management - Ein Leitfaden für Product Development und Life Cycle Management, 2008, pp. 27-45.

5. A. Saaksvuori and A. Immonen, Product Lifecycle Management. 2008.

6. J. Stark, "Product Lifecycle Management," in Product Lifecycle Management: 21st Century Paradigm for Product Realisation, 2011, pp. 1–16.

7. D. Kiritsis, A. Bufardi, and P. Xirouchakis, "Research issues on product lifecycle management and information tracking using smart embedded systems," Adv. Eng. Informatics, vol. 17, no. 3-4, pp. 189-202, 2003.

8. D. Kiritsis, "Closed-loop PLM for intelligent products in the era of the Internet of things," Comput. Des., vol. 43, no. 5, pp. 479-501, May 2011.

9. M. E. Porter and J. E. Heppelmann, "How smart, connected products are transforming com-petition," Harvard Business Review, no. November 2014. 2014.

10. VID/VDE, "Reference Architecture Model Industrie 4.0 (RAMI4.0)," Igarss 2014, vol. 0, no. 1, p. 28, 2015.

11. S. Vandermerwe and J. Rada, "Servitization of Business: Adding Value by Adding Ser-vices," Eur. Manag. J., vol. 6, no. 4, pp. 314-324, 1988.

12. T. Baines and H. Lightfoot, Made to Serve. How manufacturers can compete through ser-vitization and product-service systems, vol. 1. 2013.

13. A. Parrott and W. Lane, "Industry 4.0 and the digital twin," Deloitte Univ. Press, pp. 1-17, 2017.

14. M. Rossi, L. Cattaneo, J. Le Duigou, S. Fugier-Garrel, S. Terzi, and B. Eynard, "Lean prod-uct development and the role of PLM," in IFIP Advances in Information and Communica-tion Technology, 2016, vol. 492, pp. 183-192.