How "Rough Cut" Analysis Smoothes HP's Supply Chain

by Jason Amaral and Brian Cargille -- Supply Chain Management Review, 9/1/2005

It’s been said that about 80 percent of a product’s cost is decided long before any metal is cut or plastic is molded. In the same way, a large part of a product’s supply chain complexity is determined right there on the drawing board.

But before anyone starts pointing fingers at the product developers, let’s look at the constraints they face. Customer expectations and competitive pressures have increased across many industries. As a result, R&D groups have less development time to achieve ever-greater product functionality. This is certainly true in the high-tech sector in which Hewlett-Packard (HP) operates. Although most designers are aware of the advantages of, say, component commonality and reuse, supply chain efficiencies are not always uppermost in their minds.

That is because most of the critical design-for-supply chain (DfSC) decisions have to be made in the early phases of the product development lifecycle. We have found that even with the support of seasoned financial analysts, the thousands of HP engineers making daily design decisions normally don’t have the time, data, or tools to perform detailed DfSC analyses. As a result, the impact of product design on supply chains is often ignored and decisions, if they are considered at all, are made using overly-simplistic functional metrics such as materials cost and time-to-market. The consequences can be severe: copious excess inventory and lost sales which, for large global companies such as Hewlett-Packard Co., can add up to millions of dollars a year.

“Design for supply chain” is not a new concept to us at HP. We have used elements of DfSC, such as postponement and commonality, in several successful projects.1 Yet DfSC has often met with resistance from product managers and designers. Our recent work, however, has led us to implement a systematic, repeatable, and broad-based approach to making design decisions and quickly evaluating whether to analyze a decision in more detail. We call this our “rough-cut” analysis technique.

HP is now diffusing this approach across the company. As a result, supply chain costs are now being considered by far more development teams than ever before. Rough-cut is easily understood and accepted by senior management and by nonengineering functions such as marketing and finance. We have found that this approach bridges the gap nicely between purely qualitative assessments and analytical model-building. It has led to less “churn” on decisions—in other words, once a decision is made, it is more likely to stay made. The success to date has confirmed our belief that rough-cut techniques for product-design decisions can help unlock hundreds of millions of dollars of benefits for companies like HP.

The Story of the Square-Hole Racks
When Hewlett-Packard and Compaq Computer merged a few years ago, HP’s supply chain managers felt the pain of a relatively minor design difference: HP’s mid-range servers used mounting racks with round holes, while Compaq’s comparable servers used racks with square holes. As a result, the combined company had to order, stock, and distribute 12 different rail kits for mounting servers to cabinet racks. HP’s customers, of course, couldn’t care less about the shapes of the holes in the racks as long as they had the right kit needed to install their product. But the rack design had a huge impact on supply chain costs over the product’s lifecycle. The eventual decision: create five common rail kits for both families of servers at an expected lifecycle savings of $32 million in reduced material and inventory costs. The customers experienced benefits as well: The same rail kits could be used across their various racks and servers.

The outcome of that seemingly insignificant decision is typical of the gains made possible by our DfSC program. It shows the opportunities that exist to improve commonality among parts and subsystems—particularly for those parts that do not differentiate a product, such the cooling fans for servers, power supplies for printers, and power cables for PCs. Parts designed for one system can be reused in new designs and can come from preapproved suppliers. (See the sidebar highlighting HP’s “six pack” of DfSC benefits.)

We have progressively tackled such opportunities across HP’s largest product units—the Imaging and Printing Group, Personal Systems Group, and Enterprise Storage and Servers Group. These efforts have saved more than $100 million since the program’s inception. The savings have come primarily from the reduced costs of materials, inventory, and packaging.

SPaM: The Roots of DfSC
HP has had a formal DfSC program for two years now, with author Brian Cargille leading the effort. The roots of the program, however, reach back into the late 1980s, when HP formed an internal consulting team—Strategic Planning and Modeling (SPaM)—and staffed it with industrial engineers and management scientists. SPaM’s job was (and is) to support strategic decision making with data-driven analyses. By 1995, the team had completed many projects that helped HP dramatically reduce inventory levels while improving order fulfillment to customers.

