BOM Data Integrity in a “Post‑BOM” World (and Why I Disagree)

Reading “2026 – The year we have to unlearn BOMs!” immediately brought back decades of scars from broken configurations, field failures, and costly recalls rooted in poor BOM data integrity. The thesis that classic assemblies and traditional BOM thinking have become obsolete misses the very real consequences when EBOM, MBOM, and customer drawings drift out of alignment. I fear we are putting our feet on the road to the de-evolution of product management- that may not be a good thing.

In recent consultations, we have witnessed the consequences of the diminishing thread between the engineering, manufacturing, and customer documentation. We can say that there was little upside, and plenty of downside. I am not a youngster, and do not refer to myself as a musician; I’m more of a bass-playing mimic, and I have strong thoughts on the difference between music from the 70s-80s, or even the 90s, and today. I believe music has backslid to what it is today with few exceptions. I am not sure we should let this backsliding continue. Substitute methods, sure thing, but those substitutions should be as good as today, or better than the olden days.

BOM Data Integrity and Real‑World Product Risk

In my work across automotive, heavy vehicles, and industrial products, the bill of materials is not a relic from the 1990s—it is a control mechanism that directly impacts safety, cost, and customer trust. When BOM data integrity fails, warranty costs spike, misbuilds occur, and recall campaigns follow, regardless of how modern the PLM or ERP stack appears.

That is why unlearning BOMs outright is dangerous; the real need is to relearn disciplined configuration management, not to discard the very structure that keeps product definition, manufacturing, and service synchronized.

EBOM, MBOM, and Customer Drawings: How They Should Connect

From a configuration management perspective (as discussed extensively in Configuration Management: Theory, Practice, and Application and Modernizing Product Development Processes), the EBOM, MBOM, and customer drawings are different views of the same product intent. Each has a distinct role, and the integrity of BOM data ties them together.

Product and documentation ideally are congruent.

EBOM (Engineering Bill of Materials)

- Represents the design intent and functional structure of the product.
- Usually derived from CAD and systems models, with part numbers, specifications, tolerances, and revision control tightly governed in PLM or PDM systems.
- Connects directly to customer drawings and internal engineering drawings, which are revision‑controlled documents describing geometry and requirements. The EBOM references those documents as part attributes or relationships, ensuring that a specific EBOM revision always points to the correct drawing revision.
MBOM (Manufacturing Bill of Materials)
- Represents how the product is built, sequenced, and sometimes kitted in the plant, often aligned with workstations, operations, or routing steps in ERP/MES.
- Enriches the EBOM with manufacturing‑specific information: alternative materials, packaging units, phantom assemblies, tooling references, and line‑specific groupings.
- Must remain traceable back to the EBOM and its drawing set so that every manufacturing change can be evaluated against engineering requirements, approvals, and compliance obligations.
Customer Drawings and External Specifications
- For OEM customers, the “drawing” may be an external specification, 3D model with PMI, or a standards‑based definition that constrains the EBOM.
- The EBOM parts are mapped to the customer documents via explicit references (drawing number, specification number, version) so that any change on the customer side triggers a controlled review and, if needed, EBOM/MBOM updates.

When that triangle—EBOM, MBOM, drawings—is stable and traceable, the configuration state is understandable at any point in time, enabling reliable testing, PPAP, and serial‑number level traceability into the field.

Types of BOMs: More Than EBOM and MBOM

While the article focuses on assemblies and attempts to move past classical BOM logic, in practice, organizations operate with multiple BOM types that each serve a specific governance purpose. Some of the most common include:

EBOM (Engineering BOM) – Design view, functional hierarchy, tied to drawings, requirements, and verification artifacts.
MBOM (Manufacturing BOM) – Production view, aligned to processes, routings, and line constraints in ERP and MES.
SBOM / Service BOM – Field‑service view, often simplified to what technicians need to replace, diagnose, and order as spare parts.
CBOM / Configured BOM – Customer or order‑specific BOM generated from rules, options, or modular kits for CTO/CTO+ scenarios.
DBOM / CAD BOM / Design BOM – Geometric or model‑centric view closely tied to 3D CAD structure, which may not exactly match the EBOM’s logical product breakdown.

In my experience, problems rarely arise from having multiple BOM types; they arise when BOM data integrity across those views is weak—no clear source of truth, poor change propagation, and inconsistent revision semantics. This often means poor configuration management, poor document connectivity – hierarchy-oriented.

BOM Assemblies, Technical Order Structures, and the “Unlearn BOMs” Argument

The article argues that classic assemblies are obsolete and proposes transitioning to Technical Order Structures (TOS) and ERP‑near structures derived from hybrid modular kits, with BOM segments generated subsequently. That idea overlaps with configuration‑driven, variant‑oriented architectures that I have seen work well—when governed robustly.

However, there are several issues if this shift is used to justify relaxing BOM discipline:

