# Tracking the Capture of Tacit Knowledge in Product Lifecycle Management Implementation

Daniela Oliveira, Mickaël Gardoni, Kimiz Dalkir

► To cite this version:

Daniela Oliveira, Mickaël Gardoni, Kimiz Dalkir. Tracking the Capture of Tacit Knowledge in Product Lifecycle Management Implementation. 16th IFIP International Conference on Product Lifecycle Management (PLM), Jul 2019, Moscow, Russia. pp.146-155, 10.1007/978-3-030-42250-9_14. hal-04444752

HAL Id: hal-04444752

https://inria.hal.science/hal-04444752v1

Submitted on 7 Feb 2024

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>
<figure><img src="image_2.png" /></figure>

ifip

International Federation for Information Processing

This document is the original author manuscript of a paper submitted to an IFIP
conference proceedings or other IFIP publication by Springer Nature. As such, there
may be some differences in the official published version of the paper. Such
differences, if any, are usually due to reformatting during preparation for publication or
minor corrections made by the author(s) during final proofreading of the publication
manuscript.
Tracking the Capture of Tacit Knowledge in Product Lifecycle Management Implementation

Daniela Oliveira¹[0000-0001-9285-0173], Mickael Gardoni¹ and Kimiz Dalkir²[0000-0003-3120-6127]

¹ École de Technologie Supérieure, Montreal, QC H3C 1K3, Canada

² School of Information Studies – McGill University, Montreal, QC H3A 1X1, Canada
daniela.innovation.oliveira@gmail.com

**Abstract.** This study outlines the importance of tacit knowledge for engineering organizations, specially engineer-to-order organizations, and its impact in Product Lifecycle Management (PLM) implementations. The use of maturity models as roadmaps and its functions in PLM and knowledge management (KM) are explored. Difficulties of managing knowledge to prepare an organization for PLM implementation, and how PLM maturity models lack the granularity to support KM for PLM implementations are also explored. To support KM for PLM implementations, a tacit knowledge codification scale is developed from KM and PLM maturity models. The scale intends to help knowledge managers better prepare the organization for a PLM implementation and better support the implementation effort.

**Keywords:** Tacit knowledge codification, Explicit knowledge, Product Lifecycle Management, Knowledge Management, Maturity models, Content Analysis

# 1 Introduction

A lot of knowledge in an organization resides in people's heads and nowhere else. How does this knowledge relate to Product Lifecycle Management (PLM) initiatives and how to measure its integration in those initiatives?

When knowledge is codified, written, explained, be it in policies, procedures, detailed estimates, patents or any other kind of document, it can be said to be “explicit”. Explicit knowledge is visible, can be regrouped and analyzed without interaction with the people who hold that knowledge. There is however a great amount of knowledge that has never gone through the codification process. It is, for instance, the knowledge of which policies apply in a specific case, which procedures interact in a process, what is the consequence of including an information in a detailed estimate and so on. This kind of knowledge is recognized by the term “tacit knowledge”, which covers all knowledge that is not codified. Tacit knowledge may have never been articulated, discussed or exposed to management. It is, however, the kind of knowledge that helps
organizations build success in new projects and deal with uncertainty. Tacit knowledge is built through diversified experience, interaction with other knowers, observation, on-the-job training, mentorship, and other activities with high level of interaction between participants. Tacit knowledge is the power behind situations where engineers make recommendations that would apparently go against standards but that effectively solve a problem with no further repercussions. Another example is where an activity is theoretically dependent on a piece of equipment, but engineers know that the task can be completed without it just fine. It is the knowledge that empowers the worker to do the right thing even when conditions are not optimal. This kind of knowledge is less visible because it resides in people's minds and, as such, cannot be exposed without interaction with the people who hold it. Tacit knowledge may be less visible but is still the doorway for the application of the organizational knowledge to the operational environment [17].

The success of an organization in creating, producing, commercializing and supporting the sales of a given product at any point in time depends on how it employs the knowledge it holds. If there are no policies or procedures, all the knowledge involved is tacit. Codified tacit knowledge, or explicit knowledge, enables department integration, data production and software implementation and, therefore, allows for PLM implementation. Explicit knowledge also reduces the risk of knowledge loss. Many initiatives in knowledge management focus on codifying tacit knowledge, or, in other words, creating documents or systems out of tacit knowledge, in order to attain these advantages. However, the process is rather costly.

