By
Dipl.-Ing. (M.S.) Mechanical Engineering
RWTH Aachen (Germany), 1994 and
B.S. Biomedical Engineering
University of Iowa, 1986
Submitted to the System Design and Management Program in Partial Fulfillment of the Requirements for the Degree of
Master of Science in Engineering and Management at the
Massachusetts Institute of Technology
February 2002
C 2002 Hans D. Schumacher and Donald J. Mecsey. All rights reserved
The authors hereby grants to MIT permission to reproduce and to distribute publicly paper and electronic copies of this thesis document in whole or in part.
Signatures of Authors
Certified by
Accepted by
Accepted by
MASSACHUSETTS INSTITUTE
OF TECHNOLOGY
JUL 1 8
LIBRARIES
/
Hans D. Schumacher and jonad J. Me
/1/ tem Desi and Maiageent Prog 2
1 O 7/~
February 2002
O-
Thesis Supervisor
Execu e Director, Engineering Systems Learning Center, MIT and Senior Research Scientist, Sloan School of Management, MIT
Steven D. Eppinger
Co-Director, LFM/SDM
K'G ML Professor of Manageient Science and Engineering Systems
Paul A. Lagace
Co-Director, LFM/SDM
Professor of Aeronautics & Astronautics and Engineering Systems
1
4 ell

2

BY
Hans D. Schumacher
Dipl.-Ing. (M.S.) Mechanical Engineering
RWTH Aachen (Germany), 1994
Donald J. Mecsey
B.S. Biomedical Engineering
University of Iowa, 1986
Submitted to the System Design and Management Program in Partial Fulfillment of the Requirements for the Degree of
Master of Science in Engineering and Management
AT THE
Massachusetts Institute of Technology
FEBRUARY 2002
ABSTRACT
Key product development decisions at the onset and during the product development process shape the product's subsequent value stream and, ultimately, the firms' competitive edge. Even though decisions can be key differentiators between success and failure, literature research and interview research suggests that decision-making is a highly variable process with many unintended consequences. Our focus here is on product development decisions about supplier sourcing and downstream execution, which are particularly important areas of a firm's decision-making. While the topic of decision-making is discussed extensively in the literature, decision process interdependencies within organizational hierarchies in product development are largely unexplored.
In particular, product success correlations between program enterprise senior management and front line staff decision rules require in depth studies, which this thesis addresses.
Ultimately, it is corporate, functional and personal decision rule drivers that impact actual decisionmaking. These sets of decision rules may or may not be aligned between enterprise and frontline levels - a key issue investigated here. We find that positive product performance outcomes can happen even when decision rules are not aligned. We also find that differing rule sets between both enterprise and front line rules impact product performance. While enterprise sourcing decisions that value supplier capability can have a positive effect on product performance, this product performance improvement can be undermined by fire fighting on the front line level, which tends to quickly degrade the OEM-Supplier relationship.
Although not the initial focus of the research, the analysis also surfaced unexpected implications for career development, skill building, reward systems, and even recruitment of engineering professionals. Many of these human resource factors ended up playing important reinforcing or undercutting roles in the product sourcing decision-making process - a finding with important organizational policy implications. In addition, it was substantiated that intangible variables such as employee motivation (i.e. emphasis on value engineering versus project management) within the
OEM-Supplier product development system impact tangible product performance variables, with substantial time lags, but enable long-term competitiveness.
Thesis Supervisor: Dr. Joel Cutcher-Gershenfeld
Title: MIT Senior Research Scientist
3

4

TABLE OF CONTENTS
LIST OF FIGURES ......................................................
1
7
1 .1
Objectives and Discussion................................................................................................ 9
In tro d u c tio n ................................................................................................................... 9
12 1.2 Literature Search .......................................................................................................
1.3 Research Fram ework ................................................................................................ 19
1.4 Objective of the Research.......................................................................................... 24
1.4.1 Hypotheses ...................................................................................................... 26
2 Research Design and Survey Descriptive Statistics........................................................ 28
2 .1 In tro d u c tio n ................................................................................................................. 2 8
2.2 Data Collection ........................................................................................................... 29
2.3 Decision Rule Identification....................................................................................... 30
2.3.1 Core Criteria ....................................................................................................... 30
2.3.2 Decision Rule Categories .................................................................................. 32
2.3.2.1 Product Complexity .................................................................................... 33
2.3.2.2 Internal (OEM) Capability ........................................................................... 35
2.3.2.3 Supplier Capability..................................................................................... 38
2.3.2.4 Supplier Proximity....................................................................................... 39
2.3.2.5 Customer Proxim ity .................................................................................... 40
2.3.2.6 Com petition ................................................................................................ 40
2.3.2.7
2.3.2.8
2.3.3
Product Performance................................................................................ 41
Decision Rule Category Overview .............................................................. 41
Decision Rule Drivers ....................................................................................... 42
2.4 Quantitative Research ............................................................................................. 43
2.4.1 Survey Development ......................................................................................... 43
2.4.2 Data Analysis..................................................................................................... 45
2.4.3 Descriptive Statistics.......................................................................................... 46
2.4.3.1 Demographics ........................................................................................... 46
2.4.3.2 Com ponent Outsourcing ............................................................................ 46
2.4.3.3 Decision Rule Priority (mean, standard deviation) ..................................... 47
2.4.3.4 Decision Rule Drivers ................................................................................ 48
2.4.4 Alignment Analysis ........................................................................................... 49
2.4.5 Reliability Analysis.............................................................................................. 62
2.4.6 Product Outcome Correlations.......................................................................... 63
3 Qualitative Data and Systems Dynamics Model.............................................................. 67
3.1.1 Research Intent .................................................................................................. 67
3.1.2 Research Preparation and Planning .................................................................. 67
3.1.3 Pre-Interview Discussions ................................................................................ 69
3.1.4 Boundary Objects .............................................................................................. 69
3.1.5 Identification of Key Product Development Variables........................................ 72
3.1.6 Systems Dynamics Data Gathering Procedures ..............................................
3.1.6.1
73
Loop Development Process........................................................................ 74
3.2
3.1.6.2 Causal Relationships................................................................................... 74
Systems Dynam ics Modeling ..................................................................................... 77
3.2.1 Background ...................................................................................................... 77
3.2.2
3.2.3
Problem Identification .........................................................................................
Cause and Effect Relationships .........................................................................
78
79
3.2.3.1 Tangible/Intangible Relationship ................................................................. 79
3.2.3.2 Inter-Com pany Relationship ....................................................................... 80
5

3.2.3.1 Tangible/Intangible Relationship.................................................................
3.2.3.2 Inter-Com pany Relationship .......................................................................
79
80
3.2.3.3 Inter-Functional Relationship ..................................................................... 80
3.2.3.4 Dynam ic Relationship ................................................................................
81
3.2.3.5 Evolutionary................................................................................................
3.2.4 Construction of Sim ulation M odel ....................................................................
3.2.4.1
82
83
View 1: Supplier Capability / Number of Programs / Product Outcome .........
85
4
3.2.4.4 View 4: Internal Technical Knowledge ....................................................... 88
3.2.4.5 View 5: Product Attribute Level / O EM Com petition ................................... 89
3.2.4.6 View 6: Data Input and G raphical O utput ................................................... 90
3.2.5 M odel Correlation .............................................................................................. 92
3.2.6 Lim itations of the M odel ..................................................................................... 99
Hypothesis Testing .......................................................................................................... 101
4.1 Hypothesis 1 Testing ................................................................................................ 101
4.2 Hypothesis 2 Testing ................................................................................................ 106
4.3
3.2.4.2 View 2: Internal Capability / Resource Burden & Supplier Resource Burden 86
3.2.4.3 View 3: Supplier Proxim ity ......................................................................... 87
Hypothesis 3 Testing ................................................................................................ 108
4.4 Hypothesis 4 Testing ................................................................................................ 112
4.5 Hypothesis 5 Testing ................................................................................................ 115
5 Unexpected Findings and Next Steps .............................................................................. 122
5.1 M anagem ent Vision & Leadership ............................................................................ 123
5.2 New Hire Q uality....................................................................................................... 126
5.3 Fire Fighting.............................................................................................................. 128
5.4 Value Engineering .................................................................................................... 130
5.5 System Engineering Efficiency ................................................................................. 133
5.6 Com m odity ............................................................................................................... 136
5.7 Supplier Capability.................................................................................................... 140
6 Conclusions and Insights................................................................................................. 143
APPENDIX ............................................................................................................................. 148
6

Figure 1 - Decision-Making Tree .............................................................................. 19
Figure 2 - Product Development Funnel .................................................................... 20
Figure 3 - Decisions and Organizational Hierarchy ....................................................
21
22
Figure 4 - Decision Rule Drivers...............................................................................
Figure 5 - Influence of Objectives ............................................................................. 23
Figure 6 - Corporate Decision-Making Framework .................................................... 25
Figure 7 - Component Functional Interfaces.............................................................
34
Figure 8 - Knowledge Dependency Flow ....................................................................
36
Figure 9 - Outsourcing vs. Architecture ......................................................................
37
Figure 10 - Decision Rule Categories ........................................................................
42
Figure 11 - Survey Demographics .............................................................................
46
Figure 12 - Component Outsourcing ........................................................................ 47
Figure 13 - Engineering Responsibilities ...................................................................
47
Figure 14 - Decision Rule Priorities .......................................................................... 48
Figure 15 - Decision Rule Drivers............................................................................. 49
Figure 16 - Alignment Segmentation ........................................................................ 50
Figure 17 - Shareholder Value Misalignment............................................................. 51
Figure 18 - Organization Infrastructure Alignment Gap ............................................. 52
Figure 19 - Quality of Competitive Product Alignment Gap........................................ 53
Figure 20 - Number and Type of Functional Interface Alignment Gap........................54
Figure 21 - Number of Programs Alignment Gap ...................................................... 54
Figure 22 - OEM's Knowledge and Expertise Misalignment ...................................... 55
Figure 23 - WCR, DVP&R, FMEA Adherence Misalignment ..................................... 56
Figure 24 - Supplier Manufacturing Assets Alignment Gap ....................................... 57
Figure 25 - Supplier's Component Knowledge Misalignment .................................... 57
Figure 26 - Number of Other OEM's Supplier Supplies Alignment Gap ..................... 58
Figure 27 - Level of Supplier Responsibility Alignment Gap ...................................... 58
Figure 28 - Part Cost and Timing vs. Objective Alignment Gap................................. 59
Figure 29 - Number of Competitive Suppliers Misalignment ..................................... 59
Figure 30 - Supplier Technical Assistance Involvement Alignment Gap.................... 60
Figure 31 - Decision Rule Driver Importance Rankings ..............................................
60
Figure 32 - Decision Rule Importance Rankings ...................................................... 61
Figure 33 - Decision Rule Category Reliability (Initial)................................................62
Figure 34 - Decision Rule Driver Category Reliability (Initial) .....................................
62
Figure 35 Decision Rule Category Reliability (Final) ............................................... 63
Figure 36 - Decision Rule Drier Category Reliability (Final)........................................63
Figure 37 - Decision Rule Driver to Product Outcome Correlation ............................ 64
Figure 38 - Decision Rule to Product Outcome Correlation ....................................... 66
Figure 39 - Product Performance Graph As Boundary Object ................................... 70
Figure 40 - R/1 000 Graph As Boundary Object ........................................................ 71
Figure 41 - Dynamic Causal Loop Structure ............................................................. 75
Figure 42 - Tangible/Intangible Relationship Loop .................................................... 79

Figure 62
Figure 63
Figure 64
Figure 65
Figure 66
Figure 67
Figure 68
Figure 69
Figure 70
Figure 71
Figure 72
Figure 73
Figure 74
Figure 75
Figure 76
Figure 77
Figure 78
Figure 79
Figure 80
Figure 81
Figure 82
Figure 83
Figure 84
Figure 85
Figure 86
Figure 87
Figure 43 -
Figure 44 -
Figure 45
Figure 46
Figure 47
Figure 48
Figure 49
Figure 50
Figure 51
Figure 52
Figure 53-
Figure 54-
Figure 55*
Figure 56
Figure 57
Figure 58
Figure 59
Figure 60
Figure 61
Inter-Com pany Relationship Loop ........................................................... 80
Inter-Functional Relationship Loop ......................................................... 81
Dynam ic Relationship Loop .................................................................... 81
Evolutionary Relationship Loop ............................................................... 82
M odel View 1 .......................................................................................... 85
M odel View 2.......................................................................................... 86
M odel View 3.......................................................................................... 87
M odel View 4.......................................................................................... 88
M odel View 5.......................................................................................... 89
M odel View 6................................................................................. ............ 91
M odel Correlation to Com ponent Level 1 ............................................... 94
M odel Correlation to Com ponent Level 2 ................................................ 95
M odel Correlation to Com ponent Level 3 ................................................ 96
Base M odel O utput.................................................................................. 98
M isalignm ent of Supplier Capability Priority ..............................................
102
M isalignm ent of Com petition Priority .........................................................
102
Hypothesis 1 Test Results.........................................................................103
Product O utcom e vs. M isalignment...........................................................104
Decision Rule Category to Decision Rule Driver Correlation.....................109
System s Dynam ics Next Steps .................................................................
111
Decision Rule Driver Influence ..................................................................
113
Product O utcom e vs. O rganizational Level Test 1 ....................................
116
Product O utcom e vs. Organizational Level Test 2 ....................................
117
Product O utcom e vs. O rganization Level Test 3 .......................................
118
Product O utcom e vs. Upfront Planning .....................................................
120
Product O utcom e vs. Knowledge of Supplier Ability ..................................
120
Loop Notation ............................................................................................
123
M anagem ent Vision/Leadership Loop .......................................................
123
Product Outcome vs. Management Leadership and Vision .......................
125
New Hire Q uality Loop ..............................................................................
126
Product O utcom e vs. Motivation to Stay ...................................................
127
Fire Fighting Loop .....................................................................................
128
Product O utcom e vs. Upfront Planning Rewards ......................................
129
Value Engineering Loop ............................................................................
130
Product O utcom e vs. Program s to Do .......................................................
131
Product O utcom e vs. Program M anagem ent W ork ...................................
132
System Engineering Efficiency Loop .........................................................
133
Product O utcom e vs. Cascade Efficiency .................................................
135
Com m odity Loop .......................................................................................
136
Supplier Capability vs. Pressure to Reduce Cost ......................................
137
Internal Capability vs. Pressure to Reduce Cost .......................................
137
Product O utcom e vs. Pressure to Reduce Cost ........................................
138
Cost Reduction Em phasis Switch..............................................................139
Supplier Capability Loop ...........................................................................
140
Product O utcom e vs. Shadow Engineering ...............................................
141

1
All competitive advantage is temporary. This principle has held true throughout history. The
Greeks, Romans, and the Ottomans reigned with substantial power and influence at one point in time. Today, one might consider the Western civilization as the most influential power in the world. While Ford stood out as the leader in automotive production early in the past century,
General Motors was considered the dominant automotive firm in the 1950's and 1960's. In the
1980's, Japanese firms led the industry due their progressive manufacturing initiatives.
Disruptions in competitive advantage occur in many dimensions. And the authors of this thesis would argue that those disruptions are enabled by the decisions and decision rules made along the way.
Product decisions before and during the product development process shape the product's subsequent value stream and, ultimately, the firms' competitive edge. Even though decisions can be key differentiators between success and failure, literature research and interview research suggests that decision-making is a highly variable process with many unintended consequences.
While the topic of decision-making is discussed extensively in literature, decision process interdependencies within organizational hierarchies in automotive product development efforts are largely unexplored. The specific area of research concentrating on the interrelations and product success correlations between enterprise level senior management and front line staff decisions and decision rules, will be addressed in this thesis. For purposes of this research we define enterprise as the executive management level of a product development organization within a large corporation. This thesis provides an initial test of the following five hypotheses:
HYPOTHESIS 1: Misalignment of decision rules impedes achievement of corporate goals
HYPOTHESIS 2: Decision rules for a particular PD team vary over time
HYPOTHESIS 3: Corporate, functional and personal goals directly shape the decision rules applied teams during key product development decisions.
9

HYPOTHESIS 4: Decision rules vary by the level within the organization, with enterprise level decision rules heavily influenced by corporate goals and front line level decisions heavily influenced by personal goals
HYPOTHESIS 5: Enterprise decision rules at pivotal PD events have a greater impact (on product outcome) than front line engineering decisions
In order to better understand decision-making processes in the corporate environment, a practical framework on how to think about product development decision-making was developed. This framework, initially developed based on interviews within the corporation, intends to map product development decision-making in light of organizational hierarchies and corporate, functional, and personal boundaries. The theoretical decision model developed in this thesis attempts to contrast the upper level management decision-making in organizations concerned with strategic goals and the lower level engineering staff of an organization concerned with product development execution of such strategies. This generic framework is then applied to the area of automotive OEM-Supplier relationships via independent research approaches within an engineering organization. Our focus here is on early product development decisions regarding supplier sourcing and effects on downstream engineering execution, which are particularly important areas of a firm product development process.
Key variable relationships are quantified by means of an original survey of 33 executives and lead engineers, involved in sourcing decisions and product performance consequences on nine selected components, along with statistical data analysis of the results. The supplier sourcing and subsequent product development decision rule categories (product complexity, internal capability, supplier capability, supplier proximity, customer knowledge, competition, and product performance) were decomposed into sub-elements. These sub-elements were based on technical features, product architecture, performance tuning characteristics, manufacturing assets and data exchange which are critical, but not necessarily unique, to the specific product and organization analyzed (automotive engine). This enabled the development of a survey eliciting the importance of pragmatic decision rules. Statistical survey data analysis yielded quantitative decision rule category relationships given intervening parameters, such as corporate, functional, and personal decision rule drivers.
10

The qualitative portion of the research commenced with developing interview guides for both interview and focus group data gathering. P. Carlile's' 2 work in boundary object theory and systems dynamics reference modes presented by Lyneis and Warmkessel
3 and J. Sterman
4 laid the foundations for eliciting critical information from research participants. Traditional "voice of the customer" tools 5 and processes were then applied to the interview and focus group transcriptions and evaluations. Qualitative data on variable relationships were derived from in depth interview and focus group research from the same population. Here, simple relationships, identified in interviews, between key variables were developed, ultimately producing a complex web of relationships. This web contains several surprising and unique reinforcing loops that can cause instability in the system. Thus, recommendations were developed to prevent such instability.
Further, a system dynamics model was developed based on the aforementioned organization and supplier relationships. The systems dynamics model was developed using real world data from several engine component development case studies, providing an opportunity to understand the interrelationships between the OEM-Supplier product development system.
Ultimately, relationships between enterprise and front line decision objectives are better understood through this triangulation of research methods, which increases confidence in the validity and reliability of the findings.
After developing a decision process, the authors contend that there is misalignment between those organizationally distant groups, namely senior leaders and front line staff. Data research informed by corporate interviews, focus groups and statistical survey analysis suggests that misalignment is largely influenced by differences in corporate, functional, and personal decision drivers across organizational hierarchies.
' Carlile, Paul. Organizational Behavior and Processes. Class Notes. Cambridge, MA: MIT, January 6, 2000
2
Carlile, P. A Pragmatic View of Knowledge and Boundaries: Boundary Objects in New Product Development.
Working Paper. Cambridge, MA: MIT, August 15, 2000
3 Lyneis, Jim and Warmkessel, Joyce. System and Project Management. Class Notes. Cambridge, MA: MIT,
September 10, 2000.
4 Sterman, John D., Business Dynamics Systems Thinking and Modeling for a Complex World, Irwin McGraw-
Hill, 2000.
5 Brodie, Christina Heperner and Burchill, Gary. Voices into Choices Acting on the Voice of the Customer, Joiner
Associates Inc., 1997.
11

While researching the issue of component outsourcing in particular, this study expands on C.
Fine and D. Whitney's 6 capability dependency and outsourcing model that focuses on enterprise level outsourcing decision objectives. This study looks to expand the work of Fine and Whitney work by highlighting success and failure relationships between enterprise level component outsourcing and front line product execution decision objectives for an automotive product development activity.
While interrelating simple and known relations between key variables, the research attempts to honor the core principle of systems engineering in its dealing with the system as a whole.
Furthermore this research finds that decision rules correlate well to product outcome metrics.
Both enterprise and front line decision rules impact product performance successfully given differing rule sets between these organizational levels. While enterprise sourcing decisions value supplier capability positively, fire fighting can cause a skewed vision of the OEM-Supplier relationship within engineering. This results in lost opportunities adversely impacting OEM capability and decision-making. In this research we will provide evidence on how these and other key variables, such as cost reduction initiatives and lack of upfront planning, can initiate downward product performance spirals that may take years to overcome.
Although not the initial focus of the research, the analysis also surfaced unexpected implications for career development, skill building, reward systems, and even recruitment of engineering professionals. Many of these human resource factors ended up playing important reinforcing or undercutting roles in the product sourcing decision-making process - a finding with important organizational policy implications. In addition, it was substantiated that intangible variables such as employee motivation (i.e. emphasis on value engineering versus project management) within the OEM-Supplier product development system impact tangible outcome variables, such as product performance with substantial time lags, but enable long-term competitiveness.
Decision-making represents a very crucial skill set that all individuals and organizations must possess in order to achieve goals and objectives. Given the organizations' stated mission statement or corporate vision, it will ideally attempt to realize its vision by generating both a
6 Fine, C., Whitney, D. (1996), "Is the Make-Buy Decision Process a Core Competence", MIT Center for
Technology, Policy, and Industrial Development.
12

strategy and an execution plan. Thus, decisions made in both strategy and execution will have a strong impact in realizing the vision.
Literature provides many examples where decisions in either strategy or execution led to consequences for organizations, in some cases unintended and in others intended. Specific to product development organizations, Crawley
7 argues that product architecture actually represents the product strategy. Here, product architecture can be thought of as the product's strategic design intent ranging from the organization executing the product design to the manufacturing strategy developed to produce the product. Furthermore, product architecture includes the supply chain architecture mapping the product value stream from raw materials to the product beneficiary and beyond, and the market strategy enabling product sales and revenue growth. As evidenced by R. Henderson and K. Clark
8 (product architecture drives organizational architecture), C. Christensen
9
(architectural innovations drive market discontinuities), and C. Fine' (system architecture drives supply chain design), dominating firms failed and lost competitive advantage once the impact of the product architecture on downstream efforts was no longer sufficiently understood. Thus, decisions made during the strategic design deriving the product architecture have success altering consequences. Similar impact of decisions can be identified on the product development execution side. For instance, a risky decision to disregard design information and seal failures during verification testing ultimately led to the catastrophic failure of Challenger seventy-four seconds after launch in
January of 1986. Therefore, one can see how only a single product execution decision can lead to adverse outcome.
Above evidence confirms the importance of product development decision-making. We will demonstrate for an automotive organization that in fact both strategic and product execution
7 Crawley, Edward. 16.882 System Architecture. Class Notes. Cambridge, MA: MIT, September 10, 2000.
8
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, pp. 9-30
9
Christensen, C. M. (1995). Explaining the attacker's advantage: technological paradigms, organizational dynamics, and the value network, Research Policy 24, pp. 233-257.
10 Fine, Charles H. (1998), Clock Speed: Winning Industry Control in the Age of Temporary Advantage, Perseus
Books, Reading, MA.
" US Congress Report 1016 Investigation of the Challenger Accident
13

decision-making is crucial for product quality. However, as this paper will illustrate, this finding is dependent on which set of decision rules were applied.
Interview and literature research indicates that decision-making processes are highly variable and that corporations have difficulties arriving and standing by decisions. Quotes from interview research within several corporate activities, such as human resources, product planning, purchasing and others, at an automotive manufacturer suggest some of the difficulties real world decisions are subjected to. They are follows:
Quote 1:
"We have difficulty in representing 'intangible benefits' with long-term consequences during decision-making events. The mindset is cost driven and short-term."
This is not too dissimilar from the quote by Albert Einstein
3
: "Not everything that counts can be counted and not everything that can be counted, counts". The suggestion is that each decision process is dependant on its particular circumstances and that both intangible and tangibles need representation in its conclusion. Unfortunately, we must realize that benefits from some of the most important factors, such as the intangibles, often cannot be quantified. Similarly, we tend to only understand those things that we are measuring: Your organization will become what is measured" (John Hauser
3
); "Tell me how you will measure me and I tell you how I will behave" (Eli Goldratt
3
). We will further develop the implications of tangible and intangible variables later in this paper.
Quote 2:
"Decision-making events require many meetings, because there are many stakeholders."
This reference indicates that decision rules, and ultimately the decision, change based on the perspectives represented. Interviewees indicated the power of presentation has a significant impact on the decision made. This will become specifically important for the results in our study, as well demonstrate how stakeholder decision-making is not only dependent on corporate goals, but also on functional and even personal objectives.
3 Lyneis, Jim and Warmkessel, Joyce. System and Project Management. Class Notes. Cambridge, MA: MIT,
September 10, 2000.
14

Quote 3:
"There are many decision tools, but we don't really use them."
The observation is consistent with the authors' product development experience. While CAE tools and testing results are used to influence product decisions, generic decision tools addressing the trade-off of conflicting decision objectives are rarely applied. Clemen
12 indicates that the value of decision analysis (DA) tools is difficult to demonstrate, as it is not easy to measure the value of the chosen course of action relative to paths not taken. However, he indicates intangible benefits to DA in general which include facilitating discussions among stakeholders with different preferences, providing a common language for discussing elements of a decision problem, focusing on specific disagreements and helping to build consensus, which in turn speeds implementation. Such contributions can improve the overall functioning of the organization, thereby contributing to the bottom line. Interestingly, Yassine
1 3 indicates that no body of literature exists that shows unequivocally whether the use of DA techniques actually helps individuals to make better decisions. As part of this research, we will evaluate both the human element (in the form of strong leadership) and the brick and mortar element (cascade efficiency throughout an organization) and how they both play a substantial role in transforming decision rules into positive product actions. Thus, we contend that decision tools alone are not sufficient for product development decision-making.
Quote 4:
"Why can't I get information that exists to make this decision?"
The answer to this age old senior management question, as described to us by many interviewees, could be because: 1) people are invested in their knowledge and they are careful in volunteering it, or 2) systems are locally optimized and information formats useful to one part of the organization cannot easily be transferred to other parts of the system, or 3) knowledge exists in people, it is tacit, thus not easily detectable, or simply 4) because 'George' is on vacation. We will show that product development decision rules vary over time and with that the key information required for decision-making changes. Thus locally optimized systems, which are a function of people and knowledge transfer and databases, are not efficient.
1
Clemen, Robert T., Kwit, Robert C. (2000), The Value of Decision Analysis at Eastman Kodak Company, 1990-
1999, Joint Research Paper between Duke University and Eastman Kodak Company.
" Yassine, Ali and Chelst, Kenneth. Opportunities for Decision Analysis in Engineering and Manufacturing
Management: An Overview, MIT Research Paper.
15

Without trying to embark on the impossible task of citing and describing the massive amount of published literature on decision-making, referring to some scholars and their work maybe helpful to understand difficulties with decision-making in general.
Scholars in the field of decision sciences suggest many reasons for why decision-making is difficult. They address some of issues described in the quotes listed above. In 1772, Benjamin
Franklin in a letter titled "Morale or Prudential Algebra"
14 made the following statement: "When those difficult cases occur, they are difficult, chiefly because while we have them under consideration, all the reasons pro and con are not present to the mind at the same time; but sometimes one set present themselves, and at other times another, the first being out of sight.
Hence the various purposes or inclinations alternatively prevail, and the uncertainty that perplexes us." Simon, who developed the concept of "bounded rationality", emphasizes the cognitive limitations of decision-makers, limitations of both knowledge and computational capacity. Miller 16 highlights limitations in the human span of attention (i.e. recognizing number of objects at a glance), of absolute judgment (i.e. distinguishing between categories), and of immediate memory (i.e. number of items that can be recalled). Thus Franklin, Simon, and Miller each addressed the limitations of human capacities on decision-making. Our research further verifies that for a product development organization, the relationship mapping that we developed clearly indicated that the organizational dynamics represented relationships so complex and large in number that it would be infeasible for any one or two individuals to understand them well enough to be able to make efficient decisions.
Another large body of decision-making research is the area of Decision Analysis (Raiffa
17
).
Within the context of decision analysis, Hammond, Keeney, and Raiffa
18 describe what they call the "even-swaps method" - thinking about the value of one objective in terms of another. The thought here is that decision objectives have relative importance and alternatives have different
14 Franklin, Benjamin (London Sep. 19th, 1772), A Letter Titled "Morale or Prudential Algebra", published in
Harvard Business Review (March-April 1998), Reprint 98206.
15 Simon, Herbert A. Models of Bounded Rationality, Volume 3, The MIT Press, Cambridge, MA.
16 Miller, G.A, "The magic number seven, plus or minus two: Some limits on our capacity for processing information," An Essay in the psychology of communication, Basic Books, 1967.
17 Raiffa, H., Decision Analysis. Addison-Wesley, Reading, MA, 1968.
18 Hammond, John S., Keeney Ralph L., and Raiffa Howard, Even Swaps: A Rational Method for Making Tradeoffs, Harvard Business Review (March-April 1998), Reprint 98206.
16

utilities. The research contends that if alternatives are equally good in one objective, this objective can be deleted from decision. Clemen'
9 indicates that a good decision making process is a process where "if I still know what I exactly knew back then (when I made the decision), I still would make the same decision". In "The Effective Decision", Drucker 2
0 suggests the following pre-described steps for efficient decision-making. However, given the complex cultural, political, and strategic dimensions influencing product development decisions, the methodology seems impractical to undertake in the corporate environment. A more realistic perspective presented by Hammond, Keeney, and Raiffa
2 1 , warns of various traps that decision-makers are exposed to. We will show that the decision maker must understand more than just the process
by which to weigh competing variables and objectives. The relationship mapping performed in our research indicates that it is just as important to have an understanding of the balancing and reinforcing network loops that define the decision-making environment. Various loops and their associated behavior will be presented later in greater detail.
Literature on the automotive industry tends to be centered on the decision-making culture differences between Japanese and American OEM's 2 2
'
2 3
.
In the Toyota model, set based concurrent engineering and the ability to delay decisions until later in the PD process govern.
This may provide advantages as product development activities circumvent upfront ambiguities in an environment that slowly converges to the final product. US automotive manufactures tend to converge early to an end solution only to have that solution refined as product development continues. This approach causes constant tuning of one good idea rather than the convergence of sets of ideas. The difference product development approaches at US OEM's and Toyota is significant for decision-making. Our research shows that product development decision rules vary over time and thus the Toyota approach may be a better competitive approach, because it
19 Clemen, Robert T., Making Hard decisions An Introduction to Decision Analysis, Duxbury Press, 1996.
20
Drucker, Peter F., The Effective Decision, Harvard Business Review (January-February 1967), Reprint 67105.
21
Hammond, John S., Keeney Ralph L., and Raiffa Howard, The Hidden Traps in Decision Making, Harvard
Business Review (September-October 1998), Reprint 98505.
22
Sobek, Durward K., Ward, Allen C., Liker, Jeffrey K., Toyota's principles of set based concurrent engineering,
MIT Sloan Management Review (Winter 1999, Vol. 40, Number 2), Reprint 4025.
23 Ward, Allen C., Liker, Jeffrey K., Cristiano, John J., Sobek, Durward K., The second Toyota paradox delaying decisions can make better cars faster, MIT Sloan Management Review (Spring 1995, Vol. 36, Number 3), Reprint
3634.
17

allows for decision space and reaction to changing consumer wants and economic developments late in the product development effort.
From above quotes and literature references, it becomes clear that issues surrounding uncertainty, timeliness of decisions, multiple objective trade-offs, stakeholder views, and complex system interdependencies make decision-making a highly unpredictable and variable process with unforeseen consequences. Decision-making becomes an extremely complicated task as information overload makes it difficult to decipher key information under ever-increasing budget and time constraints. As described by Apostolakis
2 4 , decision-making depends on variables, such as outcome probabilities, outcome consequences, and a person's utility towards risk, none of which are easily controlled or measured.
Ultimately, decisions are reached by the application of decision rules. And decision rules are informed by corporate, functional, and personal goals or objectives. Forrester
25
, Hines and
House 26 similarly equate decision rules in terms of policies or procedures that people actually use to make a series of decisions. Yet another interesting writing in the field of decision-making comes from Hines and House 27 who equate organizational evolution to biological evolution.
Hines and House contend that organizational policies correspond to biological genes; policy innovation corresponds to genetic mutation; and organizational learning corresponds to genetic recombination. Policies, like genes, are a fulcrum on which evolution can operate. If policies or decision rules evolve, so will the company. Thus, consistent with research from Forrester and
Hines, and House, organizational evolution assumes decision rule evolution. Thus, the study of decision rules as applied to an organization's pivotal decision-making events, is key not only to understanding how the organization operates, but also to identifying rules that, when adhered to, will effect positive change. Given that decision rules are applied during strategy and product execution events, the question for product development organizations becomes whether decision rule success patterns exist and can be identified so that product performance can be enhanced.
24
Apostolakis, George. Engineering Risk-Benefit Analysis. Class Notes. Cambridge, MA: MIT, February 7, 2000.
25
Forrester, Jay W. 1961. Industrial Dynamics. Portland, OR: Productivity Press.
26 Hines, Jim and House, Jody, Policy Evolution within an Organization, MIT Research Paper.
2 7 Hines, Jim and House, Jody, Harnessing Evolution For Organizational Management, MIT Research Paper
18

All product development teams encounter decisions that involve everything from routine tradeoffs to the career-defining actions. For the most part, corporate decisions are based on data that tends to be limited by the manner in which the problem was framed, the amount of time available to gather the data, the knowledge and experience of the team assigned to collect the data, and the effectiveness of the risk analysis process (see figure below). In addition, once the decision is made, success of the solution is dependant upon the changes inherent in the business climate and the ability of the team to execute the decision.
Figure 1 - Decision-Making Tree
28
No
Specify Objectives
(performance, quality, profit, etc.)
Frame Decision
(team members, decision makers, stakeholders, economic state, etc.)
Establish Alternatives
(choices, resources, timeframe. etc.)
Risk Analysis
(uncertainties/probabilities, costs, benefits. etc.)
No
An
Alterna
Stil
Reasoi
Yes
Apply Decision Rules
(constraints, goals, incentives, etc.)
Make Decision select best alternative
Implement/Execute
Chosen Alternative
__
One might ask then "is the outcome a result of the strategy set forth in the decision making, the execution of the chosen direction, the intangible external factors, or some combination of all of these?" We can assume that the latter is the correct explanation, but how can we test for this?
28
Unless noted, all Figures are original works developed jointly by both thesis authors.
19

