How to Resolve BOM Types Discourse?

Earlier this week, an insightful article by Prof. Jorg Fischer grabbed my attention. It explored the complexity of BOM (Bill of Materials) types, a topic familiar to many in the fields of manufacturing, engineering, and product management. Terms like EBOM (Engineering BOM), MBOM (Manufacturing BOM), PBOM (Procurement BOM), SBOM (Service BOM), and expressions such as “as designed”, “as built”, “as planned” are not just jargon but pivotal elements in understanding product lifecycle by many companies. You can hear them in many presentations of PLM vendors, PLM RFQ documents, and other places. Prof. Fischer’s piece proposes a framework for classifying these BOM names and suggests standards adaptable to various scenarios like ETO (Engineer-to-Order), CTO (Configure-to-Order), etc..

Here a passage from Prof. Fischer article:

Don’t bother mapping both categorizations. It works in theory but breaks down in deeper discussion. I think these are often categorizations of the same thing from different perspectives and at different levels of detail.

Categorization 1: The As … BOMs focus on a defined point in time in the process. This categorization simply states that these BOMs have different contents at different times. That’s all. What the BOMs are used for, who creates them, their semantics, and what business objects they carry (document, part, material or equipment) is not clear.
 
Categorization 2: The xBOMs are named BOMs, where the first letter (e.g., E and M) tries to denote the area in which the BOMs are used or created. This categorization is also vague. Since it comes from the PLM world, specific BOMs from the ERP are missing.

The article and debates made me think about what are possible ways to resolve the discourse.

Historical Background

The concept of BOM types has evolved from diverse origins. Back in time when the BOM was only exists in MRP II (Manufacturing Resource Planning) identifying raw materials and components required, it was simply known as BOM or a parts list in Drawings. However, as companies began organizing their processes and adopting different tools for management, the need for distinct naming arose. PLM (Product Lifecycle Management) systems swiftly adopted EBOM, while ERP (Enterprise Resource Planning) software systems gravitated towards MBOM. The “as x” notation increasingly reflected a product’s maturity level.

The Significance of These Names

Are these names merely labels, or do they hold substantial meaning? On one hand, they are just terms, allowing flexibility in product data model and reflecting different baselines in product development, lifecycle maturity and organization process. Yet, when it comes to a complex process coordination across business, engineering, and manufacturing sectors, achieving terminological alignment is crucial. It’s a balancing act between BOM type name freedom and the necessity for clarity in interdepartmental communications.

Identifying the Conflict

It is important to understand the underlying process of these names, how they formed in each organization and what is behind them – a unique product process, a specific way to structure a multi-level BOM, a definition of finished product or configurable BOM. Some BOM organization can reflect production process and sometimes a single level BOM is specifically done for simplicity of assembly BOM or production process. Sometimes a simplified BOM is built to support sales BOM and sales process. Including packaging materials or organizations of assembly process are also examples how different BOMs can be used.

From my experience, most examples of misalignment stem from terminological misunderstandings and disagreements, leading to frustration and inefficiency in organizations. This discord points to a deeper issue in the standardization of BOM terminology. It is very typical for people to bring their history and experience, so you should be sensitive to the suggestions of people to use one or another “system” how to call BOMs.

What Is Possible Solution? How To Resolve The Discourse?

In my view, each company often has its unique way of naming and understanding BOM types, be it EBOM, “as designed”, or CAD BOM. This naming dilemma is unlikely to find a universal solution. The pragmatic approach is to allow customers to define their own terms. As long as the overarching product model is coherent, the specific BOM Type naming used should be secondary. This perspective advocates for a holistic product model that accommodates multiple “BOM views”, as I discuss in my recent article Simplifying Complexity: Adopting a Digital Product Data Model in Place of Multiple BOMs.

What is my conclusion?

While it’s very important for companies to focus on terminological and process alignment, software vendors play a crucial role in this ecosystem. They should aim to reduce complexity, not increase it. In the space of BOM types, manufacturing process planning what’s essential is providing flexible data management models that allow companies to name and apply their BOM types as per their specific business logic. Let companies call their bill of materials in the way they want and need. They can call engineering bill “as designed” or “as planned”. Or they can call assembly BOM by manufacturing bill name. This approach of providing flexible product model with capability to support various bill of materials in proudct development, supply chain management and other stages of production systems in the way they want can improve coordination between people and different software components such as computer aided design (CAD), PLM, ERP. It will also improve coordination between different organizations – engineering departments, and others. Flexible data modeling approach distinguishes dynamic and robust digital platforms from rigid, monolithic legacy systems. These are my reflections on navigating the BOM types discourse, advocating for flexibility and clarity in an ever-evolving digital landscape. Just my thoughts…

Best, Oleg

Disclaimer: I’m co-founder and CEO of OpenBOM developing a digital-thread platform with cloud-native PDM & PLM capabilities to manage product data lifecycle and connect manufacturers, construction companies, and their supply chain networks. My opinion can be unintentionally biased.