Keywords

1 Introduction

Product lifecycle management (PLM) in global manufacturing companies has been studied through the analysis of nine industrial cases. Six of them were analyzed in 2011 by Pulkkinen et al. [1] and three new companies are analyzed in this follow-up study in 2014 and 2015. The focused factors of PLM were the maturity of PLM, business types and PLM systems’ architectures.

The research questions of this paper are: how mature is the PLM approach and what kind of changes are taking place in PLM architectures of case companies? The paper continues with a literature review, which substantiates the research approach and serves as a theoretical basis for of the model which is used in the analysis. The research method is outlined and results presented. The conclusions summarize the findings and estimate the effects of the changes in the architectures of PLM systems.

2 PLM Architecture, Maturity and Business Processes

Two widely cited models of different PLM architecture integration approaches were studied. Crnkovic et al. [2] identify three levels of integration in their book “Implementing and Integrating Product Data Management and Software Configuration Management”. Even though they concentrate on the integration of PDM and SCM, the same logic can also be applied to the integration of other engineering tools and subsystems like PDM and ERP or EDM and PDM. The levels are full integration, loose integration and no integration [5].

In full integration a homogenous system containing all the subsystems with a common repository and common information model is built. Loose integration means that the each system has its own functions and local data storage. The systems are independent, but there are mechanisms for information exchange and thus data can be accessed from both systems. If there is no integration, the data transfer between the systems has to be done manually by users [5].

Bergsjö et al. [3] identify four different approaches as ways to connect the tools used for product development. Similarly to Crnkovic et al. [3], Bergsjö et al. [2] focus on PDM and SCM integration concepts in order to simplify the analysis. The four approaches are best-in-class, one system as integrator, all-in-one integration and peer-to-peer integration [2].

These two models are compared and based on them three dominant architecture types were discovered: legacy architecture, single source architecture and service-oriented architecture [5].

  1. 1.

    The term legacy, or ad hoc, architecture can be used to define the state of the architecture of tools, applications and systems of a company before or in the starting point of a PLM software harmonization project. This means there is little or no integration between the subsystems and data exchange is performed mostly manually. The legacy system might have a unifying name, but in practice usually consists of many different databases and applications [4] with limited or non-existent interoperability.

  2. 2.

    The all-in-one integration introduced by Bergsjö et al. [2] shares several aspects with full integration model defined by Crnkovic et al. [3] and both form a single source architecture. Typical for a single source architecture and for the two integration models is that it is important that all the data is stored in a single database with which each separate tool communicates. As the master database usually belongs to one system, such as PDM or ERP, it can be defined as the PLM backbone [5].

  3. 3.

    The third architecture model is the Service-oriented architecture (SOA). In this study, service-oriented architecture is considered as an approach which integrates heterogeneous applications and databases. In this context, heterogeneous means that the information models and processes vary. Therefore SOA will make it possible to bridge gaps between the intercommunication between various tools.

The benefits of architecture integration can be approached for example from the viewpoints of user satisfaction and system manageability. Engineers who use the tools prefer at least the amount of functionality they have had before, thus resisting any change which might hinder the usability of a software or system. Therefore companies keep using legacy systems or customize the new software implemented drastically. From the other viewpoint, the amount of different subsystems and tools can lead to a very difficult to manage architecture with several interoperability functions and integrations between every system [5].

At the moment the legacy architecture is still found to be the most common, as single source bundles and the middleware needed in a service-oriented architecture are difficult to implement at present. Because of the lack of standardization and common information models between the software of various suppliers, the task of creating the middleware needed for SOA is still very challenging [5].

A four level PLM maturity model put together by Vainio [5] was used. The model is based on two models by Batenburg et al. [6] and Stark [7]. Each of the levels include a determination of the level of application of PLM, extent of the users and organizations involved in the PLM application, level of integration, level of interoperability and finally a summary of the situation as a whole. The model is presented in Table 1.

Table 1. PLM maturity level summary.
Full size table

3 Research Method and Material

An overall outlook of the current situation of PLM in a considerable sample of the largest Finnish manufacturing companies is presented in this paper. The material used is based on nine case studies, corresponding to the amount of companies involved in two research projects. The case companies represent fairly typical examples of system architectures in the Finnish manufacturing industry. There are also some cases which do not share the same PLM strategies, for example when a company’s operations are based on project business, in other words one-of-a-kind products, rather than standard or configurable products.

