ISO 22400 defines a common language and structure for manufacturing KPIs, especially around OEE and related performance metrics. Aligning with it is less about inventing new KPIs and more about documenting what you already use in a way that is traceable to the standard.
1. Decide which ISO 22400 KPIs actually apply
Do not try to implement every KPI in ISO 22400 by default. Start by identifying which of the standard’s KPIs are relevant for your products, equipment and regulatory context. Typical candidates:
- OEE and its components (Availability, Performance, Quality)
- Equipment utilization and loading
- Production throughput and lead time metrics
- Scrap, rework and first-pass yield metrics
Document this scoping decision explicitly so it is clear why some ISO KPIs are in scope and others are not.
2. Create a standard KPI specification template
Use a controlled template so every KPI is documented consistently. At minimum, each KPI record should include:
- Name and identifier: Local KPI name and a unique ID. Reference the corresponding ISO 22400 KPI ID where applicable.
- Purpose and decision use: What decisions this KPI informs (e.g., shift-level dispatching, weekly performance review, CAPA effectiveness checks).
- ISO mapping: Which ISO 22400 part and KPI it aligns with, and whether it is a direct match, a partial match, or an extension.
- Formal definition: Plain-language description of what is being measured and the scope (plant, line, cell, asset, product family, time bucket).
- Formula: Exact formula with units, including how each term is defined (e.g., what counts as planned vs unplanned downtime, what is excluded from good units).
- Data sources: Systems, interfaces and, if needed, manual inputs (e.g., MES events, PLC tags, ERP order data, QMS defect records).
- Aggregation rules: How the KPI is rolled up across lines, shifts, products and periods, and what is not allowed (e.g., why you cannot average OEE percentages directly across lines).
- Calculation timing and latency: Real-time, near-real-time, end-of-shift, end-of-day, etc., and expected update delay.
- Filters and exclusions: Maintenance windows, engineering trials, non‑standard products, or restricted operations that are excluded from the KPI.
- Responsible owner: Role accountable for definition, correctness and change control.
- Validation and testing: How the KPI is validated when first implemented and after each change (test cases, sample calculations, reconciliation checks).
This template should itself be a controlled document, linked to your document control and change management process.
3. Map existing KPIs to ISO 22400 terms
Most brownfield plants already track OEE-like metrics, but with local names and variations. To align with ISO 22400:
- Catalogue current KPIs: List the KPIs used in production reviews, management dashboards and regulatory reporting.
- Compare definitions: For each KPI, compare your definition and formula to the ISO 22400 definition.
- Classify the relationship:
- Exact match: Same meaning, scope and formula as ISO.
- Partial match: Same intent but different scope or components (e.g., your OEE excludes certain losses that ISO includes).
- Local KPI: Not defined in ISO 22400 but useful internally.
- Document gaps and deviations: For partial matches and local KPIs, explicitly describe how and why they differ from ISO 22400.
This mapping avoids confusion when auditors, customers or corporate functions reference ISO 22400 terminology.
4. Normalize definitions and terminology carefully
Alignment with ISO 22400 often means cleaning up legacy definitions that vary by plant, product or even supervisor. To document KPIs consistently:
- Standardize key terms: For example, what counts as “good units”, “planned downtime”, “setup”, “micro-stops” or “rework” must be defined once and used consistently across sites where you claim ISO 22400 alignment.
- Resolve local variants: If different plants use “OEE” differently, consider renaming local metrics (e.g., “Line OEE (legacy)”) and defining an ISO-aligned version explicitly.
- Use a glossary: Keep shared definitions for terms used across multiple KPIs, and reference that glossary from each KPI spec instead of redefining terms each time.
In regulated environments, apply change control if you change definitions, because historical trends and any prior analyses may no longer be directly comparable.
5. Document data lineage and system coexistence
In mixed MES/ERP/SCADA/QMS landscapes, two plants can implement the “same” KPI very differently unless data lineage is explicit. For each KPI:
- Identify system of record: E.g., equipment state from MES vs SCADA, quantity produced from MES vs ERP, quality disposition from QMS vs LIMS.
- Describe transformations: Any filtering, time alignment, or reclassification performed in data warehouses, analytics tools or custom scripts.
- Note known limitations: For example, legacy machines that do not provide fine-grained downtime codes, or manual quality logs that limit timeliness.
- Clarify multiple implementations: If two plants use different data paths for an ostensibly common KPI, document both and state whether they are considered equivalent for corporate reporting.
This level of documentation is often necessary to support auditability, investigations and cross-plant benchmarking.
6. Put KPI definitions under document control and change management
In regulated settings, KPI definitions and their formulas should be treated like any controlled method specification:
- Version control: Assign version numbers, maintain change history and archive prior definitions.
- Impact assessment: Before changing a KPI, assess impact on regulatory reports, SLAs, management targets and incentive schemes.
- Effective dates: Record when a new definition goes live so analysts know where historical comparisons may break.
- Communication: Ensure operations, quality and IT teams know which KPI versions are active in which systems and dashboards.
If KPI logic is implemented in software (MES reports, data models, dashboards), link the controlled KPI document to implementation artifacts and tickets, and require re-validation after changes.
7. Validate KPI implementations against the documentation
To claim alignment with ISO 22400, you should be able to show that what the system calculates matches the documented definition:
- Define test cases: Use realistic scenarios with known downtime, counts and scrap to compute expected KPI values by hand or in a spreadsheet.
- Compare system output: Run the same scenarios through MES reports or analytics tools and reconcile differences.
- Check boundary conditions: Very low volumes, partial shifts, overlapping downtime, mixed product runs, and backdated transactions.
- Re-validate after changes: Treat KPI logic changes like any other validated computation: regression tests, documented approvals and sign-off.
Without this step, you may have beautifully documented KPIs that are not actually used or computed as specified.
8. Be explicit about where you do not fully align with ISO 22400
Full, literal alignment is not always realistic in brownfield environments. Common constraints include:
- Legacy equipment without granular event data, forcing approximations.
- Integration gaps that prevent clean separation of some loss categories.
- Existing contractual or regulatory reporting formats that conflict with ISO structures.
Where this happens, document the deviation from ISO 22400, the rationale, and any mitigation (e.g., additional local KPIs or annotations in reports). This is usually more credible than claiming full compliance when underlying data does not support it.
9. Why “rip-and-replace” KPI systems usually fails in regulated plants
Teams sometimes propose replacing all existing metrics with a “pure” ISO 22400 set. In long-lifecycle, regulated environments this often fails because:
- Qualification and validation burden: Reworking KPIs across MES, ERP, data warehouses and reports can trigger significant re-validation and re-qualification work.
- Downtime and change risk: Deep changes to production and quality reporting logic can disrupt operations and confuse decision-making if cut over abruptly.
- Traceability impact: Abruptly changing KPI definitions complicates investigations, CAPA trending and audit trails that rely on historical continuity.
A more workable approach is to converge definitions toward ISO 22400 over time, starting with documentation and mapping, then gradually aligning formulas and data flows as systems are upgraded or re-validated.
10. Practical next steps
To move toward ISO 22400-aligned KPI documentation:
- Publish a KPI specification template under document control.
- Catalogue current KPIs used in operations, quality and management reviews.
- Map each to ISO 22400 where applicable and classify as exact, partial or local.
- Prioritize 5 to 10 critical KPIs and fully document them using the template.
- Work with IT and MES/ERP owners to verify system calculations against the documented formulas.
- Plan a phased roadmap to address the biggest gaps and inconsistencies, aligned with existing maintenance, upgrade and validation cycles.
This approach respects existing systems and constraints while moving you toward a traceable, ISO 22400-aligned KPI framework.