In the beginning, SPaM only dealt with product design as an input to the supply chain decision-making process. At that time, engineering designed the product architectures and bills of materials, which were then accepted by the procurement, manufacturing, and distribution groups. Given these fixed constraints, SPaM helped the supply chain organizations set appropriate inventory-stocking policies, reduce lead times, improve production-planning processes, and design efficient and robust supply chain networks.

However, despite these improvements, some distribution centers (DCs) inevitably had too much of some products and not enough of others as most high-volume HP products at the time were “built to stock.” The guiding sentiment seemed to be that you “have a hunch and make a bunch.” Two major projects, however, helped to quantify the supply chain benefits that strategic planning and modeling could unlock from product-design decisions.

The first project was with the DeskJet business. HP produced finished goods at a factory in Vancouver, Wash., and transported them by land and sea to DCs around the world. As unit volumes in Europe and Asia began to increase, the costs and lost revenues of having the wrong number of localized printers grew ever larger. SPaM realized that the transportation times were too long and the forecasts too uncertain for the factory to ever get it right. The big opportunity was in postponement. Despite the required changes to the product-design and the manufacturing processes, SPaM was able to show that localizing generic printers at regional DCs resulted in big financial benefits.

The second project was with the LaserJet printer, which was assembled in the United States and shipped to the various regions for localization. But even with postponement, HP faced significant inventory write-offs in North America and lost sales in Europe. The problem was caused by a key subassembly sourced from a Japanese supplier. This “engine” included a dedicated power supply (110V for North America or 220V for Europe) that had long planning, manufacturing, and logistics lead times. As a result, the number of products destined for each region had to be forecasted far in advance. In this case, the opportunity was in parts “commonality.” SPaM found that in some cases the supply chain benefits of a universal power supply more than offset the additional price charged by the subassembly supplier.

These and other DfSC projects during the early to mid-’90s were typically sponsored by supply chain (SC) organizations directly after a particularly painful product shortage and/or inventory write-down. SPaM helped senior management quantify whether the supply chain benefits of a significant design change would offset the engineering costs. Although R&D owned the decisions creating the supply chain costs, they didn’t feel the impacts because R&D was measured against product functionality, material costs, and time-to-market—not downstream inventory, logistics, or warranty costs.

SPaM’s neutrality and credibility helped convince general managers not only to allow R&D to make decisions that went against its traditional performance metrics but also in many cases, to give the function credit for acting in the company’s best interests overall. The result was to raise awareness of DfSC in the R&D community and to reinforce the need for early involvement of SC and new-product-introduction (NPI) engineers on cross-functional product-development teams. Such experiences allowed HP to capture the fundamental lessons of design for supply chain in a highly regarded series of papers and case studies.2 But there was a growing feeling that HP still wasn’t deriving the maximum benefits from design for supply chain. It was this feeling that set the stage for innovation.

Different Ways of Making Design Decisions
The turning point was a project we worked on with the high-end server division during the summer and fall of 1998. Because of SPaM’s reputation in conducting DfSC analyses, the supply chain (SC) and R&D managers jointly sponsored a project to determine the best combination of product designs and supply chain networks for a new family of products scheduled to be launched in several years. SPaM staff were being invited into the world of design decision-making; we were no longer just being asked to correct for a particular design decision that would cause significant supply chain costs.

At the beginning of the project, we spent many long phone conferences trying to identify the decision to be made and the alternatives to be considered. We struggled. Historically, SC had come to us with a very clear decision proposition—”Should InkJet printers be localized at regional DCs?” or “Should LaserJet printers use a universal power supply?” But in the server project, many sequential and interrelated decisions had to be made over the next several months.

As with most SPaM projects, we began by performing a simple analysis that captured some of the major cost drivers. Such a step helps to scope a project and focus subsequent modeling efforts on the most important issues. After much debate among members of the extended team, we decided to focus on several important decisions involving about two dozen alternative product architectures and supply chain networks. Design decisions included, for example, whether to integrate memory modules with processor modules; supply chain decisions, for example, included whether regional sites should configure servers from a preassembled “base box” or manufacture them directly from the various components and subassemblies.

