1. Aoshima, y. Industrial Relations
-
Upload
filipe-fagundes -
Category
Documents
-
view
219 -
download
0
Transcript of 1. Aoshima, y. Industrial Relations
-
8/17/2019 1. Aoshima, y. Industrial Relations
1/24
Transfer of System Knowledge Across
Generations in New Product Development:Empirical Observations from Japanese
Automobile Development
YAICHI AOSHIMA*
The objective of this article is to explore effective ways of retaining knowledge
involved in new product development. Although human-based mechanisms,
such as the direct transfer of project members, more effectively convey
knowledge required in design integration at the higher level of product systems,
the article shows that standardized mechanisms are more appropriate for
retention of lower-component knowledge. However, it is also argued that
product architecture affects these relationships through its impact on a locus of
design change in a product system. Such argument is partially tested in the
context of the Japanese automobile industry.
Introduction
Ever since effective new product development became crucial for competi-
tiveness in many industries, numerous researchers have explored factors
affecting new product development performance. Many of these studies focus
on development processes within a single development project at a specific
point in time. However, the transfer of technologies and other product-
related knowledge across different generations of projects has received littleattention. A new product, by definition, should involve ‘‘newness’’—be
different from past products. Thus, many researchers have addressed the issue
of how to break automatic knowledge flows from preceding projects, and
knowledge retention tends to be regarded as an obstacle to innovation or
*Institute of Innovation Research, Hitotsubashi University, Tokyo, Japan.
Industrial Relations, Vol. 41, No. 4 (October 2002). 2002 Regents of the University of CaliforniaPublished by Blackwell Publishing, Inc. 350 Main Street, Malden, MA 02148, USA, and 108 Cowley
Road, Oxford, OX4 1JF, UK.
605
-
8/17/2019 1. Aoshima, y. Industrial Relations
2/24
something to be avoided (Allen and Marquis 1964; Leonard-Barton 1992;
Henderson and Clark 1990; Anderson and Tushman 1990; Dougherty 1992).
However, in most cases, new products are not ‘‘completely’’ new, neither
in terms of technology nor market concepts. A technology developed forone product subsequently may be used in a range of products (Cusumano
1991; Meyer and Utterback 1993; Uzumeri and Sanderson 1995; Cusumano
and Nobeoka 1998). Additionally, knowledge about existing customers can
be a useful basis for interpreting current customer needs (Christensen and
Rosenbloom 1995). Therefore, successful new product development at least
partially depends on the ability to understand technical and market
knowledge embodied in existing products, and the adaptation of this
knowledge to support new product development (Iansiti 1997; Iansiti and
Clark 1994).Drawing on examples from the Japanese automobile industry, this study
explores effective ways of retaining knowledge across different generations
of product development. In the subsequent sections, I discuss two broadly
defined mechanisms for knowledge retention—human-based and standard-
ized mechanisms—by illustrating some practices of Japanese automobile
producers. I then identify two factors that affect the relative effectiveness of
these two mechanisms. Next, I examine my argument empirically by using
data obtained from 223 engineers engaged in 25 new automobile develop-
ment projects at seven Japanese automobile producers.
Knowledge Retention Mechanisms
The existing literature proposes several mechanisms for retaining
knowledge (Walsh and Ungson 1991; Krippendorf 1975; Huber 1990,
1991; Garud and Nayyar 1994), but for the sake of simplicity, this article
will focus on just two of these mechanisms. The first is a human-based
mechanism. Knowledge obtained through past development activities may
be partially stored in individuals. Therefore, bringing persons who haveappropriate experience in past development into current projects is one way
to transfer knowledge across generations (Roberts 1979). In an extreme
case, the same group of people successively takes charge of multiple
generations of product development. There are, however, obvious limita-
tions in completely depending on a particular individual or group: when
people leave, knowledge disappears. To overcome this problem, companies
may partially overlap project members across different generations and
create a chain of overlapped common experience among their people. For
example, Nakayama (1997) investigated the history of Japanese aircraft
606 / Yaichi Aoshima
-
8/17/2019 1. Aoshima, y. Industrial Relations
3/24
development from the Zero fighter in the 1930s to the FSX support fighter
in the 1990s and found that ‘‘development technology’’ has long been
retained either through continuity of key persons or by overlapping project
members across different generations of projects. In particular, he foundthat overlapped membership in the medium-scale intermediate projects,
which bridge the gap between large-scale next-generation projects, played
an important role in retaining development technology.
This study of the Japanese automobile industry reveals the same kind
of overlapped membership across generations of projects. For example,
Figure 1 shows the project manager groups on the Celica/Carina/Corona
projects in Toyota.
The figure shows that most project managers for these projects were
promoted from their former positions as subproject managers within thesame series development. At Toyota, project mangers and their staff
formerly worked in the Product Planning Office.1 Typically, engineers with
seven to 10 years’ experience in body design or chassis design move to the
Product Planning Office at around age 30. They then become responsible for
particular vehicle development projects, working as staff members of project
managers. New entrants to the Product Planning Office start from the Shu-
tantoin (a lower-ranked subproject manager). They are then promoted to
the Shusa-tsuki (a subproject manager) and Shusa (a project manager),
most often within the same product line.2 They are trained as candidates for
future project managers and learn how to coordinate and integrate theentire product development process. Once they become Shusa (now Chief
Engineer (CE)), they tend to be responsible for two successive product
generations. As a reason for this continuity of project managers,
Mr. Nakagawa, CE for the fifth generation of the Celica project, made
the following comment:
Even if the present Celica uses a different technological concept from the past, the
characteristics of users have some commonalty. To understand the characteristics
of users needs long experience [therefore, a project manager tends to stay in the
same project for a long time]. For example, although the current Celica sharesbasically the same 2.2 liter engine, 5SAF, with the Camry, we did not use the
balance shaft for the Celica engine, because I knew that Celica users require more
power at the cost of noise. Also, when we decided to carry over a part of the under-
floor panels from the previous model, I learned from the past project several issues
1Toyota reorganized its product development organization in 1992 and divided it into three vehicle
centers and one advanced engineering center. The Product Planning Office was disbanded and absorbed
into each of three vehicle centers.2In the late 1980s, Toyota changed these titles. Since then, what was formerly a Shusa is called CE
(Chief Engineer); the former Shusa-Tsuki is called Shusa.
Transfer of System Knowledge Across Generations / 607
-
8/17/2019 1. Aoshima, y. Industrial Relations
4/24
such as what kinds of problems occurred in previous projects both in technical and
user characteristics.3
This comment seems to indicate that continuity of project members may
be required to deepen the understanding of linkages between user needs andrequired design features.
Another mechanism for knowledge retention is a more standardized one.
Project members may document knowledge obtained from past development
activities in written or electronic form. A drawing or blueprint used in design
activities can contain important knowledge. Companies also can make use of
various others kinds of documents and reports for retaining past experiences.
Such documents and reports vary in terms of their formality. For example,
FIGURE 1
Project Management Groups of the Celica/Carina/Corona Projects
3Interview with Mr. Nakagawa, Chief Engineer, Toyota Motor Corporation, May 31, 1994.
608 / Yaichi Aoshima
-
8/17/2019 1. Aoshima, y. Industrial Relations
5/24
documents and reports used at Japanese automobile producers can be
broadly classified into the following categories (although boundaries
between these categories differ somewhat across companies):
1. Companywide technical standards (e.g., Toyota Technical Standard).
2. Department-level design standards, standardized design (test) proce-
dures, and design (testing) tools (e.g., Layout Check List at Honda).
3. Formal reports and documents storing nonstandardized knowledge,
such as process and design know-how documents, testing reports, and
user-claim reports (e.g., Know-How Document at Mitsubishi).
4. Informal documents and memos to keep track of past problematic and
successful cases (e.g., Problem-Information Memo at Mitsubishi).
The first two documents describe standards and rules that engineers mustfollow. The last two documents are more flexible and describe design
know-how, testing results, and other problematic and successful cases found
in previous development activities. Japanese automobile producers use such
documentation extensively as a means to store knowledge about past
practices. Although engineers are not obliged to record information, it
seems to be a common practice for them to write down information
obtained from their development activities.
In addition to documents, an advanced computer-aided design (CAD)
system helps project members store and retain knowledge. CAD systems
serve not only as tools to help design and test, but also as facilities for
retaining prior knowledge obtained through design and testing experiences.
Data stored in the CAD system can be directly reused in future design work.
For example, since an automobile body consists of several separate body
panels (e.g., front, center, and rear floor panels), each of which has a
particular drawing stored in CAD, designers often reuse and edit designs
from existing body panels and recombine them with newly designed panels
to develop the entire body design. Similarly, computer-aided engineering
(CAD) models reflect knowledge obtained from the prior prototype testing.
Whether companies develop their own CAE models or use commercialpackages, it is critical to incorporate their experience of actual prototype
testing into CAE models to make it usable.
Factors Affecting Effectiveness of Transfer Mechanisms
When should companies depend on a human-based mechanism for
retaining knowledge in product development? When should they use a more
Transfer of System Knowledge Across Generations / 609
-
8/17/2019 1. Aoshima, y. Industrial Relations
6/24
standardized mechanism? What determines the relative effectiveness of these
two methods? The following sections discuss two factors that have the
potential to affect effectiveness: the nature of the knowledge and the
frequency of design changes needed for a particular product architecture.
Nature of Knowledge Retained. First, some knowledge is inherently more
suitable for a human-based knowledge retention mechanism than for an
archival-based one, and vice versa. The inherent nature of knowledge
directly influences the effectiveness of retention mechanisms. This article
pays particular attention to the systemic nature of knowledge and the
associated context-specificity (Zander and Kogut 1995; Garud and Nayyar
1994; Badaracco 1991; Iansiti 1998).
As many researchers have pointed out, the design of new ‘‘systems’’products (i.e., products that contain numerous components and technol-
ogies that must work together) invariably depends on a complex interaction
among potentially fragmented individual knowledge bases (Clark and
Fujimoto 1991; Henderson and Clark 1990; Iansiti 1997; von Hippel 1994).
On the one hand, knowledge required for new product development comes
from various domain-specific and specialized disciplinary areas. Such
knowledge tends to be generalizable and independent of a specific context.
On the other hand, new product development demands the integration of
specialized knowledge with other information and its application to specific
contexts. This latter type of knowledge will be called ‘‘system knowledge.’’4
Architectural knowledge, defined by Henderson and Clark (1990) as
knowledge that is about the interactions between physically distinctive
components, is one special case of system knowledge.
Development of a printer, for example, calls for an understanding
of precision machinery engineering, mechanical engineering, optical elec-
tronics, material sciences, imaging science, and so on. However, a mere
collection of such specialized knowledge does not necessarily lead to the
development of a good commercial printer. For a printer to work well as a
coherent system, engineers must understand complex interactions and subtlebalances among such specialized technologies and knowledge, which must
be managed so as to adapt the end result to a particular use environment.
The system/domain-specific dimension of knowledge is closely connected
to the tacit/explicit dimension, which many management studies have
discussed (Nonaka 1994; Zander and Kogut 1995; Garud and Nayyar
1994). System knowledge tends to be tacit. It is difficult, if not impossible, to
articulate system knowledge because of its embeddedness in a specific
4Iansiti (1997) uses the same conceptualization of system knowledge.
610 / Yaichi Aoshima
-
8/17/2019 1. Aoshima, y. Industrial Relations
7/24
context. This embeddedness is one element of ‘‘tacit knowing,’’ a concept
introduced by Polanyi (1966). According to him, we may say that we know
more than we can tell when we comprehend the entity (a whole) without
being able to specify its particulars (parts). He describes ‘‘achieving anintegration of particulars to a coherent entity to which we are attending.
Since we were not attending to the particulars in themselves, we could not
identify them (p. 18).’’ For example, we can identify physiognomy without
specifying its features.
The same concept can be illustrated by the development of products
consisting of various components and technologies. Throughout product
development processes, project managers try to find an appropriate way to
integrate components, technologies, and other elements so that all will
function together as a coherent product system that will be valuable totargeted customers. The appropriateness of this integration is understand-
able only in light of the context of the final product, which is mostly
provided by users of the product. The relationship between this context and
the product’s elements tends to remain tacit.
For example, in the case of automobile development, vehicle styling
solely for the purpose of maximizing aerodynamic performance can be
theoretically determined and generalizable. However, linkages between the
styling, the body structure, the engine shape, and the suspension type will
be different among vehicles, which will be of different sizes, for different
purposes, and have different customer bases. Without understanding sur-rounding contexts of the product, one cannot know how and why the
components are integrated in a particular way. In other words, we cannot
communicate what we know about the integration of components without
sharing the contexts.
Regarding the context-specific nature of system knowledge, von Hippel
and Tyre (1995) found that problems in the introduction of new process
technology were often discovered through learning by doing by field
engineers after process introduction. Since such problems are invariably
caused by subtle and specific interactions among particular attributes of machine design and user environments, they are difficult to predict. Since
field problems in production machines depend on context-specific factors,
scientific investigation to discover universal cause-effect relationships may
not be very effective.
For context specific-knowledge to be usable in other settings, people
need to retain and transfer information about numerous surrounding
contingency factors behind easily observable facts and results. Therefore, it
can be quite costly, if not impossible, to articulate context-specific system
knowledge.
Transfer of System Knowledge Across Generations / 611
-
8/17/2019 1. Aoshima, y. Industrial Relations
8/24
The most direct way to transfer and retain less-articulable and context-
specific system knowledge may be to transfer or retain individuals who have
first-hand experience with the context. In some cases, system knowledge
may be held by a group of people who share the context. In other cases,system knowledge might be embedded in specific relationships between
people. This latter situation might make it necessary to retain the same
group of people for a long period of time. Wilson and Hlavacek (1984)
found that firms that benefited from technologies created in past projects
kept knowledge alive by the active presence of a core group of people.
Accordingly, I hypothesize that the more knowledge is systemic, the more
effective a human-based retention mechanism is, such as the direct transfer
of individuals or a group of people with shared experience. On the other
hand, the more knowledge is domain-specific and specialized, the best wayof retaining it is through the use of archival mechanisms, such as
documentation, standardization, and computerized systems.
Frequency of Design Change. The second factor affecting the relative
effectiveness of retention mechanisms is the frequency of design changes.
Retaining knowledge through standardized mechanisms often takes more
time than through human-based mechanisms because the former includes
articulation processes, abstraction from experiences, and knowledge
transformation between different media. If market conditions change
rapidly and fast product development cycles are critical to competition,retaining and quickly utilizing knowledge across generations of projects
may become particularly important. If companies devote too much time to
articulating past experience as, for example, propositions and causal
relationships, the experience may become outdated before it can even be
used.
As noted above, articulating knowledge is also costly. Design standard-
ization efforts, for example, often start by collecting the direct experiences
of first-ranked engineers. To promote standardization, companies may have
to ask such engineers to temporarily leave their current tasks, incurringhuge opportunity cost. If articulated and systematized knowledge is
applicable for a relatively long period of time, such costs can be justified.
If projects can use standardized designs for many generations, standard-
ization becomes an efficient way to retain knowledge. However, when
product change takes place frequently due to fast-changing environments,
the cost of maintaining and renewing articulated knowledge increases
considerably. Thus, the more frequent changes a product design receives,
the more efficient human-based mechanisms of knowledge retention become
compared to standardized mechanisms.
612 / Yaichi Aoshima
-
8/17/2019 1. Aoshima, y. Industrial Relations
9/24
System knowledge can be retained through standardized mechanisms if
projects have very few design changes at the system level. However, project
development may have to depend on human-based mechanisms of
knowledge retention if there is considerable and rapid design fluidity.The relative frequency of change between the system level and the
component or subsystem level is influenced by the design strategy of
product architecture, whose role is discussed below.
Product Architecture and Locus of Change. Product architecture is one
characteristic of a product system that involves interdependency between
the constituent components. This interdependency is, in turn, determined by
the pattern of allocating product functions to constituent components and
the interfaces between these constituents (Ulrich 1995; Ulrich and Eppinger1994). Figure 2 classifies product architectures along these two dimensions.
FIGURE 2
Types of Product Architecture
Transfer of System Knowledge Across Generations / 613
-
8/17/2019 1. Aoshima, y. Industrial Relations
10/24
Under a modular architecture, located in the upper-right cell, a product
system is divided into several physical chunks called modules, each of which
has a simple correspondence to a particular product function (Ulrich 1995).
Simple rule-based relationships among modules lower interdependencybetween constituents and maintain high design flexibility at the module
level. For example, a stereo system consists of a CD player as an input
device, an amplifier as an audio signal processor, and a speaker as an output
device. Each device or module has its own exclusive function and there are
standardized interfaces between them. As a result, users can improve
performance of a stereo system by independently upgrading each module
(Langlois and Robertson 1992).
The PC is also a relatively modularized product. Each product function is
mostly exclusively allocated: a short-term memory function is allocated toRAM; a long-term memory to a hard disk; a data-processing function to the
CPU; an input function to a keyboard; an output function to a monitor,
and so on. As long as designers keep interface rules, they can freely change
module designs without considering other module designs (Clark and
Baldwin 1997). Most of the recent dramatic performance improvement in
the PC comes from technological advancement at the component level, such
as the density improvement of the DRAM, the CPU, and the hard disk. In
other words, a design strategy of modular architecture is a decision to shift
sources of product improvement and design changes into lower levels of
product systems, such as modules and components. Changes of environ-ments are absorbed independently at the module level. Thus, a product with
modular architecture tends to show more design changes at the component
level than at the system level.
The lower-left cell of Figure 2 illustrates integrated architecture, in which
a product’s functions and physical constituents have a complex relationship,
with no simple rules specifying interfaces of constituents (Ulrich 1995). An
automobile has a relatively integrated architecture (Fujimoto 1998). For
example, the upper body of an automobile fulfills various functions, such as
shielding from bad weather, reducing air resistance, maintaining bodystrength, providing insulation from vibration, and so on. However, the
function of reducing noise and vibration is also spread over various other
components, such as the drive-shaft, the engine, the chassis, and so on. In
this way, the relationship between product functions and components, or
subsystems, in automobiles is complex and intertwined. This accounts for a
relatively high interdependence among automobile components. For
example, a change in suspension design will influence the designs for the
braking system, chassis, and body. Because of such high interdependence,
component designs are subject to more restrictions compared to modular
614 / Yaichi Aoshima
-
8/17/2019 1. Aoshima, y. Industrial Relations
11/24
architecture designs. Since the interfaces between components are not
specified by explicit rules, there are opportunities for improving the
relationships between components. The entire product performance may be
continuously improved by finding better linkages among components.Thus, I conjecture that, compared to products with modular architecture,
products with integrated architecture show more frequent design changes at
the system level and less frequent design changes at the component level. As
an illustration, the average product life cycle of Japanese automobiles is
four years, that of engines and suspensions, which have a more integrated
architecture, often exceeds eight years.
Figure 3 summarizes the above discussions.
The more systemic and context-specific knowledge is, the more effective
are human-based retention mechanisms. Since system knowledge integratesvarious technological elements, such knowledge may be more critical in
design at the higher levels of product systems: more useful in subsystem
designs than in detailed parts designs, more useful in entire product designs
than in subsystem designs.
Although I conjectured that human-based mechanisms are more suitable
for system knowledge in the integration of design activities at higher levels
of product systems, their suitability also depends upon the locus of design
changes determined by product architecture. While a modular architecture
facilitates more frequent design changes at the lower level of product
systems, integrated architecture is expected to show a relatively highfrequency of design changes at the higher level. Thus, the question of
whether human-based mechanisms are suitable for retaining knowledge at
the higher levels of product systems or at the lower levels rests on both the
FIGURE 3
Determinants of Relative Eectiveness of Knowledge Retention Mechanisms
Transfer of System Knowledge Across Generations / 615
-
8/17/2019 1. Aoshima, y. Industrial Relations
12/24
inherent systemic nature of knowledge and product architecture as a design
strategy.
Empirical Observations from Japanese Automobile DevelopmentProjects
This section conducts a partial examination of the above discussion; it is
‘‘partial’’ because it deals with only with one type of product, an automobile.
Assuming that an automobile has a relatively integrated architecture, I
conjecture that knowledge for integration at the higher levels of a product
system will tend to be retained through a human-based mechanism, whereas
retention of knowledge in designing constituents at the lower levels of theproduct system will tend to rely on standardized mechanisms.
Continuity of Core Project Members. Automobile development projects
involve numerous people with different engineering roles and functional
backgrounds. Different people invariably require different types of knowl-
edge to accomplish their tasks. For example, for project members primarily
responsible for integration and coordination of dispersed functional
activities, system knowledge should be more critical. On the other hand,
specialized and functional knowledge should be more important for people
whose primary task is to design particular component systems, such assuspension systems, braking systems, under-floor panels, and engine
components.
The discussion thus far has implied that transfer of system knowledge will
be associated with direct personnel transfers. I expect to observe that project
members primarily responsible for integration among different functional
and technical areas are more likely to continue in their positions for
successive generations of projects than are those responsible for functional
activities. In the case of automobile development, the following three types
of project members are defined as integrators: project managers, vehiclelayout engineers, and vehicle test engineers.
The role of project managers as system integrators is discussed in other
studies (Clark and Fujimoto 1991; Imai et al. 1985). Although project
managers’ responsibilities vary from project to project, my research on
Japanese automobile companies revealed that all project managers were at
least responsible for concept making, the basic vehicle plan, and coordi-
nation of development processes.
Vehicle layout design is an activity that involves complex adjustments
between conflicting engineering areas. The vehicle layout, basically, is the
616 / Yaichi Aoshima
-
8/17/2019 1. Aoshima, y. Industrial Relations
13/24
design for how the mechanical components, body structures, luggage, and
passengers will be distributed throughout the vehicle. It involves key
decision making for platform designs, basic component configuration, and
major physical dimensions (e.g., wheel base, tread, hip point). The vehiclelayout determines the basic architecture of an automobile, which expresses
total vehicle concepts in physical terms (Clark and Fujimoto 1991).
Accordingly, vehicle layout significantly influences interfaces among differ-
ent component systems, for example, between suspension systems and
under-floor panels, between engines and engine mount. Therefore, layout
engineers thus require broad-based experience in different engineering areas.
Vehicle test engineers, as opposed to component test engineers, also
engage in extensive coordination activities cutting across different compo-
nent development areas. Since the overall performance of automobiles, asindicated by, for example, NVH (Noise-Vibration-Harshness), safety, body
strength, and driving stability, is derived from many complex interactions
among individual components, a vehicle test engineer has to interact with
related component engineers to achieve targeted performance levels.
This leads to the following hypothesis:
Hypothesis 1: The probability that project managers, vehicle layout engineers,
and vehicle test engineers are transferred from the previous generation of the
project is higher than that for the other project members.
Methods. To test this hypothesis, we obtained data on project members’
experiences in the previous generation of projects by a questionnaire survey.
The sample contains 223 project members representing 25 new product
development projects at seven Japanese automobile producers. The survey
was conducted between 1987 and 1995. A questionnaire was distributed to
the following 10 project members for each project, who represented their
own activity areas for that project. These members will hereafter be referred
to as ‘‘project core members.’’
1. Project manager.
2. Representative of vehicle layout designers/planners.
3. Representative of vehicle test engineers.
4. Representative of chassis design engineers.
5. Representative of body design engineers.
6. Representative of exterior/interior designers.
7. Representative of engine design engineers.
8. Representative of electronics component design engineers.
Transfer of System Knowledge Across Generations / 617
-
8/17/2019 1. Aoshima, y. Industrial Relations
14/24
9. Representative of production engineers.
10. Representative of marketing/product planners.
All 10 responses were obtained from 17 projects, but there is some
missing data for the remaining eight projects. As a result, the sample
comprises 229 core members. Out of these, 223 responses included usable
answers with respect to experience in the previous projects.
I identified whether respondents had experience in the previous project by
asking them to list the names of past new product development projects on
which they had spent more than an average of 30 percent of their time for at
least six months. When the name of the direct predecessor model was on this
list, that respondent was treated as a project member in the previous
generation of projects. Respondents were not counted, even if they had
participated in the previous model development, unless they had devotedmore than 30 percent of their time for at least six months.5
Table 1 shows the number and the percentage of project core members
transferred from the previous project by each category of person.
Out of the 223 respondents, 83 project core members had experience in
the previous generation of projects. Out of 10 different types of core
members, layout engineers were more likely to be transferred from previous
projects (15 out of 20 layout engineers), followed by project managers (12
out of 24),6 and vehicle test engineers (11 out of 22). Being a layout
engineer, vehicle test engineer, or a project manager, as opposed to the otherfunctional engineers, makes a significant difference as to whether one will be
transferred from the previous generation of projects. This appears to
support my hypothesis that integrators are more likely to be in charge of the
same model development in successive generations.
To examine the validity of the above finding more precisely, a logistic
regression analysis was conducted. Three explanatory variables were
considered as predictors for whether project core members had experience
in previous project generations:
5This way of defining project members needs to be treated with care. Since some components, such as
electronics components, are often designed for multiple projects, engineers might not spend more than 30
percent of their time even on their principal project. We therefore considered these people as not having
worked for the preceding project unless they explicitly indicated otherwise in the questionnaire.6Some may wonder that only half the project managers are retained from previous projects despite
the importance of accumulated project management experience. One reason may be that a project
manager tends to be promoted to a higher position, especially when his project turns out to be successful.
Also, companies that do not have enough competent project managers rotate them to other key product
development projects. Additionally, if a product needs a significant change in terms of a market concept,
retaining system knowledge may have a negative impact on project performance. Aoshima (1997) reports
this effect.
618 / Yaichi Aoshima
-
8/17/2019 1. Aoshima, y. Industrial Relations
15/24
• System Integrator: A dummy variable indicating system integrators
(1 if respondents are project managers, vehicle layout engineers, or
vehicle test engineers; 0 otherwise).
• Task Newness: Percent of design change from the previous model.Available Project: The number of available projects at the time of the
start of the focal project.
Ten project core members were divided into two categories: System
Integrators or functional engineers. As already defined, System Integrators
include project managers, vehicle test engineers, and vehicle layout
engineers. System Integrator was set equal to 1 if respondents were system
integrators, and 0 otherwise.
In addition to system integrator, two control variables were included. The
first control variable is a percentage of new design, Task Newness, whichindicates the degree of change in engineering tasks from the previous
project. The previous project members might be assigned to the current
project because the required engineering work is similar between two
successive projects. For example, it could be expected that project members
will continue in successive generations if the current project activity involves
only minor modification of the previous design.
Project managers assessed the degree of novelty of the design for their
new products. Answers encompassed 10 different component systems,
including exterior/upper body, interior/trim, steering, floor panels, braking
TABLE 1
Transfer of Project Members from Previous Generation of Project
Project members in the previous
generation of project?
Yes No Total
Project managers** 12 (50.0%) 12 (50.0%) 24
Layout engineers**** 15 (75.0%) 5 (25.0%) 20
Vehicle test engineers** 11 (50.0%) 11 (50.0%) 22
Exterior/interior designers 5 (20.8%) 19 (79.2%) 24
Chassis engineers 4 (17.4%) 19 (82.6%) 23
Body engineers 10 (43.5%) 13 (56.5%) 23
Engine design engineers 9 (37.5%) 15 (62.5%) 24
Electronics component engineers 4 (19.0%) 17 (81.0%) 21
Production engineers 9 (47.4%) 10 (52.6%) 19Marketing/product planners 4 (17.4%) 19 (82.6%) 23
Total 83 (37.2%) 140 (62.8%) 223
Asterisks indicate results of the chi-square tests of independence between being each of three integrators, as opposed tothe other functional/component engineers, and being the previous project members (** p < 0:05, *** p
-
8/17/2019 1. Aoshima, y. Industrial Relations
16/24
systems, suspension systems, transmissions, engine, engine control, and
instrument panels. Newness of each design was measured on a four-point
scale: 1 ¼ minor modification of less than 20 percent of the existing design,
2 ¼ major modification involving 20–80 percent of the new design, 3 ¼ newdesign involving more than 80 percent of the new design, and 4 ¼ entirelynew technology not applied to any model before. This scale was conceived
to capture the theoretical distinction between component system designs
that are purely ‘‘carry-over,’’ involved substantial redesign, or were entirely
new designs.
The novelty involved in activities of component engineers was calculated
by averaging newness of appropriate component designs in terms of the
number of new parts involved. We measured newness of System Integrator
activities by the newness of the platform design as indicated by newness of suspension systems and under-floor panels (Nobeoka 1993). The extent of
novelty in the design activities of production engineers was measured by the
percentage of new production equipment. Marketing/product planners were
excluded from the analysis since indicators could not be obtained for their
Task Newness that were comparable to those for the other core members.
As a result, values of Task Newness were assigned to 192 project members.
The second control variable, Available Project, is the number of available
projects at the time of the current project’s start. It is expected that the greater
the number of simultaneous ongoing projects in a company, the lower the
probability of project members being transferred within the same model line.Tables 2 to 4 summarize descriptive statistics of the dependent variable,
the explanatory variables, and two control variables.
Results. Table 5 shows the results of a fitted logistic regression analysis.
Model II in Table 5 involves only control variables. It shows that the
number of available projects has a negative effect on the transfer of core
project members, as expected. However, Task Newness does not have a
significant relationship with transfer of project members, although it does
have the expected sign for the coefficient.Model III, in the third row of Table 5, involves System Integrator as a
predictor. The parameter estimate of System Integrator is 1.10, which
TABLE 2
Descriptive Statistics for Experience with Previous Project Generation
Frequency
Cumulative
frequency
Cumulative
percent
0 ¼ not members of previous generation of project 107 107 58.5%1 ¼ members of the previous generation of projects 76 183 100.0%
620 / Yaichi Aoshima
-
8/17/2019 1. Aoshima, y. Industrial Relations
17/24
indicates a positive relationship between System Integrator and previous
experience, as expected. The chi-square goodness of fit statistic was reduced
for 10.98 from Model II ð p
-
8/17/2019 1. Aoshima, y. Industrial Relations
18/24
more retention of such knowledge will benefit from the use of standardized
mechanisms, such as documentation, standardization, and computerized
systems. This implies that component engineers may use documents,
reports, design standards, and computerized media to retain past knowledgemore frequently than do integrators, leading to the following hypothesis.
Hypothesis 2: Component engineers refer to documents and reports, and use
design standards and standard design procedures, more frequently than do
integrators.
To partially examine this, engineers were asked to rate, on a five-point
Likert scale (from 1 ¼ not refer at all to 5 ¼ refer very frequently), thefrequency with which they referred to documents and reports that described
design know-how and design solutions and problems identified in the pastdevelopment activities. Similarly, respondents rated how important were the
roles design standards and standard design procedures played in their
project activities, on a five-point Likert scale, from 1 ¼ not important at all to 5 ¼ played a very important role.
Based on these ratings, a series of OLS regression analyses was
conducted. Dummy variables were introduced into the analyses, each of
which indicates a particular type of engineer. The dummies were effect
coded so that the coefficients are deviations from the overall mean. In
addition, two control variables were taken into consideration: tenure of
project members and task newness. Tenure indicates the length of thesubject’s service in the current company. We used the same measure for task
newness as used in the previous section.
Next, individual dummies were substituted for a single dummy indicating
integrators versus component engineers to explore the effect of being
integrator. Integrators include layout engineers and test engineers.7 Table 6
shows summary statistics of some of these variables.
Table 7 shows the results. This table shows that layout engineers tend to
rate significantly lower the frequency of reference to documents and reports
in their development activities. Engine and body engineers reported morefrequent references to documents and reports for the purpose of learning
from the past design activities.
As for importance of design standards and standard design procedures,
layout engineers also rated these significantly lower. Combined with the
above result, this seems to suggest that knowledge regarding vehicle layout
design is less likely to be transferred through documentation and
7Project managers were excluded from this analysis because there are no standards available for
project managers that are equivalent to design standards or test codes.
622 / Yaichi Aoshima
-
8/17/2019 1. Aoshima, y. Industrial Relations
19/24
standardization. Considering the findings of the previous sections that
layout engineers tend to continue their positions in successive generations of
projects, it appears that knowledge to design the total vehicle layout may be
less codifiable and its retention may tend to depend on personal experience.For example, one engineer responsible for vehicle layout design in the four
successive Familia (323) projects at Mazda, explained why it is important
for layout engineers to continue their positions in successive generations:
Since ‘‘Kikaku-sekkei’’ [basic design, which means the layout design in Mazda] is
related to the all engineering areas, it’s important to gain broad experiences [within
the same product line] to be able to capture a whole [complex relationships between
different engineering domains]. . . . Thus layout engineers tend to stay in the same
product line for long time.8
However, contrary to the second hypothesis, Table 7 shows that both
documentation and standardization seem to be important means of
capturing prior practices in vehicle test engineering. In particular, test
engineers rated significantly higher the importance of standards (in their
case, standards means test codes).
This may be partially because documents and reports have particular
meaning or usefulness to test engineers. While drawings are the primary
outputs for design engineers, testing reports are the primary outputs for test
engineers. Test engineers summarize test results in various forms of reports,
which they distribute to related engineering and design departments.
Knowledge related to testing activities, such as that about target perfor-mance setting, design, and production prototype evaluation, are thought to
be transferred through documentation. For example, Cusumano and Selby
(1995) report that software testers at Microsoft rely heavily on various types
of checklists and scripts.
The result also suggests that existing testing methods and established test
codes become a critical basis for testing new vehicles. Compared to design
work, testing work may require more consistency and thoroughness than
TABLE 6
Descriptive Statistics of Variables
N ¼ Mean SD Min. Max.
Frequency of reference to documents and reports 167 3.78 0.95 1.00 5.00
Importance of standards (design standards and
test codes)
165 4.06 0.94 1.00 5.00
Tenure 167 17.82 7.38 4.00 42.00
Task newness 167 0.55 0.28 0.05 1.00
8Interview with Mr. Morioka, Mazda Motor Corp., May 19, 1994.
Transfer of System Knowledge Across Generations / 623
-
8/17/2019 1. Aoshima, y. Industrial Relations
20/24
creativity. Thus, standards and documents may become important.
Although it was assumed that vehicle test engineering involves complex
integrative efforts across many different component systems development,
the testing function itself may be a well-established discipline.
Because of test engineers’ reliance on standardized mechanisms, Columns 2and 4 in Table 7 show no significant difference between system integrators and
component engineers in terms of use of documents and standards. The second
hypothesis is not supported. Although the findings for layout engineers are
consistent to with the hypothesis, from the above analysis, this cannot be
attributed to the fact that they are system integrators. The tasks of test
engineers may have distinctive characteristics that call for the extensive use of
documents and standards, which might obscure the effect of being system
integrators. However, this cannot be confirmed from the available data.
Summary
The main objective of this article was to explore effective ways of
retaining knowledge involved in new product development. I discussed the
idea that retention of knowledge about the interactions among fragmented
functional domains may demand direct transfer of individual experience
bases, but that standardized mechanisms may be more beneficial for
retaining specialized and functional knowledge. This further implied that
TABLE 7
Regression Analyses for the Use of Documents and the Importance of
Standards
Frequency of reference
to documents and reports
Importance of standards
(design standards and test code)
Tenure 0:01 0.04 0:07 0:00Task newness 0:11 0:12 0:11 0:16**Chassis engineer 0:05 0:04
Body engineer 0.16* 0.08
Engine engineer 0.19 0.04
Electronics comp. engineer 0.04 0.05
Manufacturing engineer 0.11 0.19*
Layout engineer 0:23** 0:27***Test engineer 0.11 0.17*
System integrators 0:08 0:17df of residuals 157 163 155 161
Adjusted R2 0.05* 0.02 0.07* 0.01
* p < 0:1.** p < 0:05.*** p
-
8/17/2019 1. Aoshima, y. Industrial Relations
21/24
although human-based mechanisms more effectively convey knowledge
required in design integration at the higher levels of product systems,
standardized mechanisms are appropriate for retention of lower-component
knowledge. However, it was also argued that product architecture affectsthese relationships through its impact on a locus of design change in a
product system. Modular architecture, for example, focuses design change
at the module and component levels. The resulting high frequency of design
changes at module and component levels may make human-based mech-
anisms of retaining component knowledge more suitable than archival-
based mechanisms despite its less systemic nature.
Two empirical analyses of data obtained from Japanese automobile
development projects were conducted to test these ideas. In these analyses,
first, it was found that project members responsible for integration activitiescutting across different functional domains tend to continue in their positions
for successive generations of projects. This implies that knowledge for
integration may tend to be associated with the transfer of people. On the other
hand, component engineers were less likely to be responsible for successive
generations of the same product. Second, it was found that layout engineers
tend to rely less on documents, reports, and standards to learn from past
design practices than do component engineers. These results may imply that
standardized mechanisms alone are not enough to retain knowledge
regarding interaction and integration among different design domains.
Limitations and Further Research
Limitations of this study are mostly due to considering only one industry
in one country. Because of this, the empirical part of this article has weak
connections to the theoretical discussions.
First, this study dealt with the automobile that, it is assumed, has integrated
product architecture, I did not examine knowledge retention practices in the
development of modularized products. There could be quite different results
in development projects of modularized products. For example, in the case of
PC development, there may be more dependence on human-based retention
mechanisms in the development of components such as hard disks, monitors,
CPUs and other semiconductor devices, and less on integration of those
components into final goods. Investigation of products that have been rapidly
modularized recently, such as the bicycle, may provide important additional
insights into the management of knowledge retention processes.
Focusing only on the automobile industry made it impossible to examine
the effect of the frequency of design change on retention mechanisms. The
Transfer of System Knowledge Across Generations / 625
-
8/17/2019 1. Aoshima, y. Industrial Relations
22/24
theoretical discussions in this article suggest that industries facing higher
rates of design changes tend to rely more on human-based retention
mechanisms than on standardized mechanisms. To examine this, this study
needs to be extended to include a variety of industries in terms of speed of change, ranging from a rapidly growing industry to a mature one.
Second, this article focused on the benefit side of retention mechanisms.
However, there is a cost in using them, which may differ across different
institutional settings. For example, the cost of retaining a specific individual
across multiple generations of projects may be very high in countries that
have high labor mobility. Since this study includes only a Japanese sample,
such institutional influences could not be examined.
In our sample, only one project member out of 223 had working
experience in other automobile companies: almost all members had workedfor only one company. Further examination is needed to determine whether
this low mobility is common in Japan or specific to the Japanese auto
industry. The low labor mobility in our sample probably reduces the cost of
retaining a project member, which may generate some biases in favor of
human-based retention mechanisms. On the other hand, where labor
mobility is quite high, companies cannot help depending on standardized
mechanisms to retain knowledge even if it is systemic. Although the cost of
articulating system knowledge may be high, retaining people may be even
more costly. In that case, companies either invest in standardized retention
mechanisms or modularize and standardize a product itself to decrease theneed for context-specific system knowledge.
The third limitation is lack of project level analyses. If our interest resides
in performance of new product development, knowledge retention at the
project level needs to be considered. In particular, since system knowledge
can be stored in multiple people, knowledge retrieval may be triggered when
members with common experiences get together. Such a group-level
phenomenon was not considered in this paper.9 Once data is analyzed at
the project level, we can examine, for example, a relationship between the
generation linkage and the cross-functional integration that is been knownto exist in Japanese companies.10
9On project-level phenomenon, see Aoshima (1997).10By examining the same database at the project level, Aoshima (1996) examines the relationship
between the cross-functional integration and the cross-generation linkage, and finds a high correlation
between two. There, the cross-generation linkage is measured by the percentage of core project members
having experiences in the previous generation of projects, and the degree of common past project
experience among members. From this result it can be implied that the cross-generation linkage may be a
foundation for the cross-functional integration.
626 / Yaichi Aoshima
-
8/17/2019 1. Aoshima, y. Industrial Relations
23/24
To overcome the above limitations, future research should make
comparisons across different industries in different countries, dealing with
data at the project level.
References
Aoshima, Y. 1996. ‘‘Knowledge Transfer Across Generations: The Impact on Product Development
Performance in the Automobile Industry.’’ Ph.D. dissertation. MIT.
———. 1997. Knowledge Retention: The Impact on New Product Development Performance. Working
Paper #97-08. Institute of Business Research, Hitotsubashi University.
Allen, T., and D. G. Marquis. 1964. ‘‘Positive and Negative Biasing Sets: The Effects of Prior Experience
on Research Performance.’’ IEEE Transaction on Engineering Management 11:158–62.
Anderson, P., and M. Tushman. 1990. ‘‘Technological Discontinuities and Dominant Designs: A
Cyclical Model of Economic Change.’’ Administrative Science Quarterly 35(4):604–633.Badaracco, J. L. 1991. The Knowledge Link: How Firms Compete Through Strategic Alliances . Boston,
MA: HBS Press.
Christensen, C. M., and R. S. Rosenbloom. 1995. ‘‘Explaining the Attacker’s Advantage: Technological
Paradigms, Organizational Dynamics, and the Value Network.’’ Research Policy 24:223–57.
Clark, K. B., and C. Y. Baldwin. 1997. ‘‘Managing in an Age of Modularity.’’ Harvard Business Review
September–October: 84–93.
——— and T. Fujimoto. 1991. Product Development Performance: Strategy, Organization, and Man-
agement in the World Auto Industry. Boston, MA: Harvard Business School Press.
Cusumano, M. A. 1991. Japan’s Software Factories: A Challenge to U.S. Management. New York:
Oxford University Press.
——— and K. Nobeoka. 1998. Thinking Beyond Lean. New York: Free Press.
——— and R. W. Selby. 1995. Microsoft Secret: How the World Most Powerful Software Company
Create Technology, Shapes Markets, and Manage People. New York: Free Press.
Dougherty, D. 1992. ‘‘Interpretive Barriers to Successful Product Innovation in Large Firm.’’ Organi-
zation Science 3(2):179–202.
Fujimoto, T. 1998. ‘‘Japanese Automobile Product Development in 1990s—Capability-Building Com-
petition by Front-Loading (in Japanese).’’ Business Review 46(1):22–45.
Garud, R., and P. R. Nayyar. 1994. ‘‘Transformative Capacity: Continual Structuring by Intertemporal
Technology Transfer.’’ Strategic Management Journal 15:365–85.
Henderson, R. M., and K. B. Clark. 1990. ‘‘Architectural Innovation: The Reconfiguration of Existing
Product Technologies and the Failure of Established Firms.’’ Administrative Science Quarterly
35:9–30.
Huber, G. P. 1990. ‘‘Organizational Learning: The Contributing Processes and the Literatures.’’
Organizational Science 2(1):88–111.
Huber, G. P. 1991. ‘‘Organizational Learning: The Contributing Processes and The Literatures.’’
Organizational Science 2(1):88–111.
Imai, K., I. Nonaka and H. Takeuchi. 1995. Managing the New Product Development Process: How
Japanese Learn and Unlearn. In K. B. Clark, R. H. Hayes and C. Lorenz, (Eds.). The Uneasy
Alliance: Managing the Productivity-Technology Dilemma. Boston, MA: Harvard University
Press.
Iansiti, M. 1997. Technological Integration: Making Critical Choices in a Turbulent World. Boston,
MA: Harvard Business School Press.
Iansiti, M. 1998. Technology Integration. Boston, MA: HBS Press.
——— and K. B. Clark. 1994. ‘‘Integration and Dynamic Capability: Evidence from Product
Development in Automobiles and Mainframe Computers.’’ Industrial and Corporate Change
3(3):557–605.
Transfer of System Knowledge Across Generations / 627
-
8/17/2019 1. Aoshima, y. Industrial Relations
24/24
Krippendorf, K. 1975. ‘‘Some Principle of Information Storage and Retrieval in Society.’’ General
Systems:15–35.
Langlois, R. N., and P. L. Robertson. 1992. ‘‘Networks and Innovation in a Modular System: Lessons
from the Microcomputer and Stereo Component Industries.’’ Research Policy 21:297–313.
Leonard-Barton, D. 1992. ‘‘Core Capabilities and Core Rigidities: A Paradox in Managing New ProductDevelopment.’’ Strategic Management Journal 13(Summer):111–26.
Meyer, M. H., and J. M. Utterback. 1993. ‘‘The Product Family and the Dynamics of Core Growth.’’
Sloan Management Review 29(4):29–47.
Nakayama, T. 1997. ‘‘The Keisho of Development Technology: The Case of the Japanese Aircraft
Industry.’’ Journal of Product Innovation Management 14(5):393–405.
Nystrom, P. C., and W. H. Starbuck. 1984. ‘‘To Avoid Organizational Crises, Unlearn.’’ Organizational
Dynamics 12:53–65.
Polanyi, M. 1966. The Tacit Dimension. Gloucester, MA: Peter Smith.
Ulrich, K. 1995. ‘‘The Role of Product Architecture in the Manufacturing Firm.’’ Research Policy
24:419–40.
——— and S. Eppinger. 1994. Product Design and Development. New York: McGraw-Hill.
Uzumeri, M., and S. Sanderson. 1995. ‘‘A Framework for Model and Product Family Competition.’’Research Policy 24:583–607.
von Hippel, E. 1994. ‘‘‘‘Sticky Information’’ and the Locus of Problem Solving: Implications for
Innovation.’’ Management Science 40(4):429–39.
——— and M. J. Tyre. 1995. ‘‘How Learning by Doing is Done: Problem Identification in Novel Process
Equipment.’’ Research Policy 24:1–12.
Walsh, J. P., and G. R. Ungson. 1991. ‘‘Organizational Memory.’’ Academy of Management Review
16(1):57–91.
Wilson, T. L., and J. D. Hlavacek. 1984. ‘‘Don’t Let Good Idea Sit on the Shelf.’’ Research Management
27(3):27–34.
Zander, U., and B. Kogut. 1995. ‘‘Knowledge and the Speed of the Transfer and Imitation of Orga-
nizational Capabilities: An Empirical Test.’’ Organization Science 6(1):76–92.
628 / Yaichi Aoshima