Recently, I came across a thought-provoking LinkedIn article by Prof. Jörg Fischer, where he made a bold observation: “PLM vendors don’t understand MBOM.” According to Fischer, many in the PLM world treat MBOMs merely as restructured EBOMs, failing to understand their deeper role in manufacturing processes. That statement stuck with me.
It led me to revisit Fischer’s body of work, where he consistently emphasizes that MBOMs are not just a derivative of engineering outputs, but a representation of real manufacturing needs. In this blog, I want to unpack that idea and share my perspective — informed by my work with data models, PLM/ERP integrations, and practical implementations in manufacturing companies.
Let’s explore why the EBOM-MBOM conversation is not just about what system provides a better fit for EBOM or MBOM, but about how we treat data, semantics, and processes in the modern enterprise.
Understanding the Landscape: EBOM, MBOM, SBOM, and beyond
Everyone knows the acronyms: EBOM (Engineering BOM), MBOM (Manufacturing BOM), SBOM (Supply BOM), and more. These terms are widely used to define the different structures and views of product data in the enterprise.
But the acronyms themselves often obscure more than they reveal. At their core, BOMs represent logical data models (sometimes called “product structure” by PLM vendors) and by different names (yes, sometimes MBOM) by ERP vendors. Additional pieces of information are blended and connected to these structures. But those are ways of structuring and connecting information to serve specific business needs. Historically, these data models evolved inside enterprise applications like CAD, PLM, ERP, MRP, and MES systems, each of which came to define and “own” its version of the BOM.
What’s important to realize is that these models were never just about structure. They were also business functions. Enterprise software vendors developed their applications to lock down specific data and workflows — the EBOM in PLM, the MBOM in ERP/MRP, the SBOM in service platforms — and monetize access to them.
A Historical Perspective: The Data Silos We Built
Enterprise software vendors didn’t start from the same place. CAD and PLM vendors came from the engineering side; ERP/MRP vendors from accounting and production planning; MES vendors from factory control systems. There are many others – procurement, supply chain, maintenance. Different production models such as engineering to order (ETO), configure to order (CTO), build to stock (BTS) and variations of them create large amount of logical model needs (for example Prof Fischer rightfully speak about CTO+ models). Each evolved to dominate a specific data domain — design, manufacturing, procurement, or operations.
But as these systems matured, they began to overlap. Suddenly, your MRP/ERP vendor wants to keep information about the product design (for business needs). Your PLM vendor wants to offer manufacturing process planning (to ensure seamless process). Your MES vendor is interested in inventory (to optimize planning). This convergence created a collision of data ownership — and confusion for customers (because this is how enterprise software business is built today)
The fundamental issue wasn’t the tools themselves, but how they approached the data. Each system brought its own assumptions, semantics, and processes. As a result, when a customer asked a simple question like “Where is the true product structure?” — the answer depended on which system you asked and what team you’re talking to. The roots of EBOM/MBOM conflict go to intersections of interests between PLM and ERP vendors as well as complexity of customer needs.
What Customers Really Need: Organized, Connected Information
In real life, manufacturers don’t care about whose software owns the EBOM or the MBOM. They also don’t care if the software called PLM, ERP, or something else. They care about making products, procuring parts, meeting deadlines, and keeping costs under control.
What customers really need is not another BOM structure, but a cohesive information model that supports their processes across engineering, manufacturing, and supply chain. But that’s easier said than done.
The reality is that each system — whether it’s Teamcenter, Windchill, 3DEXPERIENCE, SAP, or Oracle — comes with its own complex data model, specific logic, and often rigid integration paths. Combining these systems into a coherent whole without breaking processes or requiring massive customization is where the true challenge lies.
That’s where professionals, advisors and service providers step in — not to teach what MBOM “should” be, but to help organizations rationalize across these fragmented systems. It’s less about ideology, and more about making practical decisions within messy enterprise realities. But, in a competitive world, at the end of the days, it is about what software tool (PLM, ERP, etc) and what software vendor will be chosen. This is a reality of “data locking” and the market.
Let’s talk about semantics. BOM acronyms like EBOM and MBOM give a false sense of clarity. In reality, what they represent are deeply embedded and often incompatible process logics:
- EBOM is a reflection of how a product is designed — typically derived from CAD systems, managed in PLM, and structured by engineering intent.
- MBOM reflects how a product will be made — accounting for manufacturing steps, logistics, part substitutions, packaging, and more.
- Procurement BOMs or supply BOMs reflect vendor realities, multi-sourcing, and availability constraints.
Sometimes, these names are intertwined and different vendors use the same name to express different semantics and meaning. This is what happens with MBOM, for example.
These models are often implemented in separate systems (PLM, ERP, MES), each with its own lifecycle, object types, references, and constraints. And worse, they don’t always agree.
For example, what’s called a “Part” in PLM might be a material or SKU in ERP. What’s a “phantom assembly” in one system is a non-existent object in another. Each system insists it’s right — because it is, within its own context.
This is where Fischer’s statement becomes sharp: the PLM community often underestimates the depth of MBOM complexity because they view it through the lens of engineering structure, not manufacturing flow.
The EBOM-MBOM Conflict: Connecting Silos, Not Just Restructuring Trees
The so-called EBOM-MBOM “conflict” is not just about mapping two tree structures. It’s about connecting fundamentally different views of the product, each tied to real-world constraints.
- EBOMs are created during design and rarely reflect packaging, routing, or supply chain nuances.
- MBOMs include work centers, operations, tooling, supply chain, and vendor-specific choices that don’t exist in the engineering world.
The details of these data objects and their specific really depending on specific business process and logic required from the applications managing them.
Trying to “convert” EBOM to MBOM with rules and transformations works to a point. But without a shared semantic model — a way to understand and link meaning between domains — these connections are very fragile.
Moreover, enterprise systems are not built to play nice. PLM doesn’t want to give up ownership of data. ERP systems often resist external manipulation. Despite being “collaborative” for marketing, each tool’s business model is built for control, not collaboration.
So Where Do We Go From Here? Toward Open and Flexible Models
The future isn’t about building yet another BOM (or structure) view — it’s about creating shared, open data models that reflect the needs of multiple stakeholders and can live across applications. It’s about semantic interoperability, not just data synchronization.
New technologies — like graph data models, flexible object schemas, and AI driven workflows and integrations — give us the opportunity to model product structures and workflows in a way that reflects reality: messy, dynamic, and interconnected.
I believe this is the direction modern PLM and digital thread platforms should take. We need to move away from proprietary object definitions and TLA-speak, and toward composable, adaptable models that allow teams to connect design, manufacturing, and supply chain without fighting the tools.
This is one of the key areas I plan to explore further in upcoming articles — particularly around data federation, semantic modeling, and flexible BOM structures using new online services.
What is My Conclusion?
Prof. Fischer was right to challenge the status quo. MBOM is not just an engineering transformation – it’s a manufacturing and supply chain reality. And enterprise systems that don’t reflect this reality will continue to frustrate users and block transformation.
But we also need to look beyond TLAs and data ownership battles. Let’s talk about real workflows. Let’s build data models that reflect how companies actually work — not just how software vendors think they should.
If you’re a PLM architect, data modeler, or manufacturing systems expert — I’d love to hear your experience. How do you approach EBOM-MBOM transformation in your organization? What tools or methods have worked for you?
Just my thoughts…
Best, Oleg
Disclaimer: I’m the co-founder and CEO of OpenBOM, a digital-thread platform providing cloud-native collaborative and integration services between engineering tools including PDM, PLM, and ERP capabilities. With extensive experience in federated CAD-PDM and PLM architecture, I’m advocates for agile, open product models and cloud technologies in manufacturing. My opinion can be unintentionally biased
