# A Method to Identify Risks Associated with a PLM Solution

Mattias Bokinge, Christoffer Levandowski, Johan Malmqvist, Hans Johannesson

► To cite this version:

Mattias Bokinge, Christoffer Levandowski, Johan Malmqvist, Hans Johannesson. A Method to Identify Risks Associated with a PLM Solution. 9th International Conference on Product Lifecycle Management (PLM), Jul 2012, Montreal, QC, Canada. pp.512-524, 10.1007/978-3-642-35758-9_46. hal-01526155

HAL Id: hal-01526155

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

Submitted on 22 May 2017

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 Method to Identify Risks
Associated with a PLM Solution

Mattias Bokinge, Christoffer Levandowski, Johan Malmqvist, and Hans Johannesson

Department of Product and Production Development, Chalmers University of Technology,
Gothenburg, Sweden

{mattias.bokinge, christoffer.levandowski, johan.malmqvist,
hansj}@chalmers.se

**Abstract.** Not all investments in PLM (Product Lifecycle Management) are successful. Measuring the business effects of a PLM is essential, but can only be applied subsequent to solution deployment. It could be more powerful to make an early evaluation of the PLM solution, resulting in the business benefits, making corrections possible prior to deployment.

In this paper, a method to identify risks associated with a PLM solution is proposed based on an architecture model of a PLM solution and available PLM solution guidelines. Its use is demonstrated in an industry case and evaluated as compared to its intended use. The intention is that identified risks can help identify change proposals to the PLM solution or to obtain a better understanding of the consequences for solution deployment.

The findings indicate that the method is a useful support for identifying risks associated with a PLM solution. However, additional testing of the method in real settings is necessary to strengthen that indication.

**Keywords:** PLM Solution, PLM Implementation, PLM Architecture, and Guidelines.

## 1 Introduction

Product Lifecycle Management (PLM) is an information technology (IT) approach whose goal is a more effective and more efficient flow of product definition information through all phases of the product lifecycle. It is defined by John Stark as "...the activity of managing a company's products all the way across their lifecycles in the most efficient way" [1]. Software packages to support the concept of PLM include engineering applications (such as CAD, CAM and CAE) and Product Data Management (PDM) systems. The use of PLM solutions with virtual models, as well as databases containing information of products, enables organisations to develop products in shorter times, to lower costs and increase product quality. More efficient PLM solutions may also reduce the environmental load occurring in the development process (for example, in less CO2 emissions from travel to meetings and less material consumed to produce physical prototypes).
<figure><img src="image_2.png" /><figcaption>**Fig. 1.** Framing PLM implementation activities and a PLM solution artefact in the PLM solution lifecycle (Source: inspired by [2] and [3])</figcaption></figure>

PLM implementation is the activity of developing and deploying a PLM solution. The result from this activity, the PLM solution, is tentative prior to deployment and real subsequent to implementation. Chartering takes place prior to the activity of implementation. Chartering is where the business case is constructed, vendors and software are usually selected, and the budget is established [2]. Subsequent to implementation is the stabilization activity, where bugs are removed and employees become acquainted with the solution. The PLM solution may later go through a number of improvements until it is finally retired. The terminology is put in relation to the rest of the PLM lifecycle in Figure 1.

Successful investments in PLM are reported by several authors [4-6]. However, endeavours that are only partly successful are also common [7-8]. Hewett [9] argues that the value gained from investments made in PLM can and should be questioned. He also claims that many failures of PLM investments are due to mistakes in implementations. We agree with that statement and argue that one way of avoiding such failures would be to assess the PLM solution during implementation. Thus, the overall aim of this paper is to describe, demonstrate and evaluate the use of a method to identify risks associated with a PLM solution.

The paper is structured as follows: Section 2 contains a review of related work. The proposed method is then presented in Section 3, demonstrated in a case from industry in Section 4, and evaluated in relation to its intended use in Section 5. The research approach is discussed in Section 6, before the conclusions are drawn in Section 7.

## 2 Related Work

