Keywords

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 disciplines 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, process-planning, production, operation, and recycling. Many authors [1, 5] and system vendors describe similar linear models of the product lifecycle in order to address capabilities, concepts, or concerns in the implementation of PLM systems.

Kiritsis et al. suggest an easy-to-use model defined by three main phases [6]: 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 [7] 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 [8] 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 et al. [2] describe a holistic PLM model emphasizing different aspects that need to be addressed: strategy, culture and people, processes, product structures, and IT architecture. PLM in their view is a holistic business 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 publications 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 technology). They point out that every phase can gain substantial value from information provided 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 [9]. 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 presented 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.

Fig. 1.
figure 1

The essence of product type and product instance and the 4 processes of interaction between them

Full size image

The product type is the concept of a product. It is the offering presented on the market. The description of a product type includes everything that is needed to promote, sell, build, operate, servitize [10, 11], and recycle product instances. Examples of information describing a type are product requirements, master data for production such as drawings, BOMs, operation plans, and manufacturing methods, or recycling instructions. 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 environmental conditions and the spectrum in tolerances every instance is as slightly different. 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 referred to as the “digital twin” [12] – but also the knowledge we gain from observing the product instances and the people around them.

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 ac-curate 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 in-stance. 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.

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

Fig. 2.
figure 2

Business processes along the reference model

Full size image

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 internal processes from what happens outside of a company and its supply chain. Definition 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 focused 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 form the field back into the company and its definition process is a challenge [13]. 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 Fig. 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 form 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. Generalization 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 structure. It acts as a leitmotiv to put the various topics of PLM into context.