Keywords

1 Introduction

The common aim of PLM adoption is to integrate people, processes, data, information and knowledge throughout the product’s lifecycle, within a company and between companies. PLM includes very extensive changes in intra- and inter-organizational practices, and requires new types of skills and capabilities, and moreover, large cultural and strategic changes.

Due to the magnitude of required transformations and coordination, a timely and well-coordinated PLM implementation can be very challenging, and companies often face difficulties when adopting it (e.g. [1]). Failures and long implementation times are often a result of the technology driven approach: PLM implementations are often led by IT investments, and other important management areas (e.g. company strategies, business processes, or employee skills) are either lagging behind or are not properly aligned with IT.

One important rather recent solution for the above types of problems are various types of maturity–related approaches. There has been a growing attention to research to PLM implementation, adoption and maturity- related issues, as demonstrated by the increasing number of papers in maturity issues in the field of PLM. However, thinking of the broad definition of PLM maturity, as well as PLM adoption and implementation issues, there are a number of different types of current approaches which can be thought to fall under the concept of PLM maturity. The aim of this paper is to investigate the maturity paradigm with regard to PLM domain specificities and discuss appropriate approaches to tackle PLM maturity in a systematic manner.

Several papers have studied PLM maturity and related approaches (e.g. [1–5]) but very few have tried to systematically interrelate and compare conceptually the different existing PLM maturity- related approaches, except for Vezzetti et al. [5] and Stenzel et al. [6]. Both of the articles focus on the benchmarking of existing models on a high level of abstraction, for instance to allow for the selection of an appropriate model from the existing PLM- related models at large, as well as creating a generic benchmarking framework for PLM maturity approaches. They do not, however, go into a more detailed comparison and the in-depth analyses of the basic foundations and the presumptions of the models, for instance their basic presumptions of what PLM and PLM maturity really are. The current studies have not, in a broader sense, identified, compared and categorized the various different types of existing approaches of PLM maturity, and have not been able yet to analyze in more detail their most suitable use domains (e.g. industry types, or other use domains). PLM maturity research is currently fragmented, and should be made comparable from the larger PLM maturity perspective.

In maturity model building, defining the scope and the focus (specific/generic), as well as the more detailed intended domains of use of maturity approaches is important [7, 8]. PLM maturity approaches’ domain specificity and the related presumptions have not been researched in detail. These have not always been brought clearly up-front in studies, but these may have a large influence on the applicability and usefulness of maturity models. In recent studies of Vezzetti et al. [5] and Stenzel et al. [6], this need has been noted, however. We will therefore aim to focus on the analyses of these factors, and if necessary, try to interpret the models’ implicit aims and presumptions.

In this paper, therefore, not only CMM/CMMI–based maturity approaches will be considered, but also other types of approaches addressing PLM maturity assessment and development problems.

Then, the main research questions addressing the current research gap are:

  1. 1.

    Broadly speaking, what does “PLM maturity” concept mean, how has it been defined, and what aims does PLM maturity strive for?

  2. 2.

    What do we know about the PLM maturity concept and approaches and their underlying foundational assumptions? What important differences are there in the existing maturity approaches, and how do they impact the potential domains of use of the models?

2 Defining PLM Maturity

2.1 Defining Maturity and PLM Maturity

In general, “maturity” can be defined as “the state of being complete, perfect or ready” [9]. Maturity thus implies an evolutionary progress in the demonstration of a specific ability or in the accomplishment of a target from an initial to a desired or normally occurring end stage [7]. Very broadly and briefly, “PLM maturity” can be seen to refer to the concept of how far an organization is in its implementation of PLM, and how much it still has to go to its targets in PLM implementation or “full PLM”. PLM maturity can refer for instance to the maturity of PLM processes, objects (such as ICT systems, documents, data structures), and people (e.g. skills, roles, responsibilities) (e.g. [1, 5]). PLM Maturity can be defined more specifically for instance as “the ability to manage the knowledge and capabilities of an organization to respond effectively to specific customer needs, at any point in time” [14].

