ISO 22400, as it exists today, does not mandate any specific software or technology. It defines standardized manufacturing KPIs (e.g., OEE-related measures) and how they should be calculated and interpreted. Whether you need new software depends on how well your current systems can support those definitions in a traceable, repeatable way.
What ISO 22400 actually expects
In practical terms, ISO 22400 expects that you can:
- Use standardized KPI definitions and terminology (e.g., availability, performance, quality rate) consistently across the plant or network.
- Calculate those KPIs using the formulas and data groupings defined by the standard.
- Show where the underlying data comes from (machines, MES, ERP, manual logs) and how it is transformed.
- Maintain stability and governance around KPI definitions over time so that reports are comparable and auditable.
None of this inherently requires a specific vendor or a new platform. It does require that your data and processes are coherent and controlled.
When existing systems are usually enough
In many regulated, brownfield environments, you can align to ISO 22400 using your current stack, assuming:
- MES / SCADA / historian already capture machine states, production counts, scrap, and downtime with timestamps.
- ERP holds order, schedule, and shift information that can be joined to shop-floor data.
- Reporting / BI tools (or MES reports) can implement ISO 22400 formulas and clearly document them.
- Governance exists to control changes to KPI definitions, queries, and calculations under formal change control.
If you can configure your existing MES or analytics tools to implement ISO 22400 KPI logic and preserve an audit trail, you do not need new software purely for ISO 22400 alignment.
When gaps in current tools become a problem
New software becomes relevant when current systems have structural gaps that you cannot close safely or cost-effectively, for example:
- Incomplete or unreliable data: No consistent recording of downtime categories, scrap reasons, or machine state transitions; manual spreadsheets with poor controls.
- No clear data lineage: KPIs built from opaque Excel logic or one-off scripts that no one can fully explain or validate.
- Inflexible legacy MES/SCADA: KPI logic is effectively hard-coded, and modifying it risks breaking validated production or requires vendor customizations you cannot maintain.
- Lack of traceability: You cannot show who changed KPI definitions, when, and why, which undermines trust and auditability.
- Fragmentation across plants: Each site uses different definitions and tools, and existing systems cannot be harmonized without major rework.
In these cases, adding a focused layer (for example, a standard KPI calculation and visualization layer on top of MES/ERP/historian) can be more realistic than trying to retrofit everything into each legacy system.
Brownfield reality: replacement vs coexistence
Completely replacing MES, ERP, or SCADA just to support ISO 22400 KPIs is rarely justified in aerospace-grade, regulated environments. Full replacements often fail or stall because of:
- Qualification and validation burden: New core systems must be validated and requalified across equipment, products, and regulatory contexts.
- Downtime risk: Cutover windows are constrained, and failures can impact deliveries or flight-critical programs.
- Integration complexity: Existing interfaces to QMS, PLM, SPC, and test systems are costly to rebuild and revalidate.
- Long asset lifecycles: OT equipment and legacy controllers may not integrate cleanly with new platforms without additional gateways.
As a result, ISO 22400 is more often implemented through coexistence:
- Keep core MES/ERP in place.
- Add or configure a metrics layer (MES module, historian, or BI platform) to implement ISO 22400 KPI logic.
- Standardize data mapping and definitions across sites, using documented calculation rules and change control.
Key questions to decide if you need new software
To determine whether you truly need additional tools, ask:
- Can we implement ISO 22400 KPI formulas in our existing MES/BI, with clear documentation and validation?
- Do we have reliable, time-aligned event and count data to feed those formulas without excessive manual entry?
- Can we trace each KPI back to raw data sources and logic, and subject changes to change control?
- Can we apply the same definitions across lines/plants without each site inventing its own logic?
If the answer to most of these is yes, new software is likely optional. If the answer is no and the gaps cannot be closed by configuration, you may need either:
- A dedicated performance metrics / OEE layer integrated to existing systems, or
- Targeted upgrades to specific legacy components that cannot deliver required data or traceability.
Constraints and tradeoffs
Regardless of whether you use existing or new tools, ISO 22400 alignment depends on:
- Data quality: Poorly classified downtime, inaccurate counts, and inconsistent scrap recording will undermine any KPI standard.
- Process maturity: Operators and supervisors must actually follow the event coding and reporting processes the KPIs rely on.
- Validation and governance: KPI logic and interfaces should be validated at a level consistent with your QMS and regulatory expectations, with documented ownership and change control.
- Integration quality: KPI calculations that join MES, ERP, and historian data must handle clock drift, missing data, and order boundary issues explicitly.
Software alone does not create ISO 22400 compliance. It is an enabler, but the substance is in how you define, calculate, and govern KPIs using the tools you have.
