ABCDEFG
UNIVERS ITY OF OULU P.O.B . 7500 F I -90014 UNIVERS ITY OF OULU F INLAND
A C T A U N I V E R S I T A T I S O U L U E N S I S
S E R I E S E D I T O R S
SCIENTIAE RERUM NATURALIUM
HUMANIORA
TECHNICA
MEDICA
SCIENTIAE RERUM SOCIALIUM
SCRIPTA ACADEMICA
OECONOMICA
EDITOR IN CHIEF
PUBLICATIONS EDITOR
Senior Assistant Jorma Arhippainen
Lecturer Santeri Palviainen
Professor Hannu Heusala
Professor Olli Vuolteenaho
Senior Researcher Eila Estola
Director Sinikka Eskelinen
Professor Jari Juga
Professor Olli Vuolteenaho
Publications Editor Kirsti Nurkkala
ISBN 978-951-42-9797-7 (Paperback)ISBN 978-951-42-9798-4 (PDF)ISSN 0355-3213 (Print)ISSN 1796-2226 (Online)
U N I V E R S I TAT I S O U L U E N S I SACTAC
TECHNICA
U N I V E R S I TAT I S O U L U E N S I SACTAC
TECHNICA
OULU 2012
C 418
Hanna Kropsu-Vehkaperä
ENHANCING UNDERSTANDING OF COMPANY-WIDE PRODUCT DATA MANAGEMENT IN ICT COMPANIES
UNIVERSITY OF OULU GRADUATE SCHOOL;UNIVERSITY OF OULU, FACULTY OF TECHNOLOGY,DEPARTMENT OF INDUSTRIAL ENGINEERING AND MANAGEMENT
C 418
ACTA
Hanna K
ropsu-Vehkaperä
C418etukansi.kesken.fm Page 1 Tuesday, March 27, 2012 11:34 AM
A C T A U N I V E R S I T A T I S O U L U E N S I SC Te c h n i c a 4 1 8
HANNA KROPSU-VEHKAPERÄ
ENHANCING UNDERSTANDING OF COMPANY-WIDE PRODUCT DATA MANAGEMENT IN ICT COMPANIES
Academic dissertation to be presented with the assent ofthe Doctoral Training Committee of Technology andNatural Sciences of the University of Oulu for publicdefence in OP-sali (Auditorium L10), Linnanmaa, on 4 May2012, at 12 noon
UNIVERSITY OF OULU, OULU 2012
Copyright © 2012Acta Univ. Oul. C 418, 2012
Supervised byProfessor Harri Haapasalo
Reviewed byProfessor Hannu KärkkäinenDoctor Jari Collin
ISBN 978-951-42-9797-7 (Paperback)ISBN 978-951-42-9798-4 (PDF)
ISSN 0355-3213 (Printed)ISSN 1796-2226 (Online)
Cover DesignRaimo Ahonen
JUVENES PRINTTAMPERE 2012
Kropsu-Vehkaperä, Hanna, Enhancing understanding of company-wide productdata management in ICT companies. University of Oulu Graduate School; University of Oulu, Faculty of Technology, Department ofIndustrial Engineering and Management, P.O. Box 4610, FI-90014 University of Oulu, FinlandActa Univ. Oul. C 418, 2012Oulu, Finland
Abstract
Data is becoming more critical success factor as business processes rely increasingly oninformation systems. Product data is required to produce, sell, deliver, and invoice a product ininformation systems. Traditionally, product data and product data management (PDM) studieshave focused on product development and related activities, with less attention being paid to PDMin other lifecycle phases.
The purpose of this doctoral dissertation is to clarify challenges and prerequisites for company-wide PDM. The study covers the entire product lifecycle and provides potential solutions fordeveloping company-wide PDM and enhancing PDM understanding as a company-wide action.
The study was realised by collecting and analysing data from those ICT companies that areseeking for better ways to manage a wide product-range, technologically complex products andcomprehensive solutions by enhancing their data management practices. The empiricalpractitioner’s experiences and perceptions are seen to have increased the knowledge in company-wide PDM. This study adopted a case study approach and utilises interviews as the main datacollection method.
This study indicates that company managers have already realised that successful businessoperations require a higher-level understanding of products and related product data. In practice,however, several challenges hinder the ability to achieve the goal of higher-level business-drivenPDM. These challenges include product harmonisation, PDM process development requirementsand information systems development requirements.
The results of this research indicate that product harmonisation is required to better supportefficient product data management. Understanding the true nature of product data, that iscombination of product master data and other general product data, and the content of product datafrom different stakeholder perspectives are prerequisites for functional company-wide PDM.Higher-level product decisions have a significant impact on product data management. Extensiveproduct ranges require general guidelines in order to be manageable, especially as even singleproducts are complex. The results of this study indicate that companies should follow a top-downapproach when developing their PDM practices. The results also indicate that companies requirea generic product structure in order to support unified product management. The main implicationof this dissertation is the support it provides for managers in terms of developing true company-wide product data management practices.
Keywords: ICT, PDM, PLM, product data, product data management, product structure,stakeholders
Kropsu-Vehkaperä, Hanna, Edellytyksiä yrityksen laajuiselle tuotetiedonhallinnalle ICT-yrityksissä. Oulun yliopiston tutkijakoulu; Oulun yliopisto, Teknillinen tiedekunta, Tuotantotalouden osasto,PL 4610, 90014 Oulun yliopistoActa Univ. Oul. C 418, 2012Oulu
Tiivistelmä
Tiedosta on tullut tärkeä liiketoiminnan menestystekijä liiketoimintaprosessien hyödyntäessäyhä vahvemmin tietojärjestelmiä. Tuotteisiin liittyvä tieto on olennaista, jotta tuote voidaan val-mistaa, myydä, toimittaa ja laskuttaa. Tuotetietoa ja sen hallintaa on perinteisesti tarkastelu tuo-tekehityslähtöisesti kun tämä tutkimus pyrkii ymmärtämään tuotetiedon hallintaa kattaen myösedellä mainitut yrityksen toiminnot. Tämän tutkimuksen tavoitteena on tunnistaa haasteita japerusedellytyksiä yrityksenlaajuisten tuotetiedonhallinnan käytäntöjen kehittämiseksi.
Tuotetiedon hallinta yrityksen laajuisena toimintona vaatii ymmärrystä eri toimijoista, jotkakäyttävät tuotetietoa; tiedon luonteesta sekä tiedon hyödyntämisestä eri prosesseissa. Tutkimustoteutettiin ICT yrityksissä, joissa tuotetiedon käytäntöjä tehostamalla haetaan keinoja hallitalaajaa tuotteistoa, teknologisesti monimutkaisia tuotteita sekä kokonaisratkaisuja. Käytännöntoimijoiden kokemukset ja käsitykset ovat ensiarvoisen tärkeitä lisätessä tietoa yrityksen laajui-sesta tuotetiedonhallinnasta. Tutkimus toteutettiin tapaustutkimuksen menetelmin, joissa pääa-siallisena tiedonkeruu menetelmänä hyödynnettiin haastatteluja.
Tämä tutkimus osoittaa, että liiketoimintalähtöisen tuotetiedon hallinnan kehittäminen onajankohtaista yrityksissä. Tutkimuksessa tunnistetaan lukuisia haasteita, jotka ovat estäneet lii-ketoimintalähtöisen tuotetiedonhallinnan saavuttamisen. Näitä haasteita ovat: tuotteen harmoni-sointi yrityksen eri toiminnoissa, tuotetiedon hallinnan prosessien kehittämisen vaatimukset sekätietojärjestelmien kehittämisen vaatimukset.
Tutkimustulosten mukaan tuotteiston harmonisointi on yksi perusedellityksistä tehokkaalletuotetiedon hallinnalle. Yrityksen kattava tuotetiedon hallinta vaatii myös tuotetiedon todellisenluonteen ymmärtämistä, joka koostuu tuotteen master datasta sekä muusta tuotetiedosta. Lisäksion olennaista ymmärtää tuotetiedon sisältö sen todellisten käyttäjien näkökulmasta käsin. Tä-män tutkimuksen tulokset osoittavat myös, että tuotetiedon hallinnan kehittäminen pitäisi edetä”top-down” eli ylhäältä-alas periaatteen mukaan. Tulokset myös viittaavat siihen, että geneeri-nen tuoterakenne tukee yhdenmukaisia tuotehallinta käytäntöjä. Nämä tulokset tarjoavat työssäesitettyjen kuvausten ja mallien ohella tukea tuotetiedon hallinnan käytäntöjen kehittämiseenyrityksen laajuisesti.
Asiasanat: ICT, PDM, PLM, tuotetiedot, tuotteet - elinkaari, tuotteet - hallinta, tuotteet- rakenne
7
Acknowledgements
In the autumn of 2007, when I started my work at the Department of Industrial
Engineering and Management (DIEM) at the University of Oulu, it was not clear
to me what the work could involve, other than working as a teaching assistant.
The intervening years have introduced me to a wide variety of academic work.
Specifically, producing this doctoral thesis has been a learning journey for a
researcher’s work. This journey has offered a lot of different kinds of experiences
and has not always moved forward in a straight line. Some parts of the journey
have been delightful and easily passable, but I have also learned to deal with
strong feelings of frustration and uncertainty. Certain special people have made
the journey easier and more pleasant and I owe them my thanks for enabling me
to complete this work.
First of all, I would to express my great gratitude to my supervisor, Professor
Harri Haapasalo, without whom this research project would not have been
possible. Thank you, Harri, for your constant support and guidance. Your
encouragement along the way has kept me on track when I doubted whether I
could complete this research. I also appreciate that, from the very beginning, you
familiarised me with the different sides of a researcher’s work, which will make
my next steps somewhat easier. It has been joy to work with you.
I also would like to thank the head of DIEM, Professor Pekka Kess, who
offered me the possibility to work at DIEM. Pekka, you have given me the
opportunity to see other views of academic work and your wide network has
enabled my research exchange during my thesis work. You also always had time
for discussions when I had my many questions of doing research.
Special thanks also go to Dr Pekka Belt, Dr Janne Härkönen and Dr Matti
Möttönen. You have showed by your example the new ways of doing research
and encouraged also others to do so – to work as a team. It took some time for me
to be ready for that but, in the end, the review sessions we held were full of
difficult but effective work that resulted in the completion of this thesis summary.
I certainly needed the positive push that you gave me in order to finalise my
thesis. Also, several people have offered their support as co-authors of the journal
articles. Many thanks to Professor Harri Haapasalo, Associate Professor Kongkiti
Phusavat, Dr Janne Härkönen, Mr Risto Silvola, Mrs Suvi Lokkinen and Mr Olli
Jääskeläinen for their valuable support and contributions to the articles.
I am very grateful to TEKES, the University of Oulu and DIEM, and the
partner companies that funded the original project (PLMD2). I would like to
8
thank the project organisation all the support for my research. The discussions in
steering group were very valuable and gave me confidence regarding the practical
applicability of the research. I would like to especially thank Mr Risto Silvola for
his commitment to this project and support for the research. You, Risto, have a
very special innovative attitude towards developing data management and
business effectiveness. Your help and wide network was also priceless when
organising the data collection in companies. Your support was also valuable and
encouraging in my moments of frustration. I would also like to thank the other
PLMD2 project researchers, Mr Olli Jääskeläinen, Mr Tapani Kemppainen and
Mr Mikko Vahtiala, for their work efforts during the research. I also want to thank
the almost 20 students who participated in the autumn of 2008 in the product data
management course and took part in the research assignment. Warm thanks for
your work in carrying out and documenting the interviews. I am also grateful to
all the company representatives who took part in the interviews for providing
their time and knowledge. You have offered me a great learning opportunity for
product data management in practice. I have been privileged to meet and discuss
with people who have strong professional know-how.
One special path on my journey led me to the wonderful country of Thailand.
I am very grateful to Associate Professor Kongkiti Phusavat for your support in
making my research exchange possible at Kasetsart University in Bangkok. I
would like to thank you your time for discussions, guidance in making research,
and your special kind of hospitality during my stay.
I also want to thank my former and present colleagues at the DIEM for your
co-operation. Special thanks are due to Dr Mirja Väänänen, Dr Maila Herrala, Ms
Anyanitha Distanont and Mr Tuomo Kinnunen for your valuable peer support.
I would also like to thank the pre-examiners Professor Hannu Kärkkäinen and
Dr Jari Collin for their constructive critique of the thesis.
I would like to express my gratitude to the following foundations that gave
me financial support during my doctoral studies and thesis work: Tauno
Tönningin säätiö, Nokia Foundation, TeliaSonera Finland Oyj:n tutkimus- ja
koulutussäätiö, Riitta ja Jorma J. Takasen Säätiö, and RADMA (Research and
Development Management).
The latest year has brought dramatic change in my life and I am really
leaving the busiest year of my life. My husband and I welcomed our first child,
Vilma, in the spring of 2011, while we were building a house and I had this thesis
project to finalise. One can feel insane finalising a thesis under such
circumstances, but I did it for three reasons. First, the incomplete thesis was on
9
my mind too much, making me unable to even make other things and, secondly, it
was not so badly incomplete after all. Thirdly, and most importantly, I received
great encouragement and support from my family. My parents’ support has being
priceless for surviving and concluding this project successfully. Without your
altruistic support, Mum and Dad, I could not have completed this thesis yet. You
have done so much for my sake, more than you can ever believe. I also appreciate
the encouragement that the rest of the family, in-laws, and friends have showed to
me during this project.
I am indescribably grateful for all the support and love of my husband, Janne.
This project has not always been easy to me but your positive grasp on life and
way of handling issues enabled me to calm my storms of frustrations sooner. Your
own research experience has been valuable to me and I have received practical
advice when needed. I am grateful for your patience and support when I was
questioning the sanity of this research. Thank you for believing me during this
project. Last but not least, Vilma, you have been the reason and given me the
power to complete the thesis sooner rather than later.
Oulu, Finland, March 2012 Hanna Kropsu-Vehkaperä
10
11
List of abbreviations and definitions
BOM Bill-of-Material
CAD Computer-Aided Design
CAM Computer-Aided Manufacturing
ECM Engineering Change Management
EOL End of Life
ERP Enterprise Resource Planning
FEM Finite Element Method
HW Hardware
ICT Information and Communications Technology
IT Information Technology
OEM Original Equipment Manufacturer
PC Personal Computer
PDM Product Data Management
PLC Product Lifecycle
PLM Product Lifecycle Management
STEP Standard for the Exchange of Product model data
SW Software
Data
Data is digitally stored information (Encyclopædia Britannica 2009).
Data occurs in forms such as symbols, images, and texts (Lawrence
1999, Williamson 1982).
Product
A product is an item that has been made to be sold. It can be
hardware, software, service or a combination thereof. Product may
also contain documentation.
Product Data
Product data broadly covers all data related to a product. Product
data ensures that a company manufactures, delivers, sells and
maintains correct products.
12
13
List of original publications
This dissertation is based on the following publications:
I Kropsu-Vehkapera H, Haapasalo H, Harkonen J & Silvola R (2009) Product data management practices in high-tech companies. Industrial Management & Data Systems 109(6): 758–774.
II Kropsu-Vehkapera H, Haapasalo H, Lokkinen S & Phusavat K (2011) The influence of product complexity on order handling process. International Journal of Innovation and Learning 10(2): 123–143.
III Kropsu-Vehkapera H & Haapasalo H (2012) Defining product data views for different stakeholders. Journal of Computer Information Systems 52(2): 61–72.
IV Kropsu-Vehkapera H, Haapasalo H, Jaaskelainen O & Phusavat K (2011) Product Configuration Management in ICT Companies: The Practitioners’ Perspective. Technology and Investment 2(4): 273–285.
The author of this dissertation was the primary author of all of the original
publications. The role of the researcher is described detailed in Chapter 1.3. The
role of the co-authors included reviewing and commenting on the article
manuscripts of the first author. In addition, the author of this dissertation has
participated as a team member in broader research on product development in the
department of industrial engineering and management at the University of Oulu,
which resulted in several other publications as a co-author.
14
15
Contents
Abstract
Tiivistelmä
Acknowledgements 7 List of abbreviations and definitions 11 List of original publications 13 Contents 15 1 Introduction 17
1.1 Background ............................................................................................. 17 1.2 Objectives and scope ............................................................................... 21 1.3 Research process and dissertation structure ............................................ 23
2 Literature review 29 2.1 Theoretical framework ............................................................................ 29 2.2 Multidimensionality of a product ............................................................ 31
2.2.1 Defining the product ..................................................................... 31 2.2.2 Different iterations of a product ................................................... 32 2.2.3 Product complexity ....................................................................... 33
2.3 Managing product data ............................................................................ 34 2.3.1 Product data management ............................................................. 34 2.3.2 Defining product data ................................................................... 36 2.3.3 Identifying the content of product data ......................................... 37 2.3.4 Product structure as a way to model a product and product
data ............................................................................................... 39 2.4 Internal stakeholders – creators and users of product data ...................... 42
2.4.1 Product lifecycle ........................................................................... 42 2.4.2 Business processes and key stakeholders ..................................... 43
2.5 Theoretical outline for analysing company-wide product data
management ............................................................................................ 44 3 Research contribution 47
3.1 Key challenges on managing PDM in ICT companies ........................... 47 3.2 Internal stakeholders and their view to product data ............................... 51 3.3 Enhancing the management of product data ........................................... 55 3.4 Results summary ..................................................................................... 59
4 Discussion 63 4.1 Theoretical implications .......................................................................... 63 4.2 Practical implications .............................................................................. 65
16
4.3 Reliability and validity ............................................................................ 67 4.4 Recommendations for further research ................................................... 71
References 73 Original publications 83
17
1 Introduction
1.1 Background
The current business environment, with its fierce competition, requires companies
to continuously seek for new ways to reduce costs and improve the effectiveness
of their activities. In particular, the operational environment of information and
communications technology (ICT) companies has changed dramatically over the
past few decades (e.g. Rao et al. 2004). Frequent technology development,
increased product complexity, constant time-to-market pressures, and heavy price
erosion have contributed to the current situation (Lehto et al. 2011, Belt et al.
2009, Helo 2004, Moore 1999, D’Aveni 1995). Technological development has
had a dramatic effect on the ICT industry, which now includes the sectors of
information technology and telecommunications and has recently even converged
with the media industry (Hallikas et al. 2008, Palmberg et al. 2006). The PC and
Internet revolution, as well as digital communication networks, has created new
business opportunities. The nature of ICT products is changing from traditional
electronic devices to offerings that include a great amount of internal integration,
as well as converging technological products and services (Pynnönen et al. 2008,
Mikkonen et al. 2008, Palmberg & Martikainen 2006, Rao et al. 2004). Even
traditional manufacturing companies are moving towards service orientation (e.g.
Baines et al. 2009). Consequently, the overall variety of ICT products 1 is
immense.
The heterogeneous nature of ICT products, combined with wide product
portfolios, increasing product variation, internal product complexity, and
continuous product changes, makes product data management (PDM) challenging.
Product management and, in particular, efficient product data sharing through
product lifecycle, has become a necessity for fast product introductions
(Buffington 2011, Ouertani et al. 2011), for process functionality with
collaborative partners in supply chain (Gerritsen et al. 2008), and for ensuring the
1 The OECD (2003) defines ICT goods as “those that are either intended to fulfil the function of information processing and communication by electronic means, including transmission and display, OR which use electronic processing to detect, measure and/or record physical phenomena, or to control a physical process”. The EU Commission (2006) adds services to the definition of ICT products: “any communication device or application … as well as the various services and applications associated with them”.
18
quality of product, service and support. All of these factors contribute to the
overall efficiency of a company’s value-creation chain (Terzi et al. 2010).
Modern digitalisation has made it possible to organise work in multiple sites
while enabling tight collaboration with business partners (e.g. suppliers and
subcontractors). One of the major challenges in this operational environment is to
ensure adequate data between different sites and stakeholders. Data has become
an important asset that makes data quality a topical issue for ensuring daily
operations (e.g. Redman 2008). The increasing amount of data makes data
management challenging, which leads to data quality problems that are very
common in today’s companies (Breuer 2009, Lee et al. 2006, Knolmayer &
Röthlin 2006). Data errors and inconsistencies cause data quality issues, which
leads to mistakes, lost opportunities, failed deliveries and invoicing problems (for
more examples, see Redman (2008)). Experts have estimated the costs of poor
information quality to equate to 15–25 percent of operating profits (Olson 2003).
According to Russom (2006), product data causes 43 percent of all data problems
in organisations. Product data-related challenges are topical today, with the vast
amount of data created and handled throughout a product’s lifecycle, and they
continue to increase as companies are required to keep track of products longer in
their IT systems (Saaksvuori & Immonen 2008, Ameri & Dutta 2005, Crnkovic et
al. 2003). However, most managers believe that IT systems actually ensure the
quality of data (Redman 2008). Figure 1 illustrates changes in the business
environment that influence product data management in ICT companies.
19
Fig. 1. Changes in the business environment increasing the importance of product
data management in ICT companies.
Since the 1980s, engineering companies have taken steps to electronically
manage engineering data (also known as engineering drawings) (Huang et al.
2004, CIMdata 2002, Sulaiman 2000). In the mid-1990s, the concept of product
data management (PDM) was introduced to the business world (e.g. Rangan et al.
2005, Sulaiman 2000, Halttunen & Hokkanen 1995). This caused a shift in focus
towards integrated and managed product data processes and applications in order
to manage all kind of information that define products2 across multiple systems
and media (e.g. Saaksvuori & Immonen, 2008, Stark 2005, Philpotts 1996). Today,
companies are looking for company-wide solutions to improve their business
performance through better product data management (CIMdata 2002). The
current trend in PDM discussion is to cover the entire product lifecycle in data
management. Consequently, the product lifecycle management (PLM) concept
has emerged recently, placing greater emphasis on full, integrated lifecycle
management (e.g. Giménez et al. 2008, Sudarsan et al. 2005). Today, PLM is the
predominant concept and also covers PDM activities (see, e.g. Stark 2005,
Sudarsan et al. 2005, CIMdata 2002).
2 When considering PDM, a “product” can be understood as a product type with possible revisions and variants, not as an individual serial-numbered item delivered to the customer. PDM is not intended to manage individual products that are delivered to customers in the first place. Enterprise resource planning (ERP) and the like are typically used for these individual product records (e.g. Philpotts 1996, Rangan et al. 2005)
Quick product development- more products in shorter time- more product variations and versions
Cost reduction- process perspective
-reusing the existing design and documentation- tackle the lack of product data in processes
- product perspective- increase effectiveness and volume by productconfiguration
New business models- life extended services- e-commerce- collaborative operations
Amount of product data is increasingNeeds for product configuration and change management
Reuse of product strucureImprove the quality and availability of product data
Need for product data model
Product data needed over longer timeProduct need to be clearly definedNeed for product data model
Drivers Needs for PDM
20
PLM promises to tackle the challenges of managing all product-related data,
from cradle to grave (e.g. Saaksvuori & Immonen 2008, Sudarsan et al. 2005).
However, the promise of full lifecycle-wide product data management has not yet
been reached in most organisations (Rangan et al. 2005). In fact, product
development and manufacturing views of product data have dominated the
discussion and solutions on PDM (e.g. Stark 2005, Abramovici & Sieg 2002, Liu
& Xu 2001). Only individual studies (e.g. Johansson and Medbo (2004) study on
material supply) have tried to raise discussions on other viewpoints. In addition,
according to Ala-Risku (2009), surprisingly few academic studies have actually
covered, even shortly, product data in operations and maintenance phases in PLM
discussion. It has also been argued that the methods used to collect product data
from middle and end-of-life phases are incomplete in practice (Yang et al. 2007,
Jun et al. 2007, Abramovici 2007). Silo thinking lives on, promoting functional
orientation, and the organisational processes and distinct applications all too often
fail to support the idea of smooth data flow through the entire order-delivery
process (Anderson et al. 2006). Stakeholders across the product lifecycle, such as
sales, delivery and after-sales, should be included in order to reach a true
company-wide PDM (Gerritsen et al. 2008). The few PLM practical experts place
greater emphasis on different operations and stakeholders when discussing
product data management (see Saaksvuori (2011), Saaksvuori & Immonen (2008)
and Stark (2005)). It seems that there is very limited knowledge about the role of
product data in other operations than product development and manufacturing.
True organisation-wide product data management cannot be achieved without
understanding the product and related data from the business perspective. In the
networks of diverse stakeholders, the way product data is understood becomes
especially challenging. Product data is complex in nature and is scattered over
organisation and managed separately, having different meanings (Snow 2008,
Saaksvuori & Immonen 2008, Boyd 2006, Sudarsan et al. 2005). Product data
exists in different forms in various applications (Feng et al. 2009, Liu & Xu 2001),
often in conflicting formats due to the lack of standardisation (Baïna et al. 2009,
Lee et al. 2006). All these variations have led to variance in the business concepts
and object definitions (Moss 2007). Consequently, integration of applications,
data and processes across companies is challenging (e.g. Qu & Wang 2011,
Silcher et al. 2010, Shu & Wang 2005).
In order to be competitive, companies require a single, company-wide
presentation of product data that can be utilised across an entire organisation
(Saaksvuori & Immonen 2008). According to Abramovici (2007), this kind of
21
company-wide product presentation is not yet to be fully realised, which leaves
room for further studies. In order to improve product data management that
covers company’s product related processes and integrates diverse organisational
product data requirements and product concepts, it is necessary to have a holistic
product data model that unifies product terminology across a company (Baïna et
al. 2009, Hvam et al. 2002, Sudarsan et al. 2005, Svensson & Malmqvist 2002).
The need to share information across the company and supply chains requires that
data is exposed and shared from silos and presented in a unified format (Boyd
2006, Dumas et al. 2005).
Overall, the benefits of PLM are widely recognised (e.g. Terzi et al. 2010,
Saaksvuori & Immonen 2008, Alemanni et al. 2008, Stark 2005, CIMdata 2002),
although the implementation of full scope PLM appears to remain a challenge.
The focus of PLM is still certain special activities rather than the entire lifecycle
of a product (Saaksvuori 2011, Siller et al. 2008, Ming et al. 2005). Also, the
academic literature has not met the challenge of recognising the relevant product
data for diverse business processes (e.g. Terzi et al. 2010) and cannot explain
what product data is by noting all the different stakeholders that use the product
data, even though product data harmonisation and standardization remains a
topical challenge for practitioners (e.g. Saaksvuori 2011). The focus of the present
thesis is on product data, how different stakeholders perceive it, and how to
expand the understanding and utilisation of product data throughout the company.
In order to tackle this challenge and manage the heterogeneous set of information,
it is necessary to have a model that helps recognise all relevant information
related to the product from diverse stakeholders’ viewpoints. This kind of
approach could also help companies create common terminology for their
products that have been pointed out as an important issue for practitioners. This
dissertation aims to identify the elements that are needed in order to develop a
company-wide product data representation.
1.2 Objectives and scope
Success in business today relies on information about markets and competitors, as
well as internal information on one’s own products and processes. The
significance of product data has increased due to product complexity and the need
to provide product variations. Companies face challenges related to the effective
use of product data as the required information is scattered and is typically
located in different parts of organisations and in multiple data bases with different
22
formats. In addition, product data needs vary depending on which stakeholder
group’s needs are to be addressed. Consequently, there is a clear need to improve
product data management across company functions.
This study explores the role of product data in modern, global ICT business.
The research objective that this doctoral dissertation attempts to address can be
formulated as:
To recognise challenges and prerequisites for company-wide product data
management covering the product’s entire lifecycle, and to provide potential
solutions on how to approach company-wide product data management.
The research objective is further divided into the following research questions:
RQ1. What are the key product data management challenges in ICT
companies?
RQ2. Who are the relevant key stakeholders using product data and how is
product data understood in different parts of a company?
RQ3. How can the company-wide management of product data be enhanced?
RQ1 aims to map the fundamental PDM challenges that apply for true ICT
companies. RQ2 clarifies what product data is throughout a company and which
actors utilise it. RQ3 takes a more holistic approach towards improving product
data management in a company-wide context.
The research questions are answered by four research articles covering
different viewpoints, all of which provide a partial answer for the research
objective. RQ1 is answered by a combination of articles I, II and IV. RQ2 is
answered by article III and RQ3 by articles III and IV.
This dissertation understands PDM as a part of the PLM concept. PLM can
be approached by numerous product management entities that are often studied
from this particular managerial viewpoint. The following product management
entities can be considered as part, but not all, of PLM: product data management,
product change management, configuration management, product structure
management, product program management, product portfolio management,
workflow and process management, and product development management (e.g.
Liu et al. 2009, Ebert & De Man 2008, Saaksvuori & Immonen 2008, Stark 2005).
However, the present study does not intend to discuss all of the different sub-areas
of PLM in great detail.
23
Product data studies are mainly focused on engineering-related data and its
management on PLM context (e.g. Siller et al. 2008, Kiritsis et al. 2003).
Therefore, the present study focuses on understanding the nature of product data
experienced by company internal stakeholders and how the product data should
be modelled in order to reach the company-wide perception of product data. This
dissertation is managerial in nature, without particularly focusing on data systems
while discussing product data. The data systems viewpoint has dominated
previous research, which leaves room for complementary viewpoints.
The focus of this dissertation is limited to large and medium-sized ICT
companies. As the ICT sector is broad in nature, the study is particularly
interested companies whose products combine hardware, software or services
(such as maintenance or consultancy), thereby making their products
heterogeneous in nature. The products are physical goods with services or
services with heavy physical infrastructure, which excludes pure software or
media products. Technology and knowledge intensity is high in the products
studied.
In order to avoid confusion, it is important to clarify the terminology for
using data and information. Data is often defined as facts (Alter 1999, Pollock
and Hodgson 2004) that occur in the form of symbols, images or text, for
example (Lawrence 1999, Williamson 1982), whereas information is defined as
data that has been processed in some manner (Lawrence 1999, Wang 1998,
Williamson 1982). The terms data and information are often used synonymously
and these two terms are separated intuitively in practice (Wang 1998). In the
context of PLM, the term product data is often used interchangeably with the
term product information when they actually mean the same thing (Fensel et al.
2001, Liu & Xu 2001). The present study uses the term product data since it is
more commonly used when discussed product data management and related
issues. Therefore, data in this case is not only unprocessed data but also
understood to include the wider definition of product data to cover all product-
related data that is used for communication, interpretation, or processing, either
by human beings or by computers.
1.3 Research process and dissertation structure
According to Lancaster (2005), researchers considering scientific research from a
philosophical viewpoint face epistemological, ontological and ethical questions.
Namely, how can one believe and know of reality based on scientific research,
24
how is scientific knowledge obtained and when is this knowledge scientific; when
does the researcher abuse his research object or act unethically against the
scientific community.
Epistemology considers what is understood as appropriate knowledge
regarding the social world. An important aspect is the question of whether a
natural science model of research process is suitable for studying the social world.
(Bryman & Bell 2003). Ontology can be seen as a reality in which studied
phenomena are understood to exist and how the studied phenomena relate to this
reality. Ontological pre-conceptions on the nature of studied topics are typical for
scientific research. Ontology determines whether the reality is objective or
subjective. Ontology is understood to influence the selection of theory and
concepts. (Harisalo 2008, Anttila 2005). Figure 2 illustrates the epistemological
and ontological basis for this research.
Fig. 2. Epistemological and ontological basis.
Epistemology can be roughly divided into positivism and interpretivism.
Positivism reflects a view in which a phenomenon is sought to explain causal
relationships or regularities, whereas interpretivism emphasises the understanding
of a phenomenon through those who are involved in it. (Saunders et al. 2009).
The present is closer to interpretivism than positivism. The research approaches
product data management as a company-wide issue, which is not a standardised
one. In general, academic PLM research is relatively young (e.g. Kärkkäinen et al.
2009), which means that the related concepts are vague. Consequently, this study
aims to increase the understanding of the subject; in order to understand this
phenomenon, it is necessary to first understand the involved persons and then
how they perceive product data and its management.
Ontology can be roughly divided into objectivism and subjectivism.
Objectivism is an ontological position that implies that research is based on facts
rather than subjective analysis. Objectivism sees phenomena as being independent
of social actors. In objectivism, a company or an organisation is seen as a
machine-like entity that functions based on standards, guidelines, rules and
Epistemology
Ontology
Positivism Interpretivism
Objectivism Subjectivism Pragmatism
25
legislation. People are operators and realise processes and values. According to
subjectivism, social phenomena are created by social actors and their observations,
which highlights individual’s experiences. In companies, operations are based on
interaction by people. (Saunders et al. 2009, Bryman & Bell 2003). The present
study is somewhere in the middle of the above ontological scale and can be seen
to follow pragmatism. Created knowledge requires a contextual understanding
and is valuable when used in practice.
Since the research topic, which approaches PDM as a company-wide issue, is
not standardised, the qualitative method was seen as providing the best support
for this study. The aim of this study is to create in-depth understanding of product
data and its company-wide management when the experiences of industry
managers and practitioners were found to be the key issue in order to obtain the
research goals.
This study has utilised inductive logic of reasoning. Inductive logic can also
benefit the dialogue of theory and observations and is not necessarily a one-way
approach from observations to theories (Bryman & Bell 2003). The present study
uses earlier studies as background of qualitative investigations in order to ensure
that relevant concepts are clearly defined for the research phase. However, the
core of the research is intended to create new knowledge based on the findings.
The interviews form the foundation for the study and utilises the understanding of
the researcher and other relevant actors.
Qualitative research is often seen as a way of gaining a deeper understanding
of a phenomenon, which makes it fitting for the purpose of this research. The case
study method was selected for data collection for several reasons. Case studies are
often used in order to increase the understanding of a fuzzy phenomenon. The
case study method makes it possible to utilise different techniques on data
collection and have a strong empirical emphasis. (e.g. Yin 2003).
In order to ensure its quality, research must meet the criteria of reliability and
validity. Research design, data collection, and data analysis are the key to
establishing the quality in case studies. (Yin 2003). The validity and reliability of
the research in the present study is designed to be increased in the following ways:
validating the case study reports by the informants; data triangulation such as
using multiple sources of evidence, as well as different perspectives and different
researchers; describing the research process; and establishing a database for
research data. These are discussed further in the following description of the
research process.
26
This research was conducted across four separate studies involving industrial
companies and university researchers. Table 1 describes the researcher’s role in
each of the studies. The researcher was the main planner of individual studies I,
III and IV. For the research in study II which covers a larger study area, the
researcher planned the sub-research part focusing on product data management
issues. In this context, planning denotes defining the research problem, relevant
interview structure and questionnaire, and the subsequent method of analysis. The
researcher was responsible for selecting the relevant informants in studies I, III,
and IV, but also participated in the selection of informants for study II. The
researcher was the major data collector in studies III and IV; study I utilised
research assistants and colleagues collected the data for study II. The contribution
of other researchers in the data collection stage reduced the level of bias in the
data. Importantly, the researcher was responsible for analysing and drawing
conclusions in all of the studies that comprise this dissertation.
Table 1. The researcher’s roles in each sub-study.
Article Planning Selecting
informants
Collecting data Analysing Drawing
conclusions
I X X X X
II X X X
III X X X X X
IV X X X X X
The research process for each study phase was almost identical. Figure 3
describes the typical research process for all four articles upon which this
dissertation is founded. The key steps of each individual study include a literature
review, followed by creation of the interview structure and, in some cases, a
framework for study, data collection, analysis, and conclusions.
Fig. 3. Research process.
The individual studies were mainly carried out inductively. Each study started
with a literature review in order to gain an understanding of the key concepts and
Literature review on
studied issuesData collection Analysis Conclusions
Framework for study
Interview structure
27
key results of previous studies related to the research topic. The literature review
was a foundation upon which to formulate interview structure and questionnaire.
Articles I and III also utilised the literature review in order to create a frame with
which to support the results analysis phase.
The research material is a set of case studies that were selected to support the
research target described in detail in each article. In article III, for example, the
case company selection is based on gaining versatile viewpoints of studied issues.
Cases from the ICT sector were chosen since product data management issues are
topical in this sector. The ICT sector includes a lot of variety, which means there
are vast possibilities for different case selections. The intention was to select
representative cases for different sub-research purposes that, together, support the
main research objective. Basically, in order to get companies interested in this
study, they must all have met product data management to be topical development
issue on their organisations.
The data collection phase in each study included interviews conducted in the
ICT sector. The interviews followed a semi-structured thematic interview
approach and were conducted informally, in a qualitative manner, which enabled
the interviewees to explain and clarify the topics as entities. All of the interviews
were recorded and transcribed in order to ensure the full utilisation of the research
data in the analysis phase. In addition to the interviews, article III included a wide
range of secondary data sources (relevant company documentation) as research
data. Table 2 summarises the industrial involvement and materials used in the
research phases. The table presents the number of companies and the number of
industrial interviews for each research article, as well as the other relevant
material utilised in the study. More than eighty interviews were conducted.
Table 2. Industrial involvement and materials used in research.
Article Nr. of companies Nr. of interviews Others
I 4 12 Workshop with 7 company representatives
II 1 12
III 3 46 16 documents related to companies’ PDM
IV 6 42
In each sub-study, all of the individual interview results were analysed according
to the chosen focus. Next, the general company-wide viewpoint on the focused
issue was drawn in order to understand the meaning of the issue in focus, not
from each interviewee’s viewpoint but from the wider company-wide or other
28
relevant sub-organisational unit viewpoint. In sub-studies II and III, the
informants validated the case reports. When appropriate, the overall results were
compared with the literature. Finally, implications and conclusions were drawn
based on the analysis. Industrial PDM expert group also participated in the study
in order to validate the final conclusions so that the business relevance of the
research reports was ensured. In each of the articles (see the appendices of the
original articles), the research process of each sub-study and conclusions of the
results are presented and discussed in more detail.
The dissertation is comprised of four individual journal articles, plus this
summary. The summary is organised as follows. Chapter 2 presents the theoretical
foundation for the research. Chapter 3 summarises the research contribution.
Chapter 4 discusses the implications of the study and presents the study’s overall
conclusions.
29
2 Literature review
2.1 Theoretical framework
Business can be viewed from different viewpoints, such as the customer, the
process, organisational functions, etc. Product lifecycle management (PLM) takes
a product focus on business (Stark 2005). These days, PLM is a concept that
provides full support for managing products from their early phases until
retirement (e.g. Terzi et al. 2010, Sudarsan et al. 2005). It has shifted from
traditional engineering-focused PDM towards an integrated business management
approach that covers people, processes, and information systems that deal with
products (e.g. Terzi et al. 2010, CIMdata 2002). PLM covers the complete
lifecycle, including several processes and stakeholders, which makes it
challenging to implement (Batenburg et al. 2006). Consequently, when a
company takes this kind of general viewpoint for a matter that is traditionally
handled in a limited manner, it can even be difficult to define the basic issues.
This theoretical review focuses on covering the key concept in order to study
company-wide product data management. Furthermore, this review takes different
viewpoints of the concepts of product, product data and its management, and also
how internal stakeholders utilise the former. The context of the theoretical study
is presented in Figure 4.
Fig. 4. Theoretical framework.
30
This theoretical review discusses products and their multidimensionality in the
context of product data management. The review includes an examination of the
nature of products and their lifecycles, but also products as informational objects.
The multiple meanings of a product and product data complicate the discussion
on product data management, which has not been systematically examined in
earlier studies.
A number of studies have discussed product data management (e.g.
Saaksvuori & Immonen 2008, Forza & Salvador 2007, Crnkovic et al. 2003, Liu
& Xu 2001). The focus of this theoretical review is limited to the basic principles
of PDM, with the intention of understanding the nature of product data and its
role during a product’s lifecycle and related processes. The emphasis is on
gaining knowledge of how product data can be presented in such a way that it can
be better utilised throughout a company. Information systems have an important
role as the main enablers of PLM (e.g. Lee & Suh 2009, Rangan et al. 2005).
However, this literature review does not cover the diverse information systems, as
such. Systems alone cannot solve the organisational challenges; they only support
operational and managerial execution. Information systems are the basis of this
theoretical foundation as they relate to the product and product data management,
but are not handled as a separate section in the theoretical review.
This dissertation aims to clarify the concept of company-wide product data
management. The company-wide aspect is understood here through different
internal stakeholders. Here, the stakeholder approach covers the business
processes and lifecycle aspect. This involves examining the organisational players
that handle product and related data in diverse business processes throughout the
products’ lifecycle. This dissertation does not include the external (extended
company) stakeholders under the review or customer viewpoint to a product and
related data.
The limited focus on engineering data handled in the product development
and manufacturing phases does not make it possible to achieve the objectives of
PLM. To better discuss PLM-related systems, practices, and organisation, it is
necessary to understand the basic concepts from a company-wide perspective.
Developing the company-wide understanding of PLM and related product data
management issues accelerates companies’ learning curve and PLM adaption.
31
2.2 Multidimensionality of a product
2.2.1 Defining the product
The term product is commonly defined as a thing that is made to be sold
(Cambridge Online Dictionary 2011, PDMA 2006). It can be goods, services or
knowledge that are sold. Products can be tangible, physical goods, or intangible,
such as services, or a combination of the two (e.g. Cooper 2001, Ulrich and
Eppinger 2000, Urban and Hauser 1980.) Some scholars separate the concepts of
product and services (e.g. Bebko 2000, Zeithaml & Bitner 1996) whereas others
consider services to only be one type of product (e.g. Saaksvuori & Immonen
2008, Stark 2005). The business environment has changed recently and even
traditional manufacturing companies are providing a product type called solutions;
that is, products that combine physical goods and services (Baines et al. 2009,
Gebauer et al. 2005).
The term product has various meanings. STEP (Standard for the Exchange of
Product model data) defines a product as both the deliverable product for a
customer as well as the sub-parts of the deliverable item (ISO 1994). The term
product also refers the product type as well as the individual serial-numbered item
delivered for a customer (Peltonen 2000). Product can be also understood from
various stakeholder viewpoints. The customer experience of a product is different
for a module manufacturer or than for a maintenance provider (e.g. Stark 2005).
As seen, the term product can be understood in multiple ways (Peltonen
2000). Therefore, this study does not aim to provide the “correct” definition for a
product; instead, the term is used here with the following meaning:
Product is defined as hardware, software, services or some combination of
these elements. Product also contains documents any of earlier defined cases.
Product is understood as a portfolio item and not an individual serial-
numbered item.
Products also have an informational aspect that is becoming more critical as
business processes rely increasingly on information systems. Informational
products represent a deliverable product in applications (Liu et al. 2009). The
product data model has an important role in the building of an informational
product (Vanderfeesten et al. 2011). The informational aspect of a product is
covered more in Chapter 2.3 as part of the discussion of product data.
32
2.2.2 Different iterations of a product
Companies today face the continuous need to provide new products to the market.
This is often handled by developing new version of existing products or creating
new variants that satisfy various customer needs (e.g. Pine 1999, McKay et al.
1996). In order to avoid confusion, it is important to understand the difference
between a product version and a product variant.
New product versions are created to improve some part of an original product
– often to reduce costs, improve quality or product performance. A new product
version replaces a previous older one (Westfechtel et al. 2001, Wilson & Norton
1998), which means that the amount of deliverable products is replaced rather
than increased.
Products are often revised several times during their lifecycle after product
release, which generates a new version to be managed in information systems
(Stark 2005). This creates an extra challenge in the form of keeping track of all
the different types of versions related to deliverable product, sub-modules and
components. Therefore, version management, and especially version
compatibility, can be a challenging task especially when the amount of product is
high (Stark 2005, Crnkovic et al. 2003).
Different product variants satisfy different sets of requirements (McKay et al.
1996). Variants effectively enable product customisation when it is not viable to
produce a unique product for each customer (Lim et al. 2011, Aldanondo &
Vareilles 2008, Pine 1999). Product variants extend the amount of deliverable
items and those that exist in parallel (Wilson & Norton 1998). A variant is a group
of alternatives of which only one is selected for the final deliverable (Pulkkinen
2007).
Product configuration is widely seen as a quick and inexpensive response to
customisation needs (Hvam et al. 2008, Zhu et al. 2008). Product configuration
can be understood as a way of reacting to customer requirements by compiling a
fixed set of pre-defined components that are defined on product design phase (e.g.
Saaksvuori & Immonen 2008, Forza & Salvador 2007, Sabin & Weigel 1998,
Tiihonen et al. 1998b). These pre-defined components are variants, options, and
rules and constraints to configure a product (Cheng & Wang 2009, Tiihonen et al.
1998a). Variants and options guide the customer’s choice.
33
2.2.3 Product complexity
ICT products are typically complex in nature (Lehto et al. 2011, Möttönen 2009
Steinmueller 2001). This complexity can be seen as a consequence of rapid
technological development that enables embedded systems, a short technological
lifecycle that drives redesigning existing product, and services that keep products
alive and active longer. (Saaksvuori & Immonen 2008, McGrath 2001, Meyer &
Zack 1996). Products that combine hardware, software and services are making
production and maintenance more complex (Crnkovic et al. 2003). This study
does not discuss customer-perceived product complexity, which has been widely
studied in the field of industrial marketing (see the review by Zhang & Reichgelt
2006). The focus of this part is to discuss product complexity and how it affects
operational processes.
Product complexity is often considered to mean the technical complexity of a
single product. The technical product complexity includes the number of parts,
the number of different types of parts, the number of interconnections and
interfaces, and the number of the performed functions of an end product (e.g.
Vesterby 2008, Closs et al. 2008, Crnkovic et al. 2003, Harter et al. 2000, Novak
& Eppinger 2001, Pugh 1991). The diverging customer requirements are realised
by customised components, embedded software, and client specific integrations
(see Saaksvuori & Immonen 2008, Hobday 1998) that makes the product even
more complex in nature. In order to manage the complexity of customised
products, the hierarchical level of customisation or special integrations and
installations should be carefully studied and defined (Vesterby 2008, Hobday
1998).
Companies that only handle single products are rare. Therefore, product
complexity can also be approached from a logistical complexity viewpoint
(Khurana 1999). Companies eagerly try to meet diverging customer needs by
offering a large range of product variants and customised solutions, which results
in a wide range of deliverable products (Vesterby 2008, Lamothe et al. 2006,
Kratochvíl & Carson 2005). This leads to wide product portfolios. Product
portfolio complexity is composed of single product complexity elements such as
end product technical complexity, the level of single product variation, and end
product maturity, together with production volume (Choe et al. 1997, Kotha &
Orne 1989). Handling multiple complex products means that the impact of
complexity is greater in operational processes than in product development or
sales (Hoole 2006). High complexity may also require variation in operations,
34
which increases costs (Anderson et al. 2006). However, the potential implications
of product portfolio complexity are not fully understood or recognised (Closs et al.
2008). In addition, frequent product versioning increases the amount of
administrative work required to keep every product and sub-module and part
version up to date (Stark 2005). Since the effects of product complexity are often
obscured by other difficulties (Smith & Reinertsen 1992), it is challenging to see
how product complexity actually affects operational processes. As a whole,
complexity increases on a new level when product complexity is multiplied
exponentially, since operational processes no longer handle a single product as
they do in the product development phase.
Products also have an informational aspect. The “physical” nature of a
product and its complexity is also faced from an informational viewpoint. Product
proliferation and customisation, together with increased service types of products,
have increased the volume and diversity of product data (Jin et al. 2007, Crnkovic
et al. 2003, Forza & Salvador 2002). Services such as maintenance and
consultancy require companies to keep track of products in information systems
for longer, which further increases the amount of product data in applications
(Saaksvuori & Immonen 2008). The role of product data in operational processes
increases when business relies on information systems. Huang et al. (2003, 2005)
and Johansson and Medbo (2004), for example, have stated that supply chain
performance is heavily dependent on product data and its handling. The complex
nature of products, together with vast amount of data, makes effective product
data management throughout the lifecycle a challenging task (Jin et al. 2007,
Anderson et al. 2006).
2.3 Managing product data
2.3.1 Product data management
This dissertation approaches PDM as part of the PLM concept. Several studies
have offered definitions for product data management (PDM), each with their
own emphasis. For example, CIMdata (2009) defined PDM as a business
approach to manage the complete set of product data – its creation, control,
dissemination and usage throughout the product’s lifecycle. Saaksvuori and
Immonen (2008), on the other hand, viewed PDM as including a set of tools and
methods with which to effectively manage product data. Liu and Xu (2001)
35
argued that PDM aims to manage all product data in an integrated manner,
sharing it with those who need it. The present study understands PDM as a system
perspective and defines it as follows: PDM integrates and manages processes,
applications and all kind of data that define products across multiple systems and
media (e.g. Saaksvuori & Immonen 2008, Stark 2005, Philpotts 1996).
The PDM system connects product data related to a product and process
management, providing an infrastructure for controlling and sharing data for users,
together with a related user interface (Rueckel et al. 2005, Stark 2005). PDM
systems contain at least the following basic modules (e.g. Kumar & Midha 2006,
Stark 2005):
– Information warehouse or data vault
– Information warehouse management: tracing any data-related actions
– Document management
– Configuration management
– Product structure management
– Product and workflow structure: definition modules
– Workflow and process management
– System administration management.
According to the above list, compatibility with other IT systems is an essential
element of a PDM system (e.g. Wei et al. 2009, Maletz et al. 2007).
PDM applications are used to gather data from specific software, such as
CAD, CAM and FEM, and to store and administrate data centrally (Stark, 2005).
The standard definition of product-related data is that it is key to integrating
activities in a value chain and to making application integration possible and more
functional (e.g. Giménez et al. 2008). The common definition of product data
includes creating an understanding of data collation needs in later PLC phases,
covering the end-to-end view of a product, as requested by Yang et al. (2007) and
Jun et al. (2007). According to these two authors, PDM and PLM technologies
also involve other challenges. For example, current technologies are not capable
of providing reasonable solutions to support the increasing need to deliver
tailored products (Ming et al. 2007) and adequately support the integration of
products’ mechanic, electronic and software components (Abramovici 2007). In a
complex product environment, the diversity of data formats, such as free text,
structured and semi-structured data and combinations of these, together with
variety of data sources, creates a challenge for data management within integrated
systems (Feng et al. 2009, Yang et al. 2009).
36
2.3.2 Defining product data
The definition of product data in the literature is somewhat ambiguous. In the
PLM context, the term is widely understood to cover all product-related
information that is required to design, produce, sell, deliver and maintain a
product (Fensel et al. 2001, Liu & Xu 2001). Some researchers have specified
that product data can be further divided into product definition data, product
lifecycle data and metadata (Saaksvuori & Immonen 2008, Halttunen &
Hokkanen 1995). Here, product definition data includes exact technical data as
well as abstract and conceptual information about the product, whereas product
lifecycle data identifies the product’s stage in the order-delivery process.
Metadata is information about information used for data management purpose: it
describes the type of product data, its location, and practicalities related to
recording and accessing it (Saaksvuori & Immonen 2008). Since the present study
aims to clarify the content of company-wide product data management, the focus
is on product definition and product lifecycle data; metadata is not further
discussed here.
Product data can be also classified as static and dynamic data (Scheidt &
Zong 1994). Static data is related to the product definition and provides details
about factors such as materials, components and suppliers, product configuration
options, and operational instructions. Generally speaking, static data is created
during product development and usually remains unmodified throughout the
product’s lifecycle. Dynamic data, on the other hand, occurs in different order-
delivery processes, covering the patterns of use, environmental conditions, and
service actions such as part replacements, for example. (Yang et al. 2007,
Hribernik et al. 2006, Simon et al. 2001). Dynamic data includes transactional
data of an individual product item, which is not typically managed under PDM
but in ERP, and similar kind of systems (e.g. Saaksvuori & Immonen 2008).
A new viewpoint for product data is presented under the master data
management discussion. These studies represent a term product master data that
includes (but is not limited to) data such as product descriptions, product item
codes, weight, price and supplier information, as well as product configuration
options (e.g. Snow 2008, Zhang et al. 2004, Nagi 2001). In addition, the master
data is static in nature (White 2007) and remains fixed over a specific period of
time (Loser et al. 2004). These characteristics are similar to the previous
representation of static product data. The master data is typically reference data
37
for transactional data, which means it is used widely across an organisation (e.g.
Otto & Hüner 2009).
However, there are other types of product data that cannot be called master
data, even if they are static in nature. Typical examples include product
specifications such as BOM, technical drawings, and functional models of a
product (e.g. Zhang et al. 2004, Vroom 1996). Some studies have expanded the
contents of product-related data to cover logistic data such as lists of packing
materials or packaging instructions, user guides and engineering change
information (Saaksvuori & Immonen 2008, Crnkovic et al. 2003, Liu & Xu 2001,
Vroom 1996). Some of this data is often informal in nature and is managed by
single disciplines, resulting in unnecessary complexity (Lee et al. 2006).
Based on earlier viewpoints, the term product data is used here with the
following meaning:
Product data is data that is broadly related to a product. Product data
ensures that a company produces, delivers, sells and maintains the correct
products. Product data compounds product master data and product-related
data. Product data is static and does not contain any transactional data (such
as a product’s sales record).
2.3.3 Identifying the content of product data
A lot of product data is created, changed, transferred, stored and converted during
the product lifecycle and is used in daily operations (Lee & Suh 2009). The
definitions of a product data do not describe the actual content of product data.
Few studies have discussed the content of product data. It is challenging to define
the content of product data due to the fact that it is not a standardised concept, is
scattered across an organisation and utilised and created in different business
functions (White 2007, Sudarsan et al. 2005).
Literature reviews of product data contents have been unfruitful and a
systematic review is somewhat impossible due to the fragmented field of studies.
Vroom (1996) is one of the few researchers to have determined and concluded the
different aspects on product data, including the following content:
38
– Product identification code and product name
– List of parts, materials, drawings, testing manual, technical design data
– Parts of product prototype
– Conception of production process design, tooling, inspection guidelines
– Logistics data, such as the number of products per box, transportation
package, description of packing materials, packaging instructions
– Product target price.
One way to obtain ideas about the content of product data is to analyse other
studies from a product data content viewpoint. However, such an approach is
laborious and actually results in a reviewer’s perception of what product data
content might be, rather than being articulated by the original authors. For
example, an analysis of Ulrich and Eppinger’s (2000) description of product
development and related data contents revealed the following product data
elements: product specification, technical drawings and 3D models, functional
model, BOM, guidance for manufacturing and layout of the modules, packaging
design, detail information on individual components, parts, and descriptions of
sub-modules and assemblies. However, this analysis is limited to the product
development phase only. An analysis of Crnkovic et al. (2003) enables the above
list of product data content to be complemented with user manuals and brochures,
SW documentation and source code. However, this kind of analysis should make
for multiple studies in order to cover the full lifecycle perspective.
In addition, only a few case studies also list some examples of product data
contents. Lee and Suh (2009), in particular, represent the EOL data that has been
defined to contain information on different EOL activities (remanufacturing,
repair, recycling, and dispose), legislative information, corporate policies for EOL
activities, as well as market analysis (repair cost vs. market price). Liu and Xu
(2001) took an engineering-oriented viewpoint of product data. They defined
product-related data as typically containing engineering change orders, product
geometry, engineering drawings, project plans, part files, assembly diagrams,
product specifications, analysis results, and BOM, among other things. Johansson
and Johansson (2004) provide examples of what product data is required to design
a material supply system. Most critical data for that purpose is component-related
data (how components should be handled and basic data about components) as
well as product structure data (which product components are linked to). However,
other research covering the other order-delivery process related actions and their
data needs is rare. According to Lee et al. (2006), it is difficult to articulate the
39
specific product data needed to fulfil certain operational tasks. When defining
product data, organisations encounter many problems because the product data
has different forms based on the traditional silo thinking, data is fragmented, and
there are no standards for product data (Feng et al. 2009, Russom 2006, Sudarsan
et al. 2005).
Earlier studies provide some examples of the actual content of product data.
Aforementioned examples describe some product data contents, such as product
identification, construction of a product, procurement, logistics and EOL
activities. However, it is very difficult to create a holistic view of product data
content throughout the lifecycle based on the literature.
2.3.4 Product structure as a way to model a product and product data
The informality and tacitness of product data complicates the creation of a formal
and structured presentation of it (Lee et al. 2006). There is a clear need to have a
common product data model throughout a company in order to efficiently manage
product data in information systems (Sudarsan et al. 2005, Svensson &
Malmqvist 2002, McKay et al. 1996). However, it is difficult to create a product
model that fulfils the need for an understandable product model for both humans
and computers (Crnkovic et al. 2003) that could support the formalised
presentation of a product over a company.
Some earlier studies (Saaksvuori & Immonen 2008, Hvam et al. 2003,
Andreasen et al. 1996) have presented the idea of utilising product structure as a
product data model. Product structure is kept in a way that can be utilised
throughout a company in order to standardise the understanding of a product (e.g.
Sudarsan et al. 2005, Svensson & Malmqvist 2002, Pikosz & Malmqvist 1996,
McKay et al. 1996). Product structure is also utilised in some information
systems as a product model (Janardanan et al. 2008, Forza & Salvador 2002). In
order to manage products in applications that support product handling, the
information related to a product should be structured appropriately (e.g. Jørgensen
2006, Crnkovic et al. 2003). For example, in the case of configurable product, a
general product structure is represented as being a typical way to describe the
product and its arrangement of ready-defined parts (Cheng & Wang 2009).
Product structure represents the product, data linked to the product, as well
as the relationship between product components (Saaksvuori & Immonen 2008,
Zhang et al. 2004, Svensson & Malmqvist 2002). The present study visualises
40
product structure as a triangle, including its components (rectangles) and their
simplified relationships (Fig. 5).
Fig. 5. Visualisation of product structure.
Product structure is more complex than BOM, so they are not synonyms. BOM
presents a single product breakdown structure, while a product can have several
common structures for different purposes (e.g. manufacturing or maintenance)
(Svensson & Malmqvist 2002, van der Hamer & Lepoeter 1996). These structures
can be also referred to as views of a product for different functions, such as
product development, sales, production or maintenance (e.g. Hilletofth &
Eriksson 2011, Saaksvuori & Immonen 2008, Shu & Wang 2005, Svensson &
Malmqvist 2002, Andreasen et al. 1996). Johnston and Clark (2008) argued that
different views are needed in order to define, for example, how customers, sales
and production perceive the product that can be either tangible or intangible, and
how these views are actually connected.
Examples of these types of views of product structure are listed in Table 3.
Consequently, the product structure, as a product representation, is seen as
standardising the understanding of a product between different functions.
However, product structuring work is seen to be challenging to realise (Andreasen
et al. 1996), even though it is seen to be beneficial in order to improve developed
solutions and knowledge reuse, experience-based database creation, or supporting
engineering change management (ECM) (Svensson & Malmqvist 2002,
Andreasen et al. 1996).
Product
Components
41
Table 3. General product structure views (Kropsu-Vehkapera & Haapasalo 2012
published by permission of IACIS).
Author Product structure views
Andreasen et al. (1996) Production, Sales, Use, Maintenance, Disposal
Svensson and Malmqvist (2002) Master structure including following views:
Design, Manufacturing, Purchasing, Sales, Service
Shu and Wang (2005) Conceptual design: Product function and product module view
Product engineering design
Product manufacturing: process planning, procurement, manufacturing
and assembly models
Service and support: sales, recycling, and service models
Saaksvuori and Immonen (2008) Definition, Design, Sales, Manufacturing, Service
Product structure can also be examined through different product item types for
different purposes. A sales item defines the product marketed to a customer.
Deliverable items describe the product to be delivered to a customer, including
user manuals, end products and accessories. Source items define sub-modules,
source codes and the like. (Jansen et al. 2005). Figure 6 demonstrates the different
potential views derived from product structure. Stakeholder specific views can be
drawn (A); alternatively, different item category views can be drawn (B) (Jansen
et al. 2005, Svensson & Malmqvist 2002, Andreasen et al. 1996). However, there
is a lack of practical examples in the literature, which has not discussed the actual
content of the specific views.
Fig. 6. Views of product structure: (A) Stakeholder-specific views, (B) Item-type-
specific views (Kropsu-Vehkapera & Haapasalo 2012 published by permission of
IACIS).
Product
Sales
Manufacturing
ServiceProduct
Sales item
Deliverable item
Source items/components
A B
42
2.4 Internal stakeholders – creators and users of product data
2.4.1 Product lifecycle
Product lifecycle (PLC) is often used to refer the phases that a product goes
through during its lifecycle. The most typically used PLC model is an S-shaped
curve with the function of sales and time in the phases of product development,
growth, maturity, and decline (e.g. Levitt 1965). This traditional PLC model has
long supported marketing executives’ product strategy decisions (Stark 2005,
Birou et al. 1998). There are other PLC models as well. Stark (2005) represents a
five-phased PLC model that varies by the actor perceiving PLC. The first three
phases – imagine, define and realise – are always the same when two last phases
differ depending on the viewpoint. From the manufacturer perspective, for
example, those phases are referred to as the support/service and retire phases,
whereas customers examine them as use and dispose phases. Across these phases
are activities such as product design, sourcing, testing, manufacturing or
maintenance. According to CIMdata (2002), the overall PLC is made up for three
interacting lifecycles: product definition, production definition, and operational
support. In the PLM context, the product definition lifecycle is the primary
lifecycle containing the full set of product data that defines how a product is
handled in different processes, such as design, manufacturing, or service. Kiritsis
et al. (2003) studied the data gathered throughout PLC. They characterised a
systems lifecycle for three phases: beginning of life (design and production),
middle-of-life (use, service and maintenance) and end-of-life (recycling).
Product data management applied during the PLC is the means by which the
product is controlled through the processes where the product is handled.
Consequently, many studies that discuss product data management and PLC (e.g.
Lee & Suh 2009, Saaksvuori & Immonen 2008, Sudarsan et al. 2005, Thimm et
al. 2006) follow the process-based view for PLC. However, they do not use
exactly the same terminology for the processes included in their PLC view. For
example, Thimm et al. (2006) highlighted the manufacturer’s viewpoint to
identify the PLC stages, whereas Kiritsis et al. (2003) and Saaksvuori and
Immonen (2008) represent PLC processes on a more general level.
In a modern company, product data has become an important resource,
especially when business shifts from product delivery to product support (e.g.
Baines et al. 2009, Gebauer et al. 2005, CIMdata 2002). The majority of product
data is created during the product development phase (Sudarsan et al. 2005);
43
during the other phases of PLC, a lot of product data is used, changed, transferred,
stored and converted by a diverse range of stakeholders (Lee & Suh 2009).
PDM has long focused on engineering data management, which has led to the
fact that PDM mainly supports product development actions (Abramovici & Sieg
2002) and there is still a lack of coverage of the whole PLC-wide PDM (Lee et al.
2008, Ameri & Dutta 2005). It has also been argued that the current applications
that should cover the whole PLC are not mature enough (e.g. Stark 2005). PDM
solutions are often based on the desires of one discipline (most commonly product
development) (Svensson & Malmqvist 2002), which means they do not meet the
requirements of other functions that create and use product data in different ways
(Sudarsan et al. 2005). Therefore, companies are limiting the use of applications
mainly to product development purposes (Stark 2005, Abramovici & Sieg 2002).
Consequently, the product-related data flow is less complete during the product’s
middle and end-of-life phases (Kiritsis et al. 2003).
2.4.2 Business processes and key stakeholders
In order to obtain the benefits promised by PLM, companies must integrate all
relevant data and processes that handle products (Shu & Wang 2005). In practice,
this means recognising all the stakeholders that create or use product data
throughout PLC or the processes in which the product is handled (see Figure 7)
(e.g. Sudarsan et al. 2005). The key business processes in which a product is
handled are product process and order-delivery process (see, e.g. Saaksvuori &
Immonen 2008). In order to recognise the relevant stakeholders, various aspects
for product structure can be utilised (see Table 3). In sum, handling product and
related data includes product development and product maintenance, whereas in
order-delivery functions include sales, production, and after sales services. The
product process generates and maintains the portfolio product whereas deliverable
product individuals are handled in the order-delivery processes. (e.g. Terzi et al.
2010, Saaksvuori & Immonen 2008).
44
Fig. 7. Business processes and stakeholders handling products.
Technically, product development can design and manage one complex product.
However, product and related data management becomes more challenging in
order-delivery processes in which a series of products are handled simultaneously.
(Ebert & de Man 2008, Kratochvíl & Carson 2005, Forza & Salvador 2002). In
order to effectively handle order-delivery process and manage products digitally,
product data needs to be correct and in the correct place (Lee & Suh 2009,
Saaksvuori & Immonen, 2008). However, organisational barriers that promote
functional orientation are still very much alive. Consequently, operations and
applications do not support the idea of smooth data flow through the order-
delivery process (Anderson et al. 2006).
2.5 Theoretical outline for analysing company-wide product data
management
The theoretical study provides an outline for the analysis of company-wide
product data management. The outline includes a definition of the key
terminology used later in the study, as well as representing a framework for
analysing product data from different stakeholder perspectives. Therefore, the key
concepts will be defined as follows:
Product is defined as hardware, software, services or a combination of these
elements. Product also contains documents related to any of earlier defined cases.
Product is understood as a portfolio item rather than an individual serial-
numbered item.
Product data is data that is broadly related to a product. Product data ensures
that a company produces, delivers, sells and maintains the correct products.
Product data compounds product master data and product-related data. Product
Product processProduct development
and product maintenance
Order-delivery process
Sales, Production, After sales services
Portfolioproduct
Deliverable products
45
data is static and does not contain any transactional data (such as a product sales
record).
Product structure is a product model that represents the product, data linked
to the product and the relationship between product components.
Stakeholders are the parties that create and utilise product data. In this study,
the key stakeholders are product development, product maintenance, sales,
production and after-sales services.
Traditionally, PDM studies have focused on product development and related
activities, with less attention being paid to PDM in other lifecycle phases, even
though it has been stated that poor PDM practices have a clear influence on
operational processes as the number of deliverable products has dramatically
increased, further increasing product data (Jin et al. 2007, Anderson et al. 2006).
In order to achieve the true management of product data across a company, all the
relevant stakeholders and their product data requirements must be addressed. It
must be taken into account that the views for product data can be divergent. This
divergence can be modelled via a product structure, which is a natural way to
model a product. The product structure may also help formalise a product from
diverse stakeholders’ viewpoints. As defined above, product structure also
represents the relationships between the product components. The applications
that store the data on product are covered in this context since that is where
product data exists. Figure 8 summarises these elements.
Fig. 8. Key components of company-wide product data management.
This dissertation focuses on analysing relevant product data for different
stakeholders. Figure 9 represents the framework used for that purpose. The
stakeholder analysis for PDM purpose is steady construction. Once the
stakeholders are identified, the actual product data content can be analysed.
Product structure is a way to model product and related product data, but can also
Applications that manage product data
Stakeholdersthat use product data
Product dataProduct
Sales
Manufacturing
Service
Product structure
Productobject that is handled
Real world
Information world
Form of appearance Conceptual model
Hierarchy
46
be utilised as a model to develop diverse stakeholder views since not all product
data is relevant for all stakeholders.
Fig. 9. Creating a stakeholder-specific view of product data (Kropsu-Vehkapera &
Haapasalo 2012 published by permission of IACIS).
Stakeholders
Product data
Product structure
Utilise Gives hierarchical organisation
View
Taking stakeholder specific view to product data
47
3 Research contribution
3.1 Key challenges on managing PDM in ICT companies
Articles I, II and IV address research question 1, with all of those articles
discussing the product data management challenges encountered in ICT
companies. Article I contains general challenges related to product data
management and related practices. Article II analyses the practical PDM
challenges experienced by operational actors, while Article IV discusses
challenges relevant for product configurations required to address the varying
needs of different customer groups.
Developing a PDM system is a topical issue in ICT companies. The results of
this dissertation indicate numerous challenges and Table 4 summarises key
product data management challenges experienced in studied ICT companies. The
identified challenges can be categorised as product harmonisation, processes for
PDM and information systems for managing product data.
Table 4. Key product data management challenges in ICT companies.
Challenge
Product
harmonisation
Fuzzy offering
Lack of clarity related to possible end-product combinations due to end-
products not being pre-designed and fixed and variable parts not being
properly defined
Inadequate planning of offering: designing single products instead of defining
the offering, resulting in a vast number of end-products
Operations having difficulties to handle the expanded offering
Configuration strategy and mechanisms
Case-by-case configuration instead of configuration strategy
Configuration strategy fails as unclear to which product level variation should
be designed
Difficulties in defining fixed and variable parts
Product structure
Integrating business goals and product structure
Challenges defining products
Challenges in perceiving product structure uniformly across a company
Rules for product definition
Managing product variations and product changes
Optimal number of configuration options
Realisation of modularisation
48
Challenge
Processes for PDM Defining product data ownership
Realisation mechanisms to ensure product data quality and availability
Standardising operations for product data maintenance and workflows
Ramp-up and ramp-down phases
Product changes
Workflows for version control and product coding, product definition etc.
End-to-end view in all product data processes
Defining relevant stakeholders
Information systems System-related challenges
Multiple non-integrated data systems for product data causing manual work
Connections to customer and suppliers
Support for managing product portfolio
Product data
Understanding the real value of information
Recognising key stakeholders and their data needs
Common company-wide understanding of product data
Product harmonisation
According to the results of this dissertation, harmonising a company’s product
range is one of the key issues in developing a PDM system. The main challenges
in product harmonisation are seen to be fuzzy offering, configuration strategy and
mechanisms, and developing general product structure.
Due to the multiplicity of customer needs on and product complexity, there is
a vast number of possible product variations. Consequently, customers are being
offered products that have unambiguous realisation to internal stakeholders.
Companies are not pre-designing their product variants adequately, and it is
unclear which elements are fixed and what can be configured. This results in fuzzy
offering; that is, different understandings within a company about what can be
sold. Also, the consultants interviewed for this study felt that a company with a
common view of products across the entire organisation would be seen as an
exception, even though the common view should be the starting point of defining
offered products, and only after that should attention turn to the composition of
products.
It is practically impossible to manage an overly extensive product portfolio in
operational processes. Sales, product development and production might not have
a common understanding of a complex product portfolio and its management. At
the point of sale, sales personnel are not able to perceive all of the information
49
relevant to a vast product portfolio, which results in customer offers being
prepared without considering what is optimal for the business. Also, after-sales
services may encounter problems related to software updates, spare parts and the
like. In addition, it can be challenging to test the functionality of all possible
options.
Defining configuration strategy and mechanisms is a key challenge for the
management of configurable products. Companies find the current situation to be
confusing, as numerous configuration needs are addressed on a case-by-case basis.
It is also unclear for companies how to optimally manage configuration
parameters and their interdependencies. All the interviewees appreciate the
potential benefits of systematic configurations; that is, improved quality of
products and services and operating efficiency. Nevertheless, it is unclear to what
level in the product hierarchy the configurability should be built in and which
hierarchy level is optimal for the company to realise customers’ wishes for
variation. Currently, products are typically configured using different mechanisms,
which makes them laborious to manage. In addition, the interviewed companies
almost exclusively ignore services and configuration, covering only the physical
product. This results in service provision not being fully repeatable and,
consequently, the situation not being economically optimal.
Product structure is seen as a model that unifies and helps the general
definition of a product to be perceived. The results of this study indicate that
companies do not have a clear enough understanding of what a product structure
could mean in their specific case. However, some of the companies have already
seen some of the potential of product structure, and some interviewees considered
it as a prerequisite for realising configurations. Companies have been unable to
define optimal product modularisation, mechanisms for realising variations, and
variation restrictions. Current product structure solutions are seen as inadequate to
simultaneously support different type of products. The interviewed consultants
felt that it typically takes several years for companies to appropriately model their
products and relevant realisation mechanisms. Companies tend to consider
product structure from a technical perspective, overlooking the business aspects.
Processes for PDM
According to the results of this dissertation, well functioning processes are
another key issue in developing a PDM system. In many of the studied cases,
there are ongoing efforts to develop product data management at a practical level,
50
including PDM processes and information systems. A key driver for developing
PDM processes is to ensure better product data quality and availability. The
bigger an organisation is, the more laborious it is to keep product data up-to-date,
even with automated actions. Inevitable manual work includes data entry into
systems and content checking, which runs the risk of human error. Practical
product data challenges at the operational level indicate practical weak points as
data being incorrectly entered into the systems or systems not replicating the data
to different applications. Especially challenging is to manage data entry during
product ramp-ups and ramp-downs. Complex products typically change many
times after their first release, and it is critical to establish new versions and have
compatibility between different versions in order to ensure smooth product
management in information systems. The interviewed companies have attempted
to prevent this type of product data challenge by defining data ownership. Each of
the studied companies has defined the basic principles for data ownership. Data
responsibilities are typically allocated according to organisational units and
related business responsibilities. However, despite efforts to define data
ownership, this is seen as being very challenging in practice. Typically,
responsibility for correcting incorrect data in the system is unclear. The results
indicate that centralised PDM solutions are considered necessary to support
business operations in a multi-site global environment when the speed of data
transfer and on-time data availability is essential.
Information systems
Information systems are the third key issue identified here as being significant for
developing a PDM system. Information systems play a key role in managing
product data, which makes them central to supporting PDM processes. Multiple
non-compatible information systems are typically used for PDM purposes, which
makes data transfer laborious, requiring unproductive work with several data
entries. Apart from the major PDM applications, several tools such as MS Office
and CAD, are used to create product data. In fact, product data is also stored and
utilised by systems such as sales configurators, ERP and other operational tools
throughout the product lifecycle. Inadequate application integration causes
manual data entry and transfer, which results in information being stored in
different forms in different data systems, thereby blurring the correctness of data.
Tool integration varies among the interviewed companies but is generally seen to
be somewhat lacking. An additional challenge is staff creating their own solutions
51
instead of following created processes and applications; this increases the
probability of errors.
The true value of product data is considered to be inadequately understood,
leading to a situation in which there are no uniform practices across companies
and the needs of all stakeholders are not addressed. It is considered vital that staff
who create product data fully understand the importance of entering the data into
systems in a manner that acknowledges the needs of others. Ensuring the correct
format of data is vital to avoid unproductive work. Interviewees emphasised the
fact that personnel should understand that product data has an impact on
profitability.
3.2 Internal stakeholders and their view to product data
Article III, which addresses research question 2, analyses how product data is
understood by different internal stakeholders in different parts of a company. The
article analyses three company cases and describes their product data in a way
that is relevant for diverse internal stakeholders. One of the companies represents
a typical consumer electronics provider with rather stable PDM traditions. The
second company provides service products, that utilise heavy infrastructure, and
takes the first steps towards developing PDM practices. The third company has
complex products, which makes product data management difficult. The third
company is currently moving towards solution business.
The results indicate that product data is typically observed and defined from
the product development and product data maintenance viewpoints. The studied
cases show that product development creates the basic product data content, while
specialised product data teams are responsible for maintaining product data in
later phases of the product lifecycle. These specialised teams are responsible for
product change and compatibility management in organisations where product
data practices are more advanced. Product data is widely needed in operational
processes across companies, even though it is mainly created by product
development. Different stakeholder groups require different product data to
complete their duties.
Key stakeholder groups using product data typically include sales, production
and after-sales. These organisational key units that utilise product data are similar
in all the studied cases. It is noteworthy that the sub-division of these main groups
into smaller entities may not be identical in different companies. For example, in
a company that only provides services, after-sales is a part of production. The
52
results indicate that production is typically sub-divided into sourcing,
manufacturing and delivery when considering product data.
To some extent, product type influences the stakeholders. In the case of
hardware products, demand/supply planning is one of the key production
stakeholders. The nature of the production process and relevant stakeholders are
slightly different in the case of service products. For example, in the case of
service products, the after-sales services are usually experienced as part of service
provision, not as a separate process as is the case with hardware products. Billing
was introduced by one key stakeholder in a studied service case whereas in other
cases it is not commonly linked to be main product data consumers.
In summary, the key internal stakeholders needing product data in their
operations include:
– Sales & Marketing
– Sales (customer interface)
– Sales support
– Production (Service provision)
– Demand/supply planning (HW)
– Sourcing
– Manufacturing (HW)
– Delivery
– Billing
– After-sales services (HW).
Even though the main stakeholder groups are nearly identical in different
companies, it was noticed that every stakeholder group contains different sub-
organisational units that handle product data. Also, not all stakeholders are
necessarily relevant in all organisations.
In this study, product data is studied from operational stakeholders’
perspective to recognise product data content that is relevant for them. The results
indicate that practitioners see product data as a combination of business-oriented
product master data and other general product data that has a more practical role.
Product master data is also seen to include the data system information required
to run the business. Consequently, any flaws in this information have a direct
business impact. Product master data is generally created during product
development. Other general product data ensures that operations are carried out in
53
a predictable and efficient manner, as opposed to staff creating their own
solutions. Other general data is more versatile in nature and is currently not
systematically defined and managed.
Product master data contains information relevant for business, required for
data systems. Table 5 summarises the content of product master data.
Table 5. Basic product master data.
Class Content
Product definition Unit code, Item price
Delivery time, Country of Origin, Customs information codes, Delivering
plants, Physical dimensions (e.g. net mass and volume, material group/type)
Item type specific definitions, such as:
List of spare parts and accessories (service item)
Licence information (SW)
Product structure Decomposition of a product: parts, product structure on module, circuit board
and components level (BOM)
Component information: lead times, lot size, order frequency, prices,
hazardous material content, part manufacturer information
Product classification Searching in data systems: Object type, product group, etc.
Product change data Item revision information
Compatibility information
Configuration rules In case of configurable products, define the rules to configure a product
Product lifecycle status Released, ramp-up, volume production, ramp-down, end of life, termination,
etc.
Basic product master data includes the core product data, such as item name and
code, product lifecycle status, and product definitions. The basic product master
data is defined for every product that is created and managed in a company.
However, it should be noted that every organisation defines its own product
master data and this compilation is only an example of it potential contents. Each
stakeholder group will only have access to master data relevant for its purposes.
This stakeholder-specific master data is derived from the basic product master
data. The exact content of the stakeholder specific master data set differs between
companies based on how they define the relevant data required for business
purposes.
Other general product data defines how a product is to be sold, produced and
maintained. Other general product data may contain different types of work
guidelines and instructions for sales, pricing and product-specific troubleshooting.
The results indicate that product data is understood as a wide set of different data
54
for different stakeholder groups. Table 6 summarises the contents of other general
product data. The summary includes different company-specific views, which
have been obtained from interviews and other data sources and which cover
general product data from diverse stakeholder perspectives.
Table 6. Stakeholders and examples of their general product data requirements
(modified Kropsu-Vehkapera & Haapasalo 2012).
Stakeholder Product data
Sales & Marketing
Sales & marketing
(Customer
accounts
Configuration
personnel)
Sales package description defining sales item combinations
Commercial and technical marketing and sales material
Service pricing and customer deal instructions
Configuration guidelines: recommended configurations, marketing/sales
limitations, customer specific configurations
Delivery times and sales channels for saleable products
Specific customer discounts (customer contracts as a reference)
Customer service descriptions
Sales Support Internal work instructions for product-specific questions
Internal product guidelines, system and realisation for reconfiguring products
Production
Demand/
supply planning
Information on planning frames and possible product allocation preferences
Prioritisation instructions (work instruction)
Information on planned volume ramp-up/ramp-down
Sourcing Purchaser of an item, vendor, lead times, lot size, order frequency, purchasing
price
Mode of purchasing if original equipment manufacturer (OEM)
Delivering plant with outsourced services: service descriptions and local costs
Manufacturing Instructions: manufacturing process guidelines, item testing, etc.
Production BOM with supplier/OEM information
Delivery Packing instructions: compliance and document requirements, package
identification marking
Information on shipping lot size and guidance for picking
(Service delivery/
Project execution)
Guidance for service implementation: roles and responsibilities
Pricing reference material for profitability calculations
Billing Price list, price item and product catalogue
After-sales
After-sales
services
Product error correction plans and roadmaps
Instructions for troubleshooting, testing and system set-ups
SW correction packages and information on new SW releases
Change information for products and supporting infrastructure
55
Unfortunately, general product data is often undervalued and, therefore, not
optimally utilised. The studied cases show how the role of stakeholder-specific
general data is particularly important for service provision. Services are often
poorly defined and managed, which results in services (in particular) having the
most room for improvement.
A versatile set of general product data, such as work instructions, guidelines
and specific product descriptions, are seen to be required for successful operations.
However, based on the results, it cannot be said that the creation of this type of
data is either systematic or is even defined in the actual contents of general
product data.
3.3 Enhancing the management of product data
Articles III and IV address research question 3. Both of these articles provide
means for enhancing product data management. Article III analyses product
structure for organising product data, while article IV discusses ways to organise
product data management at a general level.
Modern ICT companies face a diverse set of challenges. Companies have to
meet competition by providing new products faster and must answer widely
varying customer needs. From a product data management perspective, the
complexity of products is increasing and, at the same time, there is pressure to
address not only single products but also product portfolios. As a consequence, it
is becoming more difficult to manage product data and the role of information
systems increases. However, one should not fall for the illusion that selecting and
implementing a data system will rectify problems. According to interviewed
consultants, companies tend to use data systems as a starting point when
developing their product configuration management. The present study indicates
that companies should follow a top-down approach when developing their
product data management practices.
The results indicate that managers of studied ICT companies considering
their configuration and product data management ought to start with business and
strategy, not by solving the challenges of single products. The results of this study
indicate that more advanced companies are already striving for this type of
approach. In particular, when handling product portfolios that include a high
number of variations, product harmonisation should start from general, upper-
level product design. Unlike more advanced companies, companies that are
unable to manage their product portfolios and product configurations have started
56
to develop their product configuration systems on a product basis. The top-down
approach is a way to clarify fuzzy offering.
Harmonising products and their management should start with product
strategy. In the case of a configurable product, for example, the results indicate
that companies should start by formulating their general configuration strategy,
followed by configuration mechanisms and rules. In order to achieve a systematic
product portfolio, logic for handling and defining products must be clear. Too
often, the starting point is challenges encountered by a single product, resulting in
different products being realised via different mechanisms. Overall, it is very
important to understand the big picture – how the selected mechanisms, such as
configuration, affect operational processes. The logic for handling and defining
products also influence information systems. If products are configured using
different logic, diversifying applications, such as configurators, are required.
The results indicate that companies need a generic product structure to
support unified product management. A general product structure is seen as
helping formalise products and how they are understood across a company. A
general product structure is seen as a way to minimise the number of new
products and related data. General product structure also helps define all of the
different variants, thereby tackling the fuzziness of the final offering.
Since the companies are already familiar with the concept of product
structure and utilise it to define their products, product structure can also be
utilised to support product data management. General product structure can be
utilised to build separate views for different stakeholder groups. Product structure
also helps create a common understanding of a company’s products and product
data.
Figure 10 illustrates a general product structure and stakeholder-specific
views for a product. This is a compilation of three company-specific product
structures. It is built to represent a product that includes all different product types,
hardware, software, service and documents.
57
Fig. 10. Example of product structure and stakeholder specific views (modified
Kropsu-Vehkapera & Haapasalo 2012.
58
The stakeholder-specific views in Figure 10 show product levels for each
stakeholder group’s practical work. These stakeholder-specific views match with
the product data requirements presented in Table 6. The sales view covers
descriptions of saleable parts of the product, while the production view covers the
technical product aspects, including detailed description of SW and HW items.
Since the practice seems to be that service items are not versioned and their
composition is different, service items are represented separately from SW and
HW items.
The production view can be further divided into delivery, sourcing and
manufacturing views. The manufacturing view differs from the total production
view in that it does not include any raw materials such as SW components that
can be included in total production view. In the case of services, manufacturing
means producing the service. The after-sales service view consists of HW parts
that are maintained or updated with software. In this case, the demand/supply
planning view is also included. Within service products, the after-sales service
view includes maintaining the sold services and therefore understanding the
connection of sold sales items and ensuring the availability of required resources.
However, the example figure does not include all these stakeholder views (such as
demand/supply planning or billing) since the content of those views remains
unclear.
All product types, including hardware, software, service and documentation
elements, can be illustrated using this framework. However, the model is also
adequate when the final product only contains HW, SW or service. It should be
noted that the requirements for product structure are strongly company-specific.
In order to define stakeholder-specific views and related data contents, a general
product structure is required.
Defining stakeholder specific views on relevant product data for different
stakeholder groups helps improve product data management and product handling
practices. Figure 11 illustrates the common denominator for all the cases and
stakeholder groups. This illustration provides a framework for companies for
defining stakeholder-specific views. All product types, including hardware,
software, service and documentation elements, can be illustrated using this
framework.
59
Fig. 11. Stakeholder-specific view content (Kropsu-Vehkapera & Haapasalo 2012
published by permission of IACIS).
In order to utilise this framework, a company must first define a general product
structure. Structural illustrations are direct stakeholder specific subsets derived
from the general product structure. The stakeholder-specific product master data
and other general data are discussed in more detail in chapter 3.2.
3.4 Results summary
The research for this dissertation was conducted in three phases. First, key
product data management challenges encountered in ICT companies were
clarified. Second, relevant internal stakeholders dealing with product data within
companies were identified. Finally, conclusions were reached in order to find
ways to enhance product data management. Table 7 summarises the research
contributions.
Table 7. Research contribution.
RQ Results
Key PDM challenges Identification of key PDM challenges
Product harmonisation
Process development requirements
Information systems development requirements
Stakeholders & product
data
Identification of key stakeholders
Defining product data content for different stakeholders
Product data = product master data + other general product data
Enhancing product data
management
Top-down approach
Business- and strategy-driven PDM
General product view vs. single product
General product structure
Stakeholder views
Stakeholder specific view content
60
The results indicate that developing a PDM system is a topical issue in ICT
companies. PDM system development is moving towards company-wide
approaches that cover different operations. Company managers have already
realised that a higher-level understanding of products and related product data is
required for successful business operations. However, in practice, numerous
challenges hinder achieving the goal of higher-level business-driven PDM.
Product harmonisation is required to better support efficient product data
management. Fuzzy offering and deficiencies relating to configuration strategy
and mechanisms cause problems for operational-level activities. According to the
results of this dissertation, a key for product harmonisation is to model products
using a general product structure. Unfortunately, defining product structures has
proved rather complicated, as it required both general product modelling
decisions and detailed product design rules.
Developing PDM also includes considering processes for PDM and related
information systems. Key PDM process challenges include understanding product
data management as a company-wide activity and ensuring product data quality
and availability by developing product data ownership. Processes are tightly
linked to information systems that tend to suffer from integration deficiencies.
Also, it is challenging to define product data uniformly for different operations
and related systems.
The content of product data from different stakeholder perspectives is a pre-
requisite for functional company-wide PDM. Product data consists of product
master data that is relevant for business, as well as more practically-oriented
general product data. It is vital to combine business and other data that have
traditionally been considered separately.
This study indicates that higher-level product decisions have a significant
impact on product data management. Extensive product ranges require general
guidelines in order to be manageable, especially as even single products are
complex. The results of this study indicate that companies should follow a top-
down approach when developing their product data management practices.
Managers of ICT companies considering their configuration and product data
management ought to start with business and strategy, not by solving the
challenges of single products in order to harmonise their product ranges.
Harmonising products and their management should start with product strategy.
In the case of a configurable product, for example, the results indicate that
companies should start by formulating their general configuration strategy before
61
configuring mechanisms and rules. In order to achieve a systematic product
portfolio, the logic for managing and defining products must be clear.
The results indicate that companies need a generic product structure to
support unified product management. A general product structure is seen as
helping to formalise products and how they are understood across a company.
This dissertation highlights how a general product structure can be utilised to
build separate views for different stakeholder groups. Using a generic product
structure makes it possible to create a presentation in which product structure and
stakeholder-specific views for a product are interlinked. This dissertation also
presents a framework with which to define stakeholder-specific views on relevant
product data for different groups. All product types, including hardware, software,
service and documentation elements, can be covered using a general product
structure and a stakeholder-specific view framework.
62
63
4 Discussion
4.1 Theoretical implications
This study is related to the field of product lifecycle management, contributing to
the research stream of lifecycle lasting product data management. Few studies
have conducted research concerning product data management as a company-
wide action that is outside the realm of product development. Concluding the
results of this dissertation, prerequisites for company-wide PDM can be
summarised as:
– defining a harmonised product data concept over a company, potentially
exploiting product structure modelling
– understanding the true nature of product data that is a combination of product
master data and other general product data
– recognising the key product data stakeholders and their actual data needs, and
– approaching product and product data management from a top-down
perspective.
In addition, the results include different descriptions and models in order to
harmonise product data representation through a company. This includes a theory-
base model to create a stakeholder-specific view of product data as well as the
key definitions for company-wide product data management that can used to
harmonise product data representation in companies. Empirical evidence is used
as a base upon which to define the aspects of stakeholder-specific view content
and product structure and related stakeholder views.
This dissertation complements previous PDM literature (e.g. Terzi et al. 2010,
Liu et al. 2009, Saaksvuori & Immonen 2008, Stark 2005, Sudarsan et al. 2005)
by describing product data management challenges specifically in the ICT
industry (see Table 4). In particular, the results PDM challenges in cases where
products are a combination of electronics, software or services; this has recently
emerged as a topical issue in practice (see Saaksvuori 2011).
This dissertation highlights the importance of addressing and serving the
needs of different stakeholders requiring product data in a coordinated manner. In
other words, product data practices must be harmonised throughout the
organisation. Another important challenge is to approach product and product
data from a higher level rather than to solve single product-related problems, in
order to develop a long-lasting solution for PDM. Therefore, the findings of this
64
study enhance the previous, more theoretical studies (e.g. Svensson & Malmqvist
2002, Andreasen et al. 1996). This dissertation creates new theoretical knowledge
by describing the potential content of product data for different stakeholders;
however, it cannot define an all-inclusive solution. Understanding the content of
product data for each stakeholder enables efficient product data management.
Previous PDM literature has mainly viewed product data as technical data
(e.g. Liu & Xu 2001, Vroom 1996) or some other type product data (e.g. Lee &
Suh 2009, Lee et al. 2006, Johansson & Johansson 2004), but has not included
the master data aspect in definitions of product data. Product master data is
discussed separately in the master data literature (e.g. Snow 2008, Zhang et al.
2004, Nagi 2001). This dissertation creates new knowledge about defining the
content of product data by combining master data and other general product data
into product data as practitioners define the product data. Product master data
contains data that is used in data systems and is relevant for business. Product
master data contains the core product data, such as item name and code, product
lifecycle status, and product definitions. Other product data defines how a product
is to be sold, produced and maintained. Other product data may contain different
types of work guidelines and instructions for sales, pricing, and product-specific
troubleshooting. Different work instructions and guidelines relevant to specific
stakeholders are generally not discussed in the product data and management
literature; unfortunately, this data is often undervalued and consequently not
utilised optimally.
Previous PDM/PLM studies have focused on technical product data issues
(e.g. Kiritsis et al. 2003, Liu & Xu 2001). Stakeholder-specific general product
data ensures that operations are carried out in a predictable manner, which
prevents personnel from creating their own personal solutions. In contrast to
previous literature, this dissertation has shown how the role of stakeholder-
specific general data is particularly important for service provision. It is common
for services to be poorly defined and managed, which results in services and
related data management, in particular, having the most room for improvement.
Creating stakeholder-specific views requires that processes be properly analysed
and the required product data identified.
This dissertation proposes a way to utilise product structure to describe
stakeholder-specific views on product data. The previous literature presents
product structure models (e.g. Saaksvuori & Immonen 2008, Shu & Wang 2005,
Svensson & Malmqvist 2002, Andreasen et al. 1996), but does not provide
tangible instructions on how to utilise them. The present study complements the
65
previous literature by presenting possible ways to utilise product structure models
in company operations. In particular, product structure models are utilised to
create stakeholder-specific views. Stakeholder-specific views make it possible to
identify what type of product data is relevant for each actor. Therefore, this study
combines the findings of previous literature (e.g. Saaksvuori & Immonen 2008,
Shu & Wang 2005, Svensson & Malmqvist 2002, Andreasen et al. 1996) and
provides more tangible examples of how stakeholder-specific views can be
realised.
Overall, this doctoral dissertation presents a clarification for defining product
data and what type of model can be created to improve company-wide
management of product data. In so doing, the study helps consolidate a
fragmented field of product data. This study shows that companies can potentially
benefit from a more business-oriented approach to analysing and managing
product data.
4.2 Practical implications
The purpose of this dissertation is to examine the challenges and prerequisites for
company-wide product data management, especially in the ICT sector, where
products are a combination of hardware, software and/or services. These ICT
products are typically complex and there are a vast number of products and
product variants as well as different customer segments. As a result, the amount
of product-related information is greater than ever, which further complicates
PDM.
The practical implications of this dissertation include providing ICT
companies that have complex products with an overall view of PDM-related
challenges and potential solutions, as well as the necessary prerequisites for
functional company-wide product data management. Also other industries can
benefit the results especially when harmonising their products and product data
management.
This study provides new information for managers requiring new viewpoints,
as the traditional way of managing only technical product data is not sufficient to
support true organisation-wide PDM. It also requires PDM managers to widen
their scope towards the full product lifecycle, rather than just product
development and manufacturing. This dissertation shows that it is not possible to
provide guidelines that are directly suitable for every company due to the
diversity of products, processes and organisational structures. However, a
66
collective set of prerequisites can be found that better ensures product data quality
and availability during a product’s lifecycle. This dissertation offers support for
managers concerning the development of true company-wide product data
management practices.
This dissertation also highlights how product data management must be seen
to combine product management, data management, and organisational functions
dealing with product information. Consequently, solutions for managing product
data are not developed within single organisational units; instead, a functional
solution requires company-wide cooperation. Senior decision-making managers
must understand the need for cooperation.
The challenges are versatile in nature and many cannot be tackled only by
implementing a PDM/PLM application. Therefore, company managers should
abandon their traditional way of understanding product data management as an IT
issue. The IT solution should only be included once the prerequisites for
company-wide PDM have been defined. An optimal starting point for realising IT
projects would be that a company has a common company-wide understanding of
its products. This understanding acts as a requirement list for IT solutions.
It is typical for the ICT sector to tackle a number of varying customer
requests by configuring their products, which results in wide product ranges. This
study points out to product managers that a wide and complex product portfolio
also influences operational processes. The managers of ICT companies ought to
see the product portfolio as a whole in order to develop efficient product data
management practices. In practice, this requires a top-down approach, starting
from business and strategy issues related the whole product portfolio, rather than
solving the challenges of single products. The top-down approach is also a way to
clarify a fuzzy offering that has become a major challenge for ICT companies
with high product variety. Overall, it is very important to understand the big
picture – how configuration is executed in practice and how the selected
mechanisms affect operational processes. This cannot be achieved or managed
from the viewpoint of a single product.
There are many internal stakeholders within companies, all of which require
product data, even though they may have different perspectives. Companies strive
for a common company-wide understanding of their products and related data.
This study suggests utilising product structure as a base for this harmonisation.
The general product structure helps harmonise products and how they are
understood across the company. The general product structure also minimises the
number of new products and related data. In addition, a general product structure
67
helps define different product variants, which clarifies the final offering. However,
managers must note that the requirements for product structure are strongly
company-specific.
Product structure is traditionally used to describe mechanical products. This
study shows that product structure is also applicable for describing all product
types or combinations thereof. Product structure must cover all different product
types in order to systematically manage them in data systems. This dissertation
shows that a properly considered product structure also improves product data
management efficiency and makes it possible to integrate different data systems.
Managers can utilise a general product structure to enable different stakeholder
views over product data.
This dissertation indicates that companies do not adequately acknowledge
how different stakeholders have varying needs in relation to product data
management. The study presents a tangible way of building separate views for
different stakeholder groups. Managers need to recognise that company-wide
product data management requires that non-technical individuals also be
recognised as product data users and providers. Without this understanding,
functional product data management throughout product lifecycles will not be
possible. PDM managers have typically recognised the needs of product
development and production; they should also realise that other stakeholders
should be offered tailored views on product data.
This dissertation helps PLM and PDM system developers by clarifying the
true challenges encountered in current systems and proposing the use of product
structure and stakeholder-specific view approaches. System developers could
improve their systems to better serve companies wishing to use the solutions
proposed in this dissertation.
Managers need to realise that any development process will take time, as it is
not wise to jeopardise existing business relationships, current product portfolios
or functioning operations. This is also true when improving product data
management practices.
4.3 Reliability and validity
This study investigates company-wide product data management and seeks a
more in-depth understanding of this phenomenon. The empirical practitioner’s
experiences and perceptions are seen to have increased the knowledge in this field.
Therefore, the qualitative research method is justified in this study. The case study
68
method was selected since it can potentially provide a broad view of the
phenomena. As Bryman and Bell (2003) stated, the reliability and validity of
qualitative research can be assessed by answering the following four questions:
1. How trustworthy are the results?
2. Are the results valid in another environment?
3. Are the findings likely to occur at other times (repeatability)?
4. To what extent have the researcher’s own values influenced the results?
The trustworthiness of the results can be understood as the degree to which
research results correspond with the real world. In order to ensure reliability, this
research has utilised several data collection techniques and interviewed multiple
people in order to triangulate the results. The interviews were primarily made
following a semi-structured method, which enabled flexible interaction between
the researcher and interviewee and left room for interviewees to explain the issues
as they felt best. Although the interviewers did not attempt to influence the
answers of the interviewees, their impact is still worth questioning since the
discussed topics are somewhat blurry and needed to be clarified in some
interviews. Several researchers collected the research data, which decreases the
degree of researcher bias.
The representativeness of the cases is one of the main concerns in case
studies (Yin 2003). The studied cases represent the Finnish ICT sector, although
the companies act globally. The selection of the cases was based on the fact that
the case companies were developing their PDM practices. They can also be seen
to be a step ahead in terms of developing their practices in this area, which
offered a fruitful view for the topic. This means that they do not necessarily
highlight all of the types of challenges that ICT companies with complex products
may face in their PDM. Cases could always be selected differently when
resources are often the most limiting factor in the case selection.
Within each case study, the trustworthiness of each case is increased by
selecting people with different backgrounds, rather than just reaching conclusions
based on a single person’s opinion. Although the actual number of interviews in
this study was adequate, the number of interviewees in each company is quite
small compared to the company sizes. Even with this sample size, the PDM
challenges can be described within a reasonable level when the descriptions and
examples of product data are considered as the first views on what contents this
data set includes. In practice, defining the company-wide product data requires a
69
wider analysis that must be completed at the company level. Also, the overall
quantity of companies analysed in individual studies is low and the general
product structure with stakeholder-specific views was not tested on a wider
audience. Even though the results have not been tested, the trustworthiness of the
given solution can be considered relatively good, strengthening the earlier
research results as well as utilising them as a foundation for new solution. In
addition, all the results are validated by industrial experts, which means they can
be seen to correspond well with the real world.
Another issue to asses when evaluating the qualitative research is the validity
of the results in another environment. The studied phenomenon and solutions for
company-wide product data management are more relevant in companies that are
medium-sized or large. The communication of product data becomes problematic
when the organisation size and number of products increases or work is organised
in multiple sites. Therefore, PDM solutions in the studied scale are not suitable
for micro-companies since, for example, a single person can represent almost all
stakeholders using product data. However, companies that drive for growth can
use the results in a proactive way. The challenges recognised are general in nature
and are faced widely. Smaller companies can learn from the experiences of others
and avoid repeating others’ mistakes. They can also use the results as a way to
harmonise their product data.
Case studies always face the challenge of generalisability (e.g. Bryman &
Bell 2003, Yin 2003). This study includes an examination of complex ICT
products that are heterogeneous in nature, including hardware, software and
services. The solutions and preconditions are created from that sense and based
on few cases. This study does not intend to provide a full solution for
practitioners, not even of the ICT industry; instead, it describes how ICT
practitioners and other companies can approach the challenge of company-wide
product data management. The generalisability is more theoretical, providing
descriptions and models that can be applied especially in companies with
heterogeneous products. These tools may be more valuable companies that are at
least moderate in size, but not make them useless in smaller companies. The
findings do not provide a single proposition that fits all companies. Defining the
content of product data and recognising the key stakeholders and their needs
towards product data are usable in many contexts. Arguably, the suggested
product structure model with stakeholder views will be relevant in other
industries, where the convergence of different product types, especially the
addition of services with manufactured products, is topical challenge. However,
70
one must understand that the needs of each company’s product management must
be addressed by analysing their specific business realities. Even though different
types of companies were deliberately chosen, the generalisation of the results
requires further research.
Repeatability is understood in that another researcher would reach similar
findings in a similar research setting. This means that another researcher would be
able to repeat the research logic, having same data and end up same conclusions
(Yin 2003). However, it is unlikely that another researcher would be able to
obtain exactly the same research setting. The findings reflect the reality at the
time when the data was collected, which means that the ability to replicate the
research is limited (Saunders et al. 2009). One would like to believe that
companies develop their practices further, which would make the research non-
repeatable. Also, all the interviews have been unique situations, which means that
complete replication would not be possible, even when the same questions were
asked. Utilisation of case study protocol, establishment of a case database, and
multiple source of evidence can be utilised to improve reliability (Yin 2003). In
this research, the data collected has been recorded, transcribed and stored,
ensuring that the relevant evidence could be retrieved if necessary. Regardless of
this database, it is questionable whether another researcher could reach with same
conclusion, given that the role of the researcher is remarkable in analysis at the
end, despite the fact that different steps of data analysis are also retrievable. As a
researcher, one would hope that the research is objective. However, qualitative
research often has subjective connotations (Yin 2003). Qualitative research
emphasises worlds and the interpretation thereof, especially when research
utilises interviews as the main data collection method (as this study did). In order
to reduce single-researcher bias, a number of researchers collected the data for
this study. However, the data analysis is highly dependent on the researcher and
her way of thinking about the phenomena. The researcher’s previous work
experience has given her a certain mind set for the studied issue, but mostly the
presumptions and how things are valued are based on the literature study and
experience gained when preparing the research project. Therefore, in this research
project environment, the direction to the analysis would probably be rather similar.
Still, it would have been possible to select the topics of the sub-studies with a
slightly different emphasis and reaching a somewhat different conclusion.
71
4.4 Recommendations for further research
This study aims to enhance the understanding of company-wide product data
management as a way of improving PDM practices in ICT companies. In general,
few studies have sought to understand product data comprehensively throughout a
company. Therefore, this qualitative research serves to describe this research area,
as well as proposing a solution to organise product data in order to support
company-wide PDM. This study presents the preconditions for company-wide
product data management, together with more practical descriptions and models
to use in order to harmonise the representation of product data throughout the
company. The findings are preliminary in nature, presenting the aspects that
should be noticed in order to approach product data and its management holistic.
Further research is suggested in order to validate and supplement the findings.
This study suggests using the product structure with specific stakeholder
views to harmonise the product concept within a company. Since this solution has
not been tested on a wider audience and in other industries, future research could
include testing the proposed solution. The general product structure model need to
be validated in other cases and also needs more detailed extraction so that
companies can apply it more easily. Potential future research could also include
expanding the stakeholder analyses to cover external stakeholders.
This study includes recognising the stakeholder-specific product data.
However, these findings are not all inclusive. Further research is required to
create a holistic picture of product data as it is experienced by a certain
stakeholder group. This is needed in order to develop PLM to meet is full scope.
This information would also help application developers cover the required parts
of organisation and ensure that the tools really support the full organisation.
Companies often seek proven practices that could be used to save time in
order to implement new things. Therefore, it would be valuable to conduct a
longitudinal study to follow companies that have applied this type of product
structure and stakeholder-specific views approach over a longer period of time.
Future research may also include descriptive case studies on constructing the set
of stakeholders and their views. More in-depth studies are also required to show
how product data occurs in daily operational activities and how important
efficient PDM practices are also in the order-delivery process point of view.
This study is made in medium-sized and large companies, which means that
the applicability of the results for small companies is unclear in this format.
However, defining products and related product data properly is a valid issue for
72
every company. In order to prevent the product data management challenges,
more knowledge is needed regarding what is the critical point for a company to
implement a more structured approach to product data management.
Product data is more often linked to the technical, physical products.
However, current products are increasingly becoming a combination of products
and services (Baines et al. 2009, Gebauer et al. 2005). This study provides first
views that service products can also be modelled as more traditional products and
that the stakeholder-specific product data can be even more valuable for service
products. However, examples of solution product data and its management are
limited, which means that solution types of products are fruitful field of study.
In order to succeed in modern complex business, it is necessary for several
internal and external functions to have an adequate understanding of product data.
However, this dissertation focuses on PDM-related issues within a single
company and does not cover the supplier or other partner’s viewpoints regarding
product data. There would be room for further research to figure out how the
definition and practices of product data are matched when acting with external
partners and how product structuring could help such a form of collaboration.
As this section indicates, there are several appealing avenues for future
research in order to further enhance company-wide product data management.
Even though this study was conducted in the ICT industry, there are no limitations
to conducting the further research suggested above in other industry sectors,
especially where better product data has an important role in ensuring and
improving efficiency in operations.
73
References
Abramovici M (2007) Future trends in product lifecycle management (PLM). In Krause F-L (ed.) The future of product development: Proceedings of the 17th CIRP design conference. Berlin Heidelberg, Springer: 665–674.
Abramovici M & Sieg OC (2002) Status and development trends of product lifecycle management systems. Proceedings of the IPPD 2002. Wroclaw, Poland.
Ala-Risku T (2009) Installed Base Information: Ensuring Customer Value and Profitability after the Sale. Dissertation thesis, Helsinki University of Technology. Doctoral Dissertation Series 2009/6.
Aldanondo M & Vareilles E (2008) Configuration for mass customization: how to extend product configuration to-wards requirements and process configuration. Journal of Intelligent Manufacturing 19(5): 521–535.
Alemanni M, Alessia G, Tornincasa S & Vezzetti E (2008) Key performance indicators for PLM benefits evaluation: The Alcatel Alenia Space case study. Computers in Industry 59(8): 833–841.
Alter S (1999) Information Systems: A Management Perspective. 3rd ed. Reading, MA, Addison-Wesley.
Ameri F & Dutta D (2005) Product Lifecycle Management: Closing the Knowledge Loops. Computer-Aided Design & Applications 2(5): 577–590.
Anderson B, Hagen C, Reifel J & Settler E (2006) Complexity: customization’s evil twin. Straregy & Leadership 34(5): 19–27.
Andreasen MM, Hansen CT & Mortensen NH (1996) The Structuring of Products and Product Programmes. Proceedings of the 2nd WDK Workshop on Product Structuring. Delft, The Netherlands: 15–43.
Anttila P (2005) Ilmaisu, teos, tekeminen ja tutkiva toiminta. Hamina, Akatiimi. Baïna S, Panetto H & Morel G (2009) New paradigms for a product oriented modelling:
Case study for traceability. Computers in Industry 60(3): 172–183. Baines TS, Lightfoot HW, Benedettini O & Kay JM (2009) The servitization of
manufacturing: A review of literature and reflection on future challenges. Journal of Manufacturing Technology Management 20(5): 547–567.
Batenburg R, Helms RW & Versendaal J (2006) PLM roadmap: stepwise PLM implementation based on the concepts of maturity and alignment. International Journal of Product Lifecycle Management 1(4): 333–351.
Bebko CP (2000) Service intangibility and its impact on consumer expectations of service quality. Journal of Service marketing 14(1): 9–26.
Belt P, Haapasalo H, Harkonen J, Mottonen M & Kess P (2009) Improving product development in different types of ICT companies. International Journal of Innovation and Learning 6(6): 672–693.
Birou LM, Fawcett SE & Magnan GM (1998) The product life cycle: A tool for functional strategic alignment. International Journal of Purchasing and Materials Management 34(2): 37–51.
74
Breuer T (2009) Data quality is everyone’s business – Designing quality into your data warehouse – Part 1. Journal of Direct, Data and Digital Marketing Practice 11: 20–29.
Boyd M (2006) Product information management – forcing the second wave of data quality. URI: www.thecopywritingpro.com/pages/samples_assets/2nd-wave-DQ.pdf. Cited 2010/4/27.
Bryman A & Bell E (2003) Business Research Methods. New York, Oxford University Press.
Buffington J (2011) Comparison of mass customization and generative customization in mass markets. Industrial Management and Data Systems, 111(1): 41–62.
Cambridge Dictionaries Online (2011) Product. URI: http://dictionary.cambridge.org/ dictionary/british/product_1. Cited 2011/2/13.
Cheng Z & Wang L (2009) Responsive consistency restoration in interactive product configuration by con-tent-addressable memory. Journal of Intelligent Manufacturing 20: 463–479.
Choe K, Booth D & Hu M (1997) Production competence and its impact on business performance. Journal of Manufacturing Systems 16(6): 409–421.
CIMdata (2009) PLM Definition. URI: http://www.cimdata.com/plm/definition.html. Cited 20092009/5/14.
CIMdata (2002) Product Lifecycle Management: Empowering the Future of Business, A CIMdata Report. Ann Arbor, MI, CIM Data Inc.
Closs DJ, Jacobs MA, Swink M & Webb GS (2008) Toward a theory of competencies for the management of product complexity: Six case studies. Journal of Operations Management 26(5): 590–610.
Cooper RG (2001) Winning at New Products: Accelerating the Process from Idea to Launch. 3rd ed. Cambridge, Mass., Perseus Publishing.
Crnkovic I, Asklund U & Persson Dahlqvist A (2003) Implementing and integrating product data management and software configuration. Boston, Artech House.
D’Aveni R (1995) Hypercompetitive Rivalries, Competing in Highly Dynamic Environments. New York, The Free Press.
Ebert C & de Man J (2008) Effectively utilizing project, product and process knowledge. Information and Software Technology 50: 579–594.
EU commission (2006) Glossary: Information and Communication Technologies (ICTs). URI: http://ec.europa.eu/enterprise/glossary/index_en.htm#i. Cited 2012/2/16.
Feng G, Cui D, Wang C & Yu J (2009) Integrated data management in complex product collaborative design. Computers in Industry 60(1): 48–63.
Fensel D, Ding Y, Omalaenko B, Schulten E, Botquin G, Brown M & Flett A (2001) Product data integration in B2B E-commerce. IEEE intelligent systems July/August: 54–59.
Forza C & Salvador F (2007) Product Information Management for Mass Customization. Houndmills, Palgrave Macmillan.
Forza C & Salvador F (2002) Managing for variety in the order acquisition and fulfilment process: The contribution of product configuration systems. International Journal of Production Economics 76(1): 87–98.
75
Gebauer H, Fleisch E & Friedli T (2005) Overcoming the Service Paradox in Manufacturing Companies. European Management Journal 23(1): 14–26.
Gerritsen B, Gielingh W, Nowacki H, Anderl R & Dankwort W (2008) Editorial - special issue on current state and future of product data technologies (PDT). Computer-Aided Design 40(7): 735–737.
Hallikas J, Varis J, Sissonen H & Virolainen V-M (2008) The evolution of the network structure in the ICT sector. International Journal of Production Economics 115(2): 296–304.
Halttunen V & Hokkanen M (1995) Tuotetiedonhallinta: Taustaa ja ratkaisu-vaihtoehtoja. Espoo, Valtion teknillinen tutkimuskeskus (VTT).
Harisalo R (2008) Organisaatioteoriat. Tampere, University Press. Harter DE, Krishnan MS & Slaughter SA (2000) Effects of process maturity on quality,
cycle time, and effort in software product development. Management Science 45(4): 451–466.
Helo P (2004) Managing agility and productivity in the electronics industry. Industrial Management & Data Systems 104(7): 567–577.
Hobday M (1998) Product complexity, innovation and industrial organization. Research Policy 26(6): 689–710.
Hoole R (2006) Drive Complexity Out of Your Supply Chain. Harvard Business Review, Supply Chain Strategy. URI: http://www.prtm.com/uploadedfiles/strategic_viewpoint/ articles/article_content/prtm_drive_complexity.pdf.
Hribernik KA, Rabe L, Thoben K-D & Schumacher J (2006) The product avatar as a product-instance-centric information management concept. International Journal of Product Lifecycle Management 1(4): 367–379.
Huang GQ, Lau JSK & Mak KL (2003) The impacts of sharing production information on supply chain dynamics: a review of literature. International Journal of Production Research 41(7): 1483–1517.
Huang GQ, Zang XY & Liang L (2005) Towards integrated optimal configuration of platform products, manufacturing processes, and supply chains. Journal of Operations Management 23(3–4): 267–290.
Huang MY, Lin YJ & Xu H (2004) A framework for web-based product data management using J2EE. International Journal of Advanced Manufacturing Technology 24(11): 847-852.
Hvam L, Mortensen N-H & Riis J (2008) Product Customization. New York, Springer. Hvam L, Riis J & Hansen BL (2003) CRC cards for product modeling. Computers in
Industry 50(1): 57–70. Hvam L, Riis J, Malis M & Hansen B (2002) A Procedure for Building Product Models. In
Rautenstrauch C, Seelmann-Eggebert R & Turowski K (eds.): Moving into mass customization: information systems and management principles. Berlin, Springer: 19–39.
Hilletofth P & Eriksson D (2011) Coordinating new product development with supply chain management. Industrial Management and Data Systems 111(2): 264–281.
76
ISO (1994) ISO Standard 10303-203: Industrial automation systems and integration—Product data representation and exchange—Part 203: Application protocol: Configuration controlled design.
Janardanan VK, Adithan M & Radhakrishnan P (2008) Collaborative product structure management for assembly modeling. Computers in Industry 59(8): 820–832.
Jansen S, Brinkkemper S, Ballintijn G & van Nieuwland A (2005) Integrated development and maintenance of software products to support efficient updating of customer configurations: A case study in mass market erp software. Proceedings of the 21st IEEE International Conference on Software Maintenance, ICSM’05. Budapest, Hungary: 253-262.
Jin X, Koskela L & King TM (2007) Towards an integrated enterprise model: combining product life cycle support with project management. International Journal of Product Lifecycle Management 2(1): 50–63.
Johansson E & Medbo L (2004) On the use of product data in the design of the material supply system. Journal of Manufacturing Technology Management 15(7): 641–650.
Johnston R & Clark G (2008) Service Operations Management. 3rd ed. Hampshire, Prentice Hall.
Jørgensen KA (2006) Product modeling on multiple abstraction levels. In: Blecker T & Friedrich G (eds.) Mass Customization: Challenges and Solutions. New York, Springer: 63–84.
Jun H-B, Kiritsis D & Xirouchakis P (2007) Research issues on closed-loop PLM. Computers in Industry 58(8–9): 855–868.
Khurana A (1999) Managing complex production process. Sloan Management Review 40(2): 85–97.
Kiritsis D, Bufardi A & Xirouchakis P (2003) Research issues on product lifecycle management and information tracking using smart embedded system. Advanced Engineering Informatics 17(3–4): 189–202.
Knolmayer GF & Röthlin M (2006) Quality of Material Master Data and its Effects on the Usefulness of Distributed ERP Systems. Lecture Notes in Computer Science 4231: 362–371.
Kotha S & Orne D (1989) Generic Manufacturing Strategies: A Conceptual Synthesis. Strategic Management Journal 10(3): 211–231.
Kratochvíl M & Carson C (2005) Growing Modular: Mass customization of complex products, services and software. Berlin, Springer.
Kropsu-Vehkapera H & Haapasalo H (2012) Defining product data views for different stakeholders. Journal of Computer Information Systems 52(2): 61–72.
Kumar R & Midha PS (2006) An intelligent web-based expert system for analysing a company’s strategic PDM requirement. International Journal of Product Lifecycle Management 1(3): 230–248.
Kärkkäinen H, Myllärniemi J, Okkonen J & Silventoinen A (2009) Assessing maturity requirements for implementing and using product lifecycle management. The 9th International Conference on Electronic Business, Macau: 669–678.
77
Lamothe J, Hadj-Hamou K. & Aldanondo M (2006) An optimization model for selecting a product family and designing its supply chain. European Journal of Operational Research 169(3): 1030–1047.
Lancaster G (2005) Research Methods in Management: A concise introduction to research in management and business consultancy. Amsterdam, Elsevier Butterworth-Heinemann.
Lawrence DB (1999) The Economic Value of Information. New York, Springer. Lee B-E & Suh S-H (2009) An architecture for ubiquitous product life cycle support
system and its extension to machine tools with product data model. International Journal of Advanced Manufacturing Technology 42: 606–620.
Lee HJ, Ahn HJ, Kim JW & Park SJ (2006) Capturing and reusing knowledge in engineering change management: A case of automobile development. Information Systems Frontiers 8(5): 375–394.
Lee SG, Ma Y-S, Thimm GL & Verstraeten J (2008) Product lifecycle management in aviation maintenance, repair and overhaul. Computers in Industry 59(2–3): 296–303.
Lehto J, Harkonen J, Haapasalo H, Belt P, Mottonen M & Kuvaja P (2011) Benefits of DfX in Requirements Engineering. Technology and Investment 2(1): 27–37.
Levitt T (1965) Exploit the Product Life Cycle. Harvard Business Review 43(6): 81–94. Lim SCJ, Liu Y & Lee WB (2011) A methodology for building a semantically annotated
multi-faceted ontology for product family modeling. Advanced Engineering Informatics 25(2): 147–161.
Liu DT & Xu XW (2001) A review of web-based product data management systems. Computers in Industry 44(3): 251–262.
Liu W, Zeng Y, Maletz M & Brisson D (2009) Product lifecycle management: a survey. Proceedings of the ASME 2009 International Design Engineering Technical Conferencec & Computers and Information in Engineering Conference IDETC/CIE. San Diego, California, USA: 1213–1225.
Loser C, Legner C & Gizanis D (2004) Master data management for collaborative service processes. International Conference on Service Systems and Service Management, Beijing, China. URI: http://www.alexandria.unisg.ch/analyser/Publications/G/ Dimitrios _Gizanis/23160/L-en.
Maletz M, Blouin J-G, Schnedl H, Brisson D & Zamazal K (2007) A holistic approach for integrated requirements modeling in the product development process. In Krause F-L (ed.) The future of product development: Proceedings of the 17th CIRP design conference. Berlin Heidelberg, Springer: 197–207.
McGrath ME (2001) Product strategy for high-technology companies: accelerating your business to web speed. New-York, McGraw-Hill.
McKay A, Erens F & Bloor MS (1996) Relating product definition and product variety. Research in Engineering Design 2: 63–80.
Meyer M & Zack M (1996) The design and development of information products. Sloan Management Review 37(3): 43–59.
78
Mikkonen K, Hallikas J and Pynnönen M (2008) Connecting customer requirements into the multi-play business model, Journal of Telecommunications Management 1(2): 177–188.
Ming XG, Yan JQ, Lu WF, Ma DZ & Song B (2007) Mass production of tooling product families via modular feature-based design to manufacturing collaboration in PLM. Journal of Intelligent Manufacturing 18(1): 185–195.
Ming XG, Yan JQ, Lu WF & Ma DZ (2005) Technology Solutions for Collaborative Product Lifecycle Management – Status Review and Future Trend. Concurrent Engineering, 13(4): 311–319.
Moore GA (1999) Crossing the chasm. Marketing and selling technology products to mainstream customers. Revised edition. Oxford, Capstone Publishing Limited.
Moss LT (2007) Critical Success Factors for Master Data Management. Cutter IT Journal 20(9): 7–12.
Möttönen M (2009) Requirements engineering - Linking design and manufacturing in ICT companies. Dissertation Thesis, University of Oulu. Acta Universitatis Ouluensis Technica C 336.
Nagi K (2001) Transactional agents – Towards a robust multi-agent system, Berlin, Springer.
Novak S & Eppinger SD (2001) Sourcing by design: Product complexity and the supply chain. Management Science 47(1): 89–204.
OECD (2003) A Proposed Classification of ICT Goods, OECD Working Party on Indicators for the Information Society, Paris. URI: http://www.oecd.org/dataoecd/ 16/46/42978297.pdf. Cited 2012/2/16.
Olson JE (2003) Data Quality – The Accuracy Dimension. San Francisco, Morgan Kaufmann Publishers.
Otto B & Hüner KM (2009) Functional Reference Architecture for Corporate Master Data Management. Institute of Information Management, University of St. Gallen.
Ouertani MZ, Baïna S, Gzara L & Moreld G (2011) Traceability and management of dispersed product knowledge during design and manufacturing. Computer-Aided Design 43(5): 546–562.
Palmber C & Martikainen O (2006) Diversification in response to ICT convergence – indigenous capabilities versus R&D alliances of the Finnish telecom industry. The Journal of Policy, Regulation and Strategy for Telecommunications, Information and Media 8(4): 67–84.
PDMA, Product Development and Management Association (2006) The PDMA Glossary for New Product Development. URI: http://www.pdma.org/npd_glossary.cfm. Cited 2009/4/20.
Peltonen H (2000) Concepts and an Implementation for Product Data Management. Dissertation Thesis, Helsinki University of Technology. Acta Polytechnica Scandinavica, Mathematics and Computing Series No. 105, Espoo 2000.
Philpotts M (1996) An introduction to the concepts, benefits and terminology of product data management. Industrial Management & Data Systems 96(4): 11–17.
79
Pikosz P & Malmqvist J (1996) Possibilities and Limitations when using PDM Systems to Support the Product development Process. Proceedings of NordDesign’96. URI: http://w3.ppd.chalmers.se/~joma/ publications/nd96_poss_pdm.pdf. Cited 2008/2/10.
Pine BJ (199) Mass Customization: The new frontier in business competition. Boston, Harvard Business School Press.
Pollock J & Hodgson R (2004) Adaptive Information: Improving Business Through Semantic Interoperability, Grid Computing, and Enterprise Integration. New Jersey, John Wiley & Sons.
Pugh S (1991) Total design: Integrated methods for successful product engineering. Workingham, Addison-Wesley.
Pulkkinen A (2007) Product Configuration in Projecting Company: The meeting of Configurable Product Families and Sales-Delivery Process. Dissertation Thesis, Tampere University of Technology, Tampere.
Pynnönen M, Hallikas J & Savolainen P (2008) Mapping business: value stream-based analysis of business models and resources in Information and Communications Technology service business. International Journal of Business and Systems Research 2(3): 305–323.
Qu WG & Wang Z (2011) Impact of experience on open inter-organizational systems adoption. Industrial Management & Data Systems 111(3): 432–447.
Rangan RM, Rohde SM, Peak R, Chadha B & Bliznakov P (2005) Streamlining product lifecycle processes: A survey of product lifecycle management implementations, directions, and challenges. Journal of Computing and Information Science in Engineering 5: 227–237.
Rao PM, Vemuri VK & Galvin P (2004) The chancing technological profile of the leading ICT firms: Evidence from US patent data, 1981–2000. Industry and Innovation 11(4): 353–372.
Redman TC (2008) Data driven: profiting from your most important business asset. Boston, MA: Harvard Business School Press.
Rueckel V, Koch A, Feldmann K & Meerkamm H (2005) Process data management for the shortening of the whole product creation process. In Shen W, Chao K-M, Lin Z & Barthès J-P A (eds.) Computer supported cooperative work in design II. 9th International Conference, CSCWD 2005, Coventry, UK, May 24–26, 2005, Revised selected papers. Berlin Heidelberg, Springer: 616–625.
Russom P (2006) Liability and Leverage – A Case for Data Quality. DM Review Magazine.
Saaksvuori A (2011) PLM vision 2016 and beyond. Sirrus Publishing 2011. Saaksvuori A & Immonen A (2008) Product Lifecycle Management. 3rd ed. Berlin,
Springer. Sabin D & Weigel R (1998) Product configuration frame-works – A survey. IEEE
Intelligent Systems and their Applications 13(4): 42–49. Saunders M, Lewis P & Thornhill A (2009) Research methods for business students.
Harlow, Prentice Hall.
80
Scheidt LG & Zong S (1994) An approach to achieve reusability of electronic modules. Proceedings of IEEE International Symposium on Electronics & the Environment, IEEE. San Francisco, CA, USA: 331–336.
Shu Q & Wang CH (2005) Information Modeling for Product Lifecycle Management. In Bernus P & Fox M (eds.) Knowledge Sharing in the Integrated Enterprise: Interoperability Strategies for the Enterprise Architect (IFIP International Federation for Information Processing). 183/2005: 409–416. New York, Springer.
Silcher S, Minguez J, Scheibler T & Mitschang B (2010) A Service-Based Approach for Next-Generation Product Lifecycle Management. Proceedings of 11th IEEE International Conference on Information Reuse and Integration (IEEE IRI 2010). Las Vegas, Nevada, USA: 219–224.
Siller HR, Estruch A, Vila C, Abellan JV & Romero F (2008) Modeling workflow activities for collaborative process planning with product lifecycle management tools. Journal of Intelligent Manufacturing 19: 689–700
Simon, M, Bee G, Moore P, Pu J-S & Xie C (2001) Modelling of the life cycle of products with data acquisition features. Computers in Industry 45(2): 111–122.
Smith PG & Reinertsen DG (1992) Shortening the Product Development Cycle. Research Technology Management 35(3): 44–49.
Snow C (2008) Embrace the role and value of master data. Manufacturing Business Technology 26(2): 38–40.
Stark J (2005) Product lifecycle management: 21st Century Paradigm for Product Realisation. New York, Springer.
Steinmueller EW (2001) ICTs and the possibilities for leapfrogging by developing countries. International Labour Review 140(2): 193–210.
Sudarsan R, Fenves SJ, Sriram RD & Wang F (2005) A product information modeling framework for product lifecycle management. Computer-Aided Design 37(13): 1399–1411.
Sulaiman R (2000) Change and delay. Manufacturing Engineer 79(3): 122–123. Svensson D & Malmqvist J (2002) Strategies for product structure management in
manufacturing firms. Journal of Computing and Information Science in Engineering 2(1): 50–58.
Terzi S, Bouras A, Dutta D, Garetti M & Kiritsis D (2010) Product lifecycle management – from its history to its new role. International Journal of Product Lifecycle Management 4(4): 360–389.
Thimm G, Lee SG & Ma Y-S (2006) Towards unified modelling of product lifecycles. Computers in Industry 57(4): 331–341.
Tiihonen J, Lehtonen T, Soininen T, Pulkkinen A, Sulonen R & Riitahuhta A (1998a) Modeling configurable product families. 4th WDK Workshop on Product Structuring. Delft, The Netherlands.
Tiihonen J, Soininen T, Männistö T & Sulonen R (1998b) Configurable products – Lessons Learned from the Finnish Industry. Proceedings of 2nd International Confe-rence on Engineering Design and Automation, Integrated Technology Systems Inc.
81
Ulrich KT & Eppinger SD (2000) Product Design and Development. 2nd ed. New York, McGraw-Hill.
Urban GL & Hauser JR (1980) Design and Marketing of New Products. New Jersey, Prentice-Hall.
Vanderfeesten I, Reijers HA & van der Aalst WMP (2011) Product-based workflow support. Information Systems 36(2): 517–535.
van den Hamer P & Lepoeter K (1996) Managing design data: The five dimensions of CAD frameworks, configuration management, and product data management. Proceedings of the IEEE 84(1): 42–56.
Vesterby V (2008) Measuring complexity: Things that go wrong and how to get it right. E:CO Issue 10(2): 90–102.
Vroom RW (1996) A general example model for automotive suppliers of the development process and its related information. Computers in Industry 31(3): 255–280.
Wang RY (1998) A Product Perspective on Total Data Quality Management. Communications of the ACM 41(2): 58–65.
Wei Z, Tan J & Feng Y (2009) Integration technology of ERP and PDM based on business remote function call. International Journal of Advanced Manufacturing Technology 40(9): 1044–1052.
White C (2007) Using Master Data in Business Intelligence. BI Research, Version 1 March 2007. URI: http://www.broadstreetdata.com/images/pdf/MDM/Using-Master-Data-in-Business-Intelligence.pdf. Cited 2009/7/3.
Williamson RW (1982) Presenting Information Economics to Students. The Accounting Review 57(2): 414–419.
Wilson LO & Norton JA (1989) Optimal Entry Timing for Product Line Extension. Marketing Science 8(1): 1–17.
Yang J, Soonhung H, Grau M & Mun D (2009) Open PDM-based product data exchange among heterogeneous PDM systems in a distributed environment. International Journal of Advanced Manufacturing Technology 40(9): 1033–1043.
Yang X, Moore PR, Wong C-B, Pu J-S & Chong SK (2007) Product lifecycle information acquisition and management for consumer products. Industrial Management & Data Systems 107(7): 936–953.
Yin RK (2003) Case Study Research. Design and Methods. Thousand Oaks, Calif., Sage Publications.
Zeithaml V & Bitner MJ (1996) Services Marketing. New York, McGraw-Hill. Zhang A & Reichgelt H (2006) Product Complexity as a Determinant of Transaction
Governance Structure: An Empirical Comparison of Web-Only and Traditional Banks. Journal of Electronic Commerce in Organizations 4(3): 1–17.
Zhang S, Shen W & Ghenniwa H (2004) A review of Internet-based product information sharing and visualization. Computers in Industry 54(1): 1–15.
Zhu B, Wang Z, Yang H, Mo R & Zhao Y (2008) Applying fuzzy multiple attributes decision making for product configuration. Journal of Intelligent Manufacturing 19(5): 591–598.
82
83
Original publications
I Kropsu-Vehkapera H, Haapasalo H, Harkonen J & Silvola R (2009) Product data management practices in high-tech companies. Industrial Management & Data Systems 109(6): 758–774.
II Kropsu-Vehkapera H, Haapasalo H, Lokkinen S & Phusavat K. (2011) The influence of product complexity on order handling process. International Journal of Innovation and Learning 10(2): 123–143.
III Kropsu-Vehkapera H & Haapasalo H (2012) Defining product data views for different stakeholders. Journal of Computer Information Systems 52(2): 61–72.
IV Kropsu-Vehkapera H, Haapasalo H, Jaaskelainen O & Phusavat K (2011) Product Configuration Management in ICT Companies: The Practitioners’ Perspective. Technology and Investment 2(4): 273–285.
Reprinted with the permission of the copyright holders. The above-named
journals are the original sources of publication for the four articles above.
Original publications are not included in the electronic version of the dissertation.
84
A C T A U N I V E R S I T A T I S O U L U E N S I S
Book orders:Granum: Virtual book storehttp://granum.uta.fi/granum/
S E R I E S C T E C H N I C A
401. Huttunen, Sami (2011) Methods and systems for vision-based proactiveapplications
402. Weeraddana, Pradeep Chathuranga (2011) Optimization techniques for radioresource management in wireless communication networks
403. Räsänen, Teemu (2011) Intelligent information services in environmentalapplications
404. Janhunen, Janne (2011) Programmable MIMO detectors
405. Skoglind-Öhman, Ingegerd (2011) Participatory methods and empowerment forhealth and safety work : Case studies in Norrbotten, Sweden
406. Kellokumpu, Vili-Petteri (2011) Vision-based human motion description andrecognition
407. Rahko, Matti (2011) A qualification tool for component package feasibility ininfrastructure products
408. Rajala, Hanna-Kaisa (2011) Enhancing innovative activities and tools for themanufacturing industry: illustrative and participative trials within work systemcases
409. Sinisammal, Janne (2011) Työhyvinvoinnin ja työympäristön kokonaisvaltainenkehittäminen – tuloksia osallistuvista tutkimus- ja kehittämisprojekteista sekäasiantuntijahaastatteluista
410. Berg, Markus (2011) Methods for antenna frequency control and user effectcompensation in mobile terminals
411. Arvola, Jouko (2011) Reducing industrial use of fossil raw materials : Techno-economic assessment of relevant cases in Northern Finland
412. Okkonen, Jarkko (2011) Groundwater and its response to climate variability andchange in cold snow dominated regions in Finland: methods and estimations
413. Anttonen, Antti (2011) Estimation of energy detection thresholds and errorprobability for amplitude-modulated short-range communication radios
414. Neitola, Marko (2012) Characterizing and minimizing spurious responses inDelta-Sigma modulators
415. Huttunen, Paavo (2012) Spontaneous movements of hands in gradients of weakVHF electromagnetic fields
416. Isoherranen, Ville (2012) Strategy analysis frameworks for strategy orientationand focus
C418etukansi.kesken.fm Page 2 Tuesday, March 27, 2012 11:34 AM
ABCDEFG
UNIVERS ITY OF OULU P.O.B . 7500 F I -90014 UNIVERS ITY OF OULU F INLAND
A C T A U N I V E R S I T A T I S O U L U E N S I S
S E R I E S E D I T O R S
SCIENTIAE RERUM NATURALIUM
HUMANIORA
TECHNICA
MEDICA
SCIENTIAE RERUM SOCIALIUM
SCRIPTA ACADEMICA
OECONOMICA
EDITOR IN CHIEF
PUBLICATIONS EDITOR
Senior Assistant Jorma Arhippainen
Lecturer Santeri Palviainen
Professor Hannu Heusala
Professor Olli Vuolteenaho
Senior Researcher Eila Estola
Director Sinikka Eskelinen
Professor Jari Juga
Professor Olli Vuolteenaho
Publications Editor Kirsti Nurkkala
ISBN 978-951-42-9797-7 (Paperback)ISBN 978-951-42-9798-4 (PDF)ISSN 0355-3213 (Print)ISSN 1796-2226 (Online)
U N I V E R S I TAT I S O U L U E N S I SACTAC
TECHNICA
U N I V E R S I TAT I S O U L U E N S I SACTAC
TECHNICA
OULU 2012
C 418
Hanna Kropsu-Vehkaperä
ENHANCING UNDERSTANDING OF COMPANY-WIDE PRODUCT DATA MANAGEMENT IN ICT COMPANIES
UNIVERSITY OF OULU GRADUATE SCHOOL;UNIVERSITY OF OULU, FACULTY OF TECHNOLOGY,DEPARTMENT OF INDUSTRIAL ENGINEERING AND MANAGEMENT
C 418
ACTA
Hanna K
ropsu-VehkaperäC418etukansi.kesken.fm Page 1 Tuesday, March 27, 2012 11:34 AM