In order to meet the new requirements of innovative products, the PLM systems should be improved to satisfy the new demands including faster and more convenient information interaction, better information sharing, capability to detect the successful features of new products, etc. More and more current PLM IT systems cannot fulfill the needs of different companies, and yet, no perfect approaches have been proposed to appropriately detect the drawbacks and the benefits of PLM in companies. In order to help the company to select the optimum PLM and understand the AS-IS and TO-BE situations, the PLM maturity approaches should be continuously studied to consider the strengths, weaknesses and limitations of PLM maturity and maturity approaches, and improve them accordingly. In addition, the range and the conception of PLM maturity should be changed with the increasing of smart products. In practice, new PLM maturity approaches should be, for instance, easier-to use, reduce the evaluation efforts, and capable to reflect the correct maturity levels [10].

Instead of viewing PLM maturity merely from the perspective of IT and business alignment perspective (e.g. [1]) or the technology adoption and staged capability improvement perspective, PLM maturity assessment can be seen more from a measurement perspective. When aiming to measure something, such as PLM maturity, and aiming to build a consistent maturity model for PLM maturity assessment, several things should be defined and aligned according to the maturity measurement objectives (see Fig. 1 below). According to Mettler [11], it is very important to have a good understanding of what is meant by “maturity” when designing (or using) a maturity model approaches: for instance, having a process-focused understanding of maturity implies to focusing on activities and work practices for designing more effective procedures, while again, when the concept of maturity is focused to people’s skills and proficiency, the emphasis of the model lies more on the softer capabilities (e.g. people’s behaviour). By the clarification of the maturity concept, the goal function of the model (i.e. the way how maturity is facilitated) is influenced, and thus, the goal function being clear, the nature of the design process has to be determined in order to derive the maturity levels, the metrics, and the corresponding maturity improvement recommendations.

Fig. 1.
figure 1

Aligning the PLM objectives and PLM maturity objectives

Full size image

PLM and its objectives should be defined explicitly enough, preferably in a measurable way, in a manner that they help also the useful definition of PLM maturity and its measurable objectives. Finally, the whole structure of the model, including PLM maturity dimensions and individual maturity questions, should ideally serve strictly and solely the purpose of well-defined measurable PLM objectives.

2.2 PLM from Maturity Perspective

First, PLM is often seen essentially as PLM software (either essentially a single PLM solution, or a large group of different types of solutions, such as PDM, CRM, ERP, excel sheets, various collaboration tools etc.), and thus, PLM maturity approaches may for instance attempt to align the implementation of IT/PLM software with company’s business goals. Commonly, however, PLM is seen as a larger PLM concept which involves e.g. people, processes and technological solutions. It is thus important to define and understand which of these are emphasized in PLM maturity approaches. (e.g. [1, 12])

Second, PLM is quite seminally about data, information and knowledge, and about getting these properly to serve a company’s business and product development (e.g. [13, 14]). One important difference between these is that while data and information can be managed and shared in a rather straight-forward manner, using e.g. traditional PDM and CRM systems, the management and transfer of knowledge can be enabled and supported but not essentially easily managed. PLM knowledge is partly explicit knowledge, recorded for instance in documents. Other PLM knowledge relates to the concept of tacit knowledge, present in people and derived from their experiences, but often hard to explicate verbally or in writing. Current PDM techniques, for instance, are still most suitable for managing explicit knowledge [14].

Third, PLM can be seen from functional or organizational viewpoints, but in many industries, product lifecycle management is essentially about the concept of extended enterprise and networks of companies, which have different roles in a product’s lifecycle and the management of products’ lifecycle information. These emphases have also important implication for PLM maturity approaches and their use.

Furthermore, depending on the overall business goals and strategy of a company, as well as the type of business (e.g. project-based customer-oriented investment products versus mass produced and mass-customized), PLM objectives can be very different, either emphasizing strongly the efficiency of processes or the high satisfaction and service-level of customers). This should be taken into consideration in PLM maturity approaches, as well.

3 Maturity Approaches in PLM