The benefits from PLM solutions can be evaluated by measuring the fulfilment of pre-specified success criteria. Alemanni et al. [4] propose such a method based on key performance indicators for two business processes. One example of their key performance indicators is an "average number of engineering change proposals". Since the method evaluates the effects of a PLM solution, it can only be used subsequent to implementation. As a result, it could potentially contribute to improvements after implementation. However, it would be constructive to be able to make improvements in a PLM solution during development.
A prerequisite for evaluating a PLM solution is a description of its elements. Zim-merman [10] presents a generic model of enterprise architecture based on contribu-tions from [11-12] and argues that the model can be applied to the PLM area. The model consists of several different layers: objectives (the topmost layer), strategy, processes, information, application, and infrastructure (the bottom layer). Each layer requires elements of the layer below and enables elements of the layer above. The elements of each layer may be described using informal techniques, such as natural language descriptions. Formalised techniques also exist for documenting different layers of the PLM architecture, but they require skills both for creating and interpret-ing the models, e.g. analysing how elements of the PLM architecture model are trace-able to other elements of the model. Ramesh and Jarke [13] use the term “satisfied traceability” to describe how one element satisfies another element. In this paper, we use the term traceability.

Analysing models of PLM solutions has not attracted much attention from the re-
search community. However, analysis could be based on guidelines for PLM solu-
tions, where a guideline can be defined as a directional recommendation for what to
do (or what not to do) in a specific context. Bokinge and Malmqvist [14] summarised
available PLM solution guidelines (among other PLM implementation guidelines)
from available articles (see Table 1) and evaluated the guidelines' relevance and ap-
plication in a case from industry. They found that most of the guidelines were highly
relevant in the case and suggested that PLM projects should review their plans with
the PLM guidelines in mind and including a plan for how to apply the guidelines.

<table><caption>**Table 1.** PLM solution guidelines, a subset of PLM implementation guidelines, summarised from articles (Source: modified from [14])</caption>
  <thead>
    <tr>
      <th>Guidelines category</th>
      <th># Guidelines</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td rowspan="7">Project process</td>
      <td>Divide project into sub-projects</td>
    </tr>
    <tr>
      <td>Perform a pilot project</td>
    </tr>
    <tr>
      <td>Conduct pre-study prior to system selection</td>
    </tr>
    <tr>
      <td>Improve processes prior to or simultaneously with PLM projects</td>
    </tr>
    <tr>
      <td>Plan carefully</td>
    </tr>
    <tr>
      <td>Follow-up and control project process</td>
    </tr>
    <tr>
      <td>Be prepared to adjust the plan when business changes</td>
    </tr>
    <tr>
      <td rowspan="8">PLM solution</td>
      <td>a Aim to satisfy rather than to optimise</td>
    </tr>
    <tr>
      <td>b Do not force the same solution on the whole organisation</td>
    </tr>
    <tr>
      <td>c Define benefits for all stakeholders</td>
    </tr>
    <tr>
      <td>d Establish coherent PLM architecture</td>
    </tr>
    <tr>
      <td>e Align processes with system capabilities</td>
    </tr>
    <tr>
      <td>f Only roll out tried software releases</td>
    </tr>
    <tr>
      <td>g Minimise customisation</td>
    </tr>
    <tr>
      <td>Ensure management support</td>
    </tr>
    <tr>
      <td rowspan="7">Organisation</td>
      <td>Caractery estimate the magnitude of change</td>
    </tr>
    <tr>
      <td>Involve users from all departments and disciplines</td>
    </tr>
    <tr>
      <td>Authorise the project participants</td>
    </tr>
    <tr>
      <td>Use expertise from third parties</td>
    </tr>
    <tr>
      <td>Educate system users</td>
    </tr>
  </tbody>
</table>

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

<table>
  <thead>
    <tr>
      <th>Guidelines Category</th>
      <th># Guidelines</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td rowspan="7">PLM solution</td>
      <td>a Aim to satisfy rather than to optimise</td>
    </tr>
    <tr>
      <td>b Do not force the same solution on the whole organisation</td>
    </tr>
    <tr>
      <td>c Define benefits for all stakeholders</td>
    </tr>
    <tr>
      <td>d Establish coherent PLM architecture</td>
    </tr>
    <tr>
      <td>e Align processes with system capabilities</td>
    </tr>
    <tr>
      <td>f Only roll out tried software releases</td>
    </tr>
    <tr>
      <td>g Minimise customisation</td>
    </tr>
  </tbody>
