Yes. ISO 22400 is explicitly designed to be extendable, so you can add domain-specific KPIs as long as you keep a clear and traceable relationship to the standard categories and objects.
How to layer domain-specific KPIs on ISO 22400
In practice, most regulated and high-mix environments do not stop at the base ISO 22400 indicators. They:
- Use ISO 22400 KPI groups and objects (e.g., availability, performance, quality; equipment, order, material) as a common backbone.
- Define domain- or product-specific KPIs (e.g., “first-pass yield for titanium structural parts,” “batch right-first-time for sterile fill,” “NPT per engine program”).
- Map each custom KPI back to one or more ISO 22400 indicators and base measures where possible.
This mapping is important for comparability across plants, suppliers, and systems, and for explaining your metrics to auditors and customers.
Key constraints and risks
Simply adding more KPIs tends to create confusion unless you address these points explicitly:
- Definition control: Each domain-specific KPI needs a precise, version-controlled definition: scope, units, inclusions/exclusions, time basis, and data sources. Without this, discrepancies between MES, data warehouse, and local Excel calculations will accumulate.
- Double-counting and overlap: Custom KPIs often partially duplicate ISO 22400 ones. If you are not explicit about which KPI is the “authoritative” one for a decision, you can end up with conflicting numbers in management reviews.
- Traceability: For regulated environments, you should be able to trace a reported KPI value back to raw events and master data: which equipment, which production order, which time window, and which transformation logic.
- Change control: KPI formula changes, new filters, or data model changes should go through formal change control, especially when metrics drive release decisions, batch disposition, or capacity planning.
- Validation and testing: Where metrics are used in validated processes or electronic records, new KPIs and changes to them typically require documented testing and sometimes revalidation of MES, historian interfaces, and reporting tools.
Practical integration in brownfield environments
In mixed, legacy-heavy landscapes, adding domain-specific KPIs on top of ISO 22400 is feasible but rarely plug-and-play:
- MES and historian limits: Older MES or SCADA systems may not natively support ISO 22400 semantics. You can still implement the logic in a data warehouse or analytics layer, but you must be clear where the “system of record” for each KPI lives.
- Multiple calculation engines: Plants often have calculations in MES, historian, custom middleware, and BI tools. If you add a domain-specific KPI, decide where it is calculated and prevent alternative, unsanctioned versions in local spreadsheets.
- Long lifecycle assets: Some equipment or legacy interfaces cannot be changed easily without qualification or downtime. In those cases, you may need to compute both ISO 22400 and domain-specific KPIs externally, leaving the core control systems untouched.
- Avoiding full replacement: Attempting to replace all legacy KPI logic with a single new platform at once often fails due to downtime risk, integration complexity, and validation burden. Incremental layering on top of existing systems, with clear mapping to ISO 22400, is usually more realistic.
Suggested governance approach
A simple governance model makes domain-specific extensions workable:
- KPI catalog: Maintain a central catalog listing each KPI, whether it is ISO 22400-based or domain-specific, with owner, purpose, formula, and mapping to ISO 22400 indicators.
- Tiering: Separate global KPIs (based directly on ISO 22400) from domain/plant-specific ones to avoid endless debates about which number is “right” at corporate vs site level.
- Standard interfaces: Where possible, expose both standard and domain-specific KPIs via a common data model or API, even if the underlying systems are heterogeneous.
- Documentation for audits: Keep evidence of how KPIs are calculated, tested, and changed over time. This helps when auditors question why your internal metrics differ from generic OEE benchmarks.
In summary, adding domain-specific KPIs on top of ISO 22400 is not only allowed but often necessary. The value comes from disciplined definition, mapping, and governance so that extensions improve insight instead of increasing confusion.
