Connect981 – Content Dev

RSC Topic: ISO 22400 KPIs

  • How should ISO 22400 KPIs be labeled on dashboards?

    ISO 22400 does not prescribe exact dashboard labels, but in regulated, multi-site environments you should make the ISO basis explicit and distinguish between the standard KPI and any local variant. The goal is to avoid silent divergence of definitions across MES, SCADA, BI, and plant-specific dashboards.

    Core labeling pattern

    A practical, auditable pattern is:

    • Primary label (business-friendly): Short, readable name for operators and managers (e.g. “OEE”, “Availability”, “Quality Rate”).
    • Secondary label (ISO reference): Show the ISO 22400 identifier and official term nearby (e.g. “ISO 22400-2: KPI 5 – Overall Equipment Effectiveness”). This can be in a subtitle, tooltip, or info icon.
    • Formula hint: A short text or hover help showing the denominator, included losses, and time basis (e.g. “Based on ISO 22400-2, 8-hour planned time, includes minor stops, excludes planned maintenance”).

    This keeps dashboards usable day to day while maintaining traceability to a documented, standard definition.

    Distinguishing standard vs local variants

    In brownfield environments, many KPIs are already implemented with plant-specific logic. When you align with ISO 22400, avoid relabeling existing metrics as “ISO” unless the implementation actually matches:

    • Use explicit tags for variants: For example, “OEE (Local – excludes setup)” vs “OEE (ISO 22400-2)” if you maintain both.
    • Avoid ambiguous short labels: A card simply labeled “Availability” without context is risky when different systems treat micro-stops, setups, and changeovers differently.
    • Document the difference: In KPI documentation and data catalog, include a short statement such as “Differs from ISO 22400-2 by excluding changeover time from planned time.”

    Minimum information to show near each KPI

    Where possible, each ISO 22400-based KPI on a dashboard should expose:

    • Name: Friendly label (e.g. “Availability”, “Performance”, “Quality Rate”, “OEE”).
    • Standard reference: ISO 22400 part and KPI identifier where defined (e.g. “ISO 22400-2 KPI 6 – Availability”).
    • Time basis: Shift, day, week, or custom, and whether this is “planned time” vs calendar time.
    • Scope: Whether the KPI is per line, machine, cell, or plant.
    • Inclusions/exclusions: At least a short list of key inclusions/exclusions (e.g. “Includes minor stops; planned maintenance excluded from planned time”).

    The details can be in a hover tooltip, drill-down, or a linked KPI definition page to avoid cluttering the main view.

    Coexistence with existing MES/BI labels

    In long-lived, regulated operations, a full relabeling of all dashboards to align with ISO 22400 often creates confusion and retraining burden. A more realistic approach is:

    • Keep legacy labels where necessary for continuity, but add an ISO reference line or icon (e.g. “Legacy OEE (not ISO 22400)”).
    • Introduce ISO 22400 views incrementally, starting with new dashboards or specific pilot lines, clearly marked as “ISO 22400-aligned KPIs”.
    • Use consistent mapping in all tools: The same KPI name and ISO reference should appear in the MES screen, BI report, and any exported PDF used in reviews.

    This minimizes disruption while increasing transparency about what is and is not standard-aligned.

    Governance and change control

    In regulated environments, labeling is part of KPI governance, not just UI design. To keep ISO 22400 KPIs reliable over time:

    • Maintain a KPI catalog that records: name, business owner, ISO 22400 reference, formula, data sources, and known deviations.
    • Route KPI definition changes through change control, especially if the formula or data source changes but the dashboard label stays the same.
    • Validate calculations on each major system (MES, historian, BI) so that the same labeled KPI actually produces the same result across tools.

    Without this discipline, dashboards can show identically labeled ISO KPIs that are not comparable across plants or systems.

    Common pitfalls to avoid

    • Using “ISO 22400” as a label without conformance: If you cannot match the standard definition due to data gaps or integration limits, label the KPI as a local variant and document the gap.
    • Hiding ISO references entirely: Helps adoption in the short term but makes audits, cross-plant comparisons, and troubleshooting harder.
    • Letting each plant rename KPIs freely: Leads to incompatible definitions under similar names. Use controlled label sets where possible.

    Overall, label ISO 22400 KPIs so that operators can read them at a glance, while engineers, quality, and auditors can trace them back to a clear, documented standard definition.

  • Can MRO-specific turnaround KPIs be aligned with ISO 22400 concepts?

    Yes, MRO-specific turnaround KPIs can be aligned with ISO 22400 concepts, but it is a translation and modeling task, not a direct one-to-one mapping. You are effectively expressing MRO turnaround behavior (TAT, visit cycle times, AOG exposure) using ISO 22400’s way of structuring equipment, operations, states and time categories.

    What ISO 22400 actually provides

    ISO 22400 defines a framework for manufacturing KPIs, including:

    • Standard entities: equipment, work units, work centers, production orders, operations.
    • Time categories: operating, scheduled downtime, unscheduled downtime, standby, etc.
    • Common performance views: availability, effectiveness, responsiveness, quality rate, etc.

    It does not define MRO-specific indicators like turnaround time (TAT) per tail number or AOG risk, but it gives you a consistent way to decompose and measure time and events.

    Typical MRO turnaround KPIs that can align with ISO 22400

    Most MRO KPIs can be expressed using ISO 22400 concepts with careful modeling:

    • Turnaround Time (TAT) / Visit Duration
      Map the start/end of a “maintenance order” (or visit) to ISO 22400 production order timings and break the total into ISO time categories: operating time (work being performed), waiting (for parts, engineering, approvals), planned downtime (scheduled checks), and unplanned downtime (rework, findings).
    • Induction-to-Teardown / Teardown-to-Repair / Repair-to-Release cycle times
      Model each phase as an operation or operation segment. ISO 22400 timing concepts apply to each operation, so cycle-time KPIs can be expressed as operation duration and wait time between operations.
    • Hangar / Bay Utilization
      Treat each bay or dock as an “equipment” or “work center” and use ISO availability and utilization concepts: scheduled time vs actual operating time vs idle or blocked time.
    • Findings and induced work impact on TAT
      Use ISO 22400’s breakdown of planned vs unplanned activities. Induced work can be modeled as unplanned operations added to the original production order, and their time contribution measured explicitly.
    • Rework and quality-related delays
      Align with ISO time categories for rework and scrap. Even though MRO quality metrics may be tailored to regulatory and airline program terms, the time they consume fits ISO 22400’s loss-tree style thinking (e.g., rework as a specific class of non-productive time).
    • Material- and engineering-hold time
      Model these as specific standby or waiting states associated with the “equipment” (bay) or the maintenance order. ISO 22400 supports the concept of waiting time; you must define clear rules for when an order is “waiting for parts” vs “waiting for engineering” vs actually in work.

    Where alignment is more approximate

    Some MRO KPIs sit partly outside ISO 22400’s native focus on production:

    • AOG risk and exposure
      ISO 22400 can help with internal responsiveness and lead time, but “AOG risk” is a fleet- and schedule-level concept. You will likely need an external model that uses ISO-derived cycle times and variability as inputs rather than a pure ISO KPI.
    • Contractual or program-specific SLAs
      SLAs that include penalty windows, partial credits, or complex definitions of “clock stop” often extend beyond simple start/end timestamps. ISO 22400 time categories help you structure the underlying data, but the SLA logic usually remains custom.
    • Configuration and maintenance lineage KPIs
      Metrics about configuration changes per visit, SB/AD compliance velocity, or maintenance lineage complexity tie more to asset history and traceability than to ISO 22400’s production focus. You can still use ISO time concepts for “how long did it take,” but the configuration dimension is outside ISO’s core scope.

    Practical alignment steps in brownfield MRO environments

    In a real MRO stack with legacy MRO software, ERP, MES-like systems, and point tools, alignment depends heavily on data quality and integration maturity.

    1. Define what “the unit” is for KPIs
      Decide whether you treat the unit of analysis as the aircraft visit, the work package, the maintenance order, or the bay. ISO 22400 expects clarity about “production unit”; without this, mappings become inconsistent across sites and systems.
    2. Map your existing states to ISO 22400 time categories
      Most MRO systems already track status codes (e.g., IN WORK, AWAITING PARTS, ENGINEERING HOLD, QA HOLD). Create a mapping to ISO categories like operating, planned downtime, unplanned downtime, standby. This is usually the most contentious step and should go through change control.
    3. Align events and timestamps
      Ensure that key MRO events (induction, bay-in, maintenance start, maintenance complete, bay-out, release to service) are consistently timestamped across systems. ISO 22400 concepts are only useful if the event data is reliable and traceable.
    4. Implement a common time accounting model
      Use an ISO 22400-aligned “time accounting” layer that sits above individual systems. It can consume events from MRO software, ERP, MES, and planning tools, then compute standardized durations and categories, without forcing a full system replacement.
    5. Document KPI definitions and governance
      For each MRO turnaround KPI, maintain a controlled definition that states how it maps to ISO 22400 entities and time categories, including explicit treatment of clock start/stop rules, holds, partial work, and rework. Treat these as controlled documents under your QMS.
    6. Validate before using for compliance or contracts
      If ISO 22400-aligned KPIs will feed regulatory reports, internal audits, or customer-facing dashboards, validate the calculation logic and data flows. In regulated aerospace MRO, this typically requires test datasets, comparison to legacy reports, and documented verification.

    Constraints and tradeoffs

    • No automatic compliance benefit
      Aligning KPIs to ISO 22400 does not, by itself, improve audit outcomes or prove compliance. It mainly improves internal consistency and comparability across sites and programs.
    • Brownfield integration complexity
      Legacy MRO and ERP systems may not expose all required timestamps or state changes cleanly. You may need middleware, data warehouse logic, or MES overlays to derive ISO-style KPIs without replacing core systems, which is often not feasible due to downtime, validation, and re-qualification burdens.
    • Site- and program-specific variations
      Different hangars and programs may have meaningfully different process states and coding practices. A single ISO 22400 mapping is possible, but it usually involves compromise and local change management.
    • Partial alignment is still useful
      It is reasonable to keep some KPIs as explicitly “MRO-specific” and not force a clean ISO 22400 mapping, while still using ISO-based time accounting as the foundation for most turnaround metrics.

    How this typically works in aerospace MRO

    In aerospace MRO, operators commonly:

    • Keep existing MRO and ERP systems for work control and finance.
    • Add an execution or analytics layer that normalizes states and timestamps into an ISO 22400-like model.
    • Define turnaround KPIs (TAT, on-time release, bay utilization, induced work impact) using that normalized model.
    • Maintain KPI definitions and mappings under document control so that audits and customers can see how times are derived and aggregated.

    This coexistence approach avoids the cost and risk of replacing core MRO systems, while still giving you ISO 22400-aligned, comparable metrics across fleets and facilities.

  • How does ISO 22400 influence our MES and historian data schemas?

    ISO 22400 influences MES and historian schemas mainly by giving you a more consistent way to define manufacturing KPIs, their underlying elements, and the context needed to calculate them. It is best treated as a semantic and data-model reference, not as a command to redesign every production database around the standard.

    For most plants, the practical impact is this: your MES, historian, and reporting layers should be able to map plant events, states, material context, equipment context, and time models to KPI definitions that are aligned with ISO 22400 where useful. That does not mean your internal schemas must mirror the standard one-to-one.

    What it usually changes

    ISO 22400 tends to push teams toward tighter definition and governance of the data behind performance metrics. In schema terms, that often means:

    • clear separation between raw observations, calculated values, and business KPIs

    • consistent equipment, work center, order, material, and personnel identifiers across systems

    • explicit event and state modeling, especially for run, stop, idle, fault, setup, and planned versus unplanned time

    • time-bounded records with unambiguous timestamps, timezone handling, and aggregation rules

    • versioned KPI formulas and reference data so historical calculations remain explainable after changes

    • traceable mappings from historian tags and MES transactions to KPI inputs

    If your current schema mixes transactional records, machine tags, and rolled-up dashboard numbers without lineage, ISO 22400 will expose that weakness quickly.

    What it usually does not change

    It does not automatically tell you how to model every MES transaction, historian tag namespace, batch record, genealogy object, or ERP integration. It also does not eliminate plant-specific interpretation issues. Two plants can both claim alignment to ISO 22400 and still differ materially in how they classify downtime, count good units, handle rework, or assign labor time.

    So the answer is not that ISO 22400 replaces your existing schema design. The answer is that it gives you a disciplined target for KPI semantics, while your actual schemas still need to reflect equipment realities, vendor models, legacy integrations, and validation constraints.

    MES versus historian implications

    For MES, the influence is usually stronger at the transactional and contextual level. The MES often owns order status, operation completion, labor declarations, quality dispositions, material consumption, and route context needed to make KPI calculations defensible.

    For the historian, the influence is usually indirect. Historians are optimized for time-series capture, not for full business semantics. You may need additional structures or middleware to associate raw tag streams with equipment states, product context, job context, and approved KPI logic. Trying to force a historian alone to become the canonical KPI model often creates brittle workarounds.

    In many brownfield environments, the sustainable pattern is:

    • historian stores raw and derived time-series data

    • MES stores execution context and transactional truth for production events

    • a semantic or analytics layer maps both into ISO 22400-aligned KPI definitions

    That separation is not mandatory, but it is common because it limits disruption to validated or long-lived operational systems.

    Brownfield reality

    If you already run mixed MES, SCADA, PLC, historian, ERP, and reporting stacks, a full schema replacement is usually a poor strategy. In regulated, long lifecycle environments, wholesale replacement often fails because of qualification burden, validation cost, downtime risk, integration complexity, and the need to preserve traceability through change control.

    A more realistic approach is incremental alignment:

    • define a canonical KPI vocabulary and calculation rules

    • map existing source fields and tags to that model

    • close high-impact gaps in master data and event capture

    • version the mappings and calculations under change control

    • retire redundant calculations only after parallel verification

    This is slower than a clean-sheet redesign, but usually safer and more auditable.

    Tradeoffs and failure modes

    Aligning schemas to ISO 22400 can improve comparability and reduce metric disputes, but there are tradeoffs.

    • More structure can improve consistency, but it also increases governance overhead.

    • Standardized KPI definitions can help cross-plant reporting, but they may hide process differences if local context is flattened too aggressively.

    • Retrofitting event models into legacy systems can improve analytics, but may require custom integration and data cleansing that are costlier than expected.

    • Versioned KPI logic improves traceability, but it complicates historical restatement and report reconciliation.

    • Historian tag quality may be too inconsistent for reliable KPI alignment without significant instrumentation or contextualization work.

    Common failure modes include treating ISO 22400 as a direct database template, assuming vendor data models already align, ignoring master data quality, and overlooking how KPI semantics change when routing, batch logic, or downtime coding differs by line or site.

    What to do in practice

    Start by deciding where ISO 22400 alignment matters most for your operation. Usually that is not every schema object. It is the subset tied to performance reporting, loss analysis, and cross-system KPI consistency.

    1. Inventory the KPI definitions you actually use.

    2. Identify the source systems and fields behind each one.

    3. Document gaps in time states, material context, quality status, and order linkage.

    4. Create a governed mapping layer rather than rewriting every source schema first.

    5. Validate calculations against current reports before changing operational use.

    6. Apply formal change control if outputs feed regulated records, release decisions, or quality evidence.

    So, yes, ISO 22400 should influence your MES and historian schemas, but mostly by shaping a controlled semantic model and mapping strategy. It is more useful as a standard for KPI meaning and interoperability than as a mandate for wholesale schema replacement.

  • Where should I start when implementing ISO 22400 in an aerospace factory?

    Start with metric governance and a narrow pilot, not with a plant-wide dashboard rollout.

    ISO 22400 can help standardize how manufacturing KPIs are defined and calculated, but it does not fix weak data capture, inconsistent routing practices, poor equipment state models, or disconnected systems on its own. In an aerospace factory, the practical first step is to choose one production area or value stream and make sure the KPI definitions, source data, ownership, and review process are all explicit and controlled.

    Recommended starting point

    1. Pick a limited scope. Choose one line, cell, program, or work center group with meaningful throughput, recurring constraints, and manageable data complexity. Avoid starting with the entire site.

    2. Select a small KPI set. Focus on a few measures that operations, quality, and engineering already use and argue about. The point is to standardize meaning before expanding coverage.

    3. Document metric semantics. Define each KPI unambiguously: formula, units, event triggers, exclusions, time basis, ownership, and approved system of record. If different departments calculate the same metric differently today, resolve that first.

    4. Map the required source data. Identify where status, count, quality, scrap, downtime, routing, labor, and order data actually come from. In many aerospace plants, this spans MES, ERP, machine connectivity layers, historians, spreadsheets, and manual logs.

    5. Assess data readiness. Check timestamp quality, event granularity, master data consistency, equipment naming, reason-code discipline, and order-to-operation linkage. If those are weak, KPI outputs will be technically calculated but operationally untrusted.

    6. Establish change control. Treat KPI definitions, mappings, and calculations as controlled artifacts. In regulated environments, informal formula changes create traceability and audit problems even when the intent is harmless.

    7. Validate on historical data before operationalizing. Reconcile calculated values against known production records, shift reports, and quality outcomes. Expect mismatches. Those mismatches usually reveal integration gaps or inconsistent plant practices.

    8. Roll out reviews before roll out dashboards. Define who reviews which KPI, how often, what decisions it supports, and what escalation path exists when numbers conflict with shop floor reality.

    What usually matters most in aerospace

    In aerospace, the hardest part is often not the formula. It is getting stable, trusted operational context around the formula.

    • Complex routings and rework loops can distort simple throughput metrics.

    • Hold states, inspections, concessions, and partial completions may need explicit handling.

    • Manual stations often have weaker event capture than automated equipment.

    • Program-specific rules can make cross-plant standardization harder than expected.

    • Long validation cycles and controlled changes slow metric redesign, which is usually appropriate.

    If you are trying to benchmark across sites, lines, or suppliers, semantic consistency matters more than visual consistency. A shared dashboard with inconsistent source logic is worse than a smaller deployment with trusted definitions.

    How ISO 22400 fits with existing systems

    In most brownfield aerospace environments, ISO 22400 should sit on top of existing systems as a KPI standardization layer, not as a reason to replace MES, ERP, PLM, QMS, or historian platforms outright.

    Full replacement strategies often fail because the qualification burden is high, downtime windows are limited, integrations are deeply embedded, and existing assets may remain in service for many years. Even if a new platform has stronger KPI features, migrating transactional logic, equipment interfaces, genealogy links, and controlled records can cost more and introduce more risk than improving definitions and data flows around current systems.

    A more realistic path is to:

    • keep existing systems of record where they are stable,

    • normalize master data and event mappings,

    • standardize KPI definitions centrally, and

    • add calculation, reporting, or analytics layers only where they can be validated and governed.

    Common failure modes

    • Starting with too many KPIs at once

    • Assuming equipment connectivity is sufficient without reviewing event quality

    • Ignoring manual processes, rework, and inspection delays

    • Letting each department keep its own formula for the same metric

    • Building dashboards before establishing ownership and review cadence

    • Treating KPI standardization as an IT project only, without operations and quality governance

    Practical first deliverables

    • A controlled KPI definition document for the pilot area

    • A source-to-target data map for each metric

    • A list of master data gaps and naming conflicts

    • A validation log comparing calculated KPI outputs to known production records

    • A change control workflow for updates to definitions, mappings, and reason codes

    If you need a simple rule for where to begin, begin where you already have enough operational discipline to prove the numbers and enough business pain to act on them. That is a better starting point than chasing enterprise-wide KPI uniformity before the underlying data and governance are ready.

  • What is the difference between OEEA and OEEB in ISO 22400?

    ISO 22400 distinguishes multiple standardized forms of Overall Equipment Effectiveness (OEE). “OEEA” and “OEEB” are two of these variants, designed to separate different time bases and loss categories. They are not different KPIs conceptually, but different calculation models and scopes for the same family of metrics.

    Core idea: why ISO 22400 has OEE variants

    In practice, plants calculate OEE in many inconsistent ways: shifts vs 24/7, including or excluding planned maintenance, treating changeovers differently, and so on. ISO 22400 introduces variants such as OEEA and OEEB to:

    • Make the underlying time base explicit.
    • Clarify which losses are in or out of scope.
    • Allow more apples-to-apples comparisons across lines or plants.

    Each variant is a specific, defined way to slice the same operating time and production data. Which one is appropriate depends on your operating model and the questions you are trying to answer.

    Typical difference between OEEA and OEEB

    The exact definitions and formulas are in the ISO 22400 standard itself and should be treated as the authoritative source. In broad terms used by many practitioners who follow ISO 22400 guidance:

    • OEEA is usually defined on a narrower, more “pure equipment” time base, often focusing on periods when the machine is expected to run and excluding certain planned non-production times.
    • OEEB is usually defined on a broader time base that includes more categories of loss (for example, some planned stops) so that the number reflects more of the “real-world” utilization picture.

    The intent is to separate a metric that primarily reflects equipment performance during scheduled running time (often closer to OEEA) from one that reflects overall effectiveness across a wider slice of calendar or shift time (often closer to OEEB). The precise categorization of losses (availability, performance, quality and their sub-losses) and the associated formulas are defined in detail in ISO 22400 and can vary by part of the series (e.g. 22400-2, 22400-5).

    Because individual companies and software vendors use the labels “OEEA” and “OEEB” inconsistently, you should:

    • Refer directly to the current ISO 22400 text used in your organization.
    • Document your chosen interpretation unambiguously in your data model, work instructions, and system configuration.
    • Ensure the naming in dashboards and reports matches that documented interpretation.

    Implications for regulated and brownfield environments

    In aerospace, defense, and other regulated manufacturing, the distinction between OEEA and OEEB matters because:

    • Traceability and auditability: If you use OEE for management decisions, capacity planning, or continuous improvement justifications, auditors and customers may expect you to show how it is calculated and which time and loss categories are included.
    • Mixed system reality: Legacy MES, SCADA, historians, and spreadsheets may already be computing a homegrown “OEE” that does not map cleanly to OEEA or OEEB. Forcing a hard switch to a single ISO variant without a mapping plan often breaks historical trend analysis and confuses stakeholders.
    • Validation burden: If OEE feeds any validated planning, scheduling, or cost models, changing from an OEE-like metric to strict OEEA or OEEB is a change that must be impact-assessed, tested, and documented under your change control process.

    Full replacement of all existing OEE calculations with a single ISO 22400 variant across a brownfield landscape frequently fails, not because the standard is wrong, but because:

    • Different lines or value streams genuinely need different time bases (e.g., batch vs continuous, 5×8 vs 24/7).
    • Re-implementing every dashboard, report, and integration to align with a single variant can be disruptive and costly, especially when systems are validated.
    • Historical benchmarks, targets, and contractual KPIs are often tied to legacy definitions that cannot be abandoned quickly.

    A pragmatic pattern is to map existing metrics to the closest ISO 22400 variants, label them clearly, and gradually converge where the cost and risk are justified.

    Practical steps if you want to use OEEA and OEEB

    To apply OEEA and OEEB meaningfully in your plant:

    1. Obtain and freeze the reference: Make the specific ISO 22400 edition(s) you follow part of your controlled documents. Do not rely on secondary summaries.
    2. Define loss categories precisely: Create a plant-level loss model that maps your actual events (planned maintenance, changeover, setups, standby, micro-stops, speed loss, scrap, rework) to the availability, performance, and quality buckets as defined for OEEA and OEEB.
    3. Map existing data sources: For each line, identify which systems provide run/stop signals, counts, scrap data, and planned stops. Verify that your MES/SCADA tags and event codes can be unambiguously mapped to the ISO categories; if not, plan a staggered clean-up and re-coding.
    4. Implement side-by-side calculations: Before retiring any legacy OEE definition, run OEEA and/or OEEB in parallel for a period. Document differences and agree with stakeholders on how targets will be revised.
    5. Validate and document: In regulated environments, treat the OEE calculation logic as configuration that must be version-controlled, change-controlled, and testable. Keep calculation examples and test cases as evidence.

    Ultimately, the difference between OEEA and OEEB in ISO 22400 comes down to which time you count, which losses you include, and how you want to use the metric. The standard provides the structure, but it is your responsibility to implement and document a consistent interpretation that fits your systems, products, and regulatory context.

  • Who should own KPI governance in an ISO 22400 project?

    In an ISO 22400 project, KPI governance should not sit with a single department. The most robust pattern in regulated, brownfield environments is a cross-functional KPI governance group, usually led by operations but with explicit, shared ownership across operations, quality, IT/OT, and finance.

    Primary ownership: cross-functional KPI governance group

    In practice, KPI governance is best owned by a formal KPI governance group or steering committee that reports into existing operational governance (for example, an operations excellence board or site leadership team). This group should be explicitly chartered for ISO 22400 metrics and aligned with existing management review structures.

    Typical chair and members:

    • Chair: Operations or manufacturing leadership (e.g., Plant Manager, Director of Operations, or VP Manufacturing), because ISO 22400 KPIs primarily describe manufacturing performance and are used to run the plant.
    • Core members:
      • Quality (e.g., Site Quality Head or Quality Systems lead) to ensure KPI definitions, data usage, and change control align with QMS, validation expectations, and regulatory commitments.
      • IT/OT (e.g., MES architect, OT lead, or IT manufacturing systems lead) to own data lineage, integration design, system performance impact, and cybersecurity constraints.
      • Finance / Controlling to align KPI formulas and time-basis with financial reporting and avoid conflicting “truths” for utilization, OEE, or cost-related metrics.
      • Continuous Improvement / Industrial Engineering to ensure KPIs support realistic improvement programs and standardized work measurement.

    This group owns the KPI framework and decisions, not the day-to-day measurement. Daily data collection and review typically remains within operations, line leadership, and existing MES/reporting teams.

    What the KPI governance group should own

    Regardless of organizational chart, someone must explicitly own these responsibilities. In a mature ISO 22400 initiative, the governance group should control:

    • KPI catalog and scope
      • Selection of which ISO 22400 KPIs are in scope by plant/asset/area.
      • Standard naming, units, and aggregation levels across sites where feasible.
      • Clear mapping from ISO 22400 concepts to local terminology to avoid ambiguity.
    • Definitions and calculation rules
      • Formal, versioned definitions of each KPI, including inclusions, exclusions, and timing.
      • Resolution of contentious edge cases (e.g., what counts as “planned downtime,” “rework,” or “microstop” in your context).
      • Alignment of formulas across MES, data lake/BI, and any local spreadsheets to avoid multiple versions of the same KPI.
    • Data sources and lineage
      • Approved source systems and signals for each KPI: MES, historians, ERP, LIMS, QMS, PLC tags, etc.
      • Data lineage and transformation rules from raw signals to KPI-ready data.
      • Expectations for data quality checks, reconciliation, and exception handling.
    • Change control and validation
      • Change process for KPI formulas, thresholds, and visualizations, integrated with existing IT and QMS change control.
      • Impact assessment for regulated contexts (e.g., whether a change affects validated reports, batch record content, or management review inputs).
      • Approval workflows and documentation for audits and internal traceability.
    • Usage and behavior
      • Guidance on how KPIs should and should not be used (e.g., for tier meetings, incentive schemes, supplier reviews).
      • Alignment of KPI targets with realistic process capability and qualification constraints.
      • Training expectations so that supervisors and engineers interpret metrics consistently.

    Why a single-owner model usually fails in regulated plants

    It is tempting to assign KPI governance to a single function (e.g., IT, quality, or a central analytics team). In most ISO 22400 implementations in regulated, long-lifecycle environments, this creates problems:

    • IT-only ownership often leads to technically correct dashboards that misrepresent actual operations because key edge cases, rework flows, and shop-floor realities are not captured. It can also conflict with quality and validation expectations.
    • Quality-only ownership may bias toward audit-friendly metrics and document-heavy processes that slow operational updates and discourage iterative improvement.
    • Operations-only ownership can optimize local decision-making but neglect data lineage, integration constraints, and alignment with corporate financial and regulatory reporting.
    • Corporate analytics-only ownership risks creating a parallel “metrics universe” that diverges from what MES, ERP, and local plants actually use, undermining trust.

    In brownfield environments with multiple MES, ERP, SCADA, and data lake solutions, a single function rarely has authority and context across all systems. Cross-functional governance is usually the only practical way to manage the tradeoffs among accuracy, usability, and compliance.

    Fitting ISO 22400 KPI governance into brownfield reality

    ISO 22400 projects almost always coexist with legacy metrics, site-specific dashboards, and long-qualified systems. Effective ownership should acknowledge that:

    • Full replacement of existing KPIs is rarely feasible in the short term. Replacing long-standing metrics or reports can trigger revalidation, retraining, and re-baselining of improvement programs. The governance group should plan for coexistence and phased convergence.
    • Site autonomy and corporate standards must be balanced. The governance group may define a core, standardized ISO 22400 KPI set, while allowing controlled local extensions with clear labeling and documentation.
    • Integration debt is a constraint, not an afterthought. OT and IT representatives must be able to say “no” or “not yet” when a desired ISO 22400 metric would require unsafe changes to PLCs, impactful MES outages, or brittle data pipelines.
    • Audit and regulatory expectations limit rapid changes. For plants where KPIs feed into management review, quality indicators, or batch release decisions, even “purely operational” metric changes can have regulated implications. Quality and regulatory affairs must be part of ownership.

    Practical ownership pattern

    A pragmatic approach many plants use for ISO 22400 KPI governance is:

    1. Charter a KPI governance group under existing operational governance, with a written mandate covering scope: ISO 22400 mapping, KPI definitions, and system-of-record decisions.
    2. Assign a single accountable leader (often a senior operations or manufacturing systems leader) who is responsible for convening the group and ensuring decisions are implemented, without owning all details personally.
    3. Define RACI for KPI lifecycle steps (design, implementation, validation where applicable, deployment, change management), spanning operations, quality, IT/OT, and finance.
    4. Embed KPI changes into standard change control so that KPI formula or source changes are treated like any other system change with risk assessment, testing or validation, and documented approvals.
    5. Review ownership annually as plants, systems, and regulatory expectations evolve, updating responsibilities and membership.

    In summary, KPI governance in an ISO 22400 project should be owned by a cross-functional governance group led by operations, with mandatory participation from quality, IT/OT, finance, and continuous improvement. Concentrating ownership in a single siloed function tends to fail in regulated, brownfield manufacturing environments.

  • Can I phase in ISO 22400 by site or must I do it all at once?

    ISO 22400 can be phased in by site. The standard defines how manufacturing KPIs are structured and calculated, but it does not require a single, simultaneous global go-live.

    Phased adoption is normal

    In multi-site, regulated environments, most organizations roll out ISO 22400 gradually, for example:

    • Pilot on one plant or value stream to harden definitions and data mappings.
    • Extend to other lines or sites once the KPI model, interfaces, and reports are stable.
    • Backfit legacy reports and dashboards over time, retiring old KPIs under change control.

    This approach reduces disruption, limits downtime on critical assets, and respects the validation/qualification burden on MES, historians, and reporting tools.

    Key constraints and risks in a site-by-site rollout

    A phased approach is feasible, but there are non-trivial constraints you need to manage explicitly:

    • Single source of truth for KPI definitions: Maintain a governed catalog of ISO 22400-aligned KPIs (e.g., OEE, availability, performance, quality) so that each site implements the same definition and calculation method.
    • Version control and traceability: Treat KPI definition changes like any other controlled document or configuration. You should be able to show which version of a KPI definition was active for which site and time period.
    • Mixed-state reporting: During the transition, some sites will use ISO 22400-compliant KPIs and others will not. Enterprise dashboards must clearly label which metrics are ISO 22400-based and avoid blended rollups that silently mix incompatible definitions.
    • System coexistence: Brownfield plants will often keep legacy MES/SCADA/ERP reports. Plan for coexistence rather than assuming you can replace them all at once, and map legacy data sources into the ISO 22400 model incrementally.
    • Validation and qualification: Any MES, historian, or analytics changes that support ISO 22400 KPIs will typically require validation, especially in aerospace, defense, or medical-adjacent work. Phasing by site can limit scope, but you still need documented test evidence for each environment.
    • Operator and supervisor training: Ensure each site understands not just the formulas, but how events (downtime, speed loss, scrap) must be logged to keep ISO 22400 KPIs meaningful. Training content and work instructions should be controlled and consistent.

    Why not do a single global cutover?

    In long-lifecycle, regulated manufacturing, attempting a “big bang” ISO 22400 rollout across all sites often fails or stalls due to:

    • Integration complexity: Sites use different versions of MES, historians, PLC code, and ERP. Aligning all data interfaces and event models at once is high risk.
    • Downtime and production risk: Coordinated, multi-site downtime windows are rare. Plants typically cannot accept simultaneous disruption to data collection on critical lines.
    • Validation burden: Validating new KPI logic and data flows across all sites at once creates a large, multi-team validation project with high coordination overhead.
    • Change saturation: Operators, planners, and quality leads already manage multiple initiatives. Phasing reduces the load and allows lessons learned from early sites to improve later rollouts.

    For these reasons, a controlled, incremental rollout is usually more realistic than full replacement of existing KPI and OEE reporting in one step.

    How to phase ISO 22400 responsibly

    To make a site-by-site approach robust and auditable:

    • Define a corporate KPI governance model: Clarify who owns ISO 22400 interpretations, approves changes, and manages the central KPI catalog.
    • Choose a reference site: Implement ISO 22400 rigorously at one site first and treat it as the reference implementation for others.
    • Standardize data mapping patterns: Document how common events (planned downtime, minor stops, rework, scrap) map to ISO 22400 inputs so other sites can follow the same pattern even with different equipment vendors.
    • Maintain clear labeling during transition: Mark reports and dashboards with “ISO 22400-aligned” where applicable, and keep legacy KPIs visibly separate until migrated.
    • Use formal change control: Manage each site’s transition as a controlled change, with impact analysis, test plans, and rollback procedures.

    In summary, you do not need to implement ISO 22400 everywhere at once. A phased rollout by site is often the only practical option in brownfield, regulated operations, provided you enforce cross-site consistency of definitions, robust change control, and clear traceability for how metrics are calculated and used.

  • Should custom KPIs reuse ISO 22400 terminology?

    In most cases, yes: if your custom KPI is conceptually the same as an ISO 22400 metric, reusing the ISO term and structure is beneficial. However, it is not mandatory and should not be forced where the fit is poor or would confuse existing stakeholders.

    When it makes sense to reuse ISO 22400 terminology

    Reusing ISO 22400 names and definitions usually helps when:

    • The KPI concept matches closely, for example availability, performance, quality rate, OEE-related measures, and many standard production or resource utilization indicators.
    • Multiple plants or vendors are involved and you want a common language across different MES, historians, and analytics tools.
    • Auditability and traceability matter, because referencing a recognized standard can make it easier to explain how a KPI is defined and maintained, without implying compliance or certification.
    • Data integration is a problem today, and aligning to a standard reduces mapping work between systems or sites.

    In these situations, adopting ISO 22400 terms (and documenting the link to the ISO definition) can reduce ambiguity, support evidence packages, and make future system upgrades or integrations less brittle.

    When you should not force ISO 22400 reuse

    There are also valid reasons not to reuse ISO 22400 terminology mechanically:

    • Your KPI meaning diverges materially from the ISO definition, for example mixing schedule adherence with throughput in a single composite score.
    • Legacy reports and SOPs already rely on a different term and renaming would create confusion or significant retraining burden without clear benefit.
    • Regulatory filings, customer contracts, or internal specifications bind you to historical KPI definitions that are not ISO 22400 aligned.
    • Your data model cannot support the ISO definition cleanly today due to how downtime, scrap, or rework are captured, and changing it would require high-risk system and validation changes.

    In these cases it is often safer to keep the existing term but explicitly document how it differs from the nearest ISO 22400 metric, rather than forcing alignment in name only.

    Practical approach in brownfield, regulated environments

    In mixed, validated system landscapes, a pragmatic approach typically looks like this:

    1. Map first, rename later (if at all)
      Start by mapping existing KPIs to ISO 22400 concepts where possible. Capture this mapping in a controlled document or data dictionary rather than changing system names immediately.
    2. Document definitions and formulas
      For each KPI, maintain a controlled definition including purpose, formula, data sources, aggregation rules, and any deviations from the ISO 22400 definition. This supports traceability and audit questions regardless of naming.
    3. Use aliases in tools and specifications
      Where systems allow, you can show both the legacy name and an ISO 22400-aligned alias. This is often less disruptive than fully renaming tags, reports, or MES objects.
    4. Apply change control to any renaming
      Renaming KPIs in MES, data warehouses, or reports can affect trending, alerting, and validated calculations. Treat KPI definition and naming changes under the same change control and validation discipline as other configuration changes.
    5. Avoid full replacement just to match ISO terms
      Swapping out existing KPI logic or systems solely to achieve ISO 22400 purity rarely justifies the downtime, revalidation, and integration risk in aerospace-grade or similar environments.

    Benefits and tradeoffs of ISO 22400 alignment

    Potential benefits:

    • More consistent understanding of KPIs across plants, vendors, and functions.
    • Simpler interface specifications for MES, historians, and analytics tools.
    • Clearer responses in audits when asked how performance is measured and controlled.
    • Smoother integration with commercial tools that already reference ISO 22400 structures.

    Key tradeoffs and risks:

    • Retraining and change impact on operations, quality, and management accustomed to legacy KPI names and dashboards.
    • Historical comparability risks if the underlying formula changes while keeping the same name, or vice versa.
    • Configuration and validation effort to update MES, data pipelines, and reports under change control.
    • Vendor mismatches where off-the-shelf MES or OEE modules use proprietary definitions that only partially align with ISO 22400.

    Recommended policy stance

    A balanced policy in regulated, long-lifecycle operations is:

    • Prefer reuse of ISO 22400 terminology where the KPI meaning and formula are substantially the same.
    • Explicitly document any deviations when your custom KPI only partially aligns with an ISO 22400 metric.
    • Allow justified exceptions when aligning would introduce confusion, high change cost, or conflict with validated or contractual definitions.
    • Maintain a master KPI catalog (under document control) that records the relationship between your KPIs and relevant ISO 22400 metrics.

    This approach gains most of the interoperability and clarity benefits of ISO 22400 while respecting brownfield constraints and existing regulatory and validation commitments.

  • How do we label KPIs that are outside the ISO 22400 framework?

    KPIs that are outside the ISO 22400 framework can be used, but they should be labeled in a way that avoids any implied standardization while still making them usable across plants, systems, and audits.

    1. Distinguish clearly between ISO 22400 and non-ISO KPIs

    In KPI catalogs, reports, and dashboards, use explicit labeling so it is obvious which metrics are standardized and which are not. For example:

    • ISO 22400 KPI: Use the ISO name, identifier, and unit where adopted without modification.
    • ISO-derived KPI: If you have modified a formula, scope, or unit, label it as “ISO 22400-derived” and document the deviation.
    • Local KPI: For KPIs that have no ISO 22400 equivalent or intentionally diverge, label them as “Local” or “Site-specific” KPIs.

    This separation reduces the risk that non-standard KPIs are misinterpreted as ISO-compliant during internal reviews or external audits.

    2. Use a structured naming convention

    Define a naming pattern that indicates origin and scope. Example conventions (adapt to your environment):

    • Standard (ISO) KPIs: ISO22400:<Category>:<KPI Code>:<Short Name>
    • ISO-derived KPIs: ISO22400-DER:<Category>:<Plant or BU>:<Short Name>
    • Local KPIs: LOCAL:<Function>:<Plant or BU>:<Short Name>

    Whatever pattern you choose, apply it consistently in MES, data warehouses, BI tools, and documentation. In brownfield environments with many legacy reports, this is often rolled out gradually via change control.

    3. Map non-ISO KPIs to ISO categories where it makes sense

    Even if a KPI is outside ISO 22400, it can often be mapped conceptually to an ISO category (for example, availability, performance, quality, resource utilization). To keep this transparent:

    • Maintain a KPI catalog that includes, for each KPI, an optional “Related ISO 22400 category” field.
    • Use this only as a logical mapping, not as a compliance claim.
    • Document when no reasonable ISO category exists and leave the field empty rather than forcing a fit.

    This helps stakeholders understand how local metrics align with broader operational performance topics without implying that the metric itself is part of the standard.

    4. Document definitions, formulas, and boundaries

    For non-ISO KPIs, documentation matters more than the label itself, especially in regulated environments and long-lifecycle plants. For each KPI, document at minimum:

    • Purpose and decision use: What decisions does this KPI support, and at what level (cell, line, plant, enterprise)?
    • Exact formula and units: Include numerator, denominator, time base, and any exclusion rules.
    • Data sources and systems: MES tags, historians, QMS records, ERP transactions, etc.
    • Scope and applicability: Which sites, products, shifts, or technologies the KPI is valid for.
    • Owner and steward: Who can approve changes.

    This should live in a controlled repository (KPI catalog, data dictionary, or equivalent) under your existing document control and change management processes.

    5. Integrate labeling into existing systems, not just documentation

    In brownfield environments, the same KPI often appears across multiple systems: legacy MES screens, spreadsheets, BI dashboards, and reports. To keep labeling consistent:

    • Introduce the ISO vs local status as a field in your KPI catalog and use that to drive how metrics are labeled in front-end tools.
    • Where technically feasible, add a short prefix or badge in dashboards (for example, “ISO”, “ISO-derived”, “Local”).
    • In data warehouses or data lakes, represent KPI type as a column (for example, kpi_standard_type with values like ISO22400, ISO22400_DERIVED, LOCAL).
    • Apply changes gradually under change control to avoid breaking validated reports or interfaces.

    Full replacement of legacy KPI definitions purely to align with ISO often fails in regulated settings due to validation effort, downtime risk, and change management burden. A coexistence model, with clear labeling, is typically more realistic.

    6. Manage non-ISO KPIs under formal change control

    Non-ISO KPIs can still be critical for operations and quality. Treat them as configuration items:

    • Review and approve new KPIs through a cross-functional governance group (operations, quality, IT/OT, and sometimes finance).
    • Version-control definitions and keep a change history detailing why the KPI was introduced or changed.
    • Assess impact on validation and audit trails when modifying or retiring KPIs, especially those used in batch release, traceability, or regulatory reporting.

    This reduces the risk of silent metric drift and conflicting values across systems and sites.

    7. Communicate limitations explicitly

    When you publish or use KPIs outside the ISO 22400 framework:

    • State clearly in documentation and, where practical, in reports that the KPI is not an ISO 22400 standard metric.
    • Avoid wording or abbreviations that could be confused with ISO 22400 KPI names or identifiers.
    • Be explicit when comparing plants or suppliers that some metrics are local and not suitable for direct benchmarking.

    This reduces misunderstanding during audits, customer visits, and internal performance reviews.

    Summary

    You can label KPIs outside ISO 22400 as long as you avoid implying standardization. The practical pattern in regulated, brownfield environments is:

    • Use clear labels such as “ISO 22400”, “ISO 22400-derived”, and “Local” or “Site-specific”.
    • Maintain a governed KPI catalog with precise definitions and optional conceptual mapping to ISO categories.
    • Reflect KPI type in all systems where the metric appears, rolling out changes under existing change control and validation processes.