collaborative product development also sets higher requirements ... cooperation. Here the terms IOIS will be used, since IOS (interorganizational system) can.
Linköping Studies in Management and Economics, Dissertations No. 54
Dissertations from the International Graduate School of Management and Industrial Engineering, IMIE No. 59, Doctoral Dissertation
Interorganizational IT Support for Collaborative Product Development
Anna Öhrwall Rönnbäck
2002 Department of Management and Economics Division of Industrial Management and Economics Linköpings universitet, SE-581 83 Linköping
© Anna Öhrwall Rönnbäck, 2002 ISBN: 91-7373-323-7 ISSN: 0347-8920 ISSN: 1402-0793 Printed by: UniTryck, Linköping Distributed by: Linköpings universitet Department of Management and Economics SE-581 83 Linköping, Sweden Tel: +46 13 281000, fax: +46 13 281873
To my family
Acknowledgments First and most of all I would like to thank my supervisor Professor Staffan Brege for making it all possible by recruiting me to the research school IMIE back in 1997. Thanks for everything, Staffan, from insightful theoretical discussions, to supportive and inspiring talks when I needed them most! My gratitude also goes to Professor Staffan Gullander for his creative new ideas and constructive criticism of my work, and for good companionship in our “joint ventures”. I also thank Professor Mats Abrahamsson for sharing his ideas on the IT puzzle, his fast reading, and always valuable and encouraging comments. Thanks also to Hugh Excell for excellent proofreading and in other ways improving the readability of this dissertation. Special thanks also to UniTryck for keeping track of files and for a flexible and fast job printing this book. Over the years many skilled people have kindly read and commented on my work. Thank you Dr Johan Lilliecreutz, Tech lic Gunnar Holmberg, Dr Roland Sjöström, Dr Mats Björkman, and Dr Jakob Gramenius, for proficient help with the licentiate thesis. Thank you Dr Jonas Herbertsson, Dr Mike Danilovic, and Associate Professor Helén Andersson for important comments on previous versions of this dissertation. Moreover, I have learnt a lot from my coauthors; thank you Dr Nicolette Lakemond (the early works), Tech lic Göran Backlund, MSc Helena Wennberg, Tech lic Peter Cronemyr and Professor Steven Eppinger. Many other people have helped me on the way – thank you all at ENDREA and IMIE. There can be no product development research without product development cases. My deepest thanks to all respondents at Saab, Microturbo, Sundstrand Power Systems, Boeing, ABB Ventilation, FMV,
Fält Elektronik, and the firms connected to PUCK, SLIT, and the VMU, for letting me share your experiences and for taking your time. Here I also want to mention former colleagues in product development teams at Steelcase Strafor and DECIM who taught me a lot about product development work in practise that has been so useful for this research. And there is no good research without fun, which is yet another advantage of research in teams (that I forgot to mention in the method chapter)… Thank you all for the great memories of LARP and NISAM! Financial support for the research has been received from the Swedish Foundation for Strategic Research (supports IMIE), NFFP (supported the “Lean Aircraft Research Project” together with Saab and the research schools IMIE and ENDREA), and NUTEK (supported the project “Ny Industriell SAMverkan”, managed by the IVF). I am grateful for their support. I would also like to thank my colleagues at the Department of Economics and Management for their constantly present support and help. I can’t mention everyone by name but I want to thank especially MSc Helena Wennberg, Kicki Dahlberg, Dr Maria Huge Brodin, Dr Per-Olof Brehmer, Dr Jakob Rehme, and everyone at the “dynamic” division Industriell ekonomi for making it such an inspiring workplace! Finally, I dedicate this work to those who mean most to me, my wonderful (extended) family: Karolina, Viktor, Niklas, Zoot and Foggy, Gudrun and Birger, my parents, and sisters. Thank you for giving me all the time I needed to finish it. We have a lot to catch up now! Redinge Lillgård, March 2002 Anna Öhrwall Rönnbäck
Contents 1
INTRODUCTION ..................................................................................... 3 1.1 1.2
1.3
2
ON COLLABORATIVE PRODUCT DEVELOPMENT .....................................................................3 PURPOSE, RESEARCH QUESTIONS AND SCOPE ........................................................................6 1.2.1 Purpose........................................................................................................................................ 6 1.2.2 Research Questions..................................................................................................................... 7 1.2.3 Scope – Limitations of the Thesis ............................................................................................ 8 STRUCTURE OF THE THESIS........................................................................................................9
RESEARCH METHOD AND RESEARCH DESIGN........................ 11 2.1 2.2 2.3
2.4
2.5
3
METHODOLOGICAL APPROACH ..............................................................................................11 RESEARCH PROCESS ..................................................................................................................13 SELECTION OF CASES AND DATA COLLECTION ....................................................................15 2.3.1 Case Selection Part I............................................................................................................... 16 2.3.2 Case Selection Part II ............................................................................................................. 17 2.3.3 Categorizing of Cases.............................................................................................................. 18 2.3.4 Data Collection ....................................................................................................................... 20 METHOD FOR ANALYSIS ...........................................................................................................23 2.4.1 Within-Case and Cross-Case Analysis ................................................................................. 23 2.4.2 Analysis Individually and in Research Teams .................................................................. 26 2.4.3 Choice of Literature ................................................................................................................ 27 REFLECTION ON THE QUALITY OF THE RESEARCH STUDY ..................................................27
FRAME OF REFERENCE ...................................................................... 29 3.1 3.2 3.3
4
DEFINITION AND DISCUSSION OF KEY CONCEPTS ...............................................................29 ORGANIZATION OF COLLABORATIVE PRODUCT DEVELOPMENT ........................................33 INTERORGANIZATIONAL IT SUPPORT FOR PRODUCT DEVELOPMENT................................36
CRITICAL ISSUES OF COLLABORATIVE PRODUCT DEVELOPMENT ..................................................................................... 41 4.1 4.2
COLLABORATIVE PRODUCT DEVELOPMENT IN THE DYAD ..................................................41 4.1.1 Coordinating Independent Product Development Processes ............................................. 41 4.1.2 Characteristics of Information and Communication in the Dyad ................................ 44 COLLABORATIVE PRODUCT DEVELOPMENT IN A SUPPLIER NETWORK ..............................47 4.2.1 Managing Interfirm Integrated Product Development .................................................... 47 4.2.2 Characteristics of Information and Communication in the Supplier Network .......... 49
INTERORGANIZATIONAL INFORMATION SYSTEMS: NEEDS AND BARRIERS ...................................................................................... 53
5 5.1 5.2
6
IOIS FOR COLLABORATIVE PRODUCT DEVELOPMENT.........................................................53 5.1.1 Information and Communication in Collaborative Product Development ................ 53 5.1.2 Is IOISs a Solution for Collaborative Product Development? ........................................ 55 NEEDS AND BARRIERS OF INTERORGANIZATIONAL COMMUNICATION SUPPORT ............57 5.2.1 The Dyad .................................................................................................................................. 57 5.2.2 The Network............................................................................................................................ 61
CONCLUSIONS ...................................................................................... 65 6.1 6.2
REALIZATION OF IOIS..............................................................................................................65 6.1.1 Product Development and IOIS Requirements .................................................................. 65 6.1.2 Towards an Informed Collaborative Product Development Environment?................ 69 RECOMMENDATIONS FOR FURTHER RESEARCH ...................................................................72
REFERENCES ......................................................................................................... 75 Appendix A: Collaborative product development and IT Support: A Study in the Swedish Aerospace Industry (Licentiate thesis 1999, Abstract) Separate volume Appendix B: Product Development in Supplier Networks: A Multiple Case Study in Swedish Industry Coauthors: Staffan Gullander and Staffan Brege Appendix C: Requirements for IT Support for Competitive Collaboration: Findings from Case Studies of Collaborative Product Development Appendix D: List of previous publications Appendix E: Question guide (see also Appendix A)
2
1
Introduction
This chapter serves as an introduction to the research area. The first section gives a background to the research problem. Then, the purpose and research questions are presented, followed by an overview of the structure of the thesis.
1.1
On Collaborative Product Development Information management in product development is a delicate task since much is unknown both of market and technological aspects when a new product is being developed. Given that a large part of the product life cycle cost is determined already in the concept phase1, many variables and viewpoints need to be taken into account. Representation of several company functions is necessary for requirement specification, knowledge acquisition, and decision-making concerning the forthcoming product throughout the development project. This cross-functional integration is generally referred to as integrated product development, IPD (Andreasen and Hein 1987), commonly organized as projects with integrated product development teams, IPTs, where representatives from eg marketing, R&D, and manufacturing departments take part (Wheelwright and Clark 1992). In this research we add a dimension to the complexity of product development activities by studying interorganizational product development, ie when firms collaborate in the development of a common system. Collaboration in product development is increasingly common as a consequence of more complex products and globalization of business activities. Intensified competition
1
Boeing reports that 80 % of the product costs are locked in by the product definition (Coyle et al 2000, reports from LAI-LEM, Lean Aerospace Initiative – Lean Enterprise Model, see REF-LAI).
3
has led to more frequent product launches, which have resulted in higher pressure on time to market and faster product development cycles. Moreover, local presence on several markets is often required in order to understand customers’ varying demands. (Nishiguchi 1996) Increased product complexity is a consequence of more advanced technology, for example the fast development of electronics, increased computerization, and materials development. Fine (1998) found that it is appropriate to talk about different clockspeed for different industries. Many products today are also so-called system products composed by several parts (subsystems) that shall function together as a whole (Rechtin 1993). To develop products in this new competitive landscape (Bettis and Hitt 1995) requires competencies over a broader range than a firm usually can have in-house, and leads to larger development risks than most firms can bear on their own. Collaboration with other parties in the supply chain and with former competitors has therefore become a common solution. Examples of cases can be found eg in the aerospace industry studied in this research, in Europe the Airbus consortium2 and Saab’s close collaboration with former competitor British Aerospace, and, in the US, the development of the Joint Strike Fighter3. This increased “coopetition” (Nalebuff and Brandenburger 1996) is a consequence of the previously mentioned higher product complexity in combination with tougher competition (and in the defense industry lower military budgets, see Augustine 1983), which has led to reduced margins. In fact, buyer-supplier cooperation in highly complex product development has a long tradition, for instance in the aerospace, automotive and medical industries. A change in recent years though is towards a more differentiated attitude to suppliers depending on the long-term strategic importance of their involvement (Kraljic 1983, Lilliecreutz and Ydreskog 1998), and a focus on the relationship between the collaborating parties (Lamming, Cousins, and Notman 1996). When large manufacturing firms seek to reduce their supplier base in order to be able to manage closer relationships with a few, strategic 2
3
With British Aerospace, Aerospatiale-Matra, DaimlerChrysler Aerospace, CASA, and others, see www.airbus.com. See www.jast.com. Joint development between Boeing Lockheed Martin, McDonnell Douglas, General Electric, Northrop Grumman, Pratt & Whitney to mention a few.
4
suppliers, they become systems integrators instead of ordinary manufacturers, with responsibility for the overall quality and functionality of a product consisting of subsystems delivered from major systems suppliers with whom they work closely (Fredriksson 1994, Lilliecreutz 1996), as illustrated in figure 1.1.
Systems integrator
1st tier supplier
System Product
1st tier supplier
Figure 1.1
1st tier supplier
1st tier supplier
Development of a system product often means to integrate system parts, which major suppliers develop and produce.
Closer vertical cooperation between a buyer firm and its major suppliers can be regarded as a threat for smaller firms, which risk being pushed backwards in the supply chain. However, by joining their forces in supplier networks (Womack, Jones, and Roos 1990 and Miles and Snow 1994), several component suppliers can offer complete system products either to buyer firms or to the first and second tiers in the supply chain. Such horizontal supplier network product development collaboration is usually organized to serve one customer firm. Most often, this customer firm initiates the product development assignment, although the contrary may be found (as in one of the supplier network cases studied, where the supplier network initiated the development4). Within the supplier network, firms may also have some vertical buyer-supplier relations between them. Innovations carried out together with customers, major suppliers and subtiers lead to increasingly complex supply chain cooperation (Quinn 2000). Compared to in-house development, 4
The weapon lock case, see Appendix B.
5
collaborative product development also sets higher requirements for communication management, where the balance between necessary openness concerning information sharing and precautions to control proprietary information is delicate (Biemans 1995, Parker 2000). Conclusions on the need for improved information management between collaborating partners is found in several previous research studies in this area (eg Bruce et al 1995, Ragatz et al 1997, Wynstra 1999, Chandrashekar and Schary 1999, Christopher 2000, Quinn 2000, Sawhney and Prandelli 2000), and has probably played a part in increasing expectations of the effect supporting IT tools could have. Results from the empirical studies that this thesis is based on, show that until today mainly e-mail messages with attachments have been used for distant communication between engineers in different companies (see Appendix A – a study conducted of dyads in the aerospace industry, and Appendix B – a study of supplier networks in various industries). Is it that companies have not yet adopted the new technology, or do we have other fundamental barriers exist that prevent a more widespread use of interorganizational IT support in collaborative product development? This thesis shall further investigate the requirements for internet and web-based solutions for collaborative product development activities, the potential of such tools, and interorganizational barriers against use and implementation.
1.2
Purpose, Research Questions and Scope
1.2.1
Purpose
The objective of this thesis is to assess characteristics of communication in collaborative product development, in order to identify requirements for supporting IT tools. The first part of the purpose, to assess characteristics of collaborative product development, implies to investigate special characteristics of communication and information exchange when two or several parties conduct product development together. The second part of the purpose is directed towards specifying a systems solution that can improve efficiency and effectiveness of collaborative product development. 6
1.2.2
Research Questions
Product development is an information and communication intense activity (Clark and Fujimoto 1991). When more than one firm is involved, questions linked to business aspects regarding what information to share and how to communicate the information between the firms become important (Fulk and DeSanctis 1995). Technological solutions for information and communication over company borders, referred to as interorganizational information systems (IOIS5), are therefore considered relevant to study, however, not from a purely technological view. Also business aspects of interorganizational character must be considered in the search for explanations and explanatory models concerning IT tools for collaborative product development. Therefore, this thesis addresses the following three research questions: 1. What are the special characteristics of information and communication in collaborative product development compared to intraorganizational product development? 2. What are the needs of IOISs for collaborative product development and what are the barriers against implementation and use? 3. What are the requirements for an IOIS so that it shall contribute to rendering the collaborative product development process more efficient and effective in all phases? IT tools and platforms for product development are extensively used in-house but not with external parties. The first research question therefore seeks to clarify differences between intra- and interorganizational product development activities, since it is believed that the special characteristics of collaborative product development can give explanations to this observation, and that a better understanding of communication in collaborative product development can lead to suggestions for improvements (called for by several authors in previous research, eg Bruce et al 1995). Previous research on collaborative product development mainly concerns dyads, where a supplier is involved in a focal firm’s intraorganizational product development, and takes one firm’s 5
Both “IOIS” and “IOS” are used in previous literature for IT solutions for interorganizational cooperation. Here the terms IOIS will be used, since IOS (interorganizational system) can mean any system, not necessarily information system. The IS referred to in IOIS is an IS/IT system, ie based on information technology.
7
perspective (Håkansson 1987). This study investigates collaborative product development both in dyads and in supplier networks (where several firms take part), and is viewed from the buyer as well as from the supplier side. To include both dyads and supplier networks was considered important in order to be able to distinguish special conditions for collaborative product development compared to intrafirm development. A holistic view on buyer-supplier interaction is also encouraged by Melin (1989), in order to increase understanding of the “field-of-force” in an industrial field. Further, in studies of interorganizational activities, the relationship between the parties is central (Lamming, Cousins, and Notman 1996), and consequently to investigate the research questions from both buyer and supplier side was considered to give a more holistic picture of the problem than if the collaborative activities are one-sidedly studied. The second question, mapping the needs of and barriers against information management with IT tools, is closely linked to the special characteristics of information and communication in collaborative product development in the first. The results of the second research question, in turn, could serve as a base for answering the third, which deals with identification of requirements for IOISs for product development. It seeks to list requirements for supporting IT tools that a firm could use if it takes part in collaborative product development either as a buyer or a supplier, and is therefore more of a normative character. 1.2.3
Scope – Limitations of the Thesis
The type of product that is studied has importance for the outcome of a study in product development (Eisenhardt and Tabrizi 1995). In this research, the development of physical products that are built up from mechanical or electronic parts has been studied. The literature focused on is therefore in the traditional product development field, not mainly in software development. In this regard, the thesis is close to the studies in the automotive industry as made by eg Clark and Fujimoto (1991), who limit their studies to tangible products. The theoretical framework is however not limited to the extensive amount of auto-industry studies (Womack et al 1990), but ranges over a large number of industries (IT and telecom, textile, and biotech). The collaboration between firms studied is limited to business collaboration, ie that a business assignment is the major driving 8
force behind the collaboration, different from completely social networking (although business networking also often contains some social aspects, Melin 1989). Moreover, the study focuses on collaboration between business partners, as opposed to cooperation with other non-profit organizations such as universities or research centers (although such organizations may have some minor part in the cases studied, as described in Appendix B). A firm’s development activities are generally referred to as Research and Development, R&D. While research refers to longterm explorative activities not aiming to develop a specific product, development refers to the relatively short-term innovative activities, which aims to develop a specific product for a specific market launch (Wheelwright and Clark 1992). The connection between a firm’s research and development is that research results generally lead to product development projects. This thesis focuses on the development activities. Concerning the IT tools, the focus lies on IOISs based on internet technology. Moreover, originally the research questions also included long-term effects of using IOISs for collaborative product development. However, empirical limitations have led to this aspect not being studied. Instead, the study of the long-term effects of IOISs is suggested for further research.
1.3
Structure of the Thesis This introductory chapter has presented the area of interest, the purpose and the research questions. Chapter 2 contains a description of the research methodology. Chapter 3 gives a brief theoretical background and definition of key concepts to the problem area, but theoretical background is also described for each appended paper (Appendix A-C). Chapter 4 presents findings concerning critical issues for collaborative product development, largely based on the findings presented in Appendix A and B (and to some extent in Appendix C). Needs for and barriers against use of information systems (IOIS) for collaborative product development are discussed in Chapter 5. The discussion mainly derives from the results presented in Appendix C. Finally, chapter 6 concludes the thesis by discussing
9
how an IOIS could be realized according to the requirements of Appendix C, and suggestions of further research.
10
2
Research Method and Research Design
In this chapter the research strategy is described and a detailed description of the research process is given. Further, selection of cases is presented together with tactics for data collection, data analysis and theory generation. The chapter concludes with reflections on quality measures for the kind of study conducted for this research.
2.1
Methodological Approach The research problem presented in this thesis emanates from problems identified in business practice (eg Johnson 2000). Its specific focus on collaborative product development and internet applications makes it relatively new as a research area. Since the problem studied stretches over several areas such as integrated product development (engineering management), interfirm business organization (business strategy, strategic purchasing, and interorganizational relationships), and supporting information technology tools (IT management), it could be characterized as interdisciplinary and relatively complex. The research strategy to apply to this kind of study can be discussed. According to Yin (1989) a researcher’s choice of methodological approach in social science research depends on the problem at hand and the control that the researcher has over the behavioral events. He suggests to choose case study method as a research strategy, as opposed to experiments and surveys, when a ‘how’ or ‘why’ question is being asked about a contemporary set of events, over which the investigator has little or no control (Yin 1989:20)
11
To conduct a case study was an early choice in this research, due to the novelty of the problem area and the complexity with several theoretical disciplines involved (Eisenhardt 1989). The study contains also elements of action research where the role of the researcher lies in between the role of researcher and consultant (as described by Gummesson 1988). The choice of research strategy is also based on the researcher’s personal preferences. At the beginning of this research, my personal preference was to conduct a comparative multiple case study with more the character of survey, with several empirical cases and essential quantitative parts (in the direction of a multiple case study within operations management as described by eg Lewis 1998). However, the initial empirical studies revealed that such a research strategy would be difficult to carry out in this field due to the problem characteristics: its novelty, its complexity, and consequently the difficulty for the researcher to control the course of events. Eisenhardt (1989) adds to this argument that a caseoriented research process is considered appropriate in new topic areas. Since case studies typically combine several data collection methods, such as archives, interviews, questionnaires and observations, and thus permit analysis of both qualitative and quantitative data, I found this method appropriate both due to the problem at hand and appealing from a personal point of view. Moreover, case studies can be applied for various aims; descriptive, theory testing or theory generating (Eisenhardt 1989). This research aims to be theory generating, but hopefully the descriptions of the case studies (in Appendix A and B) will also make relevant research contributions. The importance of a rather well specified initial research question is valuable for systematic collecting of specific kinds of data (Mintzberg 1979). Early theoretical constructs are also important for a study, since it can contribute to more accurate and precise measurements. This is acceptable as long as the researcher recognizes that the possible constructs are only tentative and that the research question may change during the study (Eisenhardt 1989). Otherwise, the ideal of starting from “a clean theoretical slate” and avoiding thinking too much of relationships between variables and theories should be striven for at the outset of a study that aims to be theory building, since expected theoretical perspectives or propositions may interfere with the findings (Glaser and Strauss 1967, Eisenhardt 1989). My opinion is though, 12
that some theoretical insights in the area are necessary for forming better research quality and gain an awareness that helps avoid the risk of coming up with theoretical constructs that already exist (in accordance with Lewis 1998, Alvesson and Sköldberg 2000).
2.2
Research Process The research process is illustrated in figure 2.1. It has been iterative, with constant interplay between empirical data and theory. All along the data collection phases, reading and writing have been an integrated part of the research. (See list of previous publications from 1997-2001 in Appendix D.) Part I
Empirical data
The product development process
Three dyad cases (international aircraft industry)
Current IT tools in product development
IT (internet) projects (in the aircraft industry)
Theory Integrated product development Collaborative product development IT management RESULTS Appendix A
Appendix B Appendix C
Part II The collaborative product development process
Three network cases (Swedish industry)
Functions of an IT tool for collaborative product development
Implementation of a web-based infrastructure
Figure 2.1
Theoretical contributions Managerial implications
Dissertation
Supply chain management (SCM) Buyer-supplier relationships Interorganizational information systems
The research process
The research set out as an exploratory study, in order to get acquainted with the empirical phenomenon studied. This first part was carried out in a methodological approach influenced by grounded theory (Glaser and Strauss 1967, Strauss and Corbin 1990), with the objective of generating theoretical questions. At the outset of this research, a study with the research question to compare the formal product development process as described by a case company with the applied product development process, and to map the use of IT tools was conducted at one case company (Saab AB, reported in Andersson, Backlund, Cronemyr, Pohl, Sveder, and Öhrwall Rönnbäck 1998).
13
This initial study was important for the continued research, as it revealed empirical evidence concerning the involvement of suppliers and close collaboration with customers and other parties in complex system product development, which became central in the continued research. This was also something that I had experienced as a practitioner of product development6. The preunderstanding I gained before and during the study of empirical areas and theoretical areas is shown in the chart in figure 2.1 (the “clouds” to the left). After the initial intrafirm study (fall 1997), three in-depth case studies of interorganizational product development were carried out (1998-1999) at one firm and its major suppliers (Saab AB and suppliers Microturbo and Sundstrand). In the licentiate thesis, Appendix A, the empirical findings were related to previous theoretical findings, mainly in three areas: integrated product development, collaborative complex system product development, and IT management. The first part of the study can be classified as mainly inductive, ie it generates theoretical problems, as presented in Appendix A (see also Backlund and Öhrwall Rönnbäck 1998, and Cronemyr, Öhrwall Rönnbäck, and Eppinger 2001). The theoretical findings and conclusions drawn in Part I were used to design the study and formulate questionnaires for Part II of the research. Part II was therefore of a more deductive character since the theoretical issues generated from the first part were used as a base for data collection. The first empirical results of Part II (fall 1999) led into further readings of previous work in the areas of buyer-supplier relations, supply chain management, and interorganizational information systems (IOIS), as illustrated in figure 2.1. The complementary data collection carried out (fall 2000) was therefore much influenced by the empirical as well as the theoretical results so far, and led to more precise question areas in the last round of indepth interviews. The second part resulted in Appendix B (see also Öhrwall Rönnbäck, Gullander, Brege 2001, and Pilemalm, Gullander, Norling, and Öhrwall Rönnbäck 2001). 6
My personal prior experience of product development work consists primarily of participation in an international project team for the development of an office furniture system for the European market in 1993-1994 (see final product TNT by Steelcase Strafor, www.steelcase-strafor.fr), and participation in the development of a dental CAD/CAM system 1994-1997 (see final product DECIM and DENZIR at Decim, www.decim.se).
14
In Appendix C the empirical data from Part I and Part II is analyzed from an information and communication angle, while Appendix A and B described and analyzed the cases from a broader collaborative product development point of view.
2.3
Selection of Cases and Data Collection The research design for case studies should be kept open for changes due to emergent results along the studies. Yet, this flexibility to complement initially selected cases should not be confounded with a shift in underlying theoretical objectives, which should be avoided in order not to make the study fit the cases found. (Yin 1989) Research tactics concerning how openness and flexibility was handled in this research will be accounted for in this section. Since the researcher only can study a limited number of cases indepth, case selection is central and should not be done at random. First, it is important to select an appropriate population among which the cases are selected. Definition of the population controls unwanted variation and gives the limits for generalizing from the cases. (Eisenhardt 1989) In this research, a specification of the population is “collaborative product development of physical products”. Studies of IT support in the collaboration (especially web-based tools) were conducted as a special track of data collection, connected to these product development cases. An overview of the cases studied in chronological order is given in figure 2.2. (See also table 2.1 below).
15
Part I: Saab and Major Suppliers
Part II: Supplier Networks
Product Product development development process process Saab Saab
Collaborative product development of physical products
APESS APESS 328 328 Saab-MT Saab-MT
Weapon Weapon lock lock FMVFMV- VMU VMU
New New APESS APESS Saab-SPS Saab-SPS
Ventilation Ventilation control control system system ABB ABB -- SLIT SLIT
Sweden-France
Sweden-USA
Sweden
Sweden
GECU GECU Saab-ESB Saab-ESB
Platelet Platelet meter meter Fält Fält Elektronik Elektronik -- PUCK PUCK
Sweden
IS/IT projects
Web-based Web-based platform platform www.puck.se www.puck.se
1997 Jan
Sweden
IT IT projects projects at at Saab Saab EMPIRE, EMPIRE, PAM, PAM, VEGA VEGA
1999
1998 Jun
Jan
Figure 2.2
Jun
2000
Jan
Jun
Jan
2001 Jun
Jan
Overview of empirical studies carried out showing population and chronological order of the two parts.
In a multiple-case study the selection of cases should be done in order to reach a desired theoretical sampling (Glaser and Strauss 1967), ie it could include polar type cases and extreme situations that fill certain theoretical categories or extend the emergent theory7. In this research, the tactic was to complement an initial study mainly carried out at one firm (in Part I) with a multiple case study (in Part II) that could extend emergent theory. Thus the multiple cases were not selected at the outset of the study, but were chosen at the end of Part I. 2.3.1
Case Selection Part I
Theoretical categories initially taken into account were, for the product development track in Part I, outsourcing of innovation activities and product complexity. The population was defined as product development carried out by a major supplier, studied from the buyer’s (systems integrator) perspective. The buyer and major suppliers studied were relatively large firms. The cases chosen were the development of two of the major systems (the auxiliary power and engine starting system, APESS, and the general electronic control 7
As opposed to statistical sampling where random cases are selected from a larger population.
16
unit, GECU). In the on-going New APESS project (half-way into the project during the time of this study), there was potential for introducing a web-based project management tool between the collaborating firms (via the PAM project). The previous development of the APESS system was just finished and could serve for comparison (of an “as-is”-“to-be” situation, as described for example in Profozich 1998). The previous APESS development served also as an example of relationship management for the product life cycle, when an outsourced product development project is finished. In order to be able to map the complete collaborative product development process, the third project, development of the GECU, was chosen, since it was just about to start at the time of the empirical study, and gave an opportunity to study the early phases with “make or buy” decision and selection of supplier. Altogether these cases were estimated to give a good view over the complete collaborative product development process, something that is further discussed in section 2.3 (Method for Analysis). The IT track studied comprised development and implementation of IT (web-based) tools, the project management tool and others, for communication between the buyer-supplier parties in product development activities. These were complemented with extensive studies at IS/IT provider companies and benchmarking studies at similar companies (Boeing Military and Boeing Commercial). Moreover, research results were exchanged with a similar project conducted within the American LAI program (Antonelli 1999, see Kandebo 1997). 2.3.2
Case Selection Part II
The findings from Part I concerned dyad cases, where the product development activities carried out at the firms studied were not integrated but only coordinated. Moreover, a result from Part I was that the supplier had to manage a large number of subtiers. These results motivated me to conduct a complementary case study from the supplier perspective instead of the buyer perspective as in Part I. In Part II therefore, the population could be labeled: “product development carried out by a supplier network, studied from the supplier’s perspective”. Compared to the larger firms in Part I, the other polar type small business was studied here. The cases included different kinds of products and were conducted at various industries. Selection of cases was done from about thirty
17
identified Swedish supplier networks in the manufacturing industry, of which a handful carried out interfirm product development (to our knowledge). These were contacted, and the three most appropriate cases in terms of number of firms involved (more than two) and certain degree of product complexity (based on number of parts, technical fields, and the user interface, as defined by Clark and Fujimoto 1991) were chosen for the study. Due to our requirements for product complexity, a manufacturer and developer of wooden houses was not selected. Compared to the product complexity in Part I (multi-role combat aircraft, a high-tech and very complex product), though, the products studied in Part II were more traditional and based on established technology. The IT track studied in Part II concerned development of a webbased communication platform for an SME network conducted in the form of action research studies. Studies of the IT infrastructure among the companies in the network were conducted, and a web-based standard solution was implemented in cooperation with an IS/IT company. The results of these studies are mentioned in Appendix C, and described in detail in Wennberg and Öhrwall Rönnbäck (2000). 2.3.3
Categorizing of Cases
In figure 2.3 the two parts are mapped according to their product complexity and interorganizational complexity (number of relationships to manage, eg Biemans 1995). Product complexity
PART I
PART II
Interorganizational complexity
Figure 2.3
Positioning the selected cases in Part I and Part II according to their level of product complexity and interorganizational complexity.
18
In order to further position the studied cases in a supply chain, figure 2.4 shows the firms in the cases studied schematically marked as parts of a supply chain. In the dyad situation in Part I, mainly the buyer and major supplier firms were studied, with the customer and subtiers only sketchily looked at. In the network situation in Part II all parties of the supply chain that contributed to the product development activities were studied.
Third - xth tier supplier
Second tier supplier
Part II: Three cases of product development in supplier networks
Figure 2.4
OEM or first tier supplier
Systems integrator
Customer and end-user
Part I: Three cases of collaborative product development in the aerospace industry
Positioning the empirical cases of Part I and II in a supply chain view. (OEM stands for original equipment manufacturer.)
The major unit of study was both in Part I and in Part II product development projects. Nevertheless, the empirical studies were not limited to the projects, but included descriptions of the participating firm’s business situation and organization in connection to the product development activities studied (a holistic approach, as recommended by Melin 1989). To be able to work with such a holistic view is, as previously mentioned, one of the major advantages with case studies (Yin 1989). The case studies have been conducted in several industries (aerospace and defense, construction, medico-technical), in various technical fields (mechanical engineering, electronics, and polymer industries), and different product complexity levels, with both high-tech products such as combat airplanes and more traditional product areas where the innovations involve mainly established technologies. The cases can be divided into three different types, as described in the discussion above: 1. Dyad studies of collaborative product development in the aerospace industry (Part I) 2. Studies of collaborative product development between a customer and several firms cooperating in supplier networks in
19
respectively the mechanics, polymer and electronic industries (Part II) 3. Studies of IT tools and IT projects and in dyads and networks, connected to the dyad and supplier network cases studied (Part I and II) 2.3.4
Data Collection
Table 2.1 below gives further details, regarding when the cases were studied, when the events studied took place (which were in some cases studied in real time, but mainly in retrospect), the firms studied, and where the detailed case description can be found, and the research project of which it was part. This latter, to take part of a larger project as a framework, had an impact both on data collection and on the analysis of the cases. To work in a group of several researchers can be a major advantage. According to Eisenhardt (1989), multiple investigators contribute with complementary insights and different perspectives, which may enhance both the richness of data collected and the likelihood of discovering new and interesting results. In both Part I and Part II of this research I took part in research teams where the researchers looked at the same empirical cases from various angles. Individual analysis was presented as tentative results within the research team, something that led to sharpened theoretical discussions as an important step of the analysis. This was a working method in both Part I (in the research project LARP) and Part II (in the research project NISAM). It is recommended as a strategy for several reasons; the enhanced confidence in the findings, where the researchers’ convergent or conflicting perceptions prevent the premature closing of the data collection of a case especially worth mentioning (Eisenhardt 1989).
20
Case
When the studied events took place Collaborative product development cases Saab product 1997 Continuously development APESS 328 1998-1999 1995-1999 New APESS
Time period for the study
1998-1999
1997-1999
GECU
1998-1999
1998-1999
Weapon lock
1999-2000
1998-2000
Ventilation control system Platelet meter
1999-2000
1998-2000
1999-2000
1998-2000
Firms studied
Case description in Appendix
Research project
Saab
A
Saab, Microturbo (FMV) Saab, Sundstrand Power Systems (FMV) Saab (Ericsson Radio Systems) FMV-supplier network with 5 firms and other organizations, VMU ABB-supplier network with 5 firms, SLIT Fält Elektronik – supplier network of 10 firms, PUCK
A
ENDREA PhD course LARP
A
LARP
A
LARP
B
NISAM
B
NISAM
B
NISAM
IS/IT projects PAM, VEGA, EMPIRE www.puck.se
1998-1999
1998-1999
Saab, IS/IT providers
A
LARP
1999-2001
1999-2001
(B)
IMIE
AWACS Costran
1998 1998-1999
1997-1998 1998-1999
PUCK and member firms, IS/IT providers Boeing Military Boeing Commercial, IS/IT providers
(A) (A)
LARP LARP
Table 2.1
Overview of studied cases, time period, companies, and research projects. The cases are described in detail Appendix A and B, except the IS/IT projects which are only briefly mentioned in these appendices.
The participation in the Lean Aircraft Research Program (LARP) set the empirical framework of Part I, with focus on the special conditions for the aircraft industry, especially the relationships between a systems integrator firm, its customer and major suppliers. Part I of this research lay within a sub-project with the objective "to make the integrated product development process in the buyer/supplier relation more effective in all phases through use of information technology, standardized data and integrated development tools".8 Part II was carried out mainly as a part of the national project NISAM9, initiated by a research institute to enhance knowledge about industrial networks. Dealing specifically with product 8
9
LARP was organized in subprojects, where this subproject was number 4, consisting of two parallel tracks; 4A - Use of model-based tools in the early phases, a study conducted by Göran Backlund, ENDREA (licentiate thesis 2000), and 4B - Web-based infrastructure in collaborative product development, which is this specific research. See www.liu.se/org/imie/larp and NFFP report no 361 (Nationellt Flygforskningsprogram, the Swedish National Aerospace Research Program). The NISAM (Ny Industriell Samverkan) was sponsored by the Swedish National Board of Science and Research (NUTEK). See http://extra.ivf.se/nisam.
21
development, this subproject10 was one of about ten within the research program. Data collection was carried out in the form of interviews, meetings and on-site observations. In total approximately 60 interviews and meetings were carried out in 25 different companies during 19972000. These are listed for Part I in Appendix A and for Part II in Appendix B. Of the cases presented in table 2.1, the collaborative product development cases were studied in-depth. This means that several interviews and meetings were held with integrated product development team (IPT) members (mainly engineers from various disciplines, but also marketing and manufacturing professionals), product development managers and project managers, purchasing managers, and logistics managers. Especially in Part I also on-site observations were carried out at the focal firm. This was done only to limited extent in Part II of the study, mostly because of the large number of firms included in the study and the special characteristics of SMEs, whose activities often depend on one or only a few key persons. Interviews were carried out around the question areas presented in Appendix A (Appendices I and II) and Appendix E. All interviews and meetings were typed and summarized as soon as possible after they had been carried out (usually the same day). Most were also recorded and stored on tapes and CDs. A more thorough discussion about data collection in the in-depth case studies is given in Appendix A, section 3.2.4. The studied IS/IT projects presented in table 2.1 served more as a complement to the collaborative product development cases. Mainly the project managers and the software providers were interviewed. The exception lies in the PUCK case, where action research was carried out, including implementation of a web-based communication platform and about ten training occasions and seminars for the network member firms, as well as some hands-on training on site for some of them. Thus, the PUCK case can also be considered as an in-depth case study, although fewer formal interviews were carried out. However, since the web-based platform was implemented for use in the supplier network in general, and 10
The objective of the subproject was: “To increase knowledge about how firms in company networks can communicate and cooperate efficiently between each other and with a customer (systems integrator) throughout the product development process. From a company perspective, the goal is that this knowledge shall increase understanding for cooperation between individuals in distributed product development projects and the role of the customer in such project. An academic purpose is to spread generalized knowledge about new perspectives, new organizational forms, and new tools for distributed product development.”(Translated from the project plan in Swedish.)
22
not specifically for product development, it is considered as peripheral to this dissertation and not described in-depth here (see Wennberg and Öhrwall Rönnbäck 2000).
2.4
Method for Analysis
2.4.1
Within-Case and Cross-Case Analysis
The analysis carried out in this research is strongly empiricallybased, and as such it is important that the researcher becomes closely familiar with each of the cases studied, as Eisenhardt expresses it: the overall idea is to become familiar with each case as a stand-alone entity (Eisenhardt 1989:540)
Within-case analysis was therefore carried out for each of the collaborative product development cases, as reported in the case descriptions in Appendix A (chapter 4) and in Appendix B (chapter 3). Writing down the case descriptions was done by an iterative procedure, alternating between data collection and withincase analysis. In parallel, cross-case analysis revealed any missing data in the cases, and if so, need to make complementary data collection before the cases were closed. The use of the same data collection instruments in the cases within Part I and within Part II respectively facilitated this cross-case analysis. Further, the iterative procedure of within-case analysis, cross-case analysis, and complementary data collection made it possible to describe the studied cases with the same categories for the cases that were studied for sampling purposes (two cases in Part I and three cases in Part II), as accounted for in table 2.2.
23
Part I The systems integrator
The supplier
- General about the project - The product - Experiences from the project - Integrated product development at the supplier (product development organization, - Systems development development of complex system - Information exchange products, project organization, process descriptions and refinement of the - Current use of IT at the process) supplier - Collaborative product development, Formal information exchange and collocation (with major suppliers) - The IS/IT vision, current use of IT and development of future applications, restructuring the IS/IT function - IT communication between the systems integrator and the supplier
Table 2.2
Part II Collaborative product development in supplier networks
- The supplier network studied - Local network - Product network - The collaborative product development - Product development assignment - Buyer-supplier relationship - Supplier network relationship - Product characteristics - Risk and intellectual property - Outcome
Descriptive categories for the studied cases of Part I (the systems integrator studied in-depth and the buyer-supplier dyads, see Appendix A) and Part II (collaborative product development in the three supplier networks, see Appendix B).
Moreover, this categorizing of the cases was an important analysis tool. Hopefully these categories also facilitate the reading of the cases. In Part I the three collaborative product development cases were used to complement each other in the mapping of the collaborative product development process (shown in Appendix A, figure 3.3, which resulted in figure 5.5), a illustrated in figure 2.5. The three cases also served for theoretical sampling purposes, since three different firms were studied in order to increase understanding of integrated product development and management of IT for product development. These three were Saab and two of its major suppliers, Microturbo and Sundstrand Power Systems. The third supplier was not studied in-depth, since it as being selected during the course of the study.
24
GECU start: late 1997 New APESS start: early 1997 APESS 328 duration: 1994 -1998
Figure 2.5
The three cases of Part I (GECU, New APESS, and APESS) complemented each other for the mapping of the collaborative product development. (See Appendix A, figure 3.3 and 5.5.)
In the analysis of Part II the collaborative product development cases in the three supplier networks were used for theoretical sampling purposes. Part II was carried out in two steps of data collection, with thorough analysis carried out in between the phases, for example cross-case pattern analysis of the cases studied, ie setting various observed patterns against each other (for instance product modularity and distance between collaborating partners). The analysis after the first step revealed a need to complement data collection with the customer perspective. A new question guide was therefore developed (Appendix E). This working procedure when question guides are refined, and complementary cases are added successively as a result of ongoing within-case and cross-case analysis is common in case studies for theory building, according to Eisenhardt (1989). Finally, the results of Part I were compared with those of Part II (in Appendix C). Thus, cross-case searching tactics were applied between Part I’s buyer perspective and dyad cases and Part II’s supplier perspective and network cases. Concerning analysis of “use of internet-based IT support for collaborative product development” the cases in the two parts served for theoretical sampling, of the population collaborative product development of physical products with polar cases: large firm – SME, dyad – network, close relationship – arm’s-length relationship (during development), integrated collaborative product development – 25
coordinated collaborative product development, complex product – simple product (in several different industries and with modular or integral architecture). 2.4.2
Analysis Individually and in Research Teams
Analysis was carried out in research teams with researchers from different areas and with different theoretical backgrounds, where investigators who had carried out data collection on the field worked together with those who had not taken part in the interviews and meetings. Eisenhardt (1989) recommends this kind of cross-case analysis, since it can reveal new connections and patterns in the data (that the human mind hardly discovers due to our limitations as data processors!). Within the LARP project, the results from the data collection were discussed at project meetings both internally in the research group, and externally together with representatives from industry (up to fifteen people in a conference room). These meetings were important for interpretation of the data. Besides these group meetings, before as well as after, the individual researchers in the team compared the empirical data with existing literature and previous studies. Preliminary results were often the basis for discussions. Thus, a pure grounded theory methodology (Strauss and Corbin 1990) was not applied during Part I. I agree here with criticism against the overconfidence in coding and disregard of the data’s dependence on theory, as presented by Alvesson and Sköldberg (2000). In Part II a similar method for data analysis was applied. However, in this case the research team of about twenty researchers met less often, and the meetings with the industrial reference group had more the character of reporting meetings when the researchers presented their results, whose relevance and significance for industry were discussed. The analysis work took place mainly in smaller groups of researchers who worked together on subprojects. These smaller groups were often distributed (from different universities and research institutes) and therefore telephone conferences were common. Writing took place by individuals sharing the same document that was sent between the team members (and stored on a common web-based project platform). During meetings mainly the empirical data was analyzed. The theoretical background to the phenomena studied
26
was discussed when complementary interview guides were worked out, and when writing articles together (see Appendix D:[12], [13]). Besides the analysis in groups of researchers with contributions from reference groups from industry, most of the analysis was independent and individual work where I went through interview protocols, tapes and written material on several occasions both before and after having read other researchers’ earlier results. The interpretation of the results as I present it in this thesis is therefore my own, yet with influences from the above mentioned procedures. 2.4.3
Choice of Literature
The literature reviewed for this research has been a winding journey over a large number of theoretical fields, since previous research on collaborative product development derives from various underlying theoretical fields, eg business strategy and outsourcing literature (eg Sanchez 1995, Nischiguchi 1996, Quinn 2000), including strategic purchasing and interorganizational relationships (eg Gadde and Håkansson 1993, Lamming, Cousins, and Notman 1996), and engineering management (eg Allen 1977, Andreasen and Hein 1987, Pahl and Beitz 1996, Rechtin 1991), and also works based on the social science (Burns and Stalker 1962) and sociotechnical fields (Pava 1993) have come across. Moreover, the younger field of IT management has been explored, with authors such as Keen (1991) and Zuboff (1988), and especially the IOIS area (Fulk and DeSanctis 1995, Kumar and van Dissel 1996), which also is based on different theoretical areas. Both conflicting literature and literature supporting the emerging results and discussions have been used to develop the theoretical constructs.
2.5
Reflection on the Quality of the Research Study Measures taken in this research to enhance the quality of the study are, to summarize discussions in this chapter, 1) a listening attitude in interviews and meetings with respondents, and being careful not to influence the respondent with my own opinions or attitudes, 2) disregard of previous research and extant theories during field work (data collection), 3) constant iterations of data
27
collection and analysis, 4) feedback from respondents on fieldnotes, 5) research team evaluation of early constructs, 6) review of early constructs by reference groups with representatives from empirical case companies and projects, and 7) comparison between constructs and extant literature (both conflicting and agreeing). Quality of this research can be discussed in terms of if the emergent theory generated from the case study has novelty value, is testable, and is empirically valid (internally and externally). Eisenhardt (1989) categorize these three measures as strengths of theory-building case studies. Weaknesses on the other hand mainly deal with the generalizability of the study. Eisenhardt mentions that the theory can be so rich in detail that it lacks the overall perspective, that the results are linked too much to the individual cases studied, and, in close connection to these, that they rarely lead to “grand theories” but rather to supporting some extant. Such aspects, which are recognized for this study, represent the risk with case studies attempting to be theory-generating and are taken into account in the following discussion. Yin (1989) presents a useful framework for quality assertion for case studies, which will be used to describe measures taken for quality. In order to construct validity, multiple sources have been used for the empirical study (interviews, meetings, observations, internal company documents such as requirement specifications or product development software tools, etc), and key respondents have participated in reviews of documents and oral presentations of intermediary result. The tactics for internal validity has been to work with explanation building as an iterative process between individual analysis of data and discussions of constructs in the research teams. External validity was aimed at with three cases in Part I and the multiple case study in Part II. However, although a large number of interviews, company visits together with observations, and collection of secondary sources, the studied sample is small. This limitation to generalize is an inbuilt problem of in-depth case studies (Eisenhardt 1989). As often recommended for case studies (Merriam 1994), I have tried to provide enough information on the cases studied, the data collection procedures, the analysis, and evidence for the constructs, in order for readers to make their own assessment of whether the resulting theory fits or not, and could be generalized from or not. 28
3
Frame of Reference
This chapter contains a brief summary of the theoretical framework for this research and definitions of key concepts used in the thesis. More ample theoretical background is presented in the three appendices A-C.
3.1
Definition and Discussion of Key Concepts Collaborative product development includes always a business relationship between the parties, which makes it different from inhouse product development. In general, the buyer-supplier relationship is changing and the interaction between cooperating companies is growing increasingly complex, as some authors claim is due to the possible interconnectivity with information systems and the internet (Bettis and Hitt 1995, Chandrashekar and Schary 1999, Lambert and Cooper 2000). Concerning business relationships in general, Gummesson (1995) speaks of the many-headed customer and the many-headed supplier. There is no longer one-to-one communication between cooperating companies. Instead, individual contacts have shifted towards multiple team contacts at several levels simultaneously. Moreover, there is a need to assess the relationship instead of onesidedly evaluate the supplier (Lamming, Cousins, Notman 1996), and find a strategic management approach to how firms can gain a sustainable position within a supply and value chain (Cox 1996). Several authors call for a more dynamic view of how the firm shall manage its network relationships in supply and value chains (Miles and Snow 1994, Ciborra 1996), since business relationships of this kind can involve everyone in the firm, not only the purchasing department. Reciprocally, with more supplier contacts in several business processes, purchasing has an important strategic function in eg product development (Wynstra 1998). Questioning existing theoretical organization models, Ciborra 29
(1996) suggests for example the platform organisation as a new concept for firms to obtain the flexibility and dynamism needed to manage technological discontinuities and changing organizational borders. Some clarifications of key concepts for this work are required. To start with, the terms collaboration and cooperation will be used synonymously in this work. Collaboration has become the generally accepted term used both in theory and in practice to denote business cooperation when two or more companies join their efforts to reach common goals, for example in collaborative commerce (c-commerce) or in collaborative product development (CPD). Further on, in this work, coordination of collaborative product development refers to mapping activities against each other and to see to that input and output is delivered when needed (in the general meaning for organizing business activities, as eg in Mintzberg 1983). Third, the difference between coordination and integration is central. Integration refers to the IPD concept, ie that crossfunctional integration is required for more efficient and effective product development. Andreasen and Hein (1987) present the product development process as a three-folded process of parallel activities in marketing, manufacturing and traditional R&D activities. IPD has given birth to the expression integrated product development team, abbreviated as IPT, commonly used in the American literature and firms to denote the multifunctional team that works with a product development assignment (eg Fine 1998). An IPT consists in general of representatives from marketing, manufacturing and the technical areas needed for the development. Integration in product development is a means to coordinate closely linked activities and functions in the product development process. IPD in collaborative (interfirm) development is needed when a necessary functional area lies outside the firm. According to Ragatz et al (1997), to integrate suppliers in the new product development work depends on the firm’s willingness to share assets, including (1) intellectual assets, such as customer requirements, technology information, and cross-functional communication, (2) physical assets, such as linked information systems, technology, plant and equipment, and (3) human assets, 30
such as project team participation. Lambert and Cooper (2000), with a similar definition of integration in supply chain business processes, question how many suppliers that a buying firm actually can manage to work together with in an integrated manner. They illustrate this from a supply chain management perspective with figure 3.1, referring to this as cross-functional business process integration “penetrating functional silos within the company” (p 66), where product development is one of a number of processes, as illustrated in figure 3.1. The authors also show that information flow between the parties is one of the main challenges in order to obtain an efficient supply (or value11) chain. A supply chain management perspective on product development does not stand in conflict with the criticism against the supply chain view on product development presented by Clark and Fujimoto (1991). Their argument that the traditional view of flow of materials from supplier to manufacturer to marketer and out to the customer should be revisited and changed into a flow of information instead, from product concept that takes input from the customer, is thus coherent with the previous discussion of product development work as an iterative process, rather than a straight-forward chain. Supply chain in this context refers to the different parties involved, from the end-user and customer (which can be separate entities) to the systems integrator, major suppliers and subtiers of different orders (first, second, etc), and is the established terminology in the logistics and purchasing literature (Christopher 1994, Cox 1996, Wynstra 1998).
11
Value chain and supply chain (and value net, see Nalebuff and Brandenburger 1996) are used in the same sense (as in Fine 1998).
31
Supply chain business processes
Information flow
2nd tier supplier
1st tier supplier
Focal company
Customer
End-customer
Product flow Company functions Customer relationship management Customer service management Demand management Order fulfillment Manufacturing flow management Procurement Product development and commercialization Returns
Figure 3.1
Information flow, key supply chain business processes to coordinate or integrate, tier suppliers, focal firm, customer and end-customers (Lambert and Cooper 2000:67)
Fourth, efficiency of individual product development projects means that a project meets its target without waste of resources (eg time and budget). One of the keys for obtaining higher efficiency is that cross-functional communication and information flow in a project team can be obtained (Allen 1977, Clark and Fujimoto 1991). This is challenging in collaborative product development, where the project members either are distributed on separate coordinated IPTs, or are organized in one IPT with functional representation from team members in separate firms, who needs both to integrate and coordinate their activities. In any case, not only efficient but also effective product development needs to be considered, ie regarding the actual output of the development. Of significant importance is to obtain a product that is effective throughout its complete life cycle, ie that it respects requirements for eg manufacturing, spare-parts, further marketing, and future development (Pahl and Beitz 1996). When product development is carried out with several participating firms, their collaboration may continue throughout the product life cycle. Going further than regarding only the 32
single product, into the direction of long-term effects of collaborative product development, communication and information flow also touch upon management of core competencies such as the in-house knowledge base (Håkansson 1987, Nonaka 1994), intellectual property rights (Biemans 1995, Sawhney and Prandelli 2000), and management of competing supply chains and networks, in which current and previous partners may take part (Chandrashekar and Schary 1999). Moreover, it should be pointed out that an efficient process not automatically leads to an effective product, and that the efficiency measures may vary from case to case depending on the characteristics of the product and the industry (Eisenhardt and Tabrizi 1995, Fine 1998).
3.2
Organization of Collaborative Product Development Product development is recognized as one of the most complex activities of the firm, due to the high degree of uncertainties; the difficulty to estimate future demand often on fast changing markets, working with new, quite unknown technology fields, difficulties to estimate cost and time required, but most perhaps, since innovative activities are depending on a well-functioning communication between individuals from various background (Griffin and Hauser 1996). As Lundqvist puts it: …organizing product development activities is an ongoing process of defining, assigning and controlling tasks in a dynamic temporary work system that eventually yields a new product (Lundqvist 1996:19)
The most common organizational form for product development in industry toady is the project, which with its focus on deadlines (time-limits) and temporary relationships fit well for conducting engineering tasks (Söderlund 2000). Often mentioned as a challenge in product development is the fuzzy front-end and the requirement specification of a forthcoming product (Wheelwright and Clark 1992). From the systems engineering perspective, Rechtin (1991) draws a picture of how the requirements for a new product can be divergent and contradictory. 33
Function Simplicity
System requirements
Human needs
Fit Balance Compromise
Complexity
Figure 2.5
Form
Affordability
Environmental imperatives
Requirements for a forthcoming product might be contradictory, and cause tensions in systems design. (Rechtin 1991)
In the engineering management field, Pahl and Beitz (1996) argue that requirements are often inconsistent and ambiguous. Smith and Reinertsen (1998) illustrate how the shared vision of the forthcoming product may cause misunderstandings within a firm, among all the individuals who have expectations of the new product. (Illustrations in Appendix A, figure 2.5 and 2.6.) Takeuchi and Nonaka (1986) suggest the Japanese term “sashimi” to illustrate how activities should be carried out overlapping, or even as a “rugby”-like organization where several simultaneously ongoing activities are supported. Both are means to compress project time and to avoid thrown-over-the-wall behavior, which was common previously when separate departments carried out their part of the development and handed it over to the next department to get rid of the problem (Dussauge, Hart, and Ramantsoa 1987). IPD and IPTs are now generally accepted in firms and such behavior is more and more rare, as the empirical cases have shown in this thesis. Also the results of Lundqvist (1996) show that the sequential waterfall view is rarely used in firms and does not represent the actual course of events in product development activities, and if so mainly as to create a mental image that may be easier to grasp. For example, standards describing the buyer-supplier process may still use such notations (eg Mil-STD-881B). Also in research the waterfall model can be useful to delimit the product development process and show which process activities are referred to (Ragatz, Handfield and Scannel 1997). As such it is used in Appendix B to describe the empirical cases studied. In practice though, the product 34
development process is highly fractal (Lundqvist 1996) consisting of interacting, dependent tasks (Eppinger, Whitney, Smith and Gebala 1994, Appendix A). Allen (1977) investigated the communication between engineers in technology work, and found astonishing results of the importance of distance, showing that already short distances between engineers or a stairway is an obstacle for communication. His research has probably contributed to the nowadays widespread practice to collocate IPTs to enhance communication in product development work (Smith and Reinertsen 1998). Nonaka (1994) has from a product development view generalized this area to organizational knowledge creation for the firm. (See figure 2.9 in Appendix A.) Information sharing in collaborative product development is often highlighted as one of the most important, but also most difficult managerial issues. Many authors report shortcomings, and needs for improvements to achieve more successful collaborative product development (Biemans 1995, Bruce et al 1995, Ragatz 1997. Parker 2000). Information and communication management, as well as knowledge management, are extensively studied fields in product development within a firm (eg Kerssens van Drongelen el al 1996, Nonaka 1994), but for collaborative product development it is a relatively unexplored area. It is also a difficult one since there is almost always, even between the closest firms, competition between firms, and for example Cox (1994) argues that win-win relationships hardly exist. Transitory supply chains, where firms risk losing a partner to a competing supply chain are also common threats to an open attitude to knowledge and information sharing between firms (Chandrashekar and Schary 1999). Nevertheless, von Hippel (1988) showed in a large quantitative study the importance of external organizations for innovations, and Quinn (2000) maintain outsourcing of innovation as a method for survival for most firms since the demands on innovation becomes more and more complex and resource-consuming in almost all industries. Helper 1996 has discussed incentive mechanisms for improved management of supplier relations in collaborative product development. Her suggestion is to manage through voice instead of exit, in order to build long-term, stable relationships where the buyer develops the supplier or the supplier network towards the wanted direction, instead of interrupting (exit) if anything goes 35
wrong in the collaboration. This is in line with research on supplier relationships by Lamming et al (1996) and Cox (1996). The view on building strong relationships for long-term collaboration with important partners is hand in hand with the life cycle perspective on product development (Pahl and Beitz 1996). The life cycle of any product can be split in these three phases: -
New Product development (from concept to finished product) Product in service Product decline (and if possible recycling)
If a supplier develops major subsystems of a system product it cannot easily be replaced. The relationship shall often last as long as the product is in service, which for some products may be 10 years or longer. This perspective is important to have in mind during a development project, which may last during a tenth of the product life-cycle period. Several software providers (eg HP, IBM, PTC, and several others) in the product development field currently promote a supply chain management perspective, and many expressions are used, where the most common seems to be Collaborative Product Commerce12 (Verkstadsforum 2001), denoting IT supported collaborative product development. This leads to the topic of the next section; interorganizational IT support for product development.
3.3
Interorganizational IT Support for Product Development In product development, both in the literature and in practice, IT tools and IT platforms (where several tools are interlinked more or less seamlessly) are often suggested as a means to facilitate communication in order to seek shortened product development cycle time and improved quality of a forthcoming product (eg Allen 1986, Wheelwright and Clark 1992, Nonaka 1994, Smith and Reinertsen 1998). Moreover, as the internet in recent years has
12
Also other terms are seen, differ from different providers, eg PLC (Product Life Cycle) management (from IBM).
36
become a widespread communication channel, distributed work teams have turned out to be an increasingly widespread organization form (referred to as virtual by Mankin, Cohen, and Bikson 1996 and Lipnack and Stamps 1997). The internet is used as a channel for fast, standardized transmission of information, mainly via e-mail, but also as a tool for information search with mark-up languages via web browsers. Recently, a large amount of web-based project and engineering tools have become available for interorganizational product development (Verkstadsforum 2001, Ny Teknik 2001). The internet and web-based IT support could provide an interesting solution both in supply chain management in general (Chandrashekar and Schary 1999) and specifically for collaborative product development (Johansson 2000). In practice, there are several examples where improved communication via web-based, standardized systems in product development over company borders has enhanced execution for the participating firms (Holstein 2001, Reese 2001, Howe, Mathieu, and Parker 2000, Mecham 1998). Some examples are: -
-
-
For the distributed development team, CAD13 tools provided with interactive viewers that show drawings and models in 2D or 3D combined with web cameras that show project members, displayed on the same screen, make it possible for engineers at one site to follow the work of engineers at another. Changes on the drawings are immediately visible at the others’ computer screens. Microphones and loudspeakers make it possible to discuss design suggestions in real-time. (Isaksson et al 2000) Standards such as STEP14 make it possible to exchange data between different CAD systems (Johnson 2000, Johansson 2000). Web-based communication solutions for teams, so called groupware, provide interactive communication on eg requirement specifications, discussions on design, or project management communication (eg schedules with planned activities in Gantt15 charts and appearing to-do’s, time reports, and notifications, ie “alerts” of events and tasks that come up). (Appendix A, Wedlund 2000)
13
Computer Aided Design Standard for the Exchange of Product model data (ISO-10303, AP 214) 15 A Gantt chart is a way to present activities of a project with bars along a horizontal time axis, see eg Lock (1996). 14
37
-
-
-
-
Web-based solutions built on database technology make it possible to structure the information at the right place once and for all. This work method should be compared to paperbased, telephone and e-mail communication, where information is duplicated several times at various locations and often communicated ad hoc (which makes it difficult to trace and to communicate eg to new-comers to a project, or makes it impossible to gather to obtain a strategic overview). (Appendix A, Howe et al 2001) Product data can be shared between two or more firms in a common PDM16 system, where the firms can have different number series in order to simultaneously manage their data in each parties’ own PDM system, for further export to internal manufacturing or ERP systems. (Carlsson and Idegren 2000) Some software providers also offer systems combining collaborative sales and product development under the notion collaborative commerce. This requires usually, but not always, integration with the legacy systems (for sales and invoicing) of each firm. (Verkstadsforum 2001) Yet other tools are mobile devices connected to the internet that enable for marketers or engineers working on the field (eg at a trade event or visiting a customer or a partner plant) to send updated information back home in no time. This kind of IT tools provide interactive team communication regardless the distance. (Kessler 2000)
To conclude, the trend in IS/IT support for product development is that through web-based applications using TCP/IP17 for data transfer, standardized data formats such as STEP, XML18 and sql19 databases for data exchange, and standardized programming languages such as Java for integration of applications, interesting solutions for interorganizational communication between both large and small firms can be obtained where only a web browser is needed at the user’s computer. In cases when technical drawings need to be exchanged, a CAD system that supports STEP is still required (or other tools needed for the specific development, such
16
Product Data Management Transfer CP/Internet Protocol 18 eXtensible Mark-up Language 19 standard query language 17
38
as CASE20 tools, based on standards for data export to and from other systems), but with web-enabled viewers. This puts higher requirements for the web server and the databases concerning stability and security, as a platform for system integration, which depends on the needs of the organization. Also, more widespread and better knowledge among users of secure handling of devices and data is required (Kessler 2001). Several vendors21 of IT services and tools present solutions combining the most commonly needed tools for collaborative product development. However, despite these trends of fast development of information technology for collaboration in product development, the previous studies conducted for this dissertation indicate a limited use so far, besides successful small-scale experiences of implementations and use of interorganizational IT tools in collaborative product development (Antonelli 1999, Appendix A). This can be due to the complex environment that each of the participating firms operate in, where transitory supply chains (ie that firms may change supply chain and become competitors) set tough requirements for secure but flexible and therefore highly standardized IT solutions, which may stand in conflict with the need to tailor the solutions for the prerequisites of the individual firm (Chandrashekar and Schary 1999). Also other IT supported communication tools such as video conferencing have been rarely used even in large-scale collaborative development.
20 21
Computer Aided Systems Engineering For example IBM’s E-business Solution for Product LifeCycle Management, CoCreate’s OneSpace, PTC’s Windchill, or Eurostep’s Share-A-Space.
39
40
4 Critical Issues of Collaborative Product Development In this chapter the first research question is dealt with: the special characteristics of information and communication in collaborative product development. These are described in two sections; first for the dyad relationship, and second for the network relationship. Since dyadic relationships were found not only in the systems integrator-major supplier relationship, but also between buyer and supplier network, the dyad part is based on empirical studies of both Part I and Part II of this research. (See case descriptions in Appendix A and Appendix B.) For the network relationship, information and communication in collaborative product development are based on Part II (Appendix B). Findings from these cases are related to intraorganizational product development in the literature.
4.1
Collaborative Product Development in the Dyad
4.1.1
Coordinating Independent Product Development Processes
When this research set out in Part I, one of the first areas to investigate empirically was the collaborative product development process. However, quite soon it stood clear that between the systems integrator Saab and its major suppliers there was not one such process, but rather one at each of the participating firms. These processes were not integrated, but coordinated, according to definitions by Ragatz et al (1997) and Lambert and Cooper (2000). We noticed the difference from how Saab worked with its partner (and part-owner) British Aerospace, with whom there was ongoing work to map the integrated product development process of one firm 41
to the other’s in order to work closely together. (The business process alignment with British Aerospace is mentioned in Appendix A, and reported in Andersson et al 1998.) This result of mapping the collaborative product development between the systems integrator Saab and its major suppliers (as accounted for in 2.3) is shown in the process map in figure 4.1 below.
Systems integrator
Common activities
1 2 6 7 10 13 16 19 22 25
3 4 8 11 14 17 20 23 26
Commission to develop new system Define system requirements Choose supplier Prepare contract Analyze system requirements Prepare preliminary design and prepare review Detailed design Design and manufacture Integrate and test system and prepare audit Prepare 1st production unit and physical audit
Figure 4.1
Study concept Cost estimate, prepare and submit quotation Review contract Analyze system requirements Prepare preliminary design and prepare review Detailed design Design and manufacture Integrate and test system and prepare audit Prepare 1st production unit and physical audit
Major supplier 5 9 12 15 18 21 24 27 28
Evaluate system concept and review quotation Sign contract Review of system requirements Review of preliminary design Review of critical design Review of test readiness Audit functional configuration Audit physical configuration Deliver 1st article
The collaborative product development process: coordination between buyer and supplier, with common reviews where the parties meet. (See also figure 2.5 and Appendix A, figure 5.5.)
At each party, an IPT was working with the product development and needed to coordinate their activities with the other party, in order to get the input required at the right time. The flow chart also shows iterations back to previous activities (dotted arrows). Such constant iterations in product development work are stressed also in the product development literature in general (Denker et al 2001), but causes in the collaborative product development case also loops back to contractual discussions which may be delicate, especially if they are due to initial misunderstandings between the parties. Danilovic (1999) showed the dependence between buyer and supplier with a design structure matrix (DSM) for the project studied, and recommends such tools in order to discover possible
42
sources of misunderstandings and be able to take precautions as early as possible. Downstream of the supply chain, Saab had all the contacts with the customer FMV22, which did not take part in the common reviews with the major supplier. This was a shift during the past decade towards cleaner and fewer interfaces between parties in the supply chain. Upstream, for the same reason, Saab did not manage the supplier’s subtiers, although these could have a significant impact on the outcome. The same pattern was seen in the buyer-supplier network relationships studied. Although the parties in the cases said that there was an open relationship and open communication in the buyer-supplier relationship (except in the weapon lock case, where a formal public tender was conducted during the development and the communication was not open until after the supplier was selected), there was not a question of integrating the suppliers into the buyer’s development process according to the description by Ragatz et al (1997) above. Also here, the supplier activities were coordinated against the buyer’s development, for example with deliveries of certain results to agreed dates according to the buyer’s product development project. The buyer also preferred to deal with one party, who represented the network, as discussed in Appendix B. The conclusions drawn from these cases are illustrated in the figure 4.2, ie that the dyadic buyer-supplier processes are coordinated.
22
Försvarets Materielverk,The Swedish Defense Materiel Organization
43
New Product Concept
BUYER
New Product Concept
BUYER
Product Specification System Product and Process Engineering product
Product Specification System Product and Process Engineering product
Product integration and Preparation for Production
Product integration and Preparation for Production Product Acceptance, Production, Market Release, Delivery
Product Acceptance, Production, Market Release, Delivery
COORDINATION
COORDINATION
New Product Concept
SUPPLIER
SUPPLIER NETWORK
Product Specification System or Product and Process Engineering subsystem Product integration and Preparation for Production Product Acceptance, Production, Market Release, Delivery
Figure 4.2
New Product Concept Product Specification System or System or Product and Process Engineering subsystem subsystem Product integration and Preparation for Production Product Acceptance, Production, Market Release, Delivery
Coordination between buyer and supplier (left) and between a buyer and a supplier network (right) in dyad collaborative product development.
In the next section the special characteristics of the dyadic communication and information sharing will be accounted for, in relation to previous literature on product development. 4.1.2
Characteristics of Information and Communication in the Dyad
In line with Wynstra’s (1998) and Lakemond’s (2001) previous research on collaborative product development, it was observed that procurement had a central role. In some of the cases the purchaser was also a product development engineer, who previously or later conducted development of the same kind of product. This was the case when a buyer firm recently had outsourced its product development and manufacturing (Appendix B, 3.2) and when the buyer firm decided to insource (ie place in-house) development of a product that previously was developed by a supplier network (Appendix B, 3.3). In one of the larger buyer IPTs we saw how the purchaser’s role was first outside the team, and halfway in the development project was re-organized to lie inside the IPT. The change led to more efficient project management and fewer misunderstandings concerning contractual issues. (See Appendix A, 4.6.)
44
In all the cases studied, the procurement aspect of the collaborative product development led to formal communication in the early phases, before the supplier was selected. In the aircraft development, the work with the contract lawyers were involved at both sides, working together with experts in various fields, in order to estimate the outcome of the development project. Once the buyer had selected a supplier, the communication between the parties became more open. However, the amount of development work that was carried out before the supplier was selected varied in the cases studied, from the engineering firm that was chosen to make the first conceptual drawings, to the network that had to show a working, producible prototype before the buyers made their choice. Development work carried out between parties that are communicating formally becomes time-consuming if documents need to be sent on paper. Moreover, in the fuzzy frontend (Wheelwright and Clark 1992) of a development project, the use of only textual specifications can be a source of misunderstanding. In the aircraft system development studied, it was found that executable system simulations can illustrate system functionality in a more exhaustive way (see Appendix A, 4.6, and Backlund and Öhrwall Rönnbäck 1998). Systems development in the aerospace industry follows generally accepted standards23, which define the activities between buyer and supplier and the content of the various reviews in figure 4.1. For example, one of the standards depicts the content of the critical design review, CDR: A review conducted to determine that the detailed design satisfies the performance and requirements of the development specification, to establish the detailed design compatibility among the item and other items of equipment, facilities, computer programs, and personnel, to assess producibility and risk areas, and to review the preliminary product specifications. (Mil-STD-1521B)
When the firms studied in the aerospace industry (Saab and its major suppliers) defined their development models, they were largely based on these standards. Therefore, in the collaboration, the parties recognized the important parts mentioned in contracts 23
Edited by US Department of Defense (eg DoD-Milstd-499A) or IEEE (eg IEEE 610.12-1990). Read more about use of development standards for systems engineering at INCOSE, www.incose.org.
45
or project plans, although they were not identical. However, although the bases were the same, the parties also said it was difficult to harmonize development plans. We observed that the supplier adapted more to the buyer’s process than vice versa, and expressed a need for its visualization. The forthcoming system was described to the supplier via a detailed text specification. The specification was also part of the contract, and any changes to it were formal and had to be communicated in writing. The airworthiness regulations set high requirements on the formal communication between the parties. (See list of documents in Appendix A, 4.3.2.) In the second and third projects studied the use of model-based specification and test was taken into use (ie meetings in digital mock-up rooms, DMU, where virtual 3D models were evaluated before physical prototypes were delivered, as described by Robertson and Allen 1992 and 1993 and Thomke and Fujimoto 2000). This work method showed large improvements with less iteration than in previous projects. In the SME supplier development cases, there was not one basic standard process to adapt to. Even when the larger buyer firm had a standard process, it did not impose it on the supplier network. On the contrary, one of the buyers preferred the supplier network not to use such a formal method since that would limit the flexibility and speed of the innovative work. Then again, in the weapon lock case the supplier network had to adapt to the formal public tender process, but it concerned only the commercial part of the development process, and not how work was carried out in between the competition rounds (see Appendix B, 3.1). In all the three cases studied, black box methods for product specifications were used in order to enhance creativity and innovation with the supplier. Nevertheless, we observed that it was most successful when it was followed by intense communication in a gray box manner between buyer and supplier, for example daily telephone meetings during the concept phase, as in the ventilation control system case (Appendix B, 3.2). Concerning project management methods, each part of the aircraft projects studied followed their own method. Saab followed its generic project method PSM, while the projects studied at Microturbo and Sundstrand Power Systems followed a project plan closely linked to the development process. The same thing was observed in the SME cases. The buyers in all the three cases (FMV, ABB, Fält Elektronik) had their own 46
methods, and cared only for delivery of results (prototypes, products) from the suppliers, not specific project reports, and had no influence over the supplier networks’ project management procedures. In the aircraft projects, the teams at the systems integrator and the supplier were not collocated. Instead, one person from Saab had an assignment of one or two years to work at the supplier site. (Appendix A, 4.5.2 and 5.2.5.) Moreover, traveling between the parties was frequent, especially in the later phases for problem solving. When the collaborating parties started to use e-mail communication a new communication pattern appeared. From being a strictly controlled one-to-one communication via the project manager of each team, and via the purchasing/sales manager, the two teams had extensive communication between members on all levels. This is illustrated in Appendix A, figure 5.6 (Case I and Case II). The same formal procedures were followed, which meant that the most important e-mail messages and signed paper documents (fax sheets mainly) were stored in the project binders. Nor were the teams collocated in the supplier network cases. The development work took place at the suppliers’, but with frequent telephone dialog between buyer and supplier, and traveling when that was required. This dialog was mainly carried out between the buyer and the supplier project managers, something that was a problem in the case where the buyer had outsourced the project management function (Appendix B, 3.3).
4.2
Collaborative Product Development in a Supplier Network
4.2.1
Managing Interfirm Integrated Product Development
Collaborative product development in SME supplier networks appear to be fundamentally different from collaborative product development in the dyad. Here, the suppliers collaborate in order to act big together (the dynamic network definition by Miles and Snow 1994). In the supplier network therefore, the firms that participate in the product development represent different functional areas. This is illustrated in figure 4.3, showing a local network with member firms (see Appendix B), their different
47
functional units, and how some of the firms take part in an activated network.
Collaborative IPT F1 F2 F3 F7 F6 F5 F4 Firm that takes part in a product network
F9 F8
F2 F1 F4 F3
F6
F1
F6
F1
Local network
F3 F7 F8
Figure 4.3
F5
Firm that does not take part in a product network
F2 F7
F4
F1 F2
F3
F2
FX
Function in a firm
FX
Function in the activated product network
F4
F1 F4 F3 F5
Coordination between buyer and supplier (left) and between a buyer and a supplier network (right) in dyad collaborative product development.
Collaborative integrated product development (involving typically marketers, design engineers, and manufacturing engineers) can be obtained only when these firms join forces, since they are too small to be able to organize such cross-functional teams required for larger assignments on their own. It should be pointed out also that the same kind of functional unit might come from more than one firm, due to the firm’s small size. In the weapon lock case for example (Appendix B, 3.1), three of the collaborating firms had skills and equipment in the same field (precision mechanics). By organizing in networks, the firms obtained higher organizational flexibility, which can be compared with Ciborra’s (1996) platform organization that enables the mobilizing of organizational settings quickly depending on the requirements for a certain business assignment. In the cases studied, the network facilitated the fast formation of a project team for the firms and to set up a product network to respond to a customer’s demand. In the concluding discussion presented in Appendix B this kind of project team is called a collaborative IPT, or a C-IPT, and it was
48
found that its characteristics concerning information sharing and communication was quite different from the dyad case or intraorganizational product development. In the latter case, the functions are represented by departments within the corporation, which share premises, tools, an intranet, etc. In the dyad case the collaborative product development communication concern coordination of two separate IPTs, one at each party. Here, the CIPT is distributed over an often small number of independent firms. Suggestions on how information and communication can be managed are discussed in the next section. 4.2.2
Characteristics of Information and Communication in the Supplier Network
From the cases studied in Appendix B, we found results on the difference between supplier networks and intrafirm or dyad product development, especially concerning project management practices and product life cycle management. Since the product development is conducted by independent firms, which can be both collaborating and competing with each other at the same time, we found that neutrality is a key word in project management. It can be expressed either as a focus on time for evaluation of the results in the project. If the deadlines can be made visible to anyone in the project the parties can get a grip on their obligations and see things they have omitted, without having been told. An example of how this could be done is by using a note-board, either physical (if the C-IPT is collocated) or webbased on a project portal where delays are visible to project members. A web-based stage-gate control is also suggested by Howe et al (2000). The organizational allegiance of the project manager can be another way to obtain neutrality. When the project manager comes from a third party organization he or she can act for the best of the total project without the risk of seeming in favor of their own or some of the other firms. In order to communicate efficiently the C-IPT members either need to be collocated at one of the firms or at a neutral site (premises held by an external organization, eg the local network), as suggested by Smith and Reinertsen (1998) or use IT support for distant communication (Lipnack and Stamps 1996, Mankin et al 1997, and Duarte and Tennant Snyder 1999).
49
Moreover, we discovered that the firms participating in the networks showed a high degree of flexibility among the participating firms. It can be expressed as three kinds of flexibility: -
flexibility to set up a new organization fast through halfready organizational units flexibility to accelerate and move fast, and flexibility to change fast, if required.
The first type can be explained by the firm’s participation in a network, which gives structures that enable faster mobilization of a team or a product network, quite similar to the platform organization that Ciborra (1996) suggests for the network firm, or what Miles and Snow (1994) refer to as an activated network. The second type of flexibility is due to a firms’ ability to make decisions fast. It can be explained by its smallness, which leads to fewer decision levels. It is also common that the entrepreneur and owner of the firm participates in the product development assignment, and can then make decisions fast and be prepared to take certain risks, based on the business opportunities that he or she sees in it. In our cases, risk-taking lay in that people worked on their spare time (initially without payment), but also that they made some early investments in equipment before the order was won. In the dyadic relationships, even when the communication were more open, the product development decisions took in general much longer time, due to for example formal review processes with many parties involved. Since this flexibility seems to be an important competitive advantage for the SME networks, it must be protected even if the project management becomes more efficient, eg with IT tools. The project manager should be familiar with these characteristics of SMEs in networks, and skilled to manage them, as we suggest in the conclusions of Appendix B (5.2.2). The heavy-weight project manager (Dussauge et al 1996) with power internally in the team and externally may not apply. Biemans (1995) also suggests special consideration as to managing collaborative product development in networks, claiming that R&D managers may not be fit for the task. Concerning product life cycle, we saw that the collaborating firms organized early for continuous production of the forthcoming product by discussing production already in the concept phase. 50
This was quite natural since most of them were producing firms. However, we also observed that more knowledge of preparation for production and assembly was needed in the early phases. This is a traditional product development problem also in intraorganizational product development (and the base for the concept of integrated product development and methods such as Design for Assembly, DFA, or Design for Manufacturability, DFM), but collaborative integration may be more difficult to achieve if another firm, which, in some cases may not even be chosen yet, is to provide the manufacturing facilities. Fine (1998) suggests three-dimensional engineering to organize for efficient supply chain product development. However, Fine (1998) recommends that firms by selecting which projects to participate in, build up their knowledge base (Nonaka 1994) and supply chain network relationships, which may be useful for its coming opportunities.
51
52
5
Interorganizational Information Systems: Needs and Barriers
This chapter seeks to answer the second research question concerning needs of interorganizational information systems for collaborative product development, and barriers against implementation and use. It starts with a discussion of previous research in the area of information and communication and IOIS support in collaborative product development, which is followed by the results from the empirical studies of Appendix C (3-4), split into dyads and networks. The results are summarized in two tables where needs and barriers concerning IOIS in dyad and networks collaborative product development are listed.
5.1
IOIS for Collaborative Product Development
5.1.1
Information and Communication in Collaborative Product Development
The analysis of information and communication in the cases studied indicated that the product development process could in the collaborative setting be isolated neither from the procurement and sales process nor from the product life cycle aspects. Figure 5.1 (based on Lambert and Cooper 2000) was developed in Appendix C to conclude the analysis of information exchange between the parties. The figure illustrates parties in a supply chain that can take part in one or several product development projects, which, and this is not shown in the figure, also may lie in competing supply chains. The suppliers in the aircraft industry were an example, where Microturbo developed systems for a Saab competitor (Dassault) as 53
well, and Sundstrand Power Systems was simultaneously a supplier of Boeing’s. This broader view on the supply chain can explain some of the needs and barriers that firms perceive with IOISs for collaborative product development.
Information flow PROCUREMENT/SALES New
PRODUCT DEVELOPMENT PRODUCT LIFECYCLE
Eg: Component supplier
Eg: Supplier network
Eg: Major supplier
Eg: Systems integrator
Eg: Customer
Eg: End-user
Product flow
2nd tier supplier
Figure 5.1
1st tier supplier
Focal company
Customer
End-customer
A supply chain view on the need of information exchange in collaborative product development.
Several authors claim that the internet opens new possibilities to take advantage of the resources in the supply chain for efficient collaborative product development (Chandrashekar and Schary 1999, Quinn 2000, Sawhney and Prandelli 2000, Reece 2001, Oliver et al 2001). Nevertheless, to facilitate the information flow over company borders also entails risks due to competing supply chains, and it requires considering of new management practices. Chandrashekar and Schary (1999) look at modularization of the supply chain, inspired by product modularization theories as represented by eg Fine (1998), as a means to smooth the progress of introducing and disconnecting firms. Quinn (2000) suggests that the internet and web-based solutions can enhance a creative, somewhat orderly chaos, which is advantageous in outsourced innovation activities. He suggests that interorganizational software solutions can give support to a common language, a set of rules, and management systems for mastering this chaos. He also maintains that software for outsourced innovations can, in a way that is not possible with hardcopies, improve communication, 54
capture knowledge and preserve detailed information that can be transferred between people. Sawhney and Prandelli (2000) report from studies of open source software development that a combination of the traditionally hierarchical organization for product development, where the buyer one-sidedly controls the development, and the chaotic market situation, where “no-one” and “anyone” runs the development, is preferable. They call this concept communities of creation. Reece (2001) presents possible advantages to gain from using IOIS for collaborative product development with customers and suppliers, with fast return on investment, while Oliver et al (2001) calls for simpler technological solutions in favor of support tools to find ways of meeting strategic objectives between collaborating firms, which they refer to as federated planning. Instead of investing in a large system for cross-functional interorganizational support then will the firms be able to take advantage of “best-in-class software” (op cit p 10) to support different levels of the supply chain collaboration. 5.1.2
Is IOISs a Solution for Collaborative Product Development?
In chapter 4 the special characteristics of information and communication in dyadic and supplier network relationships were discussed, compared to intraorganizational product development. An essential question to ask is whether this interfirm communication should be supported with IT tools or not. Smith and Reinertsen (1998), who maintain that fast product development is the key parameter to success for a firm, suggest that a product development team ought to be collocated. However, if this is not possible, the second best alternative is to travel frequently, and have many meetings. Then again, Parker’s (2000) study showed that participants of collaborative product development projects experienced an overload of meetings, and preferred action instead of having to “acclimatize” partners to each other’s company culture. Moreover, as previously mentioned, many studies of collaborative product development have concluded that improved information management, and increased IT support between buyer and supplier, would improve the performance, although such tools were not yet used, other than to some limited extent, in these studies and their outcome was therefore not evaluated (Bruce et al 1995, Ragatz et al 1997, Handfield et al 1999).
55
Only quite recently, however, reports have appeared on extensive use of the internet and web-based tools in product development, but then mainly in the intrafirm case, with some supplier involvement. Howe et al (2001) give examples of how the stagegate process for product development can be supported with webbased tools, but the authors have studied an implementation only for the intrafirm case (with some supplier involvement). Other studies of lean enterprise or lean engineering suggest advanced IS/IT support speeds up the product development process. Such studies are mainly based in the large enterprise, which needs to improve its supply chain management, and therefore includes interfaces to suppliers and customers in the product development process (which Fine 1998 refers to as three dimensional concurrent engineering). This is the case of Coyle et al (2000), who presented goals for Boeing, between the F18 generation of aircraft to its currently running Joint Strike Fighter development program, to reduce its product development cost and cycle time by 50 % while improving quality (measured as a reduced number of changes after initial release) by 90 % with more extended use of IOIS for collaborative product development in combination with management practices. The current status in 2000 was that these goals had practically been achieved. According to Coyle et al (2000) this was explained by several combined management methods, all connected to digitalization of product development data: the master definition based only on 3D solid modeling (no physical prototypes), better “data-driven” decision support for the IPT (at Boeing) with details available earlier, daily virtual reality reviews of the forthcoming product in the team, and better coordination with suppliers and concurrent procurement. Quite similar results, ie smoother information flow that leads to faster problem solving over company borders in product development, was reported by Whyte (2001) for InFocus, Holstein (2001) for DaimlerChrysler, and by Thomke and Fujimoto (2000) for Boeing and Chrysler. The conclusion that can be drawn from this recent (and ongoing) research is that there is large potential of more extensive use of IOIS for collaborative product development, but that deeper understanding of what firms actually need for the specific situation, in this research categorized as dyad and network collaborative product development, is required. The topic of the next section is therefore not only a summary of expressed needs
56
for support for information and communication in the cases studied, but also of possible barriers against use of such tools. This is largely based on the case description and analysis carried out in Appendix C (3 and 4).
5.2
Needs and Barriers of Interorganizational Communication Support
5.2.1
The Dyad
The needs and barriers are often two sides of the same coin, and will therefore be described together in this section. In the buyersupplier dyad much of both the need for improved communication and the barriers against implementation and use could be explained by the procurement and contractual (business) relationship between them, as suggested in the business action theory model by Goldkuhl and Melin (2001). (See Appendix C, 2.1.) To start with, there is a need to support the formal procurement process, which was studied in the public tender in one of the supplier network cases and the military standard procedures in the aircraft development cases (a detailed description of all the steps can be found in Appendix IX of Appendix A). It is cumbersome for both buyer and supplier when it comes to procurement of innovations. First, during the RFI phase (request for information) the buyer and suppliers can communicate quite freely, but once the RFQ phase (request for quotation) has started, the buyer is obliged to provide all involved suppliers with the same information, preferably at the same time. If one question appears, which is common since much of the forthcoming product is unknown as it concerns an innovation of some kind, the answer shall be distributed to all. In the cases studied the administration of the procurement phase was handled manually, which means extensive postal mailing of large numbers of documents. The need to simplify the process by, for example, publish all documents at the same time at an electronic notice board would be preferable, where the suppliers can post electronically their quotations. Digitally presented specifications and offers could also permit visualization of the forthcoming product, for instance with system models that show
57
expected input or output, or other features. A barrier against such tools is the strict access control needed, in order to prevent competing suppliers from accessing the others’ bids. There is more than financially confidential information in a quotation on an innovation, since it may contain military classified information, or business secrets. The presentation of the forthcoming innovation may reveal core competence and the base for the submitting firm’s future business. Parker (2000) concludes this is a delicate balance between leaking too much proprietary information and not supplying enough for the collaborative product development work to be successful. Once a supplier was selected, the communication between buyer and supplier was more open. There is in the work a need for support for distant communication (since, in the cases studied, the supplier could be very far from the buyer), sometimes in another country with, in these special cases, language, cultural, and time differences to overcome. In any case, the supplier firms expressed a need for more contextual information about the forthcoming product. The barrier may again lie in the character of business secrets, or military classified information, at the buying firm. There is a continued need for facilitating the administration between the firms, eg the formally registered changes (engineering change requests, ECRs, in the aircraft development cases), and to gather the information exchanged between the parties in such a way that it is searchable. The traceability is both helpful for the engineers in the product development work, but can also reduce costly misunderstandings concerning contractual issues. Moreover, it can be a way to collect tacit knowledge at the project level into explicit information at the business level (Nonaka 1994), and enable experience sharing over one project to another (as reported by Thomke and Fujimoto 2000). This is also where barriers appear; information exchanged between two firms that touches upon their knowledge-base layer, contains strategic risks especially in transitory supply chains where the relationships to partners switch between cooperation and competition (Nalebuff and Brandenburger 1996, Chandraschekar and Schary 1999). During the projects, there is also a need for daily communication support, which appeared as a very important management practice, referred to in previous theory as gray box (Clark and Fujimoto 1991, Calvi et al 2001). In the cases studied daily 58
telephone conferences were a means to following up the work at the supplier team, and for the supplier to check with the buyer team that the solutions developed were in line with their requirements. However, the project managers claimed that they needed even more frequent communication. E-mail was one way, but could be complemented with tools such as web-based discussion forums to make it possible for more people to take part, in a more structured manner. Again, there is a barrier that the structure also makes it too easy to retrieve confidential information that is proprietary to one of the firms. Moreover, another need for daily communication was the coordination on a team level between the two separate IPTs on the buyer and the supplier sides, ie between separate team members of each organization (eg a mechanical engineer to another mechanical engineer). This coordination was perceived as difficult especially in the projects where the parties were in different countries, for quite trivial reasons such as difficulties to find a person’s telephone number, or trying to contact a person on a bank holiday. Such information could easily be displayed for instance on a web-based project portal, of a groupware. (See listing of need for IT support for project management in Appendix A, 4.6.6). It was largely carried out via e-mail, or fax, but there was a risk that project management was not informed of some ongoing discussions or even decisions taken, something that could be solved by using discussion forums as suggested above. Along the product development process there is a continued need for communication of product specifications and suggested realizations in the design iterations between the parties (the arrows in figure 4.1). This is also described by several authors of product development in general, eg Wheelwright and Clark 1991, Pahl and Beitz 1996, Denker et al 2001, and collaborative product development, eg Ragatz et al 1997). Although these iterations cannot be completely avoided, they could be speeded up and minimized with better communication tools. This was shown with a process simulation carried out for the buyer/supplier process described in Appendix A. (See Appendix A: 6.2, figure 6.5, and Appendix X, and Cronemyr et al 2001.) The importance of faster iteration cycles is also described by Coyle et al 2001.) There was also a need to create shared views of the forthcoming product, and exchange early prototypes for evaluation. In one of the supplier network cases the negative outcome was explained as due to poor customer and end-user evaluation of the early prototypes. 59
Furthermore, the efficiency of systems integration and test could be improved with supporting IT, although there are few standard systems available, since the types of test needed depend on the product and its requirements. In the study, in-house developed tools were most common. The test results could however be transferred electronically and displayed. Finally, tools to support order fulfillment, test, delivery, and launch much depend on the type of contract, for example whether the supplier is going to produce the finished product and has quality responsibility for it. In any case, there is a need to consider product life cycle aspects between the parties, although the needs and consequently the barriers may vary. This will be further discussed in section 5.1.4. Table 5.1 summarizes the above discussion and gives examples of IT tools that were used in the cases studied, but also (within brackets) tools that could be useful for fulfilling the needs of IOIS. Process activity Procurement/sup plier selection/sales
Dyad communication Need: Extensive mailing of documents between buyer and potential suppliers Barrier: Secure access required
Contract
Need: Transfer of information that becomes the basis for the product specification Barrier: Secure access required Need: more frequent communication, tracability, structure Barrier: Risk that proprietary information is easily retrievable by external party Need: supplier needed more contextual understanding Barrier: Risk of losing proprietary and classified information Need: Exchange of model-based specifications, visualization Barrier: Complex tools, standard formats not yet wide-spread, large files require fast connections (or physical meetings) Need: Visualization of solid models before physical prototypes are exchanged Barrier: As above
Project communication
Customer specifications
Product specifications (concept) Realization
System test
Table 5.1
Need: Access to buyer’s/supplier’s test methods Barrier: Few standard programs for system tests
Eg of tools in use Office tools, web site for marketing, with resource database(Part II) Office tools
E-mail, fax (Groupware)
Office tools, web site with photos etc Fax, e-mail, office tools, model-based tools, eg StateMate, Teamwork CAD-files sent via postal mailing, 3D visualization in DMU meeting rooms (web-based visualizers) Test programs, often developed in-house
Activities of collaborative product development in dyads: Needs and barriers of IOIS support .IT tools in use in the cases studied, and suggestions of other tools (within brackets).
60
5.2.2
The Network
As described in section 4.2, the communication in collaborative product development in the supplier network deals more with cross-functional integrated product development, and a need for tools that support a distributed C-IPT. It is assumed that the dyadic relationship to the customer is managed by one of the firms in the network, as described in 4.1 and in the previous section. In order to choose suppliers for the product development assignment, the local network was the framework. It was possible to seek suppliers with a certain competence area via the resource database and competence matrix provided. It was not quite clear in the cases studied however, to what extent this tool was used. One can assume that the social contacts in the network had large influence also. Additionally to the dyad needs and barriers, a supplier network that consists of several SMEs needs tools for cross-functional operations. The difference from the dyad relationship, where operations are carried out at the separate buyer and supplier sites and mainly the results of these operations are exchanged (which could be done via visualizers, eg extensions to a complete CAD software24), is that these supplier firms work closely integrated with the innovation. There is thus a need for fast exchange of pieces of work between the parties. To use the same tools for easy exchange of data files would be a solution, but the barrier against use of the same program is that it can be costly to investments, as there is a risk that a firm needs different programs for the same function in different collaborations. Standard formats for the exchange of data would be the solution (such as STEP or IGES for CAD files), but are not yet widespread. In the cases studied therefore, the parties traveled to the firm that acted as the home base, and provided the required tools, for the development project. There is also a need for support in the innovation work, between engineers in a C-IPT. Lundqvist (1996), based on Pava (1983), refers to this important element of product development work as “a forum for deliberation”, giving some thought of when and 24
The function of a visualizer can be compared with the well-known Adobe Acrobat Reader that visualizes a file independently of on which original editing program it was produced.
61
where the actual innovation takes place and who is present. In order to be efficient in a C-IPT it is important that the information and knowledge distributed on the firms is made available for this forum. In Appendix B we suggested a “home base” for the product networks, and also supporting a IOIS that can contribute to make information available for participating firms. Standard agreements, standard methods, and templates would facilitate the collaboration. Project management can be supported with web-based forms, web-based Gantt charts, etc. A communication platform for standard templates and project management could be provided as an “intranet” between the suppliers (expression used by the respondents in the PUCK case), which strictly speaking is an extranet (Bort and Felix 1998) that can be configured for the firms that participate in the network, where access can be restricted for partners in an activated network (as described in 4.2), which we referred to as product network. The product network could be active also after the development is finished, for product life cycle management. Software solutions could enhance communication by contributing to a common language, and capturing of knowledge and experiences, as well as giving day-to-day decision support (as Quinn 2000 suggests) but there are also barriers against taking new software in use, as experienced in the IS/IT projects studied, due to lack of time for the participating individuals and/or equipment. There is also an initial cost to set up the standard agreements, templates, and the communication platform, which probably require external expertise, and coordination between member firms (eg via the local networks).
62
Process activity Procurement/supplier selection/sales
Contract
Project communication
Product specifications (concept) and realization Product life cycle
Table 5.2
Network communication Need: Competence, skills, and experiences listed in a database for search of potential suppliers Barrier: Must be kept updated Needs: Standard agreements Barriers: Initial cost to create and publish for the network Need: Support for formal project management, impersonal follow-up methods, and for experience sharing between projects Barrier: As above. Training required Need: Engineering tools for sharing IPD work Barrier: Investment in engineering tools, lack of standards in use Need: Organizational structure for product life cycle management and responsibility Barrier: As for project communication
Eg of tools in use Web site for marketing, with resource database Office tools and intranet/extranet for access E-mail, office tools (Groupware with databases for retrieval of previous project information) Office tools, CAD eg AutoCAD (rapid prototyping) (Communication platform, intranet/extranet)
Activities of collaborative product development in networks: Needs and barriers of IOIS support, complementary to the listing in Table 1. IT tools in use in the cases studied, an suggestions of other tools (within brackets).
These characteristics of needs and barriers of information and communication support can be summarized as a list of requirements, as in Appendix C (4.1-4). The requirements are discussed in the next section.
63
64
6
Conclusions
The results of this dissertation are presented in a model that shows characteristics affecting the product development in three areas: for product development in general, for product development in dyads, and for product development in supplier networks. To each area, the requirements found in the analysis of the empirical cases in Appendix C (4.1) are mapped, and technological solutions to fulfill these requirements are discussed. The chapter ends with suggestions for further research.
6.1
Realization of IOIS
6.1.1
Product Development and IOIS Requirements
In figure 6.1 below a supply chain is illustrated where a number of parties that conduct collaborative product development are sketchily drawn. These parties each conduct integrated product development, which is shown as functional areas (departments) within each firm (that Lambert and Cooper 2000 refer to as functional silos, see figure 3.1). When product development is extended to include external parties, there is a need to regard the cross-functional coordination between them. The coordination is illustrated in the figure as gray arrows between the firms (compare figure 4.2). It was found in this study that in the buyer-supplier dyads the firms coordinate their respective activities, orchestrate them as properly as possible, to achieve a resulting new product. It was also found that within a supplier network, where the functions required fulfilling the product development lie in different firms, these firms need to collaborate closely in product development activities, ie in an integrated manner (refer to figure 5.1). This difference had consequences on the characteristics of information and communication.
65
Information flow PROCUREMENT/SALES New
PRODUCT DEVELOPMENT PRODUCT LIFECYCLE
2nd tier supplier
1st tier supplier
Focal company
Customer
End-customer
Product flow Company functions Various supply chain business processes
Collaborative product development: coordination of firms’ processes
Returns
Figure 6.1
Needs of support for communication in collaborative product development.
In Appendix C (see 4.4) the needs and barriers that were found in the two parts of the study were concluded into sixteen requirements. Three derived from an analysis of the supply chain where the firms studied took part (R1-R3), eleven from the analysis of the product development assignment from concept phase to realization (launch) of the product (R4-R14), and two requirements deriving from long-term collaboration after finished product development assignment (R15-R16). The requirements are described in Appendix C (see 4.1-4.3). Briefly, requirements R1-R3 suggest that the firm needs to take into account the supply chain where it operates when investing in IOIS. It implies that the IOIS should not be set up with consideration only to one or two of its partners, but permit flexibility and movements, both between supply chains and for change of positions within a supply chain. Requirements R4-R8 goes into further detail concerning the need for interorganizational communication between several firms, especially different kinds of firms, both small and large partners.
66
For example, the IOIS should not require heavy investments (in time or money) in single relationships, since that would become impossible to manage for parties that have interfaces to many other firms (R5). In order to make the collaborative product development more efficient, information needs to be shared simultaneously to all parties in the collaboration (R6). These requirements also concern security matters (R7-R8), which was discovered as one of the current barriers against use of IOISs, especially based on the internet (see also Kessler 2001). Furthermore, requirements R9-R14 concern communication support for the IPT, such as support for daily operations (R11R12) and decision support in the product development work, with project management support (R9), visualization of early product models (R13), discussions between team members (R14), and traceability (R10) in order to make reuse of knowledge and experiences possible, and in the long run, build up the firms’ knowledge base (Nonaka 1994). Requirements R15 and R16 suggest that the collaborating firms should be able to continue their relationship for product life cycle management in the same interorganizational system environment, and if needed, be able to set up new development projects for continuous product improvements. Figure 6.2 presents characteristics that affect the product development process. These were found in the literature and in the empirical studies, and can be presented in three areas: (1) product development in general (mainly from previous literature, but also from the empirical studies), (2) product development in dyads (from studies in Part I and Part II), and (3) product development in supplier networks (from the studies in Part II). In the table, the requirements discovered in Appendix C are presented as additional in each area, ie for collaborative product development in networks the requirements presented from product development in general apply, product development in dyads as well, and also product development in networks. The reason is that for collaborative product development in the network, general product development characteristics also apply, and the network also has to handle a dyad relationship towards the customer (as discussed in chapters 4 and 5).
67
Product development (general)
Dyad product development
- Time-to-market control (1) - Fast development cycle (1) - High product quality (ie effective product development process) (1) - Efficient project management (2) - Create a shared vision of the forthcoming product (2) - Faster (shorter and fewer) iterations - Regain knowledge and information from previous projects (3)
- Possibility to change partners and supply chain (4) - Efficient interorganizational project management, matching hierarchies (5) - Coordinated product development process between buyer and supplier (6) - Simultaneous product development and procurement (7) - Balance of providing information and prevent leakage (8) - Long-term relationship for product life cycle management (9)
IOIS Requirement R10: The IOIS shall make traceability possible R11: The IOIS shall provide notification when important information is announced R12: The IOIS shall enable fast, direct communication R13: The IOIS shall enable visualization of the forthcoming product. R14: The IOIS shall support interactive discussions concerning specifications and solutions of the forthcoming product. R16: The IOIS shall provide support for new product development projects during product life cycle collaboration
IOIS Requirement R1: The IOIS shall support a firm’s change of positions within a supply chain. R2: The IOIS shall enable a firm’s change of supply chains. R3: The IOIS shall support the participating firms’ strategy concerning the collaborative processes (coordinated or integrated) R4: The IOIS shall simultaneously support procurement/sales and development work R7: The IOIS shall require identification of individuals for selected information sharing. R8: The IOIS shall protect data belonging to participating firms from fraud. R15: The IOIS shall make it possible to continue to use the same environment for product life cycle management between the firms as for procurement/sales and development.
Figure 6.2
Network product development - Small independent firms collaborate crossfunctionally Neutral project management (10) - Integrated product development process among suppliers - Product network operates from a local network (or one or two firms) as home base
IOIS Requirement R5: The IOIS shall be affordable and manageable for all supply chain members that need to take part in information sharing in the collaborative product development assignment. R6: The IOIS shall enable simultaneous information sharing between all parties involved in the development assignment. R9: The IOIS shall provide project management communication support for procedures, plans, progress reports, and daily project communication, with focus on neutral, impersonal management practices.
Characteristics that affect successful product development and a firm’s competitiveness connected to its innovations, in general, in dyads, and in supplier networks. The arrows indicate that the characteristics in a box (to the left) apply also to the next. References (examples of authors) that support these results: (1) Wheelwright and Clark (1992), (2) Smith and Reinertsen (1998), (3) Nonaka (1994), (4) Chandrashekar and Schary (1999), (5) Söderlund (2000), (6) Lambert and Cooper (1999), (7) Wynstra (1998), (8) Parker (2000), (9) Ragatz et al (1997), (10) Biemans (1995).
68
6.1.2
Towards an Informed Collaborative Product Development Environment?
The requirements in figure 6.2 (and Appendix C) form a checklist of what an information system need to fulfill depending on the environment where a firm operates, today and in the future. It is suggested in Appendix C (5) that an IOIS that shall support the collaborative product development process is chosen with respect to business process links and the strategies of the participating firms. The collaboration can involve other processes as well, eg sales, manufacturing, or support (after-sales customer service), as indicated in figure 6.1 above. Moreover, the links are not necessarily of the same character between the firms in these different processes (Lambert and Cooper 2000). An example from this research was that during the product development phase, two parties collaborated in an integrated manner, but in manufacturing the relationship was not of the same strategic importance. The conclusion in Appendix C is therefore that if the firms conduct an integrated product development process there is potential to implement an integrated IOIS, whereas when the collaborating firms conduct separate product development processes with teams at each firm that are coordinated (as in the aerospace industry cases, but also between the buyer and supplier network), the IOIS should consequently be a system consisting of loosely combined (coordinated) building blocks that can be connected and disconnected via standard interfaces. The latter is a questioning of the view on seamless integration between firms in the supply chain. Seamless integration only would be striven for if the firms conduct interorganizational integrated product development, as in the supplier network cases. Even then, as described in 5.2.2 (and Appendix B), since the product networks are of a temporary character, also such integrated IOIS should be easily re-configurable concerning participants, work methods, etc. The suggestion to find simple technological solutions in favor of support tools to meet the strategic objectives of participating firms and be able to take advantage of “best-in-class software” instead, as suggested by Oliver et al (2001), is an interesting path that is recommended to be further explored. Technologically, the development of systems for collaborative product development coordination depends largely on development and implementation of standards. Integrated engineering systems, on the other hand, already exist in cases 69
when the collaborating parties are prepared to invest in the same system. The ideal would be, as illustrated in figure 6.3, that output and input from the firm’s applications can be exchanged via systems that can be jacked into a platform, based on standard internet technology, for collaboration in product development. Internally in the firm, data and information can be exchanged via similar standard format, but with lesser strict access (illustrated as the intranets in the figure). There is also a question of where the firm’s data should belong. In the cases studied, it was obvious that each firm owns and protects its product development information in their own information systems (which supports extant theories on collaborative product development and building up a firm’s assets, eg Biemans 1995, Bruce et al 1995, Parker 2000, Fine 1998, Nonaka 1994). It is therefore not likely that collaborating firms would use any of the others’ databases for information that is created during a collaborative product development project, other than in the form of duplicates or for viewing purposes (in figure 6.3 shown with the arrows between the firms). Inter-operability between firms’ data through standard formats is therefore a viable solution for exchange of product development information between the firms (Johnson 2000). Existing platforms, such as Windchill25, OpenSpace26 and Share-ASpace27 are steps in the direction of reaching a platform for collaborative product development. Due to lack of standards such systems instead are supporting many different formats (often more than a hundred, ranging from .doc and .pdf to XML, STEP, IGES, etc).
25
By PTC (Parametric Technology Corporation), see www.ptc.com. By CoCreate, see www.cocreate.com. 27 By EuroStep, see www.eurostep.com. 26
70
Information flow PROCUREMENT/SALES PRODUCT LIFECYCLE PRODUCT DEVELOPMENT New
Internet and standard formats
System A
System B
System C
System D
System E
System F
System G
System H
Intranet
Intranet
Intranet
COMPANY 1
COMPANY 2
COMPANY 3
Figure 6.3
Open standard formats (such as XML, STEP, and IGES) enable exchange between different firms’ information systems in collaborative product development.
Team communication aspects are generally underestimated. In Appendix A, a process simulation on the effect of using an IT communication platform containing information that facilitates project management and daily operations (eg notification of news, contact information, photos, document exchange, work process maps), showed that the improvement could reach 30 % time reduction on a development project, mainly due to shorter lead times to find information. (Details are accounted for in Appendix X, and Cronemyr et al 2001.) Long-term effects such as building up the knowledge of individuals and organizations as a result of faster and more accurate information are also to be taken into account (Quinn 2000). A remaining question is where the ownership and hosting of such common systems should lie, and consequently who ought to make the investments in such general systems. Should it be part of a common business infrastructure (such as the internet), be related to e-business portals (such as Covisint28 or Endorsia29), or will the current trend of ownership at the buyer-side continue? This question will be left open for future research.
28 29
Buyer-driven e-business portal for the auto industry, see www.covisint.com. Supplier-driven e-business portal for the mechanical industry, see www.endorsia.com.
71
6.2
Recommendations for Further Research Since this study has regarded business relationships in collaborative product development and IOIS with an holistic intention (both buyer and supplier side, both small and larger firms, dyad and networks), it has opened up new interesting areas for further research, of which some were mentioned already in the previous section. Looking at the first part of this research, see Appendix A, it can be concluded that many of the questions raised in 1999 still remain unanswered, and require studies where extensive use of web-based IOISs for collaborative product development have been in use. For example, it seems important to look at the long-term consequences of linking collaborating firms’ information systems to each other, as described by eg Coyle et al (2000) for Boeing and its suppliers. It has reduced development cycle time and cost, but what happens with roles and positions in the supply chain as information and communication is carried out electronically between the parties? Cases where IOISs have been implemented for collaborative product development are also interesting to investigate from an implementation point of view. What were the requirements on the implemented system, and how did selection of system solution affect work in the IPTs – at the buyer and the supplier or supplier network? Were customers and end-users involved in system use? Who owns the IOISs: the buyer(s), the supplier(s), or a third party? Comparison to the requirements found in this study (Appendix C) could be done, to test the research results presented in this dissertation and take them forward. Moreover, cases of extended use of web-based tools could also reveal the qualities of the internet as an infrastructure for communication in collaborative product development, and its possibilities and limitations, including security aspects. The second part of the study deals with the network’s role for collaborative product development in small and medium sized firms. This is a relatively unexplored area where more research is encouraged, also from the perspective of national and regional industrial development. Three case studies were conducted for this dissertation, but more extensive research is recommended into how SMEs can be competitive when a larger amount of product development is required to achieve orders, and what kind of 72
supporting structures that facilitate joint product development efforts. Moreover, of theoretical interest would be to refine existing models of business relationships in networks, such as the field-of-force metaphor (Melin 1989) and the network typologies suggested in Appendix B. Another area of practical interest is to what extent and with what results large firms can take advantage of smaller firms’ innovative qualities. Closely related is also to study how larger firms that outsource innovation activities manage their business relationships to suppliers that carry out part of their product development. Especially important is how relationship management is handled in the supply chain in order to achieve unique, competitive products. In the cases studied for this research, a black box specification at the outset was complemented with gray box manner, ie continuous communication along the project. The risks of far-reaching modularization and standardization on product and component level, but also concerning the communication flow between the parties, seem to be rather unexplored so far. This comes down to a more thorough investigation of efficiency and effectiveness of product development, ie that an efficient development process (with eg modular product as well as supply chain design, see Chandrashekar and Schary 1999) not necessarily leads to effective products.
73
74
References Allen T. J. (1977), Managing the Flow of Technology: Technology Transfer and the Dissemination of Technological Information within the R&D Organization, Boston: MIT. Allen, T. J. (1986), Organizational Structure, Information Technology, and R&D Productivity, IEEE Transactions on Engineering Management, vol EM-33, no 4, November, pp. 212-217. Alvesson M. and Sköldberg K. (2000), Reflexive Methodology: New Vistas for Qualitative Research, London: SAGE Publications. Andreasen, M, Hein M L (1987), Integrated Product Development, London: IFS Publication Ltd. Andersson J., Backlund G., Cronemyr P., Pohl J., Sveder P., and Öhrwall Rönnbäck A. (1998), Product Development at Saab AB: A Study of Engineering Management, Design Theory, and Simulation and Digital Prototyping, Research Report ENDREA, Linköping Institute of Technology, LiTH-IKP-R-1130. Antonelli, M (1999), Building Information Systems to Integrate the Manufacturing Supply Chain, Master Thesis within Lean Aerospace Initiative, MIT, Boston. Augustine, N. R. (1983), Augustine’s Laws, and Major System Development Programs, American Institute of Aeronautics and Astronautics. Backlund G. and Öhrwall Rönnbäck A. (1998), Managing Complexity in Collaborative Development: Modeling Requirements and Enhancing Communication, Proceedings of Avionics Conference 98, London, UK, pp 7.1.17.1.12, (November), Conference paper. Published in Microprocessors and Microsystems, 23 (1999) pp 409-416 (Elsevier Science BV). Biemans W. G. (1995), Product Development within Networks: On the Other Side of the Coin, in Developing Relationships in Business Networks, by Håkansson H. and Snehota I. (eds). Bettis R. A. and Hitt M. A. (1995), The New Competitive Landscape, Strategic Management Journal, vol 16, pp 7-19.
75
Bort J, Felix B (1997), Building an Extranet: Connect Your Intranet with Vendors and Customers, New York: John Wiley & Sons Inc. Chandrashekar A. and Schary P. (1999), Toward the Virtual Supply Chain: The Convergence of IT and Organization, The International Journal of Logistics Management, vol 10, no 2, p 27-39. Christopher M. (1994), Logistics and Supply Chain Management, New York: Financial Times, Irwing Professional Publishing. Ciborra C. U. (1996), The Platform Organization, Organization Science, vol 7, no 2, March-April, pp. 103-118. Clark, K B, and Fujimoto, T (1991), Product Development Performance, Boston, Harvard Business School Press. Coyle J. M., Holly M., and Koshiba D. A., (2000), Lean Engineering: Lean World-Class Integrated Product Definition Processes and Tools, key-note speech at SIG-PM Conference (Special Interest Group of Product Models), Linköping Nov 10-11, see www.dfs.se. (Boeing-Lean Engineering Public Release Control No. 00-080) Cox A. (1996), Relational Competence and Strategic Procurement Management, European Journal of Purchasing and Supply Management, Vol 2, No 1, pp 57-70. Cronemyr P., Öhrwall Rönnbäck A., and Eppinger S. (2001), A Decision Support Tool for Predicting the Impact of Development Process Improvements, Journal of Engineering Design, December. Danilovic M (1999), LOOP: Leadership and Organization of Integration on Product Development, Linköping Studies in Management and Economics, Dissertation No 40, ENDREA, IMIE , and Linköpings universitet. Duarte D. L. and Tennant Snyder N. (1999), Mastering Virtual Teams: Strategies, Tools and Techniques that Succeed, San Francisco: Jossey-Bass Inc. Dussauge P., Hart S., and Ramantosoa B. (1987), Strategic Technology Management, Chichester: John Wiley & Sons. Eppinger S D, Whitney D E, Smith R P, Gebala D A (1994), A Model-Based Method for Organizing Tasks in Product Development, Research in Engineering Design, 6:1-13. Eisenhardt K. M. (1989), Building Theories from Case Study Research, Academy of Management Review, vol 14, no 4, pp. 532-550. Eisenhardt K. M. and Tabrizi B. N. (1995), Accelerating Adaptive Processes: Product Innovation in the Global Computer Industry, Administrative Science Quarterly, vol 40, March, pp 84-110.
76
Fine, C.H., and Whitney, D.E. (1996), Is the Make-Buy Decision Process a Core Competence?, Working Paper MIT Center for Technology, Policy and Industrial Development, February. Fredriksson, B (1994), Holistic systems engineering in product development, The Saab Scania Griffin, 8th issue, November, pp 23-31. Fulk J. and DeSanctis G. (1995), Electronic Communication and Changing Organizational Forms, Organization Science, vol 6, No 4, July-August. Gadde, L-E, Håkansson, H (1993), Professional Purchasing, London and New York: Routledge. Glaser B. G. and Strauss A. L. (1967), The Discovery of Grounded Theory, Aldine Publ. Goldkuhl G. and Melin U. (2001), Relationship Management vs Business Transactions: Business Interaction as Design of Business Interaction, Proceedings 10th International Annual IPSERA Conference, Jönköping, April. Gummesson E (1988), Qualitative Methods in Management Research, Lund: Studentlitteratur, Bromley: Chartwell-Bratt. Gummesson, E. (1995), Relationsmarknadsföring: från 4P till 30R, Malmö: Liber-Hermods AB. Griffin, A, and Hauser, J R (1996), Integrating R&D and Marketing: A Review and Analysis of the Literature, Journal of Product Innovation Management, 13, pp 191-215. Helper S (1996), Incentives for Supplier Participation in Product Development: Evidence from the U.S. Automobile Industry, chapter 7 in Nishiguchi, T (ed), Managing Product Development, New York: Oxford University Press. von Hippel, E (1988), The Sources of Innovation, Oxford University Press. Holstein W. J. (2001), DaimlerChrysler’s Net Designs, Business2.com, April 17, pp 26-28. Howe V., Mathieu R. G., and Parker J. (2000), Supporting New Product Development with the Internet, Industrial Management & Data Systems, 100/6, pp 277-284. Håkansson H. (1987), Product Development in Networks, in Ford D. (ed), Understanding Business Markets, 2nd edition, 1997, pp 475-496, London: The Dryden Press, and in Håkansson H. (ed), Industrial Technological Development: A Network Approach, 1987, pp. 84-128, New York: Croom Helm. Håkansson H. and Snehota I. (eds) (1995), Developing Relationships in Business Networks, London, New York: Routledge. Idegren L. and Carlsson A. (2000), Inter-organisational Sharing of Product and Process Data in Complex Customer-Supplier Interfaces, Proceedings of
77
SIG-PM Conference on Product Models, Linköping, Sweden, Nov 7-8, pp 347362 (ISBN 91-7219-870-2). Isaksson O., Fuxin F., Jeppsson P., Johansson H., Joansson P., Katchaounov T., Lindeblad M., Ma H., Malmqvist J., Mesihovic S., Sutinen K., Svensson D., Törnlind P. (2000), Trends in Product Modeling – An ENDREA Perspective, Proceedings of SIG-PM Conference on Product Models, Linköping, Sweden, Nov 7-8, pp 347-362 (ISBN 91-7219-870-2). Johansson M. (2000), Information Management for Manufacturing System Development, Doctoral Thesis, Computer Systems for Design and Manufacturing, Dept of Production Engineering, Royal Institute of Technology, Stockholm. Johnson J. (2000), Product Models in a Global Product Development: the SEDRES & AP-233 Projects and Related Initiatives in STEP, Systems Engineering and Data Management, Proceedings of SIG-PM Conference on Product Models, Linköping, Sweden, Nov 7-8, pp (ISBN 91-7219-870-2). Kandebo S. W. (1997), Lean Initiative Spurs Industry Transformation, and Model Helps Spread Key LAI Concepts, Aviation Week & Space Technology, July 28. Keen, P G W (1991), Shaping the Future: Business Design Through Information Technology, Boston: Harvard Business School Press. Kerssens-Van Drongelen, I C, De Weerd-Nederhof, P C, Fisscher, O A M (1996), Describing the issues of knowledge management in R&D: towards a communication and analysis tool, R&D Management, 26: 3, p 213-230. Kessler G. C. (2001), Nontechnical Hurdles to Implementing Effective Security Policies, IT PRO, IEEE, March-April pp 49-52. Kraljic, P., (1983), Purchasing Must Become Supply Management, Harvard Business Review, vol. 61, Issue 5. Kumar K. and van Dissel H. G. (1996), Sustainable Collaboration: Managing Conflict and Cooperation in Interorganizational Systems, MIS Quarterly, September, pp. 279-300. Lakemond N (2001), Managing Across Organizations:: Intra- and Interorganizational aspects of Supplier Involvement in Product Development Projects, Linköping Studies in Management and Economics, Dissertation no 52. Lambert D. M. and Cooper M. C. (2000), Issues in Supply Chain Management, Industrial Marketing Management, vol 29, pp 65-83. Lamming R. C., Cousins P. D., Notman D. M. (1996), Beyond Vendor Assessment: Relationship Assessment Programmes, European Journal of Purchasing and Supply Management, Vol 2, No 4, pp 173-181.
78
Lewis M. W. (1998), Iterative Triangulation: a Theory Development Process Usinf Existing Case Studies, Journal of Operations Management, 16, pp 455469. Lilliecreutz J. (1996), En leverantörs strategi - från lego- till systemleverantör, PhD dissertation no 32, Linköpings universitet, Sweden. (A Supplier’s Strategy: from Lego to System Supplier. Written in Swedish.) Lipnack J., Stamps J. (1997), Virtual Teams: Reaching Across Space, Time, and Organizations with Technology, New York: John Whiley & Sons, Inc. Lock D. (1996), The Essentials of Project Management, Aldershot: Gower. Lundqvist M. A. (1996), Organizing Product Development: Formalizing the Informal in Interdependent Knowledge Work, doctoral dissertation, Department of Operations Management and Work Organization, Chalmers University of Technology, ISBN: 91-7197-325-7. Mankin S. G., Cohen D., Bikson T. K. (1996), Teams and Technologies: Fulfilling the Promise of the New Organization, Boston: HBR. Mecham M. (1998), Airbus Partners Select Web Enterprise Software, Aviation Week & Space Technology, Aug 17, p 65. Melin L. (1989), The Field-of-Force Metaphor, Advances in International Marketing, vol 3, pp 161-179. Merriam S B (1994), Fallstudien som forskningsmetod, Lund: Studentlitteratur. Translated from English version 1988 (Case Study Research in Education). Miles R. E., Snow C. C. (1994), Fit, Failure & the Hall of Fame: How Companies Succeed or Fail, New York: The Free Press. Mintzberg H. (1979), An Emerging Strategy of “Direct” Research, Administrative Science Quarterly, no 24, pp580-589. Mintzberg H. (1983), Structures in Five: Designing Effective Organizations, New Jersey: Prentice-Hall. Nalebuff B. J., and Brandeburger A. M. (1996), Co-opetition, London: HarperCollinsBusiness. Nishiguchi T (ed)(1996), Managing Product Development, New York: Oxford University Press. Nonaka I. (1994), A Dynamic Theory of Organization Knowledge Creation, Organization Science, vol 5, no 1, February, pp. 14-37. Ny Teknik (2001), Industrin går i spetsen för neutrala cadformat, by Göte Andersson, Ny Teknik, CAD 6/9 2001.
79
Pahl G. and Beitz W. (1996), Engineering Design: A Systematic Approach, London: Springer-Verlag. Pava, C H P (1983), Designing Managerial and Professional Work for High Performance: A Sociotechnical Approach, National Productivity Review, Spring, p 126-135. Pilemalm, J., Gullander, S., Norling, P., and Öhrwall Rönnbäck, A., (2001), Distributed Product Development: a Case Study in Interorganisational SME Business Networks, Proceedings of ICED 2001 (International Conference on Engineering Design), Glasgow Aug 21-23. Profozich D. (1998), Managing Change with Business Process Simulation, Upper Saddle River: Prentice Hall. Quinn, J. B. (2000), Outsourcing Innovation: The New Engine of Growth, Sloan Management Review, summer, p 13-28. Ragatz G. L., Handfield R. B. and Scannel T. V.(1997), Success Factors for Integrating Suppliers into New Product Development, Journal of Product Innovation Management, vol 14, p 190-202. Rechtin, E (1991), Systems architecting: creating and building complex systems, New Jersey: Prentice-Hall, Inc. Reese A. K. (2001), Stop. Collaborate and Listen, I-source online, Sep 24, 2001. Robertson D, and Allen T J (1992), Managing CAD System Use in Mechanical Design Engineering, IEEE Transactions on Engineering Management, Vol 39, No 1, February. Robertson D, and Allen T J (1993), CAD System Use and Engineering Performance, IEEE Transactions on Engineering Management, Vol 40, No 3, August. Sanchez R.(1995), Strategic Flexibility in Product Competition, Strategic Management Journal, vol 16, pp. 135-159. Sawhney M. and Prandelli E. (2000), Communitieis of Creation: Managing Distributed Innovation in Turbulent Markets, California Management Review, vol 42, no 4, summer, pp 24-54. Strauss A. and Corbin J. (1990), Basics of Qualitative Research: Grounded Theory Procedures and Techniques, Newbury Park: SAGE Publications. Söderlund J., (2000), Time-limited and Complex Interaction: Studies of Industrial Projects, IMIE doctoral dissertation no 39, Studies in Management and Economics no 42, Linköpings universitet. Thomke S. and Fujimoto T. (2000), The Effect of “Front-Loading” Problem-Solving on Product Development Performance, Journal of Product Innovation Management, vol 17, iss 2, March, pp 128-142.
80
Verkstadsforum (2001), CPC – C-Commerce, Special Issue 1/2001 with twelve case studies on Collaborative product commerce. von Hippel, see Hippel. Wedlund, T. (2000), Global Product Development Supported by Groupware, Proceedings of SIG-PM Conference on Product Models, Linköping, Sweden, Nov 7-8, pp. 123-136 (ISBN 91-7219-870-2). Wennberg H, Öhrwall Rönnbäck A (2000), The Human Face of Electronic Business: From Component Supplier to Strategic Business Partner through IT Supported Networks, Proceedings of HICSS ‘34 (Hawaii International Conference on System Sciences), Hawaii, January, 4-6. Wheelwright S. C. and Clark K.B. (1992), Revolutionizing Product Development: Quantum Leaps in Speed, Efficiency, and Quality, New York: Free Press. Womack J. P., Jones D. T., Roos D. (1990), The Machine that Changed the World: Based on the MIT 5-million-dollar 5-year Study on the Future of the Automobile, New York: Rawson Associates. Wynstra F (1998), Purchasing Involvement in Product Development, Dissertation, Eindhoven Centre for Innovation Studies (ISBN: 90-386-07393). Yin, R K (1989), Case Study Research, Design and Methods, Newbury Park: Sage Publications Inc. Öhrwall Rönnbäck, A., Gullander, S., Brege, S., (2001), Product Development in Supplier Networks: Critical Success Factors, proceedings IPSERA 2001, International Purchasing and Supply Education and Research Association Conference, Jönköping Apr 8-11.
81
LINKÖPING STUDIES IN MANAGEMENT AND ECONOMICS, DISSERTATIONS No. XX Editor: The Head of the Department of Management and Economics 1
Melin, L 1977
Strategisk inköpsverksamhet - organisation och interaktion
2
Brege, S. 1978
Marknadsförändring och företagsstrategi - från produktionsorientering till marknadsorientering
3
Philipson, D 1980
Kapitalfunktioner och arbetarnas ställning - marxistisk analys av företag utifrån arbetarkollektivets intressen
4
Drambo, L. Ekonomi och samhällsförändring. Teori och praktik om arbetslöshetens, 1981 inflationens och teknikens politiska ekonomi från antikens slaveri till kapitalismens princip om köp och försäljning av arbetskraft och alternativ framtid
5
Thurfjell, G 1983
6
Mattsson, J Att förändra teknik. En studie utifrån anställdas kunskap och intresse 1983
7
Brodén, M 1983
From Transfer to Acquisition of Technology
8
Hägg, B 1984
Utvecklingsbolag, uppfinningar och nyföretagande
9
Gustavsson P, Hellgren B: Beslut och påverkan. En studie av de komplexa beslutsprocesser 1984 som bestämmer detalhandelanställdas arbetsmiljö i ett stadsdelscentrum
Kvinnor i tandvården. En undersökning av den svenska tandvårdens institutionalisering och arbetsdelning
10 Svensson, B 1984
Acquisition of Technology Through Licensing in Small Firms
11 Anbäcken, O: 1985
Patientmedverkan och organistionsstruktur. En studie om patientens roll och funktion i vårdorganisationen
12 Revang, Ö 1985
Avviklingsprosesser i komplekse organisasjoner. En studie av fire norske virksomheter
13 Pehrsson, A 1986
Strategic Planning and Environmental Judgement: the Performance in SBU Organized Industrial Groups
14 Eriksson, GFöretagets immateriella investeringar. En begreppsutredning. 1986 15 Björklöf, S 1986
Byggbranschens innovationsbenägenhet
16 Wigblad, R Från avveckling till utveckling. Fallstudier av handlingsfriheten vid industri1987 anläggningar 17 Iggland, B 1987
Customer Evaluations for Industrial Product Development
18 Dzever, S 1987
An Appraisal of the Role of Foreign Firms in the Nigerian Tin Industry
19 Svidén, O
Scenarios. On Expert Generated Scenarios for Long Range
1989 20 Dadfar, H 1989
Infrastructure Planning of Transportation and Energy Systems Industrial Buying Behavior in the Middle East. A Cross National Study
21 Abrahamsson M: Tidsstyrd Direktdistribution - drivkrafter ohc logistisk konkurrens1992 fördelar med centrallagring av producentvaror 22 Lindell, P 1992
Strategisk styrning och förändring - En begreppsutredning baserad på en studie av Swedish Match 1960-1987
23 Hellberg, R Synkroniserad materialförsörjning - Åtgärder och hinder för effektivare 1992 logistik 24 Klofsten, M 1992
Tidiga utvecklingsprocesser i teknikbaserade företag
25 Hultman, C 1993
Managing Relations in Marketing Chanels for Industrial Goods
26 Ljung, J 1993
Idébaserad verksamhet - En studie av frikyrkan som organisation
27 Salzer, M 1994
Identity Across Borders - A Study in the "IKEA-World"
28 Lindström, G 1994
Idéutveckling - produktutveckling
29 Holmström, M 1995
Styrning i storföretag - en studie av styrningens utformning och omfattning i tre svenska koncerner
30 Sjöström, R 1996
Positionering under strategisk osäkerhet - En studie av positionering i en ny bransch
31 Andersson, S 1996
Internationalisering som entreprenörshandling
32 Lilliecreutz, J 1996
En leverantörs strategi - utveckling från lego till ego
33 Norrman, A 1997
Organizing Timebased Distribution in Transnational Corportions - Interaction between Logistics and Organizational Structure
34 Andersson, D 1997
Third Party Logistics - Outsourcing Logistics in Partnerships
35 Hellqvist, A 1997
Praktik och idéer. Om organisationsrutiners betydelse i förändringssammanhang
36 Sonesson, T Efterfrågan på långväga persontransporter - Ekonomisk-teoretisk belysning av 1998 gängse trafikmodeller samt en ny ansats till estimering av elasticiteter för reseefterfrågan 37 Ericson, T 1998
Förändringsidéer och meningsskapande - En studie av strategiskt förändringsarbete
38 Brehmer, P O 1999 39 Fang, T 1999
Towards a Model of Lean Freight Transport Operations Chinese Culture and Chinese Business Negotiating Style
40 Danilovic, M 1999
Loop – Leadership and Organisation of Integration in the Swedish Aerospace Industry
41 Tell, F 2000
Organizational Capabilities – A study of the manufacturers of power transmission equipment
42 Söderlund, J 2000
Time-limited and Complex Interaction – Studies of Industrial Projects
43 Carlsson, J 2000
Logistiskt Förändringsarbete – olika ansatser för operativ utveckling
44 Aronsson, H 2000
Three Perspectives on Supply Chain Design
45 Berglund, M 2000
Strategic Positioning of the Emerging Third-Party Logistics Providers
46 Ahlström, M 2000
Offset Management for Large Systems – A Multibusiness Marketing Activity
47 Jonsson, L 2001
Kunskapsbildning i samverkan mellan forskning och praktik – En studie av interaktiv kunskapsbildning avseende kommunchefers chefsskap
48 Vik, M 2001
Commitment and Control – On the Individual – organization relationship in pre-clinical development
49 Tomicic, M 2001
Reaching Agreement in a Management Team - a Social Influences Perspective
50 Wall, R 2001
The Importance of Transport Costs for the Spatial Structure and Competition in Goods and Service Industries
51 Rehme, J 2001
Sales coordination in multinational corporations – Development and management of key account programmes
52 Lakemond, N 2001
Managing Across Organisations – Intra- and interorganisational aspects of supplier involvment in product development projects
53 Huge Brodin, M 2002
Logistics Systems for Recycling – On the Influence of products, structures, relationships and power
54 Öhrwall Rönnbäck, A
Interorganizational IT Support for Collaborative Product Development
DISSERTATIONS FROM THE INTERNATIONAL GRADUATE SCHOOL OF MANAGEMENT AND INDUSTRIAL ENGINEERING No. xx Editor: The Head of the IMIE, Linköping University, S-581 83 Linköping, Sweden 1 1996
Engevall, Stefan: Cost Allocation in Distribution Planning. No. 1, Licentiate Thesis, LiU-TEK-LIC No. 585
2 1996
Lindström, Jörgen: Chefers användning av kommunikationsteknik. No. 2, Licentiate Thesis, LiU-TEK-LIC No. 587,
3 1997
Fang, Tony: Chinese Business Negotiation Style - A Socio-Cultural Approach. No. 3, Licentiate Thesis, LiU-TEK-LIC No. 610
4
Ekdahl, Fredrik: Increased Customer Satisfaction Using Design of Experiments, 1997 Conjoint Analysis and QFD. No. 4, Licentiate Thesis, LiU-TEK-LIC No. 632
5 1997
Tell, Fredrik: Knowledge and Justification - Exploring the Knowledge Based Firm No. 5, Licentiate Thesis, FiF-avhandling nr 8
6 1997
Nilsson, Mikael: Quality Principles in R & D - An exploratory study of two processes, No. 6, Licentiat Thesis, FiF-avhandling nr 9
7 1997
Berglund, Magnus: Third-party Logistics Providers - Towards an Conceptual Strategic Model. No. 7, Licentiate Thesis, LiU-TEK-LIC No. 642
8 1997
Johansson, Glenn: Design for Disassembly - A Framework. No. 8 Licentiate Thesis, LiU-TEK-LIC No. 651
9 1998
Augustsson, Magdalena: IT Outsourcing Relationships - A Transaction Cost Analysis of Two Cases, No. 9, Licentiate Thesis, LiU-TEK-LIC No. 667
10 1998
Anderson, Christian: Anläggningsprojekt och organisatoriskt lärande, No.10, Licentiate Thesis, LiU-TEK-LIC No. 681
11 1998
Bröte, Staffan: Disassembly Systems - Process Analysis and Strategic Considerations No.11, Licentiate Thesis, LiU-TEK-LIC No. 673
12 1998
Tjäder, Jimmy: Projektledaren & planen - en studie av projektledning i tre installations- och systemutvecklingsprojekt, No.12, Licentiate Thesis, LiU-TEK-LIC No. 675
Uppdaterad 02-03-22
13 1998
Forsberg, Torbjörn: Process Orientation and Meassurements, No.13, Licentiate Thesis, LiU-TEK-LIC No. 687
14 1998
Kroslid, Dag: Quality Management - National or Global Driving Factors? No.14, Licentiate Thesis, LiU-TEK-LIC No. 679
15 1998
Söderlund, Jonas: Globala Tider - om deadlines och kunskapsintegration i komplex utvecklingsprojekt, No.15, Licentiate Thesis, FiF-avhandling nr 18
16 1998
Rehme, Jakob: Sales Coordination: Development of Customer Teams in ABB, Sweden, No.16, Licentiate Thesis, LiU-TEK-LIC No. 709
17 1998
Säfsten, Kristina: Requirements and Strategic Preconditions for Efficient Assembly - A Theoretical analysis, No. 17, Licentiate Thesis, LiU-TEK-LIC No. 707
18 1998
Tomicic, Marie: En ledningsgrupps kognitiva struktur - homogenitet, heterogenitet och förändring. No. 18, Licentitate Thesis, FiF-avhandling Nr 19
19 1998
Hansson, Jörgen: Financial Risk Management - Aspects of Optimal Decision Strategies in an Uncertain World with Market Imperfections. No. 19, Licentiate Thesis, LiU-TEK-LIC No. 740
20 1999
Alvehus, Martin: A Lagrangian Relaxation Approach to Production Scheduling. No. 20, Licentiate Thesis, LiU-TEK-LIC No. 750
21 1999
West, Martin: Essays on Productivity, Flexibility and Manufacturing Networks. No. 21, Licentiate Thesis, LiU-TEK-LIC 757
22 1999
Rudberg, Martin: Manufacturing Strategy, Planning and Control in a Global Context. No. 22, Licentiate Thesis, LiU-TEK-LIC 758
23 1999
Ekdahl, Fredrik: On the Application of Designed Experimentation for Customer Focused Product Development, No 23, Doctoral Dissertation, Linköping Studies in Science and Technology Dissertation No. 578
24 1999
Lindström, Jörgen: Does Distance Matters? On Geographical Dispertion in Organisations, No 24, Doctoral Dissertation, Linköping Studies in Science and Technology Dissertation No. 567
25 1999
Persson, Jan: Production Planning and Scheduling in Refinery Industry No 25, Licentiate Thesis, LiU-TEK-LIC 763
26 1999
Lakemond, Nicolette: Supplier Coodination in Product Development Projects The case of Tetra Brik, No 26, Licentiate Thesis, LiU-TEK-LIC 767
27 1999
Kroslid, Dag: In Search of Quality Management – Rethinking and Reinterpreting No 27 Doctoral Dissertation, Linköping Studies in Science and Technology Dissertation No. 590
Uppdaterad 02-03-22
28 1999
Elg, Mattias: Exploring Quality Improvement Activities in New Product Development. No 28. Licentiate Thesis, LiU-TEK-LIC 773
29 1999
Nilsson, Lars: Process Orientation in Product Development No. 29, Licentiate Thesis, LiU-TEK-LIC-772
30 1999
Wasner, Reine: The Process of Outsourcing – Strategic and Operational Realities, No. 30, Licentiate Thesis, LiU-TEK-LIC No. 763
31 1999
Fang, Tony: Chinese Culture and Chinese Business Negotiating Style No. 31, Doctoral Dissertation, Linköping Studies in Management and Economics Dissertations No. 39
32 1999
Björkegren, Charlotte: Learning for the Next Project – Bearers and Barries in Knowledge Transfer within an Organisation, No. 32, Licentiate Thesis, LiU-TEK-LIC-787
33 1999
Öhrwall-Rönnbäck, Anna: Collaborative Product Development and IT Communication Infrastructures: A study in the Swedish Aerospace Industry, No. 33, Licentiate Thesis, LiU-TEK-LIC-802
34 2000
Tjäder, Jimmy: Systemimplementering i praktiken – En studie av logiker i fyra projekt. No. 34, IMIE Dissertation, Linköping Studies in Science and Technology Dissertation No. 618
35 2000
Skottheim, Joakim: Recycling in a Contradictory Environment. No. 35 LicentiateThesis, FiF-a 33
36 2000
Tell, Fredrik: Organizational Capabilities – A study of the manufacturers of power transmission equipment 1878-1990, No. 36 IMIE Dissertation, Linköping Studies in Management and Economics, Dissertation No. 41
37 2000
Askenäs, Linda: Affärssystemet – en studie om teknikens aktiva och passiva roll i en organisation, No. 37, Licentiate Thesis, LiU-TEK-LIC 808
38 2000
Grundström, Christina: The many faces of standards and phases of standardisation in 2000 product development – Findings from explorative case studies involving software, No. 38, Licentiate Thesis, LiU-TEK-LIC 821
39 2000
Söderlund, Jonas: Time-limited and Complex Interaction, No. 39 IMIE Dissertation, Linköping Studies in Management and Economics, Dissertation No. 42
40 2000
Persson, Fredrik: Simulation Modelling, Validation and Analysis of Supply Chains, No. 40, Licentiate Thesis,
41 2000
Magnusson, Thomas: ECO-Design and Product Innovation – Managing incremental and radical change for environmental compliance, No. 41, Licentiate thesis
42 2000
Bengtsson, Jens: Essays on Valuation of Manufacturing Flexibility – An option pricing theory approach, No. 42, Licentiate Thesis
Uppdaterad 02-03-22
43 2000
Berglund, Magnus: Strategic Positioning of the Emerging Third-Party Logistics Providers, No. 43 IMIE Dissertations, Studies of Management and Economics No. 45
44 2000
Antoni, Marc: Inter-Project Learning – a Quality Perspective, No. 44, Licentiate Thesis
45 2000
Erlandsson, Per: Governmental Grants in the Early Development of New Technology Based Firms, No. 45, Licentiate Thesis
46 2000
Hallström, Anders: The Retailer’s Role in Car Distribution, No. 46, Licentiate Thesis
47 2001
Nehler, Henrik: Activity-Based Costing – En kvantitativ studie kring spridning, användning, utformning och implementering i svensk verkstadsindustri. No. 47, Licentiate Thesis
48 2001
Blomvall, Jörgen: Optimization of Financial Decisions using a new Stochastic Programming Method, No. 48 IMIE Dissertation
49 2001
Johansson, Glenn: Environmental performance requirements in product development – An exploratory study of two development projects, No. 49 IMIE Dissertation
50 2001
Tomicic, Marie: Reaching Agreement in a Management Team – a Social Influences Perspective, No. 50 IMIE Dissertation
51 2001
Rehme, Jakob: Sales coordination in multinational corporations – Development and management of key account programmes, No. 51 IMIE Dissertation
52 2001
Lakemond, Nicolette: Managing across organisations – Intra- and interorganisational aspects of supplier involvement in product development projects, No. 52 IMIE Dissertation
53 2001
Elg, Mattias: Performance measures and managerial work – A modified behavior setting approach to the study of usage of performance measures in managerial meetings, No. 53, IMIE Dissertation
54 2002
Bröte, Staffan: Towards Market Driven Manufacturing Systems Design, No. 54 IMIE Dissertation
55 2002
Rudberg, Martin: Manufacturing Strategy: Linking Competitive Priorities, Decision Categories and Manufacturing Networks, No. 55 IMIE Dissertation
56 2002
West, Martin: Flexibility and Productivity: Two fundamental Properties of Production Processes in International Manufacturing Networks
57 2002
Nilsson, Lars: An Empirical Investigation of Product Development and the Goods-toServices Continuum, No. 57 IMIE Dissertation
58
Norelius, Hans: Merge in Transit, No. 58 Licentiate Thesis
Uppdaterad 02-03-22
59 2002
Öhrwall Rönnbäck, Anna: Interorganizational IT Support for Collaborative Product Development, No. 59 IMIE Dissertation
Uppdaterad 02-03-22
