Three plants, three dashboards. Plant A reports a scrap rate of 2.1%. Plant B, which produces the very same sub-assembly, reports 4.7%. Plant C doesn't report a scrap rate at all but a "first-pass non-conformance rate" of 3.2%. The plant director asks for a consolidation; three weeks later a summary file arrives, complete with a full page of footnotes explaining why the numbers aren't comparable.
Every leader of a multi-site group has lived this scene. The usual reflex: launch a KPI harmonization project, deploy a common BI layer, build a group data warehouse. That treats the symptom. The problem sits upstream, in the product data itself: bills of materials that diverge from site to site, incompatible item reference systems, technical definitions that share nothing but a name.
The symptom: KPIs that don't lie, but don't describe the same thing
Let's rule out a reassuring hypothesis right away: no, your plants aren't gaming their numbers. Each local KPI is calculated honestly, by competent teams. The problem lies elsewhere: each site calculates an indicator that is locally true on a locally defined basis.
Take the scrap rate. To compare it across two plants, you'd need to agree on at least three things: what a "part" is (a finished item? a sub-assembly? an operation?), what "scrap" is (a physical write-off? a rework? a downgrade?), and above all which bill of materials the indicator is computed on. That's exactly where everything diverges: Plant A calculates on its local MES's mBOM, Plant B on its ERP's manufacturing orders whose BOM structure was adapted four years ago, Plant C, acquired two years ago, still works on its legacy item reference system, mapped "as best as possible" to the group's.
$12.9M a year per organization: the average cost of poor data quality, with inconsistency across siloed sources ranked the hardest issue to fix (Gartner).
That figure is an average across all industries. In a multi-site group, where every investment decision, capacity allocation, or make-or-buy call rests on cross-plant comparisons, the real bill is probably higher, and above all invisible, diluted into suboptimal decisions no one ever traces back to their cause.
What the research documents
| Finding | Figure | Source |
|---|---|---|
| Average annual cost of poor data quality, per organization | $12.9M | Gartner |
| Data quality issue rated hardest to fix | Inconsistency across siloed sources | Gartner |
| Share of revenue lost to flawed data | 15 to 25% | MIT Sloan Management Review |
| Expected productivity gain from end-to-end data integration | up to 26% | McKinsey |
| Manufacturers stuck in "pilot purgatory," unable to scale across their plant network | a large majority | McKinsey |
| Escalating cost of an uncorrected error (1-10-100 rule): entered → propagated → decided on | ×1 → ×10 → ×10 | Dataversity |
The root cause: fragmented bill-of-materials data
Why is the BoM the tipping point? Because it's the backbone of nearly every industrial KPI: scrap rate, cost of production, service rate, OEE weighted by value produced, material impact of a change, all are calculated on a product structure. If that structure diverges between sites, the indicators diverge mechanically, even with perfectly harmonized calculation definitions.
This divergence isn't an accident. It's structural, and it has three sources.
It's this triad that makes your KPIs tell incompatible stories. The dashboard is just the last link in a chain where every upstream link introduces its own distortion.
Why the classic answers fail
Three answers come up systematically. All three have real value; none solves the underlying problem.
- +ERP harmonization. Three to seven years, an eight-figure budget, a scope that shrinks along the way. And even unified, an ERP removes neither the eBOM/mBOM derivation nor local process specifics: it moves the problem.
- +Data warehouses and group BI. Consolidation runs on fixed mappings, written once by teams unfamiliar with each site's business nuances. When the bill of materials changes, and it changes constantly, the mappings turn wrong. The report keeps coming out; it's simply less and less accurate.
- +Generic data governance. Naming data owners, writing a glossary, deploying a catalog: necessary, but insufficient if governance stays documentary. A glossary doesn't reconcile two mBOMs; at best it records their divergence.
McKinsey has documented the phenomenon at scale: a large majority of manufacturers stay stuck in pilot purgatory: promising pilots that never scale across the plant network, for lack of sufficient data foundations. The real pool of value sits in eliminating information loss at the interfaces: between functions, between sites, between companies. That's exactly where KPI inconsistencies live, and none of the three approaches addresses it head-on.
The digital thread: addressing continuity, not silos one by one
The digital thread rests on the idea of a continuous data thread linking product data from design through production, service and retirement. The idea isn't to replace existing systems, nor to force a single bill of materials on sites that have good reasons to run different mBOMs. The idea is to keep the link: know at any moment how Plant B's mBOM derives from the reference eBOM, which transformations were applied, and therefore exactly what each figure calculated on it actually covers.
The question changes shape. Instead of "why are your scrap rates different?" with no clean answer, since the calculation bases diverge, you can ask: "on the exact scope common to both sites, what's the real performance gap?" The first question generates justification meetings. The second generates decisions.
But the digital thread is a goal, not a technology. The question that follows immediately: what do you build it with, concretely, on top of a heterogeneous existing PLM/ERP/MES landscape that isn't up for replacement?
The knowledge graph: the infrastructure that makes the digital thread operational
A knowledge graph explicitly models what classic architectures leave implicit: this item in Plant B's ERP is an instance of this eBOM reference; this mBOM derives from this eBOM version via these transformations; this scrap rate is calculated on this bill-of-materials scope. Entities (items, bills of materials, sites, indicators, versions) and their relationships (derives from, replaces, is equivalent to, impacts) become first-class, queryable objects, without uprooting data from its source systems.
- +Comparability becomes computable. Instead of declaring two KPIs comparable and discovering six months later that they aren't, the graph lets you check: do both indicators rest on equivalent product structures? If not, where do they diverge, and is the gap material? The controller's footnote becomes a query.
- +Impact analysis becomes traversable. A design change lands: what's the real impact, site by site? With siloed bills of materials, the answer takes weeks of manual analysis. With a graph linking eBOMs, local mBOMs, stock and work-in-progress, propagation is traced by following relationships: which items, which routings, which open orders, which suppliers, in which plants.
- +The semantic layer prepares the ground for AI. Generative and agentic AI projects in industrial settings hit the same wall: no reliable context. Gartner positions semantic layers and graphs as the infrastructure that gives AI systems the definitions, relationships and guardrails needed for reliable, explainable answers. The same graph that reconciles your KPIs today is the foundation for your future industrial assistants.
What this changes for your business
Picture the Monday-morning scene again, a year later. The performance review no longer opens with a debate about the numbers: each consolidated indicator carries its own lineage: bill-of-materials scope, version, transformations applied. When two sites diverge, the first question is no longer "who's right?" but "is this a performance gap or a scope gap?" And the answer is available in the meeting, not three weeks later.
Where to start
- +Pick a use case that's painful and measurable. Analyzing the multi-site impact of a design change is often the best candidate: everyone knows the pain, the lost time is quantifiable, the result is verifiable. Avoid starting with an abstraction like "group data governance."
- +Don't chase model completeness. A graph lives and grows. Model only the entities and relationships strictly needed for the chosen use case first; the temptation of the perfect ontology before any deployment is the surest way to end up in pilot purgatory.
- +Treat reconciliation as an ongoing process, not a project. Your bills of materials will diverge again tomorrow: that's normal life for an industrial group. The graph's value isn't freezing a reconciliation in time, but making divergence permanently visible and its cost explicit.
Incompatible KPIs aren't a reporting problem: they're the visible symptom of fragmented product data. The good news, contrary to what the ERP reflex suggests: fixing this doesn't require rebuilding everything. It requires connecting what already exists.
Sources cited
- Gartner, Data Quality: Why It Matters and How to Achieve It — average cost of poor data quality and cross-source inconsistency as the #1 issue.
- McKinsey & Company, Capturing the true value of Industry 4.0 — information loss at the interfaces and "pilot purgatory."
- Siemens, Steps for effective BOM management in the ETO change process — risks of eBOM/mBOM misalignment.
- Arena Solutions (PTC), BOM Reconciliation — the challenges of bill-of-materials reconciliation.
- T. Redman, MIT Sloan Management Review — share of revenue lost to flawed data.