Where should I start when implementing ISO 22400?

Implementing ISO 22400 should start from your operational questions and existing systems, not from the standard’s KPI list. In regulated, brownfield environments, you will typically implement a subset of ISO 22400, phased in over time.

1. Clarify why you need ISO 22400 KPIs

Begin by defining a small set of concrete questions you need to answer, for example:

• Where are we actually losing productive time (planned vs unplanned NPT)?
• Which lines, cells, or programs are constraining capacity?
• How does changeover, rework, or inspection affect throughput?
• What do leadership, quality, and planning each need on a daily/weekly basis?

Map those questions to ISO 22400 KPI families (e.g. availability, performance, quality, resource utilization). Do not start by trying to implement all KPIs in the standard.

2. Define a narrow initial scope

To reduce risk and validation burden, scope your first phase tightly:

• Choose a pilot area: one line, cell, or representative value stream with manageable complexity.
• Limit KPI count: typically 5 to 10 core KPIs to start (for example availability, OEE or an OEE-like breakdown, NPT by category, schedule adherence, first-pass yield).
• Fix the time horizons: shift-level for operators and supervisors, daily/weekly rollups for management.

This keeps change control, validation, and training effort aligned with actual capacity.

3. Inventory current data sources and gaps

ISO 22400 assumes certain data structures and event definitions. In brownfield plants, you will rarely have a clean fit. Systematically review:

• MES/SCADA/PLC: what events and states are already captured (machine states, start/stop, faults, setup, inspections)?
• ERP: order data, schedule, BOM, routing, standard times, cost centers.
• QMS/LIMS: scrap codes, defect types, rework approvals, holds.
• Manual records: paper travelers, logbooks, spreadsheets in production control or quality.

From this, identify:

• Which ISO 22400 metrics you can compute now from existing data, even if imperfect.
• Where you have definition conflicts (for example different teams using different meanings for “downtime” or “scrap”).
• Where you need new events or fields configured in MES, SCADA, or data collection forms.

4. Standardize key definitions and states

Before you configure dashboards, you need agreed, documented definitions that can withstand audits:

• Equipment state model: which states exist (running, idle, planned stop, unplanned stop, setup, changeover, maintenance, quality hold) and how they map to ISO 22400 categories.
• Time accounting rules: what counts as “available,” “planned loss,” and “unplanned loss” in your context.
• Production and scrap: consistent logic for good units, rework, scrap, and test pieces.
• Shift and calendar rules: how shifts, overtime, and weekend work are defined in systems.

These should be under document control, referenced in work instructions and reporting SOPs, and aligned across MES, ERP, and QMS as far as practical.

5. Map ISO 22400 KPIs to your systems and models

Once definitions are stable, design how each KPI is computed and where:

• Source of truth per data element (e.g. order status from ERP, state transitions from MES/SCADA, scrap disposition from QMS).
• Transformation logic: how you derive ISO 22400 metrics from your actual event model and master data.
• Aggregation rules: how KPIs roll up from machine to cell, line, plant, and program.
• Traceability: how you retain calculation logic and versions for audit and troubleshooting.

In many cases, you will end up with a mapped subset rather than a textbook implementation. That is acceptable as long as it is well documented and consistently applied.

6. Pilot and validate in a controlled environment

Before you promote ISO 22400-based KPIs to official management reporting or use them to drive major decisions:

• Run the new KPIs in parallel with existing reports for a few weeks or months.
• Reconcile differences and determine whether they are due to better data, different definitions, or actual system errors.
• Perform basic validation: spot checks against manual logs, compare to known events (major breakdowns, planned maintenance periods, big quality escapes).
• Log issues and update definitions, mappings, or system configurations via formal change control.

This is especially important where KPIs may feed into capacity planning, customer commitments, or cost models.

7. Integrate with existing MES/ERP, not just dashboards

In regulated, long-lifecycle environments, a full rip-and-replace for ISO 22400 is rarely justifiable. Instead:

• Leverage existing MES and SCADA events and extend them only where the value is clear.
• Use lightweight integration (APIs, flat-file exchanges, data warehouse) to combine ERP, MES, and QMS data for KPI calculations.
• Avoid duplicating master data in new tools; pull from ERP or PLM where practical.
• Ensure any new KPI tooling or data pipelines are under appropriate configuration management and, where required, validation.

The target is coexistence: ISO 22400 KPIs surfacing a coherent view across heterogeneous systems, not a single, perfect system replacement.

8. Establish governance, ownership, and change control

To keep ISO 22400 from becoming another abandoned reporting project:

• Assign metric owners for each core KPI (typically operations or quality leaders).
• Define a simple governance cadence: regular review of KPI definitions, data issues, and improvement actions.
• Put KPI definitions, data mappings, and calculation logic under document and change control.
• Train operators, supervisors, and engineers on how states, downtime reasons, and scrap codes affect KPIs.

Consistent usage and disciplined changes matter more than perfectly matching every aspect of the ISO text.

9. Expand gradually based on proven value

After the pilot area is stable and trusted:

• Roll out to additional lines or plants that share similar processes and systems.
• Introduce more nuanced ISO 22400 KPIs only if there is a clear user and decision that depends on them.
• Continuously refine data capture (for example more detailed loss codes) where the additional effort is justified.

Resist the urge to scale faster than your ability to govern definitions, train users, and maintain integrations.

How this plays out in aerospace and other highly regulated plants

In aerospace and similar environments, ISO 22400 is most practical as a common language and reference for performance metrics across mixed MES, ERP, and QMS stacks. You will typically:

• Select a core set of ISO 22400-aligned KPIs around availability, speed loss, quality loss, and NPT.
• Map those KPIs to existing digital travelers, routings, and machine states instead of redesigning everything.
• Phase in line by line to limit downtime and validation impact.
• Maintain strong traceability from KPIs back to underlying records so you can support internal and customer audits.

The practical starting point is a tightly scoped, validated KPI model that fits your current systems and constraints, rather than a full, immediate implementation of every aspect of ISO 22400.