Are they merely labels, or do they carry substantial meaning?
In the complex world of engineering and manufacturing software, Bill of Materials (BOM) always stands out as a basic element in information delivery. Regardless of the lifecycle stage (design, engineering, manufacturing, maintenance), BOM always stands for the data that describes the product information. Each element of the product development cycle can be represented by a specific Bill of Materials type. The roots of Bill of Materials are going a long way back to the time when the first MRP/MRPII systems were introduced. Back in those days, BOM was considered a document that contained all the information needed for the product (either digital or physical). As the systems in product development and manufacturing are deeply intertwined, the question about how to organize engineering, manufacturing and supply chain information is triggered more often.
The History Of Multiple BOM Types
The concept of BOM classifications has evolved from various origins. In the early days, when the BOM resided solely within MRP II (Manufacturing Resource Planning), detailing raw materials and components needed, it was simply referred to as a BOM or a parts list in drawings. However, as companies streamlined their processes and adopted different design and data management tools, the necessity for distinct BOM types emerged. PLM (Product Lifecycle Management) systems swiftly embraced EBOM, while ERP (Enterprise Resource Planning) software systems leaned towards MBOM. The “as-x” notation increasingly denoted a product’s stage of maturity. This is how companies end up with a various “BOM type soup” – DBOM, EBOM, MBOM, SBOM, PBOM, xBOM. In addition to that, sometimes BOM management used the prefixes to indicate the source of data such as “electronic” (EBOM), “mechanical” (MBOM), “software” (SBOM) and others, which created an additional level of complexity.
What significance do these names carry? Are they merely labels, or do they carry substantial meaning? On one hand, they are indeed terms, providing flexibility in product data models and reflecting various stages in product development, lifecycle maturity, and organizational processes. Yet, in the complexity of process management across business, engineering and manufacturing realms, achieving terminological coherence is vital.
How Many BOMs Do We Need?
The history of BOM management is still around us and this is a reality of data and BOM management these days in many engineering teams and manufacturing companies. As such you can see places where BOMs still live naturally because it is part of the traditional data management practices.
MRP and ERP solutions
You need an accurate BOM to build a product, buy off the shelf components and order custom parts and assemblies. Therefore BOM information is a critical part of every MRP or inventory management system. It’s a manufacturing bill or sometimes called planned bill of materials to support procurement and production process. It’s a list of all materials and components that are required to manufacture a finished product. It’s very tactical and usually doesn’t contain a good way to trace what happened in the past. A typical manufacturing bill of materials is “effectivity based”, which means you can see how it looks for a specific day. It is tightly integrated with planning and inventory items and functions.
The roots of all BOM management and single bill of materials in every manufacturing organization are coming back to the foundation of MRP systems. A bill of materials (BOM) is a critical component of a manufacturing resource planning (MRP) system. It is a list of all the materials and components that are required to manufacture a finished product. There are several reasons why BOM is important for MRP: Planning and Scheduling, Costing, Quality Control, and Traceability. Therefore MRP BOM is not very useful for engineering functions. Read 5 Books To Start Your BOM Management Education to learn more. Inventory management was a core element of MRP, therefore, it was good for manufacturing BOM and supply chain management, which later became part of ERP solutions.
BOM IN DRAWINGS (Part List or just BOM)
This is another place where BOM lives and has a long history. The drawing part lists existed for as long as drawing and documents were standardized for manufacturing. It is (still) the most widely accepted method to release information from engineering to manufacturing. There are several standards to regulate how to do so. For example, ASME Y14.5 defines the practice of including bill of materials (or part lists). In electronic and electrical engineering, the IPC-2581 standard provides some guidelines for manufacturing data and documentation, including the use of a parts list that specifies the assembly components. Similar requirements can be found in architecture, construction, HVAC, and electrical drawing for construction. All CAD packages provide support to create part lists and bills of materials. For many engineers, it is the first place where they meet BOMs.
BOM IN PDM and PLM (EBOM and multiple BOMs)
Historically, PDM was born to manage CAD files. This is still one of the most frequent use cases for PDM (Product Data Management Systems). However, with the extensions of PDM functions, the question of how to include a good visualizations and list of all components become important. With the introduction of 3D CAD systems, the need to manage 3D components and assemblies triggered the need to keep traceability between component updates and BOM (part list) in the drawing. Most PDM systems do a decent job keeping these lists in sync. PDM systems usually provide a decent mechanism of integrating data between components and drawings. This is probably the mainstream BOM solution for all small and medium size companies. And it is a root cause of a lot of inefficiencies in data management.
However, as the complexity of products was growing the need to have an independent from 3D representation of product structure emerged. Introduction of systems including mixed mechanical, electronics and software components emerged and so the need to have an EBOM (engineering BOM) that includes all information collected from multiple design teams. This information is needed to review the engineering solution and release it to manufacturing. In this case, EBOM plays the key role in the engineering release process such as ECO.
Future advancement of PLM systems and the need to manage product structure (information) that describes the product in different stages of its lifecycle (development, manufacturing, maintenance, etc), created the need for more than one BOM to represent different product structures and data. Such data structures are also well aligned with the organization of work in manufacturing companies (engineering BOM, manufacturing BOM, maintenance BOM) – each BOM structure belongs to a specific organization and sometimes can be managed by multiple tools.
Creation of multiple BOMs became a continuous place for a battle between multiple enterprise software providers – PLM, ERP, MES, CPQ, etc. Each software provider including engineering and design software, ERP and others, used in the manufacturing process claimed a specific “BOM silo” such as engineering bill, manufacturing bill, service BOM, etc. All together it created a concept of xBOM and the need to keep this information “in sync” (will talk about it later)
One BOM vs Many BOMs?
One of the most frequent debates in the BOM management discipline is around how many BOMs is needed to manage information in a consistent and connected way.
What is behind this conflict? The reality of engineering and manufacturing is to include multiple disciplines and organizations. Each discipline defines its needs to how to structure and present the information. Also, lifecycle and changes are impacting the process. A specific production data (BOM) can be different from a specific revision of Engineering BOM (EBOM). Alternate components required for assembly, but they are not even mentioned in the engineering structure and this information is not even needed for engineers. The level of conflicts is different and depends on the industry, level of complexity, and product development organization. Organizations want to have control of the data. Having multiple BOMs (eg. Design, Engineering, Manufacturing) can be a solution to solve this problem, but at the same time the complexity of the process and potential mistakes on data synchronization forces companies to rethink the approach that is used for each specific organization.
To create multiple BOMs (eg. EBOM and MBOM) is the simplest approach that exists today in the industry. Each system keeps the BOM (sometimes multiple BOMs) and organize a synchronization process between these structures. The names can be different, but essentially means the segmentation of phases (As-Design, As-Planned, As-Built, etc.) or organizational ownership (Engineering, Manufacturing, etc.). In some situations, the segments are caused by the companies, contractors, and suppliers’ boundaries. Each BOM (product structure) is managed as a separate entity. The coordination and change process includes many synchronization and updates to keep consistency between multiple BOMs. It completely solves the problem of ownership and introduces huge complexity of reconciliation, traceability, and validations.
The idea of a single (one) BOM is interesting and worth discussion. One one side, to think that multiple organizations can change their needs and present the information in one way would be too amateur. You can see such efforts sometimes when companies are either small or too centralized and IT and business architectures decide to get a single system to manage all information.
But in a practical sense it is not happening very often. But, if you apply a “data management” thinking, the idea of a single BOM has some merit, because it basically creates a single data structure that is capable of managing all aspects of product information.
The idea of a single BOM that provides a centralized place to manage all product information, connected to all data sources leads to the approach that is called “multi-view” BOM. It is a modified version of a single BOM approach, which mainly focuses on how to segment a specific organizational or process representation from a single BOM. This option is considered a viable alternative to the first option (Multi- BOM) that creates too many difficulties for reconciliation, changes, and synchronizations.
Conceptually, this model is the best because it can reduce the data redundancy and eliminate the data synchronization points. However, this option put a heavy load on the need for the organizations to agree about single data representation and the ways to extract a segmented data representation (View).
From Multiple BOMs to Digital Graph Model
Although usage of multiple BOMs is still the mainstream method to organize product information today, I can see a trend towards creating a holistic digital product model. The main problem with traditional model is heavy orientation on documents (eg. BOM in drawings or Part Lists in MRP) and siloed data representation. In this model, customers are oriented towards documents and perceive product information through the lens of multiple BOMs. This approach, while familiar, has inherent limitations. It often leads to data redundancy, inconsistencies, and challenges in maintaining synchronization across different departments. Although it is still the mainstream model used by most of PLM vendors, it has many disadvantages. The siloed nature of this model hinders the seamless flow of information, thereby impacting efficiency and adaptability.
The idea of xBOM that can integrate multiple data representations and keep them in sync, demands evolution and improvements. The idea of “digital twins” that grows beyond just simulation is the one that I like. While the name “twin” can be debated, the rationale I can see behind it is to rely on a digital model that represents product information including engineering, planning, production, maintenance, etc. in a connected form and can be used by multiple teams and departments.
What can be better than the xBOM model? The adoption of modern data architectures and data management systems is leading the industry towards creating a new holistic digital product model. This model use modern data modeling paradigms (eg. Graph Model) to encapsulate a rich set of information about the product connected together.
Such a model is capable of encapsulating multiple facets of product data (multiple BOM structure) – combining sales, requirements, engineering, manufacturing, and maintenance. A holistic product model will support the creation of a unified view of the product life cycle, enabling better connection and process flow across various lifecycle stages of product development. This approach streamlines processes, reduces errors, and enhances the overall efficiency of product management.
The technological foundation of such a model can be a graph model, which can provide a robust representation of multiple data assets and create a flexible set of relationships. Product knowledge graph is a way to take PLM development and bill of materials data model from siloed engineering bill, manufacturing bill, service and maintenance all together to model engineering and product development process combined with production process and rest of lifecycle stages to present an accurate BOM all way down from requirement to maintenance.
Management of bill of materials has a long history of data management starting from the early days of design using drawings with ink and placing part list on the drawing, using MRPII models to create a single production BOM and advancing towards creation of complex multiple BOM models to support as-design, as-engineering, as-manufactured and as-support models. All together it contributed to the creation of the xBOM model that was dominant for the last decade to support the EBOM/MBOM dual model. At the same time, digital thread is a model that allows the connection of multiple BOMs in the xBOM model in a connected data set to support traceability and coordination of processes. The next step in multi-BOM process development is to establishing digital models (eg. product knowledge graph or digital twin) to manage all aspects of product information and to support integrated business systems development. We go from a single BOM to multiple BOMs to a single digital model and future advantages of BOM copilot for better management of product information.
