How do we label KPIs that are not part of ISO 22400?

It is completely acceptable to define and use KPIs that are not part of ISO 22400, but they should be labeled and governed so that nobody confuses them with the standard ISO indicators.

Keep a clear distinction from ISO 22400 KPIs

The first rule is to avoid implying that non-standard KPIs are part of ISO 22400. In practice, this usually means:

• Do not reuse ISO 22400 names or identifiers for different formulas.
• Do not describe non-standard KPIs as “ISO 22400 compliant” or “ISO KPIs” when they are not.
• Document explicitly when a KPI is site-specific, division-specific, or customer-specific.

Use a simple, explicit naming convention

Many regulated plants use a two-tier or three-tier convention so people and systems can distinguish standard vs local metrics at a glance. Examples (adapt the pattern, not the exact codes):

• ISO KPIs: Prefix or flag them clearly, such as ISO22400-xx plus the official name where relevant.
• Extended KPIs: Use a different prefix like EXT-, SITE-, or LOCAL-, for example SITE-OEE-variant or EXT-ReworkCostPerLot.
• Customer / program KPIs: If you have customer- or program-specific KPIs, use a distinct code such as CUST- or a contract reference.

The exact pattern is less important than consistency and clear differentiation from ISO identifiers. Be cautious about reusing common names like “OEE” without qualifiers if your formula diverges from ISO 22400 definitions.

Maintain a KPI catalog with metadata

In brownfield environments with multiple MES, BI, and reporting tools, label confusion often comes from missing documentation rather than the label itself. For non-ISO KPIs, keep a central catalog (spreadsheet, MDM, CMDB, or a dedicated KPI repository) that records at least:

• KPI ID and label: The code and human-readable name.
• Classification: For example, ISO22400, extended/site, customer/program, pilot/experimental.
• Definition and formula: Precise formula, data sources, units, and any filters or exclusions.
• Owner and approver: Who maintains the definition, and who approved it (important for change control).
• Scope: Sites, lines, products, or programs where it applies.
• Change history: Effective dates and rationale for any formula or label changes.

In validated or audited environments, treat this catalog like controlled documentation: versioned, reviewed, and change-controlled, even if it sits outside your QMS as a technical reference.

Be explicit about deviations from ISO definitions

Some organizations adapt ISO 22400 KPIs to fit historical practices or data limitations. When you deviate, you should:

• Use a modified name or suffix such as _adj, _legacy, or _site, rather than the plain ISO label.
• Document clearly how the formula differs from the ISO definition, including any missing states, approximations, or alternate time bases.
• Flag these KPIs in dashboards so users cannot mistake them for ISO-pure values.

If your goal is to migrate towards ISO definitions over time, keep both KPI versions for a defined overlap period and label them distinctly (for example, OEE_legacy and OEE_ISO22400) until the transition is complete.

Consider system coexistence and integration

In a brownfield stack, the same KPI label may be implemented differently in MES, historian, and BI tools. For non-ISO KPIs:

• Use the same ID and classification across systems wherever possible, even if the implementation details differ by vendor.
• Map local vendor-specific measures to your catalog IDs in integration layers, not in people’s heads.
• Validate that different systems produce consistent values for the same KPI ID within agreed tolerances.

Full replacement of existing KPI logic in legacy MES or reporting systems often fails or stalls because of validation burden, downtime risk, and the need to requalify metrics used in procedures or customer reports. A more realistic path is to overlay a KPI catalog and labeling scheme that can coexist with legacy definitions and be gradually harmonized.

Governance and change control

For KPIs that affect batch release, capacity decisions, or regulatory submissions, treat label and definition changes as controlled changes:

• Route changes through your existing change control processes.
• Assess impact on SOPs, work instructions, and validated reports.
• Maintain traceability between historical KPI series and new definitions so trend analyses remain interpretable.

Where the same non-ISO KPI is used across multiple plants or business units, agree on a shared definition and label before deploying to avoid conflicting local variants under the same name.

Practical starting pattern

If you do not already have a scheme, a pragmatic baseline that usually works is:

• ISO 22400 KPIs: ISO22400-[number]_[short-name]
• Extended/site KPIs: SITE-[site-code]_[short-name]
• Customer/program KPIs: PRG-[program-code]_[short-name]
• Pilot/experimental KPIs: PILOT_[short-name] (explicitly not for formal reporting)

Adapt these to your environment, but keep the main principle: make it impossible to confuse non-ISO KPIs with ISO 22400 indicators, and provide enough documentation that auditors, engineers, and managers can trace exactly what each label means and how it is calculated.