Yes. ISO 22400 does not forbid adding custom KPIs, as long as you do not relabel, redefine, or obscure the standard indicators. In most regulated, brownfield environments, you should treat extensions as a controlled, documented configuration layer on top of the reference model rather than a free-form customization exercise.
What you can safely extend
Typical, low-risk extensions include:
- Additional KPIs that are clearly labeled as non-standard (for example, “Custom: Rework Cost per Good Unit”).
- Refinements or sub-KPIs that decompose an ISO 22400 KPI into components (for example, breaking availability into planned vs unplanned loss buckets) while keeping the base KPI definition unchanged.
- Context dimensions such as product family, cell, operator group, shift, or batch, if they do not alter the mathematical definition of the ISO 22400 indicators.
- Mappings to local terminology (for example, local names for downtime categories), provided the underlying category mapping remains traceable to the standard structure.
What you should not change
To preserve comparability and avoid audit confusion, avoid:
- Redefining calculation logic of a standard KPI (for example, changing how availability or OEE is computed) and still calling it by the ISO 22400 name.
- Mixing data scopes (for example, sometimes including setup time in operating time, sometimes not) under the same KPI identifier.
- Hiding which elements are custom, for example by presenting a custom KPI in dashboards as if it were a standard ISO 22400 metric without any qualifier.
- Overloading fields (for example, using a standard data field to store unrelated local attributes) in MES/SCADA/BI data models, which breaks interoperability.
Governance and traceability requirements
In regulated environments, custom indicators should be introduced under formal governance:
- Document the KPI catalog: For each KPI, record whether it is ISO 22400 standard or custom, the exact formula, data sources, filters, time base, and units.
- Maintain change history: When you modify a KPI definition or its data sourcing, version it and log when the change took effect. This is important for auditability and trending analysis.
- Establish ownership: Define who can approve new KPIs (for example, an operations analytics or performance management board including quality and IT).
- Ensure data lineage: Map each KPI to its originating systems (MES, SCADA, LIMS, ERP) and transformations used (ETL, calculations in the data warehouse, BI logic).
Integration with existing MES/ERP/QMS stacks
In brownfield environments, how you extend the model is constrained by existing systems:
- MES limitations: Many MES products come with a fixed KPI set or opinionated OEE / performance calculations. Extending ISO 22400 often means adding logic in a data warehouse or BI layer rather than modifying the MES itself.
- ERP/financial alignment: Cost-related custom KPIs must reconcile with ERP data. Differences in time buckets, posting delays, and valuation methods need to be clearly documented.
- QMS and batch records: If quality or batch-release decisions rely on KPIs, be careful about introducing or changing indicators without revalidating procedures and documentation.
- Long equipment lifecycles: Some legacy controls or data historians cannot easily provide all data needed for certain ISO 22400 KPIs. You may need proxy metrics or manual data collection until upgrades occur.
Validation and regulated use
If KPIs affect release decisions, quality risk assessments, or regulatory submissions, adding custom indicators can trigger validation and documentation obligations:
- Treat KPI logic as configurable software behavior in your validation framework if it influences GMP/GxP or safety-relevant decisions.
- Test and verify that new calculations are accurate, consistently sourced, and robust to missing or delayed data.
- Control configuration so that changes to KPI definitions, thresholds, or filters go through formal change control with impact assessment.
- Avoid dual definitions (for example, two groups computing “availability” differently); this is a common source of audit questions and root cause analysis noise.
Cross-plant and cross-vendor comparability
One of the main reasons to follow ISO 22400 is comparability across plants, lines, and vendors. Extensions can erode this benefit if not handled carefully:
- Keep a core set of strict ISO 22400 KPIs used for benchmarking and external reporting, without local modifications.
- Layer plant-specific or product-specific KPIs as a separate namespace (for example, prefix with “PLANT-A:” or “PRODUCT-X:”) so they are obviously non-standard.
- Ensure vendor-neutral definitions so that if you swap or add systems, you can still compute the same KPIs from new sources with minimal rework.
Why full replacement of existing KPI schemes is risky
Replacing legacy KPI schemes wholesale with an ISO 22400-only model rarely works smoothly in high-regulation, long-lifecycle environments:
- Qualification burden: Replacing existing OEE / performance metrics may require requalifying reports, dashboards, and sometimes procedures.
- Downtime risk: Re-engineering KPI logic inside MES or historian layers can disrupt production monitoring or line startup procedures.
- Integration complexity: Upstream and downstream systems (ERP, PLM, QMS) often embed assumptions based on existing KPIs, time buckets, and data semantics.
- Traceability and trending: A hard switch to new KPI definitions can break comparability with historical trends unless you maintain mappings and dual reporting for a transition period.
In practice, most organizations adopt a hybrid approach: keep critical legacy KPIs where required, introduce ISO 22400 as the reference baseline, then extend that model with custom indicators under tight governance.
