How do we handle KPIs that have no direct ISO 22400 equivalent?

It is normal to have KPIs that do not map cleanly to ISO 22400. You do not need to discard them, but you should treat them as controlled, plant-specific extensions and make the gaps and translations explicit.

1. Keep the KPI, but make its status explicit

Separate your KPI catalog into at least two groups:

• ISO 22400-aligned KPIs: KPIs that directly match an ISO 22400 KPI or can be expressed as a clear variant.
• Non-standard (local) KPIs: KPIs with no direct ISO 22400 equivalent.

For each non-standard KPI, document that it is not ISO 22400-defined. This avoids people assuming comparability or compliance that is not actually present, especially in audits or cross-site reviews.

2. Decompose the KPI into ISO 22400 building blocks where possible

Even if your KPI is unique, its components often align with ISO 22400 elements. For each KPI:

• Identify which base measures or concepts come from ISO 22400 (time categories, quantity types, states, etc.).
• Express your KPI, if possible, as a function of those ISO elements, for example:
  Local KPI X = f(ISO 22400 utilization time, ISO 22400 scrapped quantity, cost per unit time).
• Note any intentional deviations (e.g., a different way of classifying downtime or losses).

This decomposition supports traceability, cross-plant comparison, and future integration with MES/BI tools that are built around ISO 22400 structures.

3. Define and control the KPI like a spec

For any KPI without a direct ISO 22400 equivalent, manage it with similar rigor to a specification:

• Purpose: Why the KPI exists, what decision it supports.
• Exact formula: Numerator, denominator, units, aggregation period, and rounding rules.
• Inclusions/exclusions: What time, quantities, or events are counted vs excluded.
• Data sources: Systems of record (MES, ERP, historian, QMS, manual logs) and any transformations.
• Ownership: Who can change the definition, and how changes are approved and communicated.

In regulated environments, tie KPI definitions and changes to existing change control and validation processes. If KPIs feed into release decisions, quality metrics, or management reporting reviewed in audits, changes must be traceable.

4. Flag non-standard KPIs in tools and reports

In brownfield system landscapes, KPIs are often rendered through multiple tools (MES dashboards, data warehouse, BI, spreadsheets). To prevent misuse:

• Label KPIs as ISO 22400 or Local in data catalogs and semantic models.
• In reports and dashboards, include a short description or hover text clarifying when a KPI is non-standard or site-specific.
• For cross-site or corporate scorecards, restrict non-standard KPIs to local views unless you have harmonized definitions across sites.

This reduces the risk that management or auditors assume KPIs are comparable across plants or aligned to ISO 22400 when they are not.

5. Avoid forcing artificial mappings

Do not relabel a custom KPI as an ISO 22400 KPI just to “fit the model.” If the meaning, data set, or calculation does not actually match:

• Keep the KPI as local and clearly named.
• At most, reference the closest related ISO 22400 concept for context, explaining the differences.

Artificial mappings can create audit exposure, misinterpretation of performance, and confusion for new plants or teams trying to align to standards.

6. Plan for coexistence with legacy KPIs and systems

Most regulated plants already have entrenched KPI definitions embedded in:

• Legacy MES/SCADA logic and reports.
• ERP or planning rules.
• Quality dashboards and management reviews.
• Excel-based operational scorecards.

Full replacement of KPI logic to match ISO 22400 is rarely practical due to validation burden, re-training, and downtime risk. A more realistic approach is:

• Layered mapping: Introduce ISO 22400-aligned metrics alongside existing ones, rather than replacing everything at once.
• Dual reporting period: For a defined time, report both the legacy KPI and the nearest ISO-aligned KPI so stakeholders can understand differences.
• Controlled migration: If you decide to retire or modify a legacy KPI, treat it as a formal change with risk assessment, validation (where required), and documented impact on historical trends.

This approach respects brownfield constraints and reduces the risk of breaking established decision processes or audit trails.

7. Use governance to prevent KPI proliferation

Non-standard KPIs tend to multiply. To keep this under control:

• Maintain a central KPI catalog with ISO-22400-aligned and local KPIs, including version history.
• Require a minimal business case and governance review before adding new KPIs that are not in ISO 22400.
• Periodically review local KPIs to retire obsolete ones or align them more closely with ISO 22400 if practice has converged.

Strong governance helps keep metrics understandable to auditors, leadership, and new plants, while still leaving room for site-specific needs.

8. Connecting this to ISO 22400 adoption efforts

If you are adopting ISO 22400 into an existing environment, treat local KPIs without direct equivalents as part of your gap analysis. For each such KPI, decide whether it should be:

• Maintained as a local extension with clear documentation.
• Gradually converged towards an ISO 22400 metric over time.
• Retired because its purpose is now covered better by a standard KPI.

This incremental, documented approach keeps you aligned with ISO 22400 where it adds value, without disrupting validated systems or embedded operational practices.