To identify the most common different types of PLM-related maturity approaches, we started off with the two recently published PLM maturity model benchmarking studies, Vezzetti et al. [5], and Stenzel et al. [6]. These are to our knowledge, and according to the carried out literature research, the only existing studies that have carried out an academic research to identify the existing maturity approaches for PLM, and to compare and benchmark them, as well as to create frameworks for the higher-level comparison of PLM maturity models.

Vezzetti et al. [5] identified and compared six approaches [1, 12, 14–17], while Stenzel et al. [6] recognized and evaluated ten approaches [1, 10, 14, 15, 18–22]. Three doubles were omitted. Due to the fact that we wanted to identify and compare, in essence, approaches that were directly PLM- related, we had to leave out Kulkarni et al. [20], which is a quite generic knowledge management capability maturity model, and CMMI-DEV [21] (a generic capability maturity model) and CM3 [22] (configuration management maturity model; see e.g. Niknam et al. [23]). In addition, since, we wanted to compare different types of models, we left out Zhang et al. [10], which was by its basis rather similar to Savino et al. [18] model. Furthermore, due to accessibility and language reasons, Frigerio et al. [17], unfortunately had to be left out, as well. This produced 8 different types of PLM maturity- related approaches.

Table 1. PLM maturity approaches analyzed in the study
Full size table

After making an additional literature search to verify potential missing models, we were able to identify two additional PLM- related models, Sharma [24] and Stark [25]. Stark [25] model was essentially rather similar to Stark [16], but the newer model was more oriented to PLM instead of PDM, and was also otherwise updated. Thus, the older was omitted, this leaving us with one added model. Taking into consideration that PLMIG proposes two different approaches for maturity evaluation, the other one being more process-oriented and the other activity-oriented, this leaves us with altogether 9 models for our comparison and analyses:

4 Analysis and Comparison of Current PLM Approaches

Two experienced PLM maturity researchers with background also in the development and testing of current PLM maturity approaches analyzed separately the different identified maturity approaches. In case of differences in evaluations, the differences were discussed, and on the basis of the consensus derived from the discussions, the final evaluations were described.

On the basis of more generic comparison of identified different types of PLM approaches (see Table 2 in Appendix), the papers reporting the approaches did not clearly identify any specific domains or limitations of use for the approaches. This would let us presume that the approaches are quite generic and can be used widely in different companies implementing PLM for their business. The approaches were in general designed, not very surprisingly, for mainly companies in the manufacturing industry. However, through a more close analysis, we were able to recognize some important differences with the approaches and their most suitable use domains. The explicated purposes of the maturity approach use were also described at a rather large level of abstraction. Mostly, the papers broadly stated that the models were to identify the as-is and to-be situations of PLM, even if some studies, such as Batenburg et al. [1], for instance, mentioned the purpose to be also to the alignment of business and PLM (IT) systems, Savino et al. [18] to identify right PLM system and tools for companies, or Sharma [24] to enable the adoption of collaborative product innovation in PLM.

Explicated PLM objectives were in many cases explicated at least somewhat in measurable terms, but in most cases, the PLM objectives were not directly and explicitly linked to the development of the model or approach content, so we cannot be sure whether the objectives were really used in the model design. Furthermore, the explicated PLM maturity objectives were, somewhat surprisingly, expresses in rather abstract terms, but we also tried to interpret the objectives from e.g. the higher level maturity descriptions. Many of the models were dealing with PLM maturity mostly from functional and/or organizational levels, but surprisingly few analysed PLM maturity taking the extended enterprise concept into consideration. We will later analyse this organizational focus in more detail. The more detailed objectives included e.g. PLM process standardization and optimization, or faster and better response to customer needs.

Finally, we analyzed the approaches and the related papers for their special viewpoints to PLM maturity, finding a variety of different types of approaches to PLM maturity, despite the approaches mostly having not identified any specific use domains or use purposes. For instance, some maturity approaches considered the process automation and optimization to be the goal of the highest maturity levels (e.g. approaches 1 and 6), while others emphasized on high maturity levels significantly the ability of companies to connect to customers and partners and their processes on need-basis and in an ad-hoc manner, making use of web-based approaches (e.g. model 4). These reflect very probably different presumptions behind the ultimate goals of PLM, or the different types of business logics behind the maturity model design. We will analyse in more detail the above types of different emphases in the identified PLM maturity approaches.

