Use labeling that makes the link to ISO 22400 explicit and traceable, while still readable for operators and managers. In regulated, brownfield environments, the priority is clarity, consistency, and unambiguous mapping to the standard and to your validated configuration.
Use a consistent naming pattern
Pick a standard pattern and apply it on every dashboard, report, and export. Common workable options are:
- “ISO 22400 KPI <number>: <standard name>”
Example: “ISO 22400 KPI 1: Availability”
- “ISO 22400-2 K<2-digit code> – <standard name>”
Example: “ISO 22400-2 K01 – Availability”
- For OEE-related metrics:
“ISO 22400 K01 – Availability (OEE component)”
“ISO 22400 K02 – Performance (OEE component)”
“ISO 22400 K03 – Quality rate (OEE component)”
The key is that the label clearly states the standard and KPI code so it can be traced back to your requirements, configuration, and validation documentation.
Show definitions, units, and time basis
Labels alone are not enough in regulated environments. Make the KPI definition transparent at the point of use:
- Include units directly in the label or sublabel, for example: “ISO 22400 K01 – Availability [%]” or “ISO 22400 K09 – Production time [min]”.
- Indicate time basis where it affects interpretation, for example: “… (shift)”, “… (last 24h)”, “… (rolling 30 days)”.
- Expose the formula via a hover tooltip, info icon, or drill-down page. The visible label should match a controlled definition in a specification or data dictionary.
This makes it easier for engineers, quality, and auditors to validate that what the screen shows matches the approved definition.
Handle site-specific variants explicitly
Many plants cannot implement ISO 22400 definitions 1:1 because of legacy data models, partial integrations, or local business rules. If you must deviate:
- Use a variant label, for example: “ISO 22400 K01 – Availability (site variant)”.
- Document the difference in a controlled specification (for example, data dictionary, MES configuration spec, or dashboard design doc) and reference that in validation records.
- Avoid ambiguous renaming. Do not call a non-standard metric simply “OEE” or “Availability” without indicating it is a modified definition.
In mixed-vendor MES/SCADA/ERP stacks, different systems may compute similar KPIs differently. Make the system of origin or method visible where conflicts are likely, for example: “ISO 22400 K01 – Availability (MES)” vs “… (SCADA)”.
Align labels with your MES/ERP and procedures
To avoid confusion in brownfield environments:
- Align terminology across dashboards, MES screens, batch records, and SOPs. If MES uses “Equipment availability”, your dashboard label might be “ISO 22400 K01 – Equipment availability” to bridge both.
- Use a governed data dictionary or master KPI catalog that lists: ISO 22400 code, standard name, local display label, units, calculation method, and system(s) providing the data.
- Control changes via your existing change control process. A label change that alters the meaning, formula, or data source should be reviewed and, where applicable, revalidated.
Full replacement of existing KPI naming across legacy systems is often risky and resource-intensive due to the need to update SOPs, training, qualification evidence, and audit trails. In many plants, a pragmatic overlay approach is used: add ISO 22400 codes to labels and documentation while existing local terms remain visible.
Make drill-down and traceability available
Dashboards in regulated operations should let a knowledgeable user trace what a KPI number represents:
- Provide a details view where users can see the ISO 22400 code, full name, formula, aggregation rules, and exclusions (for example, which downtime categories are included).
- Link to controlled documents such as KPI specifications or functional requirements, instead of embedding long definitions directly on the chart.
- Ensure consistency across views. A label used on a line-level dashboard should match the label used in corporate performance summaries for the same KPI definition.
Practical labeling examples
Here are examples of clear labels that balance ISO fidelity and operator readability:
- “ISO 22400-2 K01 – Availability [% per shift]”
- “ISO 22400-2 K03 – Quality rate [% – site variant A]”
- “ISO 22400 K02 – Performance (OEE component) [%]”
- “ISO 22400 K09 – Production time [min, MES]”
- “ISO 22400 K13 – Scrap rate [% – includes rework]” (with the inclusion of rework defined in your KPI spec)
These patterns give enough information for experts to interpret and challenge the numbers, while remaining short enough for dashboards.
Implementation dependencies and caveats
Clear ISO 22400 labeling depends on:
- Configuration quality: You must know exactly how each KPI is computed in each system. If formulas differ or data is incomplete, labeling alone will not align behavior.
- Integration maturity: Incomplete equipment connectivity or partial downtime classification may force you to define and label KPIs as intermediate or provisional metrics.
- Validation state: In GxP or aerospace-grade contexts, any change to KPI calculations or their interpretation should be assessed for impact on validated processes and evidence packages.
Labeling ISO 22400 KPIs clearly is less about picking the “right” wording and more about ensuring that every label can be unambiguously traced to a controlled, standardized, and validated definition within your actual system landscape.