Topic	Claim from “unlearn BOMs” post	Perspective from configuration management practice
Role of assemblies	Classic assemblies are obsolete; we only need non‑semantic groupings for pre‑production steering.	Assemblies, whether classic or generated, still carry meaning for testing, certification, and service; collapsing them into “non‑semantic” groups risks losing traceability to requirements and verification coverage.
EBOM material vs. document revisions	EBOM is about materials and is non‑revisioned; the documents are revision-controlled and only need to be linked correctly.	Treating engineering materials as effectively non‑revisioned is an invitation to configuration chaos; in regulated and safety‑critical domains, material master, EBOM, and documents must be coherently revision‑controlled.
New flow (TOS → BOM segments)	Hybrid modular kit drives a Technical Order Structure, from which ERP BOM segments are generated; CAD‑BOM → EBOM → MBOM is obsolete.	Generating BOM segments from configuration structures is valuable, but it does not eliminate the need for explicit EBOM/MBOM relationships, effective management, and clear governance to prevent unapproved, emergent variants in the field.
Decoupling spec from transaction	Spec (BOM and documents) should be decoupled from transactional order data, rather than “seamless integration.”	Decoupling is sensible—specification and transaction lifecycles are different—but only if the link between them remains rigorous enough to reconstruct exactly what was built, shipped, and installed at any point in time.

Digital threads, MBSE, and graph‑based semantics are powerful, but they do not replace the need for auditable structures that a quality engineer, auditor, or safety assessor can understand without a PhD in data modeling.

Pros and Cons of Challenging Traditional BOM Veracity

There is value in challenging 1990s BOM thinking, especially as products become more software‑intensive, connected, and configurable in the field; however, the proposed “unlearning” of BOMs carries both strengths and weaknesses.

Pros of the “unlearn BOMs” perspective

Highlights limitations of CAD‑centric thinking
- Many organizations still treat the CAD structure as the de facto EBOM and then casually handwave the transformation into MBOM, which leads to manual re‑work, misalignment, and errors.
- Highlighting this dependency prompts teams to design PLM/ERP data models that reflect configuration logic, product options, and cross‑domain impacts rather than a simplistic CAD tree.
Emphasizes configuration‑driven structures and modular kits
- For complex configurable products, order‑driven structures (TOS, CBOM) are a necessary evolution, allowing mass customization without exploding EBOM and MBOM variants.
- This aligns with the configuration management principles of variant management and effectiveness, where rules and constraints generate consistent product definitions at order time.
Encourages decoupling specification from transactions
- Separating long‑lived product definitions from shorter‑lived orders, work orders, and production batches can clarify responsibilities and lifecycle ownership.
- When done correctly, this reduces the temptation to use ERP line items as “shadow specifications,” which is a recurring anti‑pattern in manufacturing organizations.

Cons and risks of the “unlearn BOMs” narrative

Underestimates the importance of BOM governance
- Suggesting that EBOM material is effectively non‑revisioned undermines the core of configuration management, in which every combination of parts, software, and settings must be reconstructable to ensure safety, compliance, and liability.
- Many of the most severe quality issues observed in automotive and industrial products originate from uncontrolled or poorly synchronized EBOM and MBOM changes.
Potentially weakens traceability to customer drawings and requirements
- Moving away from recognizable assemblies without strengthening traceability to customer drawings, requirements, and verification plans can make it harder to prove that the as‑built configuration actually satisfies the as‑specified intent.
- Regulatory environments (functional safety, emissions, cybersecurity) increasingly demand transparent traceability chains, rather than opaque, generated structures that only the IT stack fully understands.
Risk of replacing one complexity with another
- Hybrid modular kits, TOS, and graph‑based semantics add conceptual load; if organizations have not mastered basic BOM data integrity, introducing more layers can amplify confusion rather than resolve it.
- Without strong roles, processes, and clear ownership—topics I emphasize in my work on total quality management and product development—fancy data models simply mask underlying gaps in discipline.
Ignores the human and organizational learning curve
- Designers, manufacturing engineers, buyers, and quality engineers have built shared mental models around EBOM and MBOM; abruptly declaring these obsolete without carefully managed change, training, and transitional governance will create more misalignment, not less.
- Improvements must respect that people debug problems and reason about risk through structures they can interpret; configuration complexity cannot be left solely to tools.

Toward Reliable BOMs: Strengthening, Not Unlearning

Rather than unlearning BOMs, the path forward is to strengthen the integrity of BOM data while embracing new configuration approaches. That means:

Defining clear ownership and governance for EBOM, MBOM, and their relationships, including how customer drawings and external specs are referenced and approved.
Implementing integrated, but decoupled, PLM‑ERP‑MES flows where EBOM changes drive controlled MBOM and routing updates with explicit effectivity and impact analysis.
Using configuration rules and modular structures to generate order‑specific BOMs while maintaining auditable links back to stable, revision‑controlled product definitions, test configurations, and compliance evidence.

The future will absolutely demand better product data models, digital threads, and configuration‑driven structures, but none of that reduces the need for disciplined, transparent, and auditable bills of materials anchored in sound configuration management practice.