Information systems in fast cycle development: identifying user needs in integrated automotive component development Klas SoÈderquist 1 and Rajesh Nellore 2 1
Grenoble Graduate School of Business, 12 Rue Pierre Semard ± B.P. 127, FR-38003 Grenoble Cedex 01, France,
[email protected] 2 General Motors Corporation, Research & Development & Planning, Warren, MI 48090, USA,
[email protected]
Product development literature strongly emphasizes the need for open communication between suppliers and Original Equipment Manufacturers (OEMs). There is a widespread expectation that computer-aided communication networks will enable organizational members to work more flexibly, to share knowledge and competencies, and to span functional and company boundaries. However, few studies merge the possibilities of new information technologies and the operational needs of specific groups of users, for example product development engineers. The research reported in this paper aims to fill that gap. Through in-depth case studies of two development projects involving one auto OEM, one of its systems suppliers (working directly with the OEM) and five medium-sized expert suppliers (working either directly with the OEM or through the systems supplier), we identify three groups of user needs that are not currently satisfied by existing information system solutions: improvement of coordination and communication; enhancement of the access to new technological information; and support for the development of an organizational memory. We then explore what kind of information systems might help satisfy the above-mentioned needs. Potential barriers to efficient implementation of information systems in terms of the motivation of people using the systems, the reliability of the information, and the willingness to render information more transparent are discussed. It is concluded that when implementing information systems to support operational development work, it is essential to ground the system specification in clearly identified user needs that reflect the double nature of product engineering, namely the continuous interplay between routines and cognitive processes.
Introduction
T
he automotive industry has undergone tremendous transformation during the 1990s. This transformation has occurred in many areas such as product development, cycle time, inventory management, supplier involvement, participation of supplier guest engineers, amongst others (Freyssenet et al., 1998). Research has been extensive in product development
(Clark and Fujimoto, 1991; Calabrese, 1997; Miller, 1995) and the involvement of suppliers in product development (Coleman et al., 1995; Dyer, 1996; Lamming, 1993; Leonard et al., 1994). The operational aspect of product development has been described by Nellore et al. (1998) as a flow of specifications from the overall vehicle level to the sub-system level and finally to the component level where suppliers proactively participate in the development of the sub-system and
R&D Management 30, 3, 2000. # Blackwell Publishers Ltd, 2000. Published by Blackwell Publishers Ltd, 108 Cowley Road, Oxford OX4 1JF, UK and 350 Main Street, Malden, MA 02148, USA.
199
Klas SoÈderquist and Rajesh Nellore component level specifications. This perspective is corroborated by Moisdon and Weil (1992) and Clark and Fujimoto (1991) who elucidate that operational design work is related to the function of sub-systems, and to the integration of sub-systems into the final vehicle ± product development is like solving a huge equation. This perspective emphasizes the fact that the operational product development decisions are a compromise between different functions and factors, making the need for information flow to support decision-making all the more important. The need for information also increases when concurrent engineering with strong, early and permanent interaction between different functions including suppliers is being implemented (Carter, 1992; Durand 1995; Hayes et al., 1988). The need for extensive lateral and diagonal flows of communication among technical employees has been documented by several researchers (Hinds and Kiesler, 1995; Allen, 1977). They have shown that among technical workers, coordination happens primarily through direct communication within and across departments with the objective of overcoming excessive specialization, improving individuals' abilities of keeping up with changes in techniques and new knowledge, and understanding and adopting innovations. The same objectives and coordination imperatives occur between buyers and suppliers in the context of integrated product development (Dyer, 1996; Lamming, 1993). Thus, communication becomes a central and critical topic in managing the integrated product development process. However, in spite of the rapid evolution of information technology in terms of internet, intranet, and group-ware, 1 our experience from the auto industry indicates that these tools are being sparsely used as supporting tools in operational design activities. Our practical experience corroborates the findings of Kerssens-Van Drongelen et al. (1996) who make the same observation. Moreover, in view of the complexity of the design task in automotive development, it would be very difficult to specify an adequate information system without an in-depth understanding of the context in which operational development work occurs. The paper is organized as follows. We first review the context of integrated product development with special emphasis on how operational development work can be conceptualized. Based on this review, we propose a framework to guide the research on how information systems can be used as support devices. Second, the research methodology, based on in-depth case studies of two development projects involving one automotive OEM, one systems supplier and five expert suppliers, is explained. The data section is then divided into two parts. We first attempt to explore and identify current existence and use of information systems in operational development work. Then, we focus on identifying needs not catered to by the existing systems. In the analysis, we discuss which information systems 200
R&D Management 30, 3, 2000
might satisfy these needs, explore the impact of the satisfaction of these needs in light of the development framework, and discuss the barriers to successful implementation of information systems in order to satisfy the user needs. Finally, conclusions, implications for management and future research are discussed.
The context of integrated product development There are two well-established schools of thought in the product development literature. These are the doing perspective emphasizing the analytical and sequential side of product development (c.f. e.g. Shigley and Mishke, 1989; Dertouzos et al., 1989), and the reflecting perspective emphasizing iterative thinking processes and conceptual learning (c.f. e.g. Bucciarelli, 1988; Wheelwright and Clark, 1992). Kim (1993) integrates the two perspectives in a model of general learning processes. This model consists of four operational steps, namely elaboration=planning, implementation, observation, and assessment. Applied to operational design work, the four steps can be characterized as follows: 1. Facing a problem at hand, the design engineer or technician plans and elaborates a specific solution; 2. The design engineer then implements that idea, i.e., creates a virtual or physical prototype based on CAD drawings and blueprints; 3. The engineer then observes the results of the implementation through testing and experimentation guided by needs and specifications that might be more or less formalized; 4. Finally, the engineer conducts an assessment of the result by comparing the needs to the specifications (that, again, can be more or less formalized). As a function of the assessment, the engineer elaborates a modified solution that will be implemented. Based on in-depth observations of a large number of design engineers at work, SoÈderquist (1997) found the four steps described above as applicable to operational design work. He emphasizes the need to integrate doing and thinking, i.e., practice and reflection in each of the four operational steps elaboration=planning, implementation, observation and assessment. This corroborates the concept of reflecting-in-practice developed by SchoÈn (1983) to describe how design engineers, among other professionals, work. SoÈderquist (1997) shows that whatever activity preoccupies a design engineer, he or she might have a need for support both for practice and thinking. The resulting enlargement of Kim's model is presented in Figure 1. In Kim's (1993) model, which develops the work of Senge (1990), the elaboration=planning and assessment steps are guided by essentially tacit frameworks, while the steps of implementation and observation are # Blackwell Publishers Ltd 2000
Information systems in fast cycle development
R E F L E C T I N G
Figure 1. (1993).
Thinking
Thinking
Elaborate /Plan
Implement
Practice
Practice
Thinking
Thinking
Assess
Observe
Practice
Practice
D O I N G
Development=learning cycle. Extension based on Kim
guided by routines that, to a large extent, are explicit. Routines are different standardized operating procedures such as design reviews, schemes for project advancement, or instructions for the handling of a CAD software program or testing equipment. Frameworks refer to belief systems and organizational assumptions about the world (labeled Weltanschauung by Kim) which shape individual behavior and company culture. They decide to a large extent what makes `good' solutions to a problem. Routines might, to a certain degree, formalize the product development process (Schilling and Hill, 1998), but the fact that design technicians are unable to give rational explanations of all choices or undertaken actions (Lawson, 1990; SchoÈn, 1983; SoÈderquist, 1997) suggests that a part of the product development work will always remain a tacit practice based on individual and collective belief systems and assumptions. Karlson (1994) and SchoÈn (1983) capture the essence of the relation between routines and frameworks in product development work when stating that the tacit part will always be present as it precedes standardized procedures; the art of a profession (in this case engineering design) evolves in the front-line of new learning. The dynamic perspective introduced by Karlson (1994) corroborates Kim's (1993) vision that routines and frameworks will undergo constant evolution based on the interplay with the four operational steps elaboration=planning, implementation, observation and assessment. Senge (1990) and Kim (1993) argue that the extent to which routines and frameworks will evolve becomes a management question integrating both hands-on implementation of routines and visionary leadership in order to modify frameworks. Bowen et al. (1994) define guiding visions for product development in the # Blackwell Publishers Ltd 2000
following way: `In the context of new product and process development, a guiding vision is a clear picture of an operational future, an organizational or project destination that serves as a referent and focal point for current decision-making' (p. 59). They qualify the use of guiding visions as conceptual leadership, and emphasize the importance of anchoring the visions in the global strategy of the company. The importance of guiding visions and the links between strategy and operations is gaining increased attention in recent management research. Collins (1999) introduces the concept of catalytic mechanisms, defining them as the crucial links between objectives and performance. Tichy (1999) conceptualizes what he has labeled the `teachable point of view' as an answer to managers' question of what actually makes change happen. The teachable point of view combines how-to statements about what it takes to succeed in a particular business or venture, and why-considerations on peoples' ways of approaching their work. Jacques Nasser's way of transforming Ford is used as a case study to explain how the teachable point of view can be successfully applied. Common to these concepts is the combination of visionary leadership and hands-on implementation, based on a company's current state of the art in terms of procedures and routines, knowledge and beliefs which are critical to succeed in any kind of change or implementation process. Based on the preceding analysis, we are now able to complete the conceptual framework of operational engineering design work: * * *
Routines come in as support for the `doing' side of operational design, Frameworks come in as support for the `reflecting' side of operational design, Hands-on implementation and visionary leadership based on careful assessment and linking of strategy, structure, and competence come in as a dynamic input provoking constant evolution of the routines and frameworks.
The proposed framework is presented in Figure 2. The above model conceptualizes the development work. Each of the steps in the model are performed by development personnel. Recalling the communication imperative in integrated development, it seems evident that the successful completion of the steps will depend on timely access to relevant information, on the ability to exchange information in a rapid and reliable manner, and on the possibility of ensuring a shared understanding of the information. One possible way of satisfying these needs could be the successful deployment of an information system. Based on experience and existing research, we assumed that existing information systems fail to adequately support operational development work. Thus, it would be important to identify operational user needs within the R&D Management 30, 3, 2000
201
Klas SoÈderquist and Rajesh Nellore
Development / Learning Context Development / Learning Cycle Thinking
Thinking
F Elaborate/Plan
r
Implement
R
a R e f l e c t i n g
m e w o r
o Practice
Practice
Thinking
Thinking
Assess
Observe
Practice
Practice
D o i n g
u t i n e
k
s
s
Hands on Implementation Visionary Leadership Figure 2. Framework for operational product development work. Extension based on Kim (1993).
framework in Figure 2. Once user needs have been identified, the barriers to successful implementation would need to be assessed. This leads us to the following research questions: Question 1. Which information systems are currently used in operational development work, and what are their shortcomings? Question 2. What needs are not being satisfied by the existing information systems in terms of support both for more routine activities, such as the implementation of a new design solution and observation of it's performance, and for more cognitive processes of planning, elaboration and assessment of new design solutions? Further, which information systems would be helpful in satisfying these needs? Question 3. How might the satisfaction of the user needs aid in operational development work? Question 4. What can constitute the barriers to successful implementation of information systems in order to satisfy the user needs previously identified?
Method Two development projects were studied simultaneously. They involved the auto OEM, one of its systems suppliers and five medium-sized expert suppliers. These were the main players in the development projects, while there were of course a large number of subcontractors delivering components with low functional added value. 202
R&D Management 30, 3, 2000
Project one was the development of an engine temperature regulation system. It involved four expert suppliers (thermostats, electronics, fasteners and plastics). Project two was the development of an electronic suspension system, involving three expert suppliers (electronics and fasteners, which were the same as in project one, and high precision screw-cut parts). All companies were based in Europe (Sweden, Great Britain and France). The study is exploratory; we wanted to develop ideas from induction of data more than propose general conclusions. The objective of the case studies was not only to identify user needs, but to understand the context, background and causal conditions in which they occurred. Data were collected through interviews, studies of documents, and by direct and participant observation. The persons met in the OEM were the Vice Presidents for R&D and Engineering, Project Managers, Chief Engineers, Design Engineers and Project Leaders. The persons met in the supplier companies were CEOs, Product Development Managers, and Design Engineers. There were altogether thirty interviews. The authors spent more than one year in the OEM, and several weeks in the supplier companies between March 1996 and May 1998. During this period one of the authors author worked as a project leader in the OEM. In order to improve the quality of our research, we used a criterion sample strategy for selecting the appropriate expert suppliers for the case study. They should supply to at least three manufacturers, should be former `off-the-shelf' suppliers with a clear objective of being partners in integrated component development and of staying aligned with the car industry. They should have an explicit strategy for quality, R&D, and organizational development, and the suppliers' components should provide central value-adding functions in the system, largely depending on the suppliers' own R&D efforts. Data from interviews and observations were analyzed according to the open coding technique (Strauss and Corbin, 1990). When using this technique, data is first broken down by taking apart an observation, a sentence, a paragraph and giving each separate idea or event a name. Data is then regrouped in categories that pull together around them groups of ideas and events that become subcategories. The following step in the method ± axial coding ± aims to regroup and link categories in a rational manner. The objective of axial coding is to identify main categories ± phenomena ± and make connections between them and their subcategories leading to the development of a series of propositions clarifying context and causal conditions to phenomena. In order to improve reliability, i.e., demonstrate that the data collection procedures can be repeated with the same results, data from interviews, open discussions and observations exist in three forms according to the # Blackwell Publishers Ltd 2000
Information systems in fast cycle development method developed by Yin (1989): * *
*
Directly taken field notes ± from interviews and observations; Expanded typed notes made as soon as possible after the field work (this includes comments on problems and ideas that arise during each stage of the fieldwork and that will guide further research); A running record of analysis and interpretation (open coding and axial coding).
Accuracy of the presented findings was improved through the use of multiple sources of evidence, the establishment of a chain of evidence, and by letting key informants review draft result reports.
Data ± Part A: existing information systems and their usage Central to the design activities were the CAD systems. At the component system level, 3D CAD was omnipresent. At the individual component level, the complexity of the product determined what systems to employ. Electronic Data Interchange (EDI) had been implemented in the majority of the suppliers' black box customer relations, both with OEMs and systems suppliers, but was merely used at project outset to transfer initial specifications, and also much later, in running production to transfer orders, schedule production, and manage invoicing. Internal design data banks (patents, design studies, already commercialized products) existed off line, i.e., possible to consult only from certain workstations and by certain people. No multi-company group-ware existed, in the sense that CAD and EDI links were bi-directional only. Moreover, these links did not allow for transmission of qualitative information, questions or discussions. To sum up, different devices for transferring data and for capturing individual and collective experiences in product development exist in the companies we studied. These present two main problems: lack of dissemination functions, and their fragmentation, i.e., blueprints, patent data base, launched product data base, design study data base, etc., do not exist in an integrated form. These different support structures acted merely as storage devices separated from the logic of inter-firm and inter-functional project organizations. This problem was common to the majority of the interviewees. The data indicated that concerning qualitative data, informal oral transmission as well as more formalized transmission through reports and meetings were insufficient to keep different players rapidly and systematically informed of new product and process technologies and their different aspects. Oral transmission ran the risk of distorting original messages and not reaching all those that might have a potential # Blackwell Publishers Ltd 2000
interest in the information. Reports had a tendency to end up in piles instead of circulating among the concerned people. Moreover, the report format did not seem to invite a joint discussion between design staff, let alone between people from different functions. Meetings, finally, were not always attended by all participants, and did not always function in a very efficient way; participants did not express themselves very vividly and seemed to have difficulties in laying aside their momentary preoccupations in order to participate actively in discussions of common interest. Computer-based systems could reduce or limit these negative effects through their possibilities of real time reaction to information, a `coffee-room' style discussion of ideas and opinions that would also be stored and be available to consult in the future.
Data ± Part B: identifying user needs not catered to by existing systems Based on the modeling of operational design work, we started looking for information system user needs in the development=learning context, i.e., in terms of routines and frameworks supporting operational design work. The assessment of existing information systems helped us to focus the research on areas where specific problems could be identified. The results are presented below.
Improvement of coordination and communication flows Project managers and design engineers expressed several problems related to coordination and communication in the product development process. Numerous late design changes, long periods of uncertainty during which the supplier engineers do not know whether their solution will be accepted by the customer(s), and redundant work on concepts that risk becoming obsolete following simultaneous evolution and increased precision of the system specifications were the most significant. The interviewees attributed these problems to the steadily increasing demands on systems suppliers and=or carmakers for coordination of the individual product development processes in different supplier firms that contribute to a system through simultaneous engineering. The main problem expressed by design engineers was not to simultaneously engineer components, but to simultaneously manage the related information flow, and above all, to ensure the relevance of the information at their disposal. In order to improve coordination and information flows, the design engineers expressed three major user needs (UNs): UN1
Informing the individuals in each contributing supplier firm about who the other participants R&D Management 30, 3, 2000
203
Klas SoÈderquist and Rajesh Nellore
UN2
UN3
in the system are, and what their respective roles and competencies are. Informing the individuals in each contributing supplier firm about the modifications undertaken on individual components and interfaces by everyone involved in the ongoing engineering of the system. This information should be received as close to real time as possible. The engineers emphasize that the importance of a design problem is judged essentially in relation to the impact it might have on interfacing components and systems. Thus, this impact should be known as well and as quickly as possible. Allowing the individuals in each contributing supplier firm to react and comment on design modifications, thus opening up a collective dialogue concerning the performance of the system (function, technology, quality, cost, lead-time).
One basic vision was common to the three user needs, namely that an information system for improving coordination and communication should support the creation of inter-functional and inter-company micro organizations, set up specifically for the life time of each project. In other words, the information systems should be flexible enough in order to be set up on an ad hoc basis.
Access to new technological information A constant flow of information concerning the evolution of product and process technology was one of the most important inputs in operational development work identified by the interviewees. Technology scanning, defined as the systematic exploitation of scientific, technological and technical-economical information (Jakobiak, 1991), was needed both to keep up with the evolution of the suppliers' specific field of expertise, and to develop new knowledge in terms of trends and evolution beyond the core technologies used and analyzed during operational development work. Related to the central role of technology scanning, design engineers and project managers asked for a specific organization of scanning activities as a support structure for developing innovative product solutions in the functional areas covered by the suppliers. As in the case of coordination and communication, they were convinced that information systems could play a central role in such an organization. Two explicit user needs were expressed: UN4
204
Ensuring exhaustive and rapid dissemination of the results of technology scanning activities. The productivity of scanning activities was found to depend on efficient dissemination of the obtained information in order to facilitate R&D Management 30, 3, 2000
UN5
analysis by operational design staff, and decision-making at the project and functional management levels. Improving the integration of operational R&D staff in the technology scanning process. First, by bringing them closer to the source of the technical information ± for example, by facilitating the establishment of direct contacts between the designers and developers of new process technologies and materials, second, by involving them further in the decision-making of how to use new technologies.
That technology scanning can be very important for the development of new products and was made clear through the case study of the fastening expert supplier and its plastics division. According to the design engineers, new process technologies and new materials, which allow for change and evolution of product functions, had been the principal sources of product innovation in plastics. Examples of production technologies that had allowed for the design of much more complicated products over the past years were gas injection, and bi-injection systems.
Development of an organizational memory R&D Managers and engineers shared two major concerns related to the efficiency of R&D projects. First, they liked to see more capitalization of earlier design efforts. They had a feeling of too often `reinventing the wheel' in new projects. Second, they were concerned with waste related to work on design solutions that either had been rejected earlier, but where this information was not available to the design engineers, or had been hindered in their commercialization due to competitors' patents. However, incomplete design efforts, seen as a problem of waste, could be transformed into useful experience only if there were some mechanisms or structures able to integrate these experiences. Two specific user needs were expressed in this context: UN6 UN7
Allowing access to blueprints and specifications for design studies that were never prototyped, produced or commercialized. Provide storage of project histories including design reviews and customer feedback.
If the notion of memory is defined as `the mechanisms through which a certain acquisition is held available and can be recalled and reutilized' (Reuchlin, 1990, p. 173), it seems obvious that what both managers and operational people were looking for was an organizational memory making it possible to store, search for, and apply different kinds of information at any moment when this was suitable for an activity at hand. # Blackwell Publishers Ltd 2000
Information systems in fast cycle development
Discussion of the findings We will discuss and analyze the findings in the following sections.
Connecting the unsatisfied user needs to information systems A shared database for the component or system in question could help fulfill the first need. A clear definition of project participants at project outset and basic information concerning their different capabilities (e.g. who can do what kind of black box engineering?), would be the main content of such a database. The OEM disposed of a data base where its direct and some of its indirect suppliers were listed, analyzed, and classified into different groups. However, access to this database was limited to the OEM and contained information that might be sensitive to spread, for example, information pertaining to performance history and financial data of certain suppliers. If a common database could be set up for all suppliers involved in the engineering of a component=system, then only data agreed upon by the suppliers would be included. The updating of this database would be required when a new supplier enters, or when an already existing supplier exits the engineering activity of the component system, or, when supplier capabilities change significantly. Using common software such as Microsoft Office would minimize the cost of the database. Based on information received from the contributing suppliers, the system coordinator (OEM or system supplier) could host the data base and keep sole responsibility for input and updates. Concerning the second need, the continuous tracking of the system's evolution calls for an information system enabling a much more dynamic access to both quantitative and qualitative data. The current use of 3D CAD could be extended to encompass as many project participants as possible, thus playing the role of a `consistent virtual prototype that progressively embeds more and more design information' (Sanchez, 1996; Corso and Paolucci, 1997). Needs pertaining to qualitative data, i.e., verbal explanations of the evolution of the CAD drawings, could be met with a data base, slightly more advanced than previously discussed, containing for example, a window for the latest modification and a storage device to keep track of previously integrated modifications. All suppliers in the concerned component system should have both input and reading access to this database. Its efficient use would be dependent on the timeliness of the updating, and the accuracy of the information made accessible. These imperatives require rigor on the part of all players involved, especially the system coordinator, who would be most likely to host the data base and also manage it on a daily bases deciding, for example, when to transfer information from the `news' area to the storage area. # Blackwell Publishers Ltd 2000
The third user need calls for an information system allowing for interpersonal information exchange and discussion to take place. At the most basic level, it could be satisfied by using regular e-mail in the individual supplier firms. However, the engineers asked for an immediate connection between an information system presenting the evolution of the engineering of the component system (as discussed above), and the possibility to send messages and even conduct virtual collective meetings. A group-ware or intranet set up around the component system could satisfy this need. The first three user needs, related to the improvement of coordination and communication, call for collective access to different kinds of information systems. The concerned companies would need to be connected through computer networks. Networks would mean a radical change in computer tools supporting design because all the different companies contributing significantly to the development of a product would be enabled to interact on the same three-dimensional model or in the same discussion forum. Concerning the user needs expressed in relation to access to technological information, UN4 would basically call for a database where the information resulting from technology scanning could be found. However, the constant time pressure in development projects would most probably hinder people from looking for the information. Thus, the scanning information could be diffused in a push manner, for example through regular diffusion of personal messages containing the latest information. Moreover, the interviewed engineers preferred an interactive system in order not only to facilitate access to information, but also to make discussions, comments, and questions possible and available to the entire product and process engineering organizations, as well as to manufacturing. It is important to note that in contrast to a support system for design, an information system for diffusion and discussion of technical information ought to be isolated from competitors, customers and suppliers ± at least until a first evaluation of the information has been undertaken within the concerned firm. Information related to scanning of new technology and patents typically pertains to the long-term strategic orientations of a company. The importance of information exchange and communication related to technology scanning stems from the fact that the scanning process involves several different players: the observers, the analyzers, the decision-makers, and the users. UN5 should be seen in light of the fact that observation and decision-making were mainly conducted by product development managers, sales engineers, or specialized staff. In some cases, however, operational design staff had been able to integrate directly with the developers of a new process technology at a very early stage. This R&D Management 30, 3, 2000
205
Klas SoÈderquist and Rajesh Nellore opportunity to discuss new process technology, using concrete design problems as a point of departure, had facilitated the assessment of the technology in question, and, ultimately, the decision whether to further investigate it. An information system fulfilling this need could be based on an extension of the configuration discussed for satisfying the first need. Sources and names of information providers should systematically be put into the data base. Occasionally, information providers could also be connected to discussion fora. Moreover, the different players in the scanning process would need to be given access to the system and also to share information at different stages of the analysis and decision-making processes. In terms of supporting a collective organizational memory, user need six concerns product data bases that were present in all of the case study companies. However, these contained only blueprints and specifications for design studies that had resulted in commercialized products. The interviewees thought that it might be useful to expand the product data bases to all design studies for which a blueprint has been made, i.e., to encompass design studies that were never prototyped, produced or commercialized. This would reduce the redundant work on design propositions previously rejected and considerably expand the databank in which to search for ideas when faced with a new design demand. A word of caution was expressed in this context. Keeping `junk' designs, sketches, and unfinished work on the database might require more resources and cause difficulties in the management of the `portfolio' of design capabilities. Strictly limiting the storage of unfinished design to those resulting in a blueprint might be one way of dealing with these potential problems. Moreover, R&D managers and design engineers would need to commonly assess the content of the database at regular intervals, possibly deleting certain traces. UN7 was emerging in the expert supplier firms as a result of a reorganization of the project methodology undertaken by the systems supplier. Since 1997, the systems supplier has been implementing and starting to use a rigorous method for project management with a clear definition of five different project phases, and emphasis on `front-loading', i.e., putting more effort in the early stages of the development process and implementing interfunctional and interfirm review sessions both during and at the end of each phase (Thomke and Fujimoto, 1998). These reviews, which took place at the design center or in the production facilities of the systems supplier, provided a unique opportunity for the expert suppliers to meet not only their direct customers, but also representatives from the auto OEM. Since this method has been applied, the design engineers at the expert suppliers considered the project reviews as the main source for improving current and future designs and for anticipating future evolution of functional and technological needs. 206
R&D Management 30, 3, 2000
However, the expert suppliers' lack access to the group-ware in which the systems supplier feeds summaries of the design reviews. Moreover, the former would need to store and internally share more detailed and extensive information than the systems supplier is able to keep track of (the systems supplier deals with over 150 expert suppliers world-wide). The user need expressed in the expert supplier firms was thus to set up their own combination of data base and discussion forum, keeping track of each project's evolution in terms of problems, customer input, learnings, and partial and final problem solving. The possibility of transferring experience from more advanced to less advanced projects was also addressed in this context. To sum up, the information technology solutions needed to satisfy the different user needs already exist in the market in one form or an other. In fact, independently of the nature of the user need, i.e., improving project coordination, technology scanning efficiency or the capitalization of existing knowledge, the basic needs could be satisfied with data base technology, while some more advanced needs call for a group-ware.
Relating the satisfaction of user needs to operational development work When connecting the results and discussions concerning the user needs on information systems to the learning=development framework developed from the literature survey, it appears that most of the needs mirror the suggested double nature of operational development work, i.e., doing and reflecting. Even though the objective of the present study was not to test the relevance of the learning=development framework (the latter was used in order to guide the data collection), the integration between thinking and practice was also confirmed by the fact that none of the interviewed design engineers objected to our double question on the needs for information systems supporting both routine and cognitive activities. The user needs expressed for improving coordination and communication flows reflected firstly (UN1, UN2) needs for having comprehensive and continuously updated information about and from the other system participants. Satisfying these needs with some sort of data base could contribute to the development of routines for rigorously identifying and integrating all key participants at project outset, and for carefully and systematically checking the modifications undertaken by each contributor (OEM, systems supplier, expert supplier) once a project is running. During regular project reviews, it would be quite easy to check that these routines are respected. Satisfying user need two could also have an impact on frameworks in the sense that a more transparent vision of how other contributors act and react in relation to modifications could modify the belief systems and organizational assumptions about one another. # Blackwell Publishers Ltd 2000
Information systems in fast cycle development The last observation would be even truer for user need three. The opening of a collective dialogue on the dynamic evolution of a project, expressed by UN3, would be an excellent means for better knowing, anticipating, and ultimately understanding the priorities, behaviors and limits of one another. The assessment of a component solution and the elaboration of modifications could both explicitly and tacitly be influenced by that kind of dialogue. Finally, through its potential for facilitating and enhancing communication, a group-ware or intranet set up around a component system could also help formalize the routines for testing and design=project reviews. User need four and five are related to the assessment of new product or process technology. If we separate the objectives of scanning activities and the means for integrating the information in operational development work, the user needs once again reflect both frameworks and routines. The prime objective with technology scanning is to provide new input to the reflecting side of operational development work, i.e., the assessment of current product solutions, and the elaboration=planning of new solutions in light of the potential evolution of technology. Satisfying UN4, a request for exhaustive and rapid dissemination of the results of technology scanning, might enhance the integration of new technologies in the assessment and elaboration=planning phases. Satisfying UN5, a request for bringing operational design staff closer to the sources of technical information and for involving them closer into the decision-making of how to use new technology, might modify their perceptions and belief systems concerning how to use different kinds of technology. An example from the supplier of high precision screw-cut parts illustrates this point. The process-engineering manager was examining a new laser-based technology for pre-cutting metal parts before proceeding to the screw-cutting operations. Traditionally, the pre-cutting did not interest the design engineers as they developed their functional solutions as if the pre-cutting was done without their intervention. The process engineer, however, invited two design engineers to join him on a visit to several suppliers of laser-based cutting technology. The design engineers immediately changed their minds concerning the importance of pre-cutting when they realized that this operation could provide significant gain in the laborious process of designing an optimal tolerance of a surface. In fact, after this experience, which involved both access to and direct contacts with the suppliers of technology, and participation in the decision-making process, the design engineers started to look more systematically for information on process technology in relation to their design problems. This also resulted in their adhesion to the user needs 4 and 5. These user needs also reflect a need to change the routines related to technology scanning, i.e. the means by which scanning activities are accomplished. # Blackwell Publishers Ltd 2000
Improving the dissemination of the results of technology scanning would require new routines in terms of information transmission and storage, for example systematically feeding new information into a shared data base. Allowing design engineers to participate in the scanning and decision-making processes would require new routines at three levels: modified information transmission patterns, modifications in the management of the interfaces with suppliers and early adopters of new process or product technology, and modifications in the decision-making process in terms of involving more people and letting them share strategic information. The last two user needs (UN6 and UN7), which were connected to the development of an organizational memory, call for access to both `hard' data in terms of previously produced design solutions, and essentially qualitative information in terms of design reviews and project evaluations. A routine, shared by all of the interviewed design engineers, was to start looking for existing designs when beginning a new study. However, this can often take a long time, and results in long and unproductive searches for paper blueprints stored away in archives. To avoid this kind of waste of time, the CAD-system used by the systems supplier was linked to a project data base in a manner that allowed the design engineers to immediately discover if similar solutions existed in the base. When drawing a couple of lines on the CAD, a list of existing blueprints with similar design and dimensions were exposed to the engineer with the possibility of downloading the different drawings. When designing a plastic component, for example, several basic forms can be used. A system that makes an automatic search whenever the first lines or basic forms are drawn can allow for significant time savings through reduction of redundant work. Used in this way, a project data base will support the routines applied at the start of every new design project. As argued in the literature section, an important part of the knowledge employed in product development work is tacit. Our interviews demonstrate the fact that engineers in the different companies all had a company-specific answer to what was a `good' solution to an operational design problem. For example, at the fastening supplier, plastic fasteners were considered less sophisticated than metal ones. Thus, in the case of black box engineering, the engineers prefer to develop a metal solution. Such behaviors can be explained by non formalized knowledge or experiences, retained in the behavior, minds, and memories of individuals and groups. An information system acting as a collective memory could help to share and transmit, but also to modify such tacit knowledge. For Boland and Tenkasi (1995), the main objectives of an information system supporting technical work are those of perspective making and perspective taking. `Perspective making is the process whereby a community R&D Management 30, 3, 2000
207
Klas SoÈderquist and Rajesh Nellore of knowing develops and strengthens its own knowledge domain and practices' (p. 356). Perspective making involves appropriation of knowledge and information. Perspective taking is then defined as the appreciation of the knowledge previously acquired, resulting in a synergetic utilization of it. In order to support the processes of perspective taking and perspective making, Boland and Tenkasi (1995) propose five functions that information systems should satisfy: * * * *
*
Support the narrativizing of experience and share the narratives with others; Capture a community's cooperative efforts and explicitly talk about the individual understanding; Expose assumptions and meaning to the reactions and criticism of others; Explore the outcomes of the use of alternative models and theories through dialogue and experiments; Provide state-of-the-art expertise in different domains, including the use of the internal information system itself.
This typology pinpoints the vast array of functions that an information system might provide in the process of operational development work. It corroborates our conclusion that information systems might support both the development of frameworks, for example through enhancing narrative=exposing opinions to the reaction of others, and the development of routines, for example, by capturing the cooperative efforts and the collective competencies of an R&D team. Building separate systems, as implicitly suggested by Boland and Tenkasi (1995), could in our opinion hamper the objective of inter-functional and inter-firm integration. However, an integrated system could contain areas reserved for specific actors, for example task narrative or knowledge representation forums reserved for design engineers.
Barriers to the development of information systems to satisfy user needs There is a widespread expectation that computer aided communication networks will enable organizational members to work more flexibly, to span contexts and boundaries, to share knowledge and competencies, and to collaborate more effectively (Hinds and Kiesler, 1995; Orlikowski et al., 1995). The identified user needs all share this expectation. As one design engineer at the fastening expert supplier said: `If only we had the appropriate tools, more and better inter- and intracompany information exchange would reduce redundancies and misunderstandings, thus reduce the time wasted and also help people know to whom to ask the right questions'. However, several barriers to information sharing can easily be identified. When looking through the user 208
R&D Management 30, 3, 2000
needs, it seems obvious that the main problem in satisfying them would be to motivate people to feed all required information into the systems, to share sometimes sensitive information, to search for information, and finally to manipulate information. A general concern expressed by several interviewees in all companies was the reliability of the information transmitted by different participants. Reliability is a function of the trust that the participating firms have in each other. This trust will, in turn, be a function of how well different individuals (design technicians and engineers, project managers) know each other and of the previous behavior of different players towards each other. In order to cope with this problem, it seems necessary to use the information system in accordance with the level of trust and integration, and related organizational situations that are at hand at any given moment in a given relationship. For example, a groupware could be applied only between companies where the design engineers already have personal contacts. Depending on how relationships evolve, the use and development of information systems would need to be adapted continuously. When it comes to improving coordination and communication flows, primarily spanning over company boundaries, the kinds of information system discussed here will very quickly unmask problems in the participating firms if, for example, the lead time for a design specification expected by the other partners is exceeded. It is, of course, embarrassing that problems become clearly visible, but it is, above all, strategically risky in terms of keeping the business with the customer in the long term. Only a true partnership approach can reduce this negative effect. In such an ideal context, a company having trouble ought to inform the other development partners in order to make it possible for them to assist in finding a solution. Concerning improvement of technology scanning, nothing guarantees that project managers or specialized staff will be willing to share their decision-making power with operational development staff. Finally, when organizational memory is discussed, design engineers and project managers would certainly not be willing to feed embarrassing errors into the shared memory of the organization. Without going into a discussion of group psychology or group sociology, it seems clear that behavioral factors grounded in power struggles and opportunistic behavior both at the individual and company levels can become barriers to the development of the different kinds of information systems that have been discussed.
Conclusions and managerial implications Our interest in information systems and their potential for improving performance in integrated product development, led us to ground the demands on such # Blackwell Publishers Ltd 2000
Information systems in fast cycle development systems in the modeling of operational development work based on in-depth studies of people at work. This modeling led to a focus on user needs in three different areas; improvement of coordination and communication, access to new technological information, and development of an organizational memory. In order to summarize the central findings, we propose a model for the evolution of information systems that might support operational product development work and satisfy the identified user needs (Table 1). The above model can then be compared to the existing state of information systems where the main Table 1.
problem was that they were fragmented and also lacked appropriate dissemination functions, thus hindering the active participation of all the concerned players. An integrated information system would enable linking of existing but separated information devices inside a company, and within a group of suppliers working on a component system. We suggest that companies might apply a step-by-step approach to information system implementation under the condition that the chosen solutions can be successively extended to a higher level of complexity and integration. Besides careful attention to user needs, this
Model for the evolution of information systems.
User Need
Information system satisfying the need
Support provided for operational development work
1.
Informing the individuals in each contributing supplier firm about who are the other participants in the system and what are their respective roles and competencies.
Shared data base.
Contributes to the development of routines for improving coordination and communication flows (who is able to do what?).
2.
Informing the individuals in each contributing supplier firm about the modifications undertaken on individual components and interfaces by everyone involved in engineering.
System enabling dynamic access to both qualitative and quantitative data.
Contributes to the development of routines and frameworks for improving coordination and communication flows (who does what and how?).
3.
Allowing the individuals in each contributing supplier firm to react and comment on design modifications, thus opening up for a collective dialogue concerning the performance of the system.
System allowing interpersonal information exchange and discussion.
Contributes to the development of frameworks for improving coordination and communication flows (how are things done and why?)
4.
Ensuring exhaustive and rapid dissemination of the results of technology scanning activities.
Database containing technology scanning related information.
Contributes to the development of frameworks for enhancing the integration of new technologies. Contributes to the development of routines for improving access to information.
5.
Improving the integration of operational R&D staff in the technology scanning process.
Extension of the shared date base in order to include sources and names of information providers.
Contributes to the development of frameworks for modifying perceptions and belief systems concerning how to use different kind of technology. Contributes to the development of routines for information transmission, interface management, and decisionmaking.
6.
Allowing access to blueprints and specifications for design studies that were never prototyped, produced or commercialized.
Product data bases that contain all design studies for which a blue print has been made.
Contributes to the development of routines for better integrating existing experience at the start out of new design studies.
7.
Provide storage of project histories including design reviews and customer feed-back.
Combination of data base and discussion forum to keep track of each projects evolution in terms of customer input, learnings, partial and final problem solving.
Contributes to the development of frameworks for better integrating previous experience and thus enhance the development of tacit knowledge and even render some tacit knowledge more explicit and easier to understand and share between engineers and other participants in the product development process.
# Blackwell Publishers Ltd 2000
R&D Management 30, 3, 2000
209
Klas SoÈderquist and Rajesh Nellore approach calls for close collaboration between product development and information systems managers. Another important outcome of the development and implementation of integrated information systems fulfilling a range of specific user needs, is that it will require a certain formalization of the different procedures in the product development process. Thus, the information system development and implementation might contribute to a clearer definition of the roles of one another and to a clearer view of the company's state-of-the-art knowledge in terms of product development. These points could be seen as additional goals that an information system should fulfil besides the fulfillment of traditional product development goals such as reduced cost and lead-time, and improved quality and innovativeness. As demonstrated in the discussion of potential barriers, the suggested redefinition of the computeraided systems that support the design process will not take place without difficulty. However, the previous lack of standards for existing CAD-systems in the European auto industry is pushing OEMs and suppliers to redesign their systems. In this process of redefinition and harmonization, CAD experts that were interviewed saw great opportunities for expanding the systems to also comprise more qualitative information exchange and instant updating of data. By grounding the architecture of information systems for integrated component development in a modeling of the development problem-solving cycle, we hope to limit the problems of user acceptance, very common in new information system implementation. When following this logic, the internal project structure and the configuration of the customer-supplier interfaces of a company will not need to be modified to fit the system. However, the implementation of new information technology might very well inspire organizational change if it reveals potential for improving the productivity of operational design. Our argument is that if new forms of information sharing are developed, new forms of organizations can be enabled. Finally, what could the R&D manager do in order to start out on a venture of developing new information systems? Basically he or she has two means at his or her disposal. As presented in the conceptual model of operational development work, these are hands-on implementation (of new systems, methods or tools), and visionary leadership. When it comes to implementation, care must be taken so that flexible solutions with development potential are chosen. Implementation should also be based on a careful assessment of user needs, this is the very essence of the message in this research. Visionary leadership might play an important role to explain and disseminate corporate goals, link them to the product development strategy, and to operational design activities. Our study indicates that only through dialogue between managers and operational staff, and explicit links between 210
R&D Management 30, 3, 2000
strategy and operations, relevant support structures in terms of information systems can be implemented for product development.
Future research The user needs identified in this paper may be seen as examples only. A quantitative study would be needed in order to identify and also assess the importance of a much more vast array of user needs. Further research would also be interesting to undertake on the very process of identifying user needs before implementing information systems in operational product development work. Who are in charge of identifying the needs? What conceptual models can be used for facilitating the process of user need identification? How are operational design staff integrated in the process? Finally, it would be interesting to compare the degree of satisfaction with information systems in place, and the process with which user needs were identified and taken into consideration.
Acknowledgements The authors would like to thank the managers and engineers in the case study companies who allowed us to access their product development departments and share strategic, tactical, and operational issues through direct and participant observation of operational product development work. We also wish to thank the two anonymous reviewers for their thoughtful comments that were instrumental in improving the paper significantly. This paper was written when Rajesh Nellore was employed as a manager at Scania in Sweden.
References Allen, T.J. (1977) Managing the Flow of Technology (3rd ed. 1986). Cambridge MA: MIT Press. Boland, R.J. and Tenkasi, R.V. (1995) Perspective making and perspective taking in communities of knowing. Organization Science, 6, 4, 350±372. Bowen, H.K., Clark, K.B., Holloway, C.A. and Wheelwright, S.C (1994) The Perpetual Enterprise Machine. New York: Oxford University Press. Bucciarelli, L.L. (1988) An ethnographic perspective on engineering design. Design Studies, 9, 3, 159± 167. Calabrese, G. (1997) Communication and co-operation in product development: a case study of a European car producer. R&D Management, 27, 3, 239± 252. Carter, D. (1992) Concurrent Engineering. Reading MA: Addison Wesley. Clark, K. and Fujimoto, T. (1991) Product Development Performance. Strategy, Organization and Management in # Blackwell Publishers Ltd 2000
Information systems in fast cycle development the World Auto Industry. Boston MA: Harvard Business School Press. Coleman, J.L., Bhattacharya, A.K. and Brace, G. (1995) Supply chain reengineering: a supplier's perspective. The International Journal of Logistics Management, 6, 1, 85 ± 92. Collins, J. (1999) Turning goals into results. Harvard Business Review, 77, 4, 71 ± 82. Corso, M. and Paolucci, E. (1997) The ambiguous role of IT in determining knowledge specialization and architectural innovation capabilities in product development. Proceedings from the 4th International Product Development Conference, Stockholm School of Economics, 26 ± 27 May, 211± 226. Dertouzos, M.L., Lester, R.K. and Solow, R.M., (1989) Made in America: Regaining the Productive Edge. Cambridge MA: MIT Press. Durand, T. (1995) Concurrent engineering and interfunctional project groups. International Journal of Technology Management, 10, 1, 67 ± 78. Dyer, J.H. (1996) Specialized supplier networks as a source of competitive advantage: evidence from the auto industry. Strategic Management Journal, 17, 271± 291. Freyssenet, M., Mair, A., Shimizu, K. and Volpato, G. (1998) One Best Way? Trajectories and Industrial Models of the World's Automobile Producers, Oxford: Oxford University Press. Goodman P.S. and Darr, E.D. (1996) Exchanging best practices through computer ± aided systems. Academy of Management Executive, 10, 2, 7 ± 19. Hayes, R.H., Wheelwright, S and Clark, K.B. (1988) Dynamic Manufacturing. New York: The Free Press. Hinds, P. and Kiesler, S. (1995) Communication across boundaries: work, structure, and use of communication technologies in a large organization. Organization Science, 6, 4, 373± 393. Jakobiak, F. (1991) Pratique de la veille technologique (Practicing Technology Scanning, in French). Paris: Les Editions d'Organization. Karlson, B. (1994) Product Design, Towards a New Conceptualization of the Design Process, Unpublished Doctoral Thesis, Stockholm: Royal Institute of Technology, Department of Industrial Economics and Management. Kerssens-Van Drongelen, I.C., de Weerd-Nederhof, P.C. and Fisscher, O.A.M. (1996) Describing the issues of knowledge management in R&D: towards a communication an analysis tool. R&D Management, 26, 3, 213± 229. Kim, D.H. (1993) The link between individual and organizational learning. Sloan Management Review, 35, 1, 37 ± 50. Lamming, R. (1993) Beyond Partnership, Strategies for Innovation and Lean Supply. Hertfordshire: Prentice Hall International. Lawson, B. (1990) How Designers Think: The Design Process Demystified (2nd ed.). Oxford: Butterworth Architecture. Leonard, R K., Wismer, R.D. and Bosserman, S. (1994) Building an integrated engineering organization. Research Technology Management, 37, 6, 14 ± 24.
# Blackwell Publishers Ltd 2000
Miller, W.L. (1995) A broader mission for R&D. Research Technology Management, 38, 6, 24 ±36. Moisdon, J.C. and Weil, B. (1992) Groupes transversaux et coordination technique dans la conception d'un nouveau veÂhicule (Transversal Groups and Technical Coordination in the Design of a New Vehicle, in French), Working Paper no. 3. Paris: Ecole des Mines. Nellore, R., Soderquist, K. and Eriksson, K.A. (1998) A specification model for product development. European Management Journal, 17, 1, 50 ± 63. Orlikowski, W.J., Yates J., Okamura, K. and Fujimoto, M. (1995) Shaping electronic communication: the metastructuring of technology in the context of use. Organization Science, 6, 4, 423± 444. Reuchlin, M. (1990) La Psychologie (Psychology, in French). Paris: PUF. Sanchez, R. (1996) Quick connect technologies for product creation: implications for competence-based competition. In Sanchez, R., Heene, A. and Thomas, H. (eds) Theory and Practice in the New Management Strategy. London: Pergamon. Schilling, M.A. and Hill, C.W. (1998) Managing the new product development process: strategic imperatives. Academy of Management Executive, 12, 3, 67 ± 81. SchoÈn, D.A. (1983) The Reflective Practitioner: How Professionals Think in Action. New York: Basic Books. Senge, P. (1990) The Fifth Discipline: The Art and Practice of the Learning Organization. New York: Doubleday. Shigley, J.E. and Mishke, C.R. (1989) Mechanical Engineering Design (5th ed.). New York: McGraw-Hill. SoÈderquist, K. (1997) Inside the Tier Model: Product Development Organization and Strategies in Automotive Expert Supplier Firms. Unpublished Doctoral Dissertation, Henley Management College, Groupe ESC Grenoble, Brunel University. Strauss, A., and Corbin, J. (1990) Basics of Qualitative Research, Grounded Theory Procedures and Techniques. Newbury Park CA: Sage Publications. Thomke, S. and Fujimoto, T. (1998) Shortening product development time through front loading problem solving. Proceedings of the 5th International Product Development Conference. Como, Italy, pp. 1015± 1030. Tichy, N. (1999) The teachable point of view: a primer. In Wetlaufer, S. Driving Change, An Interview with Ford Motor Company's Jacques Nasser. Harvard Business Review, 77, 2, 77 ± 88. Wheelwright, S. and Clark, K. (1992) Revolutionizing New Product Development. New York: The Free Press. Yin, R.K. (1989) Case Study Research, Design and Methods. Newbury Park, CA: Sage Publications.
Note 1 Group-ware is software which enables users to network hardware to share databases and discussion fora Goodman and Darr, 1996).
R&D Management 30, 3, 2000
211
