A blog by Oleg Shilovitsky
Information & Comments about Engineering and Manufacturing Software

How to Resolve BOM Types Discourse?

How to Resolve BOM Types Discourse?
Oleg
Oleg
27 January, 2024 | 5 min for reading

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.

Recent Posts

Also on BeyondPLM

4 6
29 September, 2024

Digital transformation is no longer just a buzzword—it’s a reality changing the way manufacturing companies work. Engineering teams and manufacturing...

16 December, 2012

The simplicity of DropBox and similar cloud based file storage makes it very attractive to many people. Engineers are not...

7 October, 2023

Long time ago, I visited a large company building mobile phones. One of the questions that was asked in the...

31 August, 2009

I’ve been reading blog post by Deelip related CATIA and SolidWorks and thought what can be the final solution for...

29 June, 2020

I spent time over the weekend watching Siemens RealizeLIVE event recording and catching up on the news about the new...

24 November, 2020

SaaS is a topic of many debates in the PLM industry these days. Back in the 2010s, the question was...

17 September, 2012

For many years, supply chain was a space that drove lots of attention. One of the major trends, I can...

19 February, 2012

After posting my last blog multi CAD and PDM- dead lock?, I’ve got quite many emails and calls. It again...

14 September, 2018

Earlier this week, I shared my perspective on cloud adoption in 2018, challenges of single tenant PLM architectures and differences between...

Blogroll

To the top