Can I keep my existing KPI names and still align with ISO 22400?

Yes, you can usually keep your existing KPI names and still align with ISO 22400, as long as you treat ISO 22400 as the reference model behind the scenes and rigorously map your internal KPIs to its definitions. The standard cares about what you measure, how you calculate it, and the scope and timing of the measurement, not about your local naming conventions.

What “alignment” actually means

Alignment with ISO 22400 in practice means:

• Your KPI semantics (what is included or excluded) match the ISO 22400 definition, or you can clearly state and justify how they differ.
• Your formulas and time bases (e.g., shift, day, order, line) are consistent with the standard or are explicitly documented as variants.
• Your data sources and aggregation logic are stable, traceable, and version-controlled.
• You can provide a clear mapping from your internal KPI catalog to ISO 22400 KPIs and attributes.

None of this requires you to rename dashboards or change the labels operators and supervisors see every day, as long as you can show the translation clearly.

Where names can become a problem

You run into trouble when KPI names are reused for metrics that do not match ISO 22400 definitions. Common issues include:

• Calling a metric “OEE” but using a different formula, or mixing availability, performance, and quality in nonstandard ways.
• Using terms like “availability” or “utilization” without a consistent definition across lines, plants, or systems.
• Letting MES, SCADA, and reporting tools each implement their own version of the same KPI name.

In these cases, simply claiming ISO 22400 alignment while keeping the old semantics is not credible. You either need to adjust the metric to conform or document it as a deliberate deviation and avoid presenting it as a canonical ISO 22400 KPI.

Practical way to keep names and gain ISO 22400 structure

A workable approach in brownfield, regulated environments is to separate the reference model from the user-facing language:

1. Build a KPI dictionary. For each existing KPI, document:
   • Internal name as shown in your systems.
   • Definition, formula, and exclusions/inclusions.
   • Time base (per batch, order, shift, day, etc.).
   • Data sources (MES, ERP, historians, manual logs).
2. Map to ISO 22400. For each internal KPI, specify:
   • Which ISO 22400 KPI(s) it corresponds to, or whether it has no direct equivalent.
   • Any known differences (e.g., you include planned maintenance in downtime; ISO 22400 variant does not).
3. Implement a translation layer. In your reporting and analytics stack, maintain a technical layer where each metric has an ISO 22400-compliant identifier, with your legacy KPI names treated as aliases.
4. Govern changes. Use change control when modifying KPI formulas or mappings. Version the KPI dictionary so you can reconstruct what a given report meant at a point in time.
5. Expose both views for cross-functional stakeholders. Show local names on the shop floor if that aids adoption, but make the ISO 22400 equivalents visible to engineering, quality, and corporate teams who need standardized comparison.

Dependencies in real plants

Keeping your existing KPI names while aligning with ISO 22400 depends heavily on:

• Process maturity. Plants with ad hoc KPI definitions will need restructuring before any honest claim of alignment.
• Integration quality. If your MES, ERP, historians, and manual logs are not reconciled, two KPIs with the same name may not be comparable across systems.
• Validation and change control. In regulated environments, shifting formulas to match ISO 22400 can trigger validation work, documentation updates, and training. Wholesale renaming of KPIs can increase this burden without adding value.
• System lifecycle and downtime limits. Replatforming KPIs into a single new tool to “fix naming” can be risky if it forces major MES or reporting cutovers. A staged mapping approach often carries less risk.

Because of these constraints, many plants adopt ISO 22400 progressively: first standardizing the underlying calculations and mappings, then selectively updating labels in new or revalidated systems.

Why full KPI renaming is often not worth it

Completely renaming all KPIs to match ISO 22400 terminology can create more disruption than benefit in long-lifecycle, highly regulated operations:

• Operator and supervisor confusion. Long-used terms change overnight, while the underlying behavior and expectations do not.
• Document and training updates. Procedures, WI, training materials, and governance documents may need revision and re-approval.
• Historical trend breaks. Analytics that rely on KPI labels could misinterpret or fragment long-term performance data.
• Validation cost. For validated systems, even a label change can trigger impacts that must be assessed, documented, and in some cases re-tested.

For many aerospace and defense manufacturers, a mapping and alias strategy delivers most of the benefit of ISO 22400 without incurring the full burden of a naming “big bang.”

How to present ISO 22400 alignment credibly

If you want to state that your KPI framework is aligned with ISO 22400 without promising outcomes you cannot guarantee, focus on demonstrable facts:

• Keep clear, version-controlled documentation of KPI definitions and ISO 22400 mappings.
• Show where your implementation follows the standard exactly and where it intentionally diverges.
• Ensure your digital systems (MES, analytics, reporting) implement the documented formulas and scopes consistently.
• Be explicit that ISO 22400 alignment is about standardization and comparability, not an assurance of compliance or audit results.

In short, you can usually keep your existing KPI names, but alignment with ISO 22400 is only credible if the underlying definitions, formulas, and mappings are disciplined, maintained, and transparent.