On this page
Whole-product cost information during development is critical for effective product planning, yet many organizations rely on outdated tools that fail to provide accurate and timely cost estimates. While sophisticated enterprise-class software tools are commonly used for tracking product costs during production, few tools are capable of working with product cost data during development—when costs are actually being determined.
Part 1 of this paper explores five software architectures for tracking product cost data, and evaluates their relative merits using basic principles of data management: data integrity, accessibility, flexibility, and intelligent complexity. However, architecture selection is only the first step: part 2 discusses specific, detailed implementation issues—separating prototype and production costs, tracking sourcing and pricing information (including volume, lead time, and unit of measure data), and including of manufacturing process costs—that determine the suitability of a cost management tool to the challenges of product development. Finally, Estimating Product Costs During Development discusses how timely and accurate product cost data can be used in a critical calculation for product planning: estimating aggregate materials investment for new products, including inventory pipeline costs and total material and manufacturing process costs.
Every organization that does product development or manufacturing must eventually answer the question: How much does a product cost? In recent years, estimating the product cost early in the development process has become progressively more important to a company’s financial success. At the same time, continuing business developments have made it harder to produce reliable, up-to-date product cost estimates during product development, when 70% of a product’s cost is determined.
All meaningful estimates of product cost start with a roll-up of the costs of all components of a product into a single number. To be able to do this, an organization needs two things: first, a bill of materials (BOM) for the entire product, and second, the tool to take the BOM costs and roll them up into a single number. These requirements may seem easy to satisfy, but the problem is surprisingly complicated, and in practice most organizations do not roll up product costs until the product is in production—long after this information is needed. The reality is that the tools available for cost analysis are generally ill suited for use during product development, due to inherent shortcomings in their data management architecture or the inability to handle the complex and dynamic nature of product data in the development environment.
This paper is an exploration of product cost estimation during product development, organized into two parts. In Part 1, we discuss basic data and application architecture principles and analyze the strengths and weaknesses of five classes of cost estimation solutions with respect to these principles. In Part 2, we describe specific techniques for using a bill-of-materials-based solution to estimate total product cost.
For the purpose of this paper, we will consider only “direct” product costs—the cost of materials and manufacturing processes that are the direct result of the design and production of a hardware product. Indirect costs—salaries, marketing and advertising expenses, et cetera—are beyond the scope of this paper. In particular, we will discuss approaches (both tools and business practices) to providing up-to-date answers to two closely related questions during the product development process:
What is the per-unit cost of a product?
What is the aggregate investment in materials required to bring a product to market?
Most of our attention will be focused on solutions for estimating per-unit costs, since these costs must be determined before any meaningful estimate of the aggregate investment can be made. We will briefly discuss the various components of the aggregate investment and the ways in which per-unit costs may be used in estimating the aggregate amount.
Competitive pressures in product-based industries have increased as trade barriers have fallen and global competition has become the norm. This has led to shortened product life cycles, with most of the market share (and profits) for new products going to the manufacturers that are first to market with the best, lowest-cost product. Runners-up are left to fight over market scraps, and often end up losing money in the process. Even established manufacturers with strong brands are finding that their customers quickly abandon them if they fail to demonstrate leadership with a continuing flow of innovative, low-cost, market-leading products.
In this environment, manufacturers have been forced to outsource: no single company can hope to be “best” at all the technologies and practices required to bring a modern product to market, yet the market demands products that meet this standard. The outsourcing movement started with a shift to purchasing “best of breed” components and manufacturing processes from a global supply chain. More recently it has expanded to include the purchase of design and technical expertise during product development from an outsourced “design chain”. Outsourcing—of both design and manufacturing—has had the effect of disaggregating product definition information, including cost data. As a result, it has become much more difficult to create and maintain reasonable estimates of product costs during the development process.
In addition, the drive to establish and maintain market leadership has forced manufacturers to reduce time-to-volume, thereby greatly increasing the financial consequences of misjudging product costs. Consider just one example: the cash required to finance the inventory “pipeline” for a new product. A rough estimate of the total size of the inventory investment needed to bring a product to market in volume production can be calculated as the product of three variables: the per-unit cost of the product, the production rate (typically measured in units per month), and the length of time between payment to suppliers for building the product and receipt of revenue from customers who have purchased the product. For example, assuming a three-month window between payment to suppliers and revenue from customers, a manufacturer must make an up-front inventory investment of $3 million to bring a product that costs $100 to market in a volume of 10,000 units per month. Further, allowing for typical supplier lead times, the manufacturer must commit to this investment four to five months before the product reaches the customer. Because the cost of a product has a substantial effect on the demand (and consequently on the production rate), under- or over-estimating product costs during development can have dire consequences in the form of either losses or missed revenues. In short, the success or failure of a new product launch often hinges on accurate product cost estimates early in development.
Despite the importance of cost estimation during development, there have been no solutions that competently address the complexities of product costing data and analysis during this phase of the product lifecycle. Most organizations that design and manufacture products are continually looking for ways to improve their process for estimating product costs during design and development.
There are three factors that should be considered when evaluating proposed solutions for product cost estimation during development: architecture, quality of implementation, and cost. Each of these areas warrants careful analysis before a solution is adopted; in this paper, we will focus on the issues of architecture and implementation. Analyzing the cost of various solutions is beyond the scope of this paper.
The architecture of a solution for estimating product cost during development can be evaluated with respect to four primary issues: data integrity, accessibility, flexibility, and complexity. While our main concern in this paper is product costs, it is worth noting that much of this architectural analysis can be applied to the more general problem of collecting, maintaining, and sharing product data of all types during product development.
The principle of data integrity is central to any information system. While the term can be applied to a number of considerations, we will use data integrity to describe two qualities: completeness and non-redundancy.
Completeness refers to the breadth of data captured by the system. In product data management, this means that product data is captured at the component level through to the finished goods, including processing and packaging. A product data management system that does not encompass all phases of the product design and manufacturing process cannot be considered complete.
Non-redundancy is the goal of any efficient data system: an item should be entered a single time and stored in such a way that permits it to be re-used, rather than re-entered. As an example, for a commodity component such as a resistor, the approved vendor list (and quotations from each vendor on the list) should be stored in one location, and re-referenced wherever the resistor needs to be used. This avoids wasting time re-quoting previously quoted items, and also facilitates correct and complete updates to the cost information as new sources are identified and new quotes are received.
Accessibility encompasses three concepts that are critical to the smooth function of any product design endeavor: data visibility, data aggregation, and access control.
Data visibility is the means by which information is made available to members of the design and supply chain. Product costing data is generated by a relatively small group of people (typically, engineers and purchasing agents), but is critical to the work of many other groups within the enterprise: project managers, executives, manufacturing, sales & marketing, finance, and others. For the organization to meet its goals, appropriate information must be made available to both technical and non-technical members of the extended product team, including external design consultancies and suppliers.
Data aggregation is the method by which data from different people and from different groups on the product team is incorporated into a unified whole. As cost data is generated, it must be aggregated into a form that lends itself to easy “real-time” estimation of whole-product costs. This aggregation process must be as easy and quick as possible—ideally, not requiring human intervention at all. For example, mechanical engineers are typically closely involved in the quotation and cost estimation of the “mechanical BOM”—that portion of the product that is mechanical in nature. Electrical engineers typically work with the purchasing department to identify multiple sources for each electrical component, and to obtain quotations from each source. Packaging engineers design the packaging that brings the product together with its documentation and accessory equipment and that protects the entire bundle during shipment. The ideal solution for product costing during development would allow all this information to be captured in a single, whole-product database, so that as new information becomes available to one member of the design team, it is automatically incorporated into the database and made available to all other members.
Access control is the mechanism by which data aggregation becomes a usable solution for group data management. The collection of product data cannot be a “soup” of information with which all group members can work; rather, the data must be protected for appropriate use. The visibility issues above remain valid—the access itself should be straightforward—but aggregation governs the degree to which team members have editing control over product data. For example, project managers need a high degree of visibility into product data, but they should not be able to modify technical data. A good aggregation system includes tools for controlling editing access to support good business practices.
Product cost data changes rapidly during development—new quotes are received, target volumes are adjusted, and redesigns change the list of included components and the BOM structure. Design team members should be free to focus on the product, not on the administrative task of “capturing” the latest version of the design. A system for estimating product costs during development should be flexible enough to allow changes without requiring a large administrative investment by team members. In addition, a solution for managing whole-product data must be ubiquitous, so that an engineer at a testing lab can access and update the BOM and product specifications as easily as an engineer at his or her office. This helps avoid the common practice of engineers making significant design changes in their personal versions of the product definition and only later (typically much later) communicating those changes to the rest of the product team.
In theory, it is possible to define an infinite amount of data for any situation. Yet a good data management system does not automatically track every possible data point; instead, the system defines the useful parameters of data, considered for the situation as a whole. Intelligent complexity—the correct depth of data—requires that the nature of the data itself be fully comprehended.
Product cost data typically starts out simple—a target price for each part or manufacturing process included in the product—and becomes progressively more complex as development proceeds and target costs are replaced with multiple quotes (including various quantity, lead time and even tooling options) from multiple sources. The nature of practical cost data is intricate at the item level and even more complex when considered for the product (or family of products) as a whole.
Intelligent complexity means that the intricacy of product cost data is considered and weighed against the informational needs of the project as a whole. The full complexity of data—without limits—is not appropriate. Yet setting data boundaries too restrictively can strip useful data as well. For example, a system which allows only a single cost per item will (of course) fail to capture the difference between prototype and production pricing for the item, as well as the sensitivity of the item cost to volumes and lead times. In the best case, this means that such information is filed away and accessible to only the design team member who received it from the vendor; more commonly it means that the details of vendor quotations are simply lost. As a result, under such a system the product team never knows whether the latest cost estimate is the cost to build the next prototype or the cost to build ten thousand production units. A system with intelligent complexity is developed around the pragmatic use of data, but with attention to the possibilities that extend the organization’s data needs.
In broad terms, there are five classes of product data management tools in use for estimating product cost data during development, each of which handles the architectural issues described above with varying degrees of success.
Spreadsheets programs, such as Microsoft® Excel, are by far the most common tools for sharing product cost information during development. Designed for financial modeling, spreadsheets are ubiquitous, low-cost data management tools. They are easy to create, distribute, and customize. However, spreadsheets are single-user tools: when a spreadsheet file is opened, it is unavailable to any other user. This limitation renders spreadsheets the least effective of the five classes of cost data management systems.
Because spreadsheets are single-user, they must be duplicated to disseminate information. This creates good visibility—the process of publishing spreadsheets is straightforward—but decreases the overall data integrity. Each duplicate instance of the spreadsheet creates more redundant data and confusion over which version of the spreadsheet is authoritative.
Whenever a spreadsheet is used as intended—that is, whenever a data field is updated—the data management system breaks down. Other spreadsheets are rendered obsolete. The spreadsheet system makes no provision for notifying other users that data has changed; the process of collecting, evaluating, and aggregating changed data into the authoritative whole must be done manually. The solution to the continual obsolescence of spreadsheets is to spend an inordinate amount of time managing the disconnected users—time that would be better spent focusing on the product.
The single-user nature of spreadsheets also has ramifications in the areas of flexibility and intelligent complexity. A spreadsheet appears to offer great flexibility—as a flat file structure, the spreadsheet creates no mystery around the data it contains—but this very flatness actually decreases flexibility. The more complex the data in the spreadsheet, the more difficult the spreadsheet is to maintain. Because spreadsheets can be so unwieldy, most organizations develop separate product data spreadsheets for different groups, customized for electrical engineers, mechanical engineers, packaging engineers, project managers and so forth. The “flexibility” that allows this customization actually degrades the overall data management system, as idiosyncratic spreadsheets proliferate and isolate the groups.
Finally, a spreadsheet can be no more intelligent than the individual who creates it. In the product design industry, which is an agglomeration of different talents and specialties, this is a dangerous prescription for data management. Spreadsheets actually encourage complexity without providing the means to manage it at the enterprise level. There is no mechanism to limit each user’s modification of the spreadsheet file—feeble software locks provide only rudimentary deterrence—so intelligent managed complexity is impossible.
In summary, it is extremely difficult and time-consuming to produce an up-to-date estimate of product cost during development when spreadsheets are used to manage product cost data. As a result, most organizations produce such cost estimates only two times: once at the beginning of development, and once at the end. In the intervening months (or years), when most of the decisions that determine the eventual product cost are made, the cost of the product is unknown. As a result, companies frequently find out too late that a product has substantially exceeded its cost target, and they are left with the unpleasant options of either delaying or canceling the product, or accepting reduced profits (or incurring losses) while the product team scrambles to find ways to cut costs.
Both mechanical and electrical CAD applications offer the ability to attach a limited number of data fields to components modeled in the package; some PDM implementations also offer this functionality. In addition, some third- party vendors offer “add-on modules” that extend the data management functionality of a particular CAD package. Often these features are used by individual engineers to capture a subset of product cost data. (For example, many electrical engineers use their schematic capture tools to attach primary manufacturer and vendor information to schematic components.) In some cases, enterprises attempt to use CAD or PDM tools to systematically track whole- product cost data during development. We are unaware of any successful implementation of this solution.
These CAD systems feature some rudimentary tools for data integrity, but are so limited in scope that they have little to offer the rest of the process. Typical product development efforts require the use of multiple CAD systems in which the same component or assembly must be modeled, introducing redundancy and the resulting questions about which model is authoritative for product cost data. However, the most severe failing of CAD- and PDM-based solutions is in data visibility and aggregation. The interfaces of CAD tools are highly tailored to their primary users, so data captured in a CAD application is essentially invisible to anyone outside of the primary user group—a kind of access control, but certainly not designed with intent. Electrical engineers generally cannot use a CAD tool designed for mechanical engineers (and vice versa), and non-technical users can rarely use these tools at all. In addition, CAD applications have essentially no capacity for aggregating whole-product data: the mechanical portion of a product is captured in an MCAD application, the electrical portion in an EDA application, and non-modeled components like manufacturing processes, bulk materials, or packaging are not captured at all. Finally, the cost of these tools makes it impractical to use them as a vehicle for publishing product cost data to a wider audience.
CAD applications typically have excellent flexibility—they are designed for use in a highly dynamic environment—but they are quite poor at handling the complexity of product cost data. While CAD applications use database-like functionality to track and maintain product data, these database implementations are highly specialized and generally cannot be easily extended or modified to accommodate non-CAD data. For example, few CAD applications can perform even elementary cost calculations such as a cost roll-up from a nested BOM. In addition, appending fields to modeled components severely limits the complexity of the data that can be handled—for example, it is generally quite difficult to capture multiple sources, and there is no way to maintain an approved supplier list.
In short, CAD- and PDM-based solutions are unsuitable for estimating product costs during development.
When the inadequacies of spreadsheets and CAD-based solutions become apparent, some companies turn to MRP/ ERP systems in an effort to track product costs during development. Many companies have already made substantial investment in such systems, and they hope to leverage the investment by extending the use of the tools into product development. On the face of it, this is a promising strategy: MRP/ERP systems are built on top of multi-user relational databases, so in principle they can address many of the architectural issues we have discussed. In practice, these efforts rarely succeed: the development process is far too dynamic for MRP/ERP systems that were designed to manage finalized product data during the manufacturing process.
Because they use relational databases to store product data, MRP/ERP tools can avoid problems with redundant data entry: part data can be re-used without requiring re-specification. MRP/ERP systems also typically offer good data visibility to their target users inside the company firewall, though they tend to be inaccessible to other departments (like engineering), and typically do not permit data to be shared with the extended design or supply chains. It is generally possible to address visibility to other departments by creating customized data views for the needs of these users, though this customization tends to be very expensive and difficult to execute well. However, there is generally no practical way to make MRP/ERP data visible outside the company walls: the tools are just not designed to permit this type of usage. In addition, MRP/ERP systems use dedicated client software, which must be installed on every computer that is used by members of the product team in order to effectively provide visibility to product cost data. Often this alone is a substantial barrier to usage: there may be licensing implications, or the client software may not be compatible with all the computing platforms used by the design team, or the IT department may simply lack the resources to install and support so many copies of the client software.
Without extensive customization, MRP/ERP systems typically also fall short on aggregation: their user interface is cumbersome and geared towards manufacturing and purchasing departments, not engineering. As a result, the creators of product data find it extremely difficult to maintain a current representation of the product in these systems during development. This is a natural result of the fact that a design goal of MRP/ERP systems is to limit the changes to product definition data that can be very expensive during production when inventory has already been stocked. This lack of flexibility renders these tools unsuitable for use during product development because they discourage alteration of product data—the very function of design.
Architecturally, MRP/ERP systems are well suited to handling complex product data—they use a relational data model that can capture extremely complex business and product data. In practice, however, their effectiveness depends upon the detailed design of the underlying data model. A company that proposes to use an MRP/ERP solution for tracking product cost during development (in spite of its flaws in aggregation and flexibility) should carefully evaluate how well the system handles the subtle costing issues outlined in the implementation section of this paper.
Given the shortcomings of MRP/ERP solutions, several vendors have offered dedicated client-server applications that attempt to address the problem of tracking whole-product data (including cost data) during design. While each vendor’s products differ in implementation, they share certain architectural features, and can be analyzed with respect to the architectural issues of data integrity, accessibility, flexibility, and intelligent complexity.
All client-server solutions are built on multi-user databases, designed (with varying degrees of success) for complete product data. As a centralized data source, the client-server model also offers good data visibility and access control tools. Because users enter changes directly into the system, this approach effectively addresses the integrity issue of redundancy and provides for aggregation of product data from multiple users within the enterprise. However, these solutions do not provide for aggregation of data created by the extended design chain: in general, licensing problems and complex information technology requirements prevent the use of these tools with design consultants or with vendors of custom components who create significant portions of the product data. For the same reason, these tools are extremely difficult to configure and maintain for use by the supply chain. Because the server resides behind the corporate firewall (which by default does not permit incoming data connections for security reasons), any attempt to share product data with parties outside the firewall must start with a request to the IT department to reconfigure the corporate firewall to permit incoming connections to the server in question. In the rare cases where this request is granted, the system administrator must then assume the burden of administering data privileges to permit tens or hundreds of suppliers to see specification information for hundreds or thousands of items. This is a heavy burden, particularly during development when supplier relationships are very dynamic. In short, dedicated client-server solutions generally provide good visibility and aggregation within the corporate firewall, but are impractical for use with extended design or supply chains.
Because they are designed to manage product data, dedicated client-server solutions can provide good flexibility. Because they are designed for product data management, these tools—if well-designed—can also offer greater intelligent complexity than tools that have been adapted for the space. As with MRP/ERP solutions, however, the usability of the system ultimately depends upon detailed implementation. Prospective buyers of these solutions should carefully evaluate how the system handles the issues outlined in the implementation section of this paper. Even simple issues like rolling up costs from a nested BOM should not be taken for granted. Unfortunately, the nature of these applications makes it very difficult to effectively evaluate them before a purchasing decision is made—vendors are generally unable to do more than provide canned demonstrations.
One final factor to note with regard to client-server applications is their high cost. In general, these solutions require an initial investment of hundreds of thousands of dollars (large installations run into the millions) and have annual licensing costs of tens of thousands of dollars. In addition to these direct costs, these systems typically have very high indirect IT costs. A server must be dedicated to the product, and the IT department must maintain the server and also provide support for the client software on all machines on which it is installed. These high costs generally decrease the visibility advantage that the system enables—the organization has a strong incentive to restrict access to all but the most vital users, because each additional client must be carefully cost-justified. The result is lessened visibility—fewer users get the benefits of the system.
Web-native, BOM-centric applications represent a new kind of solution to the problem of product costing during development. A web-native application is one in which the product data is hosted in a secure multi-user database outside a company’s firewall, and users employ a web browser to access the data via secure, authenticated connections. A BOM-centric data model is one that uses the multi-level bill of materials as the conceptual model for aggregating and organizing product data. The BOM (and associated item specifications, sourcing, and pricing data) has traditionally been viewed as the final deliverable from the design team to manufacturing, but the BOM is very well suited to capturing and organizing product data throughout design as well.
As with MRP/ERP-based solutions and dedicated client-server solutions, web-native BOM-centric applications use a relational database to centralize product data. As a dynamic data storage and serving solution, these tools offer precise access control. In addition, data can be re-used rather than re-entered, avoiding the issue of redundancy. However, the combination of a BOM-centric data model with a web-native architecture distinguishes itself by its substantially improved solution to the problem of data visibility: with a username and password, all members of the extended product team (including the design and supply chains) can view and update product cost data from any computer with internet access and a web browser. Both technical and non-technical users are generally familiar with the BOM as a conceptual model and are able to easily navigate the BOM to find relevant product cost data. In addition, because the data is stored in a secure database outside the company firewall and accessed using web browsers, IT support is not needed to install client software or to allow design or supply-chain users to view the data. Finally, the problem of controlling supplier access to product cost data can be handled with component sourcing relationships that automatically define “need to know” relationships between supplier users and product data: suppliers can see product data for only those BOM items for which they are identified as a source. This encourages the members of the design team to capture sourcing information completely, and also substantially reduces the overhead of administering supply- chain access to current product data.
Web-native, BOM-centric solutions also substantially improve aggregation of product data: a well-designed bill- of-materials data model can easily incorporate specifications, sourcing, and pricing data, and each member of the product team can be assigned specific areas of responsibility for certain types of data and certain levels of the BOM. Because data is captured within a BOM structure, aggregation of cost data (including roll-up of total costs from component costs) can be handled automatically—when a new component cost is entered, the whole-product cost estimates are immediately and automatically updated to reflect the new information.
Web-native, BOM-centric solutions also handle the issues of flexibility and complexity extremely well. Because product cost data is available universally, changes can be captured as they occur. In addition, the use of a relational database permits the full complexity of product cost data to be captured. As with other solutions, prospective users should carefully evaluate how well the system handles the subtle costing issues outlined in the implementation section of this paper. Fortunately, the web-native architecture permits extensive evaluation before purchasing a solution, as no software needs to be installed to run the application.
The following table compares the five solutions for managing product data according to their support of each architectural goal, as discussed above.
In Part 1 we discussed the architectural aspects of a product data management solution: the technology on which it is built, its suitability as a shared enterprise tool, and its capability to create intelligent boundaries for product data. In this section, we focus on specific problems in product cost estimation and the process of evaluating the aggregate cost of bringing a product to market—analytical tasks which overwhelm most cost estimation tools.
A system for estimating product costs must use a data model powerful enough to capture the complexities of real- world cost data. Much of this complexity arises from the fact that real products are a combination of commodity components, custom components, and a variety of manufacturing processes, each with its own cost structure and considerations. For example, commodity components and processes are typically purchased from multiple sources, some of which may be distributors and some of which may be manufacturers. To correctly handle this common situation, a tool for capturing product cost data must have a data model that comprehends the supply chain, and the manufacturers, distributors, and process vendors that it comprises. Companies looking for a product cost estimation system should prioritize the implementation issues listed below (and add any other issues that are particular to their industry or situation) and then evaluate each proposed solution with respect to the prioritized issues.
For a variety of reasons, the cost of goods for a prototype version of a product is generally much higher than the cost of goods for the production version. Often a large portion of the difference can be traced to the prototypes of custom components: in the design of custom parts, the fabrication processes to produce prototypes are completely different from those used in production. For example, injection-molded parts are common and quite inexpensive, often costing less than a dollar in volume production. However, during product development, this type of part is commonly prototyped using stereo-lithography—a fast but expensive process that typically costs hundreds of dollars for each part.
In addition to the large cost differences for prototypes of custom components, there are often significant cost differences between prototype and production prices for commodity components. During development, commodity parts are purchased in small quantities on short lead times to enable rapid prototyping. Vendors that specialize in serving this market charge substantially higher prices for providing small quantities of parts quickly—generally two to five times the price of the same component in volume. These price differences are fairly small at the part level, but when aggregated together can substantially skew the production cost estimate.
In order to avoid these problems, a product cost estimation system should track prototype component costs separately from production costs (and preferably use these costs to roll up a separate prototype cost estimate). Without this feature, it is difficult to avoid accidentally inflating production cost estimates with prototype costs.
The sourcing process is a decision-making process. In order to enable good decisions, the full complexity of sourcing information must be captured when a quotation is received from a vendor. A solution for capturing product cost data should understand common supply-chain relationships and be able to accommodate them easily within the data model. At the same time, an effective solution must allow for easy entry and use of estimated costs early in the design process. In the best case, these estimates should be preserved alongside quotations received later in the process as a way of judging (and hopefully improving) the accuracy of early estimations.
Multiple sources are available for commodity parts and processes. It is good practice to identify multiple vendors from which any particular component can be purchased, so that production is not delayed by the failure of a single vendor to provide parts as promised. However, these vendors are often distributors who resell a particular manufacturer’s component; in this case it is also necessary to identify a variety of manufacturers who can supply the part in order to avoid dependency on a single supplier. A solution for estimating product costs should be able to correctly handle any combination of the following common supply-chain situations:
No sources have yet been identified for the item. In this situation, which is common early in the development process, the system should permit the user to capture “best-guess” prototype and production costs for use in the calculation of product cost estimates.
The item is purchased directly from one or more manufacturers.
The item is purchased through distribution. Often multiple distributors may be approved sources for a single manufactured item.
The item is purchased through distribution, and the manufacturer is not known or not specified. This is a common case for true commodities like fasteners and certain types of raw material.
Volume breaks and lead times are included in almost all vendor quotations. When product plans change during the design process, the cost estimates for each component in the product must be re-evaluated. Generally, a part has multiple prices from multiple vendors, each representing a different tradeoff of lead time, volume, cost, and in some cases tooling or setup charges. The selection of a particular price for use in product cost estimation should not mean that other quoted prices are discarded; these options should be stored for use if—or, more accurately, when—the project parameters change. In particular, it is common for estimations of product demand to change several times during the course of a project, which affects the quantities (and hence the prices) of parts ordered for production. In this situation, rapidly updating the product cost estimate requires that previous quotations be fully captured; otherwise project staff must waste time looking for previous quotes, or worse, asking vendors to re-quote. Similarly, changing project schedules can substantially affect allowable lead times for component purchases. In order to save time when project parameters change, quoted pricing, volume, and lead-time options from each vendor should be captured in the cost estimation system.
Units of measure for items on a vendor quotation are often different from the units in which the item is actually used in the product. A typical example is a bulk item such as glue, purchased in units of bottles and used in units of drops. This situation also arises quite often in quotes for production quantities of discrete items such as mechanical parts or surface mounts components, which though used by the “each” may be sold by the case or in reels of several thousand parts. To make matters even more complicated, different vendors or manufacturers may package items differently: one manufacturer may package a part in reels of 2500 while another packages the part in reels of 3000, or the glue may be available in large bottles from one vendor and smaller bottles from another. To avoid data entry errors and to permit better communication with vendors, it is preferable to capture the price quoted for an item in the units specified by the vendor. This is especially true for bulk items where the exact quantity used (and the conversion between the quoted unit of measure and the used unit of measure) may not be known at the time when the quote is received. In order to fully capture all vendor quotations in such situations, a solution for cost estimation should be able to assign one unit of measure to the item as used in the product, and other units of measure to the item as purchased from each of a variety of vendors. For each vendor relationship, the application should permit a conversion factor to be specified between the “as-used” unit and the “as- purchased” unit, and this conversion factor should be used to calculate the cost per “used” unit from the (vendor- supplied) cost per “purchased” unit. For example, if a resistor is purchased in reels of 3000 from vendor A at a cost of $300 per reel, and in reels of 2000 from vendor B at a cost of $275 per reel, then the BOM cost for each resistor should be automatically calculated to be $0.10 for vendor A and $0.1375 for vendor B. This may seem like an easily handled problem, but very few solutions can capture this level of detail in sourcing relationships, particularly in multiple-source situations. Without proper unit-of-measure functionality, common errors in the entry of cost data (i.e., an incorrectly calculated conversion from one unit to another) become extremely difficult to find and correct, with resulting inaccuracies in product cost estimates. In extreme cases, vendor selection may be mistakenly based on such faulty cost data, resulting in substantial excess costs for the product manufacturer.
For example, to capture pricing for a single commodity component generally requires information about manufacturer-distributor pairings, plus quantity, price, and lead time quotes for each, as shown in Table 2 below.
The cost of a product is more than the sum of the costs of its parts: manufacturing processes generally make up a substantial portion of the overall product cost. A wide variety of accounting models (e.g., “routings,” calculation of “overhead” burdens, activity-based costing, and others) have been developed for incorporating process costs into product cost calculations during production. However, these cost models are usually too cumbersome to be practical during development, when so many aspects of the product are in flux. As a result, the cost of manufacturing processes has been largely ignored during development, with the consequence that companies frequently “discover” the true (and generally higher) full product costs only after a product reaches production. One of the significant advantages of using a single whole-product BOM for product cost estimation is that it provides a simple mechanism for incorporating process costs: during product development, processes may appear as line items on the BOM, with their own cost estimates. In this way, processes (and process costs) are integrated with the entire product definition, and are handled by the same design processes and documentation methods as physical items. Different types of processes may be handled differently in the BOM; labor, finishing, and contract assembly (on both a turnkey and a consignment basis) each warrant special consideration.
Labor, either for assembly of the product or for other operations, may be handled in the BOM in one of several ways. The first approach, creating a unique process item in the BOM for each labor operation, is best suited to situations where the development team is required to document the particulars of each operation. Having a unique item in the BOM for each process serves as a reminder to the team that each process must be documented, and the cost estimates for each process (including quantity breaks in batch manufacturing situations) may be updated whenever the process documentation is revised. When following this approach, the unit of measure for the labor item is “each,” and the cost estimates for that item correspond to the labor cost for that particular operation. The disadvantage of the unique-item approach is that it results in a large number of different labor items on the BOM, all of which must be maintained throughout the product life cycle.
In some situations, the production process engineering and documentation will be done by a third party after development, or the labor required to manufacture a product may be considered a commodity requiring no special documentation. In these cases it may be more appropriate to create a single generic item for each class of labor operations, and then include that item in the BOM wherever that class of operation is required in the manufacture of the product. With this approach, a time-based unit of measure is used for the labor item, and the quantity that appears in the BOM corresponds to the amount of time required to perform the operation. In the ideal case, where the cost estimation solution can handle unit-of-measure conversions, the cost for each class of labor operation may be captured on an hourly basis (the “as-purchased” unit), but specified in the BOM with a number of minutes (the “as-used” unit). There are two advantages to this approach. First, costs are captured in “intuitive” units: the generic labor item is priced on an hourly basis, while the duration of each particular operation is estimated (and captured in the BOM) as the number of minutes required to complete the operation. Second, revisions to labor rates may be easily incorporated into updated estimates of product costs: labor costs for the entire product are affected by the cost of the (relatively few) generic items representing different types of labor. The disadvantage of the generic-item approach is that having a few generic labor items in the BOM makes it less clear to all members of the project team which operations require special documentation.
In some cases, it is worthwhile to handle labor cost estimation with a combination of the unique-item and generic-item approaches. With this method, uniquely numbered “documents” for each labor operation are included in the BOM at a quantity of one each, and every document item is given its own one-item BOM consisting of a generic “process” item which captures the length of time required for (and the cost of) the operation. While complex, this structure permits the rolled-up cost of the labor operation to be correctly calculated from the quantity and cost of the generic labor item, while preserving the ability to track individual process documents as line items within the BOM.
Finishing for individual parts, when performed as part of a company’s internal production processes, may be handled in the same ways as labor: each finishing process may be represented in the BOM as a unique item, or as an instance of a generic item, or both. In the latter two cases, the time-based costing model for generic items can be extended to include hourly rates for different types of machinery. For example, a particular piece of machinery such as a lathe or milling machine may be represented by a generic item with a standard cost of $60/hour (one dollar per minute). A particular finishing operation may require three minutes of time on that machine, in which case the operation appears in the BOM with a quantity of three minutes and cost of $3.00.
When finishing is outsourced to a process provider, as is common for chemical processes such as painting and plating, the unique-item approach for tracking processes within the BOM is preferred. In such cases, it is generally necessary to specifically document the expected finishing process for each part; the cost of the process depends upon vendor quotations, much like the cost of physical parts in the BOM depends upon quotations for those parts.
Contract assembly (also called contract manufacturing) is a special case of an outsourced process, with its own challenges and considerations for product cost estimation. Contract assembly is used most often for printed circuit assemblies, but it is becoming common to outsource mechanical assembly processes as well, often to low-cost international suppliers. The relationships between customer companies and contract manufacturers are generally classified as either consignment or turnkey. In a consignment relationship, the customer company supplies a “kit” of component items which are assembled by the contract manufacturer; in a turnkey relationship, the contract manufacturer sells the finished assembly in its entirety to the customer company, and the price charged for the assembly includes purchasing and inventory management for all component items on the BOM. Regardless of which type of relationship is established, one of the major challenges of working with contract manufacturers is obtaining an accurate cost estimate early in design. This challenge is the result of several factors. First, without the use of web-native, BOM-centric tools for managing product data, it is extremely time-consuming to give a contract manufacturer full documentation (including sourcing data and component specifications) for a product assembly. As a result, contract manufacturers may not be given the opportunity to quote an assembly until late in the design process (long after the opportunity to optimize the design to fit the manufacturer’s process has passed). Second, in order to avoid being stuck producing the assembly at a loss, contract manufacturers generally try to avoid providing firm quotations until a design has stabilized and pre-production builds have been completed. Finally, in the case of consignment relationships, the contract manufacturer typically has an established supply chain for commodity components, and the costs of individual components for the contract manufacturer may be substantially different than the costs for the customer company.
For both types of contract manufacturing relationships, the best approach for cost estimation early in design is to capture the costs of each item in the BOM of the contracted assembly, and then add an extra cost (typically between 20% and 40% of the total component cost) as the contract manufacturer’s overhead and profit. This extra cost can be captured either with a unique item on the BOM (as described above for labor and finishing costs), or, if the cost estimation solution permits, by associating the extra cost with the assembly item itself. In this case, the total assembly cost is calculated as the sum of the estimated cost of the assembly item and the component costs. This method also works well for consignment relationships later in the design cycle—the estimate for the extra cost is updated with the quoted cost from the contract manufacturer. However, a turnkey manufacturer’s price quote for a component represents the rolled-up costs for all the component’s sub- assemblies. When a turnkey quote is accepted, the sub-assembly costs drop out, and the single quote is used to represent that component in price roll-ups.
In order to include process costs in a product cost estimate, the BOM of a product under development should include line items for both physical parts and for processes such as labor, finishing, and contract assembly. Doing so can significantly improve the accuracy of product cost estimates without substantially complicating the estimation process, but requires that the system used for estimating product costs allow non-physical components such as processes and documents to be included in the BOM. In addition, certain methods of tracking process costs make use of unit-of-measure conversions, while others require that a quoted cost be used in place of (or in addition to) the “rolled-up” cost for a subassembly. These capabilities are not commonly included in systems that are suitable for use by an extended design team during product development; proposed solutions for estimating product costs should be carefully evaluated with respect to these capabilities.
New product development is an expensive undertaking, and shorter product lifecycles mean shorter windows in which to recoup the investment required to bring a new product to market. In this section, we will discuss ways to quickly estimate the magnitude of the direct materials investment needed to bring a product to market. (Estimating the return on this investment is beyond the scope of this paper.) As in previous sections, we will concern ourselves only with the cost of materials and manufacturing processes used to build production and prototype versions of the product, and not with indirect costs such as salaries and advertising/marketing expenses.
In high-volume products, the investment in inventory in the “pipeline” from manufacturing to the customer often dwarfs all other product development costs. As discussed in the introduction to Part 1, a first approximation of this investment arises from three variables: the estimated per-unit cost of the product; the production rate (typically measured in units per month); and the length of time between payment to suppliers for building the product and receipt of revenue from customers who have purchased the product. We have already discussed systems and methods for estimating the per-unit cost in great detail, but it is important to note that the production rate is typically determined by estimating demand, which is highly dependent on price, which in turn depends on per-unit cost. Thus, under-estimating the unit cost during development can have a non-linear effect on the pipeline investment (and on the prospect for recovering that investment through product sales). For example, the marketing department may estimate high demand based upon low prices, so the company makes a large pipeline investment. When the actual unit cost is understood, the manufacturer is forced to go to market with higher prices, thereby reducing demand. In the end, the company is straddled with excess inventory—a manufacturer’s nightmare. On the other hand, while less common, over-estimating unit costs can lead to substantial missed revenues when demand is underestimated and manufacturing must scramble to catch up
Once an estimate of the cost per prototype unit is available, it becomes fairly straightforward to estimate the total material and process cost of all pre-production units: simply multiply the prototype cost by the total number of pre- production units (including units in initial engineering builds as well as later “verification” builds). In general, this simple calculation will over-estimate the total direct expense of all prototypes, because later prototypes often use production- quality components acquired at production pricing. However, this over-estimation is balanced by the fact that this calculation does not account for the scrap rate in pre-production builds, which tends to be very high: more material is purchased than is actually used in the prototypes, and the scrap rate is highest early in the design cycle when the cost per prototype component is also highest.
A simplified diagram of this type of analysis is shown below in Table 3. Assume a product with an estimated sales volume of 10,000 units per month, with a cost per unit of $100. The total cost of materials for 10,000 units of the product is therefore $1 million.
If it takes three months to bring the product to market—one month to purchase parts, a second month to assemble, and a third month of shelf time before the item is purchased—then the aggregate cost to create a steady flow of products to market is $3 million. Each month that passes without revenue—three months in this example—requires a $1 million outlay to continue to manufacture the product.
Effective cost estimation during production improves the precision of this calculation by providing a much more accurate cost per unit. When a web-native, BOM-centric product data solution is used to manage product data and provide cost estimates, the time-to-market may also be decreased: greater efficiencies in the purchasing and assembly phases of the project can speed time-to-market and ultimately decrease the aggregate cost.
The web-native, BOM-centric model for product data management provides the most effective solution for estimating product cost during development. As the de facto deliverable from design, the BOM is the end result of any successful design process. Systems that treat the BOM only as a deliverable, however, fail to take advantage of the BOM as a framework for managing product data during development as well. Data management systems that use custom schemes, such as proprietary client-server solutions and spreadsheets, still require the final step of funneling data into the BOM format. By using the BOM framework from the start, this funneling process is avoided, and product data generated during design is naturally aggregated into its final form, ready for delivery to manufacturing.
In particular, any practical solution for estimating product cost data during development must use the bill of materials as the foundation for providing continuous “bottom-up” cost estimates based on component costs. In addition to tracking per-item cost estimates for both prototype and production component costs, an effective solution for tracking product costs must extend the basic BOM data structure to include specification, sourcing, and pricing information as well as manufacturing processes such as labor, finishing, and contract assembly. Integration of sourcing data with BOM data permits multiple quotes from multiple sources to be captured. Incorporating manufacturing process information in the BOM structure provides an intuitive and easily managed way to include process costs in product cost estimates.
A solution for managing product cost data should therefore be centered around the BOM as the core data framework. In addition, implementing a BOM-centric management system as a web-native relational database provides the most effective approach to the architectural issues of redundancy, visibility, aggregation, flexibility, and complexity. Using a web-native tool dramatically improves collaboration with members of the design and supply chain, and the BOM provides a powerful framework for automatically aggregating their contributions. And lastly, with a well-designed relational data structure, such a system can support a great degree of data complexity while ensuring that data views are appropriate to all users.
Quality of implementation is just as important as product architecture when choosing a solution for estimating product costs during development. In this paper, we have discussed some of the subtleties of product cost data; a successful tool must use a data model powerful enough to handle these intricacies. An effective system must handle multiple sources for each component, including components purchased through distribution as well as direct from manufacturers. Volume and lead-time factors must be captured in order to permit rapid revisions to cost projections when project factors change. To improve the reliability of data entry, quotations should be captured using the units of measure in which they are quoted. Prototype and production costs should be separately tracked for each component and for the finished product in order to avoid errors in cost projections. Manufacturing process costs should be incorporated into the BOM as additional line items, not ignored until the product is released to production.
Aside from the process improvements that are realized with a web-native, BOM-centric solution for managing product data, the availability of accurate, up-to-date product cost estimates can be extremely helpful in higher-level financial analysis of products and projects. As discussed in Section III, complete cost information is a key variable in calculating the aggregate investment required to bring new products to market. With sound data on which to base product decisions, manufacturers can substantially improve the profitability of their new product development efforts.
©2012 Arena Solutions, Inc. Arena and Arena Solutions are trademarks of Arena Solutions, Inc., Reg. U.S. Pat. & Tm. Off. All rights reserved. Other product and company names are the property of their respective holders. Contact Arena at questions@arenasolutions.com for permission to repost or syndicate this content.
Ready to start? Try Arena free for 10 days. Sign up