As the SPaM team began the process of modeling, we started to realize just how fluid this decision environment was. Two to three weeks after our scoping meeting, we sent “data collection templates” to the development teams. In our follow-up phone calls we learned that a few smaller decisions had already been made, and several alternatives were no longer being considered. The team also asked if we could consider several new alternatives.

To try to cope with this situation, we built a flexible (albeit complex) model that allowed us to explore various alternatives and to conduct sensitivity analyses on the many assumptions that were still up in the air. During the model-building and data-validation phase, we created a set of approximate analytical techniques to determine whether the output was in the right ballpark. Were the inventory savings from commonality reasonable? Did the lower yield of the alternative memory supplier really have that much impact on the material costs? Were the correct number of assembly machines being calculated given the cycle times and batch set-up time?

As we completed the analysis, compiled the results, and documented our recommendations to management toward the end of 1998, we came to a realization. Some recommendations were surprisingly similar to the insights we generated at the beginning of the project from the simple spreadsheet. Many other recommendations could have been determined using the approximate techniques that we developed to validate the model. Although the initiative generated tens of millions of dollars of benefit—and a critical set of decisions still required comprehensive modeling—we now understood the three major ways in which most product-design decisions differ from supply chain decisions in terms of the analysis each requires.

First, in the early phases of product design, there are many simultaneous decisions and numerous feasible options, all of which must be evaluated against marketing, engineering, supply chain, and financial criteria. By contrast, most supply chain strategy projects focus on a single decision and a small number of alternatives. (Think of the decision to build a new factory, for instance.) In this latter environment, it’s beneficial to build a comprehensive analytical model to explore the alternatives and generate a robust recommendation. With DfSC, however, the many hundreds of possible design and supply chain alternatives result in a complex model that takes a long time to build (and debug), requires a lot of assumptions and data, and can become a “black box” to decision makers.

Second, most product-design decisions must be made in days or weeks, not months—especially in our high-tech sector. With strategic decisions, however, the tens of millions of dollars at stake (and the risk of being wrong) justify the three to four months required to conduct a comprehensive analysis. By focusing only on the strategic decisions in the server project, we missed countless opportunities to use data-driven analyses to answer DfSC questions that simply passed us by.

Third, most design decisions are made by R&D engineers, not managers. Yet, only managers have the authority and budget to sponsor multi-month projects using comprehensive modeling. Although engineers were now supposed to add downstream supply chain costs to their laundry list of things to consider, they didn’t have the tools or training to make day-to-day decisions. It’s one thing to know that commonality and postponement are good ideas. It is quite another to know whether one common circuit board for subassembly X is better than three unique ones. The certainty of material costs and time-to-market impacts often trumped potential, but poorly, quantified supply chain benefits.

Based on these lessons, we felt that approximate analytical techniques were just the solution that was needed for this different decision environment. Appropriately used, they would allow us to address many more decisions and know when and where detailed modeling was justified. We knew that the cumulative effects of the many day-to-day design decisions were costing HP millions of dollars a year because supply chain impacts weren’t being considered. To make further progress with DfSC, we had to reach a new client base: HP’s R&D, NPI, and SC engineers.

“Dfx’d To Death”
Now that we had a more open door to the R&D and NPI engineers, we had to develop effective ways of serving them. Not surprisingly, we learned of a widespread feeling that DfSC methods were not appropriate for their organizations. In fact, we were told that they were being “Dfx’d to death,” meaning that there was always some “design for” priority that they were being asked to factor into their work. We also found that they lacked the resources they needed to be successful in terms of DfSC. Although they had tools to quantify material costs down to fractions of a penny, they had nothing with which to identify, say, downstream inventory costs. We had to develop those tools for them.

So the next step in our journey was to take our approximate analytical techniques and extend and formalize them into “rough-cut” methods for design-for-supply-chain. By using rough-cut techniques, we make a conscious trade-off between accuracy and speed. Indeed, it is crucial that people understand the dangers of misapplying rough-cut techniques. If the situation is complex and unfamiliar or the underlying assumptions are not valid, using rough-cut approaches can lead to poor decisions and costly mistakes. When there is a lot at stake and the risk associated with being wrong is high (as identified by the rough-cut analysis), a comprehensive financial model is probably required.

