Bill of Material is one of the fundamental things in engineering, manufacturing and product development. Whatever topic you start discussing, you end up with the discussion about BOM. Wikipedia, actually, provide a decent definition of Bill of Material. Here is the link and quote:
A BOM can define products as they are designed (engineering bill of materials), as they are ordered (sales bill of materials), as they are built (manufacturing bill of materials), or as they are maintained (service bill of materials). The different types of BOMs depend on the business need and use for which they are intended. In process industries, the BOM is also known as the formula, recipe, or ingredients list. In electronics, the BOM represents the list of components used on the printed wiring board or printed circuit board. Once the design of the circuit is completed, the BOM list is passed on to the PCB layout engineer as well as component engineer who will procure the components required for the design.
It sounds so simple and straightforward. If you just finished your “BOM 101”, you can think the topic is really easy to get. The complexity of Bill of Material management comes as a result of the process, which is happening around BOM during design, engineering, manufacturing and support. What defined as “different types” of BOM, in reality, representing people, teams, department and sometimes different tools and enterprise solutions.
Time ago, I posted about how companies can have a single BOM – Seven rules towards single bill of materials, which raised many questions and comments in the past. One of the ideas of having single Bill of Materials is to streamline processes across disparate teams and departments. Few weeks ago, I came across a white paper published by Arena – Beyond BOM 101: Next Generation Bill of Materials Management. Navigate to the following link to read the document. This white paper provides a very interesting picture, which demonstrates the reality of BOM management in any manufacturing company.
This whitepaper is highlighting a very important fact – during the design, engineering and manufacturing process, engineers need to update BOM in many systems. Here is my favorite passage explaining the complexity of BOM management.
A modern BOM often includes a complex set of hundreds to thousands of structured items… Even after the first product is built, the BOM will continue to evolve—whether due to potential bug fixes, design improvements, part substitutes, or supplier switches—until the product reaches its end of life. The time spent to manually make changes and fix mistakes throughout the lifecycle of a product may amount to a substantial delay in its shipment. With multiple teams inputting frequent changes, manual revision control processes can easily become overwhelming and chaotic. It is difficult to track which changes have been made to which revisions. There is a lack of “a single version of truth” —the latest product information including BOM—that all project teams can consistently and confidently rely on throughout the lifecycle of a product.
The main challenge in this process is to maintain multiple BOMs in different systems. So, the idea of single Bill of Materials can be easy materialized to solve the complexity of synchronizations. So, why companies often fail to establish this single BOM? I can identify 3 main reasons why it happens:
1- Companies are using variety of tools to design, build and support products. Single platform PLM is probably a dream that not going to be materialized. In most of the companies, multiple design tools (including CAD), product data management and ERP systems are creating a complicated eco-systems with many rules and dependencies.
2- Because of specialization, people are not interested to switch from specialized and tailored tools to somewhat less functioning but common. The change is complex, can lead to potential delays and involvement of IT in system deployment and data integration. People prefer to bump BOM between systems rather than use a single tool.
3- It is hard to agree on how to share a single structured set of information (single BOM) among multiple teams, department and organizations. To develop export/import functionality as well as multiple synchronization services is, unfortunately, the mainstream decision taken by many companies.
What is my conclusion? I think, companies need to have a single, sharable, structured BOM representation reflecting all aspects of product development. PLM vendors applause to the idea of single database, but most of the integration and data synchronization tools and techniques are still very premature. In addition to that, PLM vendors are usually trying to lock customer to a single platform solution preventing independent and open bill of material storage. So, all together it blocks customers from migrating their infrastructure and system towards “single BOM” implementation. Just my thoughts…
Best, Oleg
