Non-Functional Influences on Product Architecture
by
Jeffrey B. Dahmus
B.S. Mechanical Engineering
Stanford University, 1997
Submitted to the Department of Mechanical Engineering
in Partial Fulfillment of the Requirements for the Degree of
Master of Science
at the
Massachusetts Institute of Technology
June 2001
BARKER
C 2001 Massachusetts Institute of Technology
All rights reserved
All
ight resrvedMASSA CHUSETTS INSTITUTE
OF TECHNOLOGY
JUL 16 2001
LIBRARIES
........................
Department of Mechanical Engineering
Signature of A uthor..............
May 11, 2001
..............................................
C ertified by .............................
Kevin N. Otto
Associate Professor of Mechanical Engineering
Thesis Supervisor
A ccepted by ............................................................
...........................................................................
Ain A. Sonin
Professor of Mechanical Engineering
Chairman, Department Committee on Graduate Studies
2
Non-Functional Influences on Product Architecture
by
Jeffrey B. Dahmus
Submitted to the Department of Mechanical Engineering
on May 11, 2001 in Partial Fulfillment of the
Requirements for the Degree of Master of Science
ABSTRACT
Determining product architecture is a key step in any product development activity. By selecting
an effective product architecture for a product, companies can realize large savings, both during
development and over the life of the product. This thesis explores how non-functional issues
such as serviceability, technology change rate, and supply chain can and should be considered
when determining product architecture. Each of these influences is carefully examined, and
detailed methodologies are developed for incorporating such concerns into product architecture
decisions. These methodologies involve first determining functionally based modules through the
application of product modularization heuristics. These modules can then be evaluated from the
perspective of a given influence by using methods and equations presented in this thesis.
Application of such methods helps to determine if the suggested modules are effective from the
standpoint of a particular influence. The methodologies developed in this thesis allow a product
development team to architect a product while taking into account serviceability, technology
change rate, and supply chain influences. By taking such concerns into consideration, product
architectures can be developed that are effective for the product and company.
Thesis Supervisor: Kevin N. Otto
Title: Associate Professor of Mechanical Engineering
3
4
Acknowledgements
I would like to thank my advisor, Kevin Otto, for his support and guidance over the past two
years.
His insights, advice, optimism, and humor have helped to make my experience a
productive and enjoyable one. I am very grateful that I had the opportunity to work with him.
I would also like to thank Michael Furst, Stephen Hoover, Abu Islam, and Gregory Kott of Xerox
for providing numerous insights into actual product development processes.
Their advice,
comments, and feedback helped to bridge the gap between research and practice.
I would also like to thank the MIT Center for Innovation in Product Development and the Office
of Naval Research for their sponsorship of my research.
Lastly, I would like to thank my friends and family for their continued encouragement and
support.
5
6
Table of Contents
S
Introduction..........................................................................................................................................
The Importance of ProductArchitecture.......................................................................................
1.1
1.2 DeterminingProductArchitecture ................................................................................................
1.3 Scope of this Thesis .........................................................................................................................
1.4 Organizationof this Thesis ..............................................................................................................
2
Product Architecture.........................................................................................................................
2.1
Terminology.....................................................................................................................................
2.2 ManagingProductArchitectures ..................................................................................................
2.3
3
4
Determining ProductArchitectures..............................................................................................
9
11
13
15
15
17
17
18
19
Functional M odeling..........................................................................................................................
21
3. 1 Background.....................................................................................................................................
22
3.2
Function Structures.........................................................................................................................
22
3.3
Modularity Heuristics......................................................................................................................
26
Serviceability ......................................................................................................................................
29
Related Work ...................................................................................................................................
29
4.2 Approach .........................................................................................................................................
31
4.1
Modeling Serviceability...................................................................................................................
33
4.3.1
Basic Service Cost Equations ..............................................................................................
33
4.3.2
Basic Reliability Concepts...................................................................................................
34
4.3.3
Random Failure M odel...........................................................................................................
37
4.3.4
Periodic M aintenance M odel..............................................................................................
42
4.4 Example: Xerox Document System ..............................................................................................
47
4.4.1
Charging M odule ....................................................................................................................
49
4.4.2
Cleaning M odule.....................................................................................................................
54
4.3
4.5 Discussion .......................................................................................................................................
7
56
5
Technology Change Rate ................................................................................................................... 59
5.1
Related Work ................................................................................................................................... 60
5.2
Approach ......................................................................................................................................... 62
5.3
Technology Change Rate Values ..................................................................................................... 63
5.3.1
When W ill the Technology Change? ...................................................................................... 63
5.3.2
Secondary Questions ............................................................................................................... 65
5.3.3
Using Technology Change Rate Values ................................................................................. 70
5.4
Example: Black and Decker Screwdriver........................................................................................ 71
5.4.1
5.5
Example: Xerox Document System .................................................................................................. 76
5.5.1
5.6
6
8
Charging M odule .................................................................................................................... 77
Discussion ....................................................................................................................................... 81
Supply Chain ...................................................................................................................................... 83
61
Related Work ................................................................................................................................... 83
62
Approach......................................................................................................................................... 85
63
EvaluatingSuppliers ....................................................................................................................... 86
64
Example: Black and Decker Screwdriver........................................................................................ 89
6.4.1
Torque M odule ....................................................................................................................... 91
6.4.2
Power M odule ......................................................................................................................... 93
65
7
Power M odule ......................................................................................................................... 72
Discussion ....................................................................................................................................... 95
Conclusions ......................................................................................................................................... 97
7.1
Optimization.................................................................................................................................... 97
7.2
Future Work................................................................................................................................... 105
Notes .................................................................................................................................................. 107
I
Introduction
The success of a company is rarely defined by the success of a single product. Instead, long-term
company success and market growth often depend on providing the customer with a broad and
continuous stream of value-rich products. One does not need to look far to find examples. Intel,
in the 20 years since its first microprocessor was launched, has released over a dozen more
microprocessor generations.' With each passing product generation, Intel's position as one of the
most profitable and influential players in the computer industry has been further strengthened.
Looking to the future, more generations of microprocessors are certainly in the works.
In
America, Honda has developed a solid reputation for producing dependable, high-quality
automobiles.
Customers interested in the Honda Accord sedan, one of the mainstays of the
Honda line, can choose from five different models, ranging from the basic DX model to the fully
equipped EX V6.2
This wide range of offerings helps the Accord reach numerous different
market segments. Sony, often regarded as one of the premier developers of electronic goods,
produces a broad and almost-constantly evolving line of products. Its very successful Walkman
line has seen literally hundreds, perhaps thousands, of different iterations since its initial
introduction in Japan in 1979.3
Through this method of product development, Sony has
dominated the personal portable stereo market, with products designed for virtually every
market niche.
Intel's change-intensive approach to new product development confers considerable advantages.
By rapidly introducing new technologies, Intel can be more responsive to customer needs,
providing the products and performance that customers demand when they demand it.4 Firms
like Intel, which compete in fast clockspeed industries, must continually push the technology
envelope, keeping products innovative and new.' Intel releases a steady stream of new products,
each featuring the newest technological improvements, from faster clock speeds to enhanced
graphics capabilities. Because of this approach, product developers at Intel do not need to delay
products until every last new feature is fully developed.
Instead, new features that are not
incorporated into the latest product, will simply be included in the next iteration. In a product
development environment such as this, the main concern is simply that the new model be better
than the previous one.
6
With incremental improvements, companies can also limit their risk, as
new products often do not represent major expenditures of company time and resources. While
9
there are certainly many reasons for Intel's success, part of it can be attributed to its steady
introduction of new products.
Honda's variety-intensive approach also provides the company with a competitive advantage.
With a range of product offerings, Honda can better tailor its Accord models to the needs of
different market segments. In doing so, each product can address a specific market niche, thereby
allowing Honda to gain market share and increase profitability. Satisfying the diverse needs of a
large customer pool, while difficult, is often necessary to provide sufficient value to customers.
Honda's method of offering variety can be directly contrasted to Henry Ford's approach with the
Model T. The Model T offered the customer no variety, as evidenced by Henry Ford's famous
comment, "You can have any color car you want as long as it's black." 7 Although many factors
contributed to the eventual decline in Model T sales, one important factor involved the
shortcomings of the single model philosophy. In 1925, with General Motors now offering "a car
for every purpose and every purse," Ford's one product approach was no longer effective in the
marketplace.
8
Automobile consumers now wanted a wider range of product offerings and more
frequent model changes.
Some firms, such as Sony, actively practice both change-intensive and variety-intensive product
development. In what is sometimes called "hyper-variety," Sony produces hundreds of variants
of each product over a short period of time. 9 For example, with the popular Sony Walkman, Sony
introduced over 250 different models to the US market during the 1980's.O With such prolific
new product development, Sony was able to produce a Walkman model for almost every
imaginable market niche. With so many different product offerings, Sony's approach to product
development could almost be thought of as mass customization, not mass production."
Not
surprisingly, Sony dominated the personal portable stereo market in the US, capturing 45-50% of
market revenue in 1990.12
With this broad and rapid product development process, Sony has
developed a reputation as one of the most consistent and impressive developers of consumer and
industrial electronics.13
Intel, Honda, and Sony are good examples in today's marketplace of companies striving to
decrease time to market and increase product line breadth.
By decreasing time to market,
companies are able to produce products quickly, and are thus better able to actively respond to
shifting market needs. By offering a wide variety of products, companies can better satisfy the
diverse needs of the market. By doing both, companies can often dominate their industries.
10
1.1
The Importance of ProductArchitecture
Given these distinct advantages to maintaining broad and constantly updated product lines,
companies have looked for ways to offer such variety at reduced costs to the company. One such
method that has proven successful involves the use of carefully determined product architectures.
Product architecture, as defined by Ulrich, is the scheme by which the function of a product is
allocated to physical components. 4 Choosing an appropriate product architecture is a key step in
any product development process as it can have an enormous impact on the success of a product.
In turn, companies also have a great deal of latitude in selecting product architectures and must
weigh many often-competing objectives when attempting to select an appropriate architecture.
How important is the selection of an appropriate product architecture?
While some industries
have only recently begun to realize the value of selecting a suitable product architecture, other
industries, notably the automobile industry, have used this idea for quite some time.
It is
common to hear about automobile companies basing new cars on existing platforms, thereby
allowing companies to release cars faster and at reduced costs. The term product platform, as
defined by Robertson and Ulrich, is the collection of assets, ranging from actual components to
knowledge, which are shared by a set of products.' 5
In the case of the auto industry, what
constitutes a platform differs greatly between different carmakers.
Among automobile companies, Volkswagen (VW) is generally considered to be the leader in
product platforming. In 1999, its A4 platform was used to produce over 1.9 million cars, once
again making it the world's best-selling platform.' 6
This confusingly named platform provides
the basis for seven distinct car lines: the VW Golf, VW Beetle, VW Bora, Audi A3, Audi TT,
Skoda Oktavia, and Seat Toledo."
In the case of VW, the platform includes front axles, rear
axles, wheels, steering systems, front ends, rear ends, exhaust systems, seat frames, wiring, brake
systems, fuel tanks, and more.'1
VW claims that approximately 65 percent of the components in
the VW Golf are shared by the rest of the cars built on the same platform.'"
While this
represents a great deal of sharing, VW is striving to reach 70 percent commonality between this
family of cars. 0
11
Figure 1.1: Fleet of Volkswagen cars produced from the A4 platform.
On the left is the VW Golf. On the right (from top to bottom) are the
VW Beetle, Audi TT, VW Bora, Audi A3, and Seat Toledo.
In adopting this strategy of product platforming, VW cites numerous benefits. Perhaps the most
obvious is the sizeable reduction in cost, both in development and in production. In 1999, VW
22 Through
claimed to save $1.7 billion annually through its product platforming strategy.
platforming, VW was also able to reduce new model development time, lower component prices,
and reduce component counts within the group. Improved product quality was also realized by
VW, as technologies already tested in one car model could be successfully introduced into other
models built on the same platform.
Perhaps the greatest risk in using a platform-based product strategy is that all products may end
up being too similar. VW must make sure that the owner of an Audi TT feels as if he is driving a
sporty coupe, not a small family sedan such as the VW Bora. VW prevents this partially through
styling cues, which are clearly quite different between the various automobiles. VW also
differentiates the cars by changing the height of the driving position and by modifying the
suspension characteristics. By simply altering these few properties, VW claims that the cars can
be sufficiently differentiated in the eyes of the customer.
Other carmakers also actively pursue the idea of using product platforms to reduce costs. In
February of 2001, Daimler-Chrysler announced disappointing results for the fourth quarter
of 2000. The world's fifth-largest automaker reported loses of $269 million for the October
through December period of 2000. This came in stark contrast to a profit of $1.5 billion for the
same period of 1999.25 In starting to address these disappointing financial numbers,
12
DaimlerChrysler CEO Juergen Schrempp and Chrysler CEO Dieter Zetsche introduced a plan for
recovery. The plan featured four main components: eliminating 26,000 jobs over the next two
years, demanding immediate price cuts from suppliers, pushing ahead with the introduction of
new Chrysler vehicles, and sharing more of the underlying auto components between Mercedes,
Chrysler, and Mitsubishi.2 6
The mere fact that DaimlerChrysler would include the idea of
product platforms as a main point in their recovery, demonstrates the cost-cutting value of such
techniques.
In their plan for additional component sharing among their automobiles, DaimlerChrysler listed
numerous areas for greater sharing, including electronic controls, monitoring systems, seat
frames, rear axles, transmissions, and steering systems.
It also suggested sharing engines,
placing some Mercedes diesel engines into Chrysler cars such as the PT Cruiser and Jeeps,
although only in those versions sold in the European market.2 8 As far as automobile platforms,
DaimlerChrysler suggested much greater platform sharing between Chrysler and Mitsubishi,
reducing the total number of platforms used by DaimlerChrysler from the current 29, down to 12
to 16.29
Currently, Chrysler already uses a Mitsubishi platform as the basis for its Chrysler
Sebring and Dodge Stratus sedans.
While much greater sharing is scheduled at DaimlerChrysler, company insiders are still hesitant
to leverage platforms too much, for fear of blurring the distinction between Mercedes and
Chrysler automobiles. DaimlerChysler executives have religiously defended the Mercedes brand,
trying to maintain its lofted brand image as a fine luxury car. In fact, Mercedes executives have
repeatedly commented that protecting the Mercedes brand is the utmost priority for the
company.
31
Mercedes CEO Juergen Hubbert made it clear that there would be no sharing of
components beyond those that are largely invisible to the typical car buyer.
As for using
Mercedes platforms in Chrysler's American automobiles, such an idea was dismissed by Hubbert
as not being a topic of discussion. 3
1.2 Determining ProductArchitecture
Both the Volkswagen and DaimlerChrysler examples show some of the opportunities and
difficulties associated with product platforms. While enormous cost savings can be realized, the
risk that products will no longer be differentiated in the eyes of the customer is very real. While
in theory, product platforms provide a straightforward way for companies to reduce product
13
development time and cost, in practice, making actual product platform decisions is quite
difficult.
One difficulty lies in the fact that determining product architecture is not a task limited to one
area of a company.
Although product architecture may seem to be primarily an engineering
decision, in reality, product architecture choices have impacts across the company.
architecture affects product, process, and organization.
Product
Thus, many segments of a company
should be involved in the definition of a product architecture.
Firstly, product planners and
marketing managers must decide which markets to enter, what market segments to target, and
which customer needs to address.34 In doing so, they must understand the long-term development
strategy of the company, and select markets and targets based on this strategy. Secondly, system
engineers must decide what product architecture to use to effectively share components,
processes, and knowledge.
To do this, system engineers must understand the long-term
development strategy to ensure that the selected architecture will be useful for both current and
future products. The most effective product architectures usually arise when distinct disciplines
in an organization, including marketing, management, design, and manufacturing, work together
to define an architecture. However, often such groups are unaccustomed to working together and
sometimes interact very little. In short, determining an effective product architecture needs to be
a company-wide, collaborative initiative; product architectures derived by an isolated group
within the company, stand little chance of being effective for the company as a whole.
Even if the organizational barriers to product architecture are overcome, the job of determining an
actual product platform is still very difficult. This task is often left to senior systems engineers
who, through time and experience, have gained a solid overview of the product and thoroughly
understand the many product goals.
What makes this task difficult is that there are many
different approaches to determining product architecture, with the spectrum ranging from
engineering-based approaches to operations-based approaches.
Engineering-based approaches
tend to focus on functional issues such as manufacturing and assembly, and strive to create
product platforms so as to optimize these areas of the product development process. Operationsbased approaches to product architecture tend to focus on non-functional issues, including market
variety, serviceability, and supply chain issues.
Developing successful product architectures
usually involves keeping both functional and non-functional goals in mind and making trade-offs
between these often-competing objectives. Given the nature of this multi-attribute optimization,
product architecture decisions are often best made by senior systems engineers.
14
1.3
Scope of this Thesis
There are clearly numerous issues to be addressed in determining and implementing a successful
product architecture. This thesis focuses on the task of actually defining a product architecture.
The work presented here takes an operations-based approach to the problem, addressing the
influence of certain non-functional issues. Specifically, this thesis addresses how serviceability,
technology change rate, and supply chain influence product architecture. Detailed methodologies
to incorporate such concerns into product architecture decisions are developed and presented.
These methodologies are intended to be used by product developers, both experienced and
inexperienced, in determining effective product architectures.
1.4
Organization of this Thesis
Chapter 2 defines some of the terminology relevant to product architecture.
This chapter also
explores previous work in the field, providing the background for the work presented here.
Chapter 3 describes the importance of functional modeling and presents function structures as a
tool for making such models. Flow-based modularity heuristics, used to functionally determine
product architectures, are also presented.
Chapter 4 introduces a methodology to incorporate serviceability into product architecture
decisions.
Equations to calculate serviceability costs for different modularity schemes are
presented and demonstrated on an actual system.
Chapter 5 examines the influence of technology change rate on product architecture decisions.
Issues that should be considered when determining technology change rates are discussed.
A
methodology to use these technology change rates in determining product architecture is
presented and demonstrated.
Chapter 6 presents a methodology to incorporate supply chain concerns into product architecture
decisions. Supply chain issues are explored, focusing on how such issues can influence product
architecture. The methodology is then demonstrated on an actual system.
Chapter 7 summarizes the work presented in this thesis. Methods to determine an overall product
architecture are discussed and recommendations for future work are made.
15
16
2
Product Architecture
As shown in Chapter 1,
selecting the appropriate product architecture can have serious
ramifications for product and company success. Because of this, research in this field, and in
product development as a whole, has experienced significant growth in recent years. This chapter
defines some of the terminology used in product architecture. It also provides a brief overview of
recent research in this field, thereby laying the foundation upon which this thesis is built.
2.1
Terminology
Product architecture is the scheme by which the function of a product is allocated to physical
components.'
It is concerned with the arrangement of functional elements, and with how those
functional elements map to the physical components of the product. Product architectures are
divided into two main types, integral and modular.
Integralproduct architectures commonly
have multiple functions satisfied by a single component. Modular product architectures,on the
other hand, typically exhibit a one-to-one mapping between functions and components. Integral
and modular architectures each have their own advantages and disadvantages.
Products with an integral architecture have components that perform numerous functions. This
technique, known as function sharing, often allows integral designs to be better optimized than
modular designs.2
For example, consider a typical carpenter's hammer.3
The head of such a
hammer has an integral architecture. A single cast piece features the flat, head end, which can be
used to drive nails, and the pointed, claw end, which can be used to remove nails. This function
sharing allows for an elegant and efficient solution. In general, arguments for integral product
architectures stem from technical and performance-based needs.4
Products with a modular architecture are typically comprised of a set of product modules, each of
which only performs a single or a few functions.
Product modules are thus defined to be
sub-systems within a product that are bundled as a unit and that serve identifiable functions.
Products composed of such product modules are generally easier to change, as modules within
the product can be replaced individually, instead of replacing the entire product.
This has
important implications for product variety, time-to-market, product upgrade, and serviceability,
among others.
For example, consider a typical home stereo, where, due to standardized
interfaces, the receiver, tape player, CD player, and speakers can be mixed and matched from
17
various different manufacturers.5 Therefore, if a single component in the system needs to be
changed, the entire system is not disrupted.
This ability to easily undergo change must be
weighed against the disadvantages of a modular architecture, which include lack of product
differentiation and reduced product performance. In general, the arguments for modular product
architectures, and thus product modules, tend to be based on business concerns.
A product platform is the set of assets that are shared between products.
include components, processes, knowledge, people, and relationships.
These assets can
Such sharing across
products usually requires the use of an architecture that is somewhat modular in design.
As
discussed in Chapter 1, product platforms can have considerable advantages, including shortened
development time, lowered development cost, reduced product risk, and increased market variety.
The set of products based on a product platform constitutes a productfamily.
2.2
Managing Product Architectures
Much literature has been written addressing the organizational difficulties companies face in
planning for product architectures.
Wheelwright and Clark suggest the use of an "aggregate
project plan," which helps a company to manage the set and mix of projects under development.'
In an "aggregate project plan," projects are categorized as one of five types: breakthrough,
platform, derivative, research and development, and partnered. Once the complete set of current
and future product offerings is well categorized, a company can better select useful product
platforms.
Wheelwright and Clark stress the importance of platforms and believe that such
projects should constitute a central part of the "aggregate project plan."
The importance of
involving engineering, marketing, manufacturing, and senior management
in the up-front
planning of product platforms is also stressed.
Robertson and Ulrich present a methodology to help define a product architecture by analyzing
the distinctiveness and commonality in a design.' 0 They propose a process that relies on three
information management tools: a product plan, a differentiation plan, and a commonality plan.
Product developers can use these three tools to create a product architecture through an iterative
process. Robertson and Ulrich also stress the importance of having top management involved in
the platform planning process.
18
Meyer and Lehnerd present extensive case studies on platforms, demonstrating both their
advantages and challenges." They also suggest methods to help chart the evolution of platforms
and derivative products, thereby helping to plan product families. Pedersen examines some of the
advantages and disadvantages of platform-based design, and discusses some of the organizational
challenges faced by companies attempting platform-based product development. 12
Pedersen
comments that implementing a product development approach based on product platforms
requires a long-term perspective, both in terms of investment and organizational changes.
Pulkkinen, Lehtonen, and Riitahuhta introduce the idea of design for configuration, a method that
can be used in the development of configurable product families.' 3
Design for configuration
helps enable mass customization.
Martin and Ishii present methods that use indices to help quantify the costs associated with
providing product variety.14 These three indices, a commonality index, differentiation index, and
setup index, help designers to develop products that incur minimum variety costs.
Kota and
Sethuraman also use an index-based method, employing a Product Line Complexity Index to
capture the level of part commonality in a product family."
This index incorporates issues
including materials, manufacturing, and assembly into an overall score that can be used to
evaluate a family of products.
2.3
Determining Product Architectures
A great deal of work has also focused on how actual product platforms are determined. Various
methods have been developed to identify useful modules from a functional description of a
product. A method proposed by Stone, Wood, and Crawford, begins by functionally modeling
the product, then applying a set of heuristics to identify possible product modules.
is discussed in greater detail in Chapter 3.
16
This method
Siddique and Rosen propose a graph grammar
approach, which allows product developers to design new product families or increase the
commonality of existing families."
Product functions are represented using graphs, while
relationships between functions are incorporated through the use of grammar rules. These rules
can identify core functions, which become the platform, and optional functions, which become
unique modules.
While functionally based methods can indicate product modules, they represent only one of many
possible ways in which modularity can be determined. A great deal of other information can be
19
considered when making modularity decisions. Rechtin and Maier present a set of architecting
heuristics and checks that system engineers should consider when creating system modules.18
Ericsson and Erixon introduce many different "module drivers" that should be considered when
developing a product architecture.' 9 They also present case studies in which these considerations
are used in practice.
Moore, Louviere, and Verma use a customer needs-based approach to design product platforms.20
Data from conjoint analyses is used to evaluate product features and drive product platform
design. Product features that generate strong returns, and can be produced at a reasonable price,
are included as part of the product platform. Product features that are only beneficial to a specific
market segment are not included as part of the platform, and are instead add-ons to the platform.
Gershenson, Prasad, and Allamneni take a lifecycle view of modularity, looking at how a product
can be structured to address issues such as manufacturing, assembly, and service.2 '
Coulter,
McIntosh, Bras, and Rosen also examine the role of lifecycle considerations in product
architecture decisions.
Specifically, they examine how modularity can be used to improve
product recyclability.
The research described above shows some of the many methods for managing and determining
product architectures.
This thesis builds on this body of knowledge, introducing new
methodologies for defining product architectures.
20
3
Functional Modeling
Functional modeling is an important step in the product development process. It allows design
teams to completely describe a product by identifying the functions and sub-functions that the
product must complete.
In a sense, a functional model provides a blueprint for the product.'
Such a model, when correctly constructed, should consist of a set of form-independent, discrete,
indivisible functions.
Each function in the functional model contributes in some way to the
overall function of the product.
In recent years, additional emphasis has been placed on incorporating customer needs into
product development decisions. Functional modeling provides an effective means to do this by
allowing customer needs to be translated into functional descriptions of the product. Mapping
customer needs to function, as opposed to mapping needs to form, also allows design teams a
broader design space in which to work. No longer constrained to the form of a previous solution,
product developers are now free to explore blue-sky ideas.
Extracting problems out to the
functional level in effect broadens the problem and thus the solution set. By removing form and
component dependence, designers can gain a fresh perspective on the exact issues to be solved.
Functional modeling also plays a role in how a product, process, and design team are organized.
Understanding how the overall product function can be decomposed into sub-functions can help
in determining how the larger design project should be subdivided, both from a product and
process standpoint. It also allows a design team to break down a complex problem into simpler
sub-problems.
Furthermore, interactions between sub-functions often indicate how much
communication is necessary between sub-function design teams. Clearly, functional modeling
plays an important role in how products are developed.
This chapter focuses on the importance of functional modeling in product development.
It
explains a brief history of functional modeling and introduces different methods to functionally
represent products. Function structures, a specific method to functionally model products, are
explained in detail. Heuristic methods for determining product modules from a function structure
are then introduced and examined.
21
3.1
Background
The idea of functional modeling is not new.
In the 1940's, with the development of value
engineering, Miles emphasized the importance of functional modeling as the cornerstone for this
technique. 2
Of the three fundamental steps involved in value engineering, identifying the
functions of a product is the first.3 The idea behind value engineering is cost reduction from the
standpoint of function. Therefore, instead of striving to directly reduce the cost of the product,
the product is instead decomposed into a functional representation.
Each function is then
examined to find the least expensive way to perform that function. In functionally decomposing a
product, product developers attempt to separate the function that needs to be performed from the
actual solution.
As part of the value engineering methodology, function analysis system technique (FAST) was
introduced.4 This technique features the use of FAST diagrams, which display product functions
in a logical sequence and allow the functions to be prioritized.
Developed in 1965 by Bytheway,
this hierarchical approach categorizes functions based on importance, identifying overall product
functions and differentiating them from secondary product functions.
Overall, FAST diagrams
serve to help identify basic functions, systemize these functions, and provide a creative tool for
product developers.7
Functional modeling also has a rich history in German design. In many German product design
methods, emphasis is placed on identifying the key functions that a design needs to address. This
functional approach is based upon early works by Bischoff, Hansen, Rodenacker, and Roth.
From this functionally oriented basis grew the idea of function structures, as described by Pahl
and Beitz. 9 A function structure is a type of functional model that consists of a network of
sub-functions interconnected by flows.
While providing a functional decomposition of the
product, it also preserves the relationships between sub-functions, as represented by material,
energy, and information flows. This function structure method of functional modeling is used
extensively in this thesis, and is described in greater detail in the following section.
3.2
Function Structures
Function structures are created as a means to represent products functionally.
Establishing an
accurate, customer-based representation of product function is an important early step in product
development. The product function is the overall intended function of the product, or what the
22
product is to do.'
This overall product function is often comprised of numerous sub-functions,
which are simply components of the product function. These sub-functions correspond to subtasks that the product must complete. Product functions and product sub-functions can represent
the same functional product; the only difference is the level of abstraction. To move from a
product function to sub-functions, product developers must ask "how?"
To move up the
hierarchy, from sub-functions to product functions, product developers must ask "why?"
Both
functions and sub-functions are typically represented by a verb-object pair, such as "turn screw"
or "generate light."
Functions represent what the product must do to satisfy the needs of the customer. However,
there exist other non-functional constraints to designs, such as cost, size, and reliability. While
these are not explicit functions that the product must complete, they are important aspects of the
product development process. Such non-functional criteria constitute constraints.
Constraints
must be satisfied by the product, and thus require consideration during the product development
process."
Function structures can be developed by utilizing Otto and Wood's method of tracing flows.
2
This flow is then traced through the product,
For each customer need, a flow is identified.
through a sequence of sub-functions that change the flow. The point of view of the product is
always preserved.
Thus, items such as hands pass through the product, not vice versa.
The
sub-functions related to each of these independent flows are then merged into a complete function
structure which is comprehensive of the customer needs.
Interactions between functions in a function structure are represented by flows. These flows are
divided into three types: material, energy, and information. Material flows are concerned with
the movement of matter, such as gases, liquids, and solids. Energy flows focus on energy in all
forms, including electrical, kinetic, and magnetic energy. Information flows have to do with the
transfer of signals.
While such signals are often transferred electrically, there is a distinct
difference between the flow of electricity as energy and the flow of electricity as information.
Functions and flows taken together provide a comprehensive functional view of a product. Each
sub-function helps to decompose the overall product function into simpler and smaller units. The
flows interconnecting these units show the relationship between sub-functions. They also provide
an idea about the complexity of the interactions between various sub-functions within the system.
23
In this thesis, specific symbols are used in representing function structures. Functions are shown
as boxes.
Flows into and out of functions are represented by three types of arrows: unfilled
arrows represent material flows, filled arrows represent energy flows, and dashed arrows
represent information flows. These standards are shown in Figure 3.1.
Material
Energy
Information
N
Function
e
Material
Energy
Information
Figure 3.1: Generic function with flows.
As an example, a function structure for a Black and Decker cordless screwdriver was created.
The product is shown in Figure 3.2 while the function structure is shown in Figure 3.3.
The
function structure shows various distinct product sub-functions, each in its own box. Arrows
between the boxes show the various flows. The system boundaries, where the user interacts with
the product, exist where these flows enter and exit the system. Note that only product functions
are shown; functions completed by humans and other systems in the process of inserting or
removing screws are not shown. Also, only the objects the device actually interfaces with are
part of the function structure. Objects outside this system are shown as flows into and out of the
structure.
Figure 3.2: Black and Decker cordless screwdriver.
24
Electricity
Store
Electricity
Noise
Heat'
Electricity
C0r
to Motion
Transmit
Electricity
Inputlehi
Switch
Power
Thumb
Signal
Thumb
Screw
Transform
NTs(--
Hand
L
Hand
Hot Turning
Screw
Turn
Screw
Transmit
Power
Rotation
Permit Bit
Positioning
Bit Position
Force
.
-Reaction
Hand
Hand
Force
Bit
Register
Bit
Un-lock
Bit
Secure
Bit
Release
Bit
Bit
Force into
opposite hand
Bit
v Secure
Figure 3.3: Function structure for a Black and Decker cordless screwdriver.
The gray area shows the system boundaries.
Function structures can be used at different stages of the product development process. They are
sometimes used in very preliminary research and development efforts to help conceive and
develop new technologies that are not yet physically viable. In this use, the ability of function
structures to represent the product in a form-independent manner allows designers to generate
new ideas and conceive alternative product forms.
For example, with the Black & Decker
cordless screwdriver, which utilizes a rechargeable battery, one could generate a new technology
concept that uses a different physical principle, such as compressed air, to power the device. In
this instance, functional modeling could be used to describe requirements at a level of detail
generic to both physical principles.
This use of functional modeling is different from how
function structures are used in this thesis.
Function structures can also be used later in the product development process, such as for
3
deriving physics, establishing specifications, and specifying interface requirements.
25
For
example, function structures can be used to focus on the deployment of a technology into product
lines. Once a technology concept has been selected and developed to the point of feasibility,
function structures can help determine how to implement this technology concept into actual
products. In this thesis, function structures are used to help partition a product concept. This is a
problem for which functional modeling, and function structures in particular, is ideally suited.
3.3
Modularity Heuristics
Once a functional model of a product is created, it can be used to help in determining product
architecture. A set of heuristics, developed by Stone, Wood, and Crawford, can be used to
14
identify useful product modules from a well-developed function structure. This clustering of
sub-functions into modules relies on examining flows in the function structure. By grouping subfunctions based on flow heuristics, functional relationships can be preserved. This method relies
on three heuristics to derive a modular product architecture: dominant flow, branching flows, and
conversion-transmission
The dominant flow heuristic examines flows through a function structure, following flows until
they either exit from the system or are transformed into another flow. The sub-functions through
which a flow can be traced, define a module. More succinctly, a set of sub-functions through
which a flow passes, from initial entry or formation of the flow in the system, through final exit
or conversion of the flow within the system, define a module.
=4 Function
FunctIOW ---
Function
Figure 3.4: Example of the dominant flow heuristic.
The branching flow heuristic examines flows that branch into or converge from parallel function
chains. Each branch of a flow can become a module. Each of these modules interfaces with the
product through the point at which the flow branches or converges.
26
Figure 3.5: Example of the branching flow heuristic.
The conversion-transmission module examines flows that are converted from one type of flow to
another. A conversion-transmission module converts an energy or material into another form,
then transmits that new form of energy or material. In many instances, this conversiontransmission module is already housed as a module, as in the case of an electric motor.
Convert
Convert
Transmit
Flow
Flow
Figure 3.6: Example of the conversion-transmission heuristic.
While following these three heuristics results in product modules that maintain physical
consistency, they also provide the maximal set of functions to incorporate into a module. There
are reasons, however, to further refine these suggested modules into smaller groupings. For
example, some of the functions within a maximal module might have excessive lifecycle costs,
such as for repair.
Similarly, a supplier might be able to provide some, but not all, of the
functions within a suggested maximal module.
In both cases, the maximal module should
perhaps be split. The next three chapters present methods to incorporate such non-functional
issues into product architecture decisions. Specifically, the effect of serviceability, technology
change rate, and supply chain on product architecture is examined.
27
28
4
Serviceability
In many industries, service is a major consideration for product development teams. A great
number of high-end products, including photocopiers, automobiles, and airplanes, require regular
service and maintenance for optimal performance.
Such service concerns must be taken into
consideration during the product development process to ensure that products are designed for
easy and straightforward upkeep. Ignoring such factors can lead to products that are both difficult
and costly to maintain.
At the Xerox Corporation, serviceability is a major factor to consider when determining product
architecture. Most Xerox products span a broad range of service levels. At the most basic level,
Xerox products must be regularly serviced by the customer. Consumable parts, such as paper and
toner, must be routinely replaced by the customer. While this may not be thought of as service, it
is the most commonly needed type of repair. On a slightly higher level, Xerox products must also
be serviced after simple, random, unplanned malfunctions, such as paper jams. Such problems
are once again most commonly repaired by the customer.
At the other end of the service
spectrum are repairs that warrant trained Xerox service agents. These repairs can range from
fixing unexpected failures to replacing components as part of a regularly scheduled maintenance
plan. To handle such repairs, Xerox enters into Field Service Maintenance Agreements with their
customers based on a monthly and per print service fee. Thus, such repairs, and the network of
service agents associated with these repairs, represent both a substantial income source and cost
to the company.
Clearly, with a family of products that require diligent upkeep for optimal
performance, serviceability issues play a major role in product design deliberations. In selecting
a suitable product architecture, engineers must be well aware of serviceability concerns. In this
chapter, a methodology for incorporating serviceability issues into product architecture decisions
is presented.
This method is then demonstrated on a document system from the Xerox
Corporation.
4.1
Related Work
Design for serviceability has been receiving additional attention in recent years. Since it plays a
role both in the product's lifecycle service costs and in long-term customer satisfaction, this
additional emphasis is certainly warranted.
Techniques have been developed to help product
developers address serviceability requirements during early stages of the design process. One
29
such technique that has gained some popularity is that of Failure Modes and Effects
Analysis (FMEA).
FMEA, initially developed in the 1960's for the aerospace and defense industries, is a method for
addressing reliability issues in the early stages of a design.' By providing information early in the
process, designs can be improved to increase product quality, improve reliability, and reduce
lifecycle service costs. FMEA helps design teams to identify, evaluate, and eliminate known or
potential failure modes of a product.2 FMEA focuses on the occurrence, severity, and detection
of failures, assigning risk priority estimates to various failure modes. These risk priority numbers
help to organize the various failure modes, prioritizing them to determine which should be
addressed first.
While FMEA provides a useful tool for product developers, other more probabilistic methods can
be used when additional data is available.
statistical data can be used.
If historical failure rate data is available, such
In design for serviceability, it is critical that failure rates are
accurately predicted or measured, as these failure rates can play an important role in design
deliberations. Because data is available, the examples presented in this chapter use a data driven
approach to design for serviceability. However, in the absence of such data, FMEA estimates
could have been equivalently used.
Other research involving lifecycle engineering has also examined the role of serviceability in
product design. Gershenson and Ishii were among the first to address serviceability in design.3
They recognized the drivers of service cost, including part cost, labor cost, and failure rate. This
information was incorporated into worksheets that could be applied to analyze any design. Parts
of their work, including the basis for serviceability cost equations, directly apply to the work
presented here. Modified forms of their equations are used here to evaluate candidate modules
and architectures. Ishii also looks at an integrated lifecycle design methodology that would allow
engineers to better understand the lifecycle implications of certain design decisions. 4
Ishii
presents specific evaluation methods for calculating serviceability costs. While these works focus
on the role of serviceability in product design, the work presented in this chapter looks at the role
of serviceability in product architecture, a related, but distinct area of research.
Work has also been done to look at modularity and its effect on design for the lifecycle.
One
such method looks at modules from the viewpoint of material recycling, service, and post-life
30
intent. This method relies on measuring modularity based on module correspondence between
several viewpoints and coupling between modules. An architecture decomposition algorithm is
then applied to partition a product into modules from each lifecycle perspective.
The method
presented here isolates a specific lifecycle aspect, that being serviceability. It also takes a more
numerical and in-depth approach to selecting a product architecture.
4.2
Approach
The method to incorporate serviceability into product architecture involves five basic steps, as
shown in Figure 4.1.
Create a function structure for the
given product.
Determine part cost, labor cost, and
reliability information for each function.
Determine candidate modularizations
using flow heuristics.
Compute serviceability costs for each
candidate modularization.
Evaluate alternative architectures.
Figure 4.1: General methodology for including serviceability
in product architecture decisions.
The method begins with the construction of a function structure for the given product.
This
function structure, as described in detail in Chapter 3, should contain all functions that the
product must fulfill, as well as the material, energy, and information flows between the functions.
Next, each function should be analyzed to determine part cost, labor cost, and reliability
information. To determine such information, the parts used in a design are attributed to particular
31
functions.
Part cost for a particular function is thus simply the sum of the part costs for those
involved in completing that function. Labor cost for a function can be determined by examining
the time it takes to replace the set of parts responsible for carrying out that particular function.
By knowing individual reliabilities for each part, reliability for a function as a whole can be
calculated. New products that are currently under development may not have part costs, labor
times, and failure rates from past data, but these quantities can usually be estimated, typically
from previous product generations or from developmental prototypes.
With this information,
serviceability can be incorporated into the product architecting process.
Product architecture is first determined by applying the partitioning heuristics, as discussed in
Chapter 3, to the function structure created in step one of this method. Functions in the function
structure are grouped by following flow-based product partitioning heuristics.
Application of
such heuristics allows various candidate modularity schemes to be developed, depending on
which flows are considered.
As mentioned previously, while these ideas provide modules that
maintain physical consistency, they often incorporate the maximal set of functions into a module.
Frequently, reasons exist why such suggested modules should be further refined.
As such
breakouts are not obvious, the next step in this method uses serviceability equations to examine
serviceability constraints on product modularity.
For any modularity scheme generated, it can then be analyzed by applying serviceability
equations. These equations utilize the serviceability estimates from step two of this process. By
using part cost, labor cost, and reliability information, the serviceability cost for each modularity
scheme can be determined.
With serviceability costs determined for the entire product under each candidate modularization,
the product development team is left to evaluate the potential architectures. At this point, product
developers must be aware of the many trade-offs involved in selecting a suitable product
architecture.
This five-step approach provides a new systematic methodology to architect a
product while considering serviceability issues.
32
4.3
Modeling Serviceability
Considering serviceability constraints is important when making product modularity decisions for
products that require maintenance and repair. In such situations, product modularity needs to
address the trade-offs involved between reliability, part cost, and labor cost.
For example,
increasing part reliability often increases part cost. However, with increased reliability, fewer
repairs are necessary, resulting in lower labor costs. Given the nature of these three metrics, the
maintenance cost structure for a given product should be understood prior to making modularity
decisions.
4.3.1
Basic Service Cost Equations
In evaluating service costs, equations can be used to take into account reliability, part cost, and
labor cost. The basic service cost equation for any single product failure, independent of service
model, is as follows,
(4.1)
Cservice = Cfixed labor + Cvariable labor + Cparts
Where Cservice
Cfixed labor
Cvariable labor
Cpars
In the above equation,
Cfixed labor
= Service Cost for any single service
= Fixed Labor Cost ($)
= Variable Labor Cost ($)
= Parts Cost ($)
($)
refers to the labor cost associated with sending a maintenance
representative to the customer site. The variable labor cost,
Cvariable labor,
refers to the labor cost
associated with actually repairing the product once at the customer site. The cost of the replaced
components is represented by the value Cpas.
To calculate the service cost of a product over a given period, the service cost equation must also
include a failure rate. This failure rate can take the form of failures per length of time or failures
per number of cycles. Once again, this equation is independent of the service model used. After
including this failure rate, the equation appears as follows,
Clife = (Cfixed labor + Cvariable labor + Cparts) x Fprojuct
Where Clife
Cflxed labor
Cvariable labor
CPals
Fproduct
=
=
=
=
=
Service Cost for a given period ($ per period)
Fixed Labor Cost ($)
Variable Labor Cost ($)
Parts Cost ($)
Product Failure Rate (failures per period)
33
(4.2)
By splitting labor cost into labor time multiplied by labor rate, the above equation takes the
following form,
Clife = [[(Lfixed labor + Lvariable labor) x Rlabor] + (Cans)] X Frodt
Where Clife
Lfixed labor
Lvariable labor
Riabor
Cpars
Fproduct
(4.3)
=
=
=
=
Service Cost for a given period ($ per period)
Fixed Labor Time (hours)
Variable Labor Time (hours)
Labor Rate ($/hour)
= Parts Cost ($)
= Product Failure Rate (failures per period)
The service cost equations presented here are typically applied to consider only the costs borne by
the company that produces the product. In short, the equations are normally used only to provide
an internal view of serviceability. The equations do not reflect the cost or hardship experienced
by the customer.
Therefore, companies must also examine their service policy from the
customer's point of view. For example, these equations do not consider the cost of down time.
While the company that produces the product may not suffer from product down time, their
customers may lose significant revenue due to the time it takes to secure replacement parts and
repair the product.
satisfaction.
Excessive down time may also adversely affect long-term customer
Companies should be aware of such factors when structuring their products and
service departments.
For any single product, Equations 4.1 through 4.3 hold true. However, these equations are not
entirely correct when failures can occur in multiple independent modules within a product. For
these situations, slightly different service cost equations are necessary, depending on which
service model is considered. These different service models are explored in greater detail in the
upcoming sections. The appropriate service cost equations for each particular model are also
presented. First, however, a short background in reliability analysis is provided.
4.3.2
Basic Reliability Concepts
Determining and understanding the failure rate of components and modules is not a trivial task.
An entire field of research known as reliability engineering exists to better understand issues
including reliability, quality, and failure. Given that reliability is defined as the probability that
an item will not fail for a specified period under stated conditions, any reliability analysis will, by
default, involve probability.6
A basic understanding of probability is thus necessary prior to
34
delving into any reliability analysis.
While the methodology to incorporate serviceability into
product architecture is not meant to involve a rigorous reliability analysis, it is important that
product developers understand the reliability information that they possess and how it should be
used. Thus, a few basic concepts directly relevant to the examples presented below are explained.
Probability distributions are commonly used to represent reliability for mechanical and electrical
components.
The most popular and most commonly used probability distribution in reliability
engineering is the exponential distribution.' The exponential distribution is simple to use and is
often used to represent the reliability of electronic components.
It has a constant failure rate,
meaning that a component is equally likely to fail at any time. This means that such a distribution
has a memory-less quality to it; the probability that a component will fail during some period of
time in the future is independent of its age. Therefore, each component always has the property
of being as good as new.9 A good example of such a distribution involves that of an automobile
tire failing due to a nail puncture. A tire is equally likely to be punctured by a nail at any time
during its service.
Its likelihood of failure by nail puncture is thus constant and can be
represented using an exponential distribution. Such a distribution implies that failure of a device
does not take place through wear and deterioration, but rather through a random or sudden
event.'0 With an exponential distribution, reliability figures such as mean time between failures
(MTBF) are readily available. Given a constant failure rate of X, the MTBF is the reciprocal of
the failure rate, or 1/ X.
Another model of reliability is the Weibull or "bathtub" distribution.
reliability analyses to represent mechanical components.
It is commonly used in
The Weibull curve, shown in
Figure 4.2, has three distinct regions. The first region, or break-in period, features a high but
decreasing failure rate. These failures can be attributed to such factors as manufacturing errors,
material defects, and missing parts. The next region of the Weibull curve is commonly referred
to as the useful life period, and is signified by small and near-constant failure rates.
region, failures occur as the result of random and unexpected events.
These include power
surges, vibrations, mechanical impacts, temperature fluctuations, and moisture variations."
middle region is typically the longest of the regions.
In this
This
As the failure rate in this region is the
lowest, it is usually the one claimed to be the failure rate for the product. The last region of the
Weibull curve is the wearout period. This region features a rapidly increasing failure rate, as
components gradually age and deteriorate. Such deterioration of parts can usually be attributed to
factors such as corrosion, embrittlement, fatigue cracking, and diffusion of materials.' 2
35
Break-in :
period 1
Wearout period
Useful life period
191
tEtW
Time
Figure 4.2: A typical Weibull curve.
The failure rates for the three regions of the Weibull curve can be improved through different
methods.
The break-in period can be reduced or eliminated by burning-in and debugging
components before releasing them to the market.
This region can also be addressed by
implementing stricter quality control measures. The second region of the Weibull curve can be
addressed through improved design of the components. By making designs more robust to their
environment, the failure rate in this region can be significantly reduced. The failure rate of the
third region can be reduced through the design of more durable components and the selection of
more durable materials.
This region can also be addressed through a policy of scheduled
inspections and preventative maintenance.
The useful life period of the Weibull curve is of particular interest. By breaking-in components at
the factory, and by later replacing components as they enter the wearout period, components in
the field can be limited to those in their useful life region. This region encompasses the period
from
tE,
the time a component is released to the market, to tw, the time a component is replaced.
This period is shown in Figure 4.2. In this useful life region, the failure rate is constant and can
3
be modeled using the exponential distribution mentioned earlier.'
36
In the following examples, systems are analyzed using two different service models.
These
service models, while both valid, lead to different system reliability figures, and thus different
serviceability equations.
This in turn can lead design teams to different product architecture
solutions. The first reliability model discussed is referred to as the Random FailureModel. The
second model discussed is referred to as the Periodic Maintenance Model.
Which model is
actually used depends on each company's approach to service and maintenance.
4.3.3
Random Failure Model
The first service model considered incorporates random component failures.
In this model,
components fail according to probability distributions. For simplicity, a constant failure rate is
used in this example, although other failure functions can also be used. If a constant failure rate
is applied, the component can be modeled as if it is in the useful life period of the Weibull curve,
as seen in Figure 4.2. This constant failure rate has a memory-less quality to it, meaning that its
failure rate is independent of age. This means that no matter how recently a component has been
replaced, its failure rate remains constant. Once again, the tire and nail example applies. A tire is
equally likely to fail due to a nail puncture when new as it is when nearing the point of needing
replacement.
The assumptions for this situation are important to note. It is again assumed that components are
tested and broken in prior to use in the field, thereby avoiding the high failure rates associated
with the break-in period of the Weibull curve.
The constant failure rate, X, is determined
according to the MTBF data, where MTBF equals 1/k. While this failure rate increases as the
components enter the wearout period of the Weibull curve, it is assumed that the maintenance
point, tw, is set such that most of these components are removed prior to or early on in the
wearout period. Thus, the failure rate does not increase substantially, if at all, before a part is
removed. Therefore, for the life of a component, the failure rate can be simply modeled as X.
The assumptions for this model are representative of many failure modes of consumer products,
including photocopiers and automobiles.
For example, consider again the case of automobile
tires. Assuming that tires are thoroughly tested prior to leaving the factory, the break-in period is
avoided.
During the tire's life, its chances of random, unexpected failure remains relatively
constant. Such failures can be attributed to chance events such as nail punctures.
As the tire
approaches 40,000 miles, the failure rate begins to increase slightly, reflecting wearout.
However, before failure rates increase drastically, automobile owners typically replace the tires,
37
-
--
-11M-OW-
Mm-
--
- -
thereby starting the cycle again. The plot of failure rate versus mileage is shown in Figure 4.3.
Multiple tire lifecycles are shown. The first set of tires is replaced at twi, while the second set of
tires is replaced at tw2. If both of the tire sets have the same failure rate during their useful life
periods, then the failure rate is constant over both sets of tires, from time 0 to time tw2.
0.007-
Useful life period 1
0.008-
/
T
____________________T
Wearout period I
I
Useful life period 2
0.005 -
Wearout period 2
10.004-
U.O.003-
0.002
-
0.001 -
tw2
tw1
-
0
0
10000
20000
30000
50000
40000
0000
70000
80000
90000
100000
Mileage (miles)
Figure 4.3: Plot of failure rate versus mileage for automobile tires.
The use of this method has implications for module reliability. In this case, the reliability for a
grouping of independent components is a function of the product of the reliabilities of each of the
components that make up the module. Therefore, the overall reliability of the module declines as
more components are included. For example, consider a module comprised of three independent
components: one with a reliability of 0.98, one with a reliability of 0.95, and one with a reliability
of 0.90. If the components have independent failure modes, and assuming that the failure of any
component causes failure of the entire module, then the module reliability is the product of these
three reliabilities, or 0.84.14
Using the Random Failure Model to analyze service costs leads to specific serviceability
equations. For example, consider two modularity schemes, A and B, as shown in Figure 4.4.
Modularity scheme A groups both functions into a single module, while modularity scheme B
splits the functions into two separate modules.
38
A
B
Figure 4.4: Two different modularity schemes, A and B.
Intearated Modularity Scheme (A) usine the Random Failure Model
As discussed previously, service costs are comprised of three main components: fixed labor cost,
variable labor cost, and part cost. For this example, service costs are broken into these three
categories. For the integrated modularity scheme A, the equations for these costs per period are
as follows,
Fixed Labor Cost A
Cfixae labor =
(Lfixed x Riabor)
X
Fu
(4.4)
2
Lfaxe
= Fixed Labor Cost ($ per period)
= Fixed Labor Time (hours)
Riabor
= Labor Rate ($/hour)
FIU2
= Failure Rate for Union of I and 2 (failures per period)
Where Cfix labor
Variable Labor Cost A
(4.5)
Cvariable labor = (Lvariable12 x Riabor) X Fiu2
Where Cvarjable labor
Lvariable12
Riabor
= Variable Labor Cost ($ per period)
= Variable Labor Time for Functions 1 and 2 (hours)
= Labor Rate ($/hour)
= Failure Rate for Union of 1 and 2 (failures per period)
Part Cost A
(4.6)
Cparts= (P1 + P2) xFIu2
Where Cpar.
P
P2
FIU2
= Part Cost ($ per period)
= Replacement Part Cost for Function 1 ($)
= Replacement Part Cost for Function 2 ($)
= Failure Rate for Union of 1 and 2 (failures
per period)
The overall service cost equation for modularity scheme A is thus,
CA = [[(Lfixed + Lvariablel2) x Riabor] + (P1 + P 2 )] xFIU2
39
(4.7)
Split Modularity Scheme (B) using the Random Failure Model
The split modularity scheme B is analyzed in a similar manner, once again separating the service
cost into fixed labor cost, variable labor cost, and part cost. The equations for these costs per
period are as follows,
Fixed Labor Cost B
Crixed labor - [(Lfixed x Rabor) x F1] + [(Lfixed x Riabor) x F 2 ] - [(Lfixed x Rabor) x Fn
Where
Cfixed labor
Lfixed
Rlabor
F1
F2
Fin2
=
=
=
=
=
=
2]
(4.8)
Fixed Labor Cost ($ per period)
Fixed Labor Time (hours)
Labor Rate ($/hour)
Failure Rate for Function I (failures per period)
Failure Rate for Function 2 (failures per period)
Failure Rate for Intersection of 1 and 2 (failures per period)
Variable Labor Cost B
Cvariable labor = [(Lvariablel
Where
Cvariable labor
Lvariablel
Lvariabe2
Riabor
F1
F2
x Rlabor)
=
=
=
=
=
=
x
F1]
+ [(Lvariabe2 x Rlabor) x
F 2]
Variable Labor Cost ($ per period)
Variable Labor Time for Function 1
Variable Labor Time for Function 2
Labor Rate ($/hour)
Failure Rate for Function 1 (failures
Failure Rate for Function 2 (failures
(4.9)
(hours)
(hours)
per period)
per period)
Part Cost B
Cparts= (P x F1 )+ (P 2 x F 2)
Where Cparts
P
P2
F1
F2
=
=
=
=
=
(4.10)
Part Cost ($ per period)
Replacement Part Cost for Function 1 ($)
Replacement Part Cost for Function 2 ($)
Failure Rate for Function 1 (failures per period)
Failure Rate for Function 2 (failures per period)
In Equation 4.8, Fin2 represents the simultaneous failure of both Function 1 and Function 2. The
last term in Equation 4.8 is included to take into accout the fact that a simultaneous failure,
although involving the failure of both Function 1 and Function 2, only requires one service trip.
The reason for subtracting the simultaneous failures is perhaps best shown through a Venn
Diagram, as seen in Figure 4.5. The failure region is the entire area within the two circles.
40
M1
2
12
Figure 4.5: Venn Diagram showing failure modes of the split modularity scheme (B).
From probability mathematics, it is known that given two events, El and E 2 , which are not
mutually exclusive, then,
P(EIUE 2)= P(E 1) + P(E 2) - P(EinE 2)
(4.11)
Using this property, Equation 4.8, the fixed labor cost equation for modularity scheme B, can be
simplified to the following,
Fixed Labor Cost B
(4.12)
Cfixed labor = (Lfixed x Riabor) x Flu2
Combining Equations 4.9, 4.10, and 4.12 yields the overall service cost equation for modularity
scheme B, as follows,
(4.13)
x Riabor) + (Pi )] x (Fl)] +
[[(Lvariable2 x Rlabor) + (P 2 )] x (F 2 )] + [(Lfixed x Riabor) x Flu2 ]
CA = [[(Lvariablel
This formula can equivalently be written as follows,
CA = [[[(Lfixed + Lvariablel) x Riabor] + (P 1 )] x (F1 )] +
[[[(Lixed + Lvariable2) x Riabor] + (P 2 )] x (F 2)] - [(Lfixed x Riabor)x
(4.14)
Fin
Equations 4.4 through 4.14 assume that product failures can be attributed to the module that
actually failed. Given this, it is assumed that only the failed module is replaced. The equations
also reflect the fact that modules are completely replaced when any failure occurs within. That is,
Instead, the entire module is replaced; failed
the modules are not inspected or diagnosed.
constituent parts are not replaced separately. This is a typical practice in the electronics industry.
On the other hand, if some modules have service modes in which their constituent parts can be
individually replaced, the equations above can be readily modified.
By comparing Equations 4.4 and 4.12, it becomes clear that using the Random Failure Model,
fixed labor costs do not serve to differentiate between modularity schemes. The split modularity
41
scheme has failure modes that require the same number of service trips as the integrated
modularity scheme.
Therefore, given two modularization schemes, one with an integrated
module and one with multiple, smaller, independent modules, the fixed service costs for the two
schemes are identical.
The only difference is whether the service agent replaces different
sub-modules at different times or the entire monolithic module several times. With the Random
Failure Model, fixed service costs are the same.
This result has a significant impact on how product modules are determined.
For independent
failure modes, the Random Failure analysis means that the fixed labor cost is the same regardless
of the modularity scheme used. Therefore, for this service model, only part cost, variable labor
cost, and failure rate should play a role in determining product architecture based on
serviceability. In general, single module schemes, such as modularity scheme A, will result in
higher part costs, as a larger module must be replaced with each service trip. However, with the
larger module, it will perhaps be easier to service, thereby lowering the variable labor cost.
The fact that the fixed labor cost is independent of the modularity scheme used is based partially
on the idea that the system reliability is simply the product of the constituent reliabilities for
independent events. While this is a well-accepted calculation, it is not always true in practice, as
failure modes are frequently not independent.
Often, the reliability of larger multi-functional
modules is better than the product of the reliabilities of the constituent functions. Research by
Barkan and Hinckley suggests that products designed following design for assembly (DFA) rules
have fewer overall defects, and thus higher reliability.15
In DFA, various rules are used to
improve the design, the most prominent being to minimize part count. In short, minimizing part
count generally increases reliability by eliminating or reducing component failure sources. Based
on this, it is highly likely that the reliability of a large module will be better than the reliability of
multiple smaller modules.
This also makes sense from the viewpoint of system interactions.
With fewer large modules, as opposed to numerous smaller modules, the number of interfaces
between modules is reduced. With fewer interfaces, reliability is likely to improve.
4.3.4
Periodic Maintenance Model
The Periodic Maintenance Model is based on a rigorous maintenance program that replaces parts
frequently to prevent component failure. In this model, components are only in use during the
useful life period of the Weibull curve. This method of avoiding the first and last regions of the
Weibull curve means that components are tested and broken in prior to field use, then removed
42
prior to entering the wearout period. However, unlike in the previous model, the failure rate
during the useful life period of the Weibull curve is assumed to be negligible. In some types of
service environments, this is not an unreasonable assumption.
It was discussed earlier that
failures during the useful life region occur due to random and unexpected events. This failure
rate can be decreased through robust part design. Assuming that this random failure rate is zero
simply means that parts are well designed and do not fail unexpectedly. Instead, parts only fail
due to wearout or other time-dependent reasons.
This method also assumes that parts will
definitely fail upon reaching the wearout period.
After passing its use limit, tw, as seen in
Figure 4.6, the component has a 100% likelihood of failing. Given this, components must be
replaced at or prior to tw to avoid failure. Using this method means that components are never
replaced due to failure; instead, all maintenance is of the preventative type, completed prior to
failure.
1.2-
Wearout period
Useful life period
0.8
U0
0.0o.6-
0.4-
0.2-
0
TimeW
tE
Figure 4.6: Cumulative Distribution Function for components based on the Periodic Maintenance
Model. The model assumes no random failures and a 100% failure rate at t 4 , the use limit.
Such a maintenance plan is only suitable in certain situations. Usually, it involves an active plan
of preventative maintenance, replacing components early and often. In these cases, the tw point is
often set early, so as to increase confidence that the product will not enter the wearout period.
This results in replacing components that may still have some useable life remaining. However,
by replacing them early, failure can be avoided. Such methods are often employed in military
43
and aerospace applications, where the cost of failure can be very high. These models can also be
applied to other periodically maintained products, including oil filters and toner cartridges. In
each of these cases, regular maintenance and service reduce unexpected failure to negligible,
near-zero levels.
Using this method for component reliability means that for any grouping of independent
components, the reliability for that grouping is driven by the least reliable element. For example,
consider a module comprised of three independent components: one which fails after 100,000
uses, one which fails after 150,000 uses, and one which fails after 200,000 uses. With the
assumptions given above, each of these components, if not replaced on or before their use limit,
will definitely fail. Prior to their use limit, their failure rate is zero. The module as a whole will
thus fail at 100,000 uses. Replacing the module at 100,000 uses means that only one component
drives the maintenance schedule. The other components, with use limits of 150,000 and 200,000,
do not affect the regular maintenance schedule.
Using the Periodic Maintenance Method to analyze service costs leads to different serviceability
equations. For example, consider again two modularity schemes, A and B, as shown in
Figure 4.7. Modularity scheme A groups both functions into a single module, while modularity
scheme B separates the functions into two separate modules.
A
B
Figure 4.7: Two different modularity schemes, A and B.
Integrated Modularity Scheme (A) using the Periodic Maintenance Model
Service costs are again broken into three categories: fixed labor cost, variable labor cost, and part
cost. For the integrated modularity scheme A, the equations for these costs per period are as
follows,
44
Fixed Labor Cost A
Cfixed labor
Where
=
(4.15)
(Lfixed x Riabor) X Fmax (1,2)
= Fixed Labor Cost ($ per period)
= Fixed Labor Time (hours)
= Labor Rate ($/hour)
= Maximum of the Failure Rates for 1 and 2 (failures per period)
Cfixed labor
Lfixed
Riabor
Fmax(1,2)
Variable Labor Cost A
Cvariable labor
Where
=
(4.16)
(Lvariable12 x Riabor) x Fmax (1,2)
Cvariable labor
Lvariablel 2
Riabor
Fmax(1,2)
=
=
=
=
Variable Labor Cost ($ per period)
Variable Labor Time for Functions 1 and 2 (hours)
Labor Rate ($/hour)
Maximum of the Failure Rates for 1 and 2 (failures per period)
Part Cost A
Cparts= (PI + P 2 ) x
(4.17)
Fmax(1, 2)
Where Cparts
P
P2
Fmax (1,2)
=
=
=
=
Part Cost ($ per period)
Replacement Part Cost for Function 1 ($)
Replacement Part Cost for Function 2 ($)
Maximum of the Failure Rates for 1 and 2 (failures per period)
The overall service cost equation for modularity scheme A is thus,
CA = [[(Lixed + Lvariablel2) x Riabor] + (PI + P 2 )] x Fmax (1,2)
(4.18)
Split Modularity Scheme (B) using!the Periodic Maintenance Model
The split modularity scheme is analyzed in a similar manner, splitting up the service cost into
fixed labor cost, variable labor cost, and part cost.
For the split modularity scheme B, the
equations for these costs per period are as follows,
Fixed Labor Cost B
Cfixed labor = [(Lfixed x Riabor) x F] + [(Lfixed x Riabor) x F 2] - [(Lfixed x Riabor) x Fin2 ]
Where
Cfixed labor
Lfixed
Riabor
F1
F2
Fin2
=
=
=
=
=
=
(4.19)
Fixed Labor Cost ($ per period)
Fixed Labor Time (hours)
Labor Rate ($/hour)
Failure Rate for Function 1 (failures per period)
Failure Rate for Function 2 (failures per period)
Failure Rate for Intersection of 1 and 2 (failures per period)
45
Variable Labor Cost B
Cvariable labor
Where
=
[(Lvariablel x Riabor) X
F 1]
+ [(Lvariable2 x Riabor) X
F 2]
Lvariabe2
= Variable Labor Cost ($ per period)
= Variable Labor Time for Function 1 (hours)
= Variable Labor Time for Function 2 (hours)
Riabor
= Labor Rate ($/hour)
F1
= Failure Rate for Function 1 (failures per period)
= Failure Rate for Function 2 (failures per period)
Cvariable labor
Lvariablel
F2
(4.20)
Part Cost B
Cpars=(Pi x F 1)+(P
Where Cpa,
P
P2
F1
F2
2
x F 2)
=
=
=
=
=
(4.21)
Part Cost ($ per period)
Replacement Part Cost for Function 1 ($)
Replacement Part Cost for Function 2 ($)
Failure Rate for Function 1 (failures per period)
Failure Rate for Function 2 (failures per period)
Once again using the probability mathematics shown in Equation 4.11, the fixed cost equation for
modularity scheme B, can be simplified to the following,
Fixed Labor Cost B
(4.22)
Cfixed labor = (Lfixed x Riabor) x Fiu 2
The overall service cost equation for modularity scheme B is thus,
CA = [[(Lvariablel x Riabor) +
(PI )]
x
(Fl)] +
(4.23)
[[(Lvaiable2 X Riabor) + (P 2 )] X (F 2 )] + [(Lfixed x Riabor) X Fiu ]
2
As before, Equations 4.15 through 4.23 assume that product failures can be attributed to the
module that actually failed. Thus, it is assumed that only the failed module is replaced. The
equations also reflect the fact that modules are completely replaced when any failure occurs
within; failed constituent parts are not replaced separately.
By comparing Equations 4.15 and 4.22, it is clear that using the Periodic Maintenance Model,
fixed labor costs do differentiate between modularity schemes.
When using this model, fixed
labor costs do depend on the modularity scheme chosen. The use of the Periodic Maintenance
Model also has implications for module reliability. Random failure rates under this model are
assumed to be zero. However, the service time must be computed to coincide with the use limit,
46
t,,. For a module, the service time is the minimum service time of any single component. Thus,
the failure rate for the module as a whole, is the maximum failure rate among the components.
In comparing the Random Failure Model to the Periodic Maintenance Model, it can be seen that
for split modularity schemes, as shown with scheme B, the overall service cost equations are the
same, regardless of the service approach used. Equations 4.13 and 4.23 are identical. However,
the service cost equations for the integrated modularity scheme, as shown with scheme A, are
different. Equations 4.7 and 4.18 are not identical. Serviceability costs thus depend on both the
service approach and modularity scheme used.
4.4
Example: Xerox Document System
The ideas presented above were applied to a document system developed by the Xerox
Corporation and are demonstrated here.
To begin the process, a function structure of the
photoreceptor system from a photocopier is created, as shown in Figure 4.8. A drawing detailing
some of the physical components of the photoreceptor system can be found in Figure 4.9. After
creating the function structure, the modularity heuristics of dominant flow, branching flows, and
conversion-transmission, as discussed in Chapter 3, are applied. This results in various system
modularization schemes for the entire photoreceptor system. The modules developed are then
analyzed using the serviceability equations. As highlighted in Figure 4.8, two specific areas of
this photoreceptor system are examined, the charging module and the cleaning module. Different
architectures for each of these sub-systems are explored.
47
Energy
Information
Mixed Toner
and Carrier
Light
Density
Information
Toner
Toner Density
Information
Mghtu
Figure4.8:
F cSelectively
Chardsed PR
Dica
Light to
duPR
Discharged
Meangumre
Charge
on PR
PR
Density
7
Discharged PR
Develop
Toner to
Measure
Toner
Heat
PR
Untused
Toner
iclenerratee
age
Phre
I
Unused
Cleani PRToner
bla
Moving digital
blanket with toner
Brush
Light
to Digital(R
PR
S
Moving digital
blanket wtout
toner
Charge
on PR
igBlanket
Charged
Used Toner
Particles
I
I
s
Dirty I:
Blade II
\
Energy
ank-
Endgy I
I
Regulate
Electric
I
Cleaning
Directed
Energy
--
~~
Module
Energy
I
FR
:Tru
s
I --
Charge
~~Inform"tion
~
Stnd
re Old
Field
zzEnergyI
Digital blanket
without toner
ChargingmodulehtDevelope
Hand
StOred
Toner
Particles
Create
Electric
Field
EnIg
---
---
Charging
Module
Figure 4.8: Function structure of the photoreceptor system.
The charging module and cleaning module are indicated with dashed boxes.
Toner and Carrier
Charging module
Developer
Cleaning moduleDgtabant
Photoreceptor (PR)
Figure 4.9: Xerox digital document system."6
48
Rotate PR
Regulated
r---
MoeTransport
Digital
argeon PR
arge 0
mPR
Used
Toner
Porll
Uncholged
Charged PR
Masure
Ps
T
ares
Toner
Particles -
Used Ironer
Partices Dirty
Light
I Brush
Charged PR
Mn PR
Disturb
Noutrlize
Toner
---
--- PR
-
p
PR
-ATransfer
Blade
4.4.1
Charging Module
The charging module contains three functions, as shown in Figure 4.10. These functions are
grouped as a module due to the dominant flow of energy, which initially enters the system in the
"create electric field" function, and exits the system after the "regulate electric field" function.
Grouping these three functions according to the dominant flow heuristic allows all the energy
creation and modulation activities to be isolated in a single module.
Charging Module
Energy
--
Create
Electric
Field
Energy
Directed
Energy
Direct
Electric
Fild
Regulate
Electric
Field
IRegulated
Energy
Charge
Information
Figure 4.10: Functional diagram of the Charging Module.
Given this modularization scheme, representative service costs can be calculated using the
previous formulas. Table 4.1 shows the inputs and results of the serviceability equations using
the Random Failure Model.
For this model, Equation 4.7 is used to calculate service cost.
Table 4.2 shows the inputs and results of the same serviceability equations, this time using the
Periodic Maintenance Model for reliability. For this model, Equation 4.18 is used to calculate
service cost. In these analyses, and in all following analyses, a labor rate of $90 per hour is used.
Table 4.1: Service Cost Figures for the Charging Module using the Random Failure Model.
Fixed Variable Total
Cost
Part
Failure Rate
Labor
Labor Labor
Module
Charging Module
front arc shield
rear arc shield
spring
charge wire
front insulator block
rear insulator block
filter
charge shield
charge grid
Time
(hours)
1
Time
(hours)
0.17
spring clip
49
Cost
Cost
($)
($)
$105.00
$17.04
(failures/million ($/million
copies)
copies)
$ 7,482.27
61.31
Table 4.2: Service Cost Figures for the Charging Module using the Periodic Maintenance Model.
Fixed
Labor
Time
(hours)
1
Module
Charging Module
front arc shield
Variable
Labor
Time
(hours)
0.17
Total
Labor
Cost
Part
Cost
($)
($)
$17.04
$105.00
Cost
Failure Rate
(failures/million ($/million
copies)
copies)
$ 7,114.93
58.30
rear arc shield
spring
charge wire
front insulator block
rear insulator block
filter
charge shield
charge grid
spring clip
I Total Cost
I * 7,114.93
While this modularization scheme follows the dominant flow heuristic, maintenance costs are
relatively high. Grouping these three functions into a single module may not be the best
architecture from the viewpoint of serviceability. Other possible architectures are now explored.
Rather than incorporating all three functions into a single integrated module, an alternative
scheme is to maintain functional independence by separating each function into an individual
module. In the modularization shown in Figure 4.11, each function remains separate. This
ignores the dominant flow heuristic.
Energy
Create
--->Electric
Field
Regulation Module
Direction Module
Creation Module
energy
--
Direct
Electric
Fild
Directd
n
-
iField
Regulate
Electric
Regulated
Energy
---
Charge
Information
Figure 4.11: Functional diagram of the Creation, Direction, and Regulation Modules.
Calculations for this modularization are shown in Table 4.3. As demonstrated previously, the
type of reliability model used does not affect the outcome. The Random Failure Model and
Periodic Maintenance Model yield the same result. Their service cost equations are identical, as
shown in Equations 4.13 and 4.23. Table 4.3 shows that a lower maintenance cost results with
this split modularity scheme. In Table 4.3, the row entitled "Interactions" refers to the last term
50
in Equation 4.14. This term, as discussed previously, takes into account simultaneous failures.
Simultaneous failures are clearly rare, and thus do not have a significant impact on service cost.
Table 4.3: Service Cost Figures for the Creation, Direction, and Regulation Modules. These
results are true for both the Random Failure Model and the Periodic Maintenance Model.
Fixed Variable
Total
Labor
Labor
Labor
Part
Failure Rate
Cost
Cost
Cost (failures/million ($/million
Time
Time
copies)
copies)
($)
($)
(hours) (hours)
Module
376.52
$
3.01
$120.00
$5.09
0.33
1
Creation Module
front arc shield
rear arc shield
spring
charge wire
front insulator block
rear insulator block
$
0.58
0.005
$6.44
$110.00
1
0.22
Direction Module
filter
charge shield
$ 6,442.73
58.30
$5.51
$105.00
1
0.17
Regulation Module
charge grid
spring clip
$
(0.00)
-1.76E-10
0
$ 90.00
0
1
Interactions
Total Cost
$ 6,819.83
The modularization scheme shown in Figure 4.11 has significantly less associated maintenance
costs. The first modularization scheme combined relatively unreliable components, namely the
charge grid and spring clip, with other more reliable components. This meant that every time one
of these unreliable components failed and was replaced, many reliable components were also
replaced.
By modularizing based on serviceability, highly unreliable components can be
separated, and thus replaced separately.
It can be argued that in the first modularization scheme, failure of the module does not
necessarily mean that the entire module must be replaced.
Instead, as discussed before in a
general sense, the module could be disassembled, and only the unreliable components within the
module replaced, such as the charge grid and spring clip. However, at Xerox, and at many other
companies, this is usually only done with high cost parts. Such an option could be explored.
Given the results from the previous two modularization schemes, yet a third modularization might
be considered.
This
modularization,
shown in Figure 4.12, features two
modules, a
creation/direction module and a regulation module. As the integrated modularity equations are
51
used to calculate the service cost figures for the creation/direction module, the service cost results
differ depending on the service model used for that calculation. Thus, calculations for the
modularization shown in Figure 4.12, using the Random Failure Model, appear in Table 4.4.
Calculations for this same modularization using the Periodic Maintenance Model are shown in
Table 4.5. Once again, the row entitled "Interactions" accounts for simultaneous failures.
Regulation Module
Creation/Direction Module
Create
---4Electric
Field
Direct
Electric
Field
Energy
Energy
Drectqd
Energy
Regulate
---
Electric
Fild
Regulated
Energy
Charge
Information
Figure 4.12: Functional diagram of the Creation/Direction and Regulation Modules
Table 4.4: Service Cost Figures for the Creation/Direction and
Regulation Modules using the Random Failure Model.
Module
Creation/Direction Module
front arc shield
rear arc shield
spring
charge wire
front insulator block
rear insulator block
filter
Fixed Variable Total
Labor
Labor
Labor
Cost
Time
Time
($)
(hours) (hours)
$120.00
0.33
1
charge shield____
Cost
Failure Rate
(failures/million ($/million
copies)
copies)
($)
$ 396.56
3.02
$11.53
Part
Cost
Regulation Module
charge grid
1
0.17
$105.00
$5.51
interactions
1
0
$ 90.00
0
spring clip _
52
_____
_______
____
_________
58.30
-1.76E-10
Total Cost
$ 6,442.73
$
(0.00)
$ 6,839.29
Table 4.5: Service Cost Figures for the Creation/Direction and
Regulation Modules using the Periodic Maintenance Model.
Fixed Variable
Total
Labor
Labor
Labor
Part
Failure Rate
Time
Time
Cost
Cost (failures/million
copies)
($)
($)
(hours) (hours)
Module
Creation/Direction Module
1
0.33
$120.00 $11.53
3.01
front arc shield
rear arc shield
spring
charge wire
front insulator block
rear insulator block
filter
charge shield
58.30
$5.51
0.17
$105.00
1
Regulation Module
charge grid
spring clip
0
-1.75E-10
$ 90.00
0
1
interactions
Total Cost
Cost
($/million
copies)
$
395.91
$ 6,442.73
I
(0.00)
$
$ 6,838.63
This modularity scheme partially preserves the dominant flow heuristic, yet isolates unreliable
components to meet serviceability requirements.
By partitioning the product in this way, a
compromise between flow heuristics and serviceability needs can be reached. The service cost
associated with this modularity is only slightly higher than that of the creation, direction, and
regulation modules.
Further, this scheme is better for other factors, such as assembly.
The
bundling of two functions into a single module reduces the part count for final assembly.
It should also be noted that there is little difference in total cost between the Random Failure
Model and the Periodic Maintenance Model. Given the high reliabilities of the components in
question, the union of the failure rates, FIu2 , used in the Random Failure Model (Equation 4.7), is
not significantly different from the highest failure rate, Fmax (1,2), used in the Periodic Maintenance
Model (Equation 4.18). For example, Table 4.1, which uses the Random Failure Model, features
a failure rate of 61.31 failures per million copies for the Charging Module. This is obtained by
using the union of the failure rates of the constituent modules, namely the Creation Module,
Direction Module, and Regulation Module.
Table 4.2, which uses the Periodic Maintenance
Model, features a failure rate of 58.30 failures per million copies for the Charging Module. This
is obtained by taking the failure rate of the least reliable component of this module, namely the
Regulation Module. The results from these two reliability models are not significantly different,
thereby leading to the small cost difference of only $367.34, approximately 5% of the total
service cost. Tables 4.4 and 4.5 show an even smaller difference, with a total cost difference of
53
only $0.66. Given these small differences between the two methods, and given the actual nature
of the Xerox service and maintenance methods, only the Random Failure Method is examined in
the next example.
4.4.2 Cleaning Module
Analyzing a second area of the photoreceptor function structure reveals similar results.
Figure 4.13 shows a cleaning module from the photoreceptor system. These functions are
grouped as a module due to the dominant flow of used toner, which enters through the "disturb
toner particles" function and exits through the "transport toner particles" function. Given this
modularization scheme, service costs can be calculated. Calculations are completed using the
Random Failure Model for reliability, and are shown in Table 4.6.
Blade
Brush
Cleaning Module
Uncharged
Toner
ne"La
Photoreceptor
N-
Toner
Disturb
Parbclea-
Tie
M eParticles
Toner
(o
Used
Remove
Par
Particles
Used
Transport
Toner
Particles
ate
os
Poo:cpo
Variabl
ParFixeds
bPhotoreceptor
Totalr
Figure 4.13: Functional diagram of the Cleaning Module.
$2355
36 Failure
231 the Random
$100
Mdue
Model.
Module using
Cleaning
4.6:
Service Cost Figures for the C0.67
TableClenig
brushBad
Module
Cleaning Module
brush bearing
Fixed
Variable
Total
Labor
Time
(hours)
Labor
Time
(hours)
Labor
Cost
($
1
0.67
Part
Cost
($
$150.00 $23.17
Failure Rate
(failures/million
copies)
Cost
($/million
copies)
13.66
$ 2,365.50
brush
brush bearing
brush gear
ground spring
cleaner blade
auger gear
auger bearing
auger
auger pipe
Total Cost
54
$ 2,365.50
Grouping these ten components into a single module results in both a high part cost and a high
overall service cost. While this modularization follows the heuristic of dominant flow, perhaps
by considering serviceability concerns, a better modularity can be determined.
Taking serviceability into account, a different modularity scheme becomes attractive. In the
modularization shown in Figure 4.14, each function remains separate, as compared to the
integrated modularity scheme in Figure 4.13. While this ignores the dominant flow heuristic, the
modules that are formed are effective from the viewpoint of product serviceability. Service cost
calculations using the Random Failure Model are shown in Table 4.7.
Disturb Module
Remove Module
Brush
Blade
Uncharged
Used
Toner IrOnorU,
Transport Module
........
-- Used
Used
............
Particles
DaRe
Pane
Transport
Toner
Tonercl
*
Toe
PhotorceptorPhotoreceptor
Photoreceptor
Dt
Figure 4.14: Functional diagram of the Disturb, Remove, and Transport Modules.
Table 4.7: Service Cost Figures for the Disturb, Remove, and Transport Modules using the
Random Failure Model.
Module
Disturb Module
Fixed
Variable
Total
Labor
Time
Labor
Time
Labor
Cost
(hours)
(hours)
I
1
Cost
Part
Cost
Failure Rate
(failures/million
($)
($)
copies)
$180.00
$ 13.73
0.36
($/million
copies)
69.74
$
13.29
$ 2,056.49
0.01
$
1.85
-4.9209E-12 $
(0.00)
brush bearing
brush
brush bearing
brush gear
ground spring____
__
_
_
__
_
_
Remove Module
1
0.67
Transport Module
1
1
$150.00 $ 4.74
Model.
$180.00 $ 4.70
1
0
$ 90.00
cleaner blade
_____
_______
____
auger gear
auger bearing
auger
auger pipe
interactions
0
Total Cost
55
$ 2,128.08
Once again, the split modularity scheme has lower associated service costs. Grouping unreliable
components such as the cleaner blade together with much more reliable parts results in higher
overall service costs. By separating expensive reliable components, such as those making up the
disturb module, from unreliable components, such as the cleaner blade, savings in maintenance
costs can be realized.
As before, various redesigns could be completed to reduce part cost and improve part reliability.
Reducing the part cost associated with the disturb module could make the single module plan
more feasible.
Improving the cleaner blade reliability could also make the single module plan
more attractive.
4.5
Discussion
It is important to point out another method to address the issue of labor cost, that being customer
repair.
Making modules that are simple enough for customers to repair or replace can greatly
reduce overall serviceability costs, as the labor rate would be $0 per hour. However, customers
may expect service agents to make repairs, and thus be dissatisfied that they must repair their own
system.
While such a strategy may reduce short-term service costs, it may adversely affect
long-term customer satisfaction and customer repurchase intent.
On the other hand, some
customers will like the freedom and ease of not having to rely on a service agent. The costs and
benefits related to the concept of service must be weighted; specific schemes may not be
appropriate for all customers and all situations.
There are also possible design approaches that should be considered. For example, while fixed
service costs are the same for the Random Failure Model, variable service costs can be made
different depending upon the modularization.
Combining difficult to handle sub-systems into
more easily handled modules makes for reduced variable service times and thus lower overall
serviceability costs.
Part costs can also be reduced to lower overall service cost. When one
monolithic module is not effective given the components used in a design concept, perhaps with
more inexpensive elements the single module would be successful. Through redesign, the cost of
the module may be reduced, and perhaps in such a way as to meet targeted reliability.
Serviceability costs should be considered when making modularity decisions. While heuristic
methods to determine modularity are useful to examine possible modularity schemes, other
56
criteria, including lifecycle concerns such as service costs, can often have a large impact on the
feasibility of modules.
Understanding service cost concerns when modularizing products can
result in products that can continue to save time and money throughout their product life.
The method presented above presents a means of calculating service cost differences between
different modularization schemes. This method provides insight into the effect of service costs
on product architecture decisions. This is, of course, only one of the many evaluation criteria that
must be considered when making modularity decisions. Other evaluation criteria are presented in
the following chapters. The overall decision on how to modularize a product depends on many
different considerations, not just those of serviceability.
57
58
5
Technology Change Rate
In every complex system, different components in the system can evolve at different rates.
Technological improvements often occur on different time cycles, such that while one part of a
system may be outdated in a couple years, another part may be outdated in a couple months. For
example, consider the case of a desktop personal computer.
Some of the components in this
system change so rapidly, people sometimes joke that the minute one buys a computer, it is
already outdated. However, looking more closely at each of the components that comprise this
system, it becomes clear that each has a very different technology change rate.
While Intel
releases a new processor more than once a year, Microsoft releases a new operating system every
couple of years. The physical computer tower, while changing aesthetically, is approximately the
same today as it was five years ago. The technology change rate of each of these elements is
drastically different.
While the physical tower changes very slowly, the operating system
changes faster, and the microprocessor changes even faster.
The architecture of a typical personal computer allows the user to upgrade individual pieces of
the system independently from one another. For example, consider the case of computer hard
drives. In 1996, hard drives cost approximately $100 per gigabyte (GB). A 5 GB hard-drive, a
large drive for the time, would cost a consumer approximately $500. Five years later, in 2001,
given new technologies and fierce competition in the hard drive market, it is not uncommon to
see hard drives as large as 40 GB selling for as little as $160.
This works out to a mere $4
per GB. The technology of computer hard drives is clearly changing fairly rapidly, providing
much more value to the customer. Today, if a computer user runs out of file storage space, he can
simply upgrade the hard drive, changing to a hard drive with a greater storage capacity. In doing
so, the computer user does not need to sacrifice the rest of his system.
The processor,
motherboard, operating system, computer case, and numerous other components are unaffected
by his decision to upgrade storage space. This capability allows customers to keep pace with
technological changes, without constantly sacrificing previous investments. The ability to do this
should not be underestimated.
Numerous products are not capable of being upgraded; if a
customer desires a new technology, often a completely new product must be purchased, even
though perhaps only one small part of the product is actually improved.
59
Such a scenario also occurs in product development. Much like the customer who would like to
simply upgrade one component without sacrificing the rest of his system, product developers
would often like to upgrade one part of a product without having to redesign the entire product.
In order to do this successfully, product developers must be able to take a long-term view of
product development.
In designing the current product, product developers must select an
architecture that enables them to later upgrade components as technologies evolve. In doing so,
they allow new technologies to be more seamlessly integrated into new products. No longer do
technological
improvements need to signal drastic redesigns.
This chapter presents a
methodology for incorporating technology change rate into product architecture decisions. After
explaining the methodology, examples based on products from Black and Decker and the Xerox
Corporation are presented.
5.1
Related Work
New technologies clearly play a major, if not dominant, role in driving product change.' Products
are constantly evolving, with each new product striving to provide added customer value, usually
through the incorporation of new technologies.
With this emphasis on continually improving
products, much work has been done to characterize the rate at which technologies evolve. The
field of technology forecasting tries to predict what new technologies will occur, when they will
occur, and how they will affect the marketplace.
Considerable work has been done to characterize the technology life cycle.
Perhaps the best
known is that of the s-curve, in which new technologies appearing in the marketplace follow an
"s"-shaped evolution curve. In an s-curve, technological improvements, as seen in the market,
start slowly, then pass through a period of rapid improvement, before finally topping out.
S-curves serve to accurately characterize the market behavior of many new technologies.2 Other
approaches to characterizing technology life cycles have also been presented.
Anderson and
Tushman developed a model in which technologies begin with a technological discontinuity,
where a new scientific advance or technological insight renders existing technologies obsolete.3
The new technology then enters a period of ferment, during which the technology is researched
and prepared for market. Following this, designs enter a period of incremental change until the
next technological discontinuity occurs.
60
Recently, much work has been done examining how new technologies affect the marketplace.
Christensen presents the idea of disruptive technologies, in which new technologies have the
ability to completely alter the marketplace and market landscape.! A disruptive technology often
begins by supplying products for a separate market niche.
Over time, and with improved
technologies, that market niche grows to eventually create a new market, often wiping out some
existing markets.
Such a scenario may occur with the introduction of digital photography.
Initially targeted towards a highly technical, gadget-oriented customer, digital photography had
limited market appeal. However, with technological improvements and cost reductions in both
digital photography and printing technology, the market possibilities are now very encouraging.
Digital photography may be the disruptive technology that replaces the market for traditional
silver halide film.5
Another use for technology forecasting is in making technology roadmaps.
Technology
roadmaps provide a means to show how future technologies will be introduced into upcoming
product generations.
Understanding which technologies will be used in which products is an
important part of product plannning.
Such a roadmap can also serve to help bridge the gap
between technology development and product development.6
Technology roadmaps have been
used by Motorola, Philips, Xerox, and many other companies involved in high-technology
industries.
While technology forecasting is well-researched, the link between technology change and product
architecture is less well-defined. Methods exist to help design for product variety, although such
methods usually involve variety in the market at one point in time, not over a period of time, as is
the case with evolving technologies.
Work by Ericsson and Erixon list technology evolution as
one of many drivers of product modularity.9
While the concept of technology evolution is
described, their work does not present a detailed method for deriving technology change rates and
incorporating them into product architecture decisions.
61
5.2
Approach
The general methodology to incorporate technology change rates into product architecture
decisions is shown in Figure 5.1.
Create a function structure for the
given product.
Determine technology change rate
values for each function.
Determine candidate modularizations
using flow heuristics.
Examine technology change rate values
for each candidate modularization.
Evaluate alternative architectures.
Figure 5.1: General methodology for incorporating technology
change rate into product architecture decisions.
The method begins with a functional analysis of the product. As before, a function structure for
the product should first be created. As described in Chapter 3, this function structure should
contain all product functions, as well as the material, energy, and information flows between the
functions.
Once a function structure is created for a product, each individual function should be analyzed to
determine its technology change rate. This technology change rate is usually best expressed as a
single number that represents the amount of time until a new technology is ready for market.
Coming up with these numbers is not a trivial task; it requires careful examination of the
technology landscape, both internal and external to the company. By understanding the rate of
technology change for each item in the function structure, technology change rate can be
incorporated into the product architecting process.
62
Candidate product architectures are first created by applying partitioning heuristics to the product
function structure.
These flow-based heuristics can identify multiple modularity schemes that
maintain physical consistency. However, the modules identified are also those that incorporate
the maximal set of functions into a module. These maximal modules are often not ideal, as other
factors besides physical consistency play into modularity decisions. Therefore, these modules
should be further refined to better address other modularity concerns.
The modularity schemes identified in step three of this method should now be examined by
looking at technology change rates.
With technology change rates for each function, product
modules can now be identified by simply grouping common values. Functions with common
values would make effective modules from the standpoint of technology change.
Now that different product architectures have been created, the product development team is left
to evaluate the various options.
In doing so, product developers must consider the many
trade-offs involved in selecting a suitable product architecture.
The five steps presented here
represent a methodology for architecting a product while taking technology change rate into
account.
5.3
Technology Change Rate Values
In developing an architecture that takes into account technology change rate, perhaps the most
critical step is accurately determining technology change rate values for each function. This is a
difficult task, as many factors play a role in the development of new technologies. The following
sections address this issue, providing a series of questions that, when carefully considered, should
help product developers to better estimate the rate of technology change.
5.3.1
When Will the Technology Change?
In analyzing the technology change rate of a function, product developers must address the
primary question of, "When will the technology change?"
Although this question may seem
quite straightforward, it is in reality a very difficult question to answer.
This vaguely posed
question must be greatly clarified before it can be of use in making product architecture decisions.
As most technologies evolve gradually over time, it is sometimes difficult to determine what
constitutes a "change."
In recognizing a "change," product developers must attempt to assign a
63
discrete value to a continuous process.
In order to do this, product developers must set a
threshold value for technological improvement. Any improvements beyond this value constitute
a "change." Given this need for a threshold value, where should such a value be set?
From a company's standpoint, technology changes are of little use unless they either improve
customer satisfaction or reduce internal cost.
Companies can use technology to improve
customer satisfaction in various ways. Product performance can be improved while leaving the
price paid by the customer unchanged, thereby providing the customer with additional value.
Companies can also use technology to improve performance while also raising the price to the
customer. In this case, companies must be sure that in the eyes of the customer, the improvement
in product capability is sufficient to warrant the increased price.
10
New technologies can also be
used not to improve product quality, but rather to lower product cost to the customer or lower
internal cost to the company.
In each of these cases, there is a cost involved in implementing the new technology.
technology can be introduced without some investment of resources.
No
Often times new
technologies require changes in design, manufacturing, supply chain, marketing, and other areas.
While the methodology presented here strives to reduce the cost associated with such changes, it
is still necessary for product developers to understand the overall cost of such changes.
By
understanding this, and by understanding the benefits of making such a change, product
development teams can decide if introducing such new technologies is appropriate.
In many
cases, while new technologies may exist, they do not provide the company with a real advantage.
The cost of implementing such a technology would outweigh possible financial and strategic
benefits. Therefore, it is important for product development teams to know what effect a new
technology will have on the bottom line of the company. Only those technologies that will have
an overall positive effect should be classified as a "change."
Once this threshold value of "change" is determined, product developers must determine how far
away they are from having such a "change" ready for the market.
While technologies can be
developed for limited trial use, the concern here is with when technologies will be ready for the
market. This means that issues such as production, supply chain, and others must be resolved.
Furthermore, the company must be capable of producing the new technology at the cost points
and quality levels necessary.
The time estimate for producing this level of technological
refinement should be used as the value for technology change rate.
64
This primary question of, "When will the technology change?" must be answered in order to
establish valid values for technology change rate. For each function, product developers must
determine how much time will pass before a new technology becomes ready for widespread
market use. Clearly, a great deal of team and individual judgement comes into play in assigning
these values. Product development teams must weigh the costs and benefits of new technologies
to both the customer and the company.
5.3.2
Secondary Questions
Numerous secondary questions can be asked to help product developers determine when
technologies will change. As many factors play a role in technology change, it is important for
product developers to understand the entire scope of the situation before determining a value.
The more accurately these values can be estimated, the more effective the product architecture
will be for future generations of the product.
To better predict technology change rate, product developers should consider the following
questions:
=
What is the current technology?
"
What technologies are being developed?
=
Where do the current and future technologies fit on a technology s-curve?
"
How fast have major technological improvements occurred in the past?
-
How is the rate of technological improvements changing?
"
What is driving the technological improvements?
"
Is the new technology one that is beneficial to the customer and/or company?
What is the current technology?
The first question is simply a means to understand the current state of the technology being
evaluated. The current technology can usually be thought of as the latest technology available to
the company, either internally or through external suppliers.
This technology should be
developed to the point that it is capable of being offered to the market at a price point that is
attractive to customers. In short, the current technology is the latest market-ready technology. In
most companies, the current technology will either be the technology currently on the market or a
technology that has been developed and refined since the last product release.
65
What technologies are being developed?
The technologies being developed can vary widely, with some naturally being closer to market
than others. In considering technologies under development, only those technologies that can
realistically be utilized by the company should be considered. For example, technologies being
developed in-house can certainly be incorporated into a future product. However, technologies
being developed by competitors, or perhaps by the government, will not necessarily be available
for use.
While numerous different organizations may be working to develop a specific
technology, not all of the organizations will produce results that can go to market. Government
agencies, while developing key technologies, may not release the technology to the public."
In
the case of competitors, it would not be uncommon for them to keep the technology to themselves
to gain a competitive advantage.
Given these obstacles, companies should consider only those
technologies that they will legitimately be able to utilize in the marketplace.
Where do the current andfuture technologiesfit on a technology s-curve?
New technologies can also be analyzed based on where they fit on the technology s-curve. As
mentioned previously, technology products often appear on the market in an s-curve, meaning
that a plot of one product metric versus time yields an "s"-shaped curve.
An ideal s-curve is
shown in Figure 5.2. In an s-curve, the start of the curve is marked by infrequent improvements
in technology. These initial product offerings fall at the low end of the technology spectrum. As
more companies begin to enter the marketplace, a period of rapid innovation occurs. Numerous
products are launched in an increasingly crowded marketplace.
After this period, the s-curve
begins to flatten out, as the rate of technological innovation slows and fewer products are
released. By this point on the s-curve, typically only a few mature companies remain in the
market.
66
1980
1975
1985
1990
1995
2000
2005
Product Release Date
Figure 5.2: An ideal s-curve for technological innovations.
Each point represents a product offering.
Understanding where a current technology fits on the s-curve can help product developers to
determine the rate of technology change. If it is determined that the technology in question is at
the start of its lifecycle, developers may predict an upcoming period of rapid innovation. If the
technology is already in this period of rapid evolution, developers may predict a slowing of
innovation.
If the technology is at a very advanced stage, the s-curve may be nearing its
technological limit.
Understanding these three general cases can help product developers to
determine the technology change rate of functions.
In the case of technology that is in an advanced stage, product developers must be aware of the
notion ofjumping s-curves. When an s-curve begins to plateau, technologies often jump to a new
s-curve. In this case, a disruptive technology is developed for which a new s-curve is created.
Disruptive technologies, as mentioned earlier, can often lead to large changes in the marketplace
and may affect more than simply one function. In the case where technological advances lead to
disruptive technologies, product developers must analyze what effect this new technology will
have on the product as a whole. It is likely that truly disruptive technologies will bring about
large changes in the marketplace and necessitate radical redesigns by product development teams.
67
How fast have major technological improvements occurred in the past?
Another way to estimate future technology change rate is to look at past innovation. While the
rate of technological improvement changes over time, as shown by the s-curve, past rates of
change can provide some information regarding future changes. Assuming that a company has
been working with some technology for a period of time, it should have a good understanding of
how the technology has evolved in the past. Based on this information, future technology change
rates may be estimated.
How is the rate of technologicalimprovements changing?
While past technology change rates can provide some insight into future technology change rates,
product developers must also understand how this rate is changing. This technology change rate
may be changing due to both internal and external factors. For example, a company may decide
that a certain technology represents a key strategic area, and therefore focus a large amount of
research and development funds on developing that technology. In this case, such an infusion of
resources may lead to an increased rate of technology change. Technology change rates may also
change due to external factors, including development by others, or even through changing
government regulations. For example, stricter government emissions regulations on automobiles
have almost certainly increased the technology change rate for the electric car industry.
What is driving the technologicalimprovements?
In understanding technology change rate, product developers should understand what is driving
the technological improvements. Once again, this can be attributed to both internal and external
forces.
Internally, technology change may be driven by the company strategy, or perhaps by
certain expertise available within the company.
External factors, including development by
competitors and by the government, can also drive technological improvements. In determining
the drivers of technology change rate, it is important to look outside of the specific industry in
which the company is operating. Frequently, technologies are driven by specific industries, such
as the aerospace and defense industries. Only over time do these technological improvements
become distributed across a broader range of industries and applications.
Is the new technology one that is beneficial to the customer and/or company?
Lastly, it should be verified that the new technology is actually beneficial to either the customer
or the company.
As discussed previously, technological improvements should only be
68
implemented if the benefits outweigh the costs. This last question simply serves as a check to
ensure that the new technology provides real benefits.
It addresses the fact that while new
technologies may exist, they may be of no use to the customer or company.
If the new
technology does not benefit the customer or the company, then the technology being considered
should not be implemented.
Instead, perhaps more development is necessary before such a
technology will positively affect the marketplace.
This list of questions provides a solid starting point from which to examine technology change
rate. While some of the questions may seem redundant, the goal is not to find exact answers for
each, but merely to help product developers come up with a single value for rate of technology
change.
In doing so, this list helps to illuminate some of the information that should be
considered. Once a technology change rate value has been determined for each function, product
architecture decisions can then be made.
It should be noted that while technology change rates are assigned to functions, coming up with
these values often requires analyzing specific solutions, not general functions.
Product
developers must be sure to look outside the scope of current solutions to evaluate technological
breakthroughs that may be on the horizon. The possibility always exists that an entirely new
technology could replace the existing solutions. Because of this, product developers should be
aware of disruptive technologies that may completely alter the market landscape.
No matter how rigorously technology change rate values are derived, they are still merely
predictions of the future.
It is impossible to predict such values with absolute certainty.
Therefore, while elaborate methods may be used to try to more accurately determine values for
technology change rate, the methodology presented in this chapter should provide useful product
architecture suggestions, even with less accurate values. This product architecting tool, while
meant to require a careful consideration of technology change rate, is not meant to require
rigorous predictive models.
Clearly, if such models are available, they should be utilized.
However, in the absence of such models, careful deliberations should suffice.
A further complication in predicting technology change rates is that such a process is very
susceptible to individual biases. Researchers and developers may feel as if new technologies are
only months away from viability, when in fact the technologies may be years away. It is common
for people to underestimate the amount of time and resources involved in developing new
69
technologies. This is well evidenced in numerous companies involved in product development.
It is a rare project that comes in on-time and on-budget; most projects seem to exceed both cost
and time predictions.
Up to this point, it has been suggested that technology change rate values should be time
estimates of when a new technology will become available. For example, functions should be
labeled with technology change rate values such as "6 months," "1 year," or "5 years." However,
there exists an alternative approach that allows more flexibility in assessing technology change
rates. Instead of coming up with time estimates, product developers can instead come up with
generation-based estimates.
A generation-based estimate would require product developers to
predict how many product generations will pass before a new technology is feasible. Functions
would thus be labeled with values such as "1 generation" or "3 generations." In many cases, such
a generation-based estimate is easier to determine than an exact time estimate.
As an example, consider a company that, on average, releases a new generation of products every
three years. In looking at technology change rate and its effect on product architecture, product
developers do not need to know exactly when a new technology will become available. Instead,
they simply need to know if that technology will be available in three years or in six years. This
lower-resolution requirement provides product developers with more leeway in predicting values
for technology change rate.
Clearly, this method is more useful when product development
cycles are long. For industries with rapid product development cycles, accurate prediction of
technology change rates is still necessary.
5.3.3
Using Technology Change Rate Values
Once technology change rates have been established for each function, and flow-based heuristics
have been applied to identify modules, the modularity scheme should be examined. If functions
in a module all have approximately the same technology change rate, those functions make sense
as a module. However, if the functions have drastically different technology change rates, the
functions may need to be separated.
By splitting these functions into separate modules, the
architecture can better accommodate technology upgrades.
70
The governing equations behind such modularity decisions are as follows,
(5.1)
Tmodue = min (T, T2 , ... Tn)
= Technology Change Rate for a Module
= Technology Change Rate for a Single Function, i, where i is
Contained in the Module
= Total Number of Functions in the Module
Where Tmoduie
Ti
n
For a modularity scheme such as the one shown in Figure 5.3, the technology change rate for
Module A is simply the minimum of the technology change rates of Function 1 and Function 2.
Module A
Function 2
iFunction 1 ----
Figure 5.3: Module A with two functions, 1 and 2.
The technology change rate of Module A is thus,
TmoduleA =min
Where
TmoduleA
T,
T2
(5.2)
(TI, T2 )
= Technology Change Rate for Module A
= Technology Change Rate for Function 1
= Technology Change Rate for Function 2
These equations are now demonstrated on examples from Black and Decker and the Xerox
Corporation.
5.4
Example: Black and Decker Screwdriver
The ideas presented above are first applied to a cordless rechargeable screwdriver developed by
Black and Decker. The screwdriver is shown in Figure 5.4. This is the same Black and Decker
cordless screwdriver examined in Chapter 3.
Figure 5.4: Black and Decker cordless screwdriver.
71
As the first step in this methodology, a function structure of the product is created. This function
structure is shown in Figure 5.5. After creating the function structure, the heuristics of dominant
flow, branching flow, and conversion-transmission are applied to define candidate modularization
schemes. These modules are then analyzed from the viewpoint of technology change rate. The
application of this methodology is now shown as it applies to the power module of the Black and
Decker screwdriver. This module is highlighted in Figure 5.5.
Power Module
r ------------------I
Electricity
Transmit
Electricity
Electricit
Store
Electricity
1
I
Thumb
Noisectri
EPower
Heat
Thumb
Signal
to Motion
Screw
qTorque
NMse
Transform
(T,ns
Prvent
Input
Hot Turning
Turn
Transmit
~~RotationPoeScwSrw
Hand
STorque
Hand
Hand
Permit Bit
Positioning
P
Bit Position
Reaction Force
Hand
Hand
Force
Bit
Register
Bit
Bit
Secure
Bit
Bit
Un-lock
Bit
+ Bit Secure
Bit
Release
Bit
Bit
Force into
opposite hand
Figure 5.5: Function structure of the Black and Decker cordless screwdriver.
The power module is indicated with a dashed box.
5.4.1
Power Module
The power module, as shown in Figure 5.6, contains two functions. These functions are grouped
as a module due to the dominant flow of electricity, which passes through both functions. In
grouping these two functions together, all functions that deal exclusively with electricity are
isolated as a single module.
72
Power Module
Electricity
Store
Electricity
Electricity
Transmit
Electricity
Electricity
Figure 5.6: Functional diagram of the Power Module.
Given this modularization scheme, it can now be analyzed from the viewpoint of technology
change rate. In this example, exact technology change rates are estimated. However, generationbased estimates could have equivalently been used. Each function is individually analyzed to
determine its technology change rate. To accurately arrive at the necessary values, the questions
presented earlier are carefully considered.
The first function in the power module is the "store electricity" function.
This function is
currently being completed through the use of a Nickel Cadmium rechargeable battery, a
technology that has been on the market for quite some time. At this point, Nickel Cadmium
battery technology has clearly reached the mature region of its technology s-curve, as few new
innovations have been introduced in recent years.
technological limit.
The technology has definitely neared its
Currently, numerous new technologies are being developed.
The most
market-ready of these new technologies is that of the Lithium Ion rechargeable battery.
The
Lithium Ion battery is on a different s-curve from that of the Nickel Cadmium battery. While also
at an advanced state on its technology s-curve, Lithium Ion technology is still undergoing slight
improvements. It has not yet reached its technological limit.
In the past, battery technologies have seen a major improvement on the average of every three
years.
However, with the automobile industry's push to develop electric and hybrid cars,
research into new battery technologies has increased considerably.
Given this, it would not be
unreasonable to predict that the rate of technological improvements will also increase. However,
while such innovations are being developed, Black and Decker may not be able to utilize many of
these improvements. Some of the most useful of these new battery technologies may be patented
or otherwise protected by the automobile companies.
Also, the technology for large batteries,
such as those used in the automotive industry, may not scale down to smaller batteries, such as
those used in Black and Decker power tools. Given this information, product developers may
predict that the rate of technological improvement in the battery industry will increase only
slightly, perhaps to a figure on the order of two years.
73
The final issue that needs to be addressed involves the usefulness of new technologies to the
customer or company. For this product, battery life is a major concern for customers. Extended
battery life would certainly be of use to virtually all customers. Such an improvement could help
to differentiate Black and Decker in the crowded power tool market. Given this, improving
technologies on the time cycle of two years, or faster, is certainly justified.
The second function in the power module is the "transmit electricity" function. This function is
currently being completed through short lengths of plastic-coated, stranded copper wire and small
metal contacts.
Such wiring and contacts have been available for decades.
While minor
improvements may still be possible, this is a technology that has definitely reached a very mature
state in its technology s-curve. The technology has probably hit its technological limit. New
material technologies may be under development, perhaps in an attempt to improve conductivity
or improve insulation. However, while such research is probably taking place, it is most likely
not a high priority.
In the recent past, wire and contact technology has progressed quite slowly. Few major technical
improvements have occurred in the past decade, and there exists little reason to believe that this
rate of technological improvement will quicken. Perhaps specific industries, such as the defense
industry, may be researching new technologies in this field.
However, these technological
innovations may be years away from introduction to the public.
Perhaps most importantly in the analysis of the "transmit electricity" function, is the question
regarding benefit to the customer or company. The current wire and contact technology performs
well; it is not an area of consumer complaint. An improvement in how electricity is transmitted
would most likely go unnoticed by the customer. From the company's perspective, the current
technology is neither expensive nor difficult to produce. Given this, there is little to suggest that
this technology should be improved. Taking all of this into account, the technology change rate
for this function is quite slow, perhaps on the order of ten years.
Now that technology change rates have been established for each function in the module, the
modularity scheme should be re-examined. Given the drastically different technology change
rates of the power module, it may be best to separate the functions. By splitting up the "store
electricity" and "transmit electricity" functions into separate modules, the architecture can better
74
accommodate technology upgrades. The new modularity scheme for the power module is shown
in Figure 5.7. Technology change rate values are indicated for each function.
10 years
2 years
E ecity
Electricit
E lectrcity
Electrct
Electr ity
Figure 5.7: New modularity scheme for the Power Module.
Technology change rate values are indicated for each function.
Interestingly, the latest cordless screwdriver produced by Black and Decker isolates the "store
electricity" function as its own module. As part of the Black and Decker VersaPak line of
products, the cordless screwdriver, as shown in Figure 5.8, is powered by a removable,
rechargeable battery, as shown in Figure 5.9. In the VersaPak line of products, the battery is no
longer an integrated part of the system, but instead a module that can be separately attached to,
and removed from, the various power tools. One reason why such a product architecture was
selected becomes clear upon looking at a function structure with technology change rate values.
The function structure shown in Figure 5.10 shows the technology change rate for each function.
Clearly, the "store electricity" function has a much faster technology change rate than the rest of
the system. By isolating this function, product developers allow the product to be easily updated
when new electricity-storage technologies become available. Much like the example with the
personal computer, technology enhancements to this line of power tools can now be made
without sacrificing the other components in the system.
Figure 5.8: Black and Decker VersaPak cordless screwdriver.
Figure 5.9: Black and Decker VersaPak removable, rechargeable, battery.
75
r
-
r
,I
2years 1
-
Transmit
Electricity
Store
Electricity
Electricity
Nose
5 years i
,----
10years I
r-------
I
r --
,-
Noise, I
ConvertI
Het-+-Electricity
1nu
Siu~lt
to Motion
--
5 years---- |
------
-
5 years
5 years
Pvent
Rtaio
Rotation
Transform
Noise
Thumb
iga
Torqu
S
Thumbm
--
(T,
1 o
10 years
Screw
'
---
6 ears |
5 years
Transmit
Turn
Power
Screw
I
Hot Turning
Screw
Hand
Positioning
Reaction Force
1 0yars
HLn
Hand
Hand
Force
----
---
-
- -- - - - - - - - - -
Bit
Register
Biti
Bit
- - ---- -
ears
5years
Fyears
Bit
Secure
Bit
Un-lock
Bit
/
Bit
- - - - - - - - -1
5 years I
Bit
L Bitcu-re------------
Release
Bit
--
--
Bit
Force into
opposite hand
Figure 5.10: Function structure of the Black and Decker cordless screwdriver. Technology
change rate values are shown for each function. The indicated modules suggest a possible
modularity scheme that is effective from the standpoint of technology change rate.
5.5
Example: Xerox Document System
The methodology presented above can also be applied to a document system developed by the
Xerox Corporation. Once again, to begin the process, a function structure of the photoreceptor
system from a photocopier is created, as shown in Figure 5.11.
After creating the function
structure, modularity heuristics are applied, as discussed in Chapter 3. This results in the creation
of various modularization schemes. Each function is then analyzed to determine technology
change rates. The candidate modules are then re-examined from the standpoint of technology
change rate. In this example, the charging module of the photoreceptor system, as highlighted in
Figure 5.11, is studied."
76
Energy
Mixed Toner
and CarrierInomtnLih
PR
e
Image
Generate
Heat
Toner Density
Information
Toner Den
PnR m ation
Measu
Toner
Den 't
Charge
DevO
NZ
Selectively
Discharged
DToner to
PR
Light
ParR lMeasure
on PR
D
Selectively
irect
Parea
PtCharge
Light to
PR
Charged PR
Tor
PR
Moving digital
Unused
Toner blanket with toner
Ueoe
MoigDigtl
-d
Neutralize
Charge
on PR
Digital
toBlanket
S
Uncharged
Used Toner
Particles
ta
EnC
Particles
R
-yPR
Used
Toner
Dirty
Pass
toMeayurstm
Charge to
hr
Parcles
Dal
ty
e
on PR
egulated
I
I
Store Old
TonerII
Charge
e.
Information
I
Energy
create
I
Electric
DigtalblakI
Hand
Field
Rotate PR
Energy
E
Direct
Electric
without toner
Charge
- in-E
Regulate
ry
Hand
Charged PR
Charged PR
Clean PR
r
ofmthe
-yParticles
Charged
Blade
PR
Disturb
Toner
Used Toner
irect
T
Brush
PR
PR
Transfer Toner 5
Moving digital
blanket without
Tone
Uaede
Light
Stored
PartiFcled
IL-_-_
Charging
.."q'9
' Module
Figure 5.11: Function structure of the pho-1toreceptor system.
The charging module is indicated with a dashed box.
Crae
Enry
5.5.1
Eery
O~ve
Drct
Energyrah
Rlaegu lae Dregulated
Energ
Charging Module
The charging module, as shown in Figure 5.12, contains three functions. These functions are
grouped as a module due to the dominant flow of energy, which passes through all three
functions. Grouping these three functions together allows all the energy creation and modulation
activities to be isolated in a single module.
Charging Module
Create
Energy
----
Energy
Electric
Field
Direct
Electric
Fild
Directe
Energy
Regulate
Electric
Fild
Regulated
Energy
---
Charge
Information
Figure 5.12: Functional diagram of the Charging Module.
77
This modularization scheme can now be analyzed from the viewpoint of technology change rate.
Given Xerox's longer product development cycles, generation-based estimates of technology
change rates are used in this example. While generation-based estimates allow greater flexibility
in predictions of technology change rate, actual time estimates could have equivalently been used.
As before, each function is individually analyzed to determine a technology change rate value.
To accurately arrive at these values, the questions proposed earlier are again considered for each
function.
The first function in the charging module is the "create electric field" function. The electric field
is currently created by passing high voltage through a wire. This method has been refined over
multiple product generations and has now reached a relatively mature stage in its development.
While this technology has certainly neared the end of its s-curve, small technology improvements
can still be made. New technologies are currently being developed that provide a noticeable
performance improvement over the existing charging methods.
These new technologies are
capable of producing a more uniform electric field, which is an important advantage. While these
new technologies are also fairly well developed, they are definitely not as well evolved as the
current technology. On the technology s-curve, these new technologies have considerable room
for future improvements.
In the past, new methods for electric field creation have been developed every couple years.
Given the importance of this function, a fair amount of internal resources are committed to new
research in this area.
This current rate of technology improvement will most likely continue
unchanged as there is little to suggest that this will be an area of increased attention and
resources. As most of the development of this technology occurs in-house, Xerox is the primary
driver. Given that Xerox leads the development of such technologies, they should have a reliable
idea as to how fast the technology will evolve.
With a typical product development cycle at
Xerox lasting three years, it is reasonable to predict that a new technology will be available for
the next generation product. Therefore, the generation-based technology change rate should be
set to one generation.
Lastly, it is important to evaluate if such technological improvements will be beneficial to either
the customer or the company.
The creation of an electric field plays a key role both in image
quality and in overall machine speed. As these are two key areas by which a customer evaluates
the product, improvements in these areas would certainly benefit the customer. Given this, the
78
pursuit of new innovations in this area, with the goal of incorporating such advancements into the
next generation of products, is certainly justified.
The second function in the charging module is the "direct electric field" function. This function
is responsible for directing the electric field towards the proper location, that being the
photoreceptor. Shields and filters are used to complete this function. Directing the electric field
is, at least from a technology standpoint, not a particularly challenging problem. Therefore, little
research is currently being done to improve this function. The current technology is probably
quite advanced on its technology s-curve, although small improvements may still be possible.
This technology has not changed noticeably in the past few years. In general, it does not undergo
changes as frequently as other parts of the system.
Since the role of this function in the
xerographic process is unlikely to change significantly, the rate of technology change in the next
decade will probably reflect the rate of technology change for the past decade. Given this, it can
be estimated that this technology will not change for perhaps two to three product generations.
Lastly, the impact of this function on the customer and company should be evaluated. While this
function has a small role in image quality and machine speed, it is not the primary limitation on
these properties. Therefore, while this function is important, technological improvements in this
function will not necessarily result in performance improvements or in increased customer
satisfaction. Therefore, there is no real need to improve this function. Given this, the technology
change rate should be set to three product generations. Since changing such technologies would
not be particularly beneficial to the customer or the company, there exist no real reasons for
developing new technologies in this area.
The third function in the charging module is the "regulate electric field" function. This function
is responsible for ensuring that the proper voltage is passed to the photoreceptor. This is done
primarily through the use of a charge grid. New charge grids are always under development,
although this is not a particularly active area of research. While the technology is quite advanced,
there is still room for improvement. Thus, on the technology s-curve, the current technology,
while mature, has not yet reached its technological limit.
This technology has steadily evolved over the past few years.
New grid designs have been
developed to allow a more uniform regulation of the electric field. Technological innovations
79
such as these occur perhaps every few years. Internal research at Xerox has been the primary
driver for such innovations, and will most likely continue to be the main driver. However, the
rate at which this technology evolves is not likely to change considerably in the upcoming years.
Given this information, it can be estimated that the "regulate electric field" function will not
significantly improve for perhaps one to two product generations.
Lastly, the impact of this function on the customer and company must be evaluated. Regulation
of the electric field has a direct impact on the strength and uniformity of the charge applied to the
photoreceptor. Thus, it plays a large role in image quality, which in turn plays a large role in
customer satisfaction. Therefore, technological improvements in this area are important in the
market. Given this, the technology change rate should perhaps be increased, if possible, such that
improved technologies can be implemented with every product generation.
Now that technology change rates have been established for each function in the charging
module, the modularity scheme should be re-examined. As each of these functions have different
technology change rates, perhaps they should not be grouped into a module. By separating these
three functions, the architecture can now better accommodate technology upgrades. The new
Generation-based
modularity scheme for the charging module is shown in Figure 5.13.
technology change rates are indicated for each function.
Energy
---
Create
Electric
Field
I generation
3 generations
1 generation
Energ
Oirectd
Direct
Electric
Field
Regulated
Regulate
-4-*Electric
Field
Energy
-6---
Charge
Information
Figure 5.13: New modularity scheme for the Charging Module.
Generation-based technology change rate values are indicated for each function.
80
5.6
Discussion
The method presented above allows technology change rates to be incorporated into product
architecture decisions. While the modularity equations associated with technology change rate
are quite straightforward, coming up with actual technology change rates for each function is a
difficult task.
Product developers must carefully consider both their product and the market
landscape in coming up with values for technology change rate.
Technology change rate, while important, is only one of the many evaluation criteria that must be
Other evaluation criteria, such as serviceability
considered when making modularity decisions.
and supply chain, also affect the selection of a product architecture. Thus, the overall decision on
product architecture depends on many different considerations, not just those of technology
change rate.
81
82
6
Supply Chain
Many of today's products are sufficiently complex that no single company can produce a product
alone. Instead, companies are increasingly dependent on suppliers to provide components critical
to the product. For example, consider the case of the Ford Motor Company. In the past, Ford has
relied on both internal sources and external suppliers to provide the components necessary for
Ford automobiles. While some components were provided by suppliers such as Bosch, Johnson
Controls, and Goodyear, other components were designed and manufactured in-house. Recently
however, Ford has spun off its auto parts division under the name of Visteon. This move comes
only a few years after General Motors spun off its own parts division under the name of Delphi
Automotive Systems.
company.
This recent move by Ford shows a notable strategy shift within the
Instead of designing and manufacturing parts and components, Ford has shifted its
focus to assembly and system integration.'
As an assembly and integration house, Ford is now
much more reliant on its suppliers to provide the necessary components for its products. Because
of this dependence, design of the supply chain at Ford is certainly of great importance.
The
product architecture of their automobiles is also critical, as product modules must be defined such
that suppliers are capable of delivering the functional modules specified.
As opposed to choosing a product architecture, then looking for suppliers, supply chain and
product architecture should be simultaneously determined. By doing so, product developers can
group product functions into product modules that are effective from a supply chain standpoint.
With increasing product complexity, and increasing dependence on suppliers, relating product
architecture to supply chain is an important capability. This chapter presents a methodology for
simultaneously examining supply chain and product architecture. This methodology specifically
focuses on how the network of available suppliers can and should influence the product
architecture selected. After explaining the methodology, examples based on a Black and Decker
product are presented.
6.1
Related Work
In recent years, the topics of supply chain design and supply chain management have become
increasingly important areas of research.
Research in this area has covered a broad range of
topics, from delayed differentiation to evaluating the make-buy decision. The wide scope of this
field mirrors the complexity of this issue, as many variables factor into supply chain decisions.
83
In his book, Clockspeed, Fine addresses many issues related to the design and management of
supply chains.2
Fine stresses the fact that all advantage is temporary; thus, companies must
constantly monitor and adjust their product, process, and supply chain to gain or preserve their
competitive advantage.
The key to long-term success is to avoid hanging on to diminishing
advantages. Instead, companies must constantly strive to find the next new advantage. In doing
so, Fine suggests using three-dimensional concurrent engineering, in which product architecture,
process architecture, and supply chain architecture are simultaneously developed.
Fine also investigates the make-buy decision and its importance to long-term company success.
The work presented builds upon previous work by Fine and Whitney, in which the make-buy
decision process is studied. 3 In stressing the importance of the make-buy decision, Fine presents
many cases, including the famous IBM decision in the 1980's.4 When IBM launched its first
personal computer, supply chain decisions were made which eventually proved very costly to the
company. With a modular product design, the first computer systems assembled by IBM used
major components provided by suppliers such as Intel and Microsoft. IBM primarily functioned
as the system integrator. However, as time has shown, this was a very costly decision by IBM.
Today, consumers purchase computers based on "Intel Inside" and "Windows 2000," not on the
fact that IBM assembled it. As it turned out, IBM outsourced what became the most valuable
parts of the computer system. Fine suggests that the auto companies, including Ford, must be
cautious of a similar fate. The day may come when cars are purchased based on "Bosch Inside,"
not on the fact that Ford assembled the product.'
Much has also been written regarding the power of delayed differentiation, otherwise referred to
as postponement.
With uncertain demand for products, companies that can keep a product
generic for as long as possible in the supply chain, can usually reap considerable benefits. Most
of these benefits come from lower inventory costs and an improved ability to meet customer
needs. In the literature, cases are again presented showing the value of such postponement.
While much research is currently taking place in the area of supply chain design, and much
research is going on in the area of product architecture, little has been done to link the two fields.
Fine mentions the importance of concurrently designing product, process, and supply chain, yet
stops short of presenting methodologies to do so. Ericsson and Erixon also mention supplier
availability as one of many drivers of modularity, but do not explore this idea in depth.8
84
Some
research in product architecture looks at product modularity from a lifecycle perspective, yet few
incorporate supply chain into architecture decisions. Ishii looks into supply chain factors that
influence modularity, such as outsourcing strategy and postponed differentiation.9 His methods
incorporate supply chain issues by considering how they affect product lead time. Design charts
are used to plot product variety versus lead time, thereby allowing product developers to
determine inefficiencies in manufacturing and supply chain. The work presented here addresses
the supply chain primarily by examining the network of possible suppliers and how that network
can drive product architecture. While this addresses the same relationship between supply chain
and product architecture that has been explored by others, it provides a new and more detailed
approach to studying this interaction.
6.2 Approach
The general methodology to incorporate supply chain issues into product architecture decisions is
shown in Figure 6.1.
Create a function structure for the
given product.
Determine candidate modularizations
using flow heuristics.
Examine supplier possibilities for each
candidate modularization.
Evaluate alternative architectures.
Figure 6.1: General methodology for incorporating supply chain
issues into product architecture decisions.
As in the previous methodologies, the process begins with a functional analysis of the product. A
function structure for the product must first be created. As described in detail in Chapter 3, this
function structure should contain a network of product functions, interconnected by material,
energy, and information flows.
85
Once a function structure is created for a product, candidate product modules can be formed by
applying partitioning heuristics.
These flow-based heuristics identify multiple modularity
schemes that maintain physical consistency.
However, the modules identified through these
means are also those that incorporate the maximal set of functions into a module. These maximal
modules, while maintaining physical consistency, are often not ideal.
supplier capabilities, should also play into modularity decisions.
Other factors, such as
Therefore, the modules
identified through the application of flow-based heuristics should be further refined to better
address other modularity concerns.
The modularity schemes identified in the second step of this method should now be examined by
looking at possible suppliers for each suggested module. Certain groupings of functions may fit
perfectly with the capabilities of a particular supplier. On the other hand, some modules may
present difficulties, as no supplier is currently capable of providing such a functional grouping.
In such cases, the module boundaries may need to be changed.
Various candidate
modularizations should be analyzed by examining which functional groupings most closely fit
supplier capabilities.
Now that different product architectures have been created and analyzed from the standpoint of
the supply chain, the product development team is left to evaluate the various options.
In
selecting a product architecture, product developers must consider the many trade-offs involved.
The steps presented above represent a methodology for architecting a product while taking supply
chain issues into account.
6.3 Evaluating Suppliers
In developing a product architecture that takes into account the capabilities of suppliers, a criteria
for evaluating different suppliers is necessary. However, this is a very difficult task, as many
factors play a role in supplier selection. Furthermore, each company, and even each product
development team within a company, may value supplier qualities differently.
For example,
while some may stress component quality considerations, others may be more concerned with
cost, while still others may be most concerned with component lead time.
Given this, the
following section will address some of the many issues that should be taken into consideration
when evaluating suppliers. While the list is not comprehensive, it does provide a solid basis on
86
which different suppliers can be judged.
How product development teams in turn use this
information to determine suppliers, and thus product architecture, is up to each individual team.
In order to incorporate supplier capabilities into product architecture decisions, product
developers should consider the following list of questions. These questions should be addressed
after flow heuristics have been applied to the function structure and candidate modularization
schemes have been formed.
"
Are suppliers capable of delivering the specified modules?
"
How many suppliers can provide this module?
"
Are the possible suppliers a good fit with the company?
=
How do the modules affect the make-buy decision?
Are suppliers capable of deliveringthe specified modules?
In incorporating supplier capabilities into product architecture decisions, this first question is
perhaps the most important. In partitioning a product for supply chain concerns, it is critical that
at least one of the suppliers in a company's supplier network is capable of delivering the specified
functional module. Situations will sometimes occur in which no suppliers can provide the exact
module as specified, particularly when large modules are defined.
In such a case, it must be
determined whether or not suppliers could be created or grown such that they could later produce
the desired module. Clearly, product architectures must be re-evaluated if modules are created
that cannot be provided by suppliers.
In determining if a supplier can provide a function, it is important to be aware of the quality, time,
and cost constraints for the product.
There will almost always be suppliers who have the
capability to make a specific functional module; however, there will not always be suppliers who
can produce such modules given the quality, cost, and time constraints imposed by the product
developers. Modules must be available at cost and quality levels that are appropriate given the
product under development. The module must also be available on a time frame that is practical
for the product given its production schedule. If a module is very complex, so as to make its lead
time significantly longer than that of the other components in the system, perhaps the product
architecture should be re-evaluated to bring all module lead times within a certain acceptable
range.
87
How many suppliers can provide this module?
Once it has been determined that the module can be supplied within the given constraints, the
overall supplier situation should be evaluated. Product developers should determine how many
suppliers are capable of providing such a functional module. For example, perhaps a module can
only be produced by a single supplier. In this case, the company must decide if it is willing to be
dependent on a single supplier for a particular functional module.
While nurturing a strong
collaborative relationship with a single supplier can have a positive effect on product
development, some would prefer to avoid such a monopolistic situation. In this case, the product
architecture may need to be changed in order to create modules which more suppliers can
provide. In contrast, it may be determined that multiple suppliers are capable of producing the
necessary module. In this case, competition between suppliers may result in higher quality, lower
cost, and shorter lead times. In such a situation, the product architecture may be acceptable as is.
Given that there are clearly benefits to both the single supplier and the multiple supplier system, it
is up to the individual company to determine the right supplier situation for their needs.
However, the company should be aware of their desired situation when determining product
architecture.
Are the possible suppliers a goodfit with the company?
Possible suppliers should be evaluated to see if they are a good fit with the company. It is often
better, from both a time and cost standpoint, if a company can rely on a few main suppliers for
most of its product modules. This helps to keep overall system complexity low. A larger number
of suppliers usually means that more time and resources will be spent managing relationships,
coordinating logistics, and carefully defining interfaces.
Therefore, when a set of suppliers is
proposed, the set should be evaluated to see if such a combination of suppliers is efficient and
effective for the company. Perhaps a slightly different product architecture could greatly reduce
the number of suppliers, and thus reduce the system complexity.
How do the modules affect the make-buy decision?
The modularity scheme must also be examined from the standpoint of the make-buy decision.
Modules should be analyzed to make sure that key technologies and critical knowledge stays
within the company. Each function should be evaluated based on its strategic importance to the
long-term success of the company. Those functions that are strategically important, or that may
become important in the future, should remain in-house. Given this, such functions should not be
88
grouped with functions that are best outsourced.
Understanding the strategic implications of
modularity decisions will help prevent critical strategic knowledge and capabilities from leaving
the company.
This list of questions provides a solid starting point to examine product architecture from the
viewpoint of supplier capability. Understanding the effect that the supply chain has on product
architecture is critical for product developers. While each development team will make their own
trade-offs regarding quality, cost, and time, the questions presented above provide a framework
by which such issues can be considered. As with most development issues, specific decisions
will depend on the product, company, market, and development team.
It should be noted that the idea of suppliers extends to internal suppliers, or divisions within a
single company that are responsible for providing components and modules to other divisions in
the same company.
It is important to consider internal suppliers when making product
architecture decisions. While most of the questions posed above should still be considered when
dealing with internal suppliers, some of the questions, particularly those related to the make-buy
decision, are clearly no longer applicable.
Also, while the product is examined from a functional perspective, the supplier capabilities are
often examined by analyzing specific solutions, not general functions. Product developers must
be sure to look outside the scope of current solutions when evaluating possible suppliers. It is
likely that with a different physical solution to a particular set of functions, a completely different
pool of suppliers becomes available.
Product developers must be aware of other possible
solutions and suppliers when determining an appropriate product architecture.
6.4 Example: Black and Decker Screwdriver
The ideas presented above are applied to a cordless rechargeable screwdriver developed by Black
and Decker.
The screwdriver is shown in Figure 6.2.
This same screwdriver was analyzed
previously using the methodology for technology change rate.
89
Figure 6.2: Black and Decker cordless screwdriver.
The first step in this methodology involves creating a function structure of the product, as shown
in Figure 6.3. The modularity heuristics of dominant flow, branching flow, and conversiontransmission are then applied to the function structure to define candidate modularization
schemes. These candidate modules are then analyzed from the viewpoint of supplier capabilities
to determine which make sense from a supply chain perspective. The application of this
methodology is now shown as it applies to the torque module and power module of the Black and
Decker screwdriver. These modules are highlighted in Figure 6.3.
Power Module
Store
Elcticty
Electricity
Electriciy
ElectricitY
Transmit
El
Thumb
Noise,
IConvert
Torque Ice
M
ISwitch
Electricity
to Motion
Heat *r
Iul
Thumb
Torque
ack
Transform
Noise
Input
Signal
Power
Hot Turning
Turn
Tranit
P
RRotatione
Force
Hand
Inu
Hand
HHand
oqePermit
+Bit
Bit
Position
Hand
Force
Bit
Register
Bit E'
Bit
BitBit
Secure
Bit
/
Un-lock
Bt
Release
Bit
Bit
+~ Bit Secure
Force into
opposite hand
Figure 6.3: Function structure of the Black and Decker cordless screwdriver.
The torque module and power module are indicated with dashed boxes.
90
6.4.1
Torque Module
The torque module, as shown in Figure 6.4, contains two functions. These functions are grouped
as a module due to the conversion-transmission heuristic. In this case, electricity entering the
system is converted to mechanical energy, which is then altered and transmitted. In grouping
these two functions together, all functions that deal with converting electrical energy to the
correct rotational output are isolated as a single module.
Torque Module
Electricity
ConVert
Torque
Torque
----- Electricity--to Motion
heat
Figure 6.4: Functional diagram of the Torque Module.
This modularization scheme is now analyzed from the viewpoint of supply chain. Specifically,
the possible suppliers for such a module should be considered. In considering possible
modularization schemes, the questions proposed above are carefully considered.
The first function in the Torque Module is typically completed using a small DC motor. The
second function transforms the rotational output from the motor, reducing the RPMs and
increasing the torque. This is usually done through the use of gear reductions, using sets of gears
to step down the rotational speed. There are certainly suppliers that can provide these functions
as a single module. However, in many cases, such a module would require either special
engineering on the part of the supplier, in terms of both design and manufacturing, or finding a
secondary supplier for a sub-system, then integrating their components with those of the
secondary supplier. Companies focused on DC motors would need to acquire expertise in gears
and transmissions, while companies focused on transmissions would need to acquire expertise in
motors. In either situation, substantial investments in time and resources will need to be made on
the part of the supplier. While some suppliers may be willing to do this, it could lead to part costs
and lead times that are unreasonable for the given product. With no suppliers that are uniquely
capable of providing such a module, perhaps other modularity schemes should be analyzed
Perhaps splitting this module into a Motor Module and a Transmission Module, as shown in
Figure 6.5, could make it easier to find suppliers. DC motors are virtually a commodity, with
91
numerous companies competing in a crowded marketplace. Companies such as Mabuchi Motor,
Johnson Electric, and Winston Electric all produce small DC motors for such applications.10
Given that all three of these companies provide ready-made solutions for the function of
converting electricity to motion, it may be easier to go with such a supplier. As such motors are
already being produced, cost and lead time should be less than for the Torque Module. The
Transmission Module can also be easily supplied by a host of gear and transmission suppliers,
including SDP-SI, Berg, and PIC." Black and Decker also produces some gears and
transmissions for use in other products, and thus has the knowledge and capability to produce
such systems. Each of these suppliers can readily provide a wide range of gear and transmission
solutions, thereby helping to minimize cost and lead time. By looking at supplier capabilities,
perhaps a split modularity scheme is more effective.
Motor Module
Electricity
Convert
Transmission Module
Torqu
Torque
-----
Electricity
to Motion
Iheat
Figure 6.5: Functional diagram of the Motor Module and Transmission Module.
Grouping the functions into a single Torque Module would allow a single supplier to provide
both functions. This may be advantageous in that fewer supplier relationships will need to be
managed. Also, with a single supplier for these functions, fewer interfaces will need to be
defined. With two suppliers, the interface between the Motor Module and the Transmission
Module would also need to be defined. However, the savings realized by having a single supplier
for this module may not outweigh the higher part costs and longer lead times. These issues must
be carefully evaluated by the product development team.
Lastly, the effect of modularity on the make-buy decision should be analyzed. If the Torque
Module is used, Black and Decker would be forced to outsource the module. With limited
current expertise in DC motor design or production, Black and Decker would be dependent on an
outside supplier for these functions. However, as this is not a particularly strategic module,
outsourcing may not be a problem. If the split modularity scheme is used, the motor can easily be
outsourced to one of the many DC motor producers, including those mentioned previously.
Meanwhile, the gear and transmission module can be produced by Black and Decker, using
internal design and manufacturing capabilities. By splitting up the Torque Module, commodity
92
components, such as the DC motor, can be outsourced, while other components, such as the
transmission, can be kept in-house. As neither component is of particular strategic importance,
the effect of modularity on the make-buy decision may not be significant.
Evaluating the advantages and disadvantages of these competing modularity schemes, the split
modularity scheme appears to be a valid possibility. A split modularity scheme would probably
lead to shorter lead times and lower module costs. Also, by splitting the two functions, product
development teams can take advantage of external expertise in the DC motor industry and
internal capability in gears and transmissions.
6.4.2
Power Module
The power module, as shown in Figure 6.6, contains two functions. These functions are grouped
as a module due to the dominant flow heuristic. In this case, electricity passes through both
functions in the module.
In grouping these two functions together, all functions that deal
exclusively with electricity are isolated as a single module.
Power Module
Electricky
Electricity
Electricity
bectricity
Elecrict
Figure 6.6: Functional diagram of the Power Module.
This modularization scheme is now analyzed from the viewpoint of supplier capability. In doing
so, possible suppliers for such a module should be considered. As possible modularizations are
evaluated, the questions proposed above are again addressed.
The first function in the Power Module is completed through the use of a rechargeable battery.
The second function simply transmits electricity from the battery to the rest of the system, and is
thus typically completed by wires and metal contacts. Battery suppliers are certainly capable of
providing the entire Power Module. While their expertise may be in battery technologies, a
battery supplier could easily purchase wires and contacts from a secondary supplier and add them
to their batteries, as per customer instructions. However, given that their primary focus is on
batteries, systems, such as the Power Module, may result in higher prices and longer lead times.
Wire and contact suppliers could also supply such a module by purchasing batteries from a
93
secondary supplier and adding them to their components. However, as before, such system
designs may result in higher prices and longer lead times. Companies that specialize in individual
components may not be interested in putting together systems. Given these considerations, and
given cost and time constraints, the number of suppliers for such a module is probably relatively
low.
Splitting this module into a Battery Module and a Contact Module, as shown in Figure 6.7, could
make it easier for suppliers. Numerous companies are capable of producing rechargeable
batteries, including Panasonic, Sanyo, and Varta.12 Given that many companies provide readymade solutions for the function of storing electricity, it may be easier to go with such a supplier.
As such batteries are produced in quantity, cost and lead time for a Battery Module should be less
than for a Power Module. Wire and contacts are basically a commodity, with numerous possible
suppliers. Companies including Belden, BICC General, and Alpha are capable of providing the
transmit electricity function.13
Given this, acquiring such components from one of these
companies could help minimize cost and lead time.
Contact Module
Battery Module
Eletrci
Store
E
Electricit
i
Transmit
Electricity
Figure 6.7: Functional diagram of the Battery Module and Contact Module.
Grouping the functions into a single Power Module would allow a single supplier to provide both
functions. Instead of integrating the two functions in house, Black and Decker could simply rely
on a single supplier to provide such a module. This would lessen the number of suppliers, lessen
the number of interfaces that must be defined, and lessen the part count in final assembly.
However, these advantages must be considered together with the disadvantages of higher part
costs and longer lead times.
Lastly, the effect of modularity on the make-buy decision should be analyzed. With limited
internal expertise in these areas, and a well developed supplier network, Black and Decker could
easily outsource such a module. However, the Battery Module may be becoming a more
important strategic module, as longer battery life can help to differentiate Black and Decker tools
from others on the market. Given this, battery research and development may be a capability that
Black and Decker should try to bring in-house. If indeed this is a strategic focus of the company,
94
by splitting up the Power Module, the battery development can be brought in-house while the
wiring and contacts can be outsourced.
Evaluating the advantages and disadvantages of these competing modularity schemes presents a
difficult trade-off. Product developers must carefully examine the issues and, depending on their
own evaluation, determine an architecture that fits their supply chain strategy.
6.5
Discussion
The method presented above allows supply chain issues to be incorporated into product
architecture decisions. The network of suppliers available to a company should be understood by
product developers when making product architecture decisions. By doing so, architectures can
be determined that fit well with the company's supply chain.
While supply chain is important, it is only one of the many evaluation criteria that must be
considered when making modularity decisions. Other evaluation criteria, such as those presented
in the previous two chapters, also greatly affect the selection of a product architecture.
The
overall decision on product architecture must take into account all of these considerations, not
just those of supply chain.
95
96
7
Conclusions
Determining product architecture is a critical step in any product development activity.
By
selecting an effective product architecture, companies can realize large savings, both during
product development and over the life of the product. This thesis shows how non-functional
issues such as serviceability, technology change rate, and supply chain can be incorporated into
product architecture decisions.
The methodologies presented here can be used by product
development teams to determine product architectures that are effective for the company.
7.1
Optimization
In this thesis, the issues of serviceability, technology change rate, and supply chain are analyzed
individually.
Each methodology presented looks at only one issue at a time; therefore, each
methodology yields a product architecture that is optimized for a single concern. While this is an
important step, an actual product architecture must incorporate many different objectives into a
single modularity scheme.
These objectives include, but are not limited to, serviceability,
technology change rate, and supply chain. Therefore, while each specific concern may suggest a
different modularity scheme, these often-competing goals must be resolved to yield a single
product architecture. The trade-offs involved in making such a decision depend on the overall
objectives of the product, company, and development team. Making such a decision can be a
difficult task.
In defining a single modularity scheme, primary goals for the product architecture must be
determined.
Once appropriate modularity objectives are selected, different candidate product
architectures should be formed.
These can be determined using flow-based heuristics, as
discussed in Chapter 3, or other partitioning methods. The candidate modularity schemes must
then be evaluated to determine how well they meet the overall product architecture goals. At this
stage, specific methodologies, such as those presented in this thesis, can be used to help evaluate
and adjust these candidate modularizations.
Once each candidate modularity scheme has been
evaluated from the perspective of each architecting goal, the product development team is left
with a multi-attribute decision-making problem.
Various methods exist to complete such a multi-attribute evaluation.
One of the most basic
evaluation methods is that of the Pugh selection matrix. A Pugh matrix can be used to select
97
between multiple different concepts using a set of defined criteria.1 In using a Pugh matrix for
architecture selection, candidate architectures are listed in columns, while judgement criteria are
listed in rows. One architecture serves as a datum, against which other candidate architectures
are compared and rated. For each of the evaluation criteria, architectures under consideration are
given one of three ratings, as compared to the datum: better, signified by a plus (+), worse,
signified by a minus (-), or the same, signified by an "S". The ratings in each column can then be
summed, yielding an overall score for each candidate architecture.
While the Pugh selection
matrix provides a simple yet effective evaluation technique, more numerical approaches, such as
decision analysis, could also be used.2
As an example of this architecture selection process, consider the Black and Decker cordless
screwdriver analyzed in the previous chapters.
In determining an effective overall product
architecture, the primary goals will focus on serviceability, technology change rate, and supply
chain.
Other goals can certainly be selected, depending on the objectives of the product,
company, and product development team. Once these primary goals are established, candidate
product architectures should be created.
Three possible modularity schemes are formed, as
shown in Figures 7.1 through 7.3. Modularity scheme A, shown in Figure 7.1, groups functions
following flow-based heuristics from Chapter 3, thereby creating maximally sized modules.
Modularity scheme B, shown in Figure 7.2, keeps each function as a separate module, thus
resulting in 15 individual modules. Modularity scheme C, shown in Figure 7.3, groups functions
following both flow-based heuristics and methodologies presented in this thesis.
Thus, the
modules formed address the influence of serviceability, technology change rate, and supply chain.
98
Electricity
Eletriity
Electrici
Store
Electricity
Transmit
Electricity
I
Thumb
L
Electricity
Noise
Heat
I Convert
I
Electricity
EetiiyPower
to
I
Motion
1
u
Thumb
Thm
Signal
Screw
Torqub
Noise
HandHand
Ns Transform
(T, ~
~Input
Hand
Bc
Rotation
--
Torque
I.-ILLL.....
Transmit
Power
Turn
ew
.P
Permit Bit
Positioning
Hot Turning
Screw
BtPsto
Bit Position
Reaction Force
Hnd------------Hand
Hand
Force
Bit
Register
Bit
Bit
Bitoc
Secure
Bit
BitRel
Bit
Un-ock
Bit
Bit
Release
Bit
o, Bit~Secure
Bit
Force into
opposite hand
Figure 7.1: Modularity scheme A. This candidate architecture groups
functions into maximally sized modules.
99
r ------Store
Electriity
Electricity
r-------i
1
Transmit
Electricity
Electrici
E le
I
ctric
TThumb
Transform-
Nos
I
IConver
~
I
T,Moi
Nde
I
Roaio
n
--
oerSrw
II
--------------
--
ce
PlerticitBwitc
I
r___
to~ostonn II
I--- rque
Ho Turnin
Tur
I
Trnsi
El
1
PnpstTumn
Roineaocoiot nFrc
r
-
Hand
Hand
Force
Bt
r--,------1
IBi
I
Register
Bit
Bit
r--------1
IBi'BitI
Secure
r--,------1
Bt
Bit
r--,------1
Un-lock
Release
Bit
Bit
Bit Secure
Force into
opposite hand
Figure 7.2: Modularity scheme B. This candidate architecture
keeps each function as a separate module.
100
r Store
Electricity
Electricity
Transmit
Electrici
Electricity
Thumb
Electricity
Heat
I
Convert
4-- Electricity
Motion
Porto
......- .
1
Thumb
T
Signa
Screw
_n_
Transform
Noise
r
Hand
I
I.I
(Tv
t to''t(T
Rotation
Haynd
-
Turn
SrewScrew
Transmit
co
r- --- -- - Permit Bit
Torque
Hand
P Bit Position
Reaction Force
~Positioning
L
Hot Turning
Hand
Hand
Force
Register
Bit
Bit
Secure
Bit
Un-lock
Bit
Bit
Bit
Release
Bit
-, Bit Secure
Bit
Force into
opposite hand
Figure 7.3: Modularity scheme C. This candidate architecture groups functions following
both flow-based heuristics and methodologies presented in this thesis.
Each of these candidate modularization schemes is then evaluated on how well it fulfills the goals
for the overall product architecture.
As mentioned previously, the primary goals for this
architecture will focus on serviceability, technology change rate, and supply chain. Evaluating
the candidate architectures on these three metrics involves using the methodologies presented in
this thesis. These evaluations are shown in Tables 7.1 through 7.3. Each table lists the product
functions from the function structure in the first column. This list of functions is grouped into
modules according to the modularity schemes diagrammed in Figures 7.1 through 7.3.
Each
candidate module is then examined to determine values for serviceability, technology change rate,
and supply chain. Serviceability figures for a module represent the cost of service per 100,000
hours, as calculated using the equations presented in Chapter 4. In this example, the Random
Failure Model was used. The technology change rate values for a module reflect the fastest
technology change rate of the individual functions in the given module.
These values were
derived using the criteria presented in Chapter 5. The column entitled "supply chain" shows the
potential suppliers for each module. Methods presented in Chapter 6 were used to obtain supply
chain information.
101
Table 7.1: Evaluation of Modularity scheme A based on
serviceability, technology change rate, and supply chain.
Serviceability
($1100,000
Technology
Change Rate
Supply Chain
(potential
hours)
(years)
suppliers)
2
Panasonic,
Sanyo
10
Internal
store electricity
transmit electricity
$
switch power
input signal
67.10
$
7.10
$
122.40
5
Johnson,
Mabuchi,
SDP-SI
$
10.80
10
Internal
unlock bit
release bit
$
364.80
5
Internal
Total
$
572.20 I
convert electricity to motion
transform (T, o)
prevent back rotation
transmit power
turn screw
pert ihandpositioning
register bit
102
Table 7.2: Evaluation of Modularity scheme B based on
serviceability, technology change rate, and supply chain.
Supply Chain
Serviceability
Technology
($/100,000
Change Rate
(potential
hours)
(years)
suppliers)
store electricity
$
47.20
2
Panasonic,
transmit electricity
$
7.10
10
Belden, Alpha
switch power
input signal
$
$
14.20
7.10
5
10
Internal
Internal
convert electricity to motion
$
30.00
5
ouschn,
transform (T, co)
$
28.80
5
prevent back rotation
transmit power
$
$
28.80
21.60
5
5
Internal
Internal
turn screw
$
23.10
5
Internal
input hand
permit bit positioning
register bit
secure bit
un-lock bit
release bit
$
$
$
$
$
$
7.20
7.20
100.00
100.00
97.60
97.60
10
10
5
5
5
5
Internal
Internal
Internal
Internal
Internal
Internal
$
617.50
Total
a
103
Be
PlC
Table 7.3: Evaluation of Modularity scheme C based on
serviceability, technology change rate, and supply chain.
Serviceability
($/100,000
hours)
Technology
Change Rate
(years)
Supply Chain
(potential
suppliers)
store electricity
$
47.20
2
Panaonic,
transmit electricity
$
switch power
input signal
15.60
5
Belden, Alpha
$
7.10
10
Internal
convert electricity to motion
$
30.00
5
hnson,
transform (T, o)
prevent back rotation
transmit power
$
88.20
5
SDP-SI,
Berg, PIC
turn screw
input hand
$
7.20
10
Internal
permit bit positioning
register bit
$
7.20
10
Internal
unlock bit
release bit
$
364.80
5
Internal
Total
567.30
104
Once candidate product architectures are formed and evaluated, a Pugh selection matrix can be
used to select a single product architecture.
Table 7.4 shows a Pugh matrix used to select a
product architecture for the Black and Decker cordless screwdriver.
In this selection matrix,
modularity scheme A is used as the datum. Modularity schemes B and C are compared to the
datum and given one of the three possible ratings. For example, on the criteria of serviceability,
Thus, a minus (-)
modularity scheme B is compared to the datum, and judged to be worse.
appears in the Pugh matrix. On the same criteria, modularity scheme C is judged to be better than
the datum.
Hence, a plus (+) appears in the Pugh matrix. After each criteria is judged, total
The results show that given the three
scores can be tabulated for each architecture scheme.
criteria of serviceability, technology change rate, and supply chain, modularity scheme C is the
best choice.
Table 7.4: A Pugh selection matrix for the selection of an effective product architecture given the
criteria of serviceability, technology change rate, and supply chain.
Candidate Modularity Schemes
I-
!
51
7.2
Serviceability
Technology Change Rate
Supply Chain
Total
Ii
3-
A
U
U
B
UME
C
datum
datum
+
+
datum
datum
S
0
S
+2
-
+
j
Future Work
This thesis focuses on three important concerns that have serious influences on product
architecture. While serviceability, technology change rate, and supply chain are all significant,
there exist still more issues that must be considered during product architecture decisions. Issues
such as product variety, recycling, and manufacturing can all drive product architecture.
Therefore, the three methods presented in this thesis do not constitute a complete set of concerns.
Additional methodologies should be developed to address the influence of these other issues on
product architecture.
By considering more of these influences, it becomes more likely that a
product architecture will be effective for the given design objectives.
However, taking more
influences into account will also make the overall optimization more complex.
additional optimization methods should also be explored.
105
Given this,
106
8
Notes
Chapter 1
1.
http://www.intel.com
2.
http://www.honda.com
3.
Sanderson, Susan W. and Uzumeri, Mustafa. Managing Product Families. Chicago, Illinois:
Irwin, 1997.
4.
Stalk, Jr., George and Hout, Thomas M. Competing Against Time: How Time-based
Competition is Reshaping Global Markets. New York, New York: The Free Press, 1990.
5.
The term "clockspeed," used by Charles H. Fine in his book Clockspeed: Winning Industry
Control in the Age of Temporary Advantage, refers to the rate of evolution, usually as it
relates to an industry, product, process, or organization. (Reading, Massachusetts: Perseus
Books, 1998.)
6.
Young, Lewis H. "Product development in Japan: evolution vs. revolution," Electronic
Business, June 17, 1991, pp. 75-77.
7.
Pine II, B. Joseph. Mass Customization: The New Frontier in Business Competition.
Boston, Massachusetts: Harvard Business School Press, 1993.
8.
Hounshell, David. From the American System to Mass Production, 1800-1932. Baltimore,
Maryland: The Johns Hopkins University Press, 1984.
9.
Wheelwright, Steven C. and Clark, Kim B. "Creating Project Plans to Focus Product
Development," HarvardBusiness Review, March-April 1992, pp. 70-82.
10. Sanderson and Uzumeri, 1997.
11. Pine, 1993.
12. Sanderson, Susan W. and Uzumeri, Mustafa. "Managing product families: The case of the
Sony Walkman," Research Policy, 24, 1995, pp. 761-782.
13. Sanderson and Uzumeri, 1997.
14. Ulrich, Karl. "The role of product architecture in the manufacturing firm," Research Policy,
24, 1995, pp. 419-440.
15. Robertson, David and Ulrich, Karl. "Planning for Product Platforms," Sloan Management
Review, Summer 1998, pp. 19-31.
16. Bremner, Richard. "Big, bigger, biggest," Automotive World, June 2000, pp. 36-43.
17. The Audi A4 is produced on a platform called the B5, which is shared with the VW Passat
and Audi A6. In 1999, VW sold almost 840,000 cars based on their B5 platform. Bremner,
June 2000.
18. Bremner, Richard. "Cutting edge platforms," Automotive World, September 1999, pp. 30-33.
19. Bremner, Richard. "Common knowledge," Automotive World, June 1999, pp. 42-46.
20. Ibid.
107
21. Image taken from Bremner, June 1999.
22. Bremner, September 1999.
23. Bremner, June 1999.
24. Greimel, Hans. "DaimlerChrysler Loses $269 Million," AP Business News, February 26,
2001, pp. 1-4.
25. Ibid.
26. DaimlerChysler owns 33% of the Mitsubishi Motors Corporation of Japan.
Andrews, Edmund L. "Daimler Anticipates A Hard Year, Losing Perhaps $1.5 Billion," New
York Times, February 27, 2001, pp. CI-C2.
27. Andrews, 2001.
28. Hyde, Justin. "Daimler faces tough choices in sharing parts," Reuters, February 27, 2001,
pp. 1-3.
29. Ibid.
30. Andrews, 2001.
31. Hyde, 2001.
32. Andrews, 2001.
33. Ibid.
34. Robertson and Ulrich, 1998.
Chapter 2
1. Ulrich, Karl. "The role of product architecture in the manufacturing firm," Research Policy,
24, 1995, pp. 419-440.
2. Ibid.
3.
This example appears in Charles H. Fine's book Clockspeed: Winning Industry Control in the
Age of Temporary Advantage. (Reading, Massachusetts: Perseus Books, 1998.)
4. Fine, 1998.
5.
This example also appears in Charles H. Fine's book Clockspeed: Winning Industry Control
in the Age of Temporary Advantage. (Reading, Massachusetts: Perseus Books, 1998.)
6.
Fine, 1998.
7.
Robertson, David and Ulrich, Karl. "Planning for Product Platforms," Sloan Management
Review, Summer 1998, pp. 19-31.
8.
Ibid.
9.
Wheelwright, Steven C. and Clark, Kim B. "Creating Project Plans to Focus Product
Development," HarvardBusiness Review, March-April 1992, pp. 70-82.
10. Robertson and Ulrich, 1998.
11. Meyer, Marc H. and Lehnerd, Alvin P. The Power of Product Platforms. New York, New
York: The Free Press, 1997.
108
12. Pedersen, Per Elgaard. "Organisational Impacts of Platform Based Product Development,"
InternationalConference on EngineeringDesign, Munich, Germany. August 24-26, 1999,
pp. 1507-1512.
13. Pulkkinen, Antti, Lehtonen, Timo, and Riitahuhta, Asko. "Design for Configuration Methodology for Product Family Development," InternationalConference on Engineering
Design, Munich, Germany. August 24-26, 1999, pp. 1495-1500.
14. Martin, Mark V. and Ishii, Kosuke. "Design for Variety: Development of Complexity
Indices and Design Charts," ASME Design EngineeringTechnical Conferences, Sacramento,
California. September 14-17, 1997, DETC97/DFM-4359.
15. Kota, Sridhar and Sethuraman, Kannan. "Managing Variety in Product Families through
Design for Commonality," ASME Design EngineeringTechnical Conferences, Atlanta,
Georgia. September 13-16, 1998, DETC98/DFM-565 1.
16. Stone, R., Wood, K. and Crawford, R. "A Heuristic Method for Identifying Modules for
Product Architectures," Design Studies, Vol. 21, No. 1, January 2000, pp. 5-31.
17. Siddique, Zahed and Rosen, David W. "Product Platform Design: A Graph Grammar
Approach," ASME Design EngineeringTechnical Conferences, Las Vegas, Nevada.
September 12-16, 1999, DETC98/DTM-8762.
18. Rechtin, Eberhardt and Maier, Mark W. The Art of Systems Architecting. Boca Raton,
Florida: CRC Press, 1997.
19. Ericsson, Anna and Erixon, Gunnar. Controlling Design Variants: Modular Product
Platforms. Dearborn, Michigan: Society of Manufacturing Engineers, 1999.
20. Moore, William L., Louviere, Jordan J., and Verma, Rohit. "Using Conjoint Analysis to
Help Design Product Platforms," Journalof ProductionInnovation Management, 16, 1999,
pp. 27-37.
21. Gershenson, J. K., Prasad, G. J., and Allamneni, S. "Modular Product Design: A Life-Cycle
View," Transactions of the Societyfor Design and Process Science, Vol. 3, No. 4,
December 1999, pp. 13-26.
22. Coulter, Stewart L., McIntosh, Mark W., Bras, Bert, and Rosen, David W. "Identification of
Limiting Factors for Improving Design Modularity," ASME Design Engineering Technical
Conferences, Atlanta, Georgia. September 13-16, 1998, DETC98/DFM-5659.
Chapter 3
1.
Stone, Robert B. and Wood, Kristin L. "Development of a Functional Basis for Design,"
ASME Design Engineering Technical Conferences, Las Vegas, Nevada. September 12-15,
1999, DETC99/DTM-8765.
2.
Lawrence D. Miles is generally credited with developing the technique known as value
engineering. Much of his work on value engineering can be found in his first book,
Techniques of Value Analysis and Engineering (New York, New York: McGraw-Hill, 1961).
Akiyama, Kaneo. Function Analysis: Systematic Improvement of Quality and Performance.
Cambridge, Massachusetts: Productivity Press, Inc., 1991.
3.
Heller, Edward D. Value Management: Value Engineering and Cost Reduction. Reading,
Massachusetts: Addison-Wesley Publishing Company, 1971.
109
4. Akiyama, 1989.
5.
Otto, Kevin N. and Wood, Kristin L. Product Design. Englewood Cliffs, New Jersey:
Prentice Hall, 2001.
6. Akiyama, 1989.
7.
Ibid.
8.
Bischoff, W. and Hansen, F. Rationelles Konstruieren. KonstruktionsBUcher Bd. 5, Berlin:
VEB-Verlag Technik, 1953.
Rodenacker, W. G. Methodisches Konstruieren. KonstrktionsBticher Bd. 27, Berlin:
Springer, 1970.
Roth, K. Konstruieren mit Konstruktionskatalogen. Berlin: Springer, 1982.
9.
Pahl, G. and Beitz, W. Engineering Design: A Systematic Approach. London: Springer-
Verlag, 1996.
10. Otto and Wood, 2001.
11. Ibid.
12. Otto, Kevin N. and Wood, Kristin L. "Product Evolution: A Reverse Engineering and
Redesign Methodology," Research in EngineeringDesign, 10(4), 1998, pp. 226-243.
13. Otto and Wood, 2001.
14. Stone, R., Wood, K. and Crawford, R. "A Heuristic Method for Identifying Modules for
Product Architectures," Design Studies, Vol. 21, No. 1, January 2000, pp. 5-31.
Chapter 4
1.
Ishii, Kosuke. Course Reader ME217A: Design for Manufacturability: Product Definition.
Stanford, California: Stanford University Bookstore, 2001.
2.
Eubanks, C., Kmenta, S. and Ishii, K. "Advanced Failure Modes and Effects Analysis Using
Behavior Modeling," ASME Design EngineeringTechnical Conferences, Sacramento,
California. September 14-17, 1997, DETC97/DTM-3872.
Reliability Analysis Center. Course Material: Mechanical Reliability Training Program.
Rome, New York: IIT Research Institute, 2000.
Stamatis, D. Failure Modes and Effects Analysis. Milwaukee, Wisconsin: ASQC Quality
Press, 1996.
3.
Gershenson, John and Ishii, Kosuke. "Life-Cycle Serviceability Design," ASME Design
EngineeringTechnical Conferences, Miami, Florida. September 22-25, 1991, DE-Vol. 31,
DTM, pp. 127-134.
Gershenson, John and Ishii, Kosuke. "Design for Serviceability," in Concurrent Engineering:
Theory and Practice, Kusiak, A. (ed.) New York, New York: John Wiley & Sons, Inc., 1992.
4.
Ishii, Kosuke. "Life-Cycle Engineering Design," JournalofMechanical Design. Vol. 117,
June 1995, pp. 42-47.
5.
Newcomb, Patrick J., Bras, Bert, and Rosen, David W. "Implications of Modularity on
Product Design for the Life Cycle," ASME Design EngineeringTechnical Conferences,
Irvine, California. August 18-22, 1996, DETC96/DTM-1516.
110
6. Reliability Analysis Center, 2000.
7.
Gnedenko, Boris and Ushakov, Igor. Probabilistic Reliability Engineering. New York, New
York: John Wiley & Sons, Inc., 1995.
8.
Siddall, James N. Probabilistic Engineering Design. New York, New York: Marcel Dekker,
Inc., 1983.
9.
Misra, K. B. Reliability Analysis and Prediction. Amsterdam, The Netherlands: Elsevier,
1992.
10. Ibid.
11. Lewis, E. E. Introduction to Reliability Engineering. New York, New York: John Wiley &
Sons, Inc., 1996.
12. Ibid.
13. Moss, Marvin A. Designing for Minimal Maintenance Expense. New York, New York:
Marcel Dekker, Inc., 1985.
14. Dudewicz, Edward J. "Basic Statistical Methods," in Juran's Quality Control Handbook,
Juran, J. M. (ed.) New York, New York: McGraw-Hill, Inc., 1988.
15. Barkan, Phillip and Hinckley, C. Martin. "The Benefits and Limitations of Structured Design
Methodologies," ManufacturingReview. Vol. 6, No. 3, September 1993, pp. 211-220.
16. Xerox Corporation. Xerox Docucolor 2000 Series Brochure. 2000.
Chapter 5
1.
Sanderson, Susan W. and Uzumeri, Mustafa. Managing Product Families. Chicago, Illinois:
Irwin, 1997.
2.
Otto, Kevin N. and Wood, Kristin L. Product Design. Englewood Cliffs, New Jersey:
Prentice Hall, 2001.
3.
Tushman, Michael and Anderson, Phillip. "Technological Discontinuities and Organizational
Environments," Administrative Science Quarterly,31, 1986, pp. 439-465.
4.
Christensen, Clayton M. The Innovator's Dilemma. Cambridge, Massachusetts: Harvard
Business School Press, 1997.
5.
Christensen, Clayton M. "The Opportunity and Threat of Disruptive Technologies,"
Presentation at Xerox, Inc., Rochester, New York. June 12, 2000.
6.
Ulrich, Karl T. and Eppinger, Steven, D. Product Design and Development. Boston,
Massachusetts: Irwin/McGraw-Hill, 2000.
7.
Ibid.
8.
Ishii, Kosuke, Juengel, Cheryl, and Eubanks, C. Fritz. "Design for Product Variety: Key to
Product Line Structuring," ASME Design EngineeringTechnical Conferences, Boston,
Massachusetts. 1995, DE-Vol. 83, DTM, pp. 499-506.
Martin, Mark V. and Ishii, Kosuke. "Design for Variety: A Methodology for Understanding
the Costs of Product Proliferation," ASME Design EngineeringTechnical Conferences,
Irvine, California. August 18-22, 1996, DETC96/DTM- 1610.
111
Martin, Mark V. and Ishii, Kosuke. "Design for Variety: Development of Complexity
Indices and Design Chart," ASME Design Engineering Technical Conferences, Sacramento,
California. September 14-17, 1997, DETC97/DTM-4359.
9.
Ericsson, Anna and Erixon, Gunnar. Controlling Design Variants: Modular Product
Platforms. Dearborn, Michigan: Society of Manufacturing Engineers, 1999.
10. A conjoint analysis can be used to help estimate the relative importance that customers place
on technology, cost, and other attributes for any given product. The conjoint analysis method
is well described in the following article: Green, Paul E. and Wind, Yoram. "New Way to
Measure Consumers' Judgements," HarvardBusiness Review, July-August 1975, pp. 107-
117.
11. An example of this is the Global Positioning System (GPS) developed by the US
Government. When GPS finally reached its full operational capacity in 1995, the
government, in the interest of national security, intentionally degraded the GPS signal so as to
limit the accuracy for civilian users. In this case, while the technology existed, it was not
provided to the public with its full functionality. On May 1, 2000, the US Government
stopped degrading the GPS signal.
12. Much of the information used in this example was made up for the purpose of demonstrating
the methodology. The information used is not based on actual data and does not reflect actual
information from Xerox.
Chapter 6
1.
Fine, Charles H. Clockspeed: Winning Industry Control in the Age of Temporary
Advantage. Reading, Massachusetts: Perseus Books, 1998.
2. Ibid.
3.
Fine, Charles H. and Whitney, Daniel W. "Is the Make-Buy Decision Process a Core
Competence?" Working Paper, Massachusetts Institute of Technology, Cambridge,
Massachusetts, February 1996.
http://web.mit.edu/ctpid/www/Whitney/morepapers/makeab.pdf
4.
This case is presented in greater detail in Charles H. Fine's book, Clockspeed: Winning
Industry Control in the Age of Temporary Advantage. (Reading, Massachusetts: Perseus
Books, 1998.)
5.
Fine, 1998.
6.
Davis, Tom and Sasser, Marguerita. "Postponing Product Differentiation," Mechanical
Engineering,November 1995, pp. 105-107.
Lee, H. L. and Tang, C. S. "Modeling the Costs and Benefits of Delayed Product
Differentiation," Management Science, Vol. 43, No. 1, 1997, pp. 40-53.
Ulrich, Karl T. and Eppinger, Steven, D. Product Design and Development. Boston,
Massachusetts: Irwin/McGraw-Hill, 2000.
7.
Davis and Sasser, 1995.
8.
Ericsson, Anna and Erixon, Gunnar. Controlling Design Variants: Modular Product
Platforms. Dearborn, Michigan: Society of Manufacturing Engineers, 1999.
112
9.
Ishii, Kosuke. "Modularity: A Key Concept in Product Life-Cycle Engineering," Working
Paper, Stanford University, Stanford, California, 1998.
http://mml.stanford.edu/Research/Papers/1998/1998.LEbook.ishii/1998.LEbook.ishii.pdf
10. http://www.mabuchi-motor.co.jp/english/index.html
http://www.johnsonmotor.com
http://www.winston.com.hk
11. http://SDP-SI.com
http://www.wmberg.com
http://www.pic-design.com/index.htm
12. Newark Electronics, Catalog 119, 2001.
13. Ibid.
Chapter 7
1.
Clausing, Don. Total Quality Development. New York, New York: ASME Press, 1994.
Gonzalez-Zugasti, Javier P. and Otto, Kevin N. "Platform-Based Spacecraft Design: A
foundation and Implementation Procedure," IEEE Aerospace Conference, Big Sky, Montana,
2000. Vol. 1, pp. 455-463.
Hollins, Bill and Pugh, Stuart. Successful Product Design: What to do and When. London,
England: Butterworth & Co. Ltd., 1990.
Otto, Kevin N. and Wood, Kristin L. Product Design. Englewood Cliffs, New Jersey:
Prentice Hall, 2001.
2.
Antonsson, E. K. and Otto, K. N. "Imprecision in Engineering Design," Journalof
MechanicalDesign, Vol. 117, June 1995, pp. 2 5 -3 2 .
Thurston, D. "A Formal Method for Subjective Design Evaluation with Multiple Attributes,"
Research in EngineeringDesign, 3(2), 1990, pp. 105-122.
113