Should we run old and new KPI definitions in parallel?

In most regulated and high-consequence manufacturing environments, you should run old and new KPI definitions in parallel for a limited, well-governed period. The goal is to validate the new definition, quantify the impact of the change, and protect continuity of decision making and auditability.

Why parallel KPIs are usually necessary

Changing KPI definitions (for example OEE, NPT, COPQ, on-time delivery) is not just a reporting tweak. It affects trend baselines, targets, incentive plans, and potentially regulatory or customer-facing reporting. Running old and new definitions side by side helps you:

• Quantify the delta: See how much the new definition shifts the metric (e.g., OEE drops by 5–7% because planned minor stops are now counted as downtime).
• Validate logic and data: Confirm the new calculation is implemented correctly across MES, data lake, BI tools, and any manual processes.
• Maintain continuity: Allow leadership to keep using the old KPI for critical decisions until they trust the new one, especially when tied to SLAs or contracts.
• Protect auditability: Preserve a traceable bridge between historical performance and post-change values for customers, regulators, and internal audit.

Key constraints and tradeoffs

Parallel KPIs are not free, and if they are poorly controlled they create confusion.

• Overhead: Two sets of calculations, validations, and reports increase workload for operations, IT, and data teams.
• Conflicting decisions: If leadership is not aligned on which KPI definition drives which decisions, teams can cherry-pick the more favorable number.
• System complexity: In brownfield landscapes, KPI logic may live in multiple places (MES, historian, spreadsheets, BI tools). Keeping old and new definitions in sync across all of them is non-trivial.
• Extended ambiguity: If you do not time-box and govern the parallel period, you risk never fully retiring the old KPI.

When parallel run is strongly recommended

Parallel operation is especially important when:

• The KPI is used in regulatory submissions, customer scorecards, or contract penalties.
• The KPI feeds annual targets, bonuses, or supplier agreements.
• The change modifies scope or inclusion rules (e.g., which downtime codes count, which defects are in COPQ, how rework is treated).
• You are changing systems (e.g., new MES, data platform, or reporting tool) and re-implementing KPI logic.

Skipping a parallel run in these situations pushes risk into audits, customer reviews, and financial reporting, where remediation is costly and slow.

When a brief or no parallel run may be acceptable

You may opt for a very short parallel period, or none at all, if all of the following are true:

• The KPI is internal-only and not used in external reporting, contracts, or regulatory submissions.
• The change is a minor clarification with negligible expected numeric impact.
• You have independent validation of the new logic (e.g., reconciled against sample calculations or an offline model).
• Stakeholders explicitly agree to re-baseline and accept a visible step change in the chart.

Even in these cases, clearly documenting the change and its effect on comparability is still important.

How to run old and new definitions in parallel without chaos

If you decide to run KPIs in parallel, treat it as a controlled change, not an informal experiment.

1. Define scope and ownership
   • Specify which KPIs are changing, on which assets, lines, or plants.
   • Assign an owner for the definition, implementation, and approval of the new logic (often a joint operations/quality/IT responsibility).
2. Time-box the parallel period
   • Set a clear start and target end date (e.g., 3 to 6 months) and criteria for exit (stability of results, stakeholder sign-off, successful validation).
   • Communicate upfront when the old KPI will be retired from dashboards.
3. Label KPIs explicitly
   • Use unambiguous names in dashboards and reports (e.g., “OEE (legacy definition)” vs “OEE (2025 definition)”).
   • Add footnotes indicating what changed and from which date each definition applies.
4. Control how KPIs are used
   • Decide which version drives targets, escalation thresholds, and incentives during the transition.
   • Document these rules so supervisors and analysts cannot unintentionally mix them.
5. Validate data and calculations
   • Perform sample-level reconciliation: compare new KPI values against manual or offline calculations.
   • Check every integration path where KPI data flows (MES, historian, ETL jobs, reports, exports to ERP/PLM/QMS).
   • Record validation evidence and approvals for future audits and internal reviews.
6. Create a bridge and re-baseline plan
   • Quantify typical differences between old and new definitions over the parallel period.
   • Prepare “bridge” views that show both lines together and explain the step change when the old definition is dropped.

Brownfield and long-lifecycle system considerations

In brownfield environments, KPI logic may be implemented differently in multiple systems and spreadsheets. Replacing those implementations outright often fails because of validation burden, downtime risk, and hidden dependencies.

Parallel operation lets you:

• Identify discrepancies between systems that were assumed to be aligned.
• Phase in new calculations by asset, line, or site without breaking existing workflows.
• Demonstrate equivalence (or controlled non-equivalence) to existing metrics before retiring legacy implementations.

This approach respects long equipment and system lifecycles while still moving toward more consistent, better-governed metrics.

Bottom line

Yes, you usually should run old and new KPI definitions in parallel, but as a controlled, time-bound transition with clear labeling, governance, and validation. The purpose is to manage risk, maintain traceability, and build trust in the new numbers, not to keep two permanent versions of the truth.