On the basis of our analyses of identified and evaluated PLM maturity approaches, we found several significant differences between the studied maturity models. The most significant foundational differences were related especially to the organizational development foci of PLM maturity approaches (Fig. 2), the focus on data, information and knowledge (Fig. 3), and the different types of emphases on process automation vs. ad-hoc and need-based process integration (Fig. 4). These emphases are analysed in more detail in the next figures.

Fig. 2.
figure 2

Organizational development foci of studied PLM approach (1: Batenburg; 2: Schuh; 3: Saaksvuori; 4: Sharma; 5: Karkkainen; 6: PLMIG Structurebased; 7: PLMIG Activitybased; 8: Savino 9: Stark)

Full size image
Fig. 3.
figure 3

Data and information vs. knowledge foci of studied PLM approaches (1: Batenburg; 2: Schuh; 3: Saaksvuori; 4: Sharma; 5: Karkkainen; 6: PLMIG Structurebased; 7: PLMIG Activitybased; 8: Savino 9: Stark)

Full size image
Fig. 4.
figure 4

Process automation vs. ad-hoc process integration foci of studied PLM approaches (1: Batenburg; 2: Schuh; 3: Saaksvuori; 4: Sharma; 5: Karkkainen; 6: PLMIG Structurebased; 7: PLMIG Activitybased; 8: Savino 9: Stark)

Full size image

On the basis of our analyses (see Fig. 2), all the studied approaches, quite naturally, put most of their emphases on the organizational level of PLM development, and the maturity approaches seemed clearly to be mostly intended for the intra-enterprise development of PLM maturity. Most of the approaches also took into consideration and aimed to develop, at least on the lower levels of PLM maturity, the various company functions related to PLM. However, somewhat surprisingly, even if PLM is commonly understood to include the inter-organizational and extended enterprise aspect in the development of PLM, at least on the more mature levels of PLM, only few of the approaches took this important PLM aspect into a more in-depth consideration even on the higher levels of PLM maturity. Of the approaches that took the extended enterprise explicitly into consideration included, first, Batenburg’s approach (1), which evaluated and measured in all its five maturity dimensions the PLM maturity by the extent of PLM developmental issues from ad-hoc to functional, organizational and inter-organizational levels. On the basis of the maturity model structure and individual maturity questions, it seemed to emphasize more the supplier-side of inter-organizational integration.

Second, Sharma’s model (4) emphasized on higher levels of maturity clearly the inter-organizational collaboration (customers and partners), and the typical features of such collaboration that would be expected from high-maturity companies. Third, Karkkainen’s approach (5) emphasized the knowledge-oriented integration of the customer direction, which is important for instance for engineer-to-order companies, which are often based on the proper understanding of customers’ needs and the business, and the proper transfer of customer knowledge to product development. In the PLMIG’s approaches, the inter-organizational aspects seemed somewhat to be considered, but this was not very explicitly emphasized in the described models.

Considering the viewpoint of data, information and knowledge (see Fig. 3), we found that most of the maturity approaches emphasize strongly the management of data and information by more traditional types of PDM and other information systems. Several models were found to have data and information driven approach for PLM implementation with an aim to prepare the organisation, people and processes to adapt to the PLM Information Technology investment. Mature organizations were seen as such to be capable of automating the data and formation flows, throughout the organisation and even with partner organizations and customers. This approach also assumes that PLM software handles standard workflows and procedures as well as structured and mostly explicit information. Models 1, 2, 3 and 9 were most strongly focused on this IT aspect of PLM. This is understandable, because quite often the management of structured data and information is at the core of PDM systems, and a large part of manufacturing companies find problems in the lifecycle management of structured data.