We applied different methods for collecting the raw data and for the analyzing of it. The data was collected with pre-surveys done via e-mail, structured interviews and nine benchmarking sessions. Pre-surveys were used to gather factual information about for example the software systems used. The benchmarking sessions involved the participants of all the case companies involved in each project. In a session the hosts presented the PLM approach of a company and answered consequent questions. The active audience consisted of PLM experts, practitioners, managers, consultants, and researchers. The benchmarking sessions gave more accurate information on the PLM in a company than the interviews.

All the sessions were recorded, notes were taken and presentation material collected. The collected data was processed and reported (nine reports of 10–30 pages). Finally, the reports were sent for validation and verification to the interviewees and company representatives.

Benchmarking was found to be an effective research method. The information gathered in the pre-surveys and benchmarking site visits was examined and all the issues related to the subject of this paper were extracted. This information was then reflected to the PLM maturity and PLM system architecture integration models.

4 Results and Analysis: Maturity, Processes and Architecture

The four level PLM maturity model seen in Table 1, was used to evaluate all nine case companies. Results are presented in Table 2. The numbers in the table indicate the maturity level range from 0 to 3, in which Level 0 is seen as the initial level where PLM is not thoroughly understood and investments in it have not been made. Level 3 is a sophisticated level where PLM activities function across the extended enterprise and throughout the lifecycle of a product [5].

Table 2. The PLM maturity of the nine case companies.
Full size table

Several common challenges were discovered. Company mergers, in both being the company merged and merging, have created problems in the past. The amount of systems and tools has led to for example harmonization challenges. Most, if not all, PLM systems and tools still focus on the Beginning of Life (BOL) activities.

Especially the project companies have difficulties in information management, as the information, data and knowledge are spread across the other participants of the project. These subcontractors might have very different product data management systems and processes, which are not interoperable. Security questions emerge when more than one company wants access to certain information. A project company might not have the necessary information for service business if the information from other participants of the project is not available.

In addition to the evaluation of three more companies, one of the original six companies was re-evaluated after four years. Results from the second benchmarking session indicate that change in PLM related issues is not very swift. Some of the future plans mentioned in 2011 have been actualized, but even so, the values in Table 2, have not changed.

The benefits of architecture integration can be approached for example from the viewpoints of user satisfaction and system manageability. Engineers who use the tools prefer at least the amount of functionality they have had before, thus resisting any change which might hinder the usability of a software or system. Therefore companies keep using legacy systems or customize the new software implemented drastically. From the other viewpoint, the amount of different subsystems and tools can lead to a very difficult to manage architecture with several interoperability functions and integrations between every system.

Legacy architecture is found to be the most common type used among the case companies. Single source bundles and the middleware needed in a service-oriented architecture are difficult to implement at present. Nevertheless, a legacy architecture is not seen as an architecture worth developing further and therefore the scenarios of changing from a legacy architecture to either single source or SOA are most probable and realistic. Also a change from single source to SOA could be possible, if for example a company wants to expand its PLM architecture to the whole extended enterprise, in other words the subcontractors and other companies in the supply chain who use different PLM tools and systems.

5 Conclusions

The research subject, product lifecycle management, was discussed in the literature review part by presenting a four level PLM maturity model, which has been put together based on two models presented in literature. Each of the levels include a determination of the level of application of PLM, extent of the users and organizations involved in the PLM application, level of integration, level of interoperability and finally a summary of the situation as a whole.

As a part of the maturity model, two widely cited models of different architecture integration approaches were presented. Based on these two models, three dominant architecture types were discovered: legacy architecture, single source architecture and service-oriented architecture. Legacy architecture is clearly the most dominating architecture type, however most of the companies are planning to develop their PLM landscape towards either single source or SOA architecture.

An overall outlook of the current situation of PLM in a considerable sample of the largest Finnish manufacturing companies is presented in the result section of this paper. The material used in this research is based on six plus three case studies, corresponding to the amount of companies involved in two research projects. The case companies represent fairly typical examples of system architectures in the Finnish manufacturing industry. There are also some cases which do not share the same PLM strategies, for example when a company’s operations are based on project business rather than standard or configurable products. This follow-up study also indicates that the results of the original study are still valid. Furthermore the re-evaluation of one case company shows that the progression of PLM culture is rather slow. There have been no major steps forward during four years.

There would be plenty of room for further research in PLM architecture and its relation to system and tool usage. The usage could be monitored more closely for example by researching how much time and resources could be saved when switching from manual data transfer between systems to automatic data exchange. Other potential areas for future research which have been discussed during the benchmarking site visits in the research projects are the importance of information quality, how to improve reuse of information and how to improve data search functions.