Aug 1 2018
Why bother with a yawn-inducing topic like bills of materials (BOMs)? Bring it up with manufacturing professionals and their eyes glaze over instantly. And the Lean literature is mute on the subject. I even asked Michael Ballé for his input on the subject and he responded that he had none to offer.
Yet everyone involved with assembly agrees that BOMs are at the core of their activity, that BOMs have chronic accuracy issues, that the workarounds to these inaccuracies impair the companies’ ability to update and customize products, and that BOM maintenance hogs resources. Perhaps it’s worth giving the subject some thought and having a conversation about it.
What Is a Bill of Materials (BOM)?
Over the years, usage of the term has expanded beyond recognition. Starting from a product breakdown into subassemblies and components, it grew to include drawings, machine programs, operator work instructions, supplier contracts, etc. It’s confusing but it would be fine if problems with BOMs in the original sense were not pervasive. But they are, and it’s not wise to keep adding new elements on a shaky foundation.
The BOM of a Product
The Wikipedia article on BOMs illustrates why we should pay more attention. It starts out with the following:
“A bill of materials or product structure (sometimes bill of material, BOM or associated list) is a list of the raw materials, sub-assemblies, intermediate assemblies, sub-components, parts, and the quantities of each needed to manufacture an end product.”
The German ERP supplier SAP refers to DIN standard 199-2-51, which defines a BOM as follows:
A bill of material is a complete, formally structured list of the components that make up a product or assembly. The list contains the object number of each component, together with the quantity and unit of measure.
A bill of material can only refer to a quantity of at least 1 of an object.
Why should the quantity be at least 1? A recipe can call for 1/2 tsp of sugar. A manufactured product can require 0.75 m of tape per unit…
If you ask non-manufacturing persons what they think a bill of materials is, they usually guess that it’s a form of shopping list. If you include technical drawings in a BOM, you make it a more complex structure, loaded with elements that are not needed to plan production, issue orders to suppliers and for many other uses of a BOM.
For the purpose of this discussion, I will stick with the nested shopping list view. It is a set of data without which assembly is not possible and errors in it have consequences for all the functions using it.
Firmware items are not included in BOMs because they are not materials. They don’t come in bottles or cases and don’t require trucks. Embedding software into a product is an operation in a routing but it does not involve withdrawing units from stocks.
Printed documents that are shipped with the product and disposable packaging, including shrink-wrap, need to be in the BOM but pallets and returnable containers do not. Instead, they belong with the other reusable resources used in the plant’s operations, like fixtures and tools. The BOM should contain all and nothing but the materials that are consumed in the making of the product as shipped.
BOMs as Networks
The Bill of Materials of an assembled product is most commonly visualized as a tree where the product itself is the root, purchased materials and components are the leaves, and subassemblies the intermediate nodes, marked with the quantities of each needed to manufacture a unit of the parent node.
The same item may appear in multiple nodes if it goes into multiple subassemblies, as is common, for example, with fasteners. If you print or display assembly instructions, it is normal for the fastener to appear in the component list of every subassembly that uses it, with the quantity used.
If, on the other hand, you want to aggregate the requirements for this fastener, you collapse all the nodes for it into a single one. The BOM then is no longer a tree but a more general form of directed network.
The BOM of a Product Mix
Most companies do not make only one product. If we view each BOM as a tree, then, for the whole product mix, these trees add up to a forest.
Each one has a BOM, but the same leaves or nodes can go into multiple products. If we view each one as a distinct network, we don’t see this commonality. It can, in fact be difficult or impossible to visualize when you are dealing with thousands of items.
It is then easier to treat the BOM as a table of triplets in the following form, that I suggest calling the gozinto relationship:
|Child ID||Parent ID||Quantity|
- Subassembly B uses 3 units of purchased item A.
- Finished product C uses 2 units of subassembly B.
The units of measure for the material and the assembly items are both needed for the quantity to be meaningful but they are attached to each item in the item master rather than to the gozinto relationship, as in:
|Item ID||Unit of Measure||…|
The (Child-ID, Parent-ID, Quantity) triplets are all you need to construct other views of the BOM, as a tree or a matrix. The items that appear only in the child column are purchased.
Subassemblies, semi-finished products, or kits appear on both sides, as children and parents. Some items are both subassemblies and products in their own right. The same item made in house can go into a larger product and be sold separately as a spare part.
In an engineering BOM, it is the same item; in a manufacturing BOM, it usually isn’t because the item that is fed naked to final assembly is encased in a blister pack, boxed, palletized and shrink-wrapped for shipment as a spare part. This makes it a different item, with the packaging as additional components. The general BOM logic, however, must allow for the possibility of having the same item be both a subassembly and a product.
This is resolved by introducing a new item called, for example, “Market” that products go into as shipped, which can be as a single unit, in a bin, or as a pallet load. The following table says that C is a finished product and B is both a subassembly of C and a product:
|Child ID||Parent ID||Quantity|
The network can be visualized in a toy case, for illustration, as follows:
A BOM for 2,000 products and 50,000 purchased and subassembly items cannot be visualized as a whole.
Invalid BOM Records
Not every list of item pairs and quantities belongs in a BOM. The following, for example, are not allowed because they make no sense:
- An item is not allowed to go into itself. A cannot go into A.
- Loops are not allowed either because, indirectly, they lead to an item going into itself. You cannot have A go into B, B into C, and C back into A.
- The same pair of items cannot appear multiple times with different quantities. Item B either requires 10 A screws or 5, but it can’t require both.
Such patterns violate basic logic and make planning calculations fail but, unless BOM editing software flags them, it is easy to see how typos in IDs can make them creep into tables of tens of thousands of records maintained manually.
Viewing Complex BOMs
We can use the toy example above to illustrate various ways of visualizing parts of a complex BOM. From the representation as a table of gozinto records, software can easily generate a variety of list, tree and matrix views of the BOM for a product or a family of products, as needed for its multiple uses.
As discussed below, however, the gozinto table is not easily extracted from the BOM tables of leading ERP products. Unless you have received extensive training on the ERP product, you have to go through an intermediary who has. It’s not a do-it-yourself project.
Function-specific Item Attributes
For each of the various uses a BOM is put to, other data is attached, such as a lead time for a purchased item, assembly instructions for subassemblies and products, or pick lists for kits,… but the simple gozinto structure is what all these uses have in common and it is where many companies have BOM accuracy issues.
The most common metric for BOMs is accuracy but most discussions of the topic assume everybody understands what it means. Many explain how important BOM accuracy is; few bother to discuss how to measure it.
The literature separates completeness from accuracy. If an item is missing from a BOM, the BOM is incomplete; if it’s listed with wrong data, it’s inaccurate. For the purpose of this discussion, since both are errors, I lump both under “inaccuracies.”
Why Are BOMs Inaccurate?
According to consultant Nigel Cox, inaccuracies creep into BOMs as a result of the following:
- Products are customized.
- Products are designed and manufactured by different organizations.
- Engineering changes are poorly managed.
- Management pays attention to new products, not existing products.
According to him, also, the only way to ensure BOM accuracy is for management to insist on it, which strikes me as bit short. BOMs are data, and, while I agree that good IT is no substitute for management will, it can facilitate the process of establishing and maintaining accuracy.
For example, when a BOM is handed off by the Design team to Manufacturing, it makes a difference whether it is in the form of a copy of the design BOM or shared access in a database of master data. In the first case, only extreme vigilance will prevent the design and manufacturing BOMs from diverging; in the second case, they are technically prevented from doing so.
Manufacturing managers and engineers rarely express any concern about copying BOM extracts from the company’s ERP system into their own Excel spreadsheets. They feel it is what they have to do: they won’t let the shortcomings of the information system stop production. Only the IT staff is concerned about the consequences.
On p. 62 of Manufacturing Data Structures, J. Clement et al. measure accuracy separately for each level of a multilevel BOM. There is one accuracy measurement for the product with its immediate components, and another one for each subassembly.
In this metric, inaccuracies do not propagate upwards. If the gozinto record for item A into subassembly B is incorrect, it doesn’t make the gozinto record of subassembly B into product C incorrect.
Why focus on single-level subassembly BOMs? After all, an error in any link, at any level of a product’s BOM makes it defective. The single-level subassembly BOMs, however, are the view of the BOM provided in assembly instructions. If you are assembling an electric motor on an assembly line, your parts list has only one level: rotor, stator, housing, etc. The rotor’s own, lower-level parts list is not your concern.
What is clear, on the other hand, is that this metric allows you to “improve” accuracy by gerrymandering the BOMs: restructure them to have many small, correct subassemblies and concentrate the defectives into a few large ones. This does not require you to correct any of the defective gozinto records.
In Measuring bill-of-material accuracy: Practicalities and pitfalls (1987), K.J.Balcerak and B.G.Dale argued that more than one metric is necessary.
There are several ways BOM accuracy can be measured. The following two, for examples, would measure the quality of the work done by the Technical Data Management department, in charge of issuing and maintaining BOMs:
- The ratio of the number of products with BOMs that are free of errors at any lavel to the total number of products made by the company. This measures outcomes.
- The ratio of the number of error-free gozinto triplets to the total number of gozinto triplets. This measures the amount of work needed to correct the errors.
In production, however, errors in the BOM of a product that is never made are harmless, while errors in that of a product made in high volume every day are crippling. To reflect this, we could instead use the ratio of the aggregate production volume for products with error-free BOMs to total volume.
The accountants, in turn, may be more interested in the ration of aggregate sales for for products with error-free BOMs to total sales.
The 98% Rule
The literature also says that BOMs must be at least 98% accurate for users to trust the data. This seems a low bar. If accuracy is measured as Clement et al. recommend and you have 5,000 subassemblies defined in your product mix, then you can expect 100 of the subassembly BOMs to be wrong.
If the wrong BOMs are equally likely to affect all products, this is certain to affect both productivity and quality. In practice, we should expect BOMs to be maintained with greater care for the frequently made Runners and Repeaters and the errors concentrated among the sporadically made Strangers.
If this checks out, it can mitigate the impact of the inaccuracies. I have not, however, seen any study to date of the correlation between BOM accuracy and frequency of use.
What is puzzling is that inaccuracies in BOMs should be tolerated at all. This is data that is generated and maintained internally, as part of product design and is not affected by variations in the business or technical environment.
They are not influenced by market fluctuations or tool wear. They are decisions made by professionals, and BOM inaccuracies are discrepancies between these professionals’ intent and the data they produce.
So why are they allowed to exist? Manufacturers can make smartphones, airplanes, or cars but they can’t maintain a shopping list? How do you foul that up?
Given that there is no technical reason, we have to look at human, social, and organizational causes, which leads us to examine the ways BOMs are used, and the BOM models supported by leading software vendors
Who Uses BOMs?
Use cases are now the tool of choice for software developers to specify applications. They identify potential users and scenarios of the way they would use a tool. Then they develop the tools to make all these scenarios possible.
Here we are attempting to do the same for an object called BOM that almost everyone working in a manufacturing plant uses in one way or another. In fact, it is easier to list the employees who don’t use the BOM than those who do.
Perhaps Sales, Maintenance and Human Resources don’t need it but just about everybody else does, and for many different uses. Following are the ways a few members of a manufacturing organization might describe how they use the BOMs:
- Assembler: “When assembling, I need to know which parts go into the product in which quantity at this operation.”
- Kit picker: “To prepare kits for assembly operations, I need a pick list with quantities by item.
- Design Engineer: “When designing new products, I am being asked to reuse components from previous products.”
- Manufacturing Engineer: “We have identified a better component for an assembly operation. I need to do the following:
- Run a trial run with the new component in production.
- Analyze the results of the trial.
- If successful, submit an Engineering Change Request.
- Secure approval of the change request.
- Implement the change in production. “
- Quality Engineer: “A customer has returned a defective unit. I need to trace the components it was built from.”
- Production Planner or Scheduler: “I need to explode the product demand into the time-phased demand for purchased materials and components, and for internally made subassemblies.”
- Logistics/Materials Manager: “I need to ensure that the right parts are available in the right quantities at the right time for assembly to execute its schedule.”
- Supply Chain Manager: “I need to define a plan for every part (PFEP) we buy, including ordering method, frequency and quantities, based on the production plans and schedules.” Even when you use the method that is simplest for the customer — consignment — you use the BOM to calculate the quantities used in the finished goods to calculate how much to pay the supplier.
- Accountant: “I need to assess the financial impact of changes in terms and conditions with suppliers, based on the current and future workload and the bill of materials.”
BOMs in Leading ERP Packages
It is most common for a company’s BOM to be maintained in its ERP system. ERP vendors do not have to share information about the BOM structures they support but some of them do, and what they let us see is quite revealing of their approach.
BOMs in SAP
SAP starts by agreeing with the common definition:
A bill of materials or product structure (sometimes bill of material, BOM or associated list) is a list of the raw materials, sub-assemblies, intermediate assemblies, sub-components, parts and the quantities of each needed to manufacture an end product.
Further in the same document, however, they contradict themselves by identifying the following BOM categories:
|T||Functional Location BOM|
|P||Work Breakdown Structure BOM|
This list makes you wonder what the software’s designers were thinking. Since the M in BOM stands for Materials, a Material BOM stands for Material Bill of Materials.
The notions of Document Structure, Equipment BOM and Work Breakdown Structure BOM are not covered by the definition. They are tree structures all right but it doesn’t make them BOMs. Specifically:
- A Document Structure is a tree of text and drawings. The nodes of a BOM are physical items. They must be ordered from suppliers and delivered by truck, or they must be manufactured in-house. None of this applies to documents.
- SAP’s Equipment BOM is the structure of a piece of equipment and is used by Maintenance. It may formally be identical to a product structure but is used differently.
- The Work Breakdown Structure of a project is also a tree but the operations you do on it have nothing to do with a product BOM.
Besides the strategy of calling BOM any tree-structure , we also see a supplier determined to use cryptic names for its tables. The BOM categories above are one example. Another one is the BOM Usage Table, which goes by the name of “T146”:
|Code||SAP BOM Usage|
|5||Sales and distribution|
|R||Rework (copy of production)|
The names of the tables containing the BOM data are equally baffling:
|SAP BOM||Tables Description|
|STAS||BOMs – Item Selection|
|MAST||Material to BOM Link|
|MARC||Plant Data for Material|
|MARA||General Material Data|
|USR21||Assign user name address key|
|ADRP||Persons (Business Address Services)|
Most transaction users access BOMs through forms and don’t have to worry about these cryptics, but those who want to retrieve the data to analyze it do. This has the 1980s flavor of business systems before graphic user interfaces. The legitimate use of cryptics is to protect private information from prying eyes but their use in information you publish is difficult to understand.
Exploring the maze of SAP tables in search of gozinto records is like working with a bureaucracy that keeps refering you from one department to another. The unnecessary friction increases both the training costs and the risks of errors. Not every ERP supplier has done the same.
BOMs in Oracle
In Oracle’s ERP products, for example, the Bills of Material (BOM) Tables have names that don’t require decrypting:
Like SAP, however, Oracle appears to have commingled other data with the bill of materials under the “bom_” prefix. Since BOM stands for “Bill of Materials,” bom_bill_of_materials is a redundancy, and the other bom_ tables hold data that is not part of the BOM, like routings, sequences, or resources.
BOM in Epicor Express
Likewise, for Epicor, “Bill of material” is an item in a list that is also called “Bill of material”:
Bill of Material
- Bill of material (BOM)
- Product routing
- Methods of manufacturing (MOM)
- Visual BOM display
- Same-as-except easy MOM generation
- Document linking
- Critical path view
- Phantom structures
- Where used reporting
Decentralize BOM Design and Maintenance
The literature on BOMs as well as the BOM database systems from ERP vendors do not separate the issues with the gozinto structure from those affecting other data, like routings, lead times or supplier parameters. There is value in doing this for several reasons:
- The gozinto structure is the core master data that everything else depends on. It is a common environment the must be centrally maintained.
- The other data elements are used by some but not all users and are best maintained by users with domain expertise in process planning, production planning and scheduling, or logistics/supply chain management, using their own tools and information models rather than living within constraints imposed by a central system.
The usual argument to justify holding the complete master data — including BOMS — in a single system is that it ensures consistency and integration. Many managers have been sold ERP systems based on this promise, only to find end users working around these systems and maintaining master data in separate spreadsheets, thereby achieving neither consistency nor integration.
The reasons for this sorry state are not technical. 2018 IT is up to the task but ERP suppliers have historically not been able to secure the best expertise in all the required domains and have seen their specialized modules outperformed by application-specific tools developed by domain experts.
Rather than pouring more money and effort into the all-in-one approach, manufacturers could perhaps embrace the alternative of letting each function use its preferred systems, with the following rules to play well with others:
- Use the common item nomenclature and gozinto structure.
- Sharing its own master data, indexed by item or gozinto link as lists of nested name-value pairs.
The supply chain additional data for item T4 in our toy example might be as follows:
LeadTime: 10 Business Days
MinimumOrder: 50 Cases
The materials management additional data for the gozinto record (T4, S2, 5) could be as follows:
Gozinto: [T4, S2]
Description: Washer into Housing
Location: Lineside rack R19
Pitch: 30 minutes
The names of the departments are included so that they don’t have to worry about parameter names being the same in different departments, as is the case here with “Description.”
Sharing data is much less of a technical problem that it was 20 years ago, as a variety of different formats for self-describing messages have been developed, including XML, JSON and YAML, YAML being the easiest for humans to read.
By giving each department autonomy in defining the BOM data, this approach would accomplish the following:
- Allow each department to attach to the BOM the exact data that it needs.
- Restrict the amount of central maintenance of BOM accuracy to the basic gozinto structure.
- Delegate the responsibility for the accuracy of the additional data to the organizations that use thetm.
Set Priorities in Accuracy Maintenance
Errors in a BOM that is used hundreds of times daily are lethal; in a BOM that is never used, harmless. J. Clement et al. do recommend sorting items by decreasing quantity consumed or produced to set priorities on audits of accuracy and completeness.
I would take this further and base accuracy maintenance policy on a complete runner-repeater-stranger analysis on finished goods. Runners would, of course, have the highest priority, followed by repeaters, but the policy for strangers might be to worry about a product’s BOM accuracy only when and if an order for it arrives.
Dovetail with Improvement Projects
As a stand-alone project, fixing the BOMs is never-ending and tedious, and may even be futile when an improvement project on an assembly line or a change in purchasing policy makes obsolete BOMs that have just been audited.
It is more effective to systematically include BOM audits as tasks within improvement projects. As you change the layout of an assembly line, or its subassembly structure, or the work content of different stations, shop floor observations will expose any errors in the BOMs and provide the opportunity to correct them. And the corrected BOMs will not be immediately obsolete.
Make Technology Help
In mechanical manufacturing, CAD tools automatically generate bills of materials and can be paired with tools that facilitate the reuse of existing parts. This, by construction, should generate a complete and accurate engineering bill of materials, to be handed off for further addition to package design, manufacturing, and materials management…
How it is handed off, however, makes a difference because product development is not a sequential, cascading process but an iterative one. Even after Manufacturing approved the design, it may find when implementing it that it requires a process capability the plant doesn’t have and cannot acquire in time for the product launch.
If the handoff consists of providing copies of the design documents, then all copies must be recalled, which may be difficult when recipients have made further copies and passed them on to colleagues.
If, on the other hand, rather than being copied, the design documents are shared using a collaboration tool, then there is one copy in existence, that all involved access and modify as authorized. Team messaging systems also allow participants to have private discussion groups by design topic.
Control the Engineering Change Process
Engineering changes affect not only BOMs but all other types of master data. As such, their management deserves a separate discussion, for which this is a placeholder.
Suffice it to say here that, as for other aspects of BOMs, the technology to do it well is available, and its effective use depends on the right combination of management will and technical know-how.
What I have seen while researching this topic confirms that it matters but that improving BOMs is not simple, because of the number of items, links, and parameters concerned, and because of the many stakeholders involved.
Making all the BOMs of a manufacturing company complete and accurate is patient work done one product at a time, addresing runners, repeaters, and strangers in that order, and with diminishing returns. It can’t be done in Kaizen events.
Without sustained management support, it cannot be done at all. Given this support, today’s information technology makes it doable faster and more thoroughly than was possible with the tools available even 20 years ago.
As is common with manufacturing topics, there are more books about BOMs in Japanese than in English, and they are more recent.
I only searched for books that are dedicated to the subject of BOMs. I did not include general books on production control, that normally include a discussion of BOMs among other topics.
Books in English
Phil Robinson, Bills of Material, Design and New Product Introduction(2012) Phil Robinson is a consultant on ERP, Lean Manufacturing, and Total Quality.
Dave Garwood, Bills of Materials for a Lean Enterprise (2004) Dave Garwood is a consultant on ERP.
J. Clement, Andy Coldrick, and John Sari, Manufacturing Data Structures (1992), Wiley, NY, ISBN 0471132691 All three authors were Oliver Wight consultants. Andy Coldrick is specialized in Sales and Operations Planning (S&OP)
Books in Japanese
谷口潤, 中小企業だからこそできる BOMで会社の利益体質を改善しよう! (2014) Because it’s a small business, let’s use the BOM to improve the profit structure of the company! By Jun Taniguchi, a consultant.
戸沢義夫, 四倉幹夫, グローバル生産のための統合化部品表のすべて BOM/部品表の一元管理法 (2006) Integrated Bills of Materials Management Methods for Global Production, by Yoshio Tozawa and Mikio Yotsukura. Yoshio Tozawa is a researcher at the Advanced Institute of Industrial Technology (AIIT) in Tokyo. Mikio Yotsukura runs Class Technology Co.Ltd., a provider of bill of material, production planning and scheduling solutions and a visiting professor at AIIT.
佐藤知一, 山崎誠, BOM/部品表入門(2004) Illustrated introduction to Bills of Materials, by Tomoichi Sato and Makoto Yamazaki. Tomoichi Sato, has also written books about production scheduling and project management.