Because matching the formula does not guarantee matching the meaning, source data, or counting rules behind it.
In practice, KPI variation across plants usually comes from differences in definitions, data capture, timing, and system behavior rather than the arithmetic itself. A shared formula can sit on top of different event models, different business rules, and different levels of data quality.
Where the differences usually come from
-
Different event definitions. One plant may count machine idle time from PLC state changes, while another uses operator-entered downtime codes. The formula may be identical, but the underlying events are not.
-
Different start and stop points. Plants often disagree on when a job, batch, operation, or shift officially starts and ends. That changes runtime, queue time, labor time, and schedule adherence.
-
Different inclusion and exclusion rules. Setup, first article activity, inspection holds, maintenance windows, rework, scrap, partial completions, and planned downtime are common sources of inconsistency.
-
Different source systems. One plant may calculate from MES events, another from ERP transactions, historian tags, spreadsheets, or manual logs. Those systems do not always represent the same reality at the same level of granularity.
-
Different timestamp logic. Time zone handling, shift cutoffs, delayed transaction posting, late data entry, and backdated corrections can materially change KPI values.
-
Different master data. Work centers, product families, routing versions, scrap codes, labor standards, and calendar definitions are often not harmonized across plants.
-
Different treatment of exceptions. Plants may handle aborted orders, split lots, subcontract steps, nonconformances, and engineering deviations differently. In regulated environments, those exceptions are common and materially affect reporting.
-
Different maturity of data governance. If one site has tighter change control, better code discipline, and fewer manual workarounds, its KPI output will generally be more stable.
Same formula, different semantics
This is usually a semantic governance problem before it is a math problem. A KPI needs more than a formula. It also needs a controlled definition of:
-
what business event is being measured
-
which records are in scope
-
which system is the system of record for each input
-
how corrections, overrides, and late entries are handled
-
which version of master data and routing logic applies
Without that, plants can claim standardization while still reporting different realities.
Brownfield reality
In mixed MES, ERP, PLM, QMS, historian, and spreadsheet environments, this problem is normal. Two plants can run the same corporate KPI formula and still diverge because their integrations, data latency, local coding practices, and transactional discipline differ.
That is also why full rip-and-replace programs often fail to solve KPI inconsistency on their own. Replacing systems does not automatically standardize event definitions, historical mappings, exception handling, validation evidence, or plant behavior. In regulated operations, the qualification burden, change control overhead, downtime risk, and integration complexity often make wholesale replacement slower and riskier than targeted harmonization.
What usually fixes it
The practical fix is to standardize the metric specification, not just the equation.
-
Create a controlled KPI definition with explicit inclusion, exclusion, and exception rules.
-
Define the canonical source for each input field.
-
Harmonize master data where possible, and document unavoidable local differences where not.
-
Version metric logic under change control.
-
Test the same sample scenarios across plants and compare outputs record by record.
-
Keep an auditable lineage from source transaction to reported KPI.
If that work is not done, the same KPI formula will continue to produce different values, and neither number is automatically wrong. They may simply be answering slightly different questions.