On Monday, a group of us will sit down for Part 2 of the Future of PLM BOM debate. Michael Finocchiaro pulled the panel together, and the lineup is a good one: Brion Carroll, Patrick Hillberg, Rob Ferrone, David Schultz, and me. Part 1 asked why engineering and manufacturing still struggle to speak the same language. Part 2 asks a sharper question. What if manufacturing reality should drive engineering more than engineering drives manufacturing? On the table is everything that usually gets waved past: EBOM, MBOM, BOP, BOE, MES, ERP, manufacturing execution, service intent, spreadsheets, liability, and why “throw it over the wall” still refuses to die.
And then, before the webcast even started, the debate started anyway.
Prof. Dr. Jörg W. Fischer dropped a comment on the announcement that challenged the entire premise. His words: this is old-school, an MBOM in that form does not exist, what you usually refer to is the MCAD BOM, and the relevant structure is the MRP BOM, made of segments supplied to the correct locations in ERP. Those are the correct structures. No discussion needed. He then wrote a full follow-up post explaining why, walking through four distinct use cases people lump under one word, and landing on a flat conclusion: there is no MBOM, only BOMs and BOM segments we falsely subsume under the term.
That post collected something like fifty comments from people who actually do this work, and it is the richest material I have seen on this topic in years. I read all of it. This article is my attempt to set the table before Monday by working through what was actually said.
But I want to start by being honest about where this comes from, because the framing matters.
This is not a new fight. Jörg and I have been having it for a year.
If you have followed Beyond PLM or Jörg’s writing, none of this is sudden. About a year ago Jörg published his “Structure Theory,” tracing the origin of MBOM confusion in the PLM community back to its roots in automotive, Body in White, and the 3D-centric process planning that early PLM inherited and then oversold as the universal manufacturing structure (his earlier post is here). His historical argument was strong. What PLM vendors called MBOM was originally an in-process assembly tree, a manufacturing-oriented rework of the CAD BOM for virtual assembly planning before SOP. The actual MRP BOM, shaped by logistics, provisioning, local content, and controlling, was almost entirely out of scope, because in large OEMs nobody in PLM ever spoke to the people who built it.
I responded at the time with my own piece, arguing that the deeper problem was not structure at all but data semantics (Rethinking EBOM vs MBOM: The Real Problem is Data Semantics, Not Just Structure). My claim was that EBOM and MBOM are not two trees to be mapped, but business meanings encoded in structures, owned by different systems, each insisting it is right because within its own context it is. Mapping the trees is the easy part. Reconciling the meaning is the part that breaks.
When Jörg’s comment landed on the panel announcement, I told him, half seriously, that it was funny to challenge a discussion before it happened, and that I would rather have the conversation first and respond after. I also pointed him to a reading list, because calling a topic old-school and then justifying it with classic MRP material is a fun way to open a debate (5 Books to Start Your Bill of Materials Education). Michael, generous as ever, immediately invited Jörg to join the panel. Jörg has classes Monday, so he will join another time. Which means the responsibility to carry his argument into the room, fairly, falls to the rest of us.
So consider this the pre-game. A year ago, the fight was structure versus semantics. The new thread tells me the fight has gotten bigger, and that the thing we are all circling has a name we have not been using.
The practitioner who said the quiet part out loud
Buried in those fifty comments is the one that should have stopped everyone cold. Olaf Witt wrote that after a year of struggling with the MBOM, nobody has been able to show him a live process with traceability of engineering changes through the manufacturing structure. Not a slide. Not a reference architecture. A working process, in a real company, where you can see why the manufacturing definition changed and follow it back to the decision that caused it.
He has been asking the right question, and the reason he cannot find the answer is the reason we keep having this fight. Jörg is mostly right. And the place where he is wrong is the most interesting part of the whole argument. Let me work through both.
We have been fighting about the noun for twenty years
Let me name the fatigue before someone else does. This argument has run for two decades and resolved nothing. One commenter called it intellectual exercise for people with too much education, and on the current evidence it is hard to blame him. We keep returning to the same ring to settle whether the MBOM is one structure or several, whether ERP owns it or PLM does, whether it is a rearranged EBOM or something native to the factory. Nobody wins, because the question does not change any outcome. A company that resolves the definition still cannot show Olaf his live process.
So let me concede the structural argument completely and get it out of the way, because the fight worth having is on the other side of it.
Jörg is right, and his four use cases prove it
In his follow-up post, Jörg separated the MBOM into four use cases, and the separation is correct. Assembly scope, which is really an MCAD-derived structure carrying documents at the leaf level, not material. Material provisioning groups, which depend on space at the line and call-off timing. MRP level, where demand and supply are netted and dates and quantities get fixed. And the logistical industrial engineering cases, the BOM segments created for local content, operational make-or-buy, and consignment parts.
These are not one thing. They have different owners, different lifecycles, different constraints, and different consequences when they are wrong. Forcing them into a single persistent structure is the original sin, and Jörg is right to call it out. This is also not new ground between us. A year ago we went through his Structure Theory, where he traced the confusion back to automotive, Body in White, and the 3D-centric process planning that PLM inherited and then oversold as the universal manufacturing structure. I responded then that the deeper problem was data semantics, not just structure. We have both learned a lot since, and the thread under his latest post shows the industry has not moved an inch on the thing that actually matters.
It helps to be precise about the terms, because most of the confusion is vocabulary. An EBOM, or engineering BOM, describes what a product is, structured by engineering intent and usually derived from CAD. An MBOM, or manufacturing BOM, is meant to describe how a product is built, reorganized around assembly sequence, work centers, and the parts actually consumed on the floor. An MRP BOM is something else again: the structure ERP uses to net demand against supply, fix requirement dates, and calculate quantities for procurement and production orders. These three are not the same object renamed. They carry different meaning, live in different systems, change on different schedules, and answer to different owners. The reason “MBOM” causes endless argument is that people use the single word for all of them, and sometimes for the bill of process and the service BOM on top.
So I will say it plainly. There is no single MBOM. Jörg wins that point.
He is wrong about what its absence means.
The fairies are the whole story
The most revealing line in Jörg’s post is not an argument. It is an aside. He writes about the magic of the fairies who, deep within companies, conjure up the MRP BOM. The logistical industrial engineering that has no real home in many organizations but still happens silently.
Read that again, not as a metaphor but as a confession. He is describing knowledge that is real, load-bearing, and undocumented. It lives in the head of the production engineer who knows which sequence the line can actually run, which supplier deviation got waved through last quarter, why this plant builds it differently from that one. The thread is full of the same ghost under different names. Pedro Branco calls the manufacturing structure the Money BOM, the place where mistakes are most expensive and good data fulfills the PLM dream. Jochen Hein describes companies exporting a parts list out of NX and typing it into SAP by hand, with Teamcenter sitting uselessly in between, and asks how you make them see it is a dead-end road. Olaf cannot find his live process with change traceability.
These are not five separate problems. They are one problem wearing five coats. The structures exist. ERP holds them, MES executes them, Excel patches the gaps between them. What has no home is the reasoning that connects them. The fairies are not magic. They are tribal knowledge, and tribal knowledge is just memory nobody wrote down.
That is the reframe. The absence of a single MBOM is not evidence that manufacturing meaning belongs scattered across ERP fragments. It is evidence that manufacturing meaning has no home at all. The answer is not to argue about which structure should hold it. The answer is to give it one.
Connecting the structures does not recover the meaning
The strongest alternative on the panel will be the digital thread position. Patrick Hillberg argues it well: get rid of the EBOM, maintain an end-to-end thread across create, build, support, and dispose, and give each actor a purpose-driven view into it instead of a pile of competing xBOMs. Ashutosh Sharma made the same case in the thread. It is a good idea and I agree with most of it.
But a thread connects artifacts. It connects the things that already exist in some structure. And Hillberg himself, in the same comment thread, handed over the example that shows why connection is not enough.
A designer pulls a pump from a catalog. The pump arrives with a coupling. The coupling never makes it into the EBOM or the MBOM, because it shipped inside the pump as a single catalog item. But the coupling wears far faster than the pump, so the service organization needs to provision it, and now the Service BOM needs information that appeared in no upstream structure at all.
Thread the existing BOMs together as tightly as you like. You will not recover that coupling, because it was never an artifact in any structure for the thread to link. What is missing is not a connection. It is a captured fact: this pump arrives with a coupling, and the coupling wears faster than the pump. That is context, and context is exactly what no BOM was built to hold.
A structure can hold what a product contains. It cannot hold why we changed it, what we rejected, or what the factory quietly knows that engineering never wrote down. The digital thread connects the what. The missing layer is the why.
The honest counterargument, and where it breaks
I want to take the best objection seriously, because it deserves it. Serge Driendl-Struß made it: with SAP, you do not need four BOM types. PS BOM transfer, well-crafted project networks for assembly and staging, production orders, and the right material master MRP configuration will carry assembly scope, provisioning, plant layout, and logistical dependencies inside a single mBOM. From deep project experience, he is right, and most companies lack the resources to manage four separate structures anyway.
So concede it. You can engineer one structure to bear the whole load inside one system. The context loss does not show up there. It shows up in two places that no single structure reaches.
It shows up across boundaries, when the constraint that justified the structure lives in a system that does not hold the structure. And it shows up across time, when the engineer who configured those project networks leaves, and takes with him the reasoning for why they are shaped the way they are. The configuration survives. The justification does not. Six months later someone changes a network because the constraint it encoded is invisible, and the line cannot run the sequence anymore. The structure was never wrong. It just never carried its own reason for existing.
Anton Semianin put the friendly version of the defense best: the map is not the territory, but you still need the map. He is right, and I would only push one step past him. The map is fine. But maps do not record why you chose this route over the one that floods every spring. Product Memory is not a better map. It is the route history.
AI is the forcing function, not the feature
Here is why this stops being a vocabulary argument and starts having consequences. Everyone on the panel will gesture at AI agents. Most of that gesturing assumes the agent will read our structures and make the confusion go away.
It will do the opposite. Feed an AI agent five disconnected BOMs and it will not resolve the confusion. It will industrialize it. An agent has no production engineer’s intuition to fall back on, no fairies to conjure the missing context. Ask it the one question manufacturing actually cares about, can we build this as released, and it needs exactly what no tree contains. It needs Ken Chen’s capability-bound constraints, the approved process capability and tooling and station conditions that make a manufacturing definition valid in a specific plant. It needs the rejected alternatives, the waived deviations, the reason the sequence is what it is. None of that lives in a structure. All of it lives in the heads of the fairies.
So the AI agents are not the reason to build Product Memory. They are the reason we can no longer avoid it. For thirty years we got away with leaving manufacturing reasoning undocumented, because a human always knew. Hand the work to an agent and the gap stops being a tolerable inefficiency and becomes the thing that makes the agent dangerous.
Conclusion: The fight worth having on Monday
So I do not think the interesting question is whether the MBOM exists. Jörg already settled that, and he is right. The monolithic MBOM is dead.
The questions I want the panel to sit with are sharper. What manufacturing meaning are we trying to preserve, and where does it currently go to die? Why can Olaf not find a single live process with change traceability after a year of looking? When the factory redlines the design, what carries the reason back upstream, and how fast? Why does Excel survive every PLM transformation, if not because it is the only place tribal knowledge ever finds to live? And when we hand all of this to an AI agent, what exactly do we expect it to read?
Jörg is right that the MBOM does not exist as one structure. He is wrong about what its absence means. The absence is not a filing problem to be solved in ERP. It is a memory problem. We have spent twenty years arguing about which container should hold manufacturing truth, while the truth itself, the reasoning, the constraints, the rejected paths, the silent knowledge of the people who make it real, has had no container at all.
That is the fight worth having. Not EBOM versus MBOM. Whether we can give manufacturing meaning a home before it disappears into ERP transactions, MES execution, spreadsheets, and the memory of people who will eventually leave.
Just my thoughts. See you Monday on the webinar.
Best, Oleg
Disclaimer: I’m the co-founder and CEO of OpenBOM, an AI-native collaborative digital thread platform connecting engineers and manufacturing teams. My opinion can be unintentionally biased.
