BOM health: the numbers that show the process still works

The rules from this series - who owns which BOM, one change number, a compare-and-merge import, phase-out as an approved step - can be measured. Without measuring, they drift apart within a year, quietly, the same way BOMs do.

My proposal: a simple BI report over the ERP data, starting with three or four indicators and adding more only where it actually hurts.

Eight indicators

Indicator	What it reveals	Data in the ERP
1. Made items without a valid production version or BOM	Production runs outside the master data	Production versions; item-to-BOM assignment
2. Released engineering changes without a recorded decision on the MBOM (incorporated / no impact / pending)	Manufacturing engineering hasn’t caught up, or nobody wrote the decision down. A BOM date on its own is only a prompt to check	BOM headers and rows by usage; revisions
3. Lead time of a change - separately creation → release and release → effective	Where changes get stuck, and with whom	Change numbers and their status history or workflow, depending on set-up
4. BOM changes without a change number	The process is being bypassed	BOM change history
5. Intermediates with no movement in a chosen period	Items nobody needs	Stock documents
6. Phasing-out items with stock or open orders after the new state’s effective date	A phase-out at risk	Stock, open orders, follow-up item and phase-out date (stock by revision is only visible through a new item, batches or serial numbers)
7. Repeated deviations on the same part	A candidate for a permanent change	Production orders
8. Planned vs actual material consumption	Wrong consumption norms and loss percentages	Production orders and goods issues

Start with 1, 2 and 3. They tell you whether the process from this series is running at all.

Three things that decide whether the report is any use

Compare like with like. Every indicator has to respect plant, BOM usage and alternative, validity and status. Otherwise the report compares an engineering BOM with a production BOM, or yesterday’s state with next month’s - and shows problems that don’t exist, while hiding the real ones.

An owner outside IT. The report should belong to manufacturing engineering. If IT owns it, nobody reads it.

A number is a prompt, not a verdict. Indicator 2 in particular: a BOM that hasn’t changed after an engineering change can be perfectly right - if someone decided “no impact” and wrote it down. What you measure is whether the decision exists.

Where the data sits in SAP S/4HANA

For a Power BI model on SAP data, these are the starting points. The tables are indicative; validity and status always have to be taken into account.

Data	SAP S/4HANA
Production versions (BOM + routing combination)	MKAL - in S/4HANA a production version is mandatory for in-house production
Material-to-BOM assignment, incl. BOM usage (typically 1 = production, 2 = engineering)	MAST
BOM headers and items	STKO / STPO
Change numbers	AENR (Engineering Change Management)
Material documents (stock movements, goods issues to orders)	MATDOC
Phase-out: discontinuation flag, follow-up material, date	Material master, MRP 4 view

A simple model shape: one fact per indicator, shared dimensions for plant, material, BOM usage, change number and date. Indicator 1 is the easiest start: production versions (MKAL), BOM assignments (MAST) and the list of in-house produced materials.

The BOM series

1. Your ERP will import BOMs from Excel. The second import is the problem.
2. When does an intermediate deserve its own item number? Seven criteria
3. Engineering changes: one number, revision or new part, and where-used first
4. Ten tests for your BOM import before go-live
5. From Excel to PLM: six levels of EBOM-to-MBOM tooling
6. BOM health: the numbers that show the process still works (this note)
7. The quote is the first version of the BOM