However, for instance customer focused and project-based engineer-to-order companies find serious problems in their product lifecycle management in making use of unstructured and tacit forms of knowledge from both customers and their partners, in which traditional data systems are not at their best. The models with knowledge-orientation had a people driven approach, making emphasis on experience and knowledge of people, organisational learning, collaboration and integration within inter-organisational networks. The role of activity-based tacit knowledge, interaction and experience was seen as very important for the high PLM maturity of companies, and therefore PLM software architecture can be considered as a tool for interaction, knowledge processes (creation, sharing, retrieval, storage and reuse) and should be flexible and adaptive to new situations and products. The approaches 5, 6 and 7 are most strongly oriented into the knowledge management aspect – 6 and 7 have specifically differentiated the data and knowledge aspects in PLM by dedicating a separate management dimension for data and knowledge, and can be seen to consider both aspects relatively well. Approach 5 emphasises e.g. co-creation of knowledge and co-experimenting between customers and partners on higher levels from this perspective.

As seen from Fig. 4, a larger part of the maturity approaches emphasise higher levels of maturity to involve high levels of process standardization, automation and optimization, many of them (e.g. 3 and 6) basing their approach to the principles of CMM/CMMI, and e.g. 1 (basing additionally on COBIT approach principles) aiming rather strongly to the implementation of PLM software as central part of PLM maturity. Some of the others, such as 4, high levels of PLM maturity emphasize strongly the adaptive and flexible nature of the larger PLM concept (not only PLM IT) to integrate new partners, customers and their processes on need-basis to allow fast reaction to changes in markets and customers’ needs. In this respect, the models describe mostly what characteristics of PLM are broadly to be implemented, but they do not address in more detail how to do this, thus emphasizing the descriptive instead of normative PLM maturity viewpoint.

5 Discussion and Conclusions

On the basis of the PLM maturity approach analyses, it can be stated that in most of the cases, the seminal presumptions behind the PLM maturity approaches and their design have not been defined in detail, for instance: how they define the very central concept “PLM” and its objectives, or how, in accordance with the previous definitions, the concept of PLM maturity is defined, and what types of measurable benefits should be expected from increased levels of maturity – efficiency of processes, flexibility of market changes, or better responsiveness and even prediction of customers’ needs, and how the maturity investments are presumed to be paying off in a more quantitative manner. Most of the current maturity studies in the PLM domain contend to state that the purpose of their maturity approaches is to make the complex process of PLM adoption a more coordinated and stage-like.

The above differences have implications for instance to the selection of the most suitable maturity approaches for companies with different business logics and companies coming from very different types of industries. For instance, engineer-to-order- types of organizations might make use of models that are relatively knowledge-oriented and enable the fast, flexible and need-based integration of the customers and their knowledge to their own development processes, while companies that are mass-production- or mass-customization oriented, might benefit from the process standardization and automation-focused approaches. Companies should also, depending partly on their business and current maturity stage, take into consideration the extended enterprise viewpoint to PLM, and select suitable approaches accordingly. Companies that have merged with other companies might benefit from approaches, such as the Batenburg approach, which enable the more in-depth measurement and the benchmarking of the maturity levels, instead of approaches merely describing the typical maturity characteristics on each maturity level, to align the PLM maturity and related competences of their different business units.

This study carries some limitations and restrictions, because the authors have had to make some interpretations concerning e.g. the objectives, focal emphases and the limitations of the studied maturity approaches. The evaluations between the different researchers were generally, however, quite unanimous. It is also possible that some of the models have been further defined and refined in the case of e.g. the description of their foundational presumptions and use domains. However, such studies were not identified. However, broadly speaking, we can quite confidently draw the conclusion that the different maturity approaches carried significant differences in their background presumptions and goals towards PLM facilitation and focal domains of their use, even if the related studies did not generally bring these implicit or explicit presumptions forth.

Finally, the results of this study can be used by companies that want to facilitate their PLM implementation in a coordinated and systematic ways supported by the use of PLM maturity approaches. Also academically, this study provides avenues for further research of PLM maturity, and for the more systematic development of existing and new PLM maturity approaches, as well as for the testing of the benefits of current maturity approaches in line with their implicit maturity objectives.