</table>
If a model of an organisation's PLM solution can be constructed, it should be possible to assess whether the elements of that model correlate positively or negatively with existing guidelines for PLM solutions. Thereby, it should be possible to identify risks associated with a PLM solution. The risks can, in turn, be used to generate a range of proposals. In this paper, we are building on the work presented in [10] and [14] to construct a method to identify risks with a PLM solution.

## 3 Proposal: A Method to Identify Risks Associated with a PLM Solution

Our proposed method (Figure 2) comprises five steps: (1) develop and document the PLM solution, leading to an architecture model of the PLM solution; (2) analyse the architecture model; (3) map correlations between elements of the architecture model and existing PLM solution guidelines, leading to a correlation matrix; (4) analyse the correlation matrix; and, (5) generate change proposals based on the identified risks.

<figure><img src="image_4.png" /><figcaption>Fig. 2. A method to identify risks associated with a PLM solution</figcaption></figure>
More specifically, we propose to:

1) Document the PLM solution in a layered PLM architecture model [10].

2) Analyse the PLM architecture model regarding its elements' coverage of the archi-
tectural layers, agreements and conflicts between elements, and the traceability be-
tween elements.

3) Map correlations between elements of the architecture model and PLM solution guidelines summarised by [14] in a correlation matrix. We propose to analyse correlations in terms of agreements (meaning an element contributes to fulfilling a certain guideline) or conflicts (meaning an element counteracts the fulfilment of a certain guideline).

4) Analyse the correlation matrix regarding the insufficient coverage of guidelines, the insufficient coverage of elements to assess correlations with guidelines, and conflicts between elements and between guidelines. This is done by pattern analysis, analysing rows and columns with few or no correlations, as well as rows and columns with both agreements and conflicts.

5) Generate change proposals for the PLM solution and clarify the implications for deployment.

4 Case Study

In this section, the method is demonstrated in a case from industry. Section 4.1 con-
tains a description of the research approach taken, followed by one section for each
step in the proposed method.

4.1 Research Approach

The proposed method was tested in a multinational manufacturing company hereafter called GlobalCorp. GlobalCorp has more than 150,000 employees and more than 200 manufacturing sites around the world. They consist of a myriad of acquired subsidiaries that all have different products, size, business models and culture. Historically, the idea at GlobalCorp has been that if each of the subsidiaries is profitable, GlobalCorp is profitable. However, GlobalCorp now wants to leverage on their size. Thus, they now develop a common PLM solution (based on commercial engineering applications and PDM systems) as well as a deployment plan, and deployments are on-going.

Semi-structured interviews and e-mail correspondence with six employees from GlobalCorp's PLM Centre of Excellence during the summer and fall of 2011 form the empirical base for the study. Four of the interviewees work at GlobalCorp's centralised PLM department. Two of the interviewees work at local PLM departments in two different subsidiaries that currently deploy the PLM solution. Also, in addition to the six employees who made the main data contribution to this study, eleven other employees were interviewed, providing context knowledge.

