How can we change a KPI definition without losing historical comparability?

You generally should not overwrite a KPI definition and pretend the history still means the same thing. If the definition changes materially, the safe answer is to treat it as a new KPI version and preserve the old one for historical reporting.

The goal is not to make unlike data look comparable. The goal is to keep historical interpretation honest, preserve traceability, and give stakeholders a controlled way to bridge old and new measures.

What to do in practice

• Version the KPI definition. Keep the prior formula, inclusion and exclusion rules, source systems, units, aggregation logic, and owner. Assign an effective date to the new version.

• Do not rewrite historical values by default. If old periods were calculated under a different rule set, keep those values tied to that rule set unless you can reliably recalculate them from retained raw data.

• Run both definitions in parallel for a period. A dual-run period is often the cleanest way to quantify the delta and show leadership what changed because of operations versus what changed because of measurement.

• Record the reason for change. For example: corrected business logic, changed production scope, improved data source, changed denominator, or harmonization across plants.

• Publish a comparability note with the KPI. Dashboards and reports should indicate that values before and after the effective date are not directly comparable unless explicitly normalized.

When back-calculation is possible

You can sometimes recalculate historical values under the new definition, but only if the necessary source data still exists at the right granularity and its lineage is trustworthy.

Back-calculation tends to be feasible when the change is formula-based and the underlying event data, timestamps, quantities, statuses, and master data mappings have been retained. It tends to fail when the new definition depends on data that was never captured, was captured inconsistently, or changed semantics over time across MES, ERP, PLM, QMS, historian, or spreadsheet-based reporting.

If you do back-calculate, keep both series:

• Original reported history for auditability and management traceability

• Restated history for trend analysis, clearly labeled as reconstructed under the new definition

Do not collapse them into one unlabeled time series.

What must be under change control

A KPI definition change is usually not just a dashboard edit. In regulated and high-traceability environments, it often affects management reporting, escalation thresholds, site comparisons, and evidence used in investigations or reviews. At minimum, control:

• definition and formula version

• data source mapping and transformation logic

• effective date and approval

• owner and steward

• affected reports, alerts, and downstream consumers

• validation of calculations after the change

If KPI values feed regulated records, quality decisions, or formal review processes, the validation burden may be higher. That depends on how the metric is used, not just where it is displayed.

Brownfield system reality

In mixed environments, historical comparability usually breaks because systems do not agree on the underlying business event. One plant may timestamp completion in MES, another in ERP, and a third may patch gaps manually. A KPI definition change can expose those differences rather than fix them.

That is why replacing every upstream system is rarely the practical answer. Full replacement often fails because of qualification burden, downtime risk, integration complexity, change control overhead, and the reality that long-lived equipment and legacy applications cannot be swapped out cleanly. In most plants, the workable approach is coexistence:

• define the KPI canonically

• map local source systems to that definition

• document plant-specific exceptions

• version changes centrally

• validate the reporting layer and interfaces carefully

If the source data model is weak, no governance process will create perfect comparability after the fact.

Tradeoffs to be explicit about

• Strict continuity versus honest measurement. Keeping one continuous line on a dashboard is visually convenient, but it can hide a meaning change.

• Back-calculation versus auditability. Restating history may improve analytics, but it must not erase what was originally reported.

• Cross-site standardization versus local practicality. A single KPI definition across plants is useful, but only if source-system mappings are mature enough to support it.

• Speed versus control. Fast KPI changes without governance create reporting drift and later disputes about performance.

A workable policy

A practical default policy is:

1. Classify the change as minor or material.

2. If material, create a new KPI version.

3. Maintain the old series unchanged.

4. Run both versions in parallel for an agreed period if possible.

5. Back-calculate only when raw data completeness and lineage are adequate.

6. Label all reports with version and effective date.

7. Approve through normal data governance and change control.

So the short answer is: change the KPI by versioning it, not by silently redefining history. Historical comparability can sometimes be approximated through dual-running or restatement, but it cannot be assumed.