In order to deliver these approaches to the development teams across the company, we put together a one-day workshop that captured our best practices related to product design for supply chain and taught engineers when and how to use the rough-cut techniques. The objective was to provide project teams with the intuition and tools they needed to make appropriate DfSC decisions. We also created a set of Web-based calculators, which we made available on the internal site.3

Since that time, we have extended our rough-cut methods to consider more than just inventory and material costs. We have developed a set of methods for commonality that include assessing financial impacts across the entire product lifecycle. Only such a broad consideration of the financial impacts would give R&D and marketing the confidence that DfSC was a holistic approach and not a one-sided evaluation of supply chain costs. Additionally, we communicated examples of when certain DfSC techniques should not be pursued.

A Closer Look at Rough Cut
Approximation techniques by themselves are nothing new. What is new is our formal development and dissemination of such techniques for use in a DfSC context.

When we began to see the real value of rough-cut analyses, we sought out the skilled supply chain and NPI analysts whom business-unit leaders recognized as having successfully facilitated DfSC decisions. We began to work with them to discover their techniques and processes. We wanted to refine and validate a set of standard techniques that would work broadly across HP in support of better decision making—particularly about commonality issues. Instead of seeking the perfect answer, those successful analysts used their experience in similar circumstances to create approximate methods for making rapid recommendations to management. We distilled their wisdom down to five guiding principles for DfSC decision making:

1. Focus on the factors affected by commonality by using  the relative cost differences between the feasible design options rather than absolute cost differences. It is often very difficult to calculate absolute cost differences correctly.
2. Instead of getting “too analytical too quickly,” begin by identifying the qualitative pros and cons. This will help quickly prioritize the important costs for further analysis.
3. Make simplifying assumptions whenever possible. Ask whether a particular factor would affect the decision (but always capture assumptions so that they can be validated later).
4. Evaluate the upper and lower bounds on costs, and perform sensitivity analyses. This will help ensure that recommendations are robust.
5. Build a detailed financial model when three conditions are met: the decision is too close to call, a wrong decision among the remaining options could be costly, and the most significant open issues relate to quantitative (versus qualitative) factors.

Let’s put these guidelines in terms of the two alternative decision processes illustrated in Exhibit 1.

Path A describes a design-for-supply-chain project where several analysts begin by building a comprehensive financial model that is subsequently used to evaluate design alternatives. If done correctly (including appropriate data gathering, model validation, and sensitivity analysis), this path can result in an excellent decision and a significant return on investment. But the numerous design decisions, alternatives, and uncertainties of this approach can slow down projects and try the patience of participants and sponsors alike. More importantly, many more design decisions are not evaluated quantitatively at all.

In just about every conceivable DfSC situation, path B should replace path A. The key feature: The team first performs a rough-cut analysis to understand which costs are most significant. In some cases, a decision becomes clear after the first-pass analysis (top branch). In other cases, more detailed modeling is required and justified (bottom branch).4

Although SPaM has used the path-B approach for years, we have observed that many less successful analysts jump right into detailed modeling. In some cases, “top branch” path-B projects can achieve benefits comparable to path A in one-fifth the time. Even “bottom branch” path-B projects are usually completed more rapidly than those taking path A. The time advantage is the result of subsequent financial models focusing only on the cost factors that are truly important—and ignoring everything else. In addition, the transparency and simplicity of the rough-cut analysis encourages the decision maker and the extended team to build up their intuitive “muscles” more quickly.

Cost Drivers for Commonality
While working with the analysts, we reviewed nearly 20 projects that were seen as successful. For each, we examined the decision made, the alternatives considered, and the analytical/modeling approach employed. As expected, we found that some costs were more important than others in driving commonality decisions.

We further validated the importance of each cost driver based on our experiences, considering the likely magnitude of the differences between the common and unique alternatives. In other words, if a particular cost was similar across common and unique options, we prioritized that cost category as “low” even if it was a large absolute cost.

As the first guideline described above suggests, gathering the data and modeling these costs is not always worthwhile. For example, freight and packaging costs, while significant for most supply chains, are rarely important for commonality decisions because common and unique parts are usually about the same size, weight, and fragility.
Exhibit 2 summarizes the prioritized prelaunch, production, and end-of-life costs for commonality decisions.

