BOM
EBOM and MBOM: where does the bridge break?
Over four decades, Volvo Construction Equipment ended up with four separate PDM systems. The most telling line in PTC's case study: local production adaptations had no links to the EBOMs. Today the company runs Windchill at 15 sites and connects EBOM, MBOM and SBOM on one Digital Thread.
I know this story well. The bridge between engineering and manufacturing is where my projects lose the most time.
One product, two questions
The EBOM describes the product as the designer sees it: which parts exist and how they fit together by function. The MBOM describes the same product as the shop floor sees it: which part goes to which station, in which sequence, and which consumables go with it. Both are correct. They answer different questions.
Where it breaks: stations and consumables
In my experience the break happens during the transfer itself. Moving a part from EBOM to MBOM is easy. Adding the right workstation and the consumables it needs is the hard part, and companies tend to pick one of two approaches.
Some link every consumable one to one to its part and station. I think this is the more accurate way, because every quantity can be traced. The price is more revisions and more change management. Others collect consumables and their quantities in a separate tree inside the MBOM. That means fewer changes, but it is far more error prone and less precise.
Where should the MBOM live?
Prof. Jörg W. Fischer argues that a single MBOM does not really exist. Oleg Shilovitsky agrees on the structure, but says the real problem is the manufacturing knowledge that gets lost. I am for one MBOM. The more of these structures you have, the more complex they get and the harder they are to manage. AI will make that complexity easier to handle, but it should not become an excuse to multiply structures.
The MBOM belongs in PLM. PLM has to be the single source of truth, because the design engineer decides whether a material can be used. It is very hard for a manufacturing engineer or purchasing to judge technical decisions like that.
AI: from PoC to product
This transfer is where I expect AI to make the biggest difference. A simple example: calculate how much paint a sheet metal part needs from its surface area and add it to the MBOM. Today that runs on rules and manual effort; AI can do the calculation and write the result to the right station.
Right now, building MBOMs with AI is still at PoC level. At AI World 2026, Oracle showed EBOM changes flowing into the MBOMs of several organizations through one change order, but labelled it clearly as roadmap. My guess is that we will see this as a product within a year. AI will cut the errors in between and expose the differences between EBOM and MBOM at a glance, which also makes accountability checks easier to follow.
But AI cannot fix data that has no rules. The work for today is clear: keep the MBOM in PLM, and write down how consumables link to parts and stations. When AI arrives, the ground it works on should be ready.