When the BOM No Longer Reflects What Is Installed
Across manufacturing and asset-intensive industries, there is a common master data assumption: what is recorded in the engineering Bill of Materials (BOM) matches what is actually installed on the shop floor, used in a project or operating in the field.
On a recent implementation for a major process manufacturer, we tested that assumption. We compared historical goods issues from completed work orders with the corresponding BOMs. Many components that had been consumed and installed were missing from the official BOM structure.
The plant was running, but its master data had drifted away from reality. Planners were ordering parts that were no longer used, while critical spare parts and subassemblies were missing from the BOMs used to support planning. This contributed to unnecessary inventory, gaps in replenishment planning and excess capital tied up in stock.
Many teams assume SAP Clean Core makes this kind of problem harder to solve by restricting custom development. In this case, its architectural principles helped us build a focused solution that reduced complexity and avoided modifications to core SAP code.
Why Operational Changes Fail to Reach Master Data
This gap is not always a matter of poor data discipline. It can also reflect a missing feedback loop between operational execution and master data maintenance.
Standard enterprise processes record goods issues against maintenance work orders, production orders, project stock or field service activities. However, recording consumption does not automatically mean that the relevant BOM is reviewed and updated. An order can be completed while the master data continues to describe an earlier version of reality.
Over time, substitutions, equipment modifications and replacement components widen that gap. The transaction history contains evidence of what changed, but someone still needs to identify which changes belong in the BOM.
Attempts to close the gap often take one of two forms:
- Manual reconciliation: Planners or master data teams compare spreadsheets with order histories. The work is repetitive, difficult to sustain and easily displaced by urgent operational demands.
- Deeply embedded custom logic: Teams add tightly coupled enhancements to standard order-processing routines. Depending on their design and the interfaces used, these customisations can increase technical debt and complicate upgrades.
A more sustainable approach makes discrepancy detection a separate, repeatable process, with a clear path from identification to approval.
Closing the Gap with an Automated Review Loop
We addressed the problem through an automated, “self-healing” review loop that separates discrepancy detection from standard transactional processing.
The term self-healing needs an important qualification: the solution identifies potential gaps automatically, but people remain responsible for approving master data changes. A consumed part is evidence to review, not proof that the BOM should change.
Using SAP tools and standard objects, we implemented three connected steps:
- Detect missing components automatically.
A background job compares net goods issues from closed orders with the components in the relevant active BOM. An anti-join identifies consumed parts that are absent from the BOM, creating a focused set of exceptions for review. - Give planners a clear approval workflow.
Those exceptions appear in a lightweight SAP Fiori elements list report. Planners assess whether each discrepancy reflects an emergency substitution, a one-off requirement or a lasting component change. This replaces broad manual reconciliation with targeted decisions. - Apply approved changes through standard interfaces.
Once approved, additions are written through SAP’s released transactional interfaces, with applicable engineering change numbers and audit controls respected. The approach avoids direct modifications to core source code.
The same underlying pattern can support equipment BOMs, production BOMs and field service assemblies, although the matching rules, approval requirements and available interfaces need to fit each use case.
The result is a repeatable feedback loop: operational history highlights potential gaps, planners validate the findings and approved changes improve the master record.
[Insert workflow graphic here]
Figure: The self-healing BOM review loop, from consumption analysis to planner approval and controlled master data updates.
Start with Execution Data to Improve BOM Accuracy
My advice to customers is to start with a focused comparison of completed orders and their relevant BOMs. Review the discrepancies to understand which reflect genuine master data gaps and which are valid exceptions.
If the same gaps recur, an automated review cockpit can turn occasional cleanup into an ongoing maintenance process.
The broader lesson is that SAP Clean Core can support business-specific innovation. Released interfaces, targeted extensions and clear approval controls provide a practical way to improve responsiveness while limiting technical debt. For BOM accuracy, that means creating a reliable connection between what operations consume and what planners can trust.