This research attempts to do just that by examining the decisions, decision rules engaged, and the net effect of both as encountered in an automotive product development firm.
Decision processes in automotive product development can be divided into two segments, strategy and product execution. On the same product program, these general types of decisions are separated by both time and by organizational hierarchy. While strategic decisions are made upstream in a product program by senior level management, lower level management and lead engineers make the downstream product execution verdicts. The separation of time and organizational level also leads to differences in the decision rules, those factors used to weigh various alternatives, employed. Utilizing the product development process framework as expressed by Ulrich and Eppinger
9
, enterprise pivotal decisions are predominantly made during the product planning and concept development stages of the process. Front level engineering decision-making occurs downstream during system and detail design, as well as throughout testing and refinement phases (see Figure 2).
Figure 2 - Product Development Funnel
System -Level
Design
D tail
Design
Testing and
Refinement
Enterprise Level Decisions Front Line Engineering Decisions
Enterprise decisions include all PD pivotal events that impact the product strategic design. Here, a product's strategic design is defined by parameters such as quality, cost, weight and functional objectives, product development/manufacturing/component supply chain strategy and its time to
29
Ulrich K.T. and S.D. Eppinger. Product Design and Development, McGraw-Hill, New York, 1995 (1st edition) and 2000 (2nd edition).
20

market and volume requirements. Given the product strategic design, front line engineering activities make design and development decisions (see Figure 3).
Figure 3 - Decisions and Organizational Hierarchy
0
0
C
N ecisions
Decision Rules
Enterprise
Strategy
-------------------
_ _ _ecisions
Decision Rules
Front Line Engineering
Execution
Decision rules set the constraints and objectives for the decision to be made. At the enterprise level, decisions might include the outsourcing of a specific component or the selection of one of many available suppliers for a particular component. In this instance, enterprise level decision rules may be composed of elements weighing the corporation's internal capabilities to produce the component, the supplier's knowledge of leading edge technology, or the competitive advantage of holding manufacturing in-house vs. outside. The enterprise level team may choose to outsource a component to the most technologically advanced supplier rather than maintaining capability in-house and risk becoming non-competitive. At the front line level, one can think of decision rules as the factors that weigh product feature and development trade-offs.
For instance, a shock absorber team may need to trade-off functional attributes such as noise, vibration, dampening characteristics, friction, and weight versus variable cost and investment implications. A decision rule might be that customer satisfaction in ride and handling as a function of dampening characteristics and friction are most important. Thus, among available alternatives, the product execution team will select the design with the most optimized vehicle dynamics performance.
21

As described above, decision rules are a function of time and organizational level. That is, they routinely change during the course of the product development cycle, due to evolution of the product from prototype to production ready, and based on which team, enterprise or front line, is responsible for making the decision. The authors contend that decision rules are driven by three objectives, corporate, functional and personal (see Figure 4). Answering three simple questions can identify these objectives: What's in it for the corporation? What's in it for my
department? And What's in it for me? Examples of each of these include:
Corporate Objectives:
" Corporate mission or vision
* Shareholder value
" Customer satisfaction
" Employee satisfaction
* Community obligation
Functional Objectives:
" Departmental goals
" Supply chain management
" Organizational structure
* Local processes
* Culture/tradition
Personal Objectives:
" Merit rewards
* Experience
.
Work-life balance
Figure 4 - Decision Rule Drivers
...............
Rules change over time
Weighting of influences vary per org. level
22