Tacit knowledge, on the other hand, enables flexibility, out-of-the-box thinking and innovation. These elements are especially important for engineer-to-order organizations. Engineer-to-order organizations are defined by Schönsleben [15] as industries where “at least some design or engineering work occurs during delivery lead time, according to customer specifications” (p. V). In engineer-to-order organizations, knowledge workers must adapt their interventions to the order requirements. Implementing PLM in engineer-to-order organizations is particularly difficult [9] because of the importance of tacit knowledge in those organizations.

The need to understand the impact of tacit knowledge in PLM implementations is twofold: Firstly, to maximize the use of resources by prioritizing codification initiatives where it would have the most impact. Secondly, to codify tacit knowledge to the optimal extent – the point where an acceptable compromise is reached between standardization and flexibility. In this study, maturity models in knowledge management (KM) and in PLM were analyzed to identify stages of tacit knowledge codification. A scale of tacit knowledge codification is then proposed.

## 2 Overview of Literature

Organizations place high expectations on PLM implementation [20]. One of the objectives of PLM is to centralize the product knowledge residing in individuals of the organization [14]. However, the management of knowledge, especially its tacit dimension, has been noticeably left out of PLM [8]. To verify this statement, we performed a bibliometric analysis of the field in Scopus, a major bibliographic database indexing
journal articles, books and conference proceedings, among other kinds of documents. 2163 documents were retrieved with the query "product lifecycle management" applied in title, abstracts and keywords fields or in any of them [5]. Of this body of published literature, little more than a quarter (25.16%) also mentioned the term "knowledge". Only a little less than 7% (6.85%) of the articles mentioned "tacit knowledge", "know-how" or "experience" [3], terms that would suggest some reflection on the knowledge employed by workers in the accomplishment of their tasks. The term "tacit knowledge" itself, largely established in the knowledge management (KM) field, accounts for little more than 0% (0.32%, or seven documents) of the works on PLM [4].

Stark [18] defines Product lifecycle management (PLM) as “the business activity of managing, in the most effective way, a company’s products all the way across their lifecycles; from the very first idea for a product all the way through until it is retired and disposed of” (p. 1). The need to improve the capability to manage products, according to Kale [7], comes from the traditional department-oriented paradigm, where demand is detected by marketing, the product is designed by engineering, produced by manufacturing and supported by sales. Potential benefits of applying PLM include faster and less faulty distribution of change information, the anchoring of products to its related certificates, records and test results, and easier diffusion and maintenance of standards [14] (p. 96). The common aim of adopting PLM is “to integrate people, processes, data, information and knowledge throughout the product’s lifecycle, within a company and between companies” [10] (p. 97). In knowledge terms, PLM has been defined as “the ability to manage the knowledge and capabilities of an organization to respond effectively to specific customer needs, at any point in time” [7].

PLM affects a wide range of processes inside and outside the company, often involves changes to existing business processes and working practices [1], in addition to requiring new types of skills and capabilities, not to mention large-scale cultural and strategic changes [10]. A certain level of collaboration between departments within and organization and perhaps among organizations is then sought. In fact, many problems with implementation of PLM Support Systems have been considered “more of organizational nature rather than technical” [1] (p. 335) as PLM impacts working processes and activities, which includes people’s roles, responsibilities and authorities [20]. PLM impacts and is impacted by the knowledge surrounding the lifecycle of a product.

To assess the readiness for PLM implementation and increase its chances of success, maturity models have been developed. The term "maturity" combines notions of evolution with levels of process formality. Maturity models provide the good and bad practices across transitional stages, intended to be used as a part of an improvement process [6]. Most maturity models are adapted from the Capability maturity model (CMM), developed by Paulk [13]. Initially defined to determine the readiness of an organization to adopt a given piece of software, maturity levels are well-defined evolutionary steps on the path to a clear goal [19].

PLM implementations depend on a certain level of codification of tacit knowledge, which might have not yet been attained by the organization. In addition, a balance has to be achieved in the codification of tacit knowledge to maintain the flexibility knowledge workers require to do well in their jobs.
In order to articulate tacit knowledge codification with PLM implementations, we performed content analysis on a KM and PLM maturity models to obtain a gradient of tacit knowledge codification and better inform knowledge management initiatives in PLM implementations.

# 3 Methodology

In order to analyze tacit knowledge codification states, a KM and a PLM maturity model were selected.

