BOM Management. Multiple BOM Views. These topic are always drives lots of discussion in a real life and online. There is no question about importance of BOM in product development, engineering, manufacturing… Literally, you cannot do anything without Bill of Materials.
Few weeks ago, I came with the topic that generated a very good and healthy discussion – Will PLM Manage Enterprise BOM? A bigger part of the discussion happened in PLM LinkedIn group. You need to have LinkedIn user to access that. In a nutshell, the discussion was about an influence PLM and ERP both have on BOM management in the organization. The topic is not restricted to PLM and ERP. However, it is clear that PLM and ERP are playing major roles in how BOM managed in organization and how enterprise BOM management solution can be architected.
BOM Golden Rule
I’m sure you are familiar with Golden Rule. Satirical definition of this rule says “Whoever has the gold, makes the rules“. Here is manufacturing definition of the rule – “Whoever owns the BOM, makes the rules“. This is very true in many aspects and it explains a lot of what happens in every manufacturing organization in terms of how enterprise systems are positioned. They people work in the majority of organizations these days can be summarized as following – don’t touch my BOM. You can think about design / engineering, manufacturing, sales, supply, plant and many others. Every department or organization is creating their own BOM and then trying to synchronize it during product development process with other BOMs.
I’ve seen multiple attempts to create an alignment between various enterprise systems. Here is an example of product vs. transactional alignment between PLM and ERP provided by one of my blogging buddies – Edward Lopategui from E[E] blog. I took the following passage from LinkedIn discussion:
I think part of the problem is the divide between PLM and ERP, where PLM has always been product focused while ERP is transaction focused. While few dispute that PLM has the superior BOM capability, the ERP transactional dependencies perpetuate the legacy need to continually instance MBOM on the ERP side. And since PLM does not have an acceptable equivalent of those transactional capabilities, expect the divide to continue into the foreseeable future.
You can explain what are differences between BOM in PLM and ERP from product, system and technological standpoint. However, the political influence in organization can make this type of effort meaningless. One of my permanent discussion opponents, Dr. Michael Grieves (Consultant at NASA and author of Product Lifecycle Management: Driving the Next Generation of Lean Thinking book) provided the examples of factors here:
Where the MBOM resides is going to be dependent on both technical, political, and legacy factors. Technical factors include the complexity of the product, how often the MBOM changes and who drives those changes, whether an MES system exists,… Political factors include whether the strategic direction is toward ERP or PLM. Legacy factors include what systems are currently in place for MBOM control. Compounding these issues is that ERP companies are moving into PLM solution spaces and vice-versa.
EBOM vs. MBOM
From technical standpoint, it is relatively easy to explain the difference between EBOM and MBOM. The first (EBOM) represents they way product is designed (structure, models, functionality, configurations, etc.) The variety of characteristics are depending on the type of manufacturing and processes. Manufacturing BOM defines how product will be produced (including aspects of material ordering, routing, different manufacturing plants, etc.).
EBOM and MBOM are not entirely different but data structures and attributes used in both are often not overlapping. Some engineering attributes and structures are not relevant for MBOM (or cannot be stored using MRP/ERP systems). On the other sides, MBOM information is often irrelevant and not needed for engineers and designers.
The thing that makes everything complicated is a process between these two worlds. The “throw over the wall” manufacturing concept co-exists together with tightly collaborative process of work on EBOM and MBOM. Engineers are requested to provide information about product (EBOM) as early as possible in the development cycle. At the same time, manufacturing planning can get back to engineering in order to finalize and optimize product. Very often, both BOMs (but mainly MBOM) can be used for external planing systems.
What is my conclusion? BOM is one of the most important information pieces in product development. It comes on different stages of development – design, engineering, manufacturing, supply, etc. Because of different reasons – technical, political and organizational, the most widely adopted BOM implementation practice is to split BOM into separate pieces (views) reflecting application domains. At the same time, modern business and manufacturing practices require better integration of processes around BOM. PLM vs. ERP. Engineering BOM vs. Manufacturing BOM. The debates about how to organize them in a better way are heating up in every organization. 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.
