No, ISO 22400 does not require a separate, dedicated KPI database. The standard defines terminology, structure, and calculation rules for manufacturing KPIs, not specific IT architecture. You can comply using your existing data sources and storage as long as you can reliably compute, trace, and maintain the KPIs as specified.
What ISO 22400 actually expects
ISO 22400 focuses on:
- A common model and definitions for manufacturing KPIs (such as OEE and related indicators).
- Clear relationships between events (orders, operations, downtimes, quantities) and the KPIs.
- Repeatable, documented calculation logic.
- Traceability back to the underlying operational data.
None of this forces a new physical database. It does, however, require that your current data landscape can support consistent, auditable KPI calculation.
When a separate KPI database (or data mart) is useful
In brownfield environments, plants often introduce a separate logical KPI layer or data mart, even if they do not build a brand new database platform. This is usually done to solve practical issues, not to satisfy an ISO requirement.
You might consider a separate KPI store or mart when:
- Source data is fragmented: Events and states related to ISO 22400 KPIs are spread across MES, historians, ERP, custom spreadsheets, and manual logs.
- Event modeling is inconsistent: Different lines or plants use different codes and structures for status, downtime, or scrap, making standard KPI logic hard to apply.
- Performance and availability are concerns: Direct KPI queries against MES/ERP risk slowing down production systems or require access during shifts when IT change windows are minimal.
- Versioning and validation are required: You want controlled, validated calculation logic that does not change every time a local report is edited.
- Auditability is weak: You cannot easily show how today’s OEE for a line was calculated from underlying events one year later.
In these situations, a KPI database or data mart can provide:
- A normalized event model aligned to ISO 22400 concepts.
- Centralized, governed KPI calculations.
- Isolation from production systems for analytics workloads.
- Better traceability and historical reproducibility of KPIs.
Common architectures in regulated, long-lifecycle plants
In aerospace and other regulated sectors with long equipment lifecycles, full replacement of MES, historian, or ERP just to support ISO 22400 is rarely viable due to validation burden, downtime risk, and integration complexity. Instead, most plants use one of these patterns:
- Embedded KPI layer in existing MES: MES already captures most required events. ISO 22400 logic is implemented in MES reports, with a carefully documented mapping between MES data structures and ISO KPI definitions.
- Analytics or BI layer on top of existing systems: Data is extracted from MES/ERP/historian into a warehouse or lakehouse. ISO 22400 is implemented as a semantic model and calculation layer, with version-controlled logic. This looks like a separate KPI database from a logic perspective, even if it reuses an existing warehouse platform.
- Lightweight KPI data mart: A smaller, purpose-built data mart is created specifically for OEE and related ISO 22400 measures, sourcing only the minimum required data via ETL or streaming from existing systems.
These approaches reduce risk by coexisting with current MES/ERP stacks instead of replacing them, while still allowing you to standardize KPIs to ISO 22400.
Constraints and failure modes to watch
Regardless of whether you introduce a separate KPI database, ISO 22400 adoption will fail or stall if:
- Underlying event data is incomplete: If you do not record machine states, changeovers, micro-stops, or scrap in a structured way, you cannot credibly compute several ISO 22400 KPIs.
- IDs and relationships are missing: Weak linkage between orders, operations, equipment, and materials makes it difficult to build a coherent model for availability, performance, and quality metrics.
- Calculation logic drifts locally: If each plant or engineer “tunes” the KPI logic in their own spreadsheet or report, you lose standardization, even if you have a central database.
- Change control is not enforced: KPI calculations are changed without impact analysis, testing, or documentation, which undermines comparability over time and across sites.
- Lack of validation and traceability: In regulated environments, unvalidated KPI transformations and undocumented ETL jobs can create data integrity and audit questions.
Practical guidance
To decide whether you need a separate KPI database for ISO 22400:
- Map ISO 22400 KPIs to current data: Identify all required events, states, and quantities and where they reside (MES, historian, ERP, manual systems).
- Assess data quality and completeness: Check sampling rates, gaps, inconsistent codes, and missing relationships such as order-to-line mapping.
- Prototype calculations: Implement several KPIs in a simple analytics environment to expose modeling and integration gaps.
- Evaluate system impact: Determine whether running these calculations directly on MES/ERP is acceptable for performance and support.
- Plan governance: Decide where calculation logic will live, how it will be versioned, tested, and documented, and how changes will go through change control.
If your current stack can support accurate, traceable, and governed KPI calculations, you do not need a standalone KPI database. If it cannot, you likely need at least a dedicated KPI modeling and storage layer, even if that is implemented as an extension to an existing warehouse or analytics platform rather than a brand new database product.
