DFSC

HP’s Design for Supply Chain Team

Part Commonality Process Guide

Design for Supply Chain Tools and

Techniques

December 2004

Version 8

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.

Introduction......

1Overview......

How to Use This Book......

Which Products are the Best Candidates?......

Process Description......

Customizing the Process......

Time and Resource Requirements......

Learning Objectives for This Guide......

Ability to Initiate a Commonality Project......

Learning Objectives from Applying the Process......

2Project Initiation......

Core Skills......

Team Lead......

Mentor......

Finance Lead/Modeler......

Tasks......

Obtain Sponsorship......

Define Project Scope......

Specify the RACI......

Problems and Solutions......

3Product Chunking......

Identify Product Chunks......

Inputs......

Outputs......

Exit Checklist......

Determine Feasibility for Making Each Chunk Common or Re-usable......

Exit Checklist......

Summary of Product Chunking: Time, People, and Questions......

4Cost Driver Analysis......

Summarize Issues & Evaluate Qualitatively......

Prioritize Cost Drivers......

Perform Rough-Cut Analysis......

Evaluate Sensitivity & Validate Assumptions......

Present Results......

5Financial Modeling......

Architect the financial model......

Desirable Model Characteristics......

Example Financial Model......

Whom to Involve......

Validate the Base Model and Assumptions......

6Conclusion......

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.

Version 8Page 1

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-to-use 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 industry-standard parts that are common or reused.With increasing cost and time-to-market 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 re-sell 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 higher-performance 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 8Page 1

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

Version 8Page 1

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.

Version 8Page 1

Which Products are the Best Candidates?

Version 8Page 1

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 there are fewer variations to manage. Part availability will be higher with the same inventory levels, possibly even allowing for reductions in inventory.
  5. 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.
  6. 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.
  7. High material prices. By combining volumes for products that currently use different components, the cost of obtaining the new common component can be reduced.
  8. High support costs.Re-used parts often have lower failure rates—and thus lower warranty costs—because problems have 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.

Version 8Page 1

Process Description

Version 8Page 1

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.

Version 8Page 1

Table 1: Commonality and Reuse Decision Process
Step / Activities / Outcomes
1. Project Initiation / Gain sponsorship for the project, define owners and responsibilities, and clarify decisions to be made / • Project scoping
• Decisions and alternatives
• RACI chart
2. Product Chunking / Review and prioritize commonality and reuse opportunities for specific subassemblies and components (“chunks”) / • List of design chunks that could be made common
• Feasibility for each chunk
3. Cost Driver Analysis / Perform a rough-cut analysis of a particular decision or alternative (qualitative and quantitative) / • Cost factors
• Qualitative issues Quantitative results
• Sensitivities
• Relative importance
4. Financial Modeling / Perform detailed analyses of decisions, including model validation and sensitivity analyses / • Repeatable process
• Cost analysis model/tool
• Model/tool validation

Version 8Page 1

Although we will describe these four steps as a sequential process, you can take several paths depending on your project objectives. In the figure below, we show five paths that we have observed in practice, labeled A through E.

Version 8Page 1

Version 8Page 1

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 decision-makers, 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 under-utilized 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 intuition-building 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.

Version 8Page 1

Customizing the Process

Version 8Page 1

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 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.

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 supply-chain 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.

Version 8Page 1

Time and Resource Requirements

Version 8Page 1

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,

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 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.