DFSC
HP’S DESIGN FOR SUPPLY CHAIN TEAM
Part Commonality Process Guide
Design for Supply Chain Tools and
Techniques
December 2004
Version 8
Part Commonality Process Guide
Version 8
Page 1
About the Contributors
This document was produced with the aid of the following people:
Jason Amaral, Stephen Bear, Brian Cargille, HP’s Design for Supply Chain Program
Kathy Petty, Business Critical Servers, Enterprise Storage & Servers
Katy Whitcher, Consumer Inkjet Printing, Imaging and Printing Group
Copyright Notice
This document is HP confidential, and may not be shared with parties outside of HP without
express written permission of the authors and SPaM management. It contains proprietary
information, which is protected by copyright and a pending patent that encompasses
the business process and tool described in this document. All rights are reserved. No part of
this document may be photocopied, reproduced, or translated to another language without
prior written consent of Hewlett-Packard Company’s Strategic Planning and Modeling group.
Version 8
Page 2
Introduction ......................................................................................... 5
1 Overview ....................................................................................... 7
How to Use This Book ......................................................................... 7
Which Products are the Best Candidates?.............................................. 7
Process Description ............................................................................ 8
Customizing the Process ..................................................................... 9
Time and Resource Requirements ...................................................... 10
Learning Objectives for This Guide ..................................................... 11
Ability to Initiate a Commonality Project ............................................. 11
Learning Objectives from Applying the Process .................................... 11
2 Project Initiation ........................................................................... 12
Core Skills ...................................................................................... 12
Team Lead ...................................................................................... 12
Mentor ........................................................................................... 12
Finance Lead/Modeler....................................................................... 12
Tasks ............................................................................................. 12
Obtain Sponsorship .......................................................................... 12
Define Project Scope ........................................................................ 13
Specify the RACI.............................................................................. 13
Problems and Solutions .................................................................... 13
3 Product Chunking .......................................................................... 15
Identify Product Chunks ................................................................... 16
Inputs ............................................................................................ 16
Outputs .......................................................................................... 17
Exit Checklist .................................................................................. 18
Determine Feasibility for Making Each Chunk Common or Re-usable ...... 18
Exit Checklist .................................................................................. 20
Summary of Product Chunking: Time, People, and Questions ............... 20
4 Cost Driver Analysis ...................................................................... 21
Summarize Issues & Evaluate Qualitatively ......................................... 22
Prioritize Cost Drivers ....................................................................... 24
Perform Rough-Cut Analysis .............................................................. 25
Evaluate Sensitivity & Validate Assumptions ........................................ 25
Present Results................................................................................ 26
5 Financial Modeling ......................................................................... 27
Architect the financial model ............................................................. 28
Desirable Model Characteristics ......................................................... 28
Example Financial Model ................................................................... 28
Whom to Involve ............................................................................. 29
Validate the Base Model and Assumptions ........................................... 29
6 Conclusion ................................................................................... 31
Version 8
Page 3
Version 8
Page 4
Introduction
This document is an aid for Hewlett-Packard managers and designers who are evaluating
commonality and reuse potential within a particular business. It provides tips on gathering
data, performing analyses, and making recommendations.
This process guide is part of the Design
for Supply Chain (DfSC) information
repository. These resources are intended
for new product introduction (NPI)
program managers, design engineers and
managers, and supply-chain professionals
within Hewlett-Packard. By using this
guide, you can apply robust and easy-touse decision-making techniques to reduce
supply chain and product costs, to
maximize profit margins, and to enhance
responsiveness.
The ideas in this process guide have
been developed across HP over the past
10 years. Our goal in creating the DfSC
repository is to make these techniques
accessible to a wider audience.
This guide in particular addresses the
problem of commonality. What does it
mean to have common, reused, or
industry-standard components? Should
you consider them for your products?

Commonality is the practice of
designing parts to be shared across
multiple products.

Reuse involves the use of parts that
were designed for a previous
generation of the product.

Industry-standard parts are those,
which are available, off-the-shelf, or
are otherwise generally available.
This guide takes you step-by-step
through the process of evaluating
commonality and reuse opportunities at
HP. We will also consider industrystandard parts that are common or
reused. With increasing cost and time-tomarket pressures, it is often
advantageous for HP to leverage designs
across a greater number of products.




Reduced design times help to avoid
delays in product introductions, and
the consequent lost sales.
Easier demand forecasting
translates into reduced buffer
inventory.
Industry-standard parts are usually
less expensive, easier to find in
times of shortage, and easier to resell of in times of excess.
From a procurement perspective,
value, cost, and price are easier to
determine.
Although commonality, reuse, and use
of industry-standard parts offer many
potential benefits, you should consider
other issues.

Commonality and reuse may
increase material costs if higherperformance parts are “downward
substituted” for use in lower-end
applications (the excess
functionality adds cost, but
engineering doesn’t need it and
customers don’t value it).