As mentioned above in the second guideline, we always recommend that development teams evaluate each of these costs qualitatively to ensure that these priorities remain true for their particular decision.

After documenting the advantages and disadvantages of commonality and reuse for each cost driver, we generated a set of rough-cut techniques. Let’s follow one example of the method for service parts inventory as it applies in HP’s industry.

Costing of Service Parts Inventory
When contracts with customers include short time windows for replacing failed parts, spares inventory must be stocked at field locations close to customer sites. However, because most products are reliable, some parts at a particular location may never be required. Commonality often enables dramatic reductions in both inventory levels and management complexity at field locations. The rough-cut technique goes through three steps:

Step 1: Estimate the Number of Field Parts
If the installed base of products is proportional to the world’s population, achieving a four-hour (or less) replacement window  requires about 500 field locations worldwide (there are about 400 metropolitan areas with populations greater than 1 million people). If products are concentrated in certain regions or replacement commitments are less stringent (for example, next day), considerably fewer locations are required.

To calculate the annual inventory cost, three pieces of data are required:

1. Number of field locations—the number of locations required to meet the most stringent service requirements. This data point is available from the support organization.
2. Inventory value (per unit)—the inventory value of each part, often the material cost. The data are available from procurement or R&D.
3. Inventory holding cost (percent)—the annual cost of carrying inventory as a percentage of inventory value, including financing, devaluation, storage, and scrap. Figures are available from finance or supply chain.

Although the amount of inventory at each field location must be estimated, it usually is not necessary to collect data on installed base, expected failure rates, or restocking lead times. In most cases, one unit provides sufficient inventory at each field location. So if one common part could be used instead of three unique parts, field inventory could be reduced by 67 percent (by going from three units per location to one).

The annual inventory cost of each common and unique alternative is calculated by multiplying together the total amount of inventory, the inventory value, and the inventory holding cost (usually between 10 percent and 40 percent). For this example, the savings from buying one part instead of three (in other words, a savings of two parts) would equal $10,000. This figure is based on a calculation of two parts per location for 250 locations at an inventory value of $100 per unit and a holidng cost of 20 percent.5

Step 2: Validate Field-Stocking Levels
The demand for service parts at field locations is usually small but highly unpredictable. To validate the stocking requirements, three additional pieces of data are required:

1. Installed base (units), or the number of parts at customer sites. The data are available from marketing and/or R&D and are based on part-to-product connect rates—or the number of parts per product.
2. Annual repair rate for parts (percent per year). The likelihood that a part must be repaired based on a combination of failure rates and “no-trouble-found” rates. Data are available from support.
3. Restocking lead time (days). Lead time from the regional DC or supplier to the field stockroom. Figures available from support.

The equation below can be used to estimate the daily demand (D) for service parts at each location (I is installed base, R is annual repair rate, and F is the number of field locations).

 D = IR
  365F

Imagine that a common part is installed in 100,000 products, has an annual repair rate of 1 percent, and requires four days to restock. Assuming that the installed base is evenly served by 250 field locations (that is, 400 installed-base products per location), the average demand per location is only 0.01 units per day (four units per year). Even if this part were to be required for a service call, it’s unlikely that another unit would be needed while inventory is being restocked—average demand over the four-day lead time is only 0.04 units. Similarly, for the “unique parts” scenario, we could calculate demand over the lead time. If three unique parts instead of one common part are used, the demand over the lead time for each part would be some percentage of 0.04 units (depending on the usage split of the three parts across the installed base). For example, if the first unique part is used in 60,000 products, demand over the lead time would be 60 percent of 0.04 units.

Assuming a service level objective of 95 percent or better, the table below shows inventory guidelines based on the expected demand over the lead time (D times L, where L is lead time).6 For our example, the assumption of one inventory unit per location seems reasonable, giving us confidence in our estimate of the inventory savings of commonality calculated above.

Spare Parts Inventory Needed for
Service Levels of 95 Percent or More
  Inventory to achieve >95%
 Demand over the lead time service level
 0.05 units or less 1 unit
 between 0.05 and 0.3 units 2 units
 between 0.3 and 0.8 units 3 units