Corporate objectives are cascaded from the highest level of the organization in the form of a corporate mission statement, directive or list of values. The authors contend that as these objectives are cascaded downward through the organization, it could be assumed that these objectives are more easily understood, and therefore adhered to, at the top of the organization, than at the bottom levels. This might explain the American slang phrase 'flavor of the month'.
Although the corporate mission statement or key principles may be both admirable and achievable, inefficiencies in cascading these goals prevents the lowest levels of the organization from truly understanding and adopting them. Functional objectives are naturally unique to the various levels of the organization because they are based on local product development deliverables and budget. These objectives tend to be well understood as they are most often tied to some year-end performance metric. Personal objectives, such as better pay or a better position within the organization, on the other hand are not unique to any one particular level within the organization. However, the authors contend that since enterprise level managers typically have their merit pay and bonuses tied to higher-level corporate objectives, there is less of a tendency for those at the enterprise level to make decisions based on personal considerations. Likewise, it was assumed by the authors that cascade inefficiency causes dilution of corporate objectives so that by the time these objectives make there way down to the front line engineers, they are not heavy drivers in decision making processes. Instead, front line level employees are more likely to be motivated by personal rewards, opportunities for advancement and avoidance of job induced stress (see Figure 5).
Figure 5 - Influence of Objectives
Enterprise
Executive
Level wlin Org
Middle
Mgmnt
Front Line
Corporate Functional
0. e 2.I7
0
_ _
Personal
0
0
(C;
23
Low Med High

The scope of this research was narrowed to concentrate on the study of the enterprise and front line levels only. It is the intent of the authors to illustrate the observed differences in the very top and bottom levels of the organization, as it is presumed that this data would be the least confounded and that data from the executive and middle management levels would simple indicate incremental progression from the enterprise to the front line levels (Figure 5). As a result, executive and middle management cope with all objectives at the same time. In addition, since teams make the vast majority of corporate product development decisions, this research focuses only on the decisions and decision rules of teams, rather than individuals. The scope of this research was further restricted to the study of nine separate components within the engine development organization.
This research seeks to discover the combinations of product development decisions, decision rules, and motivating factors that influence decision making behavior within the organization and their correlation to product performance (as measured by traditional automotive quality metrics).
Choosing the "right" set of decision rules is critical to a product's, and ultimately an organization's, success. It is the author's belief that alignment of decision rules at the top and bottom levels of an organization builds upon the organization's capability to make efficient decisions, ultimately reinforcing the corporation's vision, albeit for better or worse (see figure below). This thesis will focus primarily on the technical/engineering rules used for supplier outsourcing and product development execution as well some of the 'softer' personal decision rules. In addition, this thesis will provide recommendations pertaining to improving downstream product performance based on upstream enterprise and front line level decisions.
24

Figure 6 - Corporate Decision-Making Framework
Customers Shareholders
Reinforces
Reinforces
Impedes i.e.:
Experience
Personal Incentives
Functional Incentiy.qs..
(implicit/explicit)
Impedes
.
'''Community
Segment Leader in
Product(s) Produced
,.....--see
Corp. Climatee
Disseminated
Through i.e.:
............. ---. - G uiding
Principles
Customer Satisfaction
Shareholder Value
Stakeholder Satisfaction
Promotes
Generates
...
Front Lind
Decision Ru es
Environment
-Ii4e.:
Org. Structure
Tradition
Processes
Enables
oProduces
Produces c !um
25

1.4.1 Hypotheses
Hypotheses were developed around the areas of automotive product development decision rules, decision rule drivers and organizational levels. This body of research was framed around the premise that the decision rules at the top and bottom of an organization are misaligned due to factors such as the business environment (org. structure, tradition, processes), local motivation (experience, personal incentives) and inefficient cascading of corporate objectives.
In addition, it was hypothesized that alignment of decision rules (at enterprise and front line levels of org.) leads to capabilities and efficiencies that reinforce the Corporate Vision (see
Figure 6 above). In general terms, the corporate vision of the firm studied was to be the
"segment leader in specific product produced".
HYPOTHESIS 1: Misalignment of decision rules impedes achievement of corporate goals
Decision rules, as defined by the authors, are the criteria that product development teams use to weigh and prioritize available information during key decision making events. The authors further define decision rules as a function of time and level within the organization, driven by corporate, functional and personal objectives (see Figures 3, 4 and 5 above).
HYPOTHESIS 2: Decision rules for a particular PD team vary over time
HYPOTHESIS 3: Corporate, functional and personal goals directly shape the decision rules teams apply during key product development decisions
HYPOTHESIS 4: Decision rules vary by the level within the organization, with enterprise level decision rules heavily influenced by corporate goals and front line level decisions heavily influenced by personal goals
A typical product development funnel, as illustrated in Figure 2 above, often depicts pivotal decision points in the product development cycle pertaining to suppliers and supplier sourcing.
Early on in the process, the enterprise level makes the decisions to outsource particular components and identify competitive suppliers. This portion of the funnel can be deemed
'strategy'. Further into the funnel, the front line engineers make decisions involving supplier sourcing and product design and manufacturing. This portion of the funnel can be deemed
'execution'. It is recognized that valuing customer satisfaction can improve product outcome and that valuing personal goals can degrade product outcome. If Hypothesis 4 holds true, than one could surmise that enterprise level decisions, centered on customer satisfaction and other similar corporate objectives, would positively effect product outcome. Front line level decisions
26

on the other hand, which maybe be heavily influenced by personal objectives that would tend to negatively effect product outcome. Consequently, one could consider enterprise level decisions as reinforcing (corporate vision) while front line decision-making reinforces, degrades or has no net effect on product outcome, given the same primary intent by both teams of achieving product success.
HYPOTHESIS 5: Enterprise decision rules at pivotal PD events have a greater impact (on product outcome) than front line engineering decisions
27

Today's automotive products are so complex, that no single entity can entertain all knowledge and assets required to autonomously design, develop, and manufacture products and its subcomponents. Thus, companies outsource a fair amount of components to full service suppliers. A full service supplier not only manufactures the component according to a drawing, but more importantly takes responsibility for the component design, development, and validation as well. Given that these components are embedded in complex systems, that are difficult to integrate, it comes to no surprise that full service suppliers attempt to expand their area of expertise to complete systems. Suppliers that in the past were considered job shops are now converting to become systems providers. An example of that are fuel delivery systems. In the early nineties, suppliers just manufactured filler pipes, fuel lines and such. Now they are designing and developing aforementioned components. Furthermore, they attempt delivering the entire system from fuel tank to fuel pump driver module 3 0 . As a result of these developments, automotive OEM manufactures have become less vertically integrated and more dependent on outside partners. Strategic supplier sourcing and selection decision-making becomes increasingly important. Furthermore, decision-making in product development and execution with external entities as opposed to internal departments adds new challenges.
Given this development in the automotive industry, we will to focus our data research on product development decision rules that are concerned with strategy and product execution decisionmaking in the regards to the OEM-Full Service Supplier relationship.
Research literature in the field of product development efforts between automotive manufactures and their suppliers is mainly concerned with enterprise level outsourcing decision objectives. For instance, literature by Fine and Whitney 6 as well as Fine 3
' has dealt in particular with make-buy decision-making from an OEM strategic point of view. Hence, the effect of downstream engineering decisions based on upfront sourcing decisions is widely uncorrelated and the question arises, whether upfront strategic or downstream executive decision rules has more impact on the product outcome. Are there any success or failure relationships between
30
Pilot industries brochure, Steel Fuel Tank Sales, 2001.
6
Fine, C. and Whitney, D. "Is the Make-Buy Decision Process a Core Competence", MIT Center for Technology,
Policy, and Industrial Development.
3'
Fine Charles. (2000). E-Clockspeed-based Principles for Value Chain Design, MIT/SDM Class Presentation, July
2000.
28

sourcing decision rules applied upfront and decision rules used during downstream product execution? For instance, given an upfront decision requiring sourcing of a less capable supplier, can the application of certain downstream product development decision rules still lead to product success? And that lead us to question how product development rules vary? Supplier sourcing and subsequent product development decisions are influenced by a number of complex sets of decision rules. These decision rules may vary between functional organizations, such as engineering, purchasing, and product planning. As discussed in previously, in order to cover a wide array of potential parameters a mixture of informal interviews at various organizational levels (within a leading US automotive), literature research, frequent discussions with MIT-SDM cohorts, and supplier interviewing was performed. Through literature reviews and interviews there tends to be great debate as to the segmentation and complex interrelationships of component outsourcing decision rules. We will explore the broader areas of outsourcing decision rules in the following sections.
A total of nine engine sub component teams were selected as case studies for this project.
Beyond the condition that the mix of selected components to be studied varied by performance history (quality/warranty metrics over past 10 years were not identical), they were randomly selected. In addition, the level of supplier design and development responsibility and other variables for each of these components also varied over the past ten years.
Given the scope of this research, a large amount of complex data needs to be collected and analyzed in order to derive valuable conclusions. However, given the constraints associated with this project, we took the approach to collect data utilizing three research methods; quantitative surveys, qualitative interviews and focus groups, and the development of a systems dynamics model. Ultimately, we will triangulate significant results from these three independent but limited research methods to reach scientifically significant conclusions. Key variable relationships are quantified by means of an original survey of 33 executives and lead engineers, involved in sourcing decisions and product performance consequences on nine selected components, along with statistical data analysis of the results. Qualitative data on variable relationships are derived from in depth interview and focus group research from the same population - all based on original protocols developed for this research. Finally, the systems dynamic model calibrated with real world data from several engine component development case studies provides an opportunity to understand the complex web of causal relationships within the OEM-Supplier product development system. Ultimately, relationships between
29

enterprise and front line decision objectives are better understood through this triangulation of research methods, which increases confidence in the validity and reliability of the findings. In order to acquire useful data for each research method, we analyzed a specific engine engineering organization within a major automotive manufacturer.
2.3.1 Core Criteria
Supplier sourcing and subsequent product development decisions are influenced by a complex set of decision rules. These decision rules may vary between functional organizations, such as engineering, purchasing, and product planning. Therefore, in order to cover a wide array of potential parameters, the authors conducted informal interviews with employees of varying levels of responsibility from a number of departments within aforementioned automotive OEM.
This interview information was combined with literature research 6
3 2 ,9, , 33 frequent discussions with co-workers and MIT-SDM professionals, and supplier interviews. Synthesis of supplier sourcing and product development decision variables yielded the following array of decision rules, randomly listed below:
6 Fine, C. and Whitney, D., "Is the Make-Buy Decision Process a Core Competence", MIT Center for Technology,
Policy, and Industrial Development, 1996.
9 Fine, Charles H. (1998), Clock Speed: Winning Industry Control in the Age of Temporary Advantage, Perseus
Books, Reading, MA.
32 Ford Motor Company, Europe, Potential High Impact Supplier Selection Rationale, Ford Motor Company internal document, 1998.
3
SAP AG, Automotive Supplier Solution Map, SAP Ag internal document, 1999.
30

Quality of Vendors
Vendor Accountability (i.e. Warranty Sharing)
Supplier Financial Capability
Warranty Cost
Supplier Risk-Taking Behavior
Part Supply Volume
Supplier R&D Responsibility
Supplier R&D Capability
Time until engineer has proficient component knowledge
Time until Component Engineer moves on
Component Complexity
Technical Innovation
Internal Component Expertise / Capability
Supplier Mfg. Capability
Component Functional Requirements / Attributes
Component Mfg Feasibility
Internal Special Knowledge (i.e. materials etc.)
Supplier Accessibility (i.e. co-location)
Competitive Component Cost Pressure
Supplier-OEM Partnership / Teamwork
Supplier Responsiveness
Supplier Attitude
Program Staffing (early in Program)
Program Staffing (throughout Program)
Cost Cutting Pressure
Quality
Supplier Economies of Scale
Number of engine programs
Number of unique Components
Engine Program Timing
Number & degree of difficulty of regulatory wants
Special / Focus Customer Wants
Internal Behavior towards risk
Level of component mgmt leadership
Program turnover / life cycle
Special warranty causes
Supplier Productivity
Six Sigma Black Belt Staffing
Amount of Program Rework
Intensity of supplier shadow engineering
Internal Program Workload
Number of short-term projects
OEM Profitability
Supplier Profitability
OEM internal capability
Supplier Employee Turnover
Supplier Willingness to become Full Service
Supplier Competitive Pressures
OEM teaching Capability
Engineering Change Validation Capability
Supplier Business Objectives
OEM Business Objectives
Sharing of Drwg's, Tools among suppliers
Design Change Leverage
Level of internal tool development capability
31
56.
57.
58.
59.
60.
61.
62.
63.
68.
69.
70.
71.
72.
73.
74.
75.
76.
64.
65.
66.
67.
77.
78.
Engineers learning to become proficient
Average Engineer in Job time
OEM Competitor Capability
Component Attribute Knowledge
Management of Resources
Management of Facilities
Management of Documentation
Systems Engineering Concentration
Program Management Concentration
Leadership in issue resolution
Number of suppliers per component
Supplier Process Capability
Time to force bad supplier out
Perception of analytical tools
Supplier Quality
Supplier Engineering Support
Supplier Product Delivery
Number of Quality Vendors
Level of Internal Vision (know your goals)
Level of Internal Strategy Knowledge
Level of Internal Strategy Execution
Time to develop FEA/CAE Tools
Level of maintaining / extending in house capability
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
Late changes
Level of Technical Innovation
Commonality
Amount of non-value added work
Incorporation of lessons learned
Ability to predict customer duty cycles
Level of Upfront planning
Management support
Level of component documentation
Amount of component testing
Ability to prioritize work
Component Section Structure
Time to see strategy benefits
Want to be an engineer
Want to be a manager
Flexibility in schedule, relationship, outside pursuits
95.
96.
Real Engineer - empowerment
Satisfaction in doing real engineering work
97. Section learning
98. Doing the right thing
99. Doing the politically correct thing
100. Component Performance
101. Supplier Continuity
102. Ability to see weakness and resolve
103. OEM teaching ability
104. Internal Engineer Training
105. Product complexity
106. Capacity (Resources, Mfg. Etc)
107. Supplier Location
108. Supplier Organization
109. Supplier Reputation

110. Electronic Data Transfer (OEM-Supplier
111. Time until warranty issue surface
112. Architecture (Integral vs. modular)
Product /Process/Supply Chain
113. Capability Dependency
114. Strategy (Future relationship/tech/business needs)
115. Integration expertise
116. Cost and timing
117. Exchange rate and supplier location
118. Supplier Existing mfg. Assets
120. Supplier Financial Performance
121. Supplier Performance track record
In order to compare the importance of the same decision rules at the front line and enterprise levels, the authors agreed to keep a consistent set of decision rules between both organizational groups. While recognizing that some decision rules are more common for one area than the other, this approach allows all parties to consider a consistent set of decision rules. This will aid research and evaluation of the correlation of rules to product outcome. While it is impractical within this thesis to analyze the relationships between supplier sourcing/selection and product execution decision rules based on all of the variables above, the research was somewhat simplified by organizing key variables into decision rule categories
(based on interview and literature input).
2.3.2 Decision Rule Categories
We can decompose automotive component decision-making events into four areas, the customer, the OEM competition, the supplier, and the OEM itself. In order to achieve the product performance objective, an OEM uses supplier capability that is transferred via "OEM to supplier" interfaces, what we term supplier proximity. Given that input, the OEM can use its internal capability to manage the product complexities that are unique for any product. Ultimately, enabled by customer and competitor product knowledge, the OEM can or achieve successful product outcome. As a result, decision rules for enterprise level supplier sourcing and front line product execution decision-making can be divided into seven categories:
" Product Complexity
" Internal (OEM) Capability
* Supplier Capability
* Supplier Proximity
* (OEM) Customer Proximity
" Competition
" Product Performance
32

Based on decision rules gained from literature research and the interviews cited above, the seven decision rule categories were decomposed into pragmatic decision rules understood by professional decision-makers.
2.3.2.1 Product Complexity
As described by C. Boppe , complexity is thought of as a measure of the difficulty we have working with something and it typically increases when the number of attributes or situations that exist simultaneously increases. Anything with a high degree of complexity is complicated.
Therefore, considerable knowledge, study, and effort are required to analyze, solve, and understand it. There can exist many sources of complexity within any system and quantifying complexity becomes difficult. However, for our purpose we limit product complexity sources to the following elements:
* Number of simultaneous product development efforts
* Number of competitive suppliers
" Product functional interfaces
* Product cost and timing objectives
* Product attribute and functional requirement
* Level of product innovation
It is recognized that a product or sub component team may be involved in a multitude of different product (engine) programs. The resulting number of product development efforts (or projects) causes more complexity for the team, yielding different part numbers or prototype due dates the internal and supplier teams have to cope with. Given that suppliers operate uniquely or have different levels of engineering and manufacturing expertise to offer, the number of
competitive suppliers associated with the component can elicit various levels of complex engineering and project management tasks for the component team involved. Thus, while one component supplier may propose a new technology, the OEM cannot simply transfer this technology to the less capable supplier to copy in order to keep part commonality. Furthermore, manufacturing process improvement may be a competitive advantage of one supplier over the others. While potentially known by the OEM team, confidentiality agreements prevent knowledge transfer between vendors. However, if the number of competitive suppliers is high, the OEM has more leverage in sourcing and product execution decision-making.
3
Boppe, Charles. Systems Engineering. Class Notes. Cambridge, MA: MIT, June 6, 2000.
33

Product or component functional interfaces within the total system depend on whether the system architecture is of integral or more modular nature. Integral architecture features close proximity amongst its elements in both function and form. Modular architecture features multiple, interchangeable parts with standard interfaces. In this study the components analyzed have a very integral relationship to the system (engine) they are part of. Figure 7 illustrates what is meant by component functional interfaces. For instance, engine-sealing components are very integral in nature. Even the slightest component design change cause changes to other parts within the engine system. The engine components selected for our study have a variety of levels of integrality (or component functional interfaces) within the engine system.
Figure 7 - Component Functional Interfaces
Rear Seal retainer'
Cylinder
Head, g |
Cylinder Head Gasket
Cylinder
Block
Connectivity = 14
Connectivity
=
Load
Heat
Vibration
Oil
Coolant
Combustion Gases
Air/Fuel
Cylinder
Head
Exhaust Manifold Gasket
Exhaust Manifold
Connectivity = 16
L Cylinder
Cylinder
Block
Gake
l Pan
Cover
Whether or not to involve, and when to involve, suppliers in the product development process is
highly dependent on the type of architecture. If the architecture is predominantly of an integral nature, supplier integration prior to the architectural "function to form" stage may be beneficial or simply not advisable. Since subsystem interfaces are less rigid and defined, interface management between product components becomes very important for the final product performance. Modular product architectures with defined interfaces pose less interface
34

complexities; supplier's primary responsibility is to provide architectural components rather than taking part in actively defining architectural linkage as is required for integral product architectures. Standard components have very limited architectural influence as interfaces are completely defined and supplier integration later in the process, during downstream product development or even manufacturing stages, is typically sufficient.
Component cost and timing objectives constrain the engineering degrees of freedom and causes complex trade-offs with component attribute and functional requirements, embodied by such items as material usage and technology content. Component cost objectives are defined as the components variable and investment costs. Component timing objectives determine the time between design start and production start. Each engine component needs to satisfy a different number and type functional and attribute requirements such as safety, emissions, performance, noise/vibration/harshness, sealing, engine combustion needs, etc.... The level of
component innovation can range from none to breakthrough process and/or product change.
Thus, both product execution teams as well supplier sourcing decision making teams need to comprehend the supplier technical experience and probability of delivering the desired technology.
2.3.2.2 Internal (OEM) Capability
Since all the of the components researched are manufactured by an outside source, OEM capability is defined as the internal capability the OEM possess to design, develop, and validate a component going into mass production and embedded in an overall system. OEM capability can be decomposed in many sub elements. For the purpose of this study, however, those elements were assumed to be a function of the following key variables:
* Internal Resource Burden
* Knowledge
* Maintaining/Building Internal Capability
* Product Development Process Discipline
* WCR, DVP&R and FMEA Adherence
Internal resource burden is defined as the actual resources allocated to a project, in this particular component engineering activity. From a pragmatic standpoint, resources can be thought of as the actual budget, headcount, design tools, and testing resources.
35

Knowledge in this study describes the technical skill the component engineering activity possesses. Related to the subject of component outsourcing, Whitney and Fine 6 developed a method for determining the knowledge level within an activity from an OEM's perspective. While
Whitney and Fine developed the left hand side of Figure 8, a more pragmatic description as it relates to the OEM was added.
Figure 8 - Knowledge Dependency Flow
Dependent for Item Knowledge
Can Identify Qualified Supplier
*..-..... p.
Can Write Specifications
Can Evaluate Quote
......... 1
.. """" p.
Can Verify that Item Meets Spec **'""""
Can Help Supplier Technically
*
..- 0*
Can Help Supplier Operationally
*.........
Can Improve after Receiving
1p
Can Des./Dev. & Mfg. In-House
......... 00
We have extensive experience with suppliers
We understand design variables & their affect on product
We understand how to choose the best supplier
We have verification testing knowledge and capability
We can design item/system and teach technically
We can capably mfg item/system & teach operationally
We can redesign due total system knowledge
We can do everything, but lack capacity to produce item/system
Dependent for Item Capacity
Per definition, in this study the OEM is dependant on the supplier for production capacity.
Furthermore, with the introduction of full service suppliers, the OEM analyzed also has actively
(over past 20 years) outsourced design and development activities to suppliers. In regards to sourcing decisions, the OEM firm needs to decide whether it can afford knowledge and manufacturing capacity build-up internally within the given competitive environment. If the firm maintains knowledge and capacity independency, there would be no reason to ponder supplier integration questions. OEM's involve suppliers if they lack knowledge in some subsystem areas and/or if they don't possess manufacturing capabilities.
6
Fine, C., Whitney, D. (1996), "Is the Make-Buy Decision Process a Core Competence", MIT Center for
Technology, Policy, and Industrial Development.
36

As discussed by Whitney and Fine (see Figure 9), depending upon the product architecture and the firm's knowledge and capacity capability, it may find itself with better or worse outsourcing opportunities.
Figure 9 - Outsourcing vs. Architecture
0 w
U)
0
DEPENDENT FOR
KNOWLEDGE
& CAPACITY
DEPENDENT FOR
CAPACITY ONLY
A
POTENTIAL
OUTSOURCING
TRAP
BEST
OUTSOURCING
OPPORTUNITY
WORST
OUTSOURCING
SITUATION
CAN
LIVE
WITH
OUTSOURCING
INDEPENDENT FOR
KNOWLEDGE & CAPACITY
OVERKILL
IN
VERTICAL
INTEGRATION
BEST
INSOURCING
SITUATION
Adapted from Fine & Whitney, "Is the Make/Buy Decision Process a Core Competence?"
Each type of architecture has inherent advantages and disadvantages that consequently result in different degrees and timing of supplier involvement. Supplier integration into the product architecture decision process is highly dependent on the type of architecture the firm tries to use.
Ideally, a firm intending to outsource would decompose complex systems into modular systems, write competent specifications, be able to verify the product specifications when delivered, and be dependent for capacity only. Thus, product success is a function of system decomposition ability into modular systems, requirement specification and testing capability. Outsourcing risk is described by the coupling between levels of modularity and the type of supplier dependency
(capacity and/or knowledge).
37

The company analyzed can presumably make the items studied and may already do so, but for reasons of time, space, money or asset management, it chose to extend the capacity by means of involving one or more suppliers. Furthermore, the company elected to outsource some level of component design, development, and validation for all components investigated.
In summary, internal knowledge as well as maintenance/building of this knowledge are key differentiators when making upfront supplier sourcing and selection and downstream product execution decisions.
Product Development Process Discipline as well as adherence to engineering standards and best practices, such as WCR (Worldwide Customer Requirements) DVP&R (Design Verification
Plan and Report) and FMEA (Failure Mode Effects Analysis) are important for product development decision-making as well.
2.3.2.3 Supplier Capability
Supplier capability decision rule category can be defined as a function of several decision rules:
" Manufacturing assets and capacity
" Knowledge
" Cost and timing
" Quality
* Level of design and development responsibility
* Number of customers
Supplier manufacturing assets and capacity can have significant importance for both sourcing as well as downstream product development decisions. For instance, product volume needs or existing supplier process capability constraints prior to the sourcing decision can have an impact on supplier investments that need to be considered in supplier selection decision-making.
Furthermore, supplier process controls may have an impact on downstream decisions about component tolerances.
Supplier cost, timing, and quality are central considerations not only in sourcing decisions determined by engine/vehicle profitability and competitive needs but also in product execution decision-making, such as material usage or tolerance design.
The level of design and development responsibility is defined by nine independent variables.
Thus, a supplier's design and development responsibility would be highest if they were responsible for all the following tasks:
38

o Drawings o Change Control Management (SREA) o Advanced Product Quality Plans (APQP) o Design and Development Tools (i.e. CAD, CAE, FEA, CFD) o Component Key Life Testing (KLT) o Component Design and Production Verification Testing (DV/PV) o Design Verification Plan and Report (DVP&R) o Failure Mode Effects Analysis (FMEA) o Engineering (ES) and System Design Specifications (SDS)
In reality, even after component outsourcing, the OEM will keep some responsibilities in house or share others with its supply base dependent on core capability needs. From a technology, economies of scale, and/or competitive best practices standpoint it may be more or less important whether or not suppliers engineer and manufacture similar components for OEM competitors. Thus, the supplier may become a window to understanding future competitive plans. Furthermore, the number of customers and the knowledge of those OEM customers in certain engine attribute may provide lessons learned and technologies of valuable to both sourcing and product execution decision-making.
2.3.2.4 Supplier Proximity
Supplier proximity, a measure for how close OEM and supplier businesses are aligned with each other geographically, organizationally, culturally, and from a electronic information transfer standpoint, is decomposed into the following pragmatic decision rules:
* Location of supplier facilities
* Level of Supplier Technical Assistance
" Supplier trustworthiness
" Supplier-OEM Information sharing
* Supplier Flexibility and responsiveness
" Number of competitive suppliers
The above decision rules have varying levels of influence over product execution and supplier selection decisions. For, instance supplier trustworthiness is mainly derived from previous dealings with the supplier and thus, reflected in sourcing decisions. However, it could also become important when trying to manage risks with supplier promises (i.e. prototype delivery dates) in downstream engineering activities. Location of supplier facilities may have an impact on the consideration for exchange rates as well as the ability to share in person meetings with suppliers. With higher supplier-OEM information sharing and supplier flexibility and
responsiveness levels, decision-making in downstream activities may offer less risk and increase opportunities for new product ideas. Thus, sourcing and product execution decisions
39

are impacted by this decision rule. The level of supplier technical assistance is determined by the OEM's resource capabilities, but increases the knowledge about the suppliers capabilities and thus will be included in both strategic and product development decisions. The higher the
number of competitive suppliers the more leverage an OEM may possess and therefore should be considered in decision-making.
2.3.2.5 Customer Proximity
The correlation between engine component design and customer proximity (or knowledge) is somewhat difficult. In reality, engine systems produce customer attributes. Not every component researched has a clear relationship to customer wants. However, there are some decision rules that impact component performance directly from a customer perspective:
* Incorporation of lessons learned
" Interaction with engine systems, quality, testing, and manufacturing
Given long-term experience, the organization has an extensive lessons learned database and thus the level of incorporation of these rules in the development process has an impact on product outcome. Thus, the incorporation of lessons learned may be mainly important for product execution decisions. However, lessons learned from previous sourcing decisions that directly impacted the customer may find recognition in outsourcing or supplier sourcing decisions. The integral architecture of an engine system provides a need for component engineering interaction with engine systems, quality, testing, and manufacturing and thus, the level of this interaction can affect decisions.
2.3.2.6 Competition
The level of performance of OEM competition in the market affects internal decisions, not during strategy decisions, but also on the product execution side. Concern for the following decision rules are central to product development decisions:
* Cost and timing
" Product attributes
" Quality
Based on internal capabilities, competition, and performance targets, the above decision rules may force sourcing to a supplier with specific capabilities. However, key leverage components may not be outsourced, as the OEM may want to keep control to stay nimble in addressing competitive needs. Decision-making when developing a component may require certain trade-
40

offs in product attributes that provide the required product attribute leadership level. The specific composition of competitive cost, timing (time to market), and quality plays a key role in product decisions.
2.3.2.7 Product Performance
Product performance is also dependent on the competitive environment and consists of the rules that influence the ability to meet product goals:
* Actual cost and timing (vs. objective)
" Product performance metrics (quality, etc.)
Whereas the Competition category refers to how well the component can compete amongst similar components sourced from various suppliers, this category groups the influences that effect decisions made based on the current level of product performance. For instance, if the
OEM understands their product to be the poorest performing product in the marketplace, they may choose to outsource development and manufacturing to an alternative supplier who has demonstrated product success. Product performance in this research refers to cost, timing, and quality metrics.
2.3.2.8 Decision Rule Category Overview
In order to provide a more meaningful description of the pragmatic decision rules categories described above, the figure below summarizes the make-up of each category and identifies possible units measures for each individual decision rule. While most decision rules are very tangible, some decision rules are more intangible and require subjective metrics.
41

Figure 10 - Decision Rule Categories
CATEGORY
0
0
Suppliers & Part Numbers
DECISION RULE
Programs
Integration / Connectivity
E~I
Level of Change / Innovation
Anute
Performance (Durabiltty
NV Ht,
Emissions, Weight, Package) &Function
Pertor ance, oafeiy,
Cost (Tooling/Variable) & Timing
Culture/Attitude: Consumer Value (Total Cost, Consumer Focus,
Customer Satisfaction); Transformational (Champions Diversity,
Courage, Changes Ford Opps); Leadership (Business Accumen,
Integrity,
Drive, Teamwork)
Capacity (Actual Resource Allocation)
Component Knowledge & Integration Expertise
Process Discipline (PTPRP)
Manufacturing Assets (F&T)
Knowledge Metric
Cost & Timing (Proto Delivery; DesignFreeze)
Quality
Dependency on sub-suppliers (des, dev, mfg)
UNIT OF MEASURE
# of
# of
# of functional interfaces
=hone; 2=1ncr&mentaI(t6ro Or Proc.); 3= incremental
(Prod & Proc.); 4=Breakthrough (Prod or Proc.); 5=Breakthrough (Prod & Proc.) of Requirements
1 =unaware; 2=aware; 3=solid; 4=proactive; 5=champion
# of engineers
1 ="Can idenify supplier, specification, and evaluate quote"; 3="Can verify specification are met and can help supplier technically"; =Can help supplier operationally and design/develop/manfacture in house"
1 =late; 3=on time; 5=proactive
1 =New; 3 =both;
1 ="Can
5=existing idenify supplier, specification, and evaluate quote";
3=Can verify specification are met and can help supplier technically"; W=Can help supplier operationally and design/develop/manfacture in house"
1 =higher; 3=same; 5=lower than competition
I= <Competition: 3= Competition; 5=Best in Class (BIC)
# of Subtier Suppliers (Des, Dev, Mfg)
Location (des./mfg) into Sharing: tlectronic(-requency
Technical Knowledge
/
Syst.Rert.);
1 =town; 2=state; 3=country; 4=continent; 5=different continent
5=daily/no issues; 3=weekly/some issues; 1 =monthly/major issues
E
R~
CL 0
(n (L
Responsiveness / Change Mgmt Flexibility
Trustworthiness
1 =late; 3=on time; 5=proactive
1=have to watch; 3=can rely on; 5=exceeds expectations
E
Adherence to Customer Requirements and Engineering Standards 1=80%; 3=90%; 5=100%
~'
Level Lessons Learned (Lessons Learned Database, Automotive 1=data colected but not shared; 3=data used to set future targets;
Quality Metrics, Customer Clinics, Consumer insight) 5=process in place promoting immediate communication/resolution
SCL
Level of Interaction (with Eng. Syst., Qual Departments, Testing) 5=daily; 3=weekly; 1=monthly a. 0
E
0
CPU & R/1 000 3/36
Cost & Timing vs. Objective
Attribute Performance (DV/PV testing, functionals met)
R/1000
1 =does not meet; 3=meets; 5=exceeds
1 =does not meet; 3=meets; 5=exceeds
Cost & Timing
&
Attribute Performance
Quality rating vs. other competition: I=below avg; 3=among leaders; 5=BIC rating vs. other competition; I=below avg; 3=among leaders; 5=8IC rating vs. other competition; 1=below avg; 3=among leaders: 5=BIC
2.3.3 Decision Rule Drivers
The key decision rule drivers were predominantly derived from both author's long-term product development experience in the automotive industry. As mentioned previously within this paper, the authors contend that decision rules are motivated by personal, functional, and corporate objectives. These drivers can be broken down into the following categories: corporate,
42

objectives. These drivers can be broken down into the following categories: corporate, functional and personal. Corporate decision rule drivers are derived from corporate goals and the guiding principles. These drivers are cascaded from the very highest level within the organization downward. Functional objectives are those principles that govern the way the immediate department operates (i.e. local budget, local culture, management of supply chain relationships). Personal decision rule drivers are the personal considerations that each individual on the team values, such as the opportunity for advancement, rewards or recognition and the ability to reduce work related stress (i.e. ability to end the workday promptly without working overtime, limited responsibilities, etc.). Examples of each of these include:
Corporate Objectives:
* Corporate mission or vision
* Shareholder value
* Customer satisfaction
* Employee satisfaction
* Community obligation
Functional Objectives:
* Departmental goals
* Supply chain management
" Organizational structure
* Local processes
* Culture/tradition
Personal Objectives:
" Merit rewards
* Experience
" Work-life balance
2.4.1 Survey Development
In order to develop a survey that would provide data to test the hypotheses as detailed in the previous chapter, we first identified the quantitative data research intent. Intent and survey goals can be summarized as follows:
* Acquire level of supplier responsibility over the past ten years for each component surveyed consistent with above decomposition of level of supplier responsibility
* Verify decision rule category decomposition into pragmatic decision rules as detailed above
" Establish correlations between decision rule categories and product outcome parameters, such things gone wrong as well as warranty cost performance
43

* Determine the influence of intervening variables (personal, functional, corporate objectives) on both the enterprise and font line engineering organizational level
" Use survey data to correlate with system dynamics model of OEM-supplier network
* Input level of decision rule category importance over time into systems dynamics model
As discussed previously, while distinguishing the survey questioning between front line and enterprise level leaders, the set of decision rules was kept common for all surveys. Thus, enterprise level leaders were asked to rate decision rule priorities specific to component outsourcing and supplier selection decision-making. And front level engineers provide importance for each decision rule applied during product execution decision-making events. In order to ease the understanding of decision rule for survey participants, we tailored above decision rules and decision rule drivers to commonly used terms within the organization.
Furthermore, the survey was worded to stress TEAM decision-making rather individual decision rule preferences. Product development teams execute activities downstream of strategic decisions. Therefore, quantifying team decision rule importance during product development seemed more closely aligned with reality. In order to limit the time exposure for survey participants, we introduced methods to simplify the understanding of decision rules and associated questions. Furthermore, this simplification we thought would improve the quality of survey responses. Marketing survey best practices, such as the same rating scale for each decision rule, were adopted from Brodi
5 and Churchill 3.
To further improve survey response quality, we went through a rigorous survey development cycle that included the following steps:
* 1 st survey iteration critiqued by several colleagues at enterprise and front-level
* Survey adjustments based on comments
* Prototype survey filled out by several non-survey participants for verification
It is recognized that survey research has several strength and weaknesses in regards to data validity. Some strengths of this method are:
* Delivers precise numerical estimates and relationship between variables in frequency and magnitude
" Affords objectivity -capacity to break free any biases
* Application of statistical methods that can enhance the rigor and add to the depth of research findings
5
Brodie, Christina Heperner and Burchill, Gary. Voices into Choices Acting on the Voice of the Customer, Joiner
Associates Inc., 1997.
3
Churchill Jr., Gilbert A. Marketing Research: Methodological Foundations, The Dryden Press, 1999.
44

0
Ability to portray differences between organizationally distant groups
However, threats to validity in survey findings is mainly caused by the following constraints:
" Limited survey participants (33 respondents out of 40 surveys sent out) to represent an organization with average total number employees between 1,200 and 1,800 (annual attrition rate roughly 10%). However, survey participants needed to have a significant level of experience in product development working with and without full service supplier. This reduced the amount of qualified participants significantly.
* Limited amount of front level survey participants (i.e. 3-4 front level engineers) representing a large fraction of each component engineering team, but does not represent other activities, such as finance and purchasing
" Limited enterprise level survey participants (i.e. 1-2 enterprise leaders) per component caused by realities of low ratios between enterprise and front line leaders.
" Some potential for misunderstanding of questions (somewhat mitigated by follow-up interviews).
As expressed in the introduction of this thesis, survey and interview/focus group participants came from the same population. Distributing the surveys to participants prior to the focus group or interview meeting provided several advantages:
* Served as reminder for the scheduled interview/focus group sessions
* Provided orientation to participations and put them into the state of mind in terms of the interview content
" Survey collection during the interview/focus group sessions enhanced survey response level
* Specific survey question clarification enhanced survey data quality and understanding respondents thought processes.
Participation in the survey was identified as being voluntary, again to enhance response quality.
While senior management highly supported this research, no mandate was cascaded requesting employees to support the study. A copy of the enterprise and front line surveys can be found in Appendices B and C.
2.4.2 Data Analysis
After cleansing the survey data of missing variables and/or coding mistakes, the following statistical analysis of the survey responses was conducted using the SPSS software tool 36
:
* Descriptive statistics o Participant demographics o Component outsourcing pattern o Decision Rule priorities (i.e. mean and standard deviation) o Decision Rule Driver priorities (i.e. mean and standard deviation)
* Organizational alignment analysis
36 SPSS Inc., SPSS 10.0 and SPSS 10.0 Base Brief Guide, Prentice-Hall Press, 2000.
45

* Reliability analysis o Decision Rule category o Decision Rule Driver categories
* Product Outcome correlation analysis
2.4.3 Descriptive Statistics
2.4.3.1 Demographics
The general survey demographics are depicted in Figure 11. The survey, conducted within an engine engineering organization of a major automotive manufactures, was sent out to 40 engineers. 33 responded. The respondents included 10 enterprise level employees responsible for making pivotal strategic product development decisions, such as component outsourcing. All other survey participants are considered front level engineering personnel confronted with product execution decision-making. For each component at least 1-2 enterprise level and 3-4 front level engineers replied to the survey. The respondents reflect roughly three percent of the total headcount of the organization. By in large, they represent the critical mass of employees impacting the performance of the organization in the past 10 or more years. Of the enterprise level respondents, 90.6% have more than 9 years experience and 43.7% have more than 25 years experience working in the organization analyzed. Of the front line engineering respondents, 65.6% of survey participants have more than 9 years experience and 12.5% more than 25 years experience directly with the specific component surveyed.
Years Experience @ OEM
Years Experience with spec. Component
Number of Survey Participants
Figure 11 - Survey Demographics
I otal Population
Mean Std. Dev.
22.5
14.9
33
9.0
8.6 n/a
-nterprise Level
Mean Std. Dev.
25.3
20.3
10
7.1
7.5 n/a
-ront Line Level
Mean Std. Dev.
21.2
12.5
23
9.7
8.1
n/a
2.4.3.2 Component Outsourcing
Of the components analyzed, outsourcing happened between 1990 and 1998. On average,
Enterprise level personnel recognized component outsourcing roughly 2 years before front level engineers (see figure below). This can be explained with the organizational time lag between strategic decisions and execution of such decisions during product development.
46

Year Component Outsourced
Figure 12 - Component Outsourcing
I otal Population
Mean
1994
Std. Dev.
4.4
Enterprise Level
Mean
1993
Std. Dev.
5.6
Front Line Level
Mean
1995
Std. Dev.
3.4
Prior to outsourcing, the OEM organization conducted component engineering internally. Thus, the OEM controlled the engineering disciplines as depicted in Figure 13 prior to outsourcing. In
Figure 13, a mean near 1 indicates OEM responsibility; a mean near 3 indicates supplier responsibility. After outsourcing some engineering responsibilities, such as component drawing generation, engineering change control (specific to internal component changes) and advanced product quality plans migrated to the supply base. For critical engineering disciplines, such as design verification and engineering specifications, the OEM strategically kept engineering control in house. Other engineering tasks are shared between the supplier and the OEM analyzed.
Figure 13 - Engineering Responsibilities
Drawings
Change Control Management
Advanced Product Quality Plans
Design and Development Tools
Component Key Life Testing
Component Design and Production Verification
Design Verification Plan and Report
Failure Mode Effects Analysis
Engineering and System Design Specifications
1st Model Year Atter Outsourcing
Mean Std. Dev.
2.5
2.6
2.2
2.1
1.7
1.8
1.6
1.9
1.3
Scale: 1=OEM Responsibility, 2=Both, 3=Supplier Responsibility
0.9
0.8
0.9
0.8
0.9
0.9
0.9
1.0
0.7
Model Year 2000
Mean Std. Dev.
0.6
2.8
2.8
2.7
2.4
2.2
2.0
1.7
1.9
1.3
0.7
0.6
0.7
0.9
0.9
1.0
1.0
0.7
2.4.3.3 Decision Rule Priority (mean, standard deviation)
The table below (Figure 14) provides the mean and standard deviation of the decision rules responses. Cost and timing decision rules as well as supplier's component knowledge and trustworthiness have highest priority during decision-making events in the organization.
47

Figure 14 - Decision Rule Priorities
Decision Rule
Suppliers Cost & Timing
Cost & Timing Objectives for Component
Suppliers Component Knowledge
Supplier's Trustworthyness
Cost & Timing Competitors Component
Supplier's Quality
Part Cost and Timing vs. Objectives
Information Sharing
ComponentPerformance Metrics
OEM Resource Capability
Number of Functional Requirements
Flexbility and Responsiveness
Supplier Manufacturing Assets
Level of Change
Quality of Competitive Product
Supplier Resonsibility
WCR, DVP&R & FMEA Adherence
OEM's Knowledge & Expertise
Maintaining/Building In-House Capability
Number of Competitive Competitive Suppliers
Functional Performance of Competitors Product
Reinforcing/Extending Supplier Relationship
Number of Different Supplier associated with Part
Location of Facilities
Incorportation of lessons learned
Interaction with Systems Testing, Quality &Mfg
Number of other OEM's Supplier supplies
Number of Programs
Number of Part Numbers
Number & Type of Functional Interfaces
OEM Process Discipline
STA Involvement
Scale: 1=No Priority, 2= Low Priority, 3=Medium Priority, 4=High Priority
2.4.3.4 Decision Rule Drivers
The strongest decision rule driver is customer satisfaction. Drivers such as personal rewards/opportunities as well as work-life balance do not seem to have much importance.
0.9
0.9
0.9
1.1
1.0
1.1
0.9
1.0
1.0
0.8
0.9
Std. Dev.
0.7
0.9
0.9
1.0
0.9
0.9
1.0
1.0
0.9
0.9
0.9
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.9
0.9
3.0
2.9
2.9
2.9
2.9
2.8
2.8
2.8
2.8
2.7
2.7
2.6
2.6
2.5
Mean
3.4
3.2
3.2
3.2
3.1
3.1
3.0
3.0
3.0
2.5
2.4
2.4
2.3
2.3
2.2
2.2
2.1
2.0
48

Figure 15 - Decision Rule Drivers
Decision Rule Driver
Customer Satisfaction
Department Goals
Local/Department Traditions
Shareholder Value
Internal Growth Opportunities
Employee Satisfaction
OEM Organizational Infrastructure
Rewards / Opportunities
Work-Life Balance
Scale: 1=No Priority, 2= Low Priority, 3=Medium Priority, 4=High Priority
Mean
3.0
2.7
2.2
2.0
1.8
1.8
1.7
1.7
1.5
Std. Dev.
1.1
0.9
0.9
1.0
0.9
0.9
0.8
0.9
0.8
2.4.4 Alignment Analysis
After analyzing the organizations decision rules priorities in broad terms, this part of the analysis focuses on how closely enterprise and front level teams are aligned within each decision rule and decision rules driver. The analysis was conducted using a cross-tabulation procedure. This procedure forms two-way relationship tables and provides a variety of tests and measurements regarding the association between parameters. Using the SPSS software, if one were to specify a row (survey respondent), a column (survey question), and a layer factor (control variable), the cross-tabulation procedure forms associated statistics and measures for each value of the layer factor (or a combination of values for two or more control variables). The layer factor for this analysis is differentiated by all enterprise and all front line level personnel surveyed.
The authors chose to segment the type of alignment into three areas. These segments are:
* Misaligned - decision rule or driver is prioritized in opposite (or near opposite) fashion between enterprise and front line levels
* Gap - priority levels are similar around a particular priority band (no/low/med/high) but not across all priority bands (dissimilar distribution)
* Aligned - decision rule or driver is prioritized the same (or near same) by both enterprise and front line levels
In order to place a particular decision rule or decision rule driver into an alignment category, we chose to test the survey cross-tabulation results against the following criteria:
49

* Sum of all priority level differences between is larger than 60 (max. = 200).
* Sum of absolutes of difference between no and low as well as medium and high priority between enterprise and front level respondents is larger than 30.
* No or high priority importance delta at least 20% between enterprise and front level respondents
* Mean priority delta between enterprise and front line respondents is larger than 0.5.
If none of these criteria is met, the decision rule or decision rule driver is categorized as
ALIGNED. If 1 or 2 of these criteria is met, the decision rule or driver was classified as GAP. If 2 or 3 of these rules were met, the rule or driver was classified as MISALIGNED.
Figure 16 - Alignment Segmentation
Decision Rule
Competition
Quality Competitive Product
Cost & Timing Competitors Component
Functional Performance of Competitors Product
Product Complexity
Level of Change
Number of Part Numbers
Number of Different Supplier associated with Part
Number & Type of Functional Interfaces
Cost & Timing Objectives for Component
Number of Engine Programs
Number of Component Functional Requirements
Internal Capability
OEM Resource Capability
OEM's Knowledge & Expertise
Maintaining/Buildingin-House Capability
WCR, DVP&R, FMEA Adherence
Product Development Process Discipline
Supplier Capability
Supplier Manufacturing Assets
Suppliers Component Knowledge
Supplier's Quality
Suppliers Cost & Timing
Number of other OEM's Supplier supplies
Supplier Resonsibility
Supplier Proximity
Supplier Technical Assistance Involvement
Supplier's Trustworthyness
Information Sharing
Location of Facilities
Flexbility and Responsiveness
Reinforcing/Extending Supplier Relationship
Number of Competitive Suppliers
Customer Proximity
Interaction with Systems Testing, Quality &Mfg
Incorportation of lessons learned
Product Performance
Component Performance Metrics
Part Cost and Timing vs. Objectives
Alignment
A
G
A
A
A
A
M
A
A
G
A
A
A
G
M
G
G
A
M
A
M
A
A
A
A
G
A
G
A
G
A
A
Decision Rule DRIV:R
Corporate Uoals
Shareholder Value
OEM Organizational Infrastructure
Customer Satisfaction
Functional Goals
Department Goals
Local / Department Traditions
Personal Goals
Rewards / Opportunities
Internal Growth Opportunities
Work-Life Balance
Employee Satisfaction
Alignment
A
A
A
A
A
A
M
G
A
M = Misalignment between Enterprise and Front Level Engineering
G = Alignment Gap between Enterprise and Front Level Engineering
A = Alignment between Enterprise and Front Level Engineering
Following the alignment evaluation rigor as described above, the alignment pattern for the organization analyzed looked as described in Figure 16. Cross-tabulation tables underlying these results can be reviewed in Appendix D.
It appears that the organization is largely aligned with respect to decision rule drivers. Hence, survey respondents from both organizational populations placed very similar importance on all
50

functional and personal goals analyzed. Furthermore, the corporate goal 'customer satisfaction' appears to be cascaded across the organization.
However, the organization analyzed is misaligned with respect to shareholder value (Figure 17) and an alignment gap exists for organizational infrastructure (Figure 18).
Figure 17 - Shareholder Value Misalignment
8-
C
0
Cu
0
35
30
25
20
15
10
5
0
50
45
40
Example oT MISALIGNMEN I
NO LOW
Priority Level
MEDIUM
B
Enterprise Level Management
HIGH
0 Front Line Engineering
While 50% of the enterprise personnel put a medium to high priority on shareholder value when making supplier sourcing and selection decisions, only 18% of the front level engineers do so when making product execution decisions. Thus, enterprise level executives are more closely aligned with the shareholder value corporate directive than front level engineering teams analyzed. Since new investment is the lifeblood of any organization, one would expect a much higher percentage of enterprise level personnel to place a high priority on shareholder value.
Enterprise level employees in this research, however, are leaders at the PD organization level
(i.e. Powertrain Organization). Therefore, there is cascade inefficiency from the corporate enterprise level that requires further definition of what shareholder value means even to the leaders in the Powertrain Organization. Moreover, as expressed in chapter 2.4.1 and 2.4.3, the sample size is low, but the data findings are significant given that the survey participants experience level averaged greater than 20 years in relation to the subject matter in question.
51

60% of the enterprise level respondents do not place any priority on organizational infrastructure when making strategic component sourcing and supplier decisions. On the contrary, only 39% of the front line respondents place no value on infrastructure concerns when making product execution decisions. Given that front line engineers deal deeply with procedural work that involves honoring of organizational structures, they are more sensitized to the infrastructure of the organization.
Figure 18 - Organization Infrastructure Alignment Gap
R*
0
30
20
10
0
70
60
50
S40
Example of GAP
NO LOW
Priority Level
MEDIUM
U Enterprise Level Management
HIGH
0 Front Line Engineering
In terms of decision rules, statistical analysis of the survey suggests that the organization is mostly aligned during supplier selection and product execution decision-making events.
Decision rules that show a misalignment or alignment gap require further analysis.
One alignment gap appears in the competition decision rule category, namely the quality of competitive products (Figure 19). While both organizational groups make decisions by applying medium importance to competitive product quality, the alignment gap becomes noticeable when comparing each priority level between front level and enterprise respondents. For instance, half of the enterprise survey population but only a quarter of the front line engineers assign low priority, when using competitive product quality as decision rule during decision-making events.
Furthermore, viewing the distribution of enterprise respondents along the four priority levels
52

indicates same misalignment with the same population of people. Given the limited sample size, one will have to gather more data for further analysis.
Figure 19 - Quality of Competitive Product Alignment Gap
60
50
40
C
2
30
0.
0L
20
10
0
Example of GAP
NO LOW
Priority Level
* Enterprise Level Management
MEDIUM
I
HIGH
0 Front Line Engineering
The organization is fairly well aligned in the product complexity decision rule category. But, there are alignment gaps within some decision rules, namely "Number and Type of Functional
Interfaces" (Figure 20) and "Number of Programs" (Figure 21). As enterprise level executives are not as involved in the detailed system engineering work as front level engineers are, their recognition and understanding of functional interfaces is not prioritized as high. Only 20% of the enterprise people assign a medium to high importance to functional interfaces when making sourcing decisions. Given the extremely high integrality of engine components to the engine and powertrain system, this fact is surprising if not disturbing.
53

Figure 20 - Number and Type of Functional Interface Alignment Gap
60
50
40
C
0L
0
CL
30
20
10
0
Example of GAP
NO
LOW
Priority Level
E Enterprise Level Management
ME
EDIUM
HIGH
0 Front Line Engineering
40% of the enterprise level respondents did not assign any importance to the number of engine programs a during engine component sourcing events. Apparently, the number of engine programs has no or limited bearing during component outsourcing or supplier selection decision-making. Given the complexity of managing and engineering the same component used in several engine programs, only 17% front line engineers answered no priority for this decision rule.
Figure 21 - Number of Programs Alignment Gap
C
0
0L
0
30
25
20
50
45
40
35
15
10
5
0
Example of GAP
NO
LOW
Priority Level
MEDIUM
*Enterprise Level Management
HIGH
0 Front Line Engineering
54

Within the internal capability decision category the level of misalignment between enterprise and front line respondents is significant.
While almost 40% front level engineering respondents regard internal knowledge and expertise with high priority when making decisions in product development, none of the enterprise respondents place high priority on this decision rule when making sourcing decisions (Figure
22). Thus, there is a significant misalignment. While front level engineers are invested in their knowledge, enterprise level decision-makers appear to not value that fact during sourcing decisions. The following quote voiced during interview sessions by an enterprise level leader underlines this dichotomy: " Outsourcing and R&R (roles and responsibilities) changes reduce engineering attitudes. Now they have to manage a supplier. Attitude issue figures in little into the decision. We (enterprise level) assume it's going to be handled. Local management has to deal with impacts of design and development intensity on engineering attitude." Apparently, the human element is disregarded during outsourcing decision-making and this introduces intangibles that cannot be expressed in time and money. While the underlying truth of outsourcing is migration of engineering work to the supply base, front line engineers' knowledge base and appreciation is at risk. This misalignment between enterprise level and front line engineers produces tensions that need to be addressed.
Figure 22 - OEM's Knowledge and Expertise Misalignment
60
50 o 40
30
20
0~
10
Example of MISALIGNMENT
NO LOW
Priority Level
MEDIUM
* Enterprise Level Management
HIGH
0 Front Line Engineering
55

Figure 23 - WCR, DVP&R, FMEA Adherence Misalignment
60
50
40
0
0
0
a. 20
10
0
Example of MISALIGNMENT
NO LOW
Priority Level
MEDIUM
U Enterprise Level Management
HIGH
0 Front Line Engineering
Strong misalignment is also apparent in the WCR, DVP&R, and FMEA adherence decision rule
(Figure 23). While very important to product execution decision-making, enterprise level respondents placed less importance on that dimension during outsourcing or supplier selection decision-making. Sixty percent of the enterprise level respondents placed low or no priority on this decision rule. In contrast, 79% front level engineers considered this rule with medium or even high importance when arriving at decisions during product execution. Given that with outsourcing a supplier would need take over some of these key disciplines, the questions becomes whether this difference in focus that executives and front line engineers place on this decision rule could become an inhibitor to product success.
Similar to the internal capability dimension, the degree of non-alignment is rather high in the supplier capability decision rule category. While responses to the decision rules "supplier manufacturing assets" (Figure 24), "number of other OEM's supplier supplies" (Figure 25), and
"level of supplier responsibility" (Figure 26) indicate an alignment gap, the decision rule "supplier component knowledge" (Figure 27) shows misalignment between enterprise and front line levels in the organization. Supplier's component knowledge presents an area of conflict for front line engineers. While they value the supplier being knowledgeable, supplier knowledge increases will even further reduce the internal team's ability to practice engineering. Thus, a personal driver may reduce the importance that front level engineers place on the suppliers' knowledge when making decisions during the product execution phase. All enterprise level respondents surveyed indicate either a medium or high importance to supplier component knowledge when
56

making sourcing decisions. Here again surfaces what was expressed previously. Enterprise and front level engineers are at odds with each other with respect to both supplier and internal knowledge decision rules.
Figure 24 - Supplier Manufacturing Assets Alignment Gap
40
C
0
30
0 a_
20
60
50
10
0
Example of GAP
NO LOW
Priority Level
MEDIUM
E Enterprise Level Management
HIGH
0 Front Line Engineering
Figure 25 - Supplier's Component Knowledge Misalignment
Example of MISALIGNMENT
60
50 1
40
80
C
0
0
0-
30
20
1
10
0
NO
F
H
LOW
Priority Level
MEDIUM
E Enterprise Level Management
HIGH
0 Front Line Engineering
57

Figure 26 - Number of Other OEM's Supplier Supplies Alignment Gap
0
CL
45
40
35
30
25
20
15
10
5
0 ii
Example of GAP
U
1 1
HI
NO LOW
Priority Level
MEDIUM
N Enterprise Level Management
HIGH
0 Front Line Engineering
Figure 27 - Level of Supplier Responsibility Alignment Gap
C
Co
0
30
20
10
50
40
0
70
60
Example of GAP
NO LOW
Priority Level
MEDIUM
E Enterprise Level Management
HIGH
0 Front Line Engineering
Since front level engineers are measured by how well they achieve cost and timing objectives, they place significantly more importance on cost and timing constraints when making product development decisions than enterprise respondents when making sourcing decisions. Both organizational levels are aligned in terms of recognizing the importance of the customer as evidence not only in the customer proximity, but also in the customer satisfaction dimensions.
58

Figure 28 - Part Cost and Timing vs. Objective Alignment Gap
40
CL
0.
0-
30
20
10
70
60
50
0
0
CL
50
45
40
35
30
25
20
15
10
5
0
Example of GAP
NO
LOW
Priority Level
MEDIUM
U Enterprise Level Management
HIGH
0 Front Line Engineering
Figure 29 - Number of Competitive Suppliers Misalignment
Example of MISALIGNMEN1
NO LOW
Priority Level
MEDIUM
M Enterprise Level Management
HIGH
0 Front Line Engineering
-I
59

Figure 30 - Supplier Technical Assistance Involvement Alignment Gap
8 40
C
0 n~ 30
02
0
20
60
50
10
0
Example of GAP
NO LOW
Priority Level
MEDIUM
U Enterprise Level Management
HIGH
0 Front Line Engineering
Within the supplier proximity decision rule category (see Figures 29 and 30), a misalignment was discovered for the decision rule 'Number of competitive suppliers' and an alignment gap for the decision rule "Supplier technical assistance involvement'.
The following charts summarize the decision rule driver (Figure 31) and decision rule (Figure
32) rankings derived from both front line and enterprise level decision-maker surveying. These charts illustrate how decision rules and decision rules drivers vary across the organizational hierarchy. Highlighted rows in the figures indicate areas of misalignment for organization analyzed.
Figure 31 - Decision Rule Driver Importance Rankings
Decision Rule Driver
Customer Satisfaction
Department Goals
Shareholder Value
Local/Department Traditions
Internal Growth Opportunities
Rewards / Opportunities
Employee Satisfaction
OEM Organizational Infrastructure
Work-Life Balance
Importance Ranking
EP Level
1.0
2.0
3.0
2.0
5.0
6.0
7.0
8.0
9.0
FL Level
1.0
2.0
5.0
3.0
7.0
8.0
6.0
4.0
9.0
60

Figure 32 - Decision Rule Importance Rankings
Decision Rule
Suppliers Component Knowledge
Suppliers Cost & Timing
Information Sharing
Cost & Timing Objectives for Component
OEM Resource Burden
Supplier's Trustworthyness
Cost & Timing Competitors Component
Flexbility and Responsiveness
Level of Change
Number of Functional Requirements
ComponentPerformance Metrics
Number of Competitive Suppliers
Maintaining/Building In-House Capability
Part Cost and Timing vs. Objectives
Supplier Manufacturing Assets
WCR, DVP&R & FMEA Adherence
Reinforcing/Extending Supplier Relationship
Functional Performance of Competitors Product
Interaction with Systems Testing, Quality &Mfg
Number of Different Supplier associated with Part
OEM's Knowledge & Expertise
Number of other OEM's Supplier supplies
Incorportation of lessons learned
Location of Facilities
Number & Type of Functional Interfaces
Number of Programs
OEM Process Discipline
Number of Part Numbers
STA Involvement
Importance Ranking
:P Level
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
27
28
29
30
31
32
21
22
23
24
25
26 l-L Level
1
7
11
2
12
4
2
14
6
18
17
15
10
8
21
19
3
9
16
23
25
24
30
26
32
28
20
27
22
13
29
31
61

2.4.5 Reliability Analysis
When developing the survey we made assumptions about how decision rule categories can be decomposed into more pragmatic decision objectives. Using reliability analysis, one can determine the extent to which pragmatic decision rules are related to each other with respect to survey results. Thus, with statistical reliability, one can get an overall index of the repeatability or internal consistency of each decision category as a whole, as previously defined (see Figure
10). The reliability analysis using a priori category definition as detailed above yielded the following findings:
Figure 33 - Decision Rule Category Reliability (initial)
Full scale =1.0
0.478
0.748
0.781
0.755
0.765
0.636
0.601
Figure 34 - Decision Rule Driver Category Reliability (initial)
Full scale =1.0
0.787
The reliability coefficients Alpha in above figures expresses a measure of internal consistency, based on the average inter-item correlation. An Alpha close to or larger than 0.7 indicates, that decision rule variables within a decision rule category are consistent.
Further analysis of the decision category Internal Capability indicates that by eliminating the decision rule "Internal Resource Capability", we can increase the Alpha coefficient to 0.679, which is an acceptable reliability for that category. The categories "Functional and Corporate
62

Goals" are not internally consistent. Additional analysis could not achieve further improvement in decision rule and decision rule driver sets. Thus, the final sets were as follows:
Figure 35 - Decision Rule Category Reliability (Final)
Full scale =1.0
0.679
0.748
0.781
0.755
0.765
0.636
0.601
Figure 36 - Decision Rule Driver Category Reliability (Final)
Decision Rule Driver
Full scale =1.0
Reliability Coefficient
0.787
2.4.6 Product Outcome Correlations
In order to develop success and failure relationships between enterprise level outsourcing and front line level product execution decision rules, actual component specific warranty data was correlated qualitatively to the following product outcome scale:
* Significantly degrading warranty performance = 1
* Degrading warranty performance = 1.75
* No change in warranty performance = 2.5
* Improving warranty performance = 3.25
" Significantly improving warranty performance = 4
63

Here, the component warranty performance just before outsourcing or supplier selection and its development over a three-year life span just after that pivotal decision, were compared. General decision rule driver and decision rule to product outcome correlations are depicted in Figures 37 and 38 respectively.
Decision rule drivers don't correlate to product outcome for front line execution decisions. Thus, corporate, functional, and personal decision rule drivers analyzed don't correlate to product outcome on the front line. If applied during enterprise level decision-making personal goals seem to correlate negatively to product outcome. Functional decision rule drivers don't correlate to product outcome if used during enterprise level outsourcing. While shareholder value focus does not appear to correlate with product outcome, customer satisfaction focus appears to have a positive impact on product outcome.
Figure 37 - Decision Rule Driver to Product Outcome Correlation
Decision Rule DRIVER
Corporate Goals
Shareholder Value
OEM Organizational Infrastructure
Customer Satisfaction
Functional Goals
Department Goals
Local / Department Traditions
Personal Goals
Rewards / Opportunities
Internal Growth Opportunities
Work-Life Balance
Employee Satisfaction
Product Outcome Correlation
Enterprise Front Line n/a
NO
NO
+ n/a
NO
NO
NO
NO
NO
NO
NO
NO n/a
NO
NO
NO n/a
NO
NO
NO
All decision rule categories investigated either correlate positively or do not correlate to product outcome when applied during enterprise outsourcing and/or supplier selection decisions. With the exception of OEM resource capability, decision rule categories surveyed appear to have either no effect or a positive effect on product outcome when applied during product execution decision-making. OEM resource capability does not correlate on the enterprise level, but correlates positively when used during front line decision-making. We would like point out that the front line decision rule correlations came out negative for the decision rules categories
64

'Competition', OEM Resource Burden', 'Internal Capability', and ' Supplier Capability' and related sub decision rules. However, follow-up interviews with several front line lead engineers confirmed that in reality they are correlated positive to product outcome performance. The question becomes why this discrepancy occurred? We explain these phenomena due the differences in the way that the enterprise level and front line level framed the survey question.
Early in the program when enterprise level leaders make sourcing or supplier selection decisions they value the positive downstream effects that a knowledgeable supplier has and they probably are going to select the most capable supplier. If enterprise level leaders understand supplier capability they make their decisions based on the correlation to quality and they will choose a supplier that improves quality. Front line engineers however deal most closely with problem suppliers in a constant fire-fighting mode. The front line level team establishes high level of knowledge about the supplier capability when things go wrong. They gain expertise
by working on programs with poor performance, a filtered learning about supplier capabilities.
Hence, they tend to have a skewed vision leading to potential deterioration in supplier relationships in general. This finding is in line with initial qualitative interview findings where interviewees most often focused their comments around supplier non-capabilities. Similar negative comments were expressed specific to the decision categories 'Competition', 'OEM
Resource Burden', and 'Internal Capability' as well.
65

Figure 38 - Decision Rule to Product Outcome Correlation
Decision Rule
Competition
Quality Competitive Product
Cost & Timing Competitors Component
Functional Performance of Competitors Product
Product Complexity
Level of Change
Number of Part Numbers
Number of Different Supplier associated with Part
Number & Type of Functional Interfaces
Cost & Timing Objectives for Component
Number of Engine Programs
Number of Component Functional Requirements
OEM Resource Burden
Internal Capability
OEM's Knowledge & Expertise
Maintaining/BuildingIn-House Capability
WCR, DVP&R, FMEA Adherence
Product Development Process Discipline
Supplier Capability
Supplier Manufacturing Assets
Suppliers Component Knowledge
Supplier's Quality
Suppliers Cost & Timing
Number of other OEM's Supplier supplies
Supplier Resonsibility
Supplier Proximity
Supplier Technical Assistance Involvement
Supplier's Trustworthyness
Information Sharing
Location of Facilities
Flexbility and Responsiveness
Reinforcing/Extending Supplier Relationship
Number of Competitive Suppliers
Customer Proximity
Interaction with Systems Testing, Quality &Mfg
Incorportation of lessons learned
Product Performance
Component Performance Metrics
Part Cost and Timing vs. Objectives
Product Outcome Correlation
Enterprise Front Line
+
NO
+
NO
NO
NO
NO
NO
NO
NO
NO
+
+
NO
NO
NO
+
+
NO
NO
NO
NO
+
+
+
+
NO
NO
NO
+
NO
NO
NO
NO
NO
NO
NO
NO
+
+
+
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
66

3.1.1 Research Intent
The qualitative research intent can be summarized as follows:
* Identify decision rules that influence product outcome
" Derive causal relationships between decision rules
* Establish causal loop structures
" Expose leverage variables and recommend corrective actions
" Identify qualitative differences between organizational levels for a given component
Consistent with the quantitative research discussed, the qualitative portion of this study concentrates on eliciting decision rules exercised during supplier sourcing and/or selection and product execution. It is assumed that the identified decision rules impact product outcome, such as product quality and performance, in some way. Furthermore, the research makes the assumption that individual decision rules interact with each other resulting in a system of parameters that ultimately interrelate with product outcome in a multifaceted fashion. This research is intended to expose this system of relationships. Once this system is identified, system analysis should highlight reinforcing variable loop structures that can cause system imbalances, such as downward spirals, adversely affecting product outcome. Furthermore, system analysis needs to illustrate balancing loop structures that can cause alternating product outcome performance. Ultimately, the intent is to identify decision rules within the loop structures and decision rule relationships that when changed or intervened by exogenous factors can create enough leverage to help improve system behavior. Given that product development decisions in the OEM-Supplier network are conducted on different organizational levels, qualitative decision rule differences between organizational levels can have an impact on product outcome. These should be compared and contrasted between the supplier sourcing and selection enterprise level decisions and front line product execution decisions.
3.1.2 Research Preparation and Planning
The qualitative research preparation and planning resulted in the following critical choices. The first consisted of choosing the qualitative data gathering method, interview or focus group research. The recognized strengths and weaknesses of interviews include:
" Face to face interaction
* Experience the interviewees world
" Understand interviewees thinking
67

* Firsthand information
" Instability and imprecision due to small sample sizes
" Interviewer biases
Similarly, we recognized the following strength and weaknesses of focus group research:
* Interviewee interaction established capacity to provokes and produces synergy effects
* Group unification and polarization
* Capacity to research larger population at once, however, with less air time per person
Since the analysis was geared around component case studies, we ultimately decided to take the approach to use both interviews and focus groups. We studied the product performance and team synergies of nine specific component cases over the past 10 years. We first identified employees in the subject organization that spent the past 10 years entirely either within front line engineering teams or serving as enterprise level decision-makers (for particular components). Due to career advancement and other career moves the population size was somewhat restricted. We managed to conduct front line level engineering focus group interviews with a minimum of three to five engineers per component. Individual interviews were conducted with one enterprise level executive component. In order to achieve triangulation between research methods, interview and focus group participants were the same individuals as those who participated in the surveys. Since interviewees and focus group members are employed by the organization studied, they have a vested interest in the organization. As a result, we felt that many participants may be apprehensive about speaking the truth. Therefore, we decided to take notes rather than tape recording any of the sessions. In all interview sessions both authors, and is and sometimes even a third party, took interview notes. While one interviewer focused on leading the conversation, the other interviewer(s) listened for important decision rules and organizational behaviors. In addition to the standard interview guide principles described above, the following interview techniques were exercised in order to develop trust and to open communication channels:
" Pre-interview discussions
* Boundary objects
" Identification of key product development variables
" Systems dynamics data gathering procedures
68

3.1.3 Pre-Interview Discussions
Prior to actually conducting the interviews or focus group discussions, we sought to have faceto-face conversations with the participants to discuss our thesis proposal. We did not explicitly discuss the problem statement we were trying to address, but rather were seeking to open up a line of communication so that the participants felt comfortable speaking with freely with us, and so that they knew they were sought out as local component experts. This early discourse allowed us the capacity to improve and better tailor the survey and interview questions.
3.1.4 Boundary Objects
We applied boundary object theory throughout the interviews and focus group sessions.
Boundary objects, a term developed by Carlile'
2
, are effective in dealing with problematic knowledge boundaries. When effective they establish a shared method for individuals to represent their knowledge. Furthermore, they can provide a concrete means for individuals to specify their differences and dependencies. And they are able to facilitate a process for individuals to transform knowledge.
The first boundary object we applied was the survey as outlined above. In order to instill awareness and reflection prior to the sessions, we handed each participant a survey about the subject matter prior to the sessions. We asked each participant to complete the survey prior to the session. After a general introduction into the thesis research, each interview and focus group session was initiated by questions about the survey. Given that people had invested time into filling it out, they came back with clarification questions, made comments about other questions they might have asked themselves while taking the survey, and provided explanations why they answered survey the way they did. The survey not only gave each participant an opportunity for a mental introduction into the subject matter, but more importantly, it relaxed and opened the knowledge boundary between the interviewers and interviewees.
The second boundary object applied was the following problem statement:
"Ever since we started outsourcing engine components, some components have improved, but others have either not improved or perform worse in warranty. We believe that the recent spike
1Carlile, Paul. Organizational Behavior and Processes. Class Notes. Cambridge, MA: MIT, January 6, 2000.
2
Carlile, P. A Pragmatic View of Knowledge and Boundaries: Boundary Objects in New Product Development.
Working Paper. Cambridge, MA: MIT, August 15, 2000
69

in warranty is due to supplier outsourcing and we are concerned to not completely understand the systems dynamics. What can we do to achieve the HOPE curve?"
Following the presentation of the boundary object (product outcome graph - see Figure 39), the following questions were asked:
" Think again about the organization's Quality Performance with respect to MY94 until MYQO:
* Describe the variables that could be related to the engine quality improvement through
MY98?
* What variables do you think may have caused engine quality to spike up?
" How likely is the FEAR curve and why?
" What can your organization do to achieve the HOPE curve and why?
Figure 39 - Product Performance Graph As Boundary Object
Warranty k
Today
Fear
0
Model Year
Hope
.................................
Given the long-term experience in the organization, each participant was very familiar with the warranty curve shown and had a general understanding of component outsourcing during the period depicted. We intentionally did not ask about the specific component that the team was ultimately responsible for. While interviewees knew that their component was part of the
70

warranty performance, they did not feel attacked by our line of questioning as their component performance was somewhat hidden in the graph. While the communication channels further opened, above-mentioned reference modes and questioning provided a general understanding about organizational history and in most cases a good understanding about dynamics in specific component engineering areas. Thus, generic observation and events, such as reorganizations or cost reduction efforts, were highlighted to us. This boundary object was a very powerful tool for opening up communication with engineers. First, it indirectly correlated product performance with component outsourcing. As each engineer has strong feelings about the engineering work being taken away from them, they have even more interest in sharing their thoughts, sharing how their roles and responsibilities were affected. Secondly, the warranty graph established a common frame of reference that both interviewees and interviewers were familiar with. Thus, there was a shared medium that both parties could refer to during the conversation.
After having established a common frame of reference and some level of trust, the conversation entered into a component based discussion. Here we applied a third boundary object, again a graph that is known and understood by the engineering team - component warranty history. We asked engineers to qualitatively draw Repairs per Thousand (R/1000) curve as a function of time visible to all session participants. An example is depicted in Figure 40.
Figure 40 - R/1000 Graph As Boundary Object
Warranty
71
Model Year

Then we asked participants to think about the history about their specific component from the early 1990's until 2001 and went through the following line of questioning:
* Describe some of the key events that happened in that timeframe. Key events could be organizational changes, corporate goal changes, functional directives, component strategy changes, supplier outsourcing, or other events.
* Tell us about the point in time when you would consider you component being outsourced.
How would define outsourcing with respect to your component?
" Please describe the time before your component was outsourced?
* Can you tell us what changed after the component was outsourced?
" Describe some of the events, decision rules, or other parameters that in your opinion let to successes with respect to your component. And why?
" Imagine your component in the future. It meets all functional requirements and can be produced at very affordable cost. Describe some of the actions that you would have put in place to achieve this performance.
While answering the questions, session participants referred to the component warranty history curve on a regular basis. Thus, by establishing the reference mode "component warranty curve" and "component history in the last ten years" before asking the questions, provided interviewees something to compare and contrast with mentally before answering or discussing the questions posted to them.
In summary, boundary objects applied helped interviewees to triangulate between their experience, a mode of reference and their answer to questions. Thus, reference modes helped interviewees to transfer their experience across something known by both interviewees and interviewers.
3.1.5 Identification of Key Product Development Variables
The last portion of the interview varied from the first set of interviews and focus groups, to the last set. In initial front line level focus groups and enterprise level interview, we listened specifically for key causal parameters that might explain the component performance in the past ten years. After writing these parameters down, the session would conclude with the following:
"Throughout our discussion thus far, we have heard you say that the following parameters are important in order for one to understand your component's historic performance and future strategies. They are as follows: ... (the full list of variables from the interview sessions can is depicted in Appendix G).
72

Given the list of parameters mentioned throughout the interview, we continued with the following line of questioning:
* Please choose six parameters that you think are the most important?
* Could you plot its values qualitatively since MY94 until MYO1?
* Why do you think the parameters behave like they do?
* How do you think those parameters will develop in the future? Why?
As a result of the interview strategy using boundary objects, we collected quotes that discussed relationships between key parameters. In summary, boundary objects, open ended questioning, asking why, and asking positive questions encouraged the session participants to willingly share information. After conclusion of the first two front level focus groups and enterprise level interviews, we analyzed the transcription data and identified key variables that were repeated in all sessions. The list of those variables is depicted in Appendix H.
During the next set of sessions we dropped the identification of the parameters in favor of asking participants to establish causal connections between the key parameters developed in earlier sessions. Thus, we introduced the list of key variables to interviewees and focus group participants and asked the following questions:
" From your components perspective, are there variables that you would like to add to above list?
* For most variables: o Describe how this variable impacts product outcome. Why? Why? Why? o How would you increase/decrease the value of this variable for a better product outcome in the future? Why? Why? Why? o Describe how do other variables in above list impact this variable? Why? Why? Why?
3.1.6 Systems Dynamics Data Gathering Procedures
We focused the final interview and focus group on establishing relationship loop structures that would support the systems dynamics modeling efforts. Our intent was to achieve verification of the developed cause and effect relationships.
73

3.1.6.1 Loop Development Process
Each interview was transcribed to further deepen the interview information and to collect and add thoughts that one had remembered but could not capture in real- time. The second interviewee then modified the initial transcripts when things were understood differently. After key parameters were identified in the first interviews, causal loop were then development during subsequent interviews. Each transcription statement typically represented a 1:1 relationship between parameters. Given that those relationships were mentioned at least twice in independent interviews, these relationships were added to the loop structure.
3.1.6.2 Causal Relationships
The causal relationship diagram shown in Figure 41, illustrates how the research participants perceived the dynamics of the organization. The arrows indicate the direction of influence. The
'+' sign indicates that an increase in the causal variable at the beginning of the arrow, has a positive impact on the effect variable at the end of the arrow (or similarly, negative to negative).
One might say that this causal loop diagram represents the way the organization functions based on a sample population with reasonable experience working in the organization.
74

Figure 41 - Dynamic Causal Loop Structure
1.cycl-I~a
C a e i he red
.t tiht e to be eprs o o r i Tr en verifie dith o upph"lierCpitility r
I ternalvallrl I')dF'mn c tanscrpions.Witho explainal rlatyon
)hiy in da w li I-e hnvenmen in ii P-usom-
(AvqereTim two r treefocs grupsorntevies. Inple rk
cassineriew unt.P cc iR nuRd i noldgo relatonshp isgrouded n atleas onequot extacte fmt nintervoiewan ocsgru
Causal~~~~~~~~~~MI- rea'nhplwraeye.fo omnsthtnee o eepesd vra es
Nuwob or he
(Iw n ra tinhis ocsgop getting
Thos, o neviw.I om ettydiy ae, pr wer Worn veiLeaih tegrsachpricpns.Ec cua neve priianscntuce hi the decision li rulemn ineoisid niid
{Average
~~~~
"Cotinityin ngieerng s vry mportnt.Aftruyo getting petty good scre
~ ~ iu oe o w rjcs o r
75

"In the last 2.5 years we've had 3 managers (we go through them at a rate of I per year). We lost our technical expertise. Engineers are moving on and we're replacing them with younger, inexperienced people."
(New Hire Quality =>Motivation to Stay}
"We have always tried to hire all the graduates with best qualifications. But, they never failed in their life. Of course, those are the ones that want to advance. They are not likely to stay for 3 years in a component job. They want to be promoted"
{Product Complexity => Supplier Burden}
"Over the years, we demanded more and more from the supplier; such as extended reliability for alternative fuels."
"Number of engine programs has an effect on (product) performance but less than non-value engineering does. It is a big burden on suppliers though - to meet demands."
(Upfront Planning => Reward)
"We will do anything to get it right when there is a crisis. Wish we could recognize people when things are going smooth."
"How many times have you heard 'I'm not sure if they are ready to move on yet, they are awfully quiet."
(Value Engineering => Employee Satisfaction}
"Cultural impact is a significant morale issue. People with 2 masters degrees who love engineering may spend all of their time on e-mail, presentations and meetings. They go home at night without feeling that they have added value. PhD's may spend 80% of their time as paper pushers. They thought they were here to work on motors."
"Outsourcing and R&R change reduces engineering attitude. Now they have to manage a supplier. Attitude issue figures in little into the decision. We (enterprise level) assume it's going to be handled. Local mgmt has to deal with engineering attitude impacts on design and development performance."
(Value Engineering => Technical Knowledge)
"When design and manufacturing was done in-house, it wasn't a perfect system but engineering knew through experience, effects on other components."
All other relationships that underlie the construction of figure 41 are illustrated in Appendix 1.
76

3.2.1 Background
Because the strengths and weaknesses of humans and machines are most often complementary, we chose to develop a dynamic model to simulate the system of relationships constructed through interviews in the previous chapter (refer to Figure 41).
Although humans are not well suited to the memorization of minute detail, they have great strength in remembering meaning. But this strength can become a weakness. Years of physiological experiments show that people are very efficient in fitting incoming information into existing knowledge. (Why reinvent the wheel every time?). Generally, this results in better memory and faster decision making-a strength. The inevitable weakness is that humans tend to see patterns and fill out pictures that may not be there. The strength of models, however, such as their rigorous consistency and reliance on historical data, can also be a weakness. In dynamically changing decision environments, models built upon historical data may become obsolete before they can be implemented. Models are sometimes impractical because it may be too costly to build a forecasting system for many situations that are unscalable 3
System dynamics modeling is a methodology for understanding and managing complex systems of relationships, especially those with feedback circuits. Feedback here refers to element A affecting B and B in turn affecting A, perhaps through a series of other cause and effect relationships. One cannot examine individual elements of the system independently but rather only the study of the whole system will lead to correct results. The authors contend however, that the model presented in no way represents a complete view of the OEM-supplier relationship. Not only is it not possible to know/understand, all the variables in a given system, let alone model them, we are faced with the fact that those constructing the model (through interviews) are limited by what Simon calls "bounded rationality"
38
. Bounded rationality is based on the premise that human minds are limited in their capacity and hence can only understand an approximate picture of their world. Thus, the model can only be as detailed as the rationality used by the decision makers interviewed.
Due to the competitiveness and risk of commoditization in the automotive industry, it has become essential for automotive manufacturers to constantly innovate to gain competitive
3
Hoch, Stephen J., Combining Models with Intuition To Improve Decisions. John Wiley and Sons, Inc., 2001.
38 Simon, Herbert A., An Empirically Based Microeconomics, Cambridge University Press, 1997.
77

advantage and increased profitability. Analytical tools, manufacturing efficiencies, process control, quality hires, and investment in internal capabilities have become an important part of the business from strategic planning to final production. As business competition continues, automotive companies seek new innovations and external capability from suppliers in order to enhance their development processes and reduce operation costs. The hope is that these supplier partnerships will ultimately reduce business risks and offer a competitive advantage.
Due to the complexity involved in understanding the entire automotive OEM-supplier relationship, the systems dynamics potion of this thesis does not attempt to map and develop entire system, but rather maps the system as described to us by individuals within one OEM organization. Specifically, the systems dynamics model herein, was developed by front line and executive level engine component engineers from interviews and focus groups as described in the Qualitative Research portion of this paper. The challenge is in designing the relationships between each internal and external interface, as it is necessary to consider many factors, such as product development practices, existing culture, perceived and actual benefit, corporate and employee goals and objectives, technical and physical capabilities, competition and the economic landscape. It should be understood that the authors did not attempt to build the organizational relations ships based on their own experiences (outside of the organization), but rather relied on the interviewees to develop the map through the interview process.
The modeling methodology used in this thesis involved the steps defined below. It should be understood that as the model developed, there was much iteration between individual steps.
" Identify problem
" Develop cause and effect relationships through investigation and interviews
" Build computer simulation model of the system
* Test model against known real world behavior
" Devise alternative policies and test effect on system behavior
* Recommend alternative policies to system response
3.2.2 Problem Identification
As previously described in the Qualitative Research section, the problem identified was developed from statements heard time and time again within the powertrain/engine organization. The underlying issue was that the organization had realized that over the past ten years, there were varying degrees of component qualitative and varying degrees of supplier outsourcing. Some individuals within the organization had reason to believe that product performance (measured as quality) was a function of the level of supplier outsourcing. What
78

was of particular interest to the organization was an understanding of the correlation between the decisions made, in regards to outsourcing and product performance, and recommendations on what policies the various component activities could put in place to improve and sustain product performance at a level that meets objectives and defines industry leadership.
3.2.3 Cause and Effect Relationships
The intention of this study was to use the cause and effect relationships developed in the
Qualitative Research section as the basis for the dynamic system. The network of cause and effect relationships developed has the following general characteristics: tangible and intangible, inter-company, inter-functional, dynamic and evolutionary.
3.2.3.1 Tangible/Intangible Relationship
Research by Cutcher-Gershenfeld et al. 3
9
, describes how team-based work systems demonstrate both tangible and intangible interactions. Examples of tangible process components may include the generation of work, headcount, analytical tools, changes in product performance and achievement of goals. Intangible process components might include the way that work generation adds to a shared knowledge base, how trust is built amongst various stakeholders or a manager's vision or leadership qualities.
Figure 42 - Tangible/intangible Relationship Loop
? -
Up ont Planning
Tangible/Intangible
Relationship
Tools
Stong Management
Vision/Leadership
Reworl
Internal Capability uct Outcome
Figure 42 depicts the relationship between tangible variables, such as tools and product outcome are intertwined with intangible variable such as strong management vision/leadership and upfront planning.
39 Cutcher-Gershenfeld, Joel et al., Knowledge-Driven Work. Oxford University Press, 1998.
79

3.2.3.2 Inter-Company Relationship
The system not only simulates the capabilities and practices of the home organization, it also evaluates similar characteristics at the supplier (external company) organization.
Figure 43 - Inter-Company Relationship Loop
Level of
Partnership
Inter-Company Relationship nowledge of
Supplier Ability
Alignment of Supplier
Motivation to Ford
Motivation +
Trust + Supplier Discipline
Supplier esource
-
Burden
Internal Capability
The loop above is an example of how internal strengths within the home organization reduces resource burden at the supplier. Both of these elements play a role in developing trust and the level of partnership across both organizations. Thus, one organization cannot operate independent of the other (system changes effect both internal and external companies).
3.2.3.3 Inter-Functional Relationship
The OEM-supplier relationship modeled not only looks at the exchanges and activities across company boundaries, it also deals with the product and information exchange across the home organization's departmental boundaries.
80

Figure 44 - Inter-Functional Relationship Loop
Motivation to Stay
Number of
Programs
(Unique D esigns)
Product
Complexity
+ +
Interna Resource
Burden
+
Cascade
Inefficiency
Inter-Functional
Relationship
-
Knowledge o
Customer
Average Time on
Jo b
The above loop depicts relationships between the home organization's departments. The number of programs taken on effects all departments and thus, effects the cascading of information between organizations (across functional chimneys and up and down hierarchical levels within the company) and internal resource burden.
3.2.3.4 Dynamic Relationship
Because the supplier relationship extends beyond the physical boundaries of the OEM
Company, it inevitably involves extensive cause and effect interactions, time dependencies, and net performance improvement or deterioration.
Interna
Capability
Figure 45 - Dynamic Relationship Loop
Dynamic
Relationship
Internal e
Discipline+
Motivation to Stay
Average ime on
Job
New Hire Quality
Product
Outcome
Strong Ma nagemen
Vision/Le adership
Technical
Knowledge
81

Figure 45 above is one example that illustrates the dynamic nature of the system. As average time on the job increases, so do technical knowledge, strong management and internal discipline. However, new hire quality and motivation to stay will decrease, which causes a change in average time on the job. This change then effects a change in strong management and internal discipline. In addition to those variables shown above, the loops demonstrate dynamic fluctuations based on the variables (not shown) that act on those listed above.
3.2.3.5 Evolutionary
The relationships in question make up a complex system of a number of unique variables. In addition, the model is designed to reflect the interactions encountered by various component activities within the engine engineering organization. As each variable can be expected to behave differently in the different environments, each can be expected to evolve at a different rate. Thus, it is impossible to develop an optimal model that would remain so for an extended length of team.
Figure 46 - Evolutionary Relationship Loop
Commodity
Premium $
Demande
Product Attribute
Leadership
+ Profit
Product Outcome
+
Evolutionary
Relationship
Internal Capability + Cost Reduction qv....._Internal Discip1irtw*...--- Efforts
Pressure to
Reduce Cost
An example of an evolutionary loop is shown above. The loop depicts how corporate objectives affect individual components and vice-versa. Lack of profits and cost reduction efforts decrease internal capability and eventually product outcome. Individual components will be assigned
82

different product attribute leadership levels and thus will be affected differently by product outcome and in turn will affect the system differently. Hence, the system (and ultimately the model) interactions will change since the components will not all have equal effects. The model then evolves as this new information becomes evident.
3.2.4 Construction of Simulation Model
The systems dynamics model used was based off of previous modeling efforts by Sterman 4
Repenning and Sterman 40 , and Lyneis 3 but presents a detailed structure of the automotive
OEM-supplier relationship. The model represents the progression from qualitative interviews and fieldwork regarding enterprise level and front line level decision making regarding supplier outsourcing, to a formal simulation tool that one can use to apply and evaluate alternative policies. The software used to build and run the model was Vensim PLE Plus 32 from Ventana
Systems, Incorporated 42 . The completed model included over 110 variables and stocks (buffers or levels), which resulted in over 16,000 unique causal loops. Due to the model size, complexity and time constraints, the model was developed to simulate directional effects of the causal relationships with correlation to real world information. No attempt was made to validate the model against all nine-engine component development processes. To construct the model, individual views were used in order to manage smaller portions of the model at any one time.
These six views (supplier capability / number of programs / product outcome, internal capability
/ internal resource burden / supplier resource burden, supplier proximity, internal technical knowledge, PAL / OEM competition, data input / graphical output) are discussed in the following sections.
In the following illustrations, the relationship variables are connected by causal links represented by directional arrows. The bracketed (<>) variables are input variables that are fully represented in another view. The stocks and flows (stock=INTEGRAL (inflow-Outflow,
Stockto) are represented by rectangles (stocks), double lined arrows (flows) and valves (flow
4 Sterman, John D., Business Dynamics Systems Thinking and Modeling for a Complex World, Irwin McGraw-
Hill, 2000.
40
Repenning, Nelson P. and Sterman, John D., Nobody Ever Gets Credit for Fixing Problems that Never Happened:
Creating and Sustaining Process Improvement, MIT Sloan School of Management, 2001.
3 Lyneis, Jim and Warmkessel, Joyce. System and Project Management. Class Notes. Cambridge, MA: MIT,
September 10, 2000.
4
Vensim PLE Plus 32 Version 4.2a, Ventana Systems, Inc., 1999
83

controls). Time delays are incorporated by the use of various time dependent variables and smoothing functions in the variable equations (for complete list, refer to Appendix J). The larger diamonds identify variables that correlate to the decision rules segment categories described earlier in this paper. These variables are identified for the purpose of the modeler for use during data input stimulus (for testing model correlation) and for graphical output.
84

3.2.4.1 View 1: Supplier Capability / Number of Programs / Product Outcome
In Figure 47 below, supplier capability is shown to influence both programs to do (number of jobs that the team is working on) and product outcome. Product outcome in turn affects programs to do. Programs to do influences the ratio of systems-to- component-to-program management focus that the engineers are able to allocate on their programs.
Figure 47 - Model View 1
Supplier Capability, Number of Programs, Product Output
Supplier Knowledge
Cost Rate
<EL Supp Cap>
<FL Supp Cap>
<Supplier
Discipline>
Typical M<Internal
Program Life
Supplier
Erosion of Supplier Capability
Capability
Investment in
Supplier Capability
Work
Accomplished
Supplier
Knowledge
Product Outcome
*i
Capability> <Investment in
Supplier Resources>
<EL Prod
Out>
<FL Prod initial programsOut>
Programs to Do
New programs
Rewo k Rate
Geerktiut>
PM Work Do
% Systems Focus -
Cascade
Inefficiency
Component Focus
~+
Systems Focus
% Comp. Focus
85

3.2.4.2 View 2: Internal Capability / Resource Burden & Supplier Resource Burden
Model View 2 (Figure 48) depicts the relationship between internal capability, internal resource burden, internal discipline, analytical tools, and supplier capability and resource burden. In addition, other high leverage variables modeled in this view include supplier discipline, product complexity and pressure to reduce cost.
Figure 48 - Model View 2
Internal Capability, Internal / Supplier Resource Burden
<EL Int
<F L Int
Cap>
Cap>
Erosion of
Int. Cap.
Internal
Cap. I tt in Int.
Cap. +
+
<Cost Reduction
Efforts>
Tool+
+
<Investment
In R&D>
<Supplier
Capability
<Int.Tech.Vision
Knowledge
<Strong Mgt.
and Leadership>
<Know]. of
Customer>
<Supplier
Proximity>
Time toDiscipl.
Factor+
<Avg Time on Job>
<Quality of
Documentatio
<Typ. MY
Program Life>
<EL Int. Res.
Burden>
<FL Int. Res.
Burden>
<Typ. MY 5u
Res.
Progr. ife> Burden +
Prgr ie>++
Int. Discipline. <Rework ate>
<Upfront
Planning
Cost to Disc* line
Int eal Resou
Burden
<Cascade
Inefficiency>
Sup. Disciplin <EL Prod
Comp> P
FL ProdProductT
IFL
Prod
-
Complexi
C mp>
<Knowledge
Factor +
<Program to Do
<Tp.
Of Sup Ability>
<Product
Outcome>
<Change in P
Att. Level Target>
Investment in Sup. Resources
<Shadow
Engineering
Headcount
<PM Work To
Do>
Cost Reductie --
Efforts I
Cost to Person
Factcor
Progr. Timing
<Prod. Attribute
Leadership
Level>
-
Pressure t
Reduce Co
<Typ. MY
Program Life> PA
<Cometitr~s
M
PAL to Timing Program Life>
>
<Competitor's Factor
PAL
Level>
<Profit> <Typ. MY <Programs to Do
Program Life>
86

3.2.4.3 View 3: Supplier Proximity
In this view, the emphasis was on structuring the relationship between the OEM and supplier commitments (see Figure 49). Key interacting variables influencing supplier proximity include trust, alignment of supplier to OEM motivation, knowledge of supplier's ability and level of shadow engineering that the OEM has allocated to that particular supplier.
Figure 49 - Model View 3
Supplier Proximity
*
<EL Supplier
Proximity>
<FL Supplier
Proximity> n
Investment in Sup. Proximity
Supplier
Proximity
111110-
Erosio n of Supplier
Proximity
<Typical MY
Program Life>
Supplier Proximity
Switch<ItraTehia
<Internal Technical
Knowledge
Tru S
<Sup plier
Disci pline>
<Product
Outcome>
Shadow
<SupplieL/-- Engineering
Capability> ~
Knowledge of
Supplier Ability
Motivation +
<Internal Resource
Burden>
<Internal
Capability>
<Strong Management
Vision and Leadership>
87

3.2.4.4 View 4: Internal Technical Knowledge
Figure 50 illustrates how value engineering, the average time for an engineer to learn his or her
job and the average time the engineer has spent on the job, influence the rate at which the home organization gains technical knowledge. In turn, this portion of the model builds the relationships between variables such as motivation to stay on the job, promotability, employee satisfaction and strength of management leadership.
Figure 50 - Model View 4
Internal Technical Knowledge
<% Systems Focus>
Int.
Technical
Investment in Knweg
Knowledge
Erosion of
Knowledge
<% Component
Focus> toVlue Engineeri <Headcount>
+Learn
Quality of
Documentati
Avg Time on Job New Hire Quality
Average Time to ern
<EL Know of
Cust> -
+
K.binowledge of
Customer
<FL Know-<
Cust>
-Motivation
Time to
Knowledge Fac r
Typical
. /
Rotation
+ to Stay ypical MY
Program Life> Management
~Vision
Job Factor nvestment in
Job Length Factor Leadership r
<Product
Outcome>
Strong Mgt
&
Leadership
L
Promotability
Erosion of
Leadership
<Cascade
Inefficiency>
<PM ork
Do> o
Employee +
Satisfactioir---- <Value
Engineering>
<T
/
Program Life>
1
<Rework Rate>
Upfront Planning
Rewar s
88

3.2.4.5 View 5: Product Attribute Level / OEM Competition
View 5 (Figure 51) illustrates the relationships involving the product attribute leadership level
(PAL). Influences on PAL include the competitor's PAL level and customer expectations.
Likewise, the OEM's PAL affects the ability to price the product higher and increase profitability.
Figure 51 - Model View 5
Product Attribute Level and OEM Competition
Rateof A17Product Attribute
Job to PAL F0f6iM Change Leadership Level
<Product <Typical MY
Outcome> Program Life>
Change in Product
Attribute Level Target
$ to PAL Factor
Commodity Test 1
Premium Dollar
Demanded
<Cost Reduction Cusomer PAL
Efforts> Expectation+
<EL Comp Pal>
<FL Comp Pal>
Commodity Test 2
Competitor's PAL
Level
+
Profit <Typical MY
Investment In
R&D
Program Life
89

3.2.4.6 View 6: Data Input and Graphical Output
View 6 (Figure 52) was constructed to aid the modeler's in both changing input parameters
(values of the primary decision-rule segments for both the enterprise and front line levels) and in gaining graphical output comparisons. The cluster of variables that leads to 'Quality Problems' simply represents variables to be selected for graphical output data. The clusters of variables that lead to 'DR Inputs' represent the enterprise and frontline decision rules. Inputs for these variables (dimensionless) are would represent the importance or priority placed on each decision rule. This information then is used as a stimulus for the respective variables (in Views
1-5). The model was developed to have enterprise level decision rules excite the system at year 5 for 0.5 years in duration, and frontline level decision rules to excite the system at year 7 for 0.5 years in duration. This is to simulate an existing product's PD cycle where a sourcing decision was made at some point in time (year 5 in this case) followed by engineering execution decision made 2 years later. The net effect of the decisions could then be evaluated a few years later (at year 10). Since both parameters are stimulated for only a short time frame (0.5 years), product performance as depicted in the examples presented in this paper, tends to taper off after a couple of years. Stimulation of the model involved giving the 'DR inputs' a value ranging from -10 (no priority) to +10 (high priority). The model interprets this input as a -10% to
+10% reduction in the associated decision rule variable. This convention was used as a representation of how the Team valued the specific decision rule. For example, if the Team
highly valued supplier capability, the supplier capability DR input would be set to +10, indicating that given a choice, the Team would select suppliers with greater capability (hence, supplier capability in the model was stimulated for the following 0.5 years). The model did not run out past 10 years because there was some inconsistency/availability in the actual product performance data (used for correlation purposes) available at the OEM much later than a year or two after product launch. Example of the system response to the decision rule stimulation is illustrated in Chapter 3.
90

Figure 52 - Model View 6
Decision Rule Segments For Data Input and Graphical Output
<Competitor's
PA L Level>
<% Systems
Focus>
<Product
Complexity>
Competitor's PALPercent ystems
F
Prod Complexity
Prog To Do
<Internal Resource Internal Res
B u rd e n > B u rd e n
Internal Cap
Prod Outcome
* bQ u a lity P ro b le n m P r dod
PAL
<Programs to Do> u ct
<Product
Outcome>
Interna
Capability>
Supplier Cap
SLeadership
Customer Prox P'roduct Attribute
Level>
<Supplier
Capability>
Supplier Prox t
<Knowledge of
Customer>
<Supplier
Proximity>
EL Supp Cap
FL Supp Cap
EL Int Cap
L Int Cap
FL Prod Comp
EL Prod Comp
EL Int Resourc .DR
Burden
Inpu FL Int Resource
Input~~~Burden
EL Supp Proximit FL Supp Proximity
EL Know o us
EL Prod Out
EL Comp Pal
Know of Cust
FL rod Out
FL Comp Pal
91

3.2.5 Model Correlation
To validate the model, our emphasis was on correlating the output data from the model to historical data from the nine individual components. Unfortunately we ran into two limitations with the existing component data:
* Data available primarily for product performance (warranty) only, not for other variables such as internal capability or customer knowledge
* Available data was inconsistent in form, time period, quality
Thus, we asked survey respondents to qualitatively plot (see Appendices B and C) the performance of their respective component over the past 10 years along seven areas: supplier capability, internal capability, product complexity, supplier proximity, knowledge of customer, product performance and competitor product attribute leadership. (Note: The eighth key variable, internal resource burden, although represented in the model, was not used for correlation. This was because it was not identified as a key decision rule until quantitative data analysis was complete.) The qualitative plots were then discussed with the survey participants to better understand their interpretation of high, medium and low values as depicted on the y- axis. Once this was done, each component fell into one of three general performance types:
" Component Level 1 = increasing product outcome, decreasing internal capability and increasing supplier capability
" Component Level 2 = increasing product outcome, increasing internal capability and increasing supplier capability
" Component Level 3 = decreasing product outcome, decreasing internal capability and decreasing supplier capability
After this, target values for the each of the seven attribute levels were established based on the respondents input and the base model was run to evaluate model output vs. the three component levels. The model allows for initial ramp data, variable coefficients, and initial value inputs for each of the seven attribute variables. These inputs were then selected such that a 'fit' was established to the various component levels (see Figures 53, 54 and 55; y-axis scaling shown at full range). This correlation was used to demonstrate that given the known initial
92

product attribute levels, the model could effectively predict the product response over the next
10 years. (Note: In order to represent a common variable and unit of measure that would represent warranty, product performance (vs. target objectives) and quality, we chose to use the variable 'product outcome'. Product outcome, as represented in the systems dynamics model, is defined as the number of 'good jobs' performed during a year. Goods jobs indicate projects that are completed to 100% customer satisfaction without market introduction delays (those that aren't completed to 100% satisfaction are depicted as 'rework' and sent back to the total jobs to complete). In this research, jobs refer to the number of product development activities for a given component. This includes all primary development programs, derivative development programs and all design iterations for both internal and supplier capability. For purposes of this research, it was assumed that for any one component, 200 jobs per year was a maximum level.
Also, this is unrealistic for many components, we chose to use one baseline (200 jobs) to establish a common reference for all model output).
93

200
0
150
E
0 100 o
50
S
-
0
0 2.5 5 7.5 10
Time (years)
Actual Component Level 1
.
Level 1 Model
.0.
0
100 -
80
60
40
20
---
0
1
0
2.5
1
5 7.5 10
Time (years)
Actual Component Level1 Level 1 Model zA
.0
200
150
0
100
50
0)
0'
0 2.5 5
Time (years)
7.5
Actual Component Level 1 Level 1 Model
10
100
0
S80
* 60
2 40
E a 20
4 0
0 0
- -
-Actual
2.5 5 7.5 10
Time (years)
Component Level 1 Level 1 Model
Figure 53 - Model Correlation to Component Level I
0
00
00 a.~
-
100
80
60
40
20
0
0 2.5 5
Time (years)
7.5 10
Actual Component Level 1 Level 1 Model
00-
0
80
0 60
E 40
0
(L
20
0.
0
,V--
-Actual
2.5 5 7.5 10
Time (years)
ComponentiTeve
-
Level I Model
0
2
CE
.0
100
80
60
40
T -,
U)
.
20
20
0
0 2.5 5 7.5
I
10
Time (years)
Actual Component Level 1
.
.
Level 1 Model
94

Figure 54 - Model Correlation to Component Level 2
.0
0
0
200
150
100
50
-
0
0 2.5 5 7.5 10
Time (years)_
Actual Component Level 2 Level 2 Model
.0
100
80
60
40
0.
SU
20
0
0
g
2.5 5
Time (years)
7.5
Actual Component Level 2 .
Level 2 Model
10
200
150,
2
CL
.0
:U
0.
100
50
0
-
0 2.5 5
Time (years)
7.5
Actual Component Level 2
-
Level 2 Model
10
0
100
80
.~60. x
0 cL 40~ m
E 20:
0
0 0
~
2.5
-Actual
5
Time (years)
7.5 10
Component Level 2 = w Level 2 Model a
100
80
0
20
?. 0
-
0 2.5 5 7.5
Time (years)
Actual Component Level 2
-
Level 2 Model
10
100
0
80
2 60
C.
E o 40
20
0
-Actual
-- .
-- mw
2.5 5
Time (years)
7.5
Component Level 2 Level 2 Model
10 a
U)
U)
.0
100
80
0
60
40
20
0
A.-
2.5 5
Time (years)
7.5 10
Actual Component Level 2 .
.. Level 2 Model
95
I I

Figure 55 - Model Correlation to Component Level 3
E0
0
0
0
200
150
100
50
0.
0
OVA
1
2.5 5 7.5 10
Time (years)
Component Level 3 -
Level 3 Model
4W
.0
-Actual
100
80
60
2
M.
C)
40
20
01
0
~~~1~
-Actual
2.5
5
Time (years)
7.5
Component Level 3 Level 3 Model
10
(0.
200
150
100
0.2
(0
0
0
* -Actual
2.5 5
Time (years)
7.5 10
Component Level 3
Level 3 Model ;
M 100
0
=
80
60
(a 40
0
0
0
-
2.5 5
Time (years)
7.5 10
Actual Component Levei3
.
-
Level 3 Mode
100
80
04 60
40
E
-
20
-
0
0 2.5 5 7.5
Time (years)
Actual Component Level 3
Level 3 Model
10
0
100
80 x60
E 40
0
*
20
0
IL
0
-
2.5 5
Time (years)
7.5 10
Actual Component Level 3 Level 3 Model
'A
.0
100
80
E
0.
C.
0.
60
40
20
0
0
-
2.5 5
Time (years)
7.5 10
Actual Component Level 3 - Level 3 Model
I
96

Once the correlation to various levels of component data was recognized, a base model was established. For this model, the ramp input was set at 0 for all seven key decision rule variable.
The initial values and coefficients were set such that product outcome was relatively level, supplier capability was increasing and internal capability was decreasing. This represented a baseline case for one of the questions that first drove the research: "Why do some of our outsourced components demonstrate improving product performance while others demonstrate degrading product performance?" In addition, the coefficients for each decision rule stimuli was set to match the relative correlation factor levels as discussed in Chapter 2.4.6. The base case model results are depicted below (Figure 56).
97

Figure 56 - Base Model Output
80
0 t5
I0
.0
0
70
60
50
0 2.5 5
Time (years)
-Base Model
7.5 10
0
0
50
40
30
20
10
0
0
2.5
5
Time (years)
-Base Model-
7.5
(U
0
0
CL w.
:
50
40
30
20
10
0
0 2.5 5
Time (years)
7.5
-Base Model
Base Model
30
0
0
20
U
E
0
010
0
0 2.5
.
5
Time (years)
Base Model
7.5 10
10
10
0
00 o
Ec
;15
100
90
80
70
0
-
2.5 5
-
Time (years)
Base Model
-
7.5
-[
10
30
0.
E U)
00M
20
S10
0
0
0 10 2.5
.
5
Time (years)
Base Model
7.5
U)
30
20
0.
CL
10
0
0 10 2.5 5
Time (years)
-- iBase Model
7.5
98

3.2.6 Limitations of the Model
As with the study of any system, one fundamental question becomes: "Where do we set the
boundaries for the system?" For the purposes of this research, the intention was to focus on specific components within one subsystem of an automobile. But is this really a large enough scope to understand the decision rules of an organization, from front line level to the enterprise level? We soon discovered that although we had set out to understand the operations of an automotive OEM and its suppliers, we needed to also understand, or at least apply, relationships dealing with employee rewards, the valuation of the total end product as a commodity and the impact of economic cycles. Although we tried to capture these relationships in the model, it is apparent that no tool can model the entire 'system'.
One limitation of the model is that it can only be as complete as the knowledge that the modelers have. For this research project, input came from roughly 40 individuals who had ten or more years of experience. Even though this led to quite an extensive network of relations, the knowledge and insight of these 40 individuals is nowhere close to the knowledge that all 1200 within the organization could provide.
Another limitation of the model developed for this research is the sheer complexity of the relationships. Even with the limitation of research participants as described above, over 16,000 relationship loops resulted from relationships developed; a number far too comprehensive for this research to fully understand. Improvements could also be made with additional sensitivity analysis and long-term (greater than the 10 year patterns studied) data correlation. Still, one would expect to see differing results had the scope, organization and number of respondents been significantly different. Thus, results from model testing should be viewed as directional and possibly proportional, but certainly not absolute.
It should also be addressed that there were many limitations within the model variables themselves. For instance, defining the unit of measure for key variables as something other than 'number of good jobs' may have led to the development of variable equations yielding different results. In addition, most variables do not have upper or lower bound limits. This allowed us to perform many different component performance evaluations when initially developing the model. For additional applications, one would want to add proper upper and lower bound constraints to the system.
99

Results from a more comprehensive study on the impact of outside economic influences should also be incorporated into the model. Consumer behaviors, market fluctuations, and development of the competition structure would also further strengthen the model as these downstream dynamics drive future model upfront product development strategies.
100

This body of research was framed around the premise that the decision rules at the top and bottom of an organization are misaligned due to factors such as the business environment (org.
structure, tradition, processes) and local motivation (experience, personal incentives) and inefficient cascading of corporate objectives. In addition, it was hypothesized that alignment of decision rules (at enterprise and front line levels of org.) leads to capabilities and efficiencies that reinforce the corporate vision (refer to Figure 6).
1
Misalignment of decision rules impedes achievement of corporate goals
Interview research and transcription did not identify relevant data that would enable testing of hypothesis 1. However, based on the analysis of the survey data (quantitative research) and findings as part of the systems dynamics model testing, Hypothesis 1 DOES NOT HOLD. We have data that suggests that it is decision rule dependent. In two out eight decision rules categories misalignment could impede product performance and in all others it does not. This implies that operationally, organizational levels need to understand the unique effects of each decision rule and focus more attention on those rules that promote achievement of the corporate goals. Figure 59 below illustrates two distinct alignment-to-product outcome results.
Case 1: Decision rules, if misaligned, can degrade the corporate goal (improved product performance). Examples of this case are the priorities given to 'Competition' and 'Supplier
Capability'. For instance, when Supplier Capability and Competition are given high priority by the enterprise level and frontline level teams making pivotal decisions, product outcome (a metric for gauging the corporate vision for segment leadership) improves. Thus, if Competition or Supplier Capability is not given similar priority by the front line and enterprise levels, one could expect that product performance could suffer (since not prioritizing these variables would lead to degradation in product performance just as valuing these variables leads to positive product performance). In order to evaluate this case, we looked at misalignment of decision priority for both decision objectives (supplier capability and competition) separately (see figures below).
101

Figure 57 - Misalignment of Supplier Capability Priority
80
70
U)
0O.6 60
050
0 2.5 5
7.5
-Base
EL Supp CapHi / FL Supp Cap Low
..- FL Supp CapHi / EL Supp Cap Low
10
Figure 58 - Misalignment of Competition Priority
66
E
U
0 .5 62
060 a.. 58 -
0
-
-
2.5 5
7.5 10
-Base
EL Comp. PAL Hi / FL Comp. PAL Low
..- FL Supp CapHi I EL Supp Cap Low
In the supplier capability sub-case, when decision rules are misaligned with enterprise level prioritizing supplier capability one sees an improvement in product outcome even though front line engineering did not prioritize this decision rule. However, one can see the importance of the enterprise level prioritizing supplier capability, because when we run the misalignment case with
102

front line engineering having the higher priority, product outcome degrades. Similar cases run for competition does neither yield improvement nor degradation of product outcome performance. In conclusion, even when there is misalignment for decision rules that are correlated positively to product outcome on both enterprise and front line levels, nonachievement of the corporate goal (i.e. improve product performance) is not a necessary outcome.
Case 2: Decision rules, if misaligned, do not necessarily impede product performance. 'Product
Complexity' did not show a correlation to product outcome, neither on the front line nor on the enterprise level of the organization analyzed. We explain this result by the fact, that the engine engineering business is generally a fairly complex business and the components tested did not differ too much in overall complexity as we defined it. With respect to the decision rule categories 'Supplier Proximity', 'Customer Proximity', and 'Product Performance' organizational misalignment did not make a difference to product outcome. And it appears that enterprise level leaders have a strong influence on product outcome during outsourcing decisions, when they prioritize supplier and customer proximity, as well as product performance. Hence, for above decision rules enterprise level leaders can really drive product outcome success without interference from the front line engineering level. The decision rules 'OEM Resource Burden' and 'Internal Capability' show a positive correlation to product outcome for front line engineering, but no correlation on the enterprise level. Here misalignment in terms of the decision rules 'OEM Resource Burden' and 'Internal Capability' misalignment does not appear to degrade product outcome. Thus, the implications are reversed and front line engineering can influence product outcome independent of enterprise decision-making with respect to these decision rules.
Decision Rule
Competition
Product Complexity
OEM Resource Burden
Internal Capability
Supplier Capability
Supplier Proximity
Customer Proximity
Product Performance
Figure 59 - Hypothesis I Test Results
Product Outcome Correlation
Enterprise Front Line
+
NO
NO
NO
NO
+
+
+
+
NO
NO
NO
103

As discussed in chapter 2.7 the systems dynamics model structure adopted the correlation factors between decision rule categories and product outcome performance. Thus, as part of the systems dynamics model testing of hypothesis one, we will test misalignments between sets of decision rule categories (see Figure 60). For reference, data for Test 1 represents a misalignment based on the following: Enterprise level prioritizes supplier capability, internal capability, product complexity and internal resource burden while the front line level prioritizes supplier proximity, knowledge of customer, product outcome and competitor's PAL. The data for
Test 2 represents the enterprise level prioritizing supplier proximity, knowledge of customer, product outcome and competitor's PAL while the front line level prioritizes supplier capability, internal capability, product complexity and internal resource burden. When compared to the base case (equal priorities on all decision rules at both levels), the prioritization of decision rules in both Test 1 and Test 2 case show a product outcome improvement. Thus, misalignment does not degrade the program's goal of improved product performance. It is quit possible that misalignment of decision rules may in some cases impede the achievement of the corporate vision, however, we have demonstrated through these two cases that this does not always hold true.
This implies that decision rule misalignment between strategic sourcing and front line execution decision does not necessarily harm product outcome. Thus, different decision rules are important for enterprise than for front line decisions.
Figure 60 - Product Outcome vs. Misalignment
-g 80
E 70
0 c0 60
-0 50
& 0
-Base
2.5 5
Time (years)
7.5
* Test 1
104
10
Test 2

Given that above testing shows that the hypothesis is not always true, it is not necessary to cascade all decision rules across all levels of the organization. Figure 60 suggests decision rules to product outcome correlations for the organization researched that indicate the existence of optimal decision rule sets, which happened to be misaligned. The quantitative analysis and systems dynamics modeling developed around this research, was able to provide an optimal decision rule set for the specific organization studied. These sets are as follows:
" Enterprise outsourcing decisions should value competition, supplier capability, supplier proximity, customer proximity and product performance.
" Front line product development execution decisions should prioritize competition, OEM resource burden, supplier capability, and internal capability.
However, alignment of both supplier capability and competition decision rules during front execution and enterprise level sourcing decisions is crucial for product outcome as it pertains to the organization analyzed. Not only did we find these to be crucial but also through qualitative and quantitative methods we are able to provide a working definition for each:
Supplier Capability = a*manufacturing assets and capacity + b*knowledge + c*cost + d*timing + e*quality +f* level of design and development responsibility + g*number of other customers.
Competition = w*Product attributes + x*quality + y*cost + z*timing
While we can define the corresponding coefficients through our limited research, we would propose to increase data sample size by surveying other automotive organizations.
Additional research may further show that it is more important to have unique decision rules at each organizational level in order to promote accomplishment of corporate goal. Thus, we recommend that engineering teams at all levels record decision rules and their priorities at pivotal PD events. This data could then be incorporated into sophisticated analytical tools, such system dynamics modeling, in order to define future optimal decision rules at organizational levels.
105

Decision rules for a particular PD team vary over time
While only limited qualitative data was collected, there is a strong indication that decision rules for a particular PD team vary over time.
Since the survey questioned participants about a decision rules used at a single pivotal product development event, the quantitative survey data research did not lend itself well to testing
Hypothesis 2. However, as part of the survey (refer to Appendices B and C) we asked each participant to plot a trend line for each of the decision rule categories over the past 10 years. As these trends have changed significantly over the past 10 years for almost all teams in most decision rule categories, we suspected that the decision rules incorporated did also.
We were able to further confirm that this hypothesis DOES HOLD TRUE through interviews with team members. Although we did not ask this question specifically, we heard evidence that decision rules vary over time due to changes in internal and supplier capabilities. One enterprise level interviewee explained it this way:
"We knew that we wanted to be the first in the industry to incorporate this technology. It wasn't about cost or timing but about gaining a competitive advantage. Since there was only one supplier capable of providing this technology, that's who we selected. Now five years later, there are four competitive suppliers who can offer the same technology. Now we source based on price and relationship."
The systems dynamics model can interpret changes in decision rules over time, but cannot be used to verify that the decision rules employed by the engine engineering organization studied change over time.
The conclusion is that PD decision rules can vary over time. Unexpected technology changes, competition and/or economic conditions may require product development teams to change their decision rules. This discovery has significant implications to knowledge management in product development.
Here the implication is that the organizational knowledge has to change with decision rule changes. Given that change in general is difficult for product development teams to accept, the
106

danger is that old knowledge stays with decision rules that are not state of art. As a result the following is required:
" Nimble organization: Since decision rules change, we need employees and organizational structures that expect, anticipate and can react to these changes. Thus, we view the mindset of changing decision rules to be an integral part to successful product development teams to adapt quickly to change and recommend that decision-making be part of corporate training as it is inherent in the product development process.
* Further reduction of departmental chimneys: If optimal decision rule sets do vary over time, stakeholders must agree quickly to decision rules influx. This may mean that although cost and timing may be important to both engineering and purchasing activities today, tomorrow they must both be able to recognize drivers that will in effect change the optimal decision rules.
* Improved documentation: Engineering decision rule changes may result in confusion over time across organizational levels. Therefore, engineering teams need to take a more proactive approach to explain and document decision set priority changes. Thus, at each pivotal decision making event (as defined by the PD enterprise and front-line teams), we suggest that the decision rules must be cataloged (such as in a lessons learned database) in order that we may incorporate tools such as dynamic models to recreate history, understand current affects, and modify future decision rules to complement/compensate for these affects.
The aforementioned are not easy tasks to accomplish due to the effect of decision rule drivers
(i.e. corporate, functional and personal objectives), changeover in work force and the inherent time delay between engineering decision events and product field performance.
While upfront planning and decision making as early as possible in the PD cycle is important in defining the design space, our data indicates that this space needs to be held open as long as possible. This will allow the Team the ability to react to decision rule changes that, we have demonstrated, vary over time. Holding the space open for as long as possible thus enables meeting changing competitive environment and customer demand fluctuations. Furthermore, with varying decision rules, locally optimized knowledge management and data access issues will prove inefficient as information required to make the decisions continues to change as well.
107

4.3
Corporate, functional and personal goals directly shape the decision rules teams apply during key product development decisions
Survey data and qualitative interview data analysis suggests that Hypothesis 3 HOLDS TRUE.
As for the survey data, seven out of eight decision rule categories correlate positively with at least three out of the six decision drivers. For instance, with increasing priority perceived on customer proximity, the higher the importance for shareholder value, customer satisfaction, local department traditions, and personal goals. The data indicates that there is a strong correlation between decision rule drivers and decision rules. The key findings as expressed in Figure 59 are as follows:
* Corporate Goals have a stronger influence on decision rules than functional and personal goals
" Customer Satisfaction is the strongest decision rule driver
" None of decision rule drivers correlate with the decision rule 'OEM Resource Burden'
" Functional goals correlate to the decisions rules 'Product Performance', 'Supplier Proximity',
'Customer Proximity', and 'Internal Capability'
" Personal goals correlate to the decisions rules 'Product Complexity', 'Customer Proximity', and 'Internal Capability'
Customer satisfaction appears to be the strongest decision rule driver as it positively correlates to seven out of eight decision categories. It is most probable that customer satisfaction as a corporate goal is very well understood, cascaded, and enacted by the organization analyzed.
The decision rule category internal resource burden does not correlate with any of the chosen decision rule drivers. This is a surprising finding as the effects of resource burden directly impact variables such as employee satisfaction, department engineering budgets, and knowledge transfer. Product execution is extremely dependent on resource availability.
However, if none of the possible decision rule drivers bring the decision rule 'Internal Resource
Burden' forward into supplier sourcing and product execution decision-making events, product development may be at risk. Thus, resource issues may become an afterthought consistent with
108

problematic issues raised by Lyneis and Warmkessel
3.
Since functional areas usually have to conduct product development efforts, sensitizing these areas in their goal setting to address resource issues during decision-making is vital.
Personal goals only correlate to three of studied decision rules. While it is important to note that individuals seem to want to improve customer knowledge and individual capabilities, as well as reduce product complexity, the implications can be twofold. First, one could conclude that individuals don't feel personal goals have a bearing on other decision rules as they relate to product outcome. This becomes specifically problematic with respect to the decision rule
"Product Performance". Second, from a personal standpoint individuals don't understand the relationship between their personal performance and the goals of the corporation (even though corporate goals affected nearly all decision rules studied). This will result in motivational problems and employee retention issues, which could ultimately have a negative impact on technical knowledge and product outcome. The organization must find a way to a) motivate employees based on their own unique set of personal objectives, and b) correlate this reward structure to match higher level, corporate objectives.
Figure 61 - Decision Rule Category to Decision Rule Driver Correlation
-upplier
Lapablity
Product Compledty
Intemal Resource Burden
Product FPrformance
Supplier Proxity
Competition
Customer Proximity
Internal Capablity
Corporate Goals
Shareholder OEM organizationa
Value Infrastructure
+
+
0
0
+
0
+
0
+
0
+
+
+
0
+
+
Customer
Satisfaction
+
+
0
+
+
+
+
+
FnCtlional Goals
Department
Goals
Local/Department
Traditions
-
0
0
0
+
0
0
+
0
0
+
+
0
+
0
Personal Goals
0
0
0
0
Qualitative interview research further substantiates the claim that corporate, functional and personal objectives drive decision rules. The following quotes reference the use of decision rule drivers by decision-making stakeholders throughout the organization at both enterprise and front line levels:
0 Indication that teams place priority on meeting their functional goals:
3 Lyneis, Jim and Warmkessel, Joyce. System and Project Management. Class Notes. Cambridge, MA: MIT,
September 10, 2000.
109

"... creation of CBGs (consumer business groups) each is its own little kingdom. Our learning has gone down due to the cross-organizational alignment - all have different demands. This leads to a loss of expertise. Wants and needs are conflicting."
"Each individual plants is run as its own separate entity; each is its own kingdom. Very little consistency exists in processes between our plants (including engineering, vehicle, and parts plants)."
* Indication that engineering team understands corporate objective is driving decision-making process:
"We are here to serve our customer. Customer satisfaction is one of our corporate principles."
"When issues arise, they hear from engineering, the plants, design, STA, purchasing. Everyone is trying to tell them what to do. What is really important is how the issue affects customer satisfaction."
* Indication that engineers realize that personal goals cannot be discounted when considering engineering commitments:
"There are no rewards in the system to (encourage you to) stay in component engineering"
"We need a reward structure that makes people want to stay in the job. The culture has been to switch jobs and get promoted."
Similarly to comments made with respect to hypothesis 2, the systems dynamics model developed for this thesis does not lend itself to testing of hypothesis 3.
We already established that decision rules impact product development decisions and thus company success. Hypothesis 3 underlines that decision rules have drivers on a corporate, functional, and personal level. Consequently, decision rule drivers indirectly impact corporate success or failure and are the essence and leverage point for organizations. If an organization openly and concisely communicates it's corporate mission and policies, has well documented and understood reporting structures, and is clearly aware of its employees wants/needs/desires, then it's teams will have in place the knowledge to utilize decision rule drivers that can best achieve the high level corporate objectives. There is real difficulty in understanding decision rule drivers. The scope of this research did not intend to reveal such insights.
In order to collect such valuable data, we recommend that further research be conducted that unveils product development decision rule drivers. With that further evolution of the existing systems dynamics model structure to include the decision rule drivers, could provide valuable insights into the importance and opportunities that come with understanding and evolving
110

decision rule drivers. Figure 62 proposes such a systems dynamics model extension. Here, loop
1 describes the difference between performance goals and actual state requires a corrective action (decision), which typically requires some level of additional resource allocation. Loop 2 explains how decisions are made by applying the decision rules (which are established based on various objectives) to the actual state of the parameters, which make up the corrective action sought. An added loop here is required to depict the differences between enterprise and front line decision making. Loop 3 discusses changes in resource allocation due to corrective actions.
These resources can be invested back into the aforementioned parameters. Resources are typically drained from a set budget. Loop 4 expresses the state of the system plus the resources available indicate level of potential competitiveness (product goals and specific competitive data is incorporated in loops 2 and 3). This competitiveness potential then influences changes in performance goals.
Figure 62 - Systems Dynamics Next Steps
C.numpio
Loop lit y
Loop 1
Loop 43S
Loopli
Corpral jtoa betw
'-It ly i suppher P t y
'. onst
In smNz
1'. 1"
-E e n1tc is
,.
Oie . n Rule,
Comp-
>rf
S i
..
liy
Sp ilt
Po
11 i eio
111

Decision rules vary by the level within the organization, with enterprise level decision rules heavily influenced by corporate goals and front line level decisions heavily influenced by personal goals
Based on the analysis of the survey data, Hypothesis 4 PARTIALLY HOLDS TRUE.
As summarized in the chart below (Figure 63), both front line and enterprise level are aligned with respect to personal goals. Low to no priority was placed on personal goals as decision drivers, indicating that either both front line teams and enterprise level personnel surveyed were able to separate their personal interests from larger corporate initiatives or possibly that the individuals interviewed/surveyed were not willing to admit that their decision-making is influenced by their personal interests. We contend that it is more likely a combination of these factors, and that in fact, individuals may not recognize that personal goals play a role in how they perform their corporate responsibilities. As for functional goals, medium priority weighting was placed on these goals as decision drivers by both enterprise and front line level. Here, alignment is an indication that local, departmental goals which are most often well understood play a key role in the decision making process.
However, the data suggests that corporate goals, which are cascaded from the highest level of the organization, often lead to misalignment in the decision rules between enterprise and front line levels. The data suggests that shareholder value initiatives, which may be well understood and enacted at the higher levels of the organization, may not be well understood or may be ignored at the lower levels of the organization. In fact one front line level employee said it best when he said "... sure, I know shareholder value is important to the Company, I just don't know how my day-to-day job effects it". The implication is that shareholder value, a corporate goal, does not influence front line engineering activities.
In contrast, another element of corporate goals - customer satisfaction - stood out as being well aligned. The authors contend that customer satisfaction is one goal that is efficiently cascaded down the various levels of the engineering organization because it is often clearly understood how engineering actions directly effect product performance, which in turn directly effects customer satisfaction.
112

An interesting observation drawn from the data is that at the front line engineering level, decision rule drivers are not correlated with product outcome. It is understandable that valuing customer satisfaction leads to better product outcome (as in the case of enterprise level decisions) and valuing personal goals degrades product outcome (also the case with enterprise level decisions), but why are these effects only seen at the enterprise level and not at the front line level? It is probable that strategy has more of an effect on product outcome than execution.
This premise was tested below (Hypothesis 5).
Decision Rule URIVIR
Lorporate Goals
Shareholder Value
OEM Organizational Infrastructure
Customer Satisfaction
Functional Goals
Department Goals
Local / Department Traditions
Personal Goals
Rewards / Opportunities
Internal Growth Opportunities
Work-Life Balance
Employee Satisfaction
Figure 63 - Decision Rule Driver Influence
Alignment
M
G
A
A
A
A
A
A
A
Priority
2.2
1.6
1.7
1.8
1.5
1.8 n/a
2.0
1.7
3.0 n/a
2.7
Product Outcome Correlation
Enterprise Front Line n/a
NO
NO
+ n/a
NO
NO
-
-
-
NO
NO
NO
NO
NO
NO n/a
NO
NO
NO n/a
NO
NO
NO
Interview research could not substantiate the hypothesis. Both enterprise and front line level personnel expressed corporate, functional, and personal goals in a similar fashion. For example, enterprise level management did not express corporate goals more frequently than personal objectives. Similarly front line engineering interviewees referred as often to personal as corporate objectives.
The systems dynamic model as developed from relationship mapping derived from our qualitative research did not incorporate the effects of decision rule drivers. Thus, no testing of the hypothesis using the existing dynamic model was performed.
The data supports the fact that decision rule drivers are influenced by corporate objectives at the enterprise level. And a clear misalignment between enterprise and front line engineering was discovered with respect to the importance placed on shareholder value as a decision rule driver. On the other hand, customer satisfaction, another corporate decision rule driver, was equally well understood and enacted during both front line and enterprise level decision-making.
The question becomes why some corporate goals are better understood than others on front line engineering levels. Cascade processes that are tailored to the specifics of corporate goals
113

may realize better understanding. Each function can contribute differently to shareholder value.
Therefore, tailoring corporate objectives to specific departmental capabilities is essential.
In terms of decision rule drivers, there appears to be more leverage (in regards to product outcome) at the enterprise level then the front line level. For instance customer satisfaction, while aligned across organizational levels has positive impact on product performance for enterprise level sourcing decisions but there appears to be no significant correlation identified for front line product execution decisions. Similarly, personal goals tend to have a negative impact on product outcome for enterprise level decisions but there is no apparent similar correlation on the front line side.
These findings are significant because it indicates that as corporate objectives, organizational structures, department charters and personnel change, the decision rules may not change equally (or in a similar direction) at various levels of the organization (since the decision rule drivers at these levels vary). Thus, these findings (enterprise level decision rule drivers have more leverage) may not hold true as the company evolves.
Through interviews, it became quite apparent that cost and timing targets drive employees at all levels. These goals are well understood because there are strict constraints and metrics in place for monitoring. The implication of this research is that the organization must tie corporate goals such as shareholder value to objectives more closely associated with the PD organization.
It is apparent that the engineering community can work toward making decisions based on the higher corporate goals (customer satisfaction example) if there are engineering metrics associated with it. Thus, a goal such as shareholder value require translation into metrics, such product attribute targets that the product development organization understands and can easily track. As a result, corporate goals require a fine breakdown when cascaded down into engineering communities that engineers can associate with, but at the same time supports the larger corporate goal. For example, for a safety engineer shareholder value may mean protecting for an engine platform capable of contributing to a five star occupant safety rating in a vehicle crash. Whereas shareholder value to a durability attribute engineer may mean designing to zero defect performance up to a certain vehicle mileage and/or time in service.
114

Enterprise decision rules at pivotal PD events have a greater impact (on product outcome) than front line engineering decisions.
Analysis of the survey data, qualitative interviews, and systems dynamics testing indicates that
Hypothesis 5 PARTIALLY HOLDS TRUE. Given different decision rules sets applied at both the enterprise and front level, the answer on whether strategic sourcing decisions are more important than execution decisions may vary.
Interview research specifically with front line focus groups and enterprise personnel indicated that enterprise level decision-making to reduce cost and reorganize had significant impact on product outcome performance. Those decisions while indirectly linked to supplier sourcing decisions, ultimately shaped the OEM-supplier relationship and product execution. Interesting quotes to this effect are as follows:
"It's not always about who we outsource to. Most of the time it's our own internal issues. Product performance was compromised by year over year cost reduction initiatives."
"In year X, reorganization to consumer business groups caused a great increase in workload.
We had to support more programs with less people."
However, evaluating the correlation between the eight decision rule categories and product outcome (see Figure 59 above), the effects of strategy vs. execution decisions are not that clear. The data does not support the hypothesis but rather indicates both strategy and execution decisions, when based on an equal level of decision rule priority, provide opportunities to effect final product performance. Relative to the decision rules analyzed one can distinguish between three distinct enterprise level sourcing versus front line execution decision rule success correlation patterns. One where both strategic sourcing and front line decision rules can have a similar impact to product outcome success or failure (i.e. competition and supplier capability). Another where front line decision rules create the largest difference (i.e.
OEM resource burden and internal capability). And lastly there is a pattern where sourcing decision rules will drive positive product outcome (i.e. supplier proximity, customer proximity,
115

and product performance) and front line engineering has only limited leverage over product outcome performance.
While the quantitative research was able to highlight effects of individual decision rule on product outcome, the system dynamics model was applied to test various decision rule sets at both enterprise and front line engineering decision events. The model incorporated decision rule stimulus during a ten-year product development run. Both the enterprise level and front line level were set to have the same input stimulus (equal priority given to decision rule categories) at the same point in time (year five) for the same duration (0.5 years). In the first case only enterprise decision rules were stimulated. In the second case, only front line engineering decision rules were stimulated. We then plotted the product performance response for the five years following the stimulus.
The figure below depicts the results from Test 1, which compared the product performance curve response due to prioritization of all decision rules (competition, product complexity, internal resource burden, internal capability, supplier capability, supplier proximity, customer proximity, product performance). Results indicate that for this case, there is only a slight, but we deem insignificant, difference between the enterprise level and front line level results.
Figure 64 - Product Outcome vs. Organizational Level Test I
80
(0
00
0 50
0 60
0
L_ 50
0
-Base
2.5 5
Time (years)
7.5 10
*
All EL DR at 5yr -All DR FL at 5yr
116

We then looked at two other cases as depicted in Figures 65 and 66 with similar stimulation. In one case (Test 2), the enterprise decision was stimulated with the decision categories that showed stronger correlation in the quantitative research analysis at the enterprise level then the front line level. The decision rules for Test 2 included competition, supplier capability, and supplier proximity. Similarly in a second case (Test 3), both enterprise and front line levels decision-making was stimulated with decision rules that are more strongly correlated with the front line level (internal capability, supplier capability and competition).
Figure 65 - Product Outcome vs. Organizational Level Test 2
80
.0
0
0
0
0
0
70
60
.
.
.
4
50
0 2.5
5
Time (years)
7.5
10
Base .
EL Strong EL Correlation
FL Strong EL Correlation
117

Figure 66 - Product Outcome vs. Organization Level Test 3
80
0
0)
E
0
70
0
L-
60
50
50
CD
-Base
LO) LO
Time (years)
ICO
EL Strong FL Correlation -FL Strong FL Correlation
Results of this simulation indicate that based on the set of decision rules used, either enterprise level or front line level decisions have the ability to have a greater impact on product outcome.
Combining results gathered from the above research methods, we were not able to conclusively prove whether hypothesis 5 holds true. However, there is some indication that the decision rules
'Supplier Proximity', 'Customer Proximity', and 'Product Performance' have a stronger influence on product success when prioritized during strategic sourcing decisions rather than front line execution. Overall, both enterprise level sourcing and front line product execution decision rules have an impact on product outcome. While qualitative quotes indicated business principles instituted by enterprise level activities that framed consequent sourcing and product executions decisions, quantitative and system dynamics case runs indicated an indistinguishable importance between decisions rules employed on both organizational levels.
Hypothesis 5 testing, in combination with what was discussed in Chapter 2.4.6, also unveiled some consequences that arise due to front line fire fighting. To the extent that these findings are representative of OEM-Supplier relationships in general, several powerful consequences surfaced:
118

* Skewed supplier vision on the OEM working level, degrading relationships and moral in the
OEM-Supplier network with a focus on quality problems. Thus, decisions are made based on suppliers with problems. In contrast, Toyota works on continual supplier performance improvement building a more positive OEM-Supplier relationship.
* Limited interaction with good performing suppliers in front line level causes a double negative impact: o Lost opportunities, such as enhancements in lean manufacturing and technology benefits through good performing supplier.
o Limited learning from good performing supplier limiting internal capabilities to enhance product performance and sustaining competitive advantage.
One can conclude that fire fighting has implications beyond what was expressed in Repenning and Sterman . Ultimately, skewed front line vision about the supplier could result in misconceived decisions and opportunities optimizing the value of supplier relationships are lost.
Assuming that proper upfront planning reduces the need for downstream fire fighting, we recommend more upfront planning be incorporated by the organization. This could include the development of a full-time supplier assistance department, whose staff level remains proportional to the number of jobs outsourced (i.e. not the first organization to be cut during cost reduction initiatives).
To test this premise, knowledge of supplier ability (enabled through supplier technical assistance personnel) and upfront planning during the enterprise level sourcing decision was simulated within the existing systems dynamics model. The results depicted in Figure 67 and 68 indicate that both parameters have an impact on product outcome with the ability of reversing general downward product outcome trend versus the base case. Both parameters in each case were only stimulated for a short time frame (0.5 years), which explains why product outcome performance to level off after a couple of years. We recommend further studies to be conducted to substantiate our analysis.
38 Repenning, Nelson P. and Sterman, John D., Nobody Ever Gets Credit for Fixing Problems that Never Happened:
Creating and Sustaining Process Improvement, MIT Sloan School of Management, 2001.
119

Figure 67 - Product Outcome vs. Upfront Planning
80
0
E
0
0
0
C.)
0L
70
60
50
0
Base
2.5
5
Time (years)
7.5
Upfront Planning DR
10
Figure 68 - Product Outcome vs. Knowledge of Supplier Ability
80
.0
0
70
I..
LI.
0
60
50 4
0
-Base
2.5
5
Time (years)
7.5
* Knowledge of Supp. Ability DR
10
Furthermore, we recommend that downstream fire fighting could be circumvented by fullservice supplier sourcing decisions that take into account OEM and supplier capabilities, value
120

stream integration, enterprise stakeholder interest and the operation of a strategic partnership.
This will yield better quality and customer satisfaction outcomes more so than decisions narrowly conceived as a simple cost/benefit make-buy decision. However, this premise requires further analysis.
121

This chapter will address interesting relationships gathered from interview research and incorporated into the system dynamics model. While the analysis thus far concentrated on decision rules and its drivers, we would like to point your attention to underlying OEM organizational dynamics that deserve further analysis.
As we will show in this chapter intangibles are important and decision rules that address intangibles can make a difference. Organizations can evolve by finding a way to include intangibles into decision-making. Examples are illustrated and explained below. The analysis will show that valuing intangibles causes long-term merits. Hence, organizations driven by traditional systems that value short-term pay-off could derive major breakthroughs from policy changes that valued intangibles in decision-making.
Without explaining all causal relationships in detail, we would like to point out some reinforcing causal loops that ultimately can create a downward product outcome spiral in relationship to the decision rule categories identified. In the findings below we refer to product outcome measured in jobs as successful product development projects meeting all functional and quality targets and completed without market introduction delays.
To test whether or not a causal loop is a reinforcing or balancing loop, one traces the effect of a small change in one of the variables as it propagates around the loop. If the feedback effect reinforces the original change, it is a positive; if it opposes the original change, it is a negative loop.
4 Negative loops are referred to as balancing loops while positive loops are referred to as reinforcing loops.
4 Sterman, John D., Business Dynamics Systems Thinking and Modeling for a Complex World, Irwin McGraw-
Hill, 2000.
122

Figure 69 - Loop Notation
Positive/Reinforcing Negative/Balancing
Reinforcing loops can cause increasingly improving organizational performance. However, these loops are highly susceptible to downward spiraling, when adverse external influences impact loop parameters negatively. Balancing loops on the other hand can cause alternating organizational performance. Hence, temporary success is followed by negative developments on an ongoing basis.
Figure 70 - Management Vision/Leadership Loop
Employee Satisfaction
Motivation to Stay
4
Upfront Plannin
Average Time Engineer on Job
Quality of Docum+entation sStrong
Tools
+
Technical Knowledge
+
yDiscipline
Management Vision/Leadership
Management Vision/Leadership Reinforcing Loops
Product Outcome
123

In this causal loop, management vision and leadership increases with improved product outcome. A managers' promote-ability can have a negative impact to his or her ability to stay the course and be strong to promote what's best for the organization. In those cases, interviewees referred to the "Can Do Everything" mentality that does not always lead to accomplishing organizational goals.
However, the stronger the management vision and leadership, the more upfront planning, tool development, and quality of documentation are carried out. Also employee satisfaction improves. All of those variables will ultimately lead to better product outcome. Strong management is capable of understanding the intangibles that create long-term benefits versus short-term financial constraints. As a result, the more upfront planning efforts made, the more discipline downstream product development activities have which increases internal capability and improves product outcome. Further, the better product outcome the more leverage management possesses to follow its vision and to execute strategies.
While demonstrated above in a positive behavior, the reinforcing loop can also result in a downward spiral when at least one of the causal loop variables develops in the opposite direction.
Further to demonstrate the importance of managerial leadership as expressed above, the dynamic model was run with an emphasized change in the level of the "management leadership" variable. One run was made with level of management leadership 50% higher than in the base case (for the entire 10 year period) while the other run was made with management leadership set 50% lower than in the base case. Results are depicted in Figure 71 below.
While improved leadership causes gradually improving product outcome, the model shows product performance in a downward spiral (performance degrades at a faster rate) when less than desired leadership abilities are utilized. Due to that fact that automotive product development efforts take three to five years to complete, there is a time lag until the affects of leadership quality on product outcome can be expressed. While the overall product improvement seems relatively low, leadership can be viewed as enabler for organizational success.
124

Figure 71 - Product Outcome vs. Management Leadership and Vision o 80
E
0
70 o 60
50
0 a- 0
-Base
[
_
2.5 5
Time (years)
7.5
.
Improve Leadership 50%
10
Degrade Leadership 50%
In summary, management vision and leadership is a leverage item that can excel product performance. An organizational policy implication could be to sensitize managers to the fact that their vision and leadership, as expressed in their decisions/actions, can make a significant difference to product performance. However, impacts of leadership show its merits three to five years later. Traditionally employees are deployed to other programs or jobs within a shorter timeframe, thus there is less incentive to leadership as rewards and recognition are based on short-term merits. Management leadership, while difficult to express in traditional metrics, appears to have significant impact to product performance and thus warrants the development of organizational human resource mechanisms that emphasize long-term vision.
Hence, the next step should be to define what strong leadership and vision is and what it means to downstream engineering. Based on the qualitative data and interviews our relationship mapping suggested that leadership and vision affects the level of internal discipline, quality documentation, upfront planning, and employee satisfaction. Thus, a leader could be measured
by how he or she prioritizes above mentioned product development variables. While above mentioned variables might not be all inclusive, we have demonstrated, that they are of significance to product performance improvements.
125

Figure 72 - New Hire Quality Loop
Average Time Engineer on Job
New Hire Quality Reinforcing Loop
Motivation to Stay Technical Kn wledge
New Hire Qualit
The organization analyzed hired the best graduates from the most prestigious schools. Those graduates were very successful in their life and as a result have high ambition to achieve even greater things in their professional life. Thus, their motivation to stay in engine component engineering is limited; they want frequent job rotation in order to climb the corporate ladder. This ultimately reduces the average time an engineers stays on a particular job within the organization. According to the interview research, technical knowledge is directly proportional to the time engineers spend working on a particular component. As a result, with the average time on the job reducing, the technical knowledge on this component is decreasing. One tool to increase technical knowledge is to hire the brightest engineers causing a "downward spiral" as indicated by focus group participants.
To test the loop structure as shown in Figure 72, we made only one change to the model. We evaluated the base case versus the test case where "new hire quality" had a positive effect on motivation to stay (motivation to stay as a function of +new hire quality versus -new hire quality; see Appendix J for reference equations). This would be equivalent to incorporating a human resource policy revision, which would tailor rewards/motivation actions consistent with an individual's career aspirations. The results, as presented in Figure 73 below, show a significant improvement in product outcome.
126

Figure 73 - Product Outcome vs. Motivation to Stay
0
E
0
0
..
U
90
80
70
60
50
0
--
T a -- 4
-Base
2.5
5
Time (years)
7.5
10
.- Motivate Quality Hires
Similarly to above-mentioned time lags in the positive effects of leadership quality on product performance, policy revisions to human resource career development would show fundamental worth several years in the future.
In conclusion, hiring from the best schools can reduce specific knowledge. While attracting quality people is a good policy, taking additional steps in restructuring career development and compensation packages appears to greatly affect organizational performance. Thus, hiring the best talent for the job at hand is not sufficient. It may be just as important to align reward structures to career aspirations to assure a relatively lengthy time on the job and ultimately greater in-house technical knowledge.
127

Figure 74 - Fire Fighting Loop
Motivation to Stay
Employee Satisfaction Fire Fighting Balancing Loop
Average Time Engineer on J
Technical Knowledge
Discipline
Internal Capability
Rewards
Rework .
Product Outcom
Upfront Planning+ Strong Management Vision Leadership
As described in above causal loop, the organizational culture rewards "fire fighters" and does not reward engineers that deliver consistently through upfront planning. Following the loops through technical knowledge and/or discipline the short-term fire-fighting mode improves product outcome initially. However, with better product outcome becomes, employees are less likely to be rewarded, as there is less rework, consequently impacting product outcome negatively. Ultimately, this behavior can contribute to alternating product outcome performance.
Hence, fire fighting leads to alternating product performance with limited chance for long-term improvements. In order to impact the organizational performance with sustained year over year improvements, we suggest the following policy changes:
" Reward upfront planning efforts
* Emphasize upfront planning efforts over rework
128

The theory here is that leverage on product outcome improvement comes with upfront front planning if rewarded and further if emphasized over rework efforts because employees are more satisfied. This causes a reinforcing impact to improvement of product performance over time. Both policy changes were incorporated into the systems dynamics and comparisons to the base case are demonstrated in below figure. One can see rewarding upfront planning improves product performance. Even more product enhancement potential comes with an additional emphasis on upfront planning over rework.
Figure 75 - Product Outcome vs. Upfront Planning Rewards
Base
80
0
.~70
E
0
0260
0
50
0
O. 40
C0 I LO
Time (years)
LO)
.
Reward Upfront Planning
Upfront Planning Reward = 2x Rework Reward
As discussed in above mapping of current organizational tendency of rewarding fire fighting but not upfront planning causes negative impacts to organizational performance. However, we demonstrated that rewarding and overemphasizing upfront planning would result in improved product performance over time.
This is important because rewarding upfront planning not only improves employee satisfaction at the onset, but also now causes the above loop structure to become a reinforcing loop. The implication is that as product outcome increases; rework decreases and upfront planning increases. This in itself will help perpetuate the reward structure within the organization to emphasize upfront planning, and thus the cycle continues. Furthermore, the alternating portion in the product performance behavior, caused by the fire fighting balancing loop through the variable rework, gradually diminishes.
129

Depending how deeply the fire fighting behavior is culturally routed in the organization this policy change can take more time than just one product development cycle to materialize. In order to accelerate the adoption of an upfront planning mindset, we propose that the organization establishes upfront planning success metrics to be included into management performance reviews. Given the time lag required to demonstrate that upfront planning materializes in downstream product improvements, upfront planning success metrics are extremely difficult to measure and reward. As a surrogate to rewarding upfront planning efforts that may have taken 10 years prior, the organization could reward more heavily those individuals who have practiced adherence to customer requirement and design/development process principles.
Figure 76 - Value Engineering Loop
System Focus+
AValue
Engineering
Employee Satisfactiot-.->n t
Motivtion to Stay
Component Focus
Value Engineering Reinforcing
Loop +
Technical Knowledge
+ Average Time Engineer on Job
Program Management Work
Discipline
Number of Progr Ims
Internal Capabilit
Product OutcomeA;'
Rework
The value engineering reinforcing loop fundamentally underlines that engineers have a desire to work on technical challenges. For the organization studied, those challenges include working on engine components or engine subsystems. Increased value engineering leads to higher employee satisfaction and stronger technical knowledge in the engineering organization. This enhances internal capability and consequently product outcome. However, the more program management work is required the less engineers can focus on what they were educated to do.
130

Ultimately, the value engineering loop structure can cause degrading product outcome, specifically when the number of active engine programs increases. Hence, the number of active programs becomes the main leverage variable. It is not only influenced by the amount of rework, but more importantly by the amount of new product programs the organization attempts to undertake. This behavior was modeled with our systems dynamics simulation comparing a
25% increase in product programs versus the base case. Results, depicted in the figure below, substantiate above said. As the amount of product programs increases, engineers are exposed to more program management work and thus are less satisfied which ultimately degrades product outcome.
Figure 77 - Product Outcome vs. Programs to Do
80
0 70
E
0
0
0 40
0
S 20
0
Base
2.5 5
Time (years)
+ 25% More Programs
7.5 10
-25% Fewer Programs
Interview research indicated that the organization overemphasizes program management work.
Interesting quotes to substantiate what engineers expressed are as follows:
"Too many initiatives lately 'waste our time'. These initiatives (PPMP, FPDS) are designed to track programs. This was supposed to make it easier on the engineer (provide 'cookbook recipe') but reality says it's a series of tradeoffs."
"Component engineers spend so little time doing actual engineering work (vs. filling out forms).
Engineers are asked to spend all their time in meetings, explaining tools rather than using
131

them." Back in the early 1990s without all that program management work, we spent our time visiting suppliers, working on the details."
This prompts the idea that there is an opportunity to reduce program management work to affect employee satisfaction positively. Thus, the impacts on product outcome were further analyzed with the systems dynamics model as depicted in Figure 78.
Figure 78 - Product Outcome vs. Program Management Work
80
0
70 a> 60
E
0
.)
50
40
0
30
20
0
.Base
2.5 5
Time (years)
-25% Less PM
7.5 10
-..25% More PM
As the graph shows product outcome improves with decreased amount of program management work. This indicates that an engineering organization staffed with skilled engineers should focus on value engineering. While program management is still necessary to instill discipline, engineers are more satisfied with solving engineering issues. Thus, with outsourcing decisions that increase the need for internal engineers to manage suppliers, resulting in reduced employee satisfaction levels can adversely impact product performance.
People are invested in their knowledge and they want to apply and enhance it. Engineers want to do value engineering. The implication is that product sourcing and downstream product execution decisions need to consider the interests of the engineering community. While outsourcing of engineering work may be necessary, we recommend that OEM organizations take a careful look at the motivations of the engineering personnel now assuming program
132

management tasks. As companies continue to outsource more and more work, it becomes necessary to manage more and more supplier relationships. To continue to offer quality employees fulfilling assignments, it may become necessary to evaluate not only hiring high potential engineers, but in addition program management individuals, allowing for a clear separation of responsibilities with the intention of increasing employee satisfaction.
Figure 79 - System Engineering Efficiency Loop
Knowledge of Supplier Ability
Internal Resource Burden
Internal Discipline
Cascade (Up/Dow orizontal) Efficiency
Customer Knowledge
Supplier Discipline
System Engineering Efficiency Reinforcing Loop
Number of Programs
+
+
Internal Capability ework
1111 ewok
Product Outcome
+Supplier apability
In what we call the system engineering reinforcing loop, the number of engine programs again becomes a key leverage factor to effect positive product performance. In this case, however, the variable "cascade efficiency" is of fundamental importance relating to system engineering up/down cascading. For instance, the engine component targets are cascaded from the customer to the vehicle, the powertrain, the engine and its subsystems and ultimately to the specific component. Target cascade inefficiency causes component engineers to be less directly linked to customer wants. Thus, his or her customer knowledge suffers. "Up" cascading
133

happens when engine component groups need to drive cross commodity changes yielding significant workload affecting several upstream vehicle users. Hence, cascade inefficiency ultimately contributes to continually decreasing product performance.
Interview research provided a similar perspective to cascade efficiency. For instance, acquiring approvals from peer or higher-level organizations with respect to the vehicle system hierarchy often require substantial efforts:
"Too many people have to bless your changes. A $0.20 change to a fastener now requires 8 different organizations, not people but organizations, to sign off This will take at least 6 months and maybe a year."
Thus, opportunities exist with improvements to cascade efficiencies within systems engineering efforts. Analyzing the systems dynamics model with varying degrees of cascade efficiency underlines this opportunity. As a result, the figure below indicates that specific product performance targets could be achieved years earlier when cascade efficiencies are increased
(in addition to the possibility of achieving higher target levels in general).
134

Figure 80 - Product Outcome vs. Cascade Efficiency
80
0
.0 75
0)
E
0
70
2 65
0 60
-
.~55
00
Base
0 2.5 5
Time (years)
10% Greater Efficiency
7.5 10
-.- 20% Greater Efficiency
There always tends to exist competing levels of products attributes for a given component or system. As attributes are cascaded from the vehicle level down, cascade efficiency up and down is low. In addition, information flow and power struggles across organizational boundaries also slow down the development process. These inefficiencies can create a large time delay in regards to achieving target attribute performance goals.
Thus, in order to improve cross-functional interface and cascade inefficiencies, one might consider the development of tools that enable enhanced knowledge transfer. MIT researchers, such as Paul Carlile 2 (Boundary Objects) and Dov Dori 4 (Object-Process Methodology) identified such tools in past research. Given human capability constraints and ever increasing system engineering complexities, boundaries between functional engineering activities will continue to be problematic. We recommend that further research by conducted to analyze above-mentioned tools to leverage the impact of cascade efficiency gains in product development cycle process.
2 Carlile, P. A Pragmatic View of Knowledge and Boundaries: Boundary Objects in New Product Development.
Working Paper. Cambridge, MA: MIT, August 15, 2000.
4
Dori, Dov. Systems Architecture: Systems Development with Object-Process Methodology. Presentation.
Cambridge, MA: MIT, September 22, 2000.
135

Figure 81 - Commodity Loop
Supplier Capability
Supplier iscipline
Internal Capability
Supplier Knowledge ol
Disc' line Technical nowledge ++
+ rroduct
Investment in R&D Commodity Reinforcing Loop
Outcome
Investment in Supplier Resources
Headcount Profit
Product Attribute Leadership
Supplier Burden +
Cost Reduction Efforts Premium $ Demanded ressure to Reduce Cost
C
Customers value product attributes. Thus, the more attribute leadership a product embodies the less the customer perceives it as a commodity and a manufacturer is less pressured to reduce product costs. The more a product is considered a commodity the less premium dollars the manufacturer can demand for it. This drives less R&D spending resulting into internal capability erosion relative to the competition. Furthermore, cost reduction efforts drive internal headcount and supplier investment reductions as well as degraded discipline. All of which causes a downward spiral.
136

Figure 82 - Supplier Capability vs. Pressure to Reduce Cost
M(A oo
-Base
80
60
40
0
0 2.5
5
Time (years)
7.5
10
Pressure TRC 10% Greater -.- Pressure TRC 10% Less
Figure 83 - Internal Capability vs. Pressure to Reduce Cost
50
40
-C
30
0
20
0 2.5
5
Time (years)
7.5
Base Pressure TRC 10% Greater -+- Pressure TRC 10% Less
10
137

Figure 84 - Product Outcome vs. Pressure to Reduce Cost
E
0
100
80
O.o 60
0
IL 20
0 2.5 5
7.5 10
Base
-
Pressure TRC 10% Greater
-.-
Pressure TRC 10% Less
We tested the model by varying the pressure to reduce variable by plus and minus 10% of base.
Results of this analysis are shown in the Figures 82 to 84. The interesting finding from this research is that the supplier capability reacts more quickly to cost pressures than the home organization. We believe that this is true because the OEM organization initiates cost cutting initiatives. There exists a time lag between the time that the initiatives are put in place and the time that effects are seen in regards to internal capability. On the supplier side, the response to cost cutting pressures are seen much earlier. This may happen for two reasons: 1) In economic downturns suppliers tend to feel the effects first (they are smaller organizations that are effected not only by the OEM, but also by much smaller tier 2 and tier 3 companies that tend to have smaller cash reserves to stave off economic pressures; and 2) suppliers tend to go "the extra mile" when the OEM organization is having financial difficulties, in order to assure that current projects remain solvent.
This latter example was elicited during the qualitative portion of this research and modeled by having a direct relationship between pressure to reduce cost and supplier burden variables; as opposed to having pressure to reduce cost filtered by a separate cost reduction effort. It is recommended that future users of such a model further develop the magnitude of change difference between supplier capability, internal capabilities and their net effect on product outcome.
138

In summary, cost reduction efforts have an immediate impact on supplier capability, but a delayed response to internal capability. This presents a dangerous situation to the OEM in terms of competitive advantage. An OEM, that has decided to outsource engineering efforts, is strongly dependent on supplier capabilities. As the OEM is more familiar with its internal capability, it is not directly knowledgeable about what happens to the supplier capability. Thus, the OEM sees results of cost reduction efforts too late and inherent internal capability effects require some time to be corrected. Ultimately, the OEM becomes more dependent on incapable suppliers, thus causing their products to become commodities to the customer. Thus, monitoring supplier activities and capabilities could be competitive advantage. This action would be an early indicator to understanding whether cost reduction efforts will cause product performance issues seen when the product development cycle is completed some years down the road.
Since the OEM cannot do much to reduce the early anticipatory cost reduction efforts of the supplier, one response may be to reduce the cost cutting initiatives that the OEM places on the supplier and instead shift that burden in-house. This will not reduce the effect of earlier product performance degradation but will allow for a reduction in the total product performance degradation that ensues. An example of such behavior is illustrated below. For this modeling test, the effects of the cost reduction effort variable were reduced by approximately 10% from the supplier side and shifted internally (see Figure 85).
Figure 85 - Cost Reduction Emphasis Switch
W~
0
80
E 60
0 o 40
2
0
-Base
2.5 5
Time (years)
7.5
PTRC + 10%
10
-.- Cost Burden Shift
139

Figure 86 - Supplier Capability Loop
Supplier Resource burden
Knowledge of Supplier Ability
Internal Discipline
Knowledge
Investment in Supplier Resources
Supplier Relationship Reinforcing Loop
Supplier apability
Trust+
+
Level of R elatioTtship
Pressure to Re uce Cost
Supplier Capability Reinforcing Loop
Shadow ngineering +
Cost Reduction Efforts
Headount Technical Knowledge
Internal Capability
Internal Resource Burden
The figure above shows an interaction between two distinct structures, the supplier relationship and capability reinforcing loops. Both loops intersect at the decision rule 'supplier capability'.
Improving supplier capability reinforces itself by means of improving supplier-OEM relationships enabled by more trust, and by positively effecting decisions rules that are linked within the supplier capability loop. Suppliers are part of the extended network delivering product performance, thus decision rules that improve supplier relationships and enhance supplier capabilities will ultimately help the OEM. Decision rules need to be applied that view the supplier as a strategic partner. While necessary to improve efficiencies, cost reductions can ultimately lead to downward spirals.
Outsourcing of engineering work to suppliers caused a non-anticipated function, and that is shadow engineering. Shadow engineering increases because supplier abilities are not trusted in
OEM activities outside engineering (i.e. plants) and because there is only limited supplier
140

access to confidential data. Interview research substantiates this development as expressed in the following quotes:
"One advantage we have with keeping design inside, is that we can freely argue amongst ourselves whereas suppliers find it difficult to argue design issues with us. Suppliers can't tell customer that they are wrong."
"Inability to treat supplier as replacement for a in-house engineer. We don't trust suppliers.
Plants comments are: 'I want to see our engineer that is in charge'."
However, there is a strong recognition in the organization analyzed that a trusting supplier relationship could help product performance:
"With great supplier relationship you get better ideas from suppliers."
While counterintuitive, we argue that a reduction in shadow engineering builds trust. Ultimately, trust will build supplier capability and benefit the OEM. In order to test this premise, we varied shadow engineering plus/minus 25% in the system dynamics model and compared it to the base case as described in the figure below.
Figure 87 - Product Outcome vs. Shadow Engineering
80
0
70
E
0
~.60
U
0
* 50
0
_ 40
0 2.5 5
Time (years)
7.5 10
Base Shadow Eng 25% Greater
-. Shadow Eng 25% Less
As discussed above and consistent with quantitative research, improving supplier proximity, i.e.
relationship and trust, will provide opportunity for improved organizational performance. There
141

are many reasons for that. First, with trust the OEM organization can reduce the amount of shadow engineers, thus improving trust. Second, suppliers can operate more efficiently as they will get better access to data and they are respected by OEM activities. As understanding what constitutes trust was not part of this study, we recommend further research identifying trust enablers for product development networks.
142

In this research we have constructed and tested a framework for understanding how decision rules develop and are employed at both the executive and front line levels of a product development organization. The work also illustrates how appropriate decision rules may be applied at pivotal PD events to assure highest product quality. Furthermore, it demonstrates how inappropirate decision rules can instill downward spiraling effects that can cause an organization to keep repeating mistakes/processes that lead to degrading product performance.
In addition, this thesis demonstrates how a system dynamics model can be developed to evaluate decision policies and their consequences on the organizational relationships and product performance. More importantly, the tools developed within this research can enable organizations to improve their decision-making methodology and deepen the understanding of how the home organization functions in the context of its products, employees, suppliers, competitors and customers.
Decision rules typically applied during product development decisions focus primarily on tangible elements, such as cost and timing. This research showes the merits of decision rules that also value intangible elements around staffing, careers, capability, rewards, and relationships.. Hence, organizations driven by traditional systems that value short-term pay-off could derive major breakthroughs from policy changes that valued intangibles in decisionmaking.
Surprising downstream impacts of intangible decision factors became apparent in several parts of this research. Intangible decision parameters included within product development OEM-
Supplier system dynamics, developed throughout this study, can cause either continuously reinforcing success outcomes or downward spiraling organizational performance. Key findings impacting organizational performance can be summarized as follows:
* Management leadership significantly impacts product performance and thus warrants the development of organizational human resource mechanisms that emphasize leadership principles in reward structures
" Attracting quality people is not sufficient for organizational success. Additional alignment of career development and compensation packages to career aspirations ultimately preserves and extends in-house technical knowledge
143

* Engineering outsourcing actions require adjustment of employee allocation to match employee skill level and desire to required program management and engineering tasks
* Leverage of information cascade efficiencies improves product's time to market
* Sustained cost reduction efforts reinforce downward product performance spirals.
Downward product performance spirals can ultimately lead to devaluing of the product to the point where it becomes a commodity
* OEM-Supplier networks need to emphasize long-term supplier capability and relationship building
* Reward structure actions to enforce upfront planning as opposed to fire-fighting can improve product quality long-term
Addressing the last bullet point, additional research in this thesis showed that fire fighting has implications beyond what was expressed in Repenning and Sterman.
38
In a constant fire-fighting mode, skewed front line engineering vision about the supplier could ultimately result in misconceived decisions and opportunities optimizing the value of supplier relationships are lost.
System dynamics testing emphasized that proper upfront planning reduces the need for downstream fire fighting. This further motivates reward structure actions expressed above.
Unfortunately, we must realize that benefits from some of the most important factors, such as the intangibles, often cannot be quantified. As demonstrated via system dynamics testing, intangible decision rules show their importance with substantial time lags (three to five years later). Traditionally, employees are deployed to other programs or jobs within a shorter timeframe, thus there is less incentive to drive decision-making based on intangibles since rewards and recognition programs are most often based on short-term merits. Mitigating accountability issues through prolonged job rotations could enable the inclusion of intangible decision rules into product development decision-making.
What we termed "misalignment" of decision rules across levels in the organization did not prove to impede corporate objectives. However, there exist unique decision rule sets that can best enable corporate objectives (in this case, demonstrate correlation to positive outcomes). For automotive PD organizations, improvements in product performance were demonstrated when the following decision rule sets were used:
38 Repenning, Nelson P. and Sterman, John D., Nobody Ever Gets Credit for Fixing Problems that Never Happened:
Creating and Sustaining Process Improvement, MIT Sloan School of Management, 2001.
144

"
Enterprise level outsourcing decisions prioritize: competition, supplier capability, supplier proximity, and customer proximity and product performance as decision rules.
* Front line product development execution decisions value: competition, OEM resource burden, supplier capability, and internal capability as decision rules.
However, given that product development decision rules vary over time, one must not assume that these decision rule sets hold for all pivotal decision-making events and/or automotive PD organizations. Traditionally automotive organizations maintain records of key decisions, but rarely are underlying decision rules and decision rule drivers documented. In order to take advantage of analytical tools (i.e. systems dynamics modeling and analytical hierarchy process) predicting future behavior, lessons databases that maintain decisions need to be expanded to decision rules and their drivers.
Furthermore, since decision rules vary over time, there exist implications to knowledge management in product development and the product development process itself. With varying decision rules, locally optimized knowledge management and data access issues will prove inefficient as information required to make the decisions continues to change as well. Given that change in general is difficult for product development teams to accept, the danger is that old knowledge stays with decision rules that are not state of art. Thus, the following organizational policy changes are beneficial:
* Instill a mindset of changing decision rules as an integral part of product development as part of corporate training classes on decision-making
" Reduce departmental chimneys to quickly adapt stakeholders to changing decision rules
* Improved documentation of decision rule changes mitigating in confusion over time and across organizational levels.
The aforementioned are not easy tasks to accomplish due to the effect of decision rule drivers
(i.e. corporate, functional and personal objectives), changeover in work force and the inherent time delay between engineering decision events and product field performance.
Given that decision rules change within product development efforts, product development processes with slowly converging design spaces prove more flexible. Holding the space open for as long as possible thus enables meeting changing competitive environment and customer
145

demand fluctuations. In contrast, currently US automotive manufactures freeze design spaces two to three years before product introduction.
Not all corporate goals are effective. Reasons may lie in the "cascade ability" of individual goals.
Goals such as 'improved customer satisfaction' are inherently better understood at all levels of the organization because each employee a.) knows what it means to be the consumer and can put themselves in the customer's shoes, and b.) can attribute the work tasks that they are performing today to a final product performance level through metrics such as improved handling, cost of ownership, serviceability, competitive features. On the other hand, corporate goals such as 'improved shareholder value' do not translate well to all employee responsibility levels. How easily can the front line level engineer equate his design or testing results to the company's stock price or P/E ratio? It's inevitable that corporations will continue to publish highlevel goals and mission statements to inspire stakeholders of all kinds. The implication is that if these goals are not easily translated into personal objectives for its employees, these corporate objective will become nothing more than another "flavor of the month"; an initiative that has no meaning to its front line personnel.
Enterprise as well as front line staff employees are driven by personal, functional, and corporate objectives. Ultimately, all three objectives are important. Consequently, decision rule drivers indirectly impact corporate success or failure and are the essence and leverage point for organizations. Emphasizing corporate over personal objectives can lead to motivational and employee retention issues. The organization must find a way to a.) motivate employees based on their own unique set of personal objectives, and b.) correlate this reward structure to match higher level, corporate objectives.
As mentioned in the literature section of this thesis, further research in organizational decision rules or policies might ultimately result in organizational evolution (via decision rule evolution) similar to biological systems (via gene re-combinations). Understanding biological evolution means understanding "genetic material", how emergent genetic material can arise and how genetic material when manipulated results in evolution of organisms. Further organizational decision rule research might take the same route. Moreover, our research already indicates several opportunities for decision rule evolution. Thus, actively pursuing the introduction of intangible decision rules into corporate decision-making and capturing synergy or recombination effects, by creating matched sets of enterprise strategic and front line execution decision rules, are two potential ways to achieve organizational evolution for the better in product development.
146

Beyond the issue of decision rules, this study also surfaced the criticality of system interfaces. In complex product development environments, boundaries between activities such as finance, engineering, marketing and other functional areas are inherent due to human capability constraints. Interfaces such as OEM-Supplier boundaries, functional relationships due to systems engineering, and human (i.e. management to staff) boundaries surfaced as problematic in this study. We believe that further organizational evolution can be accomplished by improving system interface efficiencies across these boundaries. Therefore, further study should be conducted to develop tools that improve knowledge transfer across necessary boundaries in complex product development systems.
The problematic nature of system interfaces was recognized within thesis research project as well. One of the keys to the success of this project was the development and use of boundary objects as the primary method for establishing open communication and crossing knowledge boundaries. Boundary objects such as graphic representations of decision-making frameworks, data plots, and other shared documents were pivotal in establishing a common point of reference for both the interviewer and the research participants.
147

Apostolakis, George. Engineering Risk-Benefit Analysis. Class Notes. Cambridge, MA: MIT, February 7,
2000.
Boppe, Charles. Systems Engineering. Class Notes. Cambridge, MA: MIT, June 6, 2000.
Brodie, Christina Heperner and Burchill, Gary. Voices into Choices - Acting on the Voice of the Customer,
Joiner Associates Inc., 1997.
Carlile, Paul. Organizational Behavior and Processes. Class Notes. Cambridge, MA: MIT, January 6,
2000
Carlile, P. A Pragmatic View of Knowledge and Boundaries: Boundary Objects in New Product
Development. Working Paper. Cambridge, MA: MIT, August 15, 2000
Christensen, C. M. (1995). Explaining the attacker's advantage: technological paradigms, organizational dynamics, and the value network, Research Policy 24, pp. 233-257.
Churchill Jr., Gilbert A. Marketing Research: Methodological Foundations, The Dyrden Press, 1999.
Clemen, Robert T., Making Hard decisions - An Introduction to Decision Analysis, Duxbury Press, 1996.
Clemen, Robert T. and Kwit, Robert C. (2000), The Value of Decision Analysis at Eastman Kodak
Company, 1990-1999, Joint Research Paper between Duke University and Eastman Kodak Company.
Crawley, Edward. 16.882 System Architecture. Class Notes. Cambridge, MA: MIT, September 10, 2000.
Drucker, Peter F., The Effective Decision, Harvard Business Review (January-February 1967), Reprint
67105.
Cutcher-Gershenfeld, Joel et al., Knowledge-Driven Work. Oxford University Press, 1998.
Dori, Dov. Systems Architecture: Systems Development with Object-Process Methodology. Presentation.
Cambridge, MA: MIT, September 22, 2000.
148

Fine, Charles H. (1998), Clock Speed: Winning Industry Control in the Age of Temporary Advantage,
Perseus Books, Reading, MA.
Fine, C., Whitney, D. (1996), "Is the Make-Buy Decision Process a Core Competence", MIT Center for
Technology, Policy, and Industrial Development.
Fine Charles. (2000). E-Clockspeed-based Principles for Value Chain Design, MIT/SDM Class
Presentation, July 2000.
Franklin, Benjamin (London Sep. 19th, 1772), A Letter Titled "Morale or Prudential Algebra", published in
Harvard Business Review (March-April 1998), Reprint 98206.
Forrester, Jay W. 1961. Industrial Dynamics. Portland, OR: Productivity Press.
Ford Motor Company - Europe, Potential High Impact Supplier Selection Rationale, Ford Motor Company internal document, 1998.
Hammond, John S., Keeney Ralph L., and Raiffa Howard, Even Swaps: A Rational Method for Making
Trade-offs, Harvard Business Review (March-April 1998), Reprint 98206.
Hammond, John S., Keeney Ralph L., and Raiffa Howard, The Hidden Traps in Decision Making, Harvard
Business Review (September-October 1998), Reprint 98505.
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, pp. 9-30
Hines, Jim and House, Jody, Policy Evolution within an Organization, MIT Research Paper.
Hines, Jim and House, Jody, Harnessing Evolution For Organizational Management, MIT Research
Paper
Hoch, Stephen J., Combining Models with Intuition To Improve Decisions. John Wiley and Sons, Inc.,
2001.
Lyneis, Jim and Warmkessel, Joyce, System and Project Management. Class Notes. Cambridge, MA:
MIT, September 10, 2000.
Miller, G.A, "The magic number seven, plus or minus two: Some limits on our capacity for processing information," An Essay in the psychology of communication, Basic Books, 1967.
149

Pilot industries brochure, Steel Fuel Tank Sales, 2001.
Raiffa, H., Decision Analysis, Addison-Wesly, Reading, MA, 1968.
Repenning, Nelson P. and Sterman, John D., Nobody Ever Gets Credit for Fixing Problems that Never
Happened: Creating and Sustaining Process Improvement, MIT Sloan School of Management, 2001.
SAP AG, Automotive - Supplier Solution Map, SAP Ag internal document, 1999.
Simon, Herbert A. Models of Bounded Rationality, Volume 3, The MIT Press, Cambridge, MA.
Simon, Herbert A., An Empirically Based Microeconomics, Cambridge University Press, 1997.
Sobek, Durward K., Ward, Allen C., Liker, Jeffrey K., Toyota's principles of set based concurrent engineering, MIT Sloan Management Review (Winter 1999, Vol. 40, Number 2), Reprint 4025.
SPSS Inc., SPSS 10.0 and SPSS 10.0 Base Brief Guide, Prentice-Hall Press, 2000.
Sterman, John D., Business Dynamics - Systems Thinking and Modeling for a Complex World, Irwin
McGraw-Hill, 2000.
Ulrich, K.T. and Eppinger, S.D., Product Design and Development, McGraw-Hill, New York, 1995 (1st edition) and 2000 (2nd edition).
US Congress Report 1016 - Investigation of the Challenger Accident
Vensim PLE Plus 32 Version 4.2a, Ventana Systems, Inc., 1999
Ward, Allen C., Liker, Jeffrey K., Cristiano, John J., Sobek, and Durward K., The second Toyota paradox:
Delaying decisions can make better cars faster, MIT Sloan Management Review (Spring 1995, Vol. 36,
Number 3), Reprint 3634.
Yassine, Ali and Chelst, Kenneth. Opportunities for Decision Analysis in Engineering and Manufacturing
Management: An Overview, MIT Research Paper.
150

Introduction:
We are conducting a survey among Ford Engineering and Purchasing activities relating to V-Engine components. The purpose of the research is to find out what you and other experts think about the quality effects of engine component outsourcing. The results of the survey will aid both an internal research project and an independent thesis which fulfills degree requirements for the MIT Systems
Design and Management Program. Your answers will enable our Product Development activities to better understand the relationships between decision making (in respect to outsourcing and supplier relationships) to product quality.
You have been identified as a key member on the product development management team. Your answers are very important to the accuracy of our research. It will take only a short time to answer the simple questions on this questionnaire. Please complete the questionnaire prior to, and bring with you, to the October 3rd interview session.
Of course all answers are confidential and will be used only in combination with those of other V-Engine component engineering and purchasing representatives. Any confidential and sensitive information will be cleansed prior to any formal thesis publication.
Thank you for your help.
Hans Schumacher
Donald Mecsey
151

Participant Demographics:
1.) Please indicate your gender.
2.) Please indicate your area of responsibility.
Engineering Purchasing
Male Female
3.) Please indicate your current leadership level within this OEM.
GSR LL6/Tech. Specialist LL5/LL4
4.)
5.)
How many years of experience do you currently have with this
OEM.
Years
How many years of experience do you have which relates directly to the V-Engine.
LL3/Above
Years
Outsourcing Example
1.) From the list below, please identify 1 V-Engine component that you are familiar with, that has been outsourced in the past ten years
(Choose one only)
Valve Train Rocker Arm
Piston
Intake Manifold
Fuel Rails
Thermostat
Water Pump
Exhaust Manifold
FEAD
Cylinder Head Gasket
Sealing Die/Cast Alum Covers
2.)
3.)
What Model Year do you consider that component to have been outsourced to a Full Service
Supplier?
For the component identified, please indicate who has primary responsibility for each of the following:
At Time Of
Outsourcing
QEM pier
Drawings
SREA
APQP
Tools (CAE/CAD, FEA, CFD)
Key Life Testing
Comp. DV/PV Testing
DVP&R
DFMEA
ES-Spec
MY2000
QEM
MY a" r
152

The following questions should be answered as to how the Team made decisions to outsource engine components
When the TEAM made the key decision to outsource particular components, how you rate the importance that the TEAM placed on the following:
1.) OEM's resource capability (availability, allocation, capacity) ?
1
No Priority
2 1 3 1 4
High Priority
2.) The level of change or innovation associated with the part ?
1
No Priority
2 3 4
High Priority
3.) Performance metrics such as R/1000 and CPU?
1 1
No Priority
2 3 1 4
High Priority
4.) Quality of comparable competitive products?
1 |
No Priority
2 1 3 1 4
High Priority
5.) Department goals and objectives?
1
No Priority
2 3 4
High Priority
6.) Number of of different part numbers associated with the component?
71
No Prionty
2
3
4
|
High Priority
7.) Number of different suppliers associated with the component?
1 1
2
No Pnority
|
3 1 4
High Priorty
8.) WCR, DVP&R and FMEA adherence?
1 1
2 | 3 1 4
No Priority High Priority
9.) The supplier's manufacturing assets (facilities and tooling)?
No
1 1
2 1 3 1 4 |
Priority HIgh Priority
10.) The suppliers component knowledge?
153

11.) Shareholder value?
12.)
Nrior
Supplier Technical Assistance involvement?
NO Prorit g rority
Hig Pririty
13.) Supplier's quality?
NOProit i Pri ty
14.) The cost and timing of a comparable competitor's component ?
No Prorit Hig Pririty
15.) The supplier's trustworthiness?
NO Prorit Rig Pririty
16.) The resulting (@ Job 1) part's cost and timing (vs. objective)?
No Prorit Hig Pririty
17.) Attribute and functional performance of a comparable competitor's product?
NO
Prorit Rig Pririty
18.) Rewards and opportunities (bonus, promotion, etc.)?
NO Prorit Hig Pririty
19.) The integration (number and type of functional interfaces) associated with the component?
No Prorit Hig Pririty
20.) The cost & timing objectives for this particular component?
Norioriy rI Pr ity
154

21.) OEM's process discipline (PTPRP, FPDS, etc.)?
No
Prorit
Hig Pririty
22.) OEM's component knowledge and integration expertise?
NOPriiy i rity
23.) The level of interaction that the component TEAM had with OEM's Systems Engineering, Testing, Quality,
Manufacturing and Marketing activities?
No Prorit Hig Pririty
24.) Individual opportunities within OEM (growth, experience)?
NO
PrioitriHi
25.) The supplier's cost and timing capability for this component?
y
No Prorit Hig Pn~rity
26.) Number of other OEM customers that the supplier is providing this component to?
No Pioriy Hih Prrity
27.) The supplier's ability in sharing of technical knowledge and data/information?
NO Prorit Hig Pririty
28.) Location of supplier's design and manufacturing facilities?
N rity ighority
29.) Number of New Model Year programs this part is supporting?
No Prorit Hig Pririty
30.) Existing OEM infrastructure (organizational hierarchy, reporting relationships)?
Noiriy Hi rity
155

31.) Number of functional and attribute requirements this component has to met?
No Pioriy Hih Prority
32.) Level of supplier component engineering responsibility required (such as drawings, DVP&R, Key Life Test, FMEA, etc.)?
NO
Pioriy Hih Prority
33.) Incorporation of lessons learned, customer clinic data, and quality survey data by OEM?
No
Pioriy
Hih
Prority
34.) Employee satisfaction?
No Pioriy Hih Prority
35.) Number of capable and competitive component suppliers?
No Pioriy Hih Prority
36.) Customer satisfaction?
No Pioriy Hih Prority
37.) Local/departmental traditions?
No Pioriy Hih Prority
38.) Work-life balance?
No Pioriy Hih Prority
39.) Flexibility and responsiveness (change control process) of the supplier?
rity i ority
156

Reference Modes
1.) Component Complexity:
Consider component complexity to be a function of:
# of part numbers
# of suppliers
# of new programs functional connectivity to the engine level of change and innovation
# of functional attributes cost and timing
Please qualitatively plot component complexity over time
2.) OEM Capability:
Consider OEM's capability to be a function of: internal culture to achieve resource availability component and integration expertise process discipline
Please qualitatively plot OEM's capability over time
3.) OEM's Customer Knowledge:
Consider customer knowledge to be a function of:
WCR/DVP&R/FMEA adherence incorporation of lessons learned incorporation of quality survey data level of interaction with (eng. systems, quality, mfg.)
Please qualitatively plot OEM's customer knowledge over time
4.) Supplier Capability:
Consider supplier capability to be a function of: manufacturing assets design and development knowledge cost and timing quality
Please qualitatively plot supplier capability over time
Level of
Component Complexity
Hight
Med
Low
MY94
Outsourcing
MY
Level of
OEM capability
High
Med
Low
MY94 Outsourcing
MY
Level of
OEM customer knowledge
Hight
Med
Lnw
Low
MY94
,P
Outsourcing
MY
Level of
Supplier cap
High bility
Med
Low
MY94
Outsourcing
MY
MYO1
MYO1
MY01
MY01
157

5.) Supplier Working Relationship:
Consider supplier capability to be a function of: location of design and manufacturing facilities technical knowledge and data sharing supplier flexibility and responsiveness trustworthiness
Please qualitatively plot supplier working relationship over time
6.) OEM competition:
Consider OEM competition to be a function of: cost and timing attribute performance quality
Please qualitatively plot OEM competition over time
7.) Product performance
Consider product performance to be a function of: cost and timing vs. objective quality performance attribute performance vs. objective
Please qualitatively plot product performance over time
Level of
Supplier working relationship
High
Med
Low
MY94
Outsourcing
MY
Level of
OEM competition
Hight
Med
Low
MY94
Outsourcing
MY
Level of product performance
High+
Med
Low
MY94 Outsourcing
MY
MY01
MY01
MYO1
Thank you for participating in our survey!
158

Introduction:
We are conducting a survey among the Engineering and Purchasing activities relating to V-Engine components. The purpose of the research is to find out what you and other experts think about the quality effects of engine component outsourcing. The results of the survey will aid both an internal research project and an independent thesis which fulfills degree requirements for the MIT Systems
Design and Management Program. Your answers will enable the Product Development activities to better understand the relationships between decision making (in respect to outsourcing and supplier relationships) to product quality.
You have been identified as a key member on the exhaust manifold product development team. Your answers are very important to the accuracy of our research. It will take only a short time to answer the simple questions on this questionnaire. Please complete the questionnaire prior to, and bring with you, to the September 28 interview session.
Of course all answers are confidential and will be used only in combination with those of other V-Engine component engineering and purchasing representatives. Any confidential and sensitive information will be cleansed prior to any formal thesis publication.
Thank you for your help.
Hans Schumacher
Donald Mecsey
159

Participant Demographics:
1.) Please indicate your gender.
2.) Please indicate your area of responsibility.
Engineering Purchasing
Male Female
3.) Please indicate your current leadership level within OEM.
GSR LL6/Tech. Specialist LL5/LL4
4.) How many years of experience do you currently have with OEM.
Years
5.) How many years of experience do you have which relates directly to the product in question.
LL3/Above
Years
Component Background:
1.) What Model Year do you consider the exhaust manifold to have been outsourced to a Full Service Supplier?
2.) Please indicate who has primary responsibility for each of the following:
At Time Of
Outsourcing
OEM Supplier
Drawings
SREA
APQP
Tools (CAE/CAD, FEA, CFD)
Key Life Testing
Comp. DV/PV Testing
DVP&R
DFMEA
ES-Spec
MY2000
MY
OEM Supplier
The following questions should be answered in terms of how the exhaust manifold TEAM made decisions from the time you consider the part to be outsourced
6
160

The following questions should be answered in terms of how the exhaust manifold TEAM made decisions from the time you consider the part to be outsourced.
When the exhaust manifold TEAM made key PD decisions, importance that the TEAM placed on the following: how would you rate the
1.) OEM's resource capability (availability, allocation, capacity) ?
1
No Priority
2 3 4
High Priority
2.) The level of change or innovation associated with the part ?
1
No Priority
2 3 4
High Priority
3.) Performance metrics such as R/1000 and CPU?
1
No Priority
2 3 4
High Priority
4.) Quality of comparable competitive products?
1
No Priority
23 4
High Priority
5.) Department goals and objectives?
NO Fhont Rig Pnoty
6.) Number of of different exhaust manifold part numbers?
7.) Number of different exhaust manifold suppliers?
Nu ty
8.) WCR, DVP&R and FMEA adherence?
NO F-InIy
9.) The supplier's manufacturing assets (facilities and tooling)?
MYgn rn0nty
I~prnpty
10.) The supplier's component knowledge?
161

11.) Shareholder value?
NO Piont Hig Pririty
12.)
Supplier Technical Assistance involvement?
No
Prorit
Hig
Pririty
13.) Supplier's quality?
No Fiont Hig Pririty
14.) The cost and timing of a comparable competitor's component ?
No Pronty igh rity
15.) The supplier's trustworthiness?
No Hrority High rity
16.) The resulting (@ Job 1) part's cost and timing (vs. objective)?
No Hiont Hig Pririty
17.) Attribute and functional performance of a comparable competitor's product?
No
Pionl Hig Pririty
18.) Rewards and opportunities (bonus, promotion, etc.)?
No Fiont Hig Pririty
19.) The integration (number and type of functional interfaces) associated with the component?
20.) Thprtiariy c n n rity
20.) The cost & timing objectives for this particular component?
No Prorit Hig Pririty
162

21.) OEM's process discipline (PTPRP, FPDS, etc.)?
No Prorit Hig Pririty
22.) OEM's component knowledge and integration expertise?
No Prorit Hig Pririty
23.) The level of interaction that the component TEAM had with OEM's Systems Engineering, Testing, Quality,
Manufacturing and Marketing activities?
No Prority High ri ty
24.) Individual opportunities within OEM (growth, experience)?
No Prorit Hig Pririty
25.) The supplier's cost and timing capability for this component?
Noririty ighrity
26.) Number of other OEM customers that the supplier is providing this component to?
No Prorit Hig Pririty
27.) The supplier's ability in sharing of technical knowledge and data/information?
No Prorit Hig Pririty
28.) Location of supplier's design and manufacturing facilities?
No Prorit Hig Pririty
29.) Number of New Model Year programs this part is supporting?
3. Exsigton hiry, rrity
30.) E xisting OEM infrastructure (organizational hierarchy, reporting relationships)?
No Prorit Hig Pririty
163

31.) Number of functional and attribute requirements this component has to met?
No y Hirioty
32.) Level of supplier component engineering responsibility required (such as drawings, DVP&R, Key Life Test, FMEA, etc.)?
NO ny n rig ty
33.) Incorporation of lessons learned, customer clinic data, and quality survey data by OEM?
NO nyi orIg ty
34.) Employee satisfaction?
No yriority
35.) Number of capable and competitive component suppliers?
No iy g Hi ty
36.) Customer satisfaction?
Noyigfly ri ty
37.) Local/departmental traditions?
NOPiory i ty
38.) Work-life balance?
NO ny g RiMIty
39.) Flexibility and responsiveness (change control process) of the supplier?
No Hiy Rig ty
164

Exhaust Manifold Reference Modes
1.) Component Complexity:
Consider component complexity to be a function of:
# of part numbers
# of suppliers
# of new programs functional connectivity to the engine level of change and innovation
# of functional attributes cost and timing
Please qualitatively plot component complexity over time as it relates to the exhaust manifold.
2.) OEM Capability:
Consider OEM's capability to be a function of: internal culture to achieve resource availability component and integration expertise process discipline
Please qualitatively plot OEM's capability over time as it relates to the exhaust manifold.
3.) OEM's Customer Knowledge:
Consider customer knowledge to be a function of:
WCR/DVP&R/FMEA adherence incorporation of lessons learned incorporation of quality survey data level of interaction with (eng. systems, quality, mfg.)
Please qualitatively plot OEM's customer knowledge over time as it relates to the exhaust manifold.
4.) Supplier Capability:
Consider supplier capability to be a function of: manufacturing assets design and development knowledge cost and timing quality
Please qualitatively plot supplier capability over time as it relates to the exhaust manifold.
Level of
Component Complexity
Hight
Med
Low
MY94
Outsourcing
MY
Level of
OEM capability
Hight
Med
Low
MY94 Outsourcing
MY
Level of
OEM customer knowledge
Hight
Med
Low
MY94 Outsourcing
MY
Level of
Supplier capability
Hight
Med
Low
MY94
Outsourcing
MY
MY01
MY01
MY01
MYO1
165

5.) Supplier Working Relationship:
Consider supplier capability to be a function of: location of design and manufacturing facilities technical knowledge and data sharing supplier flexibility and responsiveness trustworthiness
Please qualitatively plot supplier working relationship over time as it relates to the exhaust manifold.
6.) OEM competition:
Consider OEM competition to be a function of: cost and timing attribute performance quality
Please qualitatively plot OEM competition over time as it relates to the exhaust manifold.
7.) Product performance
Consider product performance to be a function of: cost and timing vs. objective quality performance attribute performance vs. objective
Please qualitatively plot product performance over time as it relates to the exhaust manifold.
Level of
Supplier working relationship
Hight
Med
Low
MY94 Outsourcing
MY
Level of
OEM competition
Hight
Med
Low
MY94 Outsourcing
MY
Level of product performance
High
Med
Low
MY94 Outsourcing
MY
MY01
MY01
MY01
Thank you for participating in our survey!
h
166

Competition Alignment Table
Quality Competitive Product
Mean
No priority low priority
Count
Count med priority Count high priority Count
Total Count
Criteria
I
>60
ALIGNMENT EVALUATION
>30 >20 >20 >0.5
Front Line
2.8
26
10
43
2
9
6
5
22
23
100
I
Enterprise
2.9
No/low vs.
All Priority med/high
Priority No Priority High Priority Mean
5
50
1
10
4
40
10
100
Delta j4
9
24
33
18
04
15
-15
35U
-9
V
18
X an
15
U.1
Product Complexity Aiignment Table
Number and Type of
Functional Interfaces
No priority low priority med priority high priority
Total
Mean
Count
Count
Count
Count
Count
Front Line
2.2
7
30
7
30
6
26
3
13
23
100
Criteria
Enterprise
2.0
3
30
5
50
1
10
1
10
10
100
0ea
>60
ALIGNMENT EVALUATION
>30 >20 >20 >0.5
No/low vs.
All Priority med/high
Priority No Priority High Pri ority Mean
0
20
16
3
19
-19
5
0
U
3
U.
Number of Programs
Mean 2.4
No priority low priority med priority high priority
Total
Count
Count
Count
Count
Count
____ ___ ____ ___ ___ ____ ___ ____ ___ __I
4
17
10
43
5
22
4
17
23
100
2.0
1
10
10
100
4
40
3
30
2
20
Delta
23
13
2
7
U~I~d r4a
9
-9
H
1S
23
I
7
%.q
167

Internal Capability Alignment I able
WCR, DVP&R, FMEA
Adherence
Mean
No priority low priority med priority high priority
Total
Count
Count
Count
Count
Count
Criteria
Front Line
2.9
Enterprise
2.6
30
9
39
23
100
5
22
2
9
7
1
10
5
50
1
10
3
30
10
100
Delta
>60
ALIGNMENT EVALUATION
>30 >20 >20
No/low vs.
All Priority med/high
Priority No Priority High Priority
12
41
20
9
5
30
-30
59
-12
12
9
OEM's Knowledge & Expertise
Mean
No priority low priority med priority high priority
Total
Count
Count
Count
Count
Count
6
26
9
39
3
13
5
22
23
100
2.9
I
1
10
4
40
5
50
10
100 eita
2.4
3
18
24
39
0U
15
-15
-3
3
39
>0.5
Mean
U.3
-I
Product Performance Alignment Table
Part Cost and Timing vs.
Objectives
Mean
No priority low priority
Count
Count med priority Count high priority Count
Total Count
Criteria
Front Line
3.2
13
10
43
9
1
4
3
39
23
100
I
Enterprise
2.7
2
20
2
20
3
30
3
30
10
100
Delta
>60
ALIGNMENT EVALUATION
>30 >20 >20 >0.5
No/low vs.
All Priority med/high
Priority No Priority High Pric )rity Mean
13
9
16
7
4b
23
-23
4b 1
16
9
168

Supplier Capability Alignment I able
Supplier Manufacturing Assets
Mean
No priority low priority
Count
Count med priority Count high priority Count
Total Count
Criteria >60
ALIGNMENT EVALUATION
>30 >20 >20 >0.5
Front Line Enterprise
3.0 2.7
No/low vs.
All Priority med/high
Priority
13
11
48
2
9
3
7
30
23
100
1
10
10
100
4
40
5
50
I ueita I
9
27
2
20 u st
18
-18
.5
No Priority High Priority Mean
-9
20 zu U.3
Suppliers Component
Knowledge
Mean
No priority low priority med priority
Count
Count
Count high priority
Total
Count
Count
3.0
39
23
10(
17
8
35
9
2
9
4
3.5
Delta
50
10
100
5
50
5
9
17
15
11 b2
-26
26
-9
11
11 U
Number of other OEM's
Supplier supplies
Mean
No priority Count low priority Count med priority Count high priority
Total
Count
Count
2.3
5
22
8
35
9
39
1
4
23
100
2.4
4
40
1
10
2
20
3
30
10
100
Delta
18
25
19
26
88
-7
7
1d
18
18
26
2b U.1
Level of Supplier Responsibility
Mean 3.0
No priority low priority med priority high priority
Total
Count
Count
Count
Count
Count
2.7
3
14
5
23
9
41
5
23
22
100
I
2
20
6
60
2
20
10
100
Delta
14
3
19
3
J8
-16
16
3j
-14
14
3
169

Supplier Proximity Alignment able
Number of Competitive
Suppliers
Mean
Front Line
2.6
Criteria
Enterprise
2.8
I
>60
ALIGNMENT EVALUATION
>30 >20 >20 >0.5
No/low vs.
All Priority med/high
Priority No Priority High Pric )rity Mean
No priority low priority
Count
Count med priority Count high priority Count
Total Count
2
9
10
45
5
23
5
23
22
100
3
30
6
60
1
10
10
100
Delta
37
13
9
15
/b
-25
25
49
-9
9
13
13
U.2
Supplier Technical Assistance
Involvement
Mean
No priority low priority med priority high priority
Total
Count
Count
Count
Count
Count
2.1
7
30
9
39
5
22
2
9
23
100
I
10
100
Delta
1.7
4
40
5
50
1
10
10
11
12
9
41
20
-20
41
10
-lu
9
V U.4
170

Gorporate Goal Alignment I abie
Shareholder Value
No priority low priority med priority high priority
Total
Organizational Infrastructure
Mean
No priority low priority
Count
Count med priority Count high priority Count
Mean
Count
Count
Count
Count
Count
Criteria >60
ALIGNMENT EVALUATION
>30 >20 >20
1.8
9
39
10
43
3
13
1
Front Line
1.8
Enterprise
2.4
9
2
9
22
100
10
45
8
36
2
3
30
2
20
3
30
2
20
10
100
Delta
No/low vs.
All Priority med/high
Priority
15
16
21
11 b4
-32
32 b4
1.5
6
60
3
30
1
10
21
13
3
7
-7
No Priority High Priority Mean
-15
15
21
11
11
>0.5
U.6
Total Count
Customer Satisfaction
Mean
No priority low priority med priority high priority
Count
Count
Count
Count
Total Count
4
23
100
3.0
6
26
10
3
13
4
17
43
23
100
10
100
-e a
2.9
1
10
3
30
2
20
4
40
10
100
Delta
3
13
6
3
4
4Z 15
10
-10
21
-3 a
03
4
4
3
U.3
V.
W. I
171

Introduction (5min):
The purpose of this study is to investigate the decision making process with respect to supplier sourcing and product execution within V-Engine. What decision rules do senior management people use when selecting suppliers and what decision rules do front line engineering team apply when delivering the product in concert with the supplier. Well, a very important piece of this puzzle is what YOU think about decision-making before and after component outsourcing (since you are the people making it happen).
This is NOT a V-Engine Management mandated project. Don and I are classmates in an engineering management Masters program. This study is our final assignment.
We are very aware of how some people may feel about being candid in their responses to questions involving V-Engine dynamics and supplier outsourcing. We want to reinforce to you that we shall practice full confidentiality. This means:
1. We will not use personal names in reference to information gathered.
2. We will not use actual section names, program names or reference situations in such a way so the identity of persons involved could be implied.
3. Do not answer any question you are uncomfortable with.
4. We will not reference who did/did not participate.
We want this to be a fun and participatory exercise that can also help us understand our workplace a bit better and also lets us pass our class!
Component Survey (5min):
We gave and asked that you attempt to complete it in preparation to this interview. In case, you did not get a chance to complete it, would you mind to take 10 minutes now to fill it out?
1.) Do you have any questions?
Don't hesitate to ask questions. Your comments are very important.
Problem Statement (15 min):
"Ever since we started outsourcing engine components, some components have improved, but others have either not improved or perform worse in warranty. We believe that the recent spike in warranty coul be due to supplier outsourcing and we are concerned to not completely understand the systems dynamics. What can we do?"
A L
E ngine (R/1000; CPU)
FEAR
Level of
Supplier
Outsouring
172

Think again about the V-Engine Quality Performance with respect to MY94 until MYOO:
1.) What do you think are reasons, that may have caused engine quality to improve until MY98?
2.) What do you think are reasons, that may have caused engine quality to spike up?
3.) How likely is the FEAR curve and why?
4.) What can V-Engine do to achieve the HOPE curve and why?
Component Causal Parameters (15min)
Think again about your component specifically with respect to MY94 until MYO1:
5.) Describe some of the component outsourcing and supplier selection decision events, or other parameter that in your opinion let to successes with respect to your component. And why?
6.) Describe some of the supplier sourcing events and decisions that in your opinion let to failure wit respect to your component. And why?
Draw the components warranty performance.
7.) Why do you think this component has behaved in warranty as graphed?
8.) Imagine your component in the future. It meets all functional requirements and can be produced at very affordable cost. Describe some of the supplier sourcing decision rules that you would have put in place to achieve this performance.
Component Causal Parameter Reference Mode (20min)
Throughout our discussion thus far, we have heart you say that the following parameters are important to understand your components historic performance history and future strategies. They are as follows:
9.) Please choose ten parameters that you think are the most important to the successes or failures of your component?
10.) For some parameters, let's plot its values since MY94 until MYO1.
11.) Why do you think the plots behave like they do?
12.) How do you think will those parameters develop in the future?
173

Introduction (5min):
The purpose of this study is to investigate the decision making process with respect to supplier sourcing and product execution within V-Engine. What decision rules do senior management people use when selecting suppliers and what decision rules do front line engineering team apply when delivering the product in concert with the supplier. Well, a very important piece of this puzzle is what YOU think about decision-making before and after component outsourcing (since you are the people making it happen).
This is NOT a V-Engine Management mandated project. Don and I are classmates in an engineering management Masters program. This study is our final assignment for that course.
We are very aware of how some people may feel about being candid in their responses to questions involving V-Engine dynamics and supplier outsourcing. We want to reinforce to you that we shall practice full confidentiality. This means:
1. We will not use personal names in reference to information gathered.
2. We will not use actual section names, program names or reference situations in such a way so the identity of persons involved could be implied.
3. Do not answer any question you are uncomfortable with.
4. We will not reference who did/did not participate.
We want this to be a fun and participatory exercise that can also help us understand our workplace a bit better and also lets us pass our class!
Problem Statement (5min):
"Ever since we started outsourcing engine components, some components have improved, but others have either not improved or perform worse in warranty. We believe that the recent spike in warranty could be due to supplier outsourcing and we are concerned to not completely understand the systems dynamics. What can we do to achieve the HOPE curve?"
N
OW
Engine (R11000; CPU)
FEAR
Level of
Supplier
Outsouring
174

Think again about the V-Engine Quality Performance with respect to MY94 until MYQO:
1.) Describe the variables that could be related to the engine quality improvement until MY98?
2.) What do you think are some variables, that may have caused engine quality to spike up?
3.) How likely is the FEAR curve and why?
4.) What can V-Engine do to achieve the HOPE curve and why?
Component History (25min)
Draw the component warranty visible to all participants on a piece of paper.
Think about the history about your component from the early 90's until today:
5.) Describe some of the key events that happened in that timeframe. Key events could be organizational changes, corporate goal changes, functional directives, component strategy changes, supplier outsourcing, or other events.
6.) Tell us about the point in time when you would consider you component being outsourced. How would define outsourcing with respect to your component?
7.) Please describe the time before your component was outsourced?
8.) Can you tell us what changed after the component was outsourced?
Component Causal Parameters (10min)
Think again about your component specifically with respect to MY94 until MYO1:
9.) Describe some of the events, decision rules, or other parameters that in your opinion let to successes with respect to your component. And why?
10.) Imagine your component in the future. It meets all functional requirements and can be produced at very affordable cost. Describe some of the actions that you would have put in place to achieve this performance.
Component Causal Parameter Reference Mode (30min)
Throughout our discussion thus far, we have heart you say that the following parameters are important to understand your components historic performance and future strategies. They are as follows:
11.) Please choose ten parameters that you think are the most important?
12.) For some parameters, let's plot its values qualitatively since MY94 until MYO1.
13.) Why do you think the parameters behave like they do?
14.) How do you think will those parameters develop in the future? And why?
175

* OEM internal capability
* Supplier Capability
* Supplier Employee Turnover
* Supplier Willingness to become FSS
* Supplier Competitive Pressures
* OEM Teaching Capability
* Cost Cutting
* Working under distress
* Engineering Change Validation Capability
* Supplier Business Objectives
* OEM Business Objectives
* Level of Outsourcing (Des/Dev/Val/Mfg)
* Sharing of Drwg's, Tools among suppliers
* Design Change Leverage
* Level of internal tool development capability
* Engineers learning to become proficient
* Average Engineer in Job time
* OEM Competitor Capability
* Component Attribute Knowledge
* Management of Resources
* Management of Facilities
* Management of Documentation
* Systems Engineering Concentration
* Program Management Concentration
* Leadership in issue resolution
* # of suppliers
* Supplier Profits
* Supplier Process Capability
* Vehicle Program Turnover
* Mgmt. Ability to push back vehicle center wants
* Amount of Program Work
* Amount of rework (C&P, Black Belt)
* Time to force bad supplier out
* Perception of analytical tools
* Perception of Testing
* Supplier Quality
* Supplier Engineering Support
* Supplier Product Delivery
* # of Quality Vendors
* Level of Internal Vision (know your goals)
* Level of Internal Strategy Knowledge
* Level of Internal Strategy Execution
.
Time to develop FEA/CAE Tools
176

* Level of maintaining / extending in house capability
* Late changes
* Technical Innovation
* Relationship with Supplier
* Supplier / OEM Trust Factor
* Supplier Drive to Achieve
* Commonality
* Supplier Product Offering
* Amount of non-value added work
Incorporation of lessons learned
* Ability to predict customer duty cycles
* Quality Demand on Supplier
* Ability of engineers to be Data Driven
* Upfront planning
* Outside Pressure resistance
* Mgmt support
* Level of component documentation
* Amount of component testing
* Ability to prioritize work
* Component Section Structure
* Time to see strategy benefits
* Want to be an engineer
* Want to be a manager
* Flexibility in schedule, relationship, outside pursuits
* Real Engineer - empowerment
* Satisfaction in doing real engineering work
* Section learning
* Doing the right thing
* Doing the politically correct thing
* Component Performance
* Supplier Continuity
* Ability to see weakness and resolve
* OEM teaching ability
* Internal Engineer Training
* Time until warranty issue surface
177

* Supplier Quality
* Internal Design/DevNalidation Capability
* Supplier Des/DevNalidation Capability
* Supplier learning curve
0 Internal learning curve
* Avg. Engineer in Job Time
* Part complexity
* # of Component Functional Requirements/Attributes
* Supplier-OEM Partnership / Teamwork
* # of unique vehicle customer programs
* # of engine programs
* Customer knowledge
* Engineering expertise
* Level of component mgmt leadership / strategy I vision / discipline
* Program turnover / life cycle
* Documentation, including lessons learned
* Commonality
0 Cost cutting vs. value engineering
* Relationship building with Supplier
* Learning and teaching
* Employee Satisfaction
0 Late changes
* Supplier motivation
* Resource allocation/management
* Vendor Accountability (i.e. warranty sharing)
0 Level of Supplier Des/DevNal Responsibility
* Supplier Mfg Capability
0 Technical Innovation
0 Supplier Attitude
0 Product Development System Timing
* Supplier Employee Turnover
* OEM Teaching Capability
* Systems Engineering / Issue Resolution Concentration
* Program Management / Check the Box Concentration
* # of Quality Suppliers
0 Amount of Program Work
* Amount of Rework
* Amount of non-added value work
* Ability of Engineers to act data driven
* Doing the right thing
0 Doing the politically correct thing
178

(Average Time OEM Engineer on Job => Technical Knowledge)
"Continuity in engineering is very important. After you screw up one or two projects, you are getting pretty good"
"In the last 2.5 years we've had 3 managers (we go through them at a rate of I per year). We lost our technical expertise. Engineers are moving on and we're replacing them with younger, inexperienced people."
(Average Time OEM Engineer on Job => Customer Knowledge)
"It used to be that engineers had longer time/more experience on a project and could better interact and understand relationships with other activities and the customer. Now, 5 out of 7 engineers in "component F" group are from FCG program. Rotations have been recognized within this company as a way of getting promoted."
(Average Time OEM Engineer on Job => Discipline)
"Discipline is about understanding the process. In more and more cases design quality guidelines are not followed by younger engineers."
(Average Time to learn => Technical Knowledge)
"What's the learning curve? It takes about 3 years to be useful, people typically leave in 18-24 months."
"I've spent 2.5 years on this component now and I just start to do some good work."
(Component Engineer)
"It took me 3-4 years before I knew what I was doing; engineers move on long before that"
(Technical Specialist)
"It's a complicated system, even the best engineer takes a long time to understand this beast"
(Component Engineer)
"No matter how smart people are, the learning curve is not very steep in the beginning"
(Alignment of Supplier and OEM Motivation => Trust)
"Suppliers will go to (our) competitors first with new technologies. We are typically too interested in taking cost out. Teams are consistently looking for offsets. Toyota does what's right for quality (most important). They're willing to spend, whatever it takes."
"With FSS initiative, we may give business to suppliers, but these suppliers are only interested in proposals that match their business objectives not ours".
"Supplier doesn't work in our best interest."
179

"Component knowledge is the premise of FSS, so no reason to put priority on it. The other premise is that they will keep our best interests at heart. Right (said sarcastically), people have their own interests."
"Vendors partner with different OEM's. In order to maximize profits, they try to give us a product that is better suited for other OEM. They want to sell you what is tooled up. They sell you an apple when you need an orange."
(Cascade (Up/Down, Horizontal) Efficiency => Customer Knowledge)
"Recent internal strategy defines customer by upstream enterprises vs. downstream customer.
We've lost knowledge of the end consumer."
"(The vehicle should be designed around the engine. Instead...) the engine is designed around the vehicle. Thus, customer needs are cascaded to us putting barriers between us and the end customer."
(Cascade (Up/Down, Horizontal) Efficiency => Internal Resource Burden)
"Too many people have to bless your changes. A $0.20 change to a fastener now requires input from 8 different organizations, not people but organizations, to sign off This will take at least 6 months and maybe a year.
"I presume that our competitors don't have such complex bureaucracies. Opportunity to effect a downstream change is less - since there are fewer products in competitive organizations. We must serve everyone's interests on all changes. We really must go through entire development cycle again."
"If you go to the department homepage you see the year-over-year improvements. We want 5% improvement in customer satisfaction. The manufacturing chimney is aligned with the 5 quality objectives. Support organizations are not (Purchasing, supply base). Except for major cost reductions, we don't share objectives."
(Component Focus => Value Engineering)
"Despite paperwork, we get good parts. Not because of paperwork. We consider value engineering when we can focus on the component rather than paperwork."
(Cost Reduction Efforts => Discipline)
"...lot's of design and process changes resulting in more risk for pure execution."
"..overloading of PD factory and increased turmoil"
"Cause of spike (Problem Statement graph): cost reductions; working under duress, engineering changes not properly engineered & not properly validated. Warranty issues are internally driven, did not come from FSS alone."
"Have you noticed that people get punished for not meeting budget objectives, but rarely for not meeting quality targets?"
180

{Cost Reduction Efforts => Headcount)
"Cost cutting pressure decreases people per part."
"We used to audit but now due to headcount reduction this is no more. Now we want to save heads. We expect suppliers to self certify."
{Cost Reduction Efforts => Product Attribute Enhancements)
"More focus on cost reduction targets per year takes time away from new programs"
"The teams work on product development of new programs (model, prove-out, tooling, launch) and on cost reduction efforts. Cost reductions are superimposed, since they cannot always be incorporated into new programs in one shot, not always synergistic."
"If we continue the year-over-year material cost reduction effort the less effort we spend on new model programs."
(Cost Reduction Efforts => Tools)
"Since we got away from doing it ourselves, our capability reduced. Little nuances we don't understand. There is an uphill economic battle if, with reason, a durability test has to be added.
We have to live with stodgy designs, no light valves, no new materials."
"BMW developed ValvetronicTm in house! Where would our suppliers get the resources from to do so with all that cost cutting?"
(Cost Reduction Efforts => Investment in Supplier Resources)
"Cost cutting reduced testing and CAE at supplier; not enough resources."
(Competitions Attribute Leadership => Program Timing)
"The Japanese manufactures reduced their PD timing, thus we think we had no other choice than following their lead."
(Competitions Attribute Leadership => Customer Product Attribute Leadership
Expectation)
"BMW is one of the automotive companies that set the standard for engine functional attributes, thus consumers have higher expectations of us."
(Customer Product Attribute Leadership Expectation => Product Attribute Enhancement)
"We are here to serve our customer. Customer satisfaction is one of our corporate principles."
181

(Commodity => Premium Dollar Demanded)
"Demanding more efficiency from supplier on a mature product or process like ours? You don't have much leverage."
"The more our components are commodities, the less premium dollar we can charge."
(Discipline => Internal Capability)
"Execution of design is key and six sigma will help."
(Discipline => Supplier Resource Burden)
"We do a terrible job of sharing upfront engineering specifications. We have 3 world-class suppliers but their tools require good upfront information. Although we could get accurate information, we generally don't. We feed suppliers general info and they must make a lot of assumptions. We give them just bare minimum information
"Why do we do this? We don't see it as critical information at the time."
"Sharing of information? We don't want to share volumes, future plans, timing, and design guides with suppliers. If they have an onsite we might share it, but supplier home-base does not get the information in time."
(Employee Satisfaction => Motivation to Stay)
"There are no rewards in the system to (encourage you to) stay in component engineering"
(Headcount => Technical Knowledge)
"We reduced Supplier Technical Assistance involvement and lost numerous seasoned engineers. Voluntary separation packages specifically for guys that have 25 of more years in the business."
(Internal Capability => Internal Resource Burden)
"If we don't maintain a balance between the number of engine programs and engineering capability (headcount), our resources are over stretched"
(Internal Capability => Product Outcome)
"At best our advanced activitiesjust copy current technologies. In house technical capability gives you a 3-year competitive edge. 80 people work at BMW on Valvetronic, we have just a couple."
(Internal Capability => Alignment of Supplier to OEM Motivation)
"As outsourcing goes up, it is more difficult to understand what supplier is doing. Ears and eyes go off (the program), but you find out with a time lag, i.e. warranty. Then you spend resources internally to find root cause."
182

(Internal Capability => Supplier Capability)
"Once the supplier design sand develops a component, their capability increases and ours decreases. Transfer of knowledge from us to them is critical."
"We had to evaluate our tools vs. world-class suppliers. They were designing 20 "component
F's" per year (had other OEM customers) while we were designing I every 4 years. Guess who is more capable"
{Internal Capability => Supplier Resource Burden)
"If we don't have the resources to do it all, we prioritize. Can't do it with the resources we have so we shift the responsibility to suppliers. We say 'They can do it - make it their job'."
(Internal Resource Burden => Knowledge of Supplier Ability)
"Asian manufacturers specify and monitor the process. This would take more resources on our part."
"Worse thing you could do was to take quality audits away. Erosion and decline (of quality) at supplier is just because of human nature. If you don't monitor it, it goes away."
"In 1991-93 when we outsourced the 'Component A', quality was good. STA was strong.
There was one person assigned to a supplier. Suppliers never knew when we would show up to review facilities or production processes. Even if they were in cost cutting mode, they still feared quality reviews."
"For us to be good, we must be constantly visiting the plants. Yet cost reduction goals conflict - we are not allowed to travel."
"Toyota comes into the supplier plant and makes sure that control plans that were signed up to are all being followed."
(Internal Resource Burden => Discipline)
"Design guideline is supposed to help us in this area but most engineers say that they are too busy to understand and follow design guidelines."
(Investment in R&D => Tools)
"Our FEA tools are the best in the industry and are developed in-house. You don't get tools for free."
(Investment in Supplier Resources => Supplier Resource Burden)
"Bottom line is that you get what you pay for."
(Investment in Supplier Resources => Supplier Knowledge)
183

"When times are tough, cost pressure goes up and R&D at supplier goes down. Rob Peter to pay Paul. Suppliers rely on OEM's for investments."
"We don't give vendors money upfront for technology development. We give them money if they have technology."
(Knowledge of Supplier Ability => Supplier Discipline)
"It's human nature, like spending time with kids. Know it and it improves, let it slide and it falls."
"With outsourcing we decimated STA and did not go back and check on the supplier processes.
We expected that they had self certification capability."
"Learning by a STA (Supplier Technical Assistant) person is at least 1.5 years to become functionally assertive to understand effects of supplier actions to our business."
"S TA was high priority in the early 90's but disbanded in the mid '90's because the big suppliers were saying 'We know how to run ourselves. We'll give you the cost reductions you're looking for if you'll get out of our shorts. We promise to give you the same quality'. But the question is, were they able to execute the control plans?"
"We need to recognize that STA needs to be put back in place. Based on the number of issues we are seeing, we have recognized this."
(Knowledge of Supplier Ability => Alignment of Supplier and OEM Motivation)
"The more we know about the supplier the better we can assess their business objectives. We would like to choose the ones that have a common strategy."
"JABV, sensors, injectors - examples of fully outsourced parts with poor performance, these jobs were simply given to suppliers (that's wrong), they think about what is best for them."
(Knowledge of Customer => Internal Capability)
"Knowing what functional attributes to design for is a difficult virtue to have."
(Level of Partnership => Supplier Resource Burden)
"They service all OEMs. It takes I application engineer (supplier) to manage a Chrysler account, but takes 3 to handle our account. There's too much non-value added documentation control required."
(Level of Partnership => Shadow Engineering)
"One advantage we have with keeping design inside, is that we can freely argue amongst ourselves whereas suppliers find it difficult to argue design issues with us. Suppliers can't tell customer that they are wrong."
"Supplier engineer has less leverage than OEM engineer."
"Even if suppliers had knowledge, they would not have the power to change customer directives."
184

"Onsite supplier reps are key. It's a cultural things, once they are inside the building, they become part of the process."
"Yes, cost and timing is an important criteria. Suppliers are not in a position to say NO. They are not empowered to say NO."
"Inability to treat supplier as replacement for a in-house engineer. We don't trust suppliers.
Plants comments are: 'I want to see our engineer that is in charge'."
"The problem is the supplier can't defend themselves."
"It's servant master relationship."
(Level of Partnership => Knowledge of Supplier Ability)
"Is the supplier relationship an important decision criteria? Yes, Engineering wants the same suppliers because they know what they can do."
"With great supplier relationship you get better ideas from supplier."
"Suppliers take their best ideas to the one there are most tightly in business with. But, suppliers don't want to take technologies to us anymore."
(Motivation to Stay => Avg. Time OEM Engineer on Job)
"We need a reward structure that makes people want to stay in the job. The culture has been to switch
and get promoted."
(New Hire Quality =>Motivation to Stay)
"We have always tried to hire all the graduates with best qualifications. But, they never failed in their life. Of course, those are the ones that want to advance. They are not likely to stay for 3 years in a component job. They want to be promoted"
(Number of Programs (Unique Designs) =>Cascade (Up/Down, Horizontal) Efficiency)
"In 1995 we had 1800 people on 50 programs. In 2001 we have 1200 people on 140 programs.
Creation of Consumer Business Groups - each is its own little kingdom; all have different demands. Wants and needs are conflicting."
"To Asian OEMs, the engine is the heart of the vehicle. The vehicle is designed around the engine. There is little architectural variance"
"Customized design for each engine design application is not efficient."
"Reasonable package area common to all vehicles is not possible. So many wants for a single engineered engine family. This engine goes into seven vehicle lines. All have a different want, different technology needs."
185

(Number of Programs (Unique Designs) =>Product Complexity)
"One reason costs are so high is program year-over-year changes are big drivers. We are constantly in launch mode, also products are changing year-over-year."
"We don't control complexity. We are driven by the vehicle - for oil pan, covers etc... next package that comes along you will have to redesign. Part complexity is very high, we have to continually package around components and those are different among vehicles."
(Pressure to Reduce Cost => Supplier Resource Burden)
"We expect suppliers to make up for resource loss but they are not. They can't match what we've taken out. They've been told that if they want business they must take on added work of design and engineering."
"Due to cost pressures from Purchasing, they aren't allowed to increase prices only decrease year-over-year."
"It's our process that is wrong - we set price and then by contract we force supplier to show 2% commitment to productivity year after year. But we always go and ask for more (3-4%).
Margins are low and suppliers must find an offset. It's a master servant relationship"
"Suppliers have no leverage to resist cost reduction demands. They fear loss of business (to competitor)."
"Supplier burden went up from two ends, engineering asked for material (design) cost reduction targets and purchasing asked for non-product design cost reductions (i.e. reduce overhead, process, profit....)
"Pushing costs down eats into suppliers profits - they start doing less testing, engineering
"We create issues four years from now. Supplier has two choices, either eat profits or reduce process capability"
"This part is not a core component and it's too expensive for us to do casting changes due to package constraints and to develop CAE tools."
{Pressure to Reduce Cost => Cost Reduction Efforts)
"We still operate with year-over-year cost reduction efforts. This is a corporate finance direction.
We needs to report on annual basis, therefore there is pressure to improve cost structure to satisfy yearly financial performance metrics."
{Product Complexity => Internal Resource Burden)
Complexity and timing delays have a snowball effect. Issues compound, need for more resources and more time delay. The bureaucracy starts to overwhelm you."
"People handle too many parts and need to focus on durability and reliability as well."
(Product Complexity => Supplier Burden)
186

"Over the years, we demanded more and more from the supplier; such as extended reliability for alternative fuels."
"Number of engine programs has an effect on (product) performance but less than non-value engineering does. It is a big burden on suppliers though - to meet demands."
{Product Attribute Leadership => Commodity)
"We are buying engine component commodities from our suppliers. However, it's the attributes that can make them non-commodities"
{Product Attribute Leadership => Product Attribute Enhancement)
"The more we lead in a certain attribute the less program enhancement we need to deliver in that attribute."
{Product Attribute Enhancement => Product Complexity)
"Over years we have more complicated technology (2V vs. 4V), more components per engine, reliability failure probability goes up and the job becomes more complex"
...
proliferation of increased attribute wants. If customer does not have special NVH needs, workload reduces by 30%."
{Product Outcome => Trust)
"We don't allow suppliers to design this component due to importance to the engine function, but we have quality issues because the supplier does not follow the process."
"It's our culture. We place blame rather than identify root cause together with the supplier."
{Product Outcome => Rework)
"The higher the warranty on a component, the more time you spent fixing customer vehicles."
(Product Outcome => Pressure to Reduce Cost)
"It's very simple. If you do it right, customers are happy to pay for your product."
(Product Outcome => Product Attribute Leadership)
"With a more reliable product, the customer perceives your product attributes highly. There is more confidence and thus a better product image"
(Program Management Work => Internal Resource Burden)
"200 doers (number of design engineers), 500 watchers (number of supervisors, technical specialists, chief engineer, executives). Only 2/5 of our resources go to quality of product."
"Too many initiatives lately 'waste our time'. These initiatives are designed to track programs.
This was supposed to make it easier on the engineer (provide 'cookbook recipe') but reality says it's a series of tradeoffs."
187

{Program Management Work => Systems Focus)
"Switch from systems engineering to program engineering led to a loss of leadership in problem resolution between products"
(Program Management Work => Component Focus)
"Component engineers spend so little time doing actual engineering work (vs. filling out forms).
Engineers are asked to spend all their time in meetings, explaining tools rather than using them." Back in the early 1990s without all that program management work, we spent our time visiting suppliers, working on the details."
(Program Timing => Product Complexity)
"FPDS (product development process) is timing reduced. Assumption was that analytical tools are in place in time and mature enough, but they are still not good enough. We have to run testing to validate models. If you have failures, FPDS timing does not get you there."
(Quality of Documentation => Discipline)
"We don't police ourselves at all. Even though FSS may be poor, we don't do a good job internally of monitoring ourselves at all."
"There was no real documentation in the past that could make up for it with experience.
Documentation cannot totally make up for lack of experience but certainly brings us much closer."
(Rework => Internal Resource Burden)
"It's hard to plan for the future when your day starts at 5:30am talking to Europe about bad components."
(Rework => Rewards)
"Our culture is to reward the firefighters and not the planners."
"Maybe it's more of our corporate culture; Recognition of firefighters, lack of recognition of teams who have performed consistently year over year. We are very good firefighters as a company. Maybe because we still reward this."
(Systems Focus => Value Engineering)
"System engineering, basic responsibility is with the interfaces; work with systems. Systems focus took initiative to drive solution between components, had technical expertise.
(Supplier Capability => Product Outcome)
"During supplier selection lean mfg and DFM has low priority. We care about the supplier component knowledge, resources availability, performance, cost, timing, and quality."
188

"If supplier does not succeed, we don't succeed."
(Supplier Capability => Supplier Resource Burden)
"Our suppliers feel the same economic pinch that we do. When they're not making the profits they once did, they cut back on tools and people and at the same time try to take on more
They really can't help us if they aren't helping themselves."
(Supplier Capability => Trust)
"... certainly we more faith and expectations from a supplier who has a high level of capability.
When they perform well, with us or with other OEMs, we know we can trust and depend on them. With some history, we start giving these suppliers more work and more responsibility.
(Supplier Capability => Shadow Engineering)
"We dealt with a ton of complexity with only 3 engineers. Then we reorganized (1988) and added a component engineer to each engine group (modular engines). Our group now has 7 engineers. My supervisor thinks 3 more are needed. So we now require 10 engineers when we used to have 4 and did design work in-house. Why? Shadow engineering. FSS never picked up responsibilities they were supposed to have picked up."
"We don't give supplier the tools they needs. Consequently, we start shadow engineering if we feel the supplier is not doing the work correctly."
(Supplier Knowledge => Supplier Capability)
"Supplier X has excellent predictive CA E knowledge for material knowledge and unlike other components of that kind, supplier X's part has yet to fail."
(Supplier Resource Burden => Supplier Discipline)
"In the same supplier facility, you see Honda and Toyota production area with process controls, good lighting, no inventory. On our side of the shop you see its dark, dirty, and equipment that is out of date, not properly staffed
"Supplier Y has 3 OEMs in 1 plant. Honda asks for quality processes. Their side of the plant is lean. On our side, we had 2 stop ships in 1 week, wrong lighting, and no operating instructions."
"When you ask supplier to do more and more, quality will suffer."
"A mature product like valve trains turns up less and less profitability and yet there are cost pressures. Thus you need to increase volume, but this requires a healthy economy. Suppliers wi small margins need to increase volumes, such as going from 280 to 480 parts produced per day. Quality goes down as you overextend the workforce, less maintenance, supplier operates on thin edge. The supplier is mining."
(Supplier Discipline => Supplier Capability)
"In '96/97 timeframe, we started to focus more on cost. We beat the supplier for cost, they concentrated more cost reductions, took of eye of quality, spent less time on developing a good part, and looked to cut corners to keep up with cost pressure"
189

"Why did STA go away? Cost reductions; suppliers couldn't police themselves."
"Supplier discipline is more important because they have design, design analysis, bench test.
They do more than we do inside."
(Strong Management Vision/Leadership => Alignment of Supplier and OEM Motivation)
"When issues arise, they hear from engineering, the plants, design, STA, purchasing. Everyone is trying to tell them something different to do."
"Priority given for maintaining/building supplier relationships? None. Priority is given to improve quality, cost advantage of outside supplier, further technology and tool development."
(Strong Management Vision/Leadership => Employee Satisfaction)
"You need to have a strong manager to fight this. Strong = experience +non-upwardly mobile. It leads to stronger actions. Well maybe not stronger but you can speak the truth without worrying about repercussions."
(Strong Management Vision/Leadership => Upfront Planning)
In regards to cycle planning issues, management doesn't push back like they used to.
Everyone wants the latest and greatest. Seems like management thought is 'add more content, six sigma will fix it'.
(Strong Management Vision/Leadership => Tools)
"Too many people think they are signoff tools. Mgmt does not understand the role of directive tools."
"Priority given to maintaining/building internal capability - Low. When FSS term came to be
(1980's), it was believed that whoever made part should have design responsibility also. It was decided that design and manufacturing should be kept together (whether in-house or outsourced). Engineering expertise was the main driver to outsource, and belief quality would improve."
(Technical Knowledge => Internal Capability)
"Our capability eroded over the past couple years. Now, we just have one technical specialist teaching a couple of young engineers."
"We had to evaluate our tools vs. world-class suppliers. They were designing 20 pistons/year
(had other OEM customers) while we were designing I every 4 years. Guess who is more capable"
(Technical Knowledge => Knowledge of Supplier Ability)
"Technology improvements basically led by suppliers. That was our intent - if you outsource, you don't have to do everything yourself But, are things really getting done and done right?"
190

(Tools => Internal Capability)
"We maintain core technical competence, develop CAE tools and license to suppliers. When suppliers do their own, it is considered proprietary and other suppliers can't use it."
"Analysis tools are predictive tools."
"Analytical tools in the late 80s gave us good confidence that things would work. We could understand downstream quality effects better."
"We must make tradeoffs. With analytical tools, we could make those decisions better."
(Trust => Level of Partnership)
"It takes a year to get some trust with supplier. From then on there is a high possibility to maintain relationship."
"Toyota sees suppliers (Tieri) as long-term partners and the entire team is responsible"
"In the 1990's we started getting rid of long term contracts in exchange for year-to-year cost cuts."
(Upfront Planning => Discipline)
"We didn't adopt to MIL light strategy correctly. This was around 1997. Calibration not matched to function. The cause was a late strategy and late execution."
"Per Dr. Deming, quality is free. He is right".
"As organization we don't believe it (plan strategy; invest now rather than paying later). I think it is about the old culture we have on spending. But the positive is that it is changing. Spend now to prevent later costs. The problem we have working on the upfront strategy is the death spiral."
"We don't start programs on time."
(Upfront Planning => Reward)
"We will do anything to get it right when there is a crisis. Wish we could recognize people when things are going smooth."
"How many times have you heard 'I'm not sure if they are ready to move on yet, they are awfully quiet."
(Value Engineering => Employee Satisfaction)
"Cultural impact is a significant morale issue. People with 2 masters degrees who love engineering may spend all of their time on e-mail, presentations and meetings. They go home at night without feeling that they have added value. PhD's may spend 80% of their time as paper pushers. They thought they were here to work on motors."
191

"Outsourcing and R&R change reduces engineering attitude. Now they have to manage a supplier. Attitude issue figures in little into the decision. We (enterprise level) assume it's going to be handled. Local mgmt has to deal with engineering attitude impacts on design and development performance."
(Value Engineering => Technical Knowledge}
"When design and manufacturing was done in-house, it wasn't a perfect system but engineering knew through experience, effects on other components."
192

(001) "$ to PAL Factor"=1; Units: $/PAL
(002) "% Component Focus"= Component Focus/Programs to Do*100; Units: Dimensionless
(003) h%
Systems Focus"= Systems Focus/Programs to Do*100; Units: Dimensionless
(004) Alignment of Supplier Motivation to Internal Motivation=0.1*Internal Capability+0.1*Knowledge of
Supplier Ability+0.1*Strong Management Vision and Leadership; Units: Jobs
(005) Average Time to Learn=5/2; Units: Jobs/Year
(006) Avg Time on Job=1/5*Typical Rotation*Motivation to Stay; Units: Years/Person
(007) Cascade Inefficiency=(Programs to Do-0.7*Programs to Do)/Programs to Do; Units: Dimensionless
(008) Change in Product Attribute Level Target=(Customer PAL Expectation-Product Attribute Leadership
Level)/Cost Reduction Efforts; Units: PAL Level
(009) Commodity Test 1 =IF THEN ELSE(Product Attribute Leadership Level>70, 0, 1 ); Units: PAL Level
(010) Commodity Test 2=IF THEN ELSE(Commodity Test 1=1,Product Attribute Leadership Level-
Competitor's PAL Level , 0 ); Units: PAL Level
(011) Competitor's PAL=SMOOTH(Competitor's PAL Level,2); Units: Dimensionless
(012) Competitor's PAL Level=RAMP(0,0,5)+80+RAMP(0.5,0, 10 ) +0.62*PULSE(5,0.4)*EL Comp
Pal*0.8+0.28*PULSE(7,0.5)*FL Comp Pal*0.8,67); Units: PAL Level
(013) Component Focus=0.5*(Programs to Do-PM Work To Do); Units: Jobs
(014) Cost Reduction Efforts= 2*Pressure to Reduce Cost; Units: $/Year
(015) Cost to Discipline Factor=1/50; Units: Job/$
(016) Cost to Person Factor= 1/0.09; Units: Person*Years/$
(017) Customer PAL Expectation=1*Competitor's PAL Level; Units: PAL Level
(018) Customer Prox= SMOOTH(Knowledge of Customer,2); Units: Jobs
(019) DR Inputs=1*(EL Comp Pal+EL Int Cap+EL Int Resource Burden+EL Know of Cust+EL Prod
Out+EL Prod Comp+EL Supp Cap+EL Supp Proximity+FL Comp Pal+FL Int Cap+FL Int Resource
Burden+FL Know of Cust+FL Prod Out+FL Prod Comp+FL Supp Cap+FL Supp Proximity);
Units: **undefined**
(020) EL Comp Pal=0; Units: **undefined**
193

(021) EL Int Cap=O; Units: **undefined**
(022) EL Int Resource Burden=0; Units: **undefined**
(023) EL Know of Cust=0; Units: **undefined**
(024) EL Prod Comp= 0; Units: **undefined**
(025) EL Prod Out=0; Units: **undefined**
(026) EL Supp Cap=0 ; Units: **undefined**
(027) EL Supp Proximity=0; Units: **undefined**
(028) Employee Satisfaction= (Rewards+(Strong Management Vision and Leadership+Value
Engineering)*Job Length Factor/Typical MY Program Life); Units: Dimensionless
(029) Erosion of Internal Capability=20+(0.03*Supplier Capability);
(030) Erosion of Internal Knowledge=0.2*Average Time to Learn;
(031) Erosion of Knowledge=Average Time to Learn;
Units: Jobs/Year
Units: Jobs/Year
Units: Jobs/Year
(032) Erosion of Leadership=1 00*Promotability/Job Length Factor; Units: Jobs/Year
(033) Erosion of Supplier Capability=( 0.7*Programs to Do/Typical MY Program Life ); Units: Jobs/Year
(034) Erosion of Supplier Proximity=IF THEN ELSE(Supplier Proximity Switch<12, 0.5*Supplier Proximity
Switch , 0.25*Supplier Proximity Switch ); Units: Jobs/Year
(035) FINAL TIME = 10; Units: Year (The final time for the simulation).
(036) FL Comp Pal=0; Units: **undefined**
(037) FL Int Cap=0; Units: **undefined**
(038) FL Int Resource Burden=0; Units: **undefined**
(039) FL Know of Cust=0; Units: **undefined**
(040) FL Prod Comp= 0; Units: **undefined**
(041) FL Prod Out=0; Units: **undefined**
(042) FL Supp Cap=0; Units: **undefined**
(043) FL Supp Proximity=0; Units: **undefined**
(044) Headcount=5+1/(Cost Reduction Efforts*Cost to Person Factor); Units: People
(045) INITIAL TIME = 0; Units: Year (The initial time for the simulation).
194

(046) Internal Cap=SMOOTH(Internal Capability,2); Units: **undefined**
(047) Internal Capability= INTEG (SMOOTH(RAMP(0,0,5)+(Investment in Internal Capability-
1.25*Erosion of Internal capability) +0*PULSE(5,0.5)*ELIntCap*4+ 0.3*PULSE(7,0.5)*FL Int Cap*4,2),40);
Units: Jobs
(048) Internal Discipline=(125+0.1 *(Avg Time on Job*Time to Discipline Factor+Upfront Planning+Quality of Documentation-PM Work To Do-Cost to Discipline Factor*Cost Reduction Efforts/Typical MY Program
Life)+0.9*lnternal Resource Burden); Units: Jobs
(049) Internal Res Burden=SMOOTH(Internal Resource Burden,2); Units: Jobs
(050) Internal Resource Burden=1*(20+ (Cascade Inefficiency*(((Rework Rate*Typical MY Program
Life)+Shadow Engineering+Product Complexity+PM Work To Do )-Internal Capability-0*PULSE(5,
0.5)*EL Int Resource Burden*2 -0.35*PULSE(7, 0.5)*FL Int Resource Burden*2))); Units: Jobs
(051) Internal Technical Knowledge= INTEG ((0.023)*lnvestment in Knowledge-Erosion of
Knowledge,10); Units: Jobs
(052) Investment in Internal Capability=20+0.1 *(Internal Discipline+Knowledge of Customer+Internal
Technical Knowledge+Tools)/Typical MY Program Life; Units: Jobs/Year
(053) Investment in Knowledge=(Value Engineering/Avg Time on Job+Headcount/Typical MY Program
Life*Job to People Factor)*4.25*(Avg Time on Job*Headcount/Typical MY Program Life); Units:
Jobs/Year
(054) Investment in Leadership=1/100*(Product Outcome/Typical MY Program Life+Avg Time on Job/Job
Length Factor*Management per Job Factor/Typical MY Program Life); Units: Jobs/Year
(055) "Investment In R&D"=10*Profit/Typical MY Program Life; Units: $/Year
(056) Investment in Supplier Capability=14+(0.6*Supplier Discipline+0.7*Supplier Knowledge)*0.5; Units:
Jobs/Year
(057) Investment in Supplier Proximity=Supplier Proximity Switch; Units: Jobs/Year
(058) Investment in Supplier Resources=5-0.1*(Cost Reduction Efforts)*Typical MY Program Life;
Units: $
(059) Job Length Factor=3; Units: Years/Job
(060) Job to PAL Factor=1.5; Units: Jobs/PAL Level
(061) Job to People Factor=5; Units: Jobs/People
(062) Knowledge of Customer=RAMP(0, 0,5)+5+(Time to Knowledge Factor*Avg Time on Job/Cascade
Inefficiency)+0.4*PULSE(5,0.5)*EL Know of Cust*0.5+0*PULSE(7,0.5)*FL Know of Cust*0.5;
Units: Jobs
(063) Knowledge of Supplier Ability=0.5*(Internal Technical Knowledge+Supplier Proximity)-
0.125*lnternal Resource Burden; Units: Jobs
195

(064) Management per Job Factor=2; Units: Persons
(065) Motivation to Stay=10+1/10*(Employee Satisfaction-0.5*New Hire Quality*Job Length Factor-
0.5*PM Work To Do*Job Length Factor/Typical MY Program Life); Units: Dimensionless
(066) New Hire Quality=50-Internal Technical Knowledge/Typical MY Program Life; Units: Jobs/Year
(067) New Program Spike=PULSE(7, 10)*40; Units: Jobs/Year
(068) New Programs= INITIAL(50); Units: Jobs/Year
(069) PAL=SMOOTH(Product Attribute Leadership Level,2);
(070) PAL to Timing Factor=1; Units: Year/PAL Level
(071) Percent Systems Focus=SMOOTH("% Systems Focus",1);
Units: Dimensionless
Units: Dimensionless
(072) PM Work To Do=(0.33+0.002*Programs to Do)*Programs to Do; Units: Jobs
(073) Premium Dollar Demanded=IF THEN ELSE(Commodity Test 2>0,Commodity Test 2*"$ to PAL
Factor" , 0 ); Units: $
(074) Pressure to Reduce Cost=(1 0*(Competitor's PAL Level/Product Attribute Leadership Level)-
0.1*(Profit*Product Outcome)/Programs to Do/Typical MY Program Life); Units: $/Year
(075) Prod Complexity=SMOOTH(Product Complexity,2); Units: Dimensionless
(076) Prod Outcome= SMOOTH(Product Outcome,2); Units: Dimensionless
(077) Product Attribute Leadership Level= INTEG ((Rate of PAL change)/100; Units: PAL Level
(078) Product Complexity=RAMP(0,0,,5)+1 0+(1/50*((Change in Product Attribute Level Target)/Program
Timing*PAL to Timing Factor*(Programs to Do))-0*PULSE(5, 0.5 )*EL Prod Comp*1-0*PULSE(7, 0.5 )*FL
Prod Comp*1); Units: Jobs
(079) Product Outcome=RAMP(0,0,5)+(Internal Capability+Supplier Capability)+0.45*PULSE(5, 0.5)*EL
Prod Out*8+0*PULSE(7, 0.5)*FL Prod Out*8; Units: Jobs
(080) Profit=0.3*Premium Dollar Demanded; Units: $
(081) Prog To Do=SMOOTH(Programs to Do,2); Units: Dimensionless
(082) Program Timing=Typical MY Program Life-0.03*Competitor's PAL Level*PAL to Timing Factor;
Units: Years
(083) Programs to Do= INTEG (0.3*(New Programs+New Program Spike-Rework Generation+Rework
Rate-Work Accomplished),50); Units: Jobs
(084) Promotability=0.1; Units: Dimensionless
196

(085) Quality of Documentation=lnternal Technical Knowledge+Strong Management Vision and
Leadership; Units: Jobs
(086) Quality Problems=100+1000*1/Prod Outcome+0*(Percent Systems Focus+Competitor's
PAL+Internal Cap+lnternal Res Burden+Customer Prox+PAL+Prod Complexity+Prog To Do+Supplier
Cap+Supplier Prox); Units: **undefined**
(087) Rate of PAL Change=(0.1*(Job to PAL Factor*(2.5*Product Outcome/Typical MY Program
Life)+Change in Product Attribute Level Target/Typical MY Program Life))*6; Units: PAL Level/Year
(088) Rewards=(Rework Rate-Upfront Planning)*Typical MY Program Life; Units: Dimensionless
(089) Rework Generation=0.2*Product Outcome/Typical MY Program Life; Units: Jobs/Year
(090) Rework Rate=Rework Generation/1; Units: Jobs/Year
(091) SAVEPER = TIME STEP; Units: Year; (The frequency with which output is stored).
(092) Shadow Engineering=20-((0.1 *Supplier Capability+0.1 *Supplier Proximity)); Units: Jobs
(093) Strong Management Vision and Leadership= INTEG (Investment in Leadership-Erosion of
Leadership,50); Units: Jobs
(094) Supplier Cap=SMOOTH(Supplier Capability,2); Units: Dimensionless
(095) Supplier Capability= INTEG (SMOOTH(RAMP(0,0,5)+(Investment in Supplier Capability-Erosion of
Supplier Capability)+0.57*PULSE(5,0.5)*EL Supp Cap*4+0.27*PULSE(7,0.5)*FL Supp Cap*4,2),25);
Units: Jobs
(096) Supplier Discipline=10+(1/2)*(Knowledge of Supplier Ability-0.1 *Supplier Resource Burden)*Typical
MY Program Life; Units: Jobs/Year
(097) Supplier Knowledge=Investment in Supplier Resources*Supplier Knowledge Cost Rate;
Units: Jobs/Year
(098) Supplier Knowledge Cost Rate=5; Units: Jobs per Year/$
(099) Supplier Prox=SMOOTH(Supplier Proximity,2); Units: Dimensionless
(100) Supplier Proximity= INTEG (RAMP(0,0,5)+1/10*(Investment in Supplier Proximity-Erosion of
Supplier Proximity)+0.62*PULSE(5,0.5)*EL Supp Proximity*0.5+0*PULSE(7,0.5)*FL Supp
Proximity*0.5,5); Units: Jobs
(101) Supplier Proximity Switch=IF THEN ELSE(Trust<=12, 0.5*Trust 0.75*Trust); Units: Jobs
(102) Supplier Resource Burden=20+1/1000*((Product Complexity-Supplier Proximity-Internal Capability-
Internal Discipline)*Pressure to Reduce Cost/Investment in Supplier Resources*Typical MY Program
Life); Units: Jobs
(103) Systems Focus=(Programs to Do-PM Work To Do-Component Focus);
(104) TIME STEP = 0.5; Units: Year; (The time step for the simulation).
Units: Jobs
197

(105) Time to Discipline Factor=5; Units: Person*Jobs/Year
(106) Time to Knowledge Factor=0.5; Units: Jobs*Person/Year
(107) Tools=10-(10*Strong Management Vision and Leadership/Typical MY Program Life)*("Investment In
R&D"-0.0005*Cost Reduction Efforts); Units: $/Year
(108) Trust= +0.2*Alignment of Supplier Motivation to Internal Motivation/Typical MY Program
Life+0.3*(Product Outcome+Supplier Capability)/Typical MY Program Life+0.2*Supplier Discipline;
Units: Jobs/Year
(109) Typical MY Program Life=4.5;
(110) Typical Rotation=2.5;
Units: Years
Units: Years/Person
(111) Upfront Planning=1 +0.05*Strong Management Vision and Leadership;
(112) Value Engineering=( "% Component Focus"+"% Systems Focus" );
Units: Jobs
Units: Jobs
(113) Work Accomplished=(Supplier Capability+Internal Capability)/Typical MY Program Life;
Units: Jobs/Year
198