A buyer spent a morning building the case for a volume price on a stainless M6 bolt. The supplier offered a break at 50,000 units a year. She pulled the annual usage and the three plants that buy the bolt came back at 19,000, 18,000, and 14,000: every one short of the threshold, all of them together well past it. It was the same bolt. The part number was not. Engineering had created it once, a second plant created it again under its own convention, and a third inherited a number from a system switched off in 2019. Three records, one bolt, and a discount nobody could claim because the BOMs that consume it each point somewhere different.
Bill of materials data is where a lot of organizations assume their item master is healthy, because the BOM resolves, work orders release, and the line keeps running. It runs because the ERP only needs each part number to point at something. It never checks whether two part numbers are the same part. That gap is invisible on the shop floor and costs real money everywhere the numbers get added up: spend analysis, inventory, planning, the annual stock count.
A BOM is two layers, and only one belongs in your MDM
A bill of materials looks like one object and behaves like two. The first layer is the structure: which parent is made of which children, how many of each, at what level, under which revision. That layer belongs to engineering. It changes through the engineering change process, it is versioned by revision, and an MDM has no business owning it. Leave it in the PLM or the ERP where the change control already lives.
The second layer is the set of items the structure hangs on. Every line in the tree is a part number, and every part number is supposed to resolve to one real component with a description, a unit, a supplier, and a lifecycle status. That layer is master data, and it is the half an MDM exists to govern. The MDM does not own the shape of the tree. It owns the identity of every node the tree depends on.
Get that boundary wrong in either direction and you pay for it. Pull the whole BOM into the MDM and you spend your days fighting the engineering change process for control of revisions. Leave the items ungoverned and the tree quietly fills with duplicates, phantoms, and references to parts that no longer exist.
Where the part numbers drift
None of these stop a work order. The BOM resolves, the line runs, and the damage shows up later as a number that will not reconcile.
The same part under several numbers
Engineering creates M6-BOLT-A, a second plant creates BOLT-M6-SS for the identical bolt, a third carries 100293 from an old system. Each plant BOM consumes its own. Procurement cannot consolidate the spend, inventory shows three SKUs of one fastener, and the planner forecasts each number separately against a third of the real demand.
The phantom that outlived the part
A component is superseded and its item record is end-dated, but an active BOM still lists it. The ERP keeps resolving the number because the record still exists, just flagged obsolete. Nobody notices until a work order tries to issue a part the warehouse stopped stocking two years ago.
The unit that does not match the stock
A BOM line consumes one each of a wire the warehouse stocks and counts in metres. The structure says one, the stockroom says 1.8 metres, and the backflush posts a number that means nothing. This is the unit-of-measure problem arriving through the BOM instead of the purchase order.
The substitute that points at nothing
An alternate part is listed against a line so the planner can swap it when the primary runs short. The substitute references a part number that was deleted in a cleanup. When the swap is finally needed, the alternate resolves to nothing and the line stalls at exactly the moment it was supposed to keep moving.
The supplier number smuggled in
Someone enters the vendor catalogue number as the part number because it was on the quote and it was quicker. Now the BOM is keyed to one supplier coding scheme. The day you dual-source the part, the BOM has to be rewritten, because the identifier it used belonged to the supplier, not to you.
The first one is the most expensive because nothing about it is wrong at the record level. Three valid parts, three valid BOMs, three valid work orders. The error only exists when you try to see across them, which is the view the shop floor never needs and the business always does. You can read more on why this happens in the post on duplicate master data.
The structure can stay where it is. The references cannot.
The fix is not to migrate the BOM into your MDM. The revisions, the effectivity, the engineering change orders: leave them in the system built to version them. What you govern is the item master underneath, so every part number in every BOM resolves to one record, with one owner, that means the same thing in every plant.
The bridge between the messy reality and the single record is a cross-reference table. M6-BOLT-A, BOLT-M6-SS, and 100293 all map to one master part, and each plant keeps using the number it has always used while the MDM knows the three are the same thing. You consolidate the spend without forcing three plants to re-key their BOMs overnight.
Effectivity is a date the item has to respect
BOM lines carry effective-from and effective-to dates, because a design changes and the new component takes over on a known day. That only works if the item master agrees. A component a BOM says is effective next month, against a part record that was end-dated last week, is a contradiction the ERP will happily resolve right up to the day the work order fails.
This is the slowly-changing-dimension question wearing work clothes. The part has a history, the BOM references a point in that history, and the two have to stay consistent. Govern the lifecycle status and the end-date on the item, validate them against the effectivity on the line, and the contradiction gets caught at the desk instead of on the line.
Govern the item, and the BOM stops lying
Everything above comes back to one rule: one part, one record. The work is in enforcing it when a part is created, not discovering the breach in a spend report a year later.
A few rules carry most of the weight. Dedupe at entry, so the second person to create the M6 bolt is shown the first one before they can save a twin. Use a surrogate identifier for the master part, so a part number can be renumbered or retired without breaking every BOM that joined on it. Enforce the unit of measure, so the consume unit on the line and the stock unit on the record reconcile. Put an owner and an approval step in front of new parts, so a new component has to be argued for instead of typed in a hurry by whoever needed it that afternoon.
If you are coming off MDS, this is a familiar shape. MDS could model the item as an entity and even hold a parent-child hierarchy through a derived attribute, which made it look like it could own a BOM. What it never enforced was one part, one record across plants. Each plant staging load created its own members, deduplication was a stewardship chore nobody was funded to do, and the cross-plant rollup lived in a spreadsheet someone rebuilt every quarter. Moving off MDS is the moment to make the item master singular, instead of carrying one item master per plant into the next system and calling it migrated.
Common questions
Should the bill of materials live in my MDM?
No. The BOM structure (parent-child links, quantity per, revisions, effectivity) belongs in the PLM or ERP that runs the engineering change process. What belongs in the MDM is the item master the BOM references: every part number resolving to one governed component. Govern the nodes, not the shape of the tree.
What part of a bill of materials is master data?
The items. Every line is a part number, and each one should resolve to a single master record with a description, a unit, a supplier, and a lifecycle status. The structure that links them is engineering data. The components it links are master data.
Why do the same parts end up with several part numbers?
Because each plant, system, or engineer that needs a part can usually create one without being shown the parts that already exist. Each record is valid on its own. They only become a problem when you total demand or spend across them and the BOMs each consume a different number for the same physical part.
How does an MDM help if the BOM stays in the ERP?
It governs the item master underneath. A cross-reference table maps every plant-local and legacy part number to one master part, so the BOMs keep their own numbers while spend, inventory, and planning see the part as one thing. Deduplication at entry stops new twins, and a surrogate identifier lets parts be renumbered without breaking the BOMs that join on them.
Make every BOM point at one item master
Primentra is the governed item master that sits under your BOMs: one record per part, deduped at entry, with an owner and an approval step in front of every new component, and a cross-reference table that maps the plant-local and legacy numbers to a single master ID. The BOM structure stays in your ERP. It runs on your own SQL Server, deploys in a day, and costs €7,500 per year flat. The 60-day trial runs against your real part data, which is long enough to find the duplicates your BOMs have been quietly consuming for years.