You usually do not reconcile them by forcing them into one number. In most transitions, the correct approach is to run the old and new KPI calculations in parallel for a defined period, document exactly why they differ, and control how each number is used.
If the KPI definition, event timing, data source, filtering logic, master data, or exception handling changed, then the numbers are not directly comparable. Calling them the same KPI can create confusion in management reviews, root cause work, and audit trails.
Freeze the old and new definitions. Record formula, source systems, timestamps, inclusion and exclusion rules, and owner for each version.
Run a parallel period. Calculate both KPI versions side by side long enough to capture normal operating variation, not just one good or bad week.
Build a variance register. For each gap, identify whether the cause is definition drift, transaction timing, missing master data, integration latency, event granularity, user behavior, or data quality issues.
Classify differences. Some differences are expected and acceptable. Others indicate broken interfaces, inconsistent business rules, or uncontrolled local workarounds.
Publish both values with labels. Use clear naming such as legacy OTD and current OTD during the transition. Do not present a blended value unless you can defend the method.
Set a cutover rule. Define when the organization will stop using the legacy KPI for decision-making, and who approves that change.
Sometimes you can create a bridge between old and new KPI numbers, but only if the logic difference is narrow and stable. For example, if one system timestamps completion at work order close and the other at final operation signoff, you may be able to quantify the expected offset.
That bridge should be treated as a temporary analytical aid, not proof that the two KPIs are equivalent. If process behavior, routing structure, scrap handling, rework loops, or calendar logic differ, a simple factor or adjustment will not hold for long.
Different start and stop events
Different treatment of rework, holds, and partial completions
Different production calendars or shift cutoffs
Latency between MES, ERP, QMS, historian, or manual logs
Changed master data, routing versions, or product structures
Improved data capture in the new system that exposes losses the old method missed
Local spreadsheet corrections that were never governed
In mixed environments, KPI mismatch is often an integration and governance problem, not just a dashboard problem. Legacy MES, ERP, PLM, QMS, spreadsheets, and machine data may all represent the same event differently. Reconciliation depends on interface quality, timestamp consistency, transaction discipline, and how much local plant variation still exists.
That is why full replacement is rarely the clean answer in regulated, long-lifecycle operations. Replacing everything at once often creates more comparability problems because qualification burden, validation effort, downtime risk, and integration complexity are high. A phased coexistence model with controlled definitions is usually more realistic.
Treat KPI reconciliation as a controlled change. That means defined ownership, versioned business rules, approval of definition changes, retained history, and traceability back to source records. If leadership wants one enterprise number, agree first on the canonical definition and document where plants or systems still deviate.
If the new KPI is better, say so plainly, but do not rewrite history. Keep the legacy series intact, mark the transition date, and explain the discontinuity. That preserves credibility and makes later investigations easier.
The short answer is: reconcile by parallel run, variance analysis, and governed cutover. Do not pretend old and new numbers are directly comparable unless you have proven that they are.
Whether you're managing 1 site or 100, Connect 981 adapts to your environment and scales with your needs—without the complexity of traditional systems.
Whether you're managing 1 site or 100, C-981 adapts to your environment and scales with your needs—without the complexity of traditional systems.