BOM Master Data Management: How Manufacturers Keep Product Structures Accurate

Ask most manufacturers what their most business-critical data is, and they’ll say material master. Ask them what causes the most operational chaos when it goes wrong, and nine times out of ten the answer is the bill of materials.

A BOM error doesn’t just cause a reporting problem. It causes a production run that builds the wrong product. Components that get consumed that shouldn’t. Materials that aren’t where they need to be when the line starts. By the time anyone realises the BOM was wrong, the damage is already done.

And yet BOM data governance is one of the most underdeveloped areas in manufacturing master data management. Most manufacturers have robust processes for almost everything except the data that sits at the heart of what they actually make.

This article covers what BOM master data management actually involves, why it goes wrong so consistently, and what keeping it accurate at scale actually looks like in practice.

 

What is a BOM and what does it contain?

A bill of materials is a structured list of every component, material, subassembly and quantity required to produce a finished product. Think of it as the recipe for everything you manufacture. Without it, production doesn’t know what to build, procurement doesn’t know what to order, and costing doesn’t know what the true cost of the product is.

In a manufacturing ERP like SAP, a BOM isn’t a single flat list. It’s a hierarchical structure. At the top is the finished product. Below that are subassemblies, each of which may have their own BOM. Below those are the raw materials and components that make up each subassembly. A complex manufactured product might have a BOM that runs hundreds of lines across multiple levels.

What’s in each line? At minimum: a component material number, a quantity, a unit of measure, and a validity date. In practice, BOMs in SAP also carry information about alternative items, scrap factors, issue storage locations, and operation assignments that link components to specific steps in the routing.

That’s a lot of data… And all of it has to be right.

The different types of BOM manufacturers deal with

Not all BOMs are the same, and understanding the distinctions matters for governance.

Engineering BOMs (EBOMs) are created by design and engineering teams, typically in PLM systems. They represent how a product is designed. They don’t necessarily reflect how it’s manufactured.

Manufacturing BOMs (MBOMs) are what actually drives production. They represent how a product is built, including packaging, processing steps, and any components added during assembly that aren’t part of the engineering design. This is the BOM that lives in your ERP and that production planning, procurement and costing all depend on.

The gap between EBOM and MBOM is where a lot of BOM data problems begin. Engineering changes get captured in the PLM system but don’t make it into the ERP. Or they make it into the ERP manually, which introduces transcription errors and delays. Or they make it into one plant’s BOM but not another’s.

Variant BOMs and configurable BOMs add another layer of complexity. Manufacturers producing products with multiple configurations — different sizes, options, regional variants — need BOM structures that can handle that variation without creating an unmanageable number of individual BOM records. Getting this wrong creates either explosion of complexity or loss of accuracy. Sometimes both.

Why BOM data goes wrong

Engineering changes without governed handoffs

This is the single biggest source of BOM inaccuracy in manufacturing. An engineer changes a component. The change is valid, approved, and documented in the PLM system. But getting that change into the manufacturing BOM in SAP involves someone manually making the update. And that manual step is where things go wrong.

The update gets made in one plant but not the other three. The wrong validity date gets entered. The quantity gets transcribed incorrectly. Or the update simply doesn’t happen at all because whoever was supposed to do it was busy with something else and it fell through.

The result is production running from a BOM that doesn’t reflect the current product design. Not because anyone was careless. Because the process relied on people manually bridging a gap that should have been closed by a governed system.

No single owner for BOM accuracy

In most manufacturing businesses, the BOM is touched by engineering, production planning, procurement and sometimes quality. Nobody owns it outright. Engineering owns the design. Planning owns the production logic. Procurement cares about the components. Quality cares about specifications.

When nobody owns the whole record, nobody notices when it starts to drift. Each team maintains the parts they care about and assumes everyone else is doing the same. They’re not always wrong. But when they are, it takes a long time for the inaccuracy to surface — and when it does, the root cause is hard to trace.

Multi-plant complexity

A manufacturer running multiple plants with the same or similar products needs plant-specific BOMs in SAP. A component that’s sourced differently in one plant, a subassembly that’s produced locally in one location but bought in at another — all of this creates BOM variants that need to be maintained independently but consistently.

Without governed processes for managing plant-specific BOMs, they diverge. Each plant maintains their version in isolation. What should be a single governed product structure becomes multiple slightly different versions that nobody has full visibility of.

Validity date errors

BOMs in SAP are date-controlled. A component is valid from a certain date. An engineering change takes effect on a specific date. Get the validity dates wrong and production picks up the new component before the old stock is consumed, or continues using the old component after the engineering change was supposed to take effect.