A loss of product “distinctiveness” in
external appearance and
functionality could occur, making it
harder to segment of product line,
differentiate from the competition,
and justify higher margins.
We have identified what we feel are
some of the key success factors in making
this process work. After using this guide,
you should have the ability to apply the
principles of commonality and reuse within
your division in a way that is most
appropriate for your products and
business conditions.
Version 8
Page 5
Part Commonality Process Guide
Version 8
Page 6
1
Overview
This chapter provides an overview of the Part Commonality decision process, along with
specifics on what types of products are the best candidates for commonality and reuse.
How to Use This Book
This book is a road map, not a
cookbook. You will need to exert a fair
amount of leadership and discretionary
judgment as you guide your group
through the process it describes. What
this book will do is give you some
guidelines for conducting this type of
project. The instructions are
supplemented with examples and
learnings from specific commonality
projects that have been done in the past.
Related documentation and additional
information resources are mentioned
where appropriate.
Which Products are the Best Candidates?
Products that make the best candidates
for commonality and reuse usually have
one or more of these eight characteristics:
1. High design costs. Costs for
prototype materials, tooling,
and design engineering can't be
shared across multiple products
if they each use a different set
of components. If part design
costs are high, commonality
may yield savings.
2. Strong time-to-market
pressures. By re-using parts
or switching from custom to
industry-standard parts, you
can reduce the time to design,
prototype, and test new
products.
3. Short life cycle. Write-offs
from custom parts are a
particularly acute problem for
products with short life cycles.
Thus, benefits from reuse will
be more widely felt.
4. High demand variability. If
demand is unpredictable,
commonality reduces the
burdens of forecasting, because
Version 8
5.
6.
7.
8.
there are fewer variations to
manage. Part availability will be
higher with the same inventory
levels, possibly even allowing
for reductions in inventory.
High product fan-out. The
more variety there is in the end
products, the greater the
benefit of making the
underlying parts common
across several product variants.
Poor supply-chain
responsiveness. Commonality
makes it easier to switch
between products quickly
during manufacturing, without
holding excess inventories of
unique components that may
be hard to obtain quickly.
High material prices. By
combining volumes for products
that currently use different
components, the cost of
obtaining the new common
component can be reduced.
High support costs. Re-used
parts often have lower failure
rates—and thus lower warranty
costs—because problems have
Page 7
already been fixed in the
previous product generations.
In addition, the use of common
parts enables fewer service
parts to be stocked at field
locations.
Process Description
The Commonality and Reuse Decision Process describes the major steps that we
recommend, along with desired outcomes. The four steps are: project initiation, product
chunking, cost driver analysis, and financial modeling.
Table 1: Commonality and Reuse Decision Process
Step
Activities
1. Project Initiation
2. Product Chunking
3. Cost Driver Analysis
Outcomes
Gain sponsorship for the project, define owners
and responsibilities, and clarify decisions to be
made
•
Review and prioritize commonality and reuse
opportunities for specific subassemblies and
components (“chunks”)
•
Perform a rough-cut analysis of a particular
decision or alternative (qualitative and quantitative)
•
•
•
•
•
•
•
4. Financial Modeling
Perform detailed analyses of decisions, including
model validation and sensitivity analyses
•
•
•
Although we will describe these four
steps as a sequential process, you can
take several paths depending on your
Step 1
Project
Initiation
Q
U
E
S
T
I
O
N
Step 2
Product
Chunking
Step 3
Cost
Driver
Analysis
B
D
E
Product
Chunking
Cost factors
Qualitative issues
Quantitative results
Sensitivities
Relative importance
Repeatable process
Cost analysis model/tool
Model/tool validation
Step 4
Financial
Modeling
Financial
Modeling
Project
Initiation
List of design chunks that
could be made common
Feasibility for each chunk
project objectives. In the figure below, we
show five paths that we have observed in
practice, labeled A through E.
A
C
Project scoping
Decisions and alternatives
RACI chart
Cost
Driver
Analysis
Financial
Modeling
Ex a mple Situa tion
A: N ot recommended
B: Rough-cut analysis
C: Add’l modeling required
D: Prioritize opportunities
Financial
Modeling
Version 8
D
E
C
I
S
I
O
N
E: Systematic modeling
Page 8
The first path, A, is one that we don’t
recommend. This path describes a
modeling project where a small group of
analysts builds a big, complicated
spreadsheet that is subsequently used to
evaluate design alternatives. If done
correctly (including appropriate data
gathering, model validation, and
sensitivity analysis), path A can result in
excellent decisions and significant return
on investment. In fact, several of us have
participated in projects that proceeded
along this path. Unfortunately, these
projects also take a long time to complete
– several months – and can try the
patience of participants and sponsors
alike. Complex models take a long time to
build, become “black boxes” to decisionmakers, require a lot of data, and tend to
“over analyze” many unimportant costs.
For example, the same amount of time is
often spent analyzing a cost that ends up
contributing 1% to the result as one that
contributes 50%. More importantly, there
is a significant opportunity cost to this
path; many more decisions aren’t
analyzed at all. The groups conducting
these types of analyses often get a
reputation as “too slow to work with,”
causing design organizations to make
decisions on their own.
We believe that paths B and C should
replace path A, though both are underutilized today. In these paths, the team
first performs a “rough-cut” analysis to
understand which cost drivers are most
significant. In some cases, the decision
becomes clear after the first-pass analysis
(path B). In other cases, more detailed
modeling is required and justified (path
C). We have observed projects taking
path B that achieved comparable benefits
relative to path A in one-fifth the time.
Even projects that must take path C are
usually completed more rapidly than those
taking path A. As we’ll describe in the
sections below, this is because the
subsequent financial models for path C
only focus on the cost factors that are
truly important in driving the decision –
everything else is ignored. In addition, the
transparency and simplicity of the cost
driver analysis accelerates intuitionbuilding and model acceptance on the part
of the decision maker and the extended
team.
In paths D and E, a “product chunking”
exercise is conducted prior to modeling
the cost drivers. These paths usually
follow a decision by senior management to
improve commonality and reuse across an
entire business. Chunking allows the team
to review and prioritize all of the major
commonality and reuse opportunities,
before deciding which ones to analyze.
Path E is usually pursued if there are a
significant number of opportunities that
are “too close to call.” A model (and in
rare cases a formalized decision tool) can
streamline the analysis process of many
different chunks.
Customizing the Process
As we have implied, we expect that
each business will apply this process
somewhat differently. In fact, individuals
may modify it over time as they learn
what works best for them. Consider two
examples of how HP’s Imaging and
Printing (IPG) and Enterprise Storage &
Servers (ESS) groups have used it to
make decisions.
During the economic downturn,
Consumer Inkjet Printing (CIP) within IPG
had focused mainly on cost reduction. As
a result, commonality and other DfSC
Part Commonality Process Guide
techniques were de-emphasized.
However, the priority began to shift back
in 2002 when PhotoSmart products were
on allocation due to shortages, while
single-function printers were in excess.
Business managers began to ask: “Can we
quickly switch production between
products?” and the answer turned out to
be “No, we can’t.” The reason was that
each product had unique parts with long
lead times. This lack of commonality was
a severe constraint on supply-chain
responsiveness.
Version 8
Page 9
As a result of this experience, CIP
invested in a series of analysis projects
and tools to better understand when and
how they could share components across
products (path E above). The outcome
was a best-practice commonality process
with an Excel-based tool to help quantify
the trade-offs between different
commonality alternatives. Because of the
success of these commonality projects—
including power supplies, paper trays,
ASICs, and PCAs—demand for this type of
analysis has grown.
Another group that has applied
commonality successfully is the Business
Critical Servers (BCS) business within
ESS. This group develops high-end
servers for large enterprises. Because of
system complexity and stringent
performance requirements, development
cycles usually last 2 to 3 years. In the
past, supply-chain costs were not
evaluated until just before product launch,
much too late to influence product design.
This was because many people in the
business believed that the only factors
that were important to them were product
functionality, time-to-market, and
material costs. Over the past 5 years,
however, it has become clear that the
supply chain provides a competitive
advantage in terms of lower costs, higher
product availability and better field
service.
BCS responded by creating a supplychain analyst organization, and by staffing
all development programs with NPI
engineers responsible for ensuring that
DfSC is taken into consideration. As a
result, there have been more than a
dozen analyses of various commonality
and reuse decisions (a combination of
paths A, B, and C). Although these
projects have usually focused on a
particular question posed by the
development teams, this is changing. In
late 2003, DfSC was announced as one of
the Top 10 ESS-wide supply chain
strategy initiatives. Since then, ESS-wide
teams have begun to focus on product
chunking in order to identify commonality
and reuse opportunities across the entire
organization (path D). Some examples of
successes include server racks, rails,
cables, and DIMMS.
Time and Resource Requirements
The first commonality project often
takes longer, because the team members
are building initial expertise, learning the
process, and forging ongoing relationships
with each other. In addition, some
managers and engineers must become
familiar with the costs and benefits of
commonality and reuse. We recommend
that first-time project managers work with
a mentor who can provide some
consulting support and accelerate the
process (see, for example,
http://dfsc.corp.hp.com).
While completion of the first rough-cut
analysis (shown as “B” above) may take 1
to 2 months, subsequent analyses with
the right people and enough buy-in should
take only 1 to 4 weeks. Likewise, a
chunking, cost driver, and modeling
project (shown as “E” above) that initially
requires 6 months can later be completed
in about 3 months. Over time, you will
develop robust processes and ongoing
relationships with experts who understand
what you need from them. You will be
better able to define the decision, describe
the alternatives, gather the data, and
perform the analyses.
Most of the resources you will need are
not full-time; most of the designers and
managers whose input you need at
various stages will be called in periodically
for highly focused brainstorming
meetings, and can then return to their
primary tasks. The typical resource
requirements are:
• Team lead - dedicated at least
50%, ideally with ownership for
ensuring that the appropriate
Version 8
Page 10
•
•
•
•
decision-makers select a course of
action (versus a support role).
Mentor - about 5% to 10% for
consulting support.
Finance Lead/Modeler dedicated at least 50% during the
cost driver and financial modeling
steps.
Core Team - about 5% to 10%, a
small group of people (about 5)
who provide thoughtful input and
detailed feedback on the key
project deliverables.
Extended Team - 5% or less, the
important organizational
stakeholders (usually 10 to 20
people) who provide data and
input, and participate in review
meetings.
The core team should include key
representatives from design, supply chain,
finance, and marketing. These people
should be respected across the
organization, so that when final
recommendations are made, the decision
makers know that several trusted people
have participated in and thoroughly
reviewed the analysis. As described below,
the team and responsibilities may shift
from step to step.
The project lead should also try to
secure a limited travel budget. For project
success, it will be critical that the core
team builds relationships and conducts
effective working meetings and
brainstorming sessions. This is particularly
true for the first commonality project with
a particular group of people.
Learning Objectives for This Guide
The learning objectives for this process
guide are the capabilities that you should
acquire during the course of using this
workbook in a real-world application. You
can think of this book as a “lab guide.” A
commonality and reuse decision-making
project can take several months to
complete, and these objectives are
acquired through “hands-on” practice,
rather than in a classroom devoted to
theory.
Ability to Initiate a
Commonality Project
Management support is essential to
initiating a commonality and reuse
process. After using this guide,
participants will be able to:
• Identify change-management
issues that must be addressed in
•
order to apply the decision
process.
Effectively gain attention and
sponsorship to establish the
process.
Learning Objectives from
Applying the Process
After going through the detail steps in
this guide, participants will be able to:
• Identify and describe the major
steps of the decision process.
• Describe the people and expertise
needed to complete each step.
• Identify the inputs and outputs for
each step.
• Describe the analysis or synthesis
used to create the outputs.
• Determine when each step has
been satisfactorily completed.
Version 8
Page 11
2
Project Initiation
This chapter describes how to establish a commonality and reuse process within your
division. We are going to assume that you have already determined that at least some of
your products are candidates for commonality or reuse. By establishing a process, you will
ensure management sponsorship and cross-functional support for prioritizing and evaluating
opportunities.
2.1 Core Skills
The core teams have tended to be
small, consisting of one dedicated team
lead and perhaps a mentor and a person
with model-building expertise. It is
recommended that you work with at least
one other person, for moral support if
nothing else.
may also have modeling expertise and a
detailed understanding of product design
and/or supply chain processes.
Mentor
Team Lead
The team lead is a dedicated person
who drives the decision process. The team
lead will bring in myriad subject-matter
experts for most of the industrial design,
manufacturing, and costing portions. To
make the most effective use of these
people, the team lead must be able to
coordinate discussions effectively. This
includes the ability to recognize quickly
when a process isn’t working and come up
with alternatives.
This person should have strong skills in
project management, leadership,
facilitation, and relationship building. The
team lead should also be familiar with the
business division, the products, as well as
supply-chain analysis principles and
metrics. On rare occasions, the team lead
In practice, having a mentor often
proves to be an invaluable asset to the
team lead. This person should have
experience in completing similar exercises
in the past. As we discussed, the mentor
is unlikely to be fully dedicated to the
project; however, she or he should be
able to provide a high level of
responsiveness for the team lead as a
coach and reviewer.
Finance Lead/Modeler
At some point, it often makes sense to
complete the quantitative analysis using a
spreadsheet. The modeler, usually the
finance lead on the project, is someone
who has hands-on experience designing
and building spreadsheet models. This
person will definitely be required if the
team decides to move beyond a costdriver analysis into financial modeling.
2.2 Tasks
Obtain Sponsorship
Successfully evaluating commonality
and reuse opportunities requires strong
cross-functional sponsorship. In our
experience, even alternatives that are in
the best interest of HP can sometimes run
counter to functional metrics such as
material cost, time-to-market, and
product functionality. You will need a
strong sponsor to help you marshal
resources and overcome resistance.
Version 8
Page 12
Define Project Scope

As with any project, you should clearly
define the objectives, scope, and
deliverables. If possible, it is good to
define the decision being made and the
alternatives being considered.
Although it may seem obvious, it is
important that, for each situation, the
project lead understands who will be
making the particular decision and what
his or her criteria will be. This will drive
how you should conduct and present the
qualitative and quantitative analyses.
Remember, the decision maker’s criteria
must be respected. That person owns both
the responsibility of the decision and (we
hope) the resulting consequences.
• Who makes this particular
decision?
• What criteria will they use?
• What qualitative cost factors exist
that could “trump” quantitative
cost savings?
• Are there any immovable
constraints?
• What role do risk assessments and
technology strategy play in
commonality decisions?
• Are people being asked to make a
decision that goes against their
personal performance metrics?
• Who should be on the team?
• Who should review the outcomes?

Consulted: Group or individual who
provides information that may
affect the task or decision.
Informed: Group or individual who
is informed about the task or
decision
For each task there should be exactly
one accountable role, and one or more
responsible roles. As you progress through
the various steps in this decision process,
you may want to revisit the RACI and
decide whether the roles are still
appropriate.
Problems and Solutions
Retrospective Analysis?
With commonality and reuse, people
sometimes wonder whether they should
apply the process retrospectively and
evaluate a past decision. Although this
can be instructive and useful, we believe it
also carries the risk of creating bad
feelings and undermining your ultimate
objectives. If it is done at all, be
diplomatic and constructive. Otherwise,
people may get the sense that time is
being wasted or that someone is trying to
settle an argument. When faced with this
situation, you should ask: “What will our
organization do with the results of this
retrospective analysis?” You may find that
it is better to start with a current decision
that is more politically palatable.
Be Opportunistic
Specify the RACI
One project tool that we have found to
be especially useful is a RACI chart. An
acronym for Responsible, Accountable,
Consulted, and Informed, a RACI chart is
a simple tool for assigning cross-functional
roles and responsibilities for specific tasks
or decisions.

Responsible: Group or individual
who will actually do the work
required to complete the task.

Accountable: The individual who is
accountable for ensuring that the
task is completed correctly (“the
buck stops here”).
In some analysis projects, the original
question turns out not to be worth
pursuing, but along the way other
questions occur that are more profitable.
For example, the CIP team originally
sought to create a common paper tray
because the paper tray had identical
functionality across most products.
Although cost savings were possible,
commonality had a significantly negative
impact on industrial design (ID). The team
therefore switched its focus to items less
visible to consumers, such as ASICs,
power supplies, and PCAs.
The lesson is: Don’t require that your
original question necessarily bear fruit.
Version 8
Page 13
Just because an idea looks promising
doesn’t guarantee that it will be feasible.
There is value in approximating the costs
for a particular decision. In the case of the
paper trays, CIP management was able to
assess whether the less tangible value of
ID seemed more important than the more
tangible supply chain costs. Additionally,
even if an idea is not worthwhile now,
your work may serve as the basis for
something else down the road. Therefore,
try to maintain an opportunistic mindset
throughout so that you can pursue other
avenues as they crop up.
Know When to Stop
Sometimes, you don’t need to go
through the entire “process” to reach a
decision. This guide has structured the
commonality and reuse process into a
series of decision points. After any one of
these points, you can make a “go/no go”
decision.
Version 8
Page 14
3
Product Chunking
This chapter deals with the first step of
the detail-level analysis, which is to group
the components within your products into
the major physical building blocks, often
called “chunks.” (For information and
processes on defining chunks, see Product
Design and Development by Karl T. Ulrich
and Steven D. Eppinger, Chapter 9 (2004
Third Edition). These chunks can then be
investigated to look for commonality and
reuse opportunities.
In some cases, however, this step may
not be necessary. For example, if you are
asked by management to evaluate a
particular subassembly or component, you
can probably proceed to the next step,
cost-driver analysis. On the other hand, if
a new product is being developed (or the
team has concerns about priorities), it
may make sense for you to proactively
identify the best opportunities for
commonality and reuse.
Attempting to pursue commonality at
the lowest component level would be
prohibitive in terms of effort. Dividing the
components into the right groups can be
challenging, and will require initiative and
creative thinking. For example, some
opportunities occur by combining current
subassemblies or considering common
tooling.
The figure below shows the high-level
process for product chunking (including
typical participants). Although it is shown
sequentially, you should expect to iterate
among the steps in this chapter to
complete the chunking phase. In other
words, discoveries made during a later
step may cause you to re-visit some
analyses or categorization made in an
earlier step. A certain amount of
refinement is part of the process.
Step 2a
Identify
product
chunks
Step 2b
Determine
feasibility of
commonality
and reuse
Step 2c
Prioritize
chunks for
further
analysis
Core
team
Core
team
Decision
Maker
Architects
R&D
engineers
Core
team
As we will describe below, the first step
is to identify a set of design chunks that
are used across products and across
generations. Then, work with the
engineers representing these chunks to
understand the feasibility of making some
or all of these chunks common or reusable. Finally, prioritize chunks for
further evaluation based on the core
team’s assessment of the difficulty of
making the chunks common or re-usable
(as approved by the decision-maker)
As shown in the figure above, you will
be seeking input from a variety of people
during this phase, including industrial
Version 8
Page 15
designers, electrical and mechanical
engineers, and other subject-matter
experts. A few general hints to keep in
mind during this phase are:
• Keep meetings small and
focused. Don’t try to get everyone
in a room at one time. Too many
engineers can lead to endless
discussions.
• Keep discussions bounded and
grounded. You will receive more
meaningful answers when you ask
specific questions instead of
•
general ones. Rather than asking
“What if we had more common
electronics?” ask “What if we made
this PCA common across both allin-one and single-function
printers?”
Present R&D with technically
feasible options. Getting buy-in
from this group will be easier if you
can prove you’ve already done
your homework. For example, have
1:1 discussions with the architects
to formulate the alternatives.
3.1 Identify Product Chunks
A chunk describes a set of components
that perform a specific function. For
example, one of the functional design
chunks identified for printers was the
servo/motor, which provides mechanical
power for moving the print head. Within
each motor might be dozens of sub-parts:
screws, cables, molded casings, low-level
electronic sensors, and so forth. Pursuing
a “plug and play” approach to the motor
might work by treating it as an option that
could be added to any printer in the same
product line.
Commonality and reuse would require
taking the motor into account in all future
product designs, and making sure that the
motor itself is designed in such a way that
it can handle the functional, spatial, and
aesthetic requirements of additional
products, including both current and
future printer models.
You may need to do several iterations
to find the most useful groupings. You
may re-define what constitutes a chunk
based on what turns out to be feasible.
However, by the time you exit the
chunking phase, you should have a fairly
solid idea of how to structure your
analysis.
Inputs
For this step, we advise starting from
something like a Bill of Materials (BOM)
and then having a few brainstorming
meetings with design engineers from
different disciplines. Try to ensure that
every part is covered, i.e., every part is
assigned to a chunk, without overlap.
Whom to Involve
For many HP products, it makes sense
to consult with a mechanical architect and
an electrical architect. You need people
who thoroughly understand the structure
of the products, what the dividing lines
are, and how the product is assembled.
Involving architect-level expertise will also
help to achieve credibility later on. It may
make sense to work with each architect
separately, and then bring them together
to validate the chunking.
Functional Design Chunk
Brainstorming Questionnaire
The goal of this exercise is to identify a
master list of chunks that could possibly
be common or re-usable across products.
If the product architecture is modular, it
will be relatively easy to identify the
chunks. On the other hand, if the product
architecture is integral, it may be difficult
to identify the physical boundaries
between chunks. You may need to create
arbitrary distinctions. In either case, do
the best job possible by asking questions
such as:
• What are the major physical
building blocks of our products?
• How do these chunks vary across
the product line?
Version 8
Page 16
•
•
•
How are these chunks expected to
change over time?
What is the rationale for the
variation?
Can you separate out elements of
the chunks that are—or could be—
common?
components that are in each chunk. Then
ask them where these circles would be on
another product.
Outputs
Problems and Solutions: Getting
Engagement from Architects
You may have difficulty getting
engagement from some architects,
especially if they don’t “get” the
commonality concept right away, or have
their own mental models of how particular
components should be designed. If
possible, try to find someone from the
design area who has already bought into
this way of thinking, or who has worked
with HP’s DfSC or Strategic Planning and
Modeling (SPaM) groups.
You may find that presenting the
architects with product diagrams will help
them better understand your questions.
Present some exploded drawings to show
what the products look like now. Ask the
engineers to draw circles around the
Chunk
Carriage board
Main Logic Board
Digital ASIC
Analogue ASIC
Power Supply
Sensors
Control Panel
Servo/Motors
Chassis
Case Parts
Service Station
Paper Path
Carriage
IDS
Trays
Carriage Flex
Main Wiring Harness
Cables (other)
Electrical Components
Firmware
Writing Systems
The output of this step is a listing of
design chunks. This list may change based
upon the outcomes of later steps.
However, because most product
architectures stay relatively consistent
from one generation to the next, this
analysis need only be repeated
periodically. In fact, if a commonality
option requires a new architecture, it
probably won’t make economic sense on
its own.
Output Example
As an example, here is the list of
functional design chunks that were
identified when assessing commonality
possibilities among the all-in-one (AiO)
printer, the PhotoSmart printer, and the
single function printer.
Description
Provides carriage logic, which controls pen behavior
Provides printer logic, which controls everything else
Printer’s digital brain, which manages logic
Printer’s analog (dynamic) brain, which manages logic
Converts AC power to DC input power
Analog or digital, signal used to trigger a particular behavior
Assembly of switches, displays, and plastic housing
Provides mechanical power
Structural component that links main system chunks
Aesthetically pleasing parts that wrap everything up
Provides maintenance to the print cartridges
Moves media from an input location, past the print head, to an output location
Holds print cartridges and provides datum for ink delivery algorithms
Ink delivery system – refers to the mode used to deliver ink, could be tubes, foam, etc.
Holds media in both pre-use and post use positions
Connects carriage board to the main PCA
Connects other EE components (typically control panels and other boards) to the main PCA
Miscellaneous cables used to connect motors and other stuff
Other electrical components worth considering outside of a specific chunk, such as the LCD
Internal software
Algorithms that control pen and paper movement behavior
Version 8
Page 17
•
•
Exit Checklist
How do you know when you can move
on? We recommend ensuring that:
All BOM items are accounted for.
Participants agree on initial list of
design chunks.
3.2 Determine Feasibility for Making Each
Chunk Common or Re-usable
After asking what could be common in
a theoretical way, the next step is to
figure out what it would take to implement
that commonality, and to assess whether
that is really feasible in terms of cost,
logistics, and other factors.
Even if it is possible, it is not always
desirable to make every design chunk
common. For example, marketing may
want to retain a visually distinctive
product appearance. Therefore, industrial
design is often a constraint on the
commonality of chunks such as case parts
and paper trays. For some chunks, it may
be obvious even at this point that
commonality and reuse are not justified.
This step opens possibilities for
innovation in design, either now or at
some point in the future, based on
functional similarities that enable
commonality across platforms.
Inputs
For this step, we advise starting with
the list of chunks, including how they vary
across products and generations. You may
also find it useful to have schematics of
these products for reference.
Whom to Involve
At this stage, you should involve
designers rather than architects, because
you are interested in functional details.
Include:
• Electrical engineers (electrical
functionality)
Part Commonality Process Guide
•
•
•
Mechanical engineers (mechanical
functionality)
Industrial designers (appearance)
Supply-chain engineers
(operational constraints)
Feasibility Checklist
The checklist for this step (shown in
Table 2) lists some features that would
make a design chunk an attractive
candidate for commonality or reuse.
It probably won't be effective to make
chunks common or to reuse chunks that:
• Improve significantly in each
new generation. If the
functionality improves, it's unlikely
that it will be reused. Investing in
reuse would be a waste of money.
• Perform a core function that is
specific to one product. For
example, fax and scan modules are
unique to AiO products. Likewise,
some exterior parts physically
differentiate products from each
other. After all, if every chunk were
common, all the products would
identical.
• Form the “glue”. These chunks
are the physical and electrical
connections that tie a product
together. Almost by definition,
these must be customized for each
product.
Version 8
Page 18
Table 2: Feasibility Checklist
Item
Notes
High-value chunks with long lead times
Unique chunks have a big impact on inventory-driven
costs and reduce the ability to respond to mix or volume
demand surprises.
High development costs, time, and risk
Unique chunks squander limited resources for
designing, testing, and qualifying. Problems here can
jeopardize product launches, resulting in poor customer
satisfaction, lost sales, and lost market share.
High tooling costs
Tooling is one of the most significant fixed costs that
can be influenced by commonality. Unique chunks may
prevent amortization of tooling investment across large
unit volumes.
Feasibility Questionnaire
When interviewing your experts to
identify potential designs that could be
made common, here are some questions
to ask:
• What’s in this chunk?
• What do all the parts in this chunk
actually do?
• What would it take to make this
chunk common?
• If this chunk can’t be made
common, are there pieces within it
that could be separated out (to
create a new chunk) and made
common?
• What if we “over-design” the chunk
to provide a higher potential for
reuse? For example, by leaving
enough space in an enclosure, it
may be possible to accommodate
the larger power supply or cooling
fan that may be required in the
future.
Why Should we Make this Part
Unique?
It may be helpful to change the
question you are asking engineers.
Instead of asking, “Should we make this
part common?” you may want to ask,
“Why should we make this part unique?”
In other words, start with the premise
that all parts should be common, and then
go through and determine which ones
really need to be unique.
Below are five typical reasons for
making a part unique.
1. It is a “touch” part, and customers
have different requirements. If the
part comes in direct contact with
any of the five senses (sight,
touch, hearing, smell, taste),
customers might have different
needs and preferences in those
areas.
a. Sight: colors, styles, shapes,
graphics, languages, etc.
b. Touch: different tactile feels,
larger/smaller buttons desired,
different sizes to fit different size
bodies, etc.
c. Hearing: different volume levels,
different tones / frequencies
desired
d. Smell & taste: bad fumes, toxic
if eaten, (probably not big
factors for most HP products).
2. The part directly impacts the ability
to meet performance
specifications. Examples include
Version 8
Page 19
processor speeds, memory size,
reliability, etc.
3. End markets have different
regulatory requirements or
standards that affect the part. For
example, UL vs. CE marks, FDA vs.
European medical requirements,
8.5 x 11 vs. A4 paper, 110 V vs.
220 V, U.S. vs. European
environmental standards, etc.
4. The part is not expected to meet
future requirements. For example,
it will be discontinued or difficult to
buy in the future, it won’t meet
future regulations, or it falls below
changing internal standards for
quality or ease of repair.
5. HP wants to segment the market
by differentiating products to serve
various price points. Although
customers may want a “Cadillac at
Chevrolet prices,” companies often
design less-expensive components
to serve lower-end markets.
Problems and Solutions: Current
versus Potential Chunking
It is important to remind engineers that
“commonality” here is a functional
definition, which may be different from
what the component currently looks like.
As we’ll explore in the next section, a
significant enough cost savings may
justify physically redesigning some chunks
to achieve commonality or reuse.
Exit Checklist
How do you know when you can move
on? We recommend ensuring that:
• You understand which chunks
could feasibly be made common.
• You know what it might take to
make each chunk common.
• You have prioritized the chunks
according to which seem to present
the greatest opportunity for
commonality and reuse.
3.3 Summary of Product Chunking:
Time, People, and Questions
One meeting each with a mechanical
architect and an electrical architect.

What are the major physical
building blocks (“chunks”) of our
products?

How do these chunks vary across
the product line?

How are these chunks expected to
change over time?

What is the rationale for the
variation?
One meeting with the mechanical and
electrical architects together

Are all BOM items accounted for?

Does everyone agree on the initial
list of chunks?
A series of separate meetings with 3
design experts for each chunk (industrial
design, mechanical, and electrical)

What’s in this chunk and what do all
the parts do?

Which chunks could be made
common?

What would it take to make the
chunks common?
Version 8
Page 20
4
Cost Driver Analysis
By the time you reach this point, you
should have either:
1. A list of design chunks which
could conceivably be shared
across products and
generations, or
2. A specific common or reuse
decision to make.
Your next task is to characterize and
prioritize the relevant cost drivers. The
cost drivers that are both important and
quantifiable can then be estimated in
order to facilitate decision-making. As
discussed in the next chapter, you may
also decide to formalize the analysis using
a financial model. A detailed explanation
of conducting a cost driver analysis can be
found at:
http://dfsc.corp.hp.com/techniques/costdr
ivers.html. We encourage you to spend
some time familiarizing yourself with the
resources on this site. In addition to a
definition of the major cost drivers, the
site includes a description of the
qualitative factors to consider, detailed
instructions on calculating the cost drivers
(including formulas, data you’ll need,
people to ask for assistance), as well as
sample spreadsheets and an example cost
driver analysis for a commonality decision.
The flow of a typical cost driver
analysis, including typical participants, is
shown in the figure below. We find that it
usually takes 2 to 4 weeks to complete a
cost driver analysis. Just as with the
chunking phase, you can expect to iterate
among the steps in this chapter.
Discoveries made during a later step may
cause you to re-visit some analyses or
decisions made in an earlier step.
Step 3a
Summarize
issues &
evaluate
qualitatively
Step 3b
Prioritize
cost factors
Step 3c
Perform
rough-cut
analysis
Step 3d
Evaluate
sensitivity &
validate
assumptions
Step 3e
Present
results
(extend
analysis?)
Decision
maker
Core
team
N PI lead
Core
team
Decision
maker
Core
team
Finance
lead
Extended
team
As described in more detail below, the
team first brainstorms the pros and cons
of the particular alternative (perhaps as
informed by the chunking exercise). Next,
for the issues that are important and
quantifiable, the core team prioritizes the
cost factors for consideration. The NPI
lead and the finance lead then perform a
rough-cut analysis, working with the core
and extended team to gather data. Next,
Core
team
Extended
team
the core team evaluates the sensitivity of
certain parameters and validates the
assumptions that turn out to be critical.
Finally, the core team presents the
results, and a decision is made either to
select an alternative or extend the
analysis using financial modeling.
Version 8
Page 21
Problems and Solutions: Coordinating
Calendars
Because you will be dependent on other
people’s schedules when conducting a cost
driver analysis, you should reserve time
on their calendars as far in advance as
possible. At a minimum, this includes the
decision-maker, the core team members
(including your finance lead), and
critical/influential extended team
members. Your success and business
impact will suffer if you don’t have the
perspectives of these key people.
4.1 Summarize Issues & Evaluate
Qualitatively
After defining the decisions and
alternatives under consideration, you
should conduct a brainstorming meeting
(usually half a day) with the decisionmaker, core team, and extended team.
The objective is to identify the pros and
cons of each alternative. We recommend
that you evaluate each alternative relative
to the cost drivers shown below and
described on
http://dfsc.corp.hp.com/techniques/costdr
ivers.html. By becoming familiar with this
website, it will be easier to identify the
important factors. In addition, you’ll be
able to refer core and extended team
members to the reference, helping them
get up to speed and avoiding prolonged
discussions about how to estimate the
costs. Much of this hard work has already
been done for you.
Priority
High
Pre Launch
- TTM & lost margin
- Design & NRE
Production
- Material
- Inventory
EOL
- Service parts inventory
Med
- Tooling
- Prototype
- Qualification
- Assembly, test, & rework
- Expediting
- Warranty & service
events
Low
- PN and supplier
management
- Freight & packaging
- Tax, duty, royalties
- Take back &
environmental
Although we have prioritized these
drivers based on aggregate impact over a
sampling of commonality projects, you
and your team should always evaluate
each cost qualitatively to ensure that
these priorities still hold true for your
particular decision. Please note that these
priorities relate to the magnitude of the
difference between the common and
unique alternatives. In other words, if a
particular cost is high but nearly identical
across common and unique parts, that
cost category may be prioritized as a
“Low.” In such a case, it probably won’t
be worth the effort gathering the data and
estimating the costs – the results won’t
drive the decision one way or the other.
High Priority Costs

TTM & lost margin: Any delay in the
product’s introduction will result in
delayed and/or lost sales. If the R&D
team decides to reduce product
functionality (and list price) in order to
maintain schedule, the result may be
lower margins and/or reduced unit
sales.
Version 8
Page 22




Design & NRE: Design cost is usually
comprised of two elements: design
engineer salaries and NRE (nonrecoverable engineering) costs. Design
costs can decrease if reuse or
commonality reduces the number of
new parts needed. On the other hand,
design costs can go up if existing parts
must be re-designed to accommodate
commonality or future reuse.
Material: Material costs are often a
major driver when comparing DfSC
alternatives. Commonality and reuse
usually either increase or decrease
material costs depending on whether
the higher-cost part is “downward
substituted” or the lower-cost part is
“upward substituted.”
Production Inventory: This cost
driver includes the inventories needed
to produce the products, both in
anticipation of demand during ramp,
and to satisfy demand thereafter. With
common parts, you can hold fewer
inventories while still achieving the
same service levels. With reused
parts, the inventory-driven cost rate
can be lower, because obsolescence is
less of an issue.
Service Parts Inventory: Products
that serve enterprise customers must
be supported by a service parts
network. Customer contracts include
service windows for replacing failed
parts, which may be as short as 4
hours for critical items. Achieving
consistently fast customer response
times requires that spare parts
inventory be stocked at hundreds of
field locations close to customer sites.
By moving from two unique parts to
one common part, for example, field
inventory is often cut in half.
Medium Priority Costs

Tooling: Tooling can be a significant
pre-launch cost, often in the millions
of dollars. Reuse of parts—and the
associated tooling—eliminates these
costs. Commonality can also avoid the
cost of under-utilized unique tools.

Prototype: By re-using a component,
inexpensive production materials can




be used to prototype new products. In
other words, expensive, custom
prototype parts are not required.
Qualification: Qualification includes
mechanical and electrical testing, HALT
(Highly Accelerated Life Testing) and
other reliability testing, safety and RFI
emissions certification, and DVT/MVT
(design and manufacturing verification
tests). Component reuse offers
qualification savings for both cost and
design time.
Assembly, Test, and Re-work:
Commonality can have an impact on
assembly, test, and re-work if labor
rates, times, and/or yields are
different.
Expediting: Expediting includes the
freight, handling, and overtime costs
associated with replenishing inventory
after an upside demand surprise. The
most significant cost is often the air
freight charges from Asia of large and
heavy items (e.g. enclosures) in order
to meet delivery schedules.
Warranty and Service Events: This
driver includes material costs and
support costs involved in replacing
installed parts that have failed.
Support costs are influenced primarily
by how often a part needs to be
repaired—represented by annual
replacement rates (ARR)—and how a
repair is performed—either by the
customer (involves call center,
shipping/courier costs), or by HP
Services or a channel partner (involves
call center, technician labor, and travel
costs).
Low Priority Costs

PN and Supplier Management: This
includes all of the indirect costs of
managing part numbers and suppliers.
Part number management includes
setup, maintenance, removal, and IT
costs. Supplier management includes
procurement, planning, and
purchasing. Commonality may reduce
the effort (either through direct
headcount or, more likely, through
contractors) if parts and/or suppliers
are eliminated.
Version 8
Page 23



Freight and Packaging: Freight costs
are important if there is a significant
size or weight difference between the
common part and the unique parts.
Packaging costs could be reduced if
commonality also eliminates unique
packaging.
Tax, Duty, and Royalties: Tax
benefits are usually derived from
manufacturing the product in taxfavored countries such as Singapore or
Puerto Rico. By manufacturing within
certain other countries (e.g. Brazil,
India), it is also possible to avoid
inbound duties. Royalties must be paid
to the suppliers of certain products,
such as software. Depending on the
situation, commonality may avoid
some of these costs or achieve some
of these benefits.
Take-Back and Environmental: This
factor is not often considered, but is
becoming important in Europe. It’s
possible that re-usable and common
parts will have a more significant
after-market demand.
Inputs
For this step, you can start with the
decision and definition of the alternatives.
Whom to Involve
Because this is a brainstorming session,
you should pull together a cross-functional
team including the decision-maker, core
team, and extended team (design,
marketing, supply chain, procurement,
distribution, support, finance, etc.) You
will want to include people who can
appropriately represent each of the cost
drivers, especially those of high and
medium priority. Ideally, your finance lead
will be able to participate in order to
prepare for the upcoming analysis.
Someone on the core team should be
responsible for capturing the issues and
synthesizing them for distribution.
Outputs
The list of the pros and cons for each
alternative relative to the cost drivers.
4.2 Prioritize Cost Drivers
Based on the results of the
brainstorming session, you and the rest of
the core team should meet for a few hours
to agree on which costs to prioritize for
further analysis. This step will help you
achieve an appropriate balance between
costs that are important and costs that
can be quantified. As a team, you don’t
want to waste time analyzing factors that
are unimportant, or put undue focus on a
limited number of drivers such as material
and inventory costs only. When in doubt,
it is probably better to err on the side of
including a factor. We usually drop only
those factors that everyone in the
brainstorming session agrees are
irrelevant. The next step will allow you get
a better feel for the magnitude of the
importance.
Important costs that are difficult to
quantify should be evaluated qualitatively,
perhaps by verifying and extending the
pros and cons identified earlier.
Inputs
The results of the brainstorming
session and other input from the extended
team
Whom to Involve
This step involves the core team.
Outputs
A prioritized list of cost drivers,
including an assessment of which are
quantifiable, how you might calculate
them, and what data you will require.
Version 8
Page 24
4.3 Perform Rough-Cut Analysis
Working with your finance lead,
perform a rough-cut analysis on the
prioritized cost drivers. See
http://dfsc.corp.hp.com/techniques/costdr
ivers.html for detailed instructions. This
step usually takes about two days over
the course of a week.
Your objective for this step is to get a
sense for which factors and assumptions
really are the most important in driving
your decision. This understanding will help
you focus your energies in gathering data,
refining your analysis, and performing
sensitivity analyses.
Inputs
The qualitative assessment of the
extended team, the prioritized list of cost
drivers, data as collected from across the
business, and calculation techniques from
the DfSC website.
Whom to Involve
This step involves you and the finance
lead, with the help of the core and
extended team to collect data.
Outputs
A first-pass analysis of the alternatives
for each of the prioritized cost drivers.
Problems and Solutions: Experience
Curves
Sometimes you may want to prioritize
parts from among a long list before
performing a cost driver analysis. In this
case, the concept of experience curves
may be useful. For more information, see
http://dfsc.corp.hp.com/techniques/costdr
ivers.html and click on “material” (in “High
–Production” cell).
Just as you can use these curves to
estimate reductions in supplier material
prices as unit volumes increase (via
commonality/reuse), you can apply them
to total part costs across the supply chain
and product lifecycle. In other words, you
assume that all the costs—material,
design, tooling, inventory, expediting,
service parts, etc.—decrease in aggregate
at a constant rate per doubling of volume.
Because there are many assumptions
embedded in the “rate per doubling” that
you choose, we believe you should next
perform a cost driver analysis on the
highest priority parts. Otherwise, you will
lose granularity and risk oversimplifying
your commonality or reuse decision.
4.4 Evaluate Sensitivity & Validate
Assumptions
This step is one of the most important
in a cost driver analysis. Focusing on the
costs that drive the analysis, you should
critically evaluate the data and
assumptions that you used, and perform
sensitivity analysis on the input variables.
This will help both you and the decisionmaker to feel comfortable about the final
recommendations.
For example, the results of the roughcut analysis may be driven by a time-tomarket delay of 1 week, and a material
cost difference of $10 per unit. It’s
important to test the robustness of the
answer by recalculating the costs using
different, but feasible assumptions.
 Could an additional engineer eliminate
the time-to-market delay?
 What if the delay is 2 weeks instead of
1 week?
 What if you are 1 week earlier to
market?
 What if the material cost difference is
only $5 per unit?
This step is about two days’ worth of
work that usually occurs over the course
of a week. However, you may be able to
do steps 3c and 3d simultaneously in
order to save some time.
Version 8
Page 25
Inputs
about a day; this allows you and the
finance lead enough time to gather
additional data and recalculate the costs.
The first-pass analysis and feedback
from the core and extended team on the
important cost factors.
Outputs
Whom to Involve
Validation of the most important
assumptions, a sensitivity analysis of the
key parameters, and a recommendation
as agreed to by the core team.
After performing some initial sensitivity
analysis, you will probably want to have a
couple of 2-hour meetings with the core
team. It is good if these are separated by
4.5 Present Results
After organizing your analysis into
some presentation format, you should
review it with the decision-maker and
extended team. Don’t forget to include the
qualitative assessments – they are often
just as important as the quantitative
results.
It is during the presentation that you
will be reminded of the value of having
core team members who are respected by
the entire organization. When tough
questions come up during the
presentation (which they will), you will be
backed up by people trusted by the
decision-maker. If, for whatever reason,
you don’t have these key thought leaders
on the core team, don’t despair. At some
point before the presentation, meet with
these few people one at a time, together
with your finance lead, and step through
your results. Understand their concerns
and make sure you follow-up on any
issues they raise.
One of three things usually happens in
these main presentation meetings:
1. A decision is made.
2. A tentative decision is made, pending
follow-up on a few questions and
recalculation of a few numbers.
3. The decision is “too close to call”
based on the cost driver analysis, but
making the right choice is important to
the organization. The decision-maker
sponsors a subsequent project phase
to model the financials in more detail.
Inputs
The cost driver analysis, including
qualitative factors, as well as the
estimated costs and sensitivity analyses.
Whom to Involve
The decision-maker, core, and
extended teams. Depending on the
complexity of the decision, you will
probably want to schedule a 1 to 2 hour
meeting.
Outputs
A decision (perhaps pending some
follow-up) either to close the project or
extend it to perform financial modeling.
Version 8
Page 26
5
Financial Modeling
In this chapter, we provide guidelines
on developing and validating a financial
analysis model. As described above, this
step is usually conducted if three
conditions are met:
1. Management is not able to make a
decision based on results from the
cost driver analysis,
2. Making the right decision is
important and valuable to the
organization, and
3. The most significant open issues
relate to quantitative (versus
qualitative) factors.
You should know, however, that
building a financial model is no small
undertaking. It typically requires 2 to 4
months of effort by a core team of about 3
people at 30% to 50% time (a project
lead, a financial analyst / model builder,
and a supply chain engineer). The
commitment of the extended team must
also increase (to about 15%), because
much more data and validation are
Step 4a
Architect
and build
model
Step 4b
Gather data
and
validate
base model
cost driver analysis (steps 4d and 4e and
much of step 4b), we won’t repeat
ourselves. Instead, we’ll focus on the
important differences that you should
consider. If you decide to create a
required. It also requires additional review
meetings with the sponsor.
In special situations, the team may
also decide to build a generic analysis
“tool.” This is a type of financial model
that is expected to be reused for analyzing
similar decisions in the future. However,
before making this level of investment, we
would encourage you to perform several
analyses using only cost drivers and, if
necessary, custom financial models. In
our experience, it is very difficult to build
a tool that is flexible and robust enough to
analyze a sufficient number of future
decisions to justify the investment. When
they are actually built, such tools are
usually extremely complex and require
significant data and skills to use. As a
result, they may be applied
inappropriately and become mistrusted by
management and R&D.
A high-level process flow is show
below. Because several of the steps are
similar to the
Step 4d
Evaluate
sensitivity &
validate
assumptions
Step 4e
Present
results
(extend
analysis?)
reusable decision tool, additional steps are
required, including requirements
gathering, quality testing, and user
training. Please contact SPaM for more
information http://spam.corp.hp.com.
Version 8
Page 27
5.1 Architect the financial model
At this point you’re ready to begin
building your model. During the course of
this exercise, you may find it necessary to
re-visit some of the cost drivers and their
characterizations from the previous phase.
Although the costs and benefits of
some commonality decisions will be
obvious after completing the last step,
some teams will decide that they must
build a more detailed financial model.
Such a model goes beyond simply putting
the cost driver analysis in a spreadsheet.
A financial model considers more realistic
calculations of—and interactions
between—the various costs that are
particular to your situation. A decision
support model will make it easier for you
to effectively and appropriately compare
each alternative. A financial model is
especially required if the team believes
that some of the simplifying assumptions
made by the cost driver analysis are
invalid for your situation.
Desirable Model Characteristics
We recommend that your model have
the following features:
• Scenario-based. A “scenario” is
essentially a re-creation or
simulation of a particular set of
circumstances. Some scenarios use
the same variables with different
values. Others turn “on” or “off”
particular variables or alternatives.
Scenario analysis allows you to
compare and contrast the
outcomes and test how sensitive
your costs are to different
assumptions.
• Simple to use. Your analysis will
be more readily accepted by
management and the extended
team if they can understand the
model, and even use it to test out
some of their own scenarios. Ease
of use is especially critical if you
have decided to develop a tool and
want to achieve broad acceptance.
•
Easy to modify. Give yourself
flexibility for making changes and
upgrades. If you don’t, you'll be
doing a lot of time consuming
rework. In the course of your
analysis, you’ll discover changes
that you’ll want to make to the
model. To enable flexibility, we
recommend that you make the
calculations as modular and
intuitive as possible. Not only will
this reduce the chance of
calculation errors, it will also save
you time in the end. Tightly
interwoven formulas using hard
coded variables and cell numbers
(instead of names) can be nearly
impossible to untangle and modify.
Example Financial Model
Over a period of two years, CIP
developed advanced commonality
decision-making capabilities. It conducted
product chunking sessions, performed
several cost driver analyses, built multiple
financial models, and finally created a
reusable decision tool. The tool is specific
to common versus unique decisions for
inkjet printers and can be applied across a
broad range of product families (e.g.
single function, AiO, and PhotoSmart) and
part types (e.g. power supplies, paper
trays, PCAs, and LCDs). We’ll describe it
here in some detail, because it provides
an excellent example of how to architect a
financial model, whether or not you decide
to formalize it into a tool.
The CIP tool is a set of Excel
spreadsheets that convert user-entered
data for part-selection scenarios into total
cost comparisons. It also has sensitivity
analysis to ensure robustness of the
recommendations.
The primary user of the tool is the
supply chain analyst who created it,
though other users include production
engineering, procurement, design
engineering, and design-for-variety
Version 8
Page 28
analysts. The users are scattered across
regional sites in North America, Asia, and
Europe.
Tool Re-Usability
The tool consists of four main
spreadsheets:
• Input. This portion includes direct
material cost, engineering resource
investment, outsourcing costs, and
planned production volumes for
each alternative.
• Intermediate Calculations. This
portion allows the user to identify
which unique parts can be
combined into common parts. It
also contains default values for
WOS, scrap, salvage value, and
inventory-driven cost rate.
• Sensitivity. This spreadsheet
allows users to perform sensitivity
analysis on the default values,
including product volumes, direct
material cost, inventory
management plans (WOS and
scrap rates). It also considers the
impact of expediting components
via air shipments as opposed to
slower methods of transport.
• Results. This spreadsheet shows
the resulting costs of the various
scenarios.
Some readers may wonder whether
they can reuse models from other
projects, although these models were only
intended for a one-off analysis. As we
mentioned above, model reusability is
difficult to achieve even if the team sets
out to build a tool. Generally, our
experience suggests the calculations of
most models end up being quite different
from one another. Rather than frustrate
yourself trying to adapt another project’s
model for your needs, most likely you are
better off doing a quick prototype and
then developing your own custom model.
Of course, we encourage you to learn
from other people’s models. This is very
instructive, and we do it ourselves.
Whom to Involve
During financial modeling, you will want
to maintain a similar core and extended
team structure. The members should be
selected depending on the cost factors
that are most important to evaluate. In
addition, if you are building a tool, you will
want to work closely with the potential
users. Firstly, their feedback will help you
develop something that is easier to use.
Secondly, the experience of interacting
with multiple users will help you
understand whether the decisions and use
cases are similar enough to enable the
successful creation of a reusable tool.
5.2 Validate the Base Model and Assumptions
For model development, you will most
likely go through a crude prototyping
stage and then a second round for
refinement. Ideally, you should build a
base model that is similar to the current
situation so you can compare the results
with actual business financials. This allows
you to validate the cost algorithms and
output with the respective owners,
uncovering faulty assumptions and
incorrect formulas. For example, review
predicted assembly costs with the
production engineers and warranty costs
with the support organization. The goal is
not to simulate reality, but to get close
enough to provide you and others with
confidence in the model.
As you review the model with the
respective cost owners, you may want to
ask questions like the following:
• Are the right things in the model?
• Does our approach make sense to
you?
• Are there situations when our
assumptions become invalid?
Version 8
Page 29
•
•
Are we using the correct default
values for the variables? What is
the typical range (low value,
average value, high value)?
Are the results similar to what
you’ve experienced in the past?
After building your model and refining
your initial prototype, you will want to
analyze the decision alternatives with the
key stakeholders. If you skip this
validation step, your recommendations
may not carry much weight.
The following is a process that you
might consider:
• Use the model to analyze the initial
decision (including scenarios and
sensitivity analyses).
• Perform a walkthrough of the
model with key stakeholders. This
should include a discussion of the
assumptions and calculations.
• Perform a qualitative assessment
to ensure that the important
factors are considered. At this
stage, the team can also decide
whether it’s worth the effort (or
even possible) to model these
“important” but “hard to quantify”
drivers.
Whom to Involve in Validation
This step should involve all key
stakeholders, which typically include R&D,
marketing, supply chain, distribution, and
support.
Validate In Person
When going through the validation
process, we strongly recommend that you
have face-to-face meetings to explain the
model. Especially in the case of a tool, you
can expect some level of “thrashing.” Your
personal attention will help to contain this,
and move people past their initial
struggles and on to a sense of mastery.
In-person contact also allows you to build
partnerships and receive more useful
feedback and ideas for future
development.
Historical versus Face Validation
There are two main types of model
validation, called “historical validation”
and “face validation.” With historical
validation, the team enters historical data
and scenarios into the model, and
compares the outputs with historical
financial results. Most supply chain
modeling projects use historical validation
to check calculations and assumptions. On
the other hand, with face validation, the
team enters “typical” values and assesses
whether the outputs seem reasonable at
“face value.”
If you’re able to perform historical
validation for your DfSC analysis, by all
means do so. This will improve the
credibility of your model. However,
historical validation can be difficult with
DfSC projects because of a lack of
relevant data and comparison results. If
you’re looking at new product
architectures or new market regions, your
model assumptions and structure may not
support a historical analysis, or doing one
may not help you assess the applicability
in the new situation. With DfSC, we often
perform face validation. The key is to try
different, but familiar scenarios and ask
the core team and other experts whether
the output seems consistent with their
experiences.
Version 8
Page 30
6
Conclusion
We hope that you are able to benefit
from this process guide as you lead
commonality and reuse projects for your
business. Overall, we believe that this
process is a powerful and systematic
approach that helps people to develop
intuition around key business decisions.
With a process that everyone buys into,
you will find that decisions get made more
quickly and then “stay made.” You won’t
hear as many people say “let’s revisit this
decision one more time….” More
importantly, we find that better decision
processes lead to better decisions and
ultimately better business results. Good
luck, and let us know what you learn
along the way.
Version 8
Page 31