How do we label KPIs that are outside the ISO 22400 framework?

KPIs that are outside the ISO 22400 framework can be used, but they should be labeled in a way that avoids any implied standardization while still making them usable across plants, systems, and audits.

1. Distinguish clearly between ISO 22400 and non-ISO KPIs

In KPI catalogs, reports, and dashboards, use explicit labeling so it is obvious which metrics are standardized and which are not. For example:

• ISO 22400 KPI: Use the ISO name, identifier, and unit where adopted without modification.
• ISO-derived KPI: If you have modified a formula, scope, or unit, label it as “ISO 22400-derived” and document the deviation.
• Local KPI: For KPIs that have no ISO 22400 equivalent or intentionally diverge, label them as “Local” or “Site-specific” KPIs.

This separation reduces the risk that non-standard KPIs are misinterpreted as ISO-compliant during internal reviews or external audits.

2. Use a structured naming convention

Define a naming pattern that indicates origin and scope. Example conventions (adapt to your environment):

• Standard (ISO) KPIs: ISO22400:<Category>:<KPI Code>:<Short Name>
• ISO-derived KPIs: ISO22400-DER:<Category>:<Plant or BU>:<Short Name>
• Local KPIs: LOCAL:<Function>:<Plant or BU>:<Short Name>

Whatever pattern you choose, apply it consistently in MES, data warehouses, BI tools, and documentation. In brownfield environments with many legacy reports, this is often rolled out gradually via change control.

3. Map non-ISO KPIs to ISO categories where it makes sense

Even if a KPI is outside ISO 22400, it can often be mapped conceptually to an ISO category (for example, availability, performance, quality, resource utilization). To keep this transparent:

• Maintain a KPI catalog that includes, for each KPI, an optional “Related ISO 22400 category” field.
• Use this only as a logical mapping, not as a compliance claim.
• Document when no reasonable ISO category exists and leave the field empty rather than forcing a fit.

This helps stakeholders understand how local metrics align with broader operational performance topics without implying that the metric itself is part of the standard.

4. Document definitions, formulas, and boundaries

For non-ISO KPIs, documentation matters more than the label itself, especially in regulated environments and long-lifecycle plants. For each KPI, document at minimum:

• Purpose and decision use: What decisions does this KPI support, and at what level (cell, line, plant, enterprise)?
• Exact formula and units: Include numerator, denominator, time base, and any exclusion rules.
• Data sources and systems: MES tags, historians, QMS records, ERP transactions, etc.
• Scope and applicability: Which sites, products, shifts, or technologies the KPI is valid for.
• Owner and steward: Who can approve changes.

This should live in a controlled repository (KPI catalog, data dictionary, or equivalent) under your existing document control and change management processes.

5. Integrate labeling into existing systems, not just documentation

In brownfield environments, the same KPI often appears across multiple systems: legacy MES screens, spreadsheets, BI dashboards, and reports. To keep labeling consistent:

• Introduce the ISO vs local status as a field in your KPI catalog and use that to drive how metrics are labeled in front-end tools.
• Where technically feasible, add a short prefix or badge in dashboards (for example, “ISO”, “ISO-derived”, “Local”).
• In data warehouses or data lakes, represent KPI type as a column (for example, kpi_standard_type with values like ISO22400, ISO22400_DERIVED, LOCAL).
• Apply changes gradually under change control to avoid breaking validated reports or interfaces.

Full replacement of legacy KPI definitions purely to align with ISO often fails in regulated settings due to validation effort, downtime risk, and change management burden. A coexistence model, with clear labeling, is typically more realistic.

6. Manage non-ISO KPIs under formal change control

Non-ISO KPIs can still be critical for operations and quality. Treat them as configuration items:

• Review and approve new KPIs through a cross-functional governance group (operations, quality, IT/OT, and sometimes finance).
• Version-control definitions and keep a change history detailing why the KPI was introduced or changed.
• Assess impact on validation and audit trails when modifying or retiring KPIs, especially those used in batch release, traceability, or regulatory reporting.

This reduces the risk of silent metric drift and conflicting values across systems and sites.

7. Communicate limitations explicitly

When you publish or use KPIs outside the ISO 22400 framework:

• State clearly in documentation and, where practical, in reports that the KPI is not an ISO 22400 standard metric.
• Avoid wording or abbreviations that could be confused with ISO 22400 KPI names or identifiers.
• Be explicit when comparing plants or suppliers that some metrics are local and not suitable for direct benchmarking.

This reduces misunderstanding during audits, customer visits, and internal performance reviews.

Summary

You can label KPIs outside ISO 22400 as long as you avoid implying standardization. The practical pattern in regulated, brownfield environments is:

• Use clear labels such as “ISO 22400”, “ISO 22400-derived”, and “Local” or “Site-specific”.
• Maintain a governed KPI catalog with precise definitions and optional conceptual mapping to ISO categories.
• Reflect KPI type in all systems where the metric appears, rolling out changes under existing change control and validation processes.