What Is Bill of Materials (BOM) Master Data?

A bill of materials (BOM) is the structured list of every component, subassembly, raw material, and quantity needed to make a product. BOM master data is that structure treated as governed master data - a shared, authoritative, version-controlled reference that many systems and teams depend on, rather than a spreadsheet that lives in one engineer's folder. If the product is the noun, the BOM is its recipe, and BOM master data is the discipline of keeping that recipe correct, consistent, and trustworthy everywhere it is used.

The BOM is one of the most consequential records in any manufacturing business. It drives what gets purchased, what gets built, what a product costs, and - when something goes wrong - what has to be recalled. A single wrong quantity or an outdated revision propagates into procurement orders, production plans, and cost calculations. That leverage is exactly why the BOM belongs in the category of master data that must be actively governed rather than passively stored.

What BOM Master Data Is

A BOM is hierarchical. At the top is the finished product; beneath it are assemblies and subassemblies; at the leaves are individual parts and raw materials. Each parent-child link carries a quantity ("this assembly needs four of that bracket") and a unit of measure. A multi-level BOM captures the full tree; a single-level BOM shows only the immediate children of one item.

Treating the BOM as master data means going beyond the structure to govern its lifecycle:

• Identity - every item has a stable, unique part number, not a free-text name that varies by system.
• Revision and effectivity - which version of the BOM applies, and from which date or serial number a change takes effect.
• Ownership - who is authoritative for each attribute and who approves changes.
• Quality - rules that catch missing quantities, invalid units, or components that do not exist in the item master.

eBOM, mBOM, and Other Views

A crucial subtlety: a single product does not have one BOM. It has several, each serving a different purpose, and keeping them aligned is most of the challenge.

• Engineering BOM (eBOM) - created in the PLM system, it reflects the product as designed. It is organized around function and design intent, groups parts the way engineers think about them, and is driven by CAD.
• Manufacturing BOM (mBOM) - created in the ERP or MES, it reflects the product as built. It includes items the eBOM omits (adhesives, consumables, packaging), is organized around the assembly sequence, and ties to work centers and routings.
• Service and sales BOMs - views for spare-part support or for configurable, sellable options, which may differ again from both eBOM and mBOM.

The eBOM-to-mBOM transformation is a real, error-prone process. An engineering change has to be translated into a manufacturing change, and if that translation is manual or delayed, the two BOMs silently diverge - the classic source of "the drawing says one thing, the line builds another."

Why BOM Data Drifts

BOM data is unusually prone to inconsistency because it lives in multiple systems, changes constantly, and is edited by different teams under time pressure. The recurring failure modes:

• Multi-system fragmentation. PLM owns the eBOM, ERP owns the mBOM, MES consumes both. Without a governed link, a change in one does not reliably reach the others.
• Revision and effectivity confusion. Which revision is current, and when a change takes effect (by date, by serial number, by lot), is easy to get wrong - and expensive when it is.
• Inconsistent identifiers and units. The same physical part carries different part numbers across systems, or a quantity in "each" in one place and "meters" in another.
• Unclear ownership. When no one is authoritative for a given attribute, conflicting edits accumulate and no one is accountable for reconciling them.

Because the BOM feeds procurement, production, and costing, each of these defects converts directly into money and risk: parts ordered that are not needed, builds missing components, product costs that are quietly wrong, and recalls that take longer because no one is sure which units contain the affected part.

Governing BOM as Master Data

Governing the BOM means applying master data discipline to it. There is a defined authoritative source for each attribute - the PLM is authoritative for design, the ERP for manufacturing execution - and everything else consumes rather than re-keys. Changes flow through a controlled process with revisions, effectivity, and approvals, not ad-hoc edits. Every item has a stable identifier and consistent units. There is clear ownership for each part of the structure, and quality rules that catch the common defects automatically. And there is traceability - the ability to see how a change propagates, which is what makes both engineering changes and recalls manageable rather than frightening. This is the same master data management pattern that applies to customer or product master data, specialized for the hierarchical, multi-view nature of the BOM.

How Dawiso Fits

Dawiso is not a PLM or an ERP - it does not author BOMs or manage engineering change orders. What it governs is the layer above those systems: where BOM data lives, what it means, who owns it, and whether it can be trusted.

• A catalog of where BOM data lives. The data catalog documents the PLM, ERP, and MES datasets that hold BOM and item-master data, with owners and descriptions, so the organization has one map of its product-structure landscape instead of tribal knowledge.
• Shared definitions. The business glossary defines "eBOM," "mBOM," "effectivity," and "authoritative source" once, so PLM, ERP, and manufacturing teams reconcile against a shared vocabulary.
• Ownership and quality. Dawiso records who is authoritative for each dataset and attaches data quality expectations, turning "who owns the mBOM" into a governed answer.
• Traceability across systems. Interactive lineage shows how BOM data flows from PLM into ERP and downstream, so drift is visible and the impact of a change can be traced.

The operational systems build and change the BOM; Dawiso provides the governed context that keeps the many views of that BOM understood, owned, and trustworthy across the enterprise.

Conclusion

The bill of materials is the recipe every downstream process reads from, and BOM master data is the discipline of keeping that recipe authoritative, versioned, and consistent everywhere it is used. The hard part is that one product carries several BOMs - engineering, manufacturing, service - spread across PLM, ERP, and MES, drifting apart through mismatched identifiers, stale revisions, and unclear ownership. Treating the BOM as governed master data, with an authoritative source per attribute, controlled change, clear ownership, and traceability, is what turns it from a recurring source of wrong purchases and painful recalls into a reliable backbone for making things.

Sources

• Wikipedia - Bill of materials (BOM structure, eBOM and mBOM, multi-level BOMs).