Validity date errors are subtle, easy to make manually, and can take time to manifest as operational problems. When they do, they’re difficult to diagnose because everything in the system looks correct at first glance.

What good BOM data governance looks like

Governed engineering change management

The most important thing you can do for BOM data accuracy is close the gap between your PLM system and your ERP BOM. Engineering changes should flow through a governed process that automatically triggers a BOM change request in SAP when an engineering change is approved, routes that request to the appropriate data owners for each affected plant, validates the change before it’s posted, and records the full audit trail linking the BOM change back to the original engineering change order.

This isn’t a technology problem alone. It’s a process design problem that technology then enforces. The process needs to define who owns BOM changes, what information is required to action them, and what approval is needed before they take effect.

Clear ownership by component and plant

Every BOM, and every view within a BOM, should have a named owner. Not a team. A person. Someone who is accountable for the accuracy of that record and who is notified when a change is proposed.

This sounds like a lot of names and a lot of notifications. In practice, once the ownership structure is set up within a governed MDM tool, it runs automatically. The right person gets the right request. They review, approve and move on. The overhead is much lower than the manual back-and-forth it replaces.

Validation rules at creation and change

A BOM should not be possible to create or change without meeting a defined set of validation rules. Required fields must be populated. Quantities must be positive. Units of measure must match the component material master. Validity dates must be within a logical range.

These rules sound basic. They catch a significant proportion of the errors that would otherwise make it into production. And they do it at the point of entry, before the bad data has had any operational impact.

Change history and audit trail

Every change to a BOM record should be traceable. Who requested the change. Who approved it. When it was made. What the previous values were. Why the change was made.

This isn’t just good practice for compliance audits, although it is that too. It’s operationally valuable. When a production problem traces back to a BOM change, having a full audit trail means the root cause can be identified in minutes rather than days of investigation.

Regular accuracy reviews

Governance prevents new errors from entering. It doesn’t automatically clean up what’s already there. Manufacturers should conduct structured BOM accuracy reviews on a defined cadence, checking for components linked to obsolete materials, BOMs where validity dates have lapsed without review, plant-specific BOMs that have diverged from the master structure without explanation, and BOMs that haven’t been touched in a defined period despite active production runs against them.

This doesn’t have to be a massive project. A well-configured MDM tool can surface these issues automatically. The review becomes a governed process of working through exceptions rather than a manual audit of thousands of records.

BOM governance in SAP: native tools vs dedicated MDM

SAP provides BOM management through CS01/CS02/CS03 transactions in ECC and equivalent functionality in S/4HANA. It’s functional. It’s what most manufacturers use.

What it doesn’t provide is a governed change request process with multi-step approvals, automatic routing based on plant and component type, integration with PLM-originated engineering changes, and a user interface that non-technical business users can work in without training.

SAP MDG extends some of this, but BOM is not a standard object in SAP MDG out of the box. Implementing governed BOM management through MDG requires significant custom development.

Purpose-built MDM tools like Maextro include BOM as a native governed object alongside material master, routings, production versions and the other master data objects that manufacturing operations depend on. Changes flow through configurable approval workflows. Validation rules are defined by the business without technical development. The audit trail is automatic. And because Maextro sits natively on SAP BTP, BOM changes flow directly into SAP without manual intervention.

For manufacturers running SAP who need to bring proper governance to their BOM data without a multi-year MDG implementation project, this is what the alternative looks like.

The Princes Group example

Princes Group, a leading food and beverage manufacturer, used Maextro to bring governance to their BOM and routing data across their SAP landscape. The challenge was familiar: BOMs maintained inconsistently across plants, engineering changes that relied on manual processes to reach the ERP, and no audit trail connecting BOM changes to the business decisions behind them.

The result after implementing Maextro was a governed process for BOM creation and change that runs automatically, routes to the right approvers, validates against defined rules, and posts to SAP without manual data entry. BOM accuracy improved. The manual effort of managing changes across plants reduced significantly. And when questions arise about why a BOM looks the way it does, the answer is a few clicks away rather than a conversation with whoever made the change.

 

If your BOM data isn’t governed, it isn’t accurate

That’s not a criticism. It’s just how it works. Without a governed process for creating and changing BOM records, accuracy depends entirely on the consistency of the people doing the work. People are inconsistent. Especially when they’re busy, working across multiple systems, and managing engineering change requests by email.

BOM master data management is about replacing that dependency on individual consistency with a system that enforces it. The same validation, the same approval, the same audit trail, every time, regardless of who’s making the change or which plant they’re working in.

If BOM data accuracy is a problem in your manufacturing operation, see how Maextro governs BOM and other manufacturing master data objects in practice.