Do we need to replace our ERP or MES to standardize KPIs?

No, not usually.

In most regulated manufacturing environments, KPI standardization is primarily a data definition, governance, and integration problem, not a mandatory ERP or MES replacement project. You can often standardize KPIs across plants and programs while keeping existing systems in place.

What you do need is a consistent measurement layer across those systems. That typically means agreeing on:

• common KPI definitions and formulas
• start and stop events for each metric
• master data alignment for items, work centers, operations, shifts, and reason codes
• time conventions, units of measure, and aggregation rules
• system-of-record responsibilities for each data element

If those basics are not controlled, replacing ERP or MES will not solve the underlying problem. It often just moves inconsistent logic into a newer platform.

When replacement is not necessary

You usually do not need full replacement if your current landscape can support reliable extraction, mapping, and reconciliation of the data needed for KPI calculation. That can be done through interfaces, a reporting layer, a manufacturing data model, or a governed analytics platform.

This is especially true in brownfield environments where plants have mixed vendors, custom transactions, legacy integrations, and long-lived assets. In those cases, coexistence is often the lower-risk path.

When replacement might still be justified

Replacement can be reasonable, but usually for broader operational reasons, not just KPI standardization. Examples include:

• the current system cannot expose required data reliably
• core transactions are too inconsistent across sites to govern
• customizations are unmaintainable
• the platform cannot support needed traceability, audit trail, or change control expectations
• vendor support, security posture, or infrastructure constraints create material operational risk

Even then, replacement is a business and risk decision, not a KPI shortcut.

Why full replacement often fails as a KPI strategy

In regulated, long lifecycle operations, full replacement strategies often fail because the burden is larger than the KPI problem itself. Common obstacles include qualification and validation effort, downtime risk, retraining, re-integration with PLM, QMS, SCADA, historians, and supplier systems, plus the need to preserve traceability and evidence continuity during transition.

A new ERP or MES may also force process changes that improve standardization in one area while breaking established local controls in another. If the plant cannot absorb the change, KPI consistency may get worse before it gets better.

What usually matters more than the platform

The practical path is to standardize semantics before standardizing software. That generally means:

• define a controlled KPI catalog
• assign data owners and approval rules
• map each KPI to source transactions and equipment events
• document plant-specific exceptions explicitly
• version formulas and threshold logic under change control
• validate calculations before using them for management decisions

Without that discipline, cross-plant comparisons are often misleading, even when all sites run the same ERP or MES.

Tradeoffs to expect

A coexistence approach is usually faster and less disruptive, but it has tradeoffs. You may need to maintain translation logic between systems, resolve data latency, handle imperfect master data, and accept that some KPIs can only be standardized approximately until source processes improve.

A replacement approach may reduce some long-term complexity, but it raises short-term implementation risk, validation effort, cutover risk, and adoption burden. In many aerospace-grade and similarly regulated environments, those costs are substantial.

So the short answer is no: you do not usually need to replace ERP or MES to standardize KPIs. You do need governed definitions, trustworthy mappings, disciplined change control, and enough integration quality to make cross-system comparisons credible.