Step 3: Verify Assumptions and Perform
Sensitivity Analyses
Because it is possible that demand across the field locations is uneven, calculating inventory units based on “average demand” (per the equation for D above) may underestimate the actual requirements for the “high demand” locations. For example, if some field locations serve areas with particularly large installed bases or if the failure rates are not uniform, analysts may wish to further refine the assumptions and calculations. In performing a sensitivity analysis, we find that a field location serving more than about 450 installed products (vs. the 400 assumed above) probably requires two inventory units, while a location serving more than about 2,700 installed products probably requires three units.7 To increase the confidence of the team and decision maker regarding the final recommendations, we could perform similar sensitivity analyses on repair rates and lead times and recalculate the potential savings of commonality.

After presenting the qualitative and quantitative analyses to the decision maker and extended team (which usually includes key representatives from R&D, procurement, supply chain, and marketing), one of three things usually happens: a decision is made; a tentative decision is made, pending follow-up on some questions and the recalculation of a few numbers; or the decision is “too close to call” based on the rough-cut analysis, but making the right choice is important to the organization. In the last case, the decision maker would sponsor a subsequent project to model the financials in more detail.

Buy-in Across the Organization
We are a long way from those early days when a rough-cut analysis was applied randomly—if at all. Today, we have significant buy-in from more people in the design community. We’ve consciously consulted with our internal clients all along, so we now have the right to push the program further and faster. We believe that a combination of consulting projects, custom workshops, Web-based training, rough-cut tools, and telephone and e-mail mentoring will allow us to effectively serve HP’s thousands of R&D, NPI, and SC engineers.

Many of the NPI and R&D engineers we now work with say it’s the first time they’ve had robust and rapid methods that are consistent with how they make their design decisions. As a result, supply chain costs are being considered by far more development teams today. Standardizing on a pan-HP approach has brought credibility to the methods, leading to much faster decision making and increased alignment across functions.

We’ll close with one example of the value that rough cut is bringing. Over the 2004/2005 winter holidays, HP’s industry-standard server group was given less than four weeks to make several commonality decisions. Although the two NPI program managers were initially overwhelmed, they successfully used the commonality framework and rough-cut techniques to perform an analysis. With some mentoring from the DfSC Program Manager for Enterprise Storage and Servers, the team identified almost $2 million in commonality savings and was able to tell which parts should remain unique.

The team also identified an opportunity for further modeling: Common packaging could provide additional savings but would require a common chassis and bezel (the product’s external case) at an additional cost. The dollars at stake were significant, and the correct answer wasn’t clear. The management and development teams were very satisfied that the rough-cut analysis was completed so quickly and that it was so comprehensive.

Perhaps most impressive, however, was the relative inexperience of the analysis team. It was the first time that the NPI managers had been exposed to that level of tradeoff analysis. The fact that they were able to make credible recommendations in such little time speaks to the power of this type of rough-cut approach.  jjj

Authors’ note: The authors wish to acknowledge the contributions of Mike Meyers and Scott Ellis. Mike Meyers, DfSC Program Manager for Enterprise Storage and Servers (ESS) Group, sponsored the development of the rough-cut techniques at ESS, helped to extend them, and is driving their implementation. Scott Ellis, Director of HP Strategic Planning and Modeling, leads the SPaM team that created the fundamental approaches which led to our rough-cut techniques, is a key sponsor of HP’s DfSC Program, and provided thoughtful improvements to this paper.

Endnotes:
1 See, for example: Edward Feitzinger and Hau L. Lee, “Mass Customization at Hewlett-Packard: The Power of Postponement,” Harvard Business Review, January-February 1997: pp. 116-121.
2 See, for example: Hau L. Lee and Corey Billington, “Managing Supply Chain Inventory: Pitfalls and Opportunities,” Sloan Management Review, Spring 1992: pp. 65-73. Tom Davis, “Effective Supply Chain Management,” Sloan Management Review, Summer 1993: pp. 35-46. Laura Kopczak and Hau L. Lee, “Hewlett-Pac

Talkback

We would love your feedback!

Post a comment

» VIEW ALL TALKBACK THREADS

Related Content

• Topics
• Author

Related Content

 

By This Author

There are no other articles written by this author.

Sponsored Links