Dalkir [2] accounts for the existence of about twelve knowledge management maturity models. To allow for mapping to the PLM maturity model, the knowledge management maturity model should present descriptions of initiatives and / or outcomes in each level that are rich enough to associate them with the corresponding PLM maturity model initiatives and / or outcomes. Among the twelve knowledge management maturity models presented by Dalkir [2], the Kochikar [12] model was selected because of the richness of details presented for each level.

The Kochikar [12] maturity model has five incrementally complex phases. In phase one, Default, the organization is completely dependent on individual skills and abilities; in phase two, Reactive, the organization is capable of performing the basic business tasks repeatedly; in phase three, Aware, the organization is somewhat capable of supporting decision-making with data; in phase four, Convinced, there is quantitative decision making for strategic and operational; in phase five, Sharing, the organization is able to manage organizational competence.

The Kochikar model intends to reflect an organization's intention and ability to manage knowledge. Intentional codification of tacit knowledge is a part of knowledge management. Phase one, Default, suggests no intentional codification of tacit knowledge is attempted, resulting in the organizational dependence on individuals' skills and abilities. Tacit knowledge is produced individually only. In this phase, basic business activities are at risk when an individual leaves the organization. To reduce this risk, two complementary knowledge management solutions can be applied: (1) sharing tacit knowledge through job shadowing, on-the-job training and mentoring, for example, and (2) codifying tacit knowledge, through the creation of documents enumerating position and department responsibilities, procedures and policies. This reduction of knowledge loss, joined by the organizational ability to repeat basic business tasks through personnel movement, is represented by phase two of the maturity model, Reactive. The third phase, Aware, denotes a greater degree of tacit knowledge codification, as the coverage of data produced is enough to support decision-making. Indeed, tracking a task implies the acknowledgement that the task exists. The appreciation of the value of that task implies knowledge of the process the task belongs to. The two subsequent levels imply greater levels of conjoined work between departments in an organization. At these levels, departments are not only aware of the work in other departments, but they are able to collaborate and adapt to new business realities or new product requirements demanding collaboration between departments. Tacit knowledge is produced jointly.
On the PLM side, Kärkkäinen and Silventoinen [9] identified nine maturity models specifically conceived for PLM. As organizations have different PLM needs, the authors analyzed the focus of these maturity models along three dimensions: (1) from Functional, Organizational to Inter-organizational; (2) from Data / Information to Knowledge / People and (3) from Process automation to Ad-hoc process integration. Engineer-to-order organizations need more flexibility in adapting tasks to the product requirements at hand, meaning they need a strong Ad-hoc process integration. Of the nine PLM maturity models analyzed by Kärkkäinen and Silventoinen [9], the Sharma [16] model had the strongest ad-hoc process integration. In addition to that, it allowed for a balanced description of needs in the Data / Information to Knowledge / People spectrum. Still according to Kärkkäinen and Silventoinen [9], the Sharma [16] model also focuses on process automation.

The Sharma model was conceived to facilitate collaboration among organizations, product development and innovation and has six phases: The first phase, Manual/Ad hoc, is paper-based; in the second phase, Standardization, there is some integration; in the third phase, Visibility, there is a cross-platform visibility; in the fourth phase, Business Activity Reinvention, there is intra-organization integration; in the fifth phase, Real time track and trace, there is flexible inter-organization application integration; in phase six, Collective optimization, there is need-based inter- and intra- organization event and business process integration [16].

In terms of knowledge, at the base of the Sharma model, there is ad hoc integration due to kinships and other cultural reasons, with no intentional knowledge management. In the second level, integration between departments assumes formalization of procedures or, in other words, some tacit knowledge codification. The third level evokes the possibility of a department understanding the work involved in the inputs it receives and in the outputs it produces, denoting an understanding of roles, responsibilities and tasks of each department. The fourth level represents the possibility of a department to influence the course of production depending on specific and/or business requirements. Here, a certain degree of collaboration is implied, indicating the creation of tacit knowledge involves more than one department. Subsequent levels indicate an increasing number of departments, inside and outside of the organization, sharing the fourth level state. In other words, more and more departments share the same understanding – the same knowledge - about departments' tasks and impact in the product lifecycle. As departments work more closely together, the tacit knowledge produced becomes more collectively produced and used by more and more departments.

Table 1 summarizes both maturity models levels regarding tacit knowledge.