The interviews were between one and two hours long and were conducted by two interviewers. The interview guide covered questions regarding their organisation and history, their PLM centre of excellence, their PLM solution development, PLM solu-
tion deployment, and their PLM solution. In addition, archival records (such as GlobalCorp's defined information model and organisational charts) were reviewed during interviews. The interviews were recorded, transcribed and sent to the interviewees for validation.

The proposed method was demonstrated and evaluated in relation to the case. A PLM architecture model of GlobalCorp's PLM solution was constructed, correlations between its elements and the PLM solution guidelines were assessed, the architecture model and the correlation matrix were analysed, suggested proposals were generated, and the method was evaluated in comparison to its intended purpose. Last, all findings were presented to case representatives for validation, in both oral and written form.

## 4.2 Step 1: Architecture Model of GlobalCorp's PLM Solution

Identified elements of GlobalCorp's PLM solution are categorised in accordance with different layers of the PLM architecture model in Table 2.

## 4.3 Step 2: Analysis of the Architecture Model

Several observations can be made when analysing the architecture model, regarding the coverage of the different layers, the agreements and conflicts between elements, and the traceability between elements.

First, regarding coverage of the different layers of the architecture model, it can be observed that the model contains elements regarding all layers except for the infrastructure layer, which was not considered during interviews. It can also be observed that the strategy elements may be categorised either as high level strategy elements (S1-S3) or low level strategy elements (S4-S9). Also, high level processes are defined, as well as low level processes imposed by the engineering applications and PDM system. However, the connections between those two models are unclear.

Second, regarding agreements and conflicts between elements of the model, it can be observed that some of the identified elements suggest standardisation (S1; S6; S8; P1-P2; I1; I5; A1-A3), some allow differentiation (S2; I4; I6; A2-A3), some drive minimised customisation (S3; S4-S5; S7-S8; P2; I2), while some are of other character (O1-O2; S9; I3). The existence of elements driving standardisation as well as elements enabling differentiation can be questioned, due to their inherent conflict.

Last, traceability between elements of the model is depicted in Figure 3. Direct traceability can be identified between the high level strategy elements (S1-S3) with low level strategy elements (S4-S8) and most elements of the lower layers (P1-P2; I1-I2; I4-I6; A1-A3). Rather than indirect traceability (i.e., that application elements are traceable to information elements that are traceable to process elements, etc.), traceability is direct between elements of all lower layers and low level strategies to high level strategy elements. The implication is that the connection between low level strategies, processes, information and applications is unclear in the architecture model.
<table><caption>**Table 2.** PLM architecture model of GlobalCorp's PLM solution</caption><thead><tr><th>Layers</th><th>#</th><th>Elements</th></tr></thead><tbody><tr><td rowspan="2">Objectives</td><td>O1</td><td>Increase re-use of parts and designs</td></tr><tr><td>O2</td><td>Reduce costs of engineering applications and PDM systems</td></tr><tr><td rowspan="9">Strategies</td><td>S1</td><td>Standardise on software, information models, and processes</td></tr><tr><td>S2</td><td>Allow for some differentiation</td></tr><tr><td>S3</td><td>Minimise customisation</td></tr><tr><td>S4</td><td>Develop workarounds where the existing system support is insufficient</td></tr><tr><td>S5</td><td>Request enhancements from vendors where existing system support is insufficient</td></tr><tr><td>S6</td><td>Populate the PLM centre of excellence with representatives from the different divisions</td></tr><tr><td>S7</td><td>Populate the PLM centre of excellence with technical and business consultants</td></tr><tr><td>S8</td><td>Host a standard solution for small subsidiaries</td></tr><tr><td>S9</td><td>Continuously extend GlobalCorp's PLM standards to include more functional areas</td></tr><tr><td rowspan="2">Processes</td><td>P1</td><td>Use GlobalCorp's standard process for new product development</td></tr><tr><td>P2</td><td>Use standard PDM functionality according to the PDM system (for example, check-in)</td></tr><tr><td rowspan="6">Information</td><td>I1</td><td>Standardise objects and attributes between different subsidiaries</td></tr><tr><td>I2</td><td>Adapt objects and attributes to the information model in the selected PDM system</td></tr><tr><td>I3</td><td>Certify new releases of the selected PDM system against the standardised information model</td></tr><tr><td>I4</td><td>Modularise the information model for different functional areas in the PDM system</td></tr><tr><td>I5</td><td>Restrict existing objects and attributes of selected information model modules from being altered</td></tr><tr><td>I6</td><td>Enable that additional objects and attributes can be added</td></tr><tr><td rowspan="3">Applications</td><td>A1</td><td>Require that a specific PDM system be used</td></tr><tr><td>A2</td><td>Recommend the use of only one CAD application for 2D mechanical CAD, 3D mechanical CAD, and electrical CAD, respectively</td></tr><tr><td>A3</td><td>Recommend the use of CAD applications from the same vendor the selected PDM system has</td></tr><tr><td>Infrastructure</td><td>-</td><td>- Not discussed in interviews -</td></tr></tbody></table>

Traceability between reduced costs of engineering applications and PDM systems (O2) and standardisation (S1) and minimised customisation (S2) can be argued to be clear, as can traceability between the increased re-use of parts and designs (O1) and standardisation (S1). However, it can be questioned whether PLM standardisation (S1) is enough for securing the increased re-use of parts and designs (O1). Furthermore, allowing for differentiations (S2) cannot be traced to any of the objectives.
<figure><img src="image_5.png" /><figcaption>Fig. 3. Traceability analysis between elements of the PLM architecture model.</figcaption></figure>

In summary, the analysis showed the following: high level and low level strategy elements exist; high level and low level process elements exist, but connections between the two are missing; conflicts exist between elements due to elements of standardisation and differentiation; direct traceability can be identified between most elements of the lower layers and low level strategies with elements of high level strategy; traceability between the increased re-use of parts and designs and PLM standardisation can be argued as being clear, although it can be questioned whether it is enough to secure the increased re-use of parts and designs; and, allowing for differentiations cannot be traced to any objectives.

## 4.4 Step 3: Correlation Matrix Between the Architecture Model and the PLM Solution Guidelines

Agreements and conflicts between elements of the architecture model in Table 2 and the PLM solution guidelines in Table 1 are summarised in Table 3 below. A plus (+) (for example, in cell 'd';'S5') indicates that the architecture element 'S5' is in agreement with PLM solution guideline 'd'. The rationale behind each of the 154 (22 PLM architecture elements * 7 PLM solution guidelines) assessments in Table 3 is too extensive to fit within the scope of this paper.

<table><caption>**Table 3.** Correlation matrix with agreements (+) and conflicts (-) between PLM architecture elements and PLM solution guidelines.</caption><thead><tr><th rowspan="3"></th><th colspan="15">PLM architecture elements</th></tr><tr><th colspan="2">Objec.</th><th colspan="8">Strategy</th><th colspan="2">Process</th><th colspan="3">Information</th><th colspan="3">Application</th></tr><tr><th>O1</th><th>O2</th><th>S1</th><th>S2</th><th>S3</th><th>S4</th><th>S5</th><th>S6</th><th>S7</th><th>S8</th><th>S9</th><th>P1</th><th>P2</th><th>I1</th><th>I2</th><th>I3</th><th>I4</th><th>I5</th><th>I6</th><th>A1</th><th>A2</th><th>A3</th></tr></thead><tbody><tr><th>PLM solution guidelines</th><td>a</td><td></td><td>+</td><td>+</td><td>+</td><td>+</td><td>+</td><td>+</td><td>+</td><td>+</td><td>+</td><td>+</td><td>+</td><td>+</td><td>+</td><td>+</td><td>+</td><td>+</td><td>+</td><td>+</td><td>+</td><td>+</td></tr><tr><td></td><td>b</td><td></td><td>-</td><td>+</td><td>-</td><td></td><td></td><td></td><td></td><td></td><td></td><td>-</td><td>-</td><td>-</td><td>-</td><td></td><td>+</td><td>-</td><td>+</td><td>-</td><td>+</td><td>+</td></tr><tr><td></td><td>c</td><td></td><td>-</td><td>+</td><td>-</td><td>+</td><td>+</td><td>+</td><td></td><td></td><td></td><td>-</td><td>-</td><td>-</td><td>-</td><td></td><td>+</td><td>-</td><td>+</td><td>-</td><td>+</td><td>+</td></tr><tr><td></td><td>d</td><td></td><td>+</td><td>-</td><td>+</td><td></td><td></td><td></td><td></td><td>+</td><td></td><td>+</td><td>+</td><td>+</td><td>+</td><td></td><td>+</td><td>-</td><td>+</td><td>-</td><td>-</td><td></td></tr><tr><td></td><td>e</td><td></td><td>+</td><td></td><td>+</td><td>+</td><td></td><td></td><td>+</td><td></td><td></td><td></td><td></td><td></td><td></td><td>+</td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td></td><td>f</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td></td><td>g</td><td></td><td>+</td><td></td><td></td><td>+</td><td>+</td><td>+</td><td></td><td></td><td>+</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>
## 4.5 Step 4: Analysis of the Correlation Matrix

In terms of risk identification, a number of interesting patterns can be observed in Table 3: empty columns; empty rows; and, columns as well as rows with both agreements and conflicts.

An empty column indicates that an element is not possible to assess given the existing guidelines set, since the guidelines do not cover the area to which the element relates. In the correlation matrix, two elements lack correlations to guidelines (O1; S9). Element 'O1' is broken down into more concrete elements regarding PLM standardisation, although it has already been argued that this is insufficient to secure the increased re-use of parts and designs. There is no guideline regarding design re-use. Regarding element 'S9', there is no guideline about how the PLM solution should be expanded over time.

Similarly, an empty row indicates that the PLM solution's correlation to a guideline is not possible to assess given the existing set of elements. It does not relate to any of the existing elements, since the elements simply do not cover the area to which the guideline relates. At GlobalCorp, none of the guidelines completely lacks correlations to elements. However, guideline 'f' has only one correlation, one agreement ('I3'). Nonetheless, this agreement is very strong, and is therefore not considered a risk.

A column with both types of correlations means that an element is good from one guideline, but bad from another. A row with both types of correlations means that a guideline risks not being fulfilled with the existing elements. At GlobalCorp, several columns have both agreements and conflicts (S1-S3; S8; P1-P2; I1-I2; I5-I6; A1-A3). All conflicts from those columns are to one of the guidelines 'b', 'c', or 'd'. Elements of standardisation (S1; S3; S8; P1-P2; I1-I2; I5; A1) conflict with guidelines 'b' and 'c', although some differentiations are allowed (S2; A4; I6; A2-A3). Guideline 'c' is in agreement with elements 'S4'-'S6'. In contrast, standardisation (S1; S3; S8; P1-P2; I1-I2; I5; A1) contributes to agreement with guideline 'd', while elements of differentiation (S2; I6; A2-A3) are in conflict. This strengthens the indication that conflicts exist between the elements of GlobalCorp's PLM solution, and also that conflicts exist between the guidelines in Table 1.

In summary, the analysis showed that: guidelines are missing for assessing all of the elements of the solution; the solution is in conflict with three guidelines; and, some elements of the solution are in conflict with other elements.

## 4.6 Step 5: Generate Change Proposals

When analysing the architecture model, it was observed that GlobalCorp's process layer is very coarsely defined. Connection between high level processes and low level processes are missing and need to be developed in order to gain full advantage of the PLM concept.

It was also identified in the model that not enough elements exist to secure the increased re-use of parts and designs. In order to better gain benefits of scale, a stronger focus needs to be put on facilitating the increased re-use of parts and designs.
Furthermore, in analysing the traceability, elements of differentiation could not be
traced to any of the two objectives. However, elements of differentiation allow Glob-
alCorp's subsidiaries to better adapt the PLM solution to their needs. A new objective
could be formulated and communicated, legitimatising some degree of differentiation.
Differentiation should be based on product characteristics, such as technology do-
mains and business areas.

When analysing the correlation matrix, it was observed that conflicts exist between
the PLM solution and three guidelines. GlobalCorp could strive to further develop
their PLM solution in order to minimise conflicts with the guidelines. It is possible
that a PLM solution can contribute to coherent PLM architecture while at the same
time allowing for necessary differentiations between subsidiaries and the definition of
benefits for all stakeholders.

Several interviewees acknowledge that GlobalCorp's PLM solution in itself does
not provide benefits for all stakeholders, in particular not for the product engineers.
More work is required from them to save time in later lifecycle stages. Despite ele-
ments enabling differentiation, both end-users and departments argued that they
lacked incentives for deploying GlobalCorp's PLM solution. It is possible that, re-
gardless of any changes to the PLM solution, the third guideline in conflict ('define
benefits for all stakeholders') still risks not being satisfied. In such cases, at least the
potential drawbacks need to be mitigated. Means for doing so can for example be to
increase the workforce in those departments which after deployment need to contrib-
ute more tasks.

5 Method Evaluation

Regarding documentation of the PLM solution, elements could be described using
natural language and the PLM architecture model by [10]. As it was a first attempt to
apply the method, it was done on a high level, using a rather high level of guidelines
and generating a high level of suggested proposals. In the case of a deeper analysis, a
more formalised modelling approach may prove beneficial.

No layer of the PLM architecture model by [10] could be deemed unnecessary. The
infrastructure layer was not included and therefore not evaluated. One may, however,
argue the lack of an ‘organisational structure’ layer, as exists for example in the mod-
el by [15]. Future research on the topic is needed.

It is shown that the architecture model could be analysed in terms of the following:
coverage of elements in the different layers of the model; agreements and conflicts
between elements in the model; and traceability between elements in the model. It
was found that traceability was direct, rather than indirect, between high level strategy
elements and most low level strategy and lower layer elements. This finding challeng-
es the argument presented by [12], which has been applied in the architecture model
by [10], that traceability should be indirect between all layers of the architecture.
Whether the use of more formalised descriptions of architecture elements would have
made any difference is unclear; hence, future research on the topic is needed.
Correlations in terms of agreements and conflicts between elements of the PLM architecture model and the PLM solution guidelines could be assessed, although the assessments were somewhat subjective in nature. The assessment scale was detailed enough, given the available empirical data. Companies applying the method in assessing their own PLM solution, and thereby having a better understanding of their own context, may benefit from a multilevel assessment scale.

The correlation matrix could be analysed in terms of the following: coverage of the guidelines for assessing the PLM architecture model; coverage of the elements to secure agreements with guidelines; and agreements and conflicts between elements and guidelines.

The guidelines summarised by [14] worked to some extent, although an insufficient coverage was identified. More guidelines (e.g., in literature, at seminars or through communication with PLM experts) should be searched for in order to improve the assessment base.

Furthermore, conflicts between elements and between guidelines indicate that the relevance of elements and guidelines needs to be assessed on a relative basis, e.g. in order to properly prioritise standardisation versus differentiation. It is however not clear how relative relevance could be incorporated in the model. Future research on the topic is needed.

To conclude, more than giving absolute directions, the method served to facilitate discussions regarding risks associated with the PLM solution. Several risks were identified, concerning which suggested proposals could be made. However, a more detailed architecture model could possibly have contributed to a more accurate analysis.

# 6 Discussion of Research Approach and Usability of Results

For construct validity (cf. [16]), we have used multiple data sources (interviews, archival records and e-mail correspondence), and interviews have been transcribed and sent to the interviewees for validation. Based upon this data set, the architecture model of GlobalCorp's PLM solution, in comparison to which the method was tested, was constructed. For internal validity, all findings have been presented to case representatives, in both oral and written form.

There are two main contributions from this paper. First, the paper identifies risks associated with a PLM solution and generates suggested proposals based on those risks. The risks and suggested proposals presented are specific for GlobalCorp, although it is possible that parts of the results may be transferred to the reader by recognition (cf. [17]). The paper also provides a method for identifying risks associated with a PLM solution. Our aim has been to be as transparent as possible about the approach taken in demonstrating and evaluating the method, given the boundaries of this paper.

Some authors argue that transferability is a better quality criterion than generalisation for single case studies [e.g. 18]. An in-depth description of the characteristics of GlobalCorp would have facilitated transferability, but is omitted in this paper due to confidentiality reasons. However, we recall that GlobalCorp is a large, multinational
company, with multiple sites and subsidiaries around the world. They have formed
their PLM solution over a period of more than ten years, and can now be considered
as very experienced in the area. Despite their experience, risks associated with their
PLM solution could still be identified by applying the method. As such, this may be
an indication that the method is applicable for a wide range of cases.

7 Conclusions

The earlier a PLM solution can be evaluated, the earlier the PLM solution can be
improved. While existing research in the area focuses on evaluating the effects of a
real PLM solution, this paper has contributed to the area by proposing, demonstrating
and evaluating a method to identify risks associated with a tentative PLM solution.
Applying the method makes possible improvements to the PLM solution prior to de-
ployment.

It has been demonstrated in a case from the manufacturing industry that a PLM so-
lution can be identified, modelled using natural language description and a layered
PLM architecture framework, and analysed to identify risks associated with the PLM
solution. Furthermore, it has been demonstrated that a matrix with correlations in
terms of agreements and conflicts can be identified between elements of the model
and PLM solution guidelines from literature, and that the matrix can be analysed in
order to identify risks associated with the PLM solution. Last, it has been demonstrat-
ed that change proposals can be generated based on the identified risks.

The method evaluation indicates that the proposed method is useful support for
identifying risks associated with a PLM solution and thus serves as a base for generat-
ing suggested proposals. Rather than giving absolute directions, the method served as
discussion-facilitating support. However, additional testing of the method in real set-
tings is necessary in order to strengthen that indication.

**Acknowledgements.** This work has been carried out within the Sustainable Produc-
tion Initiative and the Production Area of Advance at Chalmers University of Tech-
nology in Gothenburg, Sweden. The support is gratefully acknowledged. We would
also like to express great gratitude to all who have participated in the study as inter-
viewees.

References

1. Stark, J.: Product Lifecycle Management: 21st Century Paradigm for Product Realisation, New York: Springer-Verlag (2004)

2. Markus, M.L. and Tanis, C.: The Enterprise System Experience: from Adoption to Success. In: Zmud, R.W. (ed.) Framing the Domains of IT Management: Projecting the Future Through the Past, Pinnaflex Educational Resources, Inc., Cincinnati, OH, USA, pp.173-207 (2000)

3. Ross, J.W.: Surprising Facts About Implementing ERP. IT Professional, Vol. 1, Nr. 1, pp.65-68 (1999)
4. Alemanni M., Alessia, G., Tornincasa, S. and Vezzetti, E.: Key Performance Indicators for PLM Benefits Evaluation: the Alcatel Alenia Space Case Study. Computers in Industry, Vol. 59, Nr. 8, pp.833-841 (2008)

5. Siddiqui, Q., Burns, N., Backhouse, C.: Implementing Product Data Management the First Time. International Journal of Computer Integrated Manufacturing, Vol. 17, Nr. 6, pp. 520-533 (2004)

6. CIMdata: Nissan Motor Corporation: Product Lifecycle Management Case Study. Ann Arbor, Michigan: CIMdata, Inc. (2008)

7. Rangan, R., Rohde, S., Peak, R., Chadha, B. and Bliznakov, P.: Streamlining Product Lifecycle Processes: a Survey of Product Lifecycle Management Implementations, Directions, and Challenges. Journal of Computing and Information Science in Engineering, Vol. 5, No. 3, pp.227-237 (2005)

8. Wognum, P. and Kerssens-van Drongelen, I.: Process and Impact of Product Data Management Implementation. International Journal of Product Development, Vol. 2, No. 1-2, pp.5-23 (2005)

9. Hewett, A.: Product Lifecycle Management (PLM): Critical Issues and Challenges in Implementation. Information Technology and Product Development, Annals of Information Systems, Vol. 5, No. 1, pp.81-105 (2009)

10. Zimmerman, T.: Implementing PLM across Organisations – for Multi-Disciplinary and Cross-Functional Product Development. PhD Thesis. Chalmers University of Technology, Gothenburg, Sweden (2008)

11. Zachman, J.A.: A Framework for Information Systems Architecture. IMB Systems Journal, Vol. 26, No. 3, pp.276-292 (1987)

12. Schekkerman, J.: How to Survive in the Jungle of Enterprise Architecture Frameworks: Creating or Choosing an Enterprise Architecture Framework. Victoria, British Columbia, Canada: Trafford Publishing (2003)

13. Ramesh, B., and Jarke, M.: Toward Reference Models for Requirements Traceability. Software Engineering, IEEE Transactions on, Vol. 27, No. 1, pp.58-93 (2001)

14. Bokinge, M., and Malmqvist, J.: PLM Implementation Guidelines – Relevance and Application in Practice: A Discussion of Findings from a Retrospective Case Study. International Journal of Product Lifecycle Management, Vol. 6, No. 1, pp.79-98 (2012)

15. Svensson, D., Malmström, J., Pikosz, P. and Malmqvist, J.: A Framework for Modelling and Analysis of Engineering Information Management Systems. Proceedings of DETC'99, Paper No DET99/CIE-9006, Las Vegas, NA, USA (1999)

16. Yin, R.K.: Case Study Research – Design and Methods, 3rd ed., Thousand Oaks, California: Sage Publications (2003)

17. Svensson, L., Brulin, G., Ellström, P.-E., and Widegren, Ö.: Interaktiv forskning – för utveckling av teori och praktik (Interactive Research – for Development of Theory and Practice). In Swedish. Stockholm: Arbetslivsinstitutet (2002)

18. Guba, E. and Lincoln, Y.: Fourth Generation Evaluation, Newbury Park, California: Sage (1989)