<table><caption>**Table 1.** Tacit knowledge codification and production in KM and PLM maturity models</caption><thead><tr><td>Level</td><td>KM maturity model (Kochikar)</td><td>PLM maturity model (Sharma)</td></tr></thead><tbody><tr><td>1</td><td>No tacit knowledge codification supported by organization</td><td>No tacit knowledge codification supported by organization</td></tr><tr><td>2</td><td>Some tacit knowledge codification; Tacit knowledge sharing</td><td>Some tacit knowledge codification</td></tr></tbody></table>
<table><tr><td>3</td><td>Tacit knowledge codification at the process level</td><td>Tacit knowledge codification at the process level; Tacit knowledge sharing</td></tr><tr><td>4</td><td>Conjoined production of tacit knowledge</td><td>collective production of tacit knowledge</td></tr><tr><td>5</td><td>Greater, conjoined production of tacit knowledge</td><td>Greater, collective production of tacit knowledge</td></tr><tr><td>6</td><td>-</td><td>Greater, collective production of tacit knowledge by greater number of departments</td></tr></table>

## 4 Results

In both KM and PLM maturity models, tacit knowledge codification precedes the sharing and collective production of tacit knowledge. This finding suggests that efforts for codification of tacit knowledge are necessary to foster the collective production of tacit knowledge. Tacit knowledge is first produced individually, then codified, and therefore shared, by department, then an understanding of the positioning of the department in the product lifecycle takes place, before the production of tacit knowledge can be undertaken by two or more departments together. The aim of PLM is to level all departments touching a product lifecycle to a stage where they can produce tacit knowledge together. Joint production of tacit knowledge, however, demands a shared context and some closeness between teams.

Evaluation of levels of tacit knowledge codification, sharing or collective production seems possible at the department level and presents a good indicator of the readiness of two or more departments to implement a PLM initiative.

The collective production of tacit knowledge implies the shared understanding of two or more departments regarding their positioning in the product lifecycle and how one department's work influences the other. However, departments might not have the same level of understanding. Departments might develop their understanding of the impact of another department over their work before understanding their own impact on another department.

This beginning of understanding seems to be a necessary stage before the implementation of PLM, in order to avoid the organizational issues mentioned by Batenburg [1].

Based on these findings, we suggest a scale of tacit knowledge codification in Table 2.

<table><caption>**Table 2.** Tacit Knowledge Codification Scale</caption><thead><tr><td>Level</td><td>Definition</td><td>Codified tacit knowledge</td></tr></thead><tbody><tr><td>Uncharted</td><td>Tacit knowledge resides only in individuals</td><td>Workers' <i>Curricula vitae</i> and personal notes</td></tr><tr><td>Interrelated</td><td>Tacit knowledge relations between departments have been identified and codified</td><td>Workflows; Fishbone diagrams[11] representing the product lifecycle; Data maps and dictionaries</td></tr></tbody></table>
<table><thead><tr><th></th><th></th><th></th></tr></thead><tbody><tr><td>Aware</td><td>Departments are aware of factors influencing work before their intervention and afterwards; Department production of tacit knowledge considers other departments</td><td>Requests for task changes in other departments; Communication of special circumstances concerning sub products to other departments; Comments regarding other departments in interdepartmental meeting minutes</td></tr><tr><td>Joined</td><td>Departments work together to find some solutions; tacit knowledge is produced jointly</td><td>Sub products produced by two or more departments</td></tr><tr><td>Appropriated</td><td>Departments have a history of working together to find solutions; tacit knowledge is produced collectively</td><td>Complex sub products produced by two or more departments</td></tr></tbody></table>

## 5 Application

To illustrate the application of the Tacit Knowledge Codification Scale, we present a case involving a regional branch of an organization charged with the maintenance of road infrastructure.

The case concerns the Maintenance Planning department charged with planning major maintenance projects. The department needed information about the state of existing products in order to predict maintenance measures. The information would be submitted to an asset management system able to predict the degradation of road quality, allowing for accurate planning of maintenance measures. This information was obtained by on-site analysis, which is quite costly. A list of roughly ninety terms, each one representing one road composition formula, was used by the asset management system to create degradation scenarios. This list had been used in previous attempts to gather information from other departments, without success. With the mediation of an information professional, it came to light that this list assumed a great deal of knowledge of road composition, knowledge that seemed to be present only in the Maintenance Planning department. Indeed, after realizing that the list could be decomposed into combinations of materials, quantities and order of application, the information professional met with members of the Maintenance Planning team to discuss how to simplify the list using more widely known terms.

Apart from the manager, other three members took part in the Maintenance Planning team. One of the members had more than ten years of experience, another had roughly four years of experience in the department and the last one had just recently joined the team. The junior member indicated their lack of knowledge to help with the decomposition of terms. The mid-career member was able to decompose about seventy percent of the terms. The rest of the terms had to be decomposed with the help of the senior member of the team. The document with the matrix connecting the original list terms and a combination of entries of the second list – called road layers list – placed the tacit knowledge of Planning regarding road composition in the Identified level of the Tacit Knowledge Codification Scale (Table 2). The complexity of the knowledge involved in road degradation analysis was keeping other departments from collaborating with
Planning. The codification effort vulgarized road composition terms into terms that other departments could understand and relate information to. The document with the matrix also served as an indicator of the tacit knowledge regarding road composition concentration in the Maintenance Planning department.

In their quest to obtain road composition information, the Maintenance Planning de-
partment mapped where the information was present. It could be found in different or-
ganizational systems. In those systems, however, data was regrouped according to a
particular logic model and were available only a certain delay after construction. They
did not represent a solution for the Maintenance Planning department. At this point,
Maintenance Planning turned to departments closer to the conception of the product.
Because these departments intervened earlier in the product lifecycle of the product,
they were also closer to the production of the needed information.

Indeed, the data was first submitted to different systems by the Project Management department. The Project Management department was however not the producer of the data. The data was produced by external contractors and were provided to comply with invoice payment requirements, which explained the particular logic used to regroup the data. Maintenance Planning had acquired the understanding of the information flow in the Project Management department, along with the challenges of obtaining this information. Maintenance Planning understood why information was managed the way it was in the Project Management department and also the correlation between that information management and their own work. Interdepartmental meeting minutes and a diagram would be evidence of the Interrelated phase of the scale.

After this first contact, Maintenance Planning sought Project Management collabo-
ration to envision a way to obtain the information needed. Maintenance Planning used
the recently gained knowledge about how Project Management operated to produce a
form for data collection. The form was submitted to Project Management to request its
use by external contractors. The form was an evidence that Maintenance Planning had
reached the Aware stage in relation to Project Management regarding road composition
data.

The logic used to regroup data in the form and the form itself, as a tool, turned out
to be potentially convenient for Project Management for some of their own information
needs. For this reason, Project Management sought collaboration with Maintenance
Planning to include more data to be gathered in the form. The resulting form was only
possible because of the collaboration of both departments and would be an evidence of
the Joined level. The collaboration of the two departments was maybe still not a solid,
long-term one, but already a break from the work-in-silo paradigm. This collaboration
would indicate a greater readiness for a PLM initiative regarding road composition.

6 Discussion and Conclusions

As illustrated in the previous section, the application of the Tacit Knowledge Codifica-
tion Scale may show evidence of shared tacit knowledge and collaboration between
departments. The existence of shared tacit knowledge and collaboration between de-
partments is a good indicator of a PLM implementation with less organizational issues.
The scale does not replace maturity level assessments but may be an additional tool to assess readiness for PLM implementation. PLM implementation may prove difficult if departments do not understand the relationship between their work, knowledge, information and data to those of other departments. In those cases, it might be more interesting and cost-effective to implement knowledge management initiatives and culturally break the work-in-silo paradigm before designing a PLM support system, for example.

Some questions regarding tacit knowledge integration still persist. For instance, when assessing the tacit knowledge codification general stage of two departments, how many documents would be needed to show evidence of a specific state? The answer to this question should consider specialization and complexity of the tasks involved, as well as turnover rates and availability of similarly talented workforce that can be hired. Another issue is the identification of documents providing proof of existing tacit knowledge or the joint production of tacit knowledge, for example. In organizations where a team responsible for knowledge management exists, those professionals can be charged with assessing the evidentiary value of documents produced. How can the assessment of this evidence be explained so that smaller organizations can also appreciate their tacit knowledge codification levels? An empirical validation of the theoretical exercise in this article would shed light on these topics and on characteristics of the documents used to assess tacit knowledge codifications. An empirical validation would pave the way for automation of the identification and analysis of these documents, possibly in large scale and should be the target of future research endeavors in this area.

## References

1. Batenburg, R. et al.: PLM roadmap: stepwise PLM implementation based on the concepts of maturity and alignment. International Journal of Product Lifecycle Management. 1, 4, 333–351 (2006). https://doi.org/10.1504/IJPLM.2006.011053.

2. Dalkir, K.: Knowledge management in theory and practice. The MIT Press, Cambridge, Massachusetts (2017).

3. Elsevier B.V.: [Scopus Results Analysis Report on "((TITLE-ABS-KEY ('product lifecycle management') AND TITLE-ABS-KEY (tacit W/2 knowledge) )) OR ((TITLE-ABS-KEY ('product lifecycle management') AND TITLE-ABS-KEY (experience) )) OR ((TITLE-ABS-KEY ('product lifecycle management') AND TITLE-ABS-KEY (know-how) ))" from 2004 to 2018].

4. Elsevier B.V.: [Scopus Results Analysis Report on "(TITLE-ABS-KEY ('product lifecycle management') AND TITLE-ABS-KEY (tacit W/2 knowledge) )" from 2008 to 2015].

5. Elsevier B.V.: [Scopus Results Analysis Report on "TITLE-ABS-KEY ('product lifecycle management')" from 1996 to 2019].

6. Fraser, P. et al.: The use of maturity models/grids as a tool in assessing product development capability. In: IEEE International Engineering Management Conference. pp. 244–249 vol.1 (2002). https://doi.org/10.1109/IEMC.2002.1038431.
7. Kale, V.: Enhancing enterprise intelligence: leveraging ERP, CRM, SCM, PLM, BPM, and BI. CRC Press, Taylor & Francis Group, Boca Raton (2016).

8. Kärkkäinen, H. et al.: Defining the Customer Dimension of PLM Maturity. In: Rivest, L. et al. (eds.) Product Lifecycle Management. Towards Knowledge-Rich Enterprises. pp. 623–634 Springer Berlin Heidelberg (2012).

9. Kärkkäinen, H., Silventoinen, A.: Different Approaches of the PLM Maturity Concept and Their Use Domains – Analysis of the State of the Art. In: Bouras, A. et al. (eds.) Product Lifecycle Management in the Era of Internet of Things. pp. 89–102 Springer International Publishing (2016).

10. Kärkkäinen, H., Silventoinen, A.: What is Product Lifecycle Management (PLM) Maturity? Analysis of Current PLM Maturity Models. The Journal of Modern Project Management. 3, 3, (2016).

11. Kenett, R.S.: Cause-and-Effect Diagrams. In: Encyclopedia of Statistics in Quality and Reliability. American Cancer Society (2008). https://doi.org/10.1002/9780470061572.eqr413.

12. Kochikar, V.P.: The knowledge management maturity model: a staged framework for leveraging knowledge. Proceedings of KM World. 1–9 (2000).

13. Paulk, M.C.: The capability maturity model: guidelines for improving the software process. Addison-Wesley Pub. Co., Reading, Mass. (1995).

14. Sääksvuori, A., Immonen, A.: Product lifecycle management. Springer, Berlin ; (2008).

15. Schönsleben, P.: Integral Logistics Management: Operations and Supply Chain Management Within and Across Companies. Taylor and Francis, London (2016).

16. Sharma, A.: Collaborative product innovation: integrating elements of CPI via PLM framework. Computer-Aided Design. 37, 13, 1425–1434 (2005). https://doi.org/10.1016/j.cad.2005.02.012.

17. Shoham, S., Hasgall, A.: Knowledge workers as fractals in a complex adaptive organization. Knowledge and Process Management. 12, 3, 225–236 (2005).

18. Stark, J.: Product Lifecycle Management. In: Stark, J. (ed.) Product Lifecycle Management (Volume 1): 21st Century Paradigm for Product Realisation. pp. 1–29 Springer International Publishing, Cham (2015). https://doi.org/10.1007/978-3-319-17440-2_1.

19. Weber, C.V. et al.: Key Practices of the Capability Maturity Model. Carnegie-Mellon Univ Pittsburgh; Pa Software Engineering Inst (1991).

20. Wognum, P.M., Kerssens-Van Drongelen, I.C.: Process and impact of product data management implementation. International Journal of Product Development. 2, 1–2, 5–23 (2005). https://doi.org/10.1504/IJPD.2005.006666.