Connect981 – Content Dev

RSC Cluster: ISO 22400 Manufacturing KPIs for Modern Plants

  • Versioning

    Versioning is the controlled practice of assigning, tracking, and managing unique versions of an item over time. In industrial and regulated environments, it commonly applies to documents, specifications, recipes, bills of materials, software, configurations, and data models that are expected to change while remaining traceable.

    Each version is typically identified by a version number or code and is associated with metadata such as effective date, author or owner, change description, and approval status. Versioning allows organizations to know exactly which definition, instruction set, or configuration was in use at a given time and to compare or revert changes when needed.

    How versioning is used in manufacturing and industrial operations

    In manufacturing systems and quality environments, versioning commonly applies to:

    • Controlled documents such as SOPs, work instructions, test methods, and quality manuals within document control systems or QMS.
    • Product definitions including part specifications, CAD models, bills of materials (BOMs), routings, and process parameters managed in PLM, ERP, or MES.
    • Manufacturing recipes and formulas used in batch or continuous processes, often managed in MES or recipe management systems.
    • Software and configurations for OT/IT systems, including MES versions, PLC logic, SCADA configurations, and integration mappings.
    • Data structures such as schemas, interfaces, and APIs that connect MES, ERP, LIMS, and other applications.

    Operationally, versioning supports tasks such as:

    • Ensuring operators use the correct, current version of work instructions on the shop floor.
    • Tracking when a new version of a process or recipe becomes effective and for which products or lines.
    • Maintaining a history of previous versions for audit, investigation, or comparison.
    • Coordinating releases so that dependent systems and documents are updated consistently.

    What versioning includes and excludes

    Versioning includes:

    • Assigning identifiers to each version (for example, 1.0, 1.1, 2.0, or letter-based revisions).
    • Maintaining a change history (who changed what, when, and why).
    • Defining status and lifecycle stages (for example, draft, in review, effective, retired).
    • Linking versions to their applicable context (effective dates, plants, lines, or customers).

    Versioning does not, by itself, define:

    • How changes are approved or reviewed; that is handled by change control or change management processes.
    • How often something should change or which version is “best”; it only records and distinguishes versions.
    • Regulatory compliance; it provides traceability that may support compliance, but is not proof of it.

    Versioning approaches

    Organizations use different approaches to structure versions, such as:

    • Sequential versioning where each new release increments a simple number or letter (for example, Rev A, Rev B, Rev C).
    • Semantic versioning (often in software) where version segments represent levels of change (for example, major.minor.patch such as 2.3.5).
    • Branching and merging in software or configuration management, where multiple development lines exist and are later combined, while each state has a defined version.

    In document control and MES/ERP environments, the key requirement is that the versioning scheme is consistent, understandable, and applied uniformly to the items under control.

    Common confusion

    • Versioning vs. revision: In many manufacturing and quality contexts, these terms are used interchangeably for the act of updating and labeling a controlled item. Some organizations use “version” for software or data and “revision” for documents or drawings, but both refer to identifiable states in a change history.
    • Versioning vs. change control: Versioning records the outcomes of change (the versions). Change control refers to the process and governance used to evaluate, approve, and implement those changes.
    • Versioning vs. backup: Backups create copies for recovery. Versioning creates an ordered history of intentional changes that are visible and selectable within normal operations.

    Relation to regulated and audit-ready environments

    In regulated manufacturing, versioning is typically part of broader document control, configuration management, and data governance practices. Clear version histories support traceability, reconstruction of past conditions, and evidence for internal or external reviews.

  • Who should be on a manufacturing KPI governance council?

    A manufacturing KPI governance council should include the people who own the process, the people who generate or steward the data, and the people who will be held accountable for acting on the metric. If one of those groups is missing, KPI definitions usually drift, reporting becomes political, and local workarounds take over.

    In most plants, the council should include:

    In practice, this connects to ISO 22400 KPI governance when teams need to turn the answer into repeatable execution habits.

    • Operations leadership, because they own throughput, schedule adherence, labor utilization, and day-to-day response.
    • Quality leadership, because many KPIs depend on how scrap, rework, defects, holds, deviations, and escapes are classified.
    • Manufacturing engineering or industrial engineering, because routing structure, cycle assumptions, standard work, and process changes affect KPI meaning.
    • IT and data/integration owners, because KPI reliability depends on source-system logic, interfaces, master data, timestamp quality, and reporting architecture.
    • Finance, if the council governs cost, variance, inventory, or cost-of-poor-quality metrics.
    • Planning or supply chain, if KPIs include schedule attainment, shortage impact, WIP aging, supplier performance, or queue behavior.
    • Site or business-unit leadership, to resolve cross-functional conflicts and approve standards that local teams may resist.
    • System owners for MES, ERP, QMS, historians, or data platforms that feed the governed KPIs.

    If the council is enterprise-wide, add representation from each major plant type or value stream. A single centralized team often misses real differences between discrete assembly, machining, batch processing, test, and repair operations. At the same time, letting every site define KPIs independently usually destroys comparability. The council has to manage that tradeoff directly.

    Who should not be the whole council

    No single function should dominate the group. A KPI council made up only of executives tends to approve metrics that look clean in slides but are weak operationally. A council made up only of analysts or IT teams often produces technically consistent numbers that do not match how the floor actually runs. A council made up only of site operators may optimize for local practicality while losing enterprise consistency.

    It is also a mistake to confuse stakeholders with decision-makers. Not everyone who consumes dashboards needs a vote on metric definitions. Keep the voting group limited, then bring in subject matter experts as needed for specific metrics.

    Typical roles and responsibilities

    The council works best when membership is paired with explicit responsibility:

    • Chair or sponsor to set priorities and break deadlocks.
    • KPI owners for each governed metric, usually from the business function accountable for outcomes.
    • Data owners or stewards for source-system definitions, transformations, and lineage.
    • Validation or quality representatives where reporting changes affect controlled processes, evidence, or decision support in a regulated environment.
    • Change control participants to review proposed definition changes, effective dates, impact analysis, and communication plans.

    Without named ownership, councils often discuss KPI problems repeatedly without fixing the underlying data, workflow, or definition issue.

    How big should it be?

    Usually 6 to 10 core members is enough. Larger groups become review forums instead of governance bodies. If you need broad input, create a smaller decision council and a wider working group underneath it.

    The right size depends on scope. A single-site KPI council can be leaner. A multi-site council with MES, ERP, QMS, and PLM dependencies usually needs more structured representation because changes in one system can alter reporting logic elsewhere.

    Brownfield reality

    In a brownfield environment, council membership should reflect the systems that actually exist, not the architecture leadership wishes it had. If KPI data comes from a mix of legacy ERP, partial MES coverage, spreadsheets, machine data, and QMS records, the council needs members who understand those boundaries. Otherwise, it will approve definitions that cannot be implemented consistently.

    This is also why full replacement is rarely the first answer. Replacing every execution and reporting system to standardize KPIs sounds clean, but in regulated and long-lifecycle operations it often fails under qualification burden, validation effort, integration complexity, downtime risk, and the need to preserve traceability across old and new records. In practice, the council usually has to govern KPI semantics across coexistence, not assume a reset.

    What the council should decide

    A KPI governance council is not just a dashboard review committee. It should decide:

    • which KPIs are official and which are local working metrics
    • the precise business definition for each KPI
    • source systems of record and fallback rules
    • calculation logic, inclusion and exclusion criteria, and effective dates
    • how changes are approved, tested, documented, and communicated
    • where site variation is allowed and where it is not
    • how exceptions, data quality issues, and disputed numbers are escalated

    If the council is not empowered to make those decisions, membership matters less because governance is not actually happening.

    Practical rule of thumb

    If a function can change the meaning of the metric, the availability of the data, or the action taken based on the result, it should be represented directly or through a named owner. If it only consumes the report, it does not necessarily need a seat.

    So the short answer is: include business owners, data owners, system owners, and decision-makers. Keep the group cross-functional, accountable, and small enough to govern definitions under change control. The exact roster depends on your KPI scope, plant diversity, and system landscape.

  • What types of users should see which ISO 22400 KPIs?

    ISO 22400 defines a common language for manufacturing KPIs, but it does not dictate who should see what. In regulated, mixed-system environments, you allocate KPIs by role, time horizon, and decision scope, and you limit views that can be misinterpreted or gamed.

    1. Executive leadership (plant leadership, VP Ops, COO)

    Goal: Direction, risk, and capital allocation, not minute-by-minute control.

    In practice, this connects to ISO 22400 KPI governance when teams need to turn the answer into repeatable execution habits.

    Typical ISO 22400 KPI focus:

    • High-level OEE / availability / performance per plant or line, trend-based, not real time.
    • Order fulfillment and due-date adherence (delivery performance) by value stream or customer group.
    • Scrap and rework rates as a contribution to cost of poor quality (aligned with finance, not shop-floor detail).
    • Capacity utilization and bottleneck load for expansion / investment decisions.

    What they should usually not see directly: Raw machine-level stoppage codes, operator-level performance, and unvalidated real-time dashboards. These tend to drive micro-management and can conflict with union or HR constraints.

    2. Operations managers and area supervisors

    Goal: Daily/shift control, schedule adherence, and coordination across lines and support functions.

    Typical ISO 22400 KPI focus:

    • OEE components by line or cell (availability, performance, quality) with drill-down.
    • Planned vs actual production by work center and shift.
    • Planned vs unplanned downtime, with reason codes and impact in minutes.
    • Changeover times and setup efficiency for high-mix lines.
    • Rework and first-pass yield per area (not yet at operator granularity).

    Key constraints: These users need near real-time data, but only if integrations and timestamp alignment between MES, machines, and ERP are trustworthy. If data quality is weak, prioritize stable daily and weekly aggregates to avoid chasing noise.

    3. Process engineering and industrial engineering

    Goal: Identify and validate improvement opportunities, set realistic standards, and support new product introduction.

    Typical ISO 22400 KPI focus:

    • Cycle time and takt alignment at operation level.
    • Micro-stoppage and minor loss KPIs (short stops, speed losses).
    • Changeover / setup KPI detail including variance vs standard.
    • Process capability / quality-related KPIs linked to yield and scrap.
    • Resource utilization and routing adherence by product family.

    Data caveats: Engineers often need more granular data than ISO 22400 names directly. Use ISO 22400 KPIs as the roll-up layer, but maintain traceability to machine tags, MES event logs, and routing data for root-cause work. Changes to KPI definitions must follow change control and be documented.

    4. Quality and reliability engineering

    Goal: Detect quality drift quickly, understand process-related drivers, and support audits and investigations.

    Typical ISO 22400 KPI focus:

    • Quality rate / defect rate aligned with OEE quality component.
    • First-pass yield by product or key characteristic families.
    • Rework and scrap ratios by line and shift.
    • Inspection throughput and backlog KPIs where inspection is a constraint.
    • Supplier-related defect KPIs connected to incoming inspection and NCR data (even if not strictly part of ISO 22400).

    Integration considerations: Quality KPIs often require merging MES, QMS, and ERP data and preserving full genealogy. If traceability is incomplete, be explicit about scope (e.g., only certain part families, only certain lines) and avoid using partial KPIs as formal audit evidence without clear limits.

    5. Production planners and schedulers

    Goal: Build feasible schedules and respond to disruptions without breaking due-date commitments or regulatory routing constraints.

    Typical ISO 22400 KPI focus:

    • Effective capacity and load by line or work center (derived from OEE and planned availability).
    • Adherence to plan (schedule attainment, sequence adherence).
    • Queue time and WIP indicators at key work centers.
    • Downtime impact on available capacity (rolling view).

    Brownfield constraint: In many plants, these KPIs depend on fragile integrations between ERP and MES. If routing data or shift calendars are inconsistent, planners should see clear data quality flags rather than a false sense of precision.

    6. Maintenance and reliability teams

    Goal: Prioritize interventions that restore or improve availability without jeopardizing validation states or regulatory approvals.

    Typical ISO 22400 KPI focus:

    • Asset availability and downtime metrics by equipment.
    • Mean time between failures (MTBF) / mean time to repair (MTTR).
    • Preventive vs corrective maintenance ratios.
    • Maintenance-related production loss translated into time or missed orders.

    Regulated-environment nuance: Some equipment cannot be taken down freely due to validation or qualification constraints. Visibility should distinguish between theoretical and realistic availability so maintenance does not get penalized for constraints they cannot change.

    7. Line leaders, team leads, and operators

    Goal: Run the shift safely and effectively, surface issues early, and improve within their span of control.

    Typical ISO 22400 KPI focus:

    • Simple, shift-level OEE view for their line or cell only.
    • Current shift performance vs target (pieces, takt adherence, first-pass yield) with minimal lag.
    • Top downtime reasons this shift or day.
    • Right-now constraints: WIP status, missing materials, machine state.

    What to avoid: Cross-line comparisons, operator-level league tables, and financialized KPIs at the station level often create blame behavior, workarounds, and under-reporting of issues. In regulated environments, that can also undermine data integrity and auditability.

    8. IT, data, and MES administrators

    Goal: Ensure KPI calculations are reliable, explainable, and stable across system changes.

    Typical ISO 22400 KPI focus:

    • Meta-KPIs on data quality: event completeness, timestamp alignment, missing reason codes.
    • System latency KPIs: time from event to dashboard availability.
    • Consistency checks between ISO 22400 KPIs and legacy plant KPIs.

    Why this matters: In brownfield environments with mixed vendors, the same-named KPI can be calculated 3 different ways. IT and data owners need visibility to maintain a validated, version-controlled KPI definition set and to document changes under formal change control.

    9. Avoiding common missteps in KPI visibility

    Regardless of role, several pitfalls recur when exposing ISO 22400 KPIs broadly:

    • Unvalidated real-time KPIs: Streaming data that is not reconciled with MES/ERP often conflicts with official reports and erodes trust.
    • Full replacement of legacy metrics: Trying to replace long-used local metrics overnight with ISO 22400 definitions can fail because of qualification burden, audit expectations, and user resistance. A coexistence and mapping period is usually necessary.
    • Operator-level financial KPIs: Tying individuals directly to cost KPIs can incentivize hiding defects or bypassing paperwork in regulated settings.
    • Lack of context: Showing OEE or downtime without explaining constraints (e.g., mandated inspections, change control, validation windows) leads to unrealistic targets and friction between functions.

    10. Practical allocation guidelines

    Given local differences in systems and maturity, there is no universal matrix, but the following rules of thumb are broadly applicable:

    • Match time horizon to role: Executives see weekly/monthly views; supervisors see shift/daily; operators see current and last shift.
    • Match scope to span of control: Operators see their cell; supervisors see their area; plant leadership sees the plant.
    • Keep one “official” definition set: Even if multiple systems calculate variants, maintain a single, documented ISO 22400-aligned definition per KPI used for reporting and audits.
    • Introduce ISO 22400 via mapping, not replacement: Start by mapping existing KPIs to ISO 22400, then progressively harmonize as integrations and validation catch up.

    Ultimately, who sees which ISO 22400 KPI is a governance decision that depends on data reliability, system coexistence, and organizational trust. Treat KPI visibility as part of your overall MES/analytics governance, with clear ownership and change control.

  • Can I keep my TPM-style OEE while adopting ISO 22400 terminology?

    You can usually keep your TPM-style OEE while adopting ISO 22400 terminology, but only if you treat them as two distinct KPI definitions and manage the mapping transparently. You cannot call an unchanged TPM-style metric “OEE per ISO 22400” unless it actually follows the ISO 22400 definitions.

    What you can safely do

    In most regulated, brownfield environments, a practical approach is:

    In practice, this connects to ISO 22400 KPI governance when teams need to turn the answer into repeatable execution habits.

    • Keep TPM OEE as a legacy or shop-floor KPI where it works well for day-to-day improvement.
    • Introduce ISO 22400 KPIs (e.g., OEE, OOE, TEEP, availability, performance, quality rate) in parallel, with clear formulas and data sources.
    • Document a mapping that explains how TPM OEE relates to ISO 22400 metrics, where it differs, and where it should or should not be used.
    • Constrain use cases: for example, allow TPM OEE for line-level Kaizen, but use ISO 22400 definitions for cross-site comparison, management reporting, or external communication.

    Key differences you must manage

    The feasibility depends on how far your current TPM OEE deviates from ISO 22400. Common gaps include:

    • Loss categories: TPM OEE often mixes planned/unplanned losses differently from ISO 22400 (which is stricter about what goes into availability, performance, and quality).
    • Ideal cycle time: TPM implementations may define it by target rate, marketing rate, or historical best. ISO 22400 expects a clearly defined, validated reference.
    • Planned shutdowns and changeovers: Some TPM practices exclude part or all of these from OEE. ISO 22400 allows related KPIs (like OOE) instead of “quietly” excluding time.
    • Scrap and rework handling: Quality rate and definition of “good units” must be consistent with your quality system, not just the OEE spreadsheet.

    If you retain TPM OEE, these differences need to be spelled out, not assumed.

    Governance and documentation expectations

    In regulated, long-lifecycle environments, coexistence is mostly a governance problem, not a math problem. To avoid confusion and audit friction:

    • Define both metrics formally: Maintain controlled documents that specify the exact formula, time base, inclusions/exclusions, and intended use for TPM OEE and ISO 22400 OEE.
    • Use unambiguous names: For example, “TPM OEE (legacy)” vs “OEE (ISO 22400)” rather than both just called “OEE” in MES/BI dashboards.
    • Implement change control: Any shift from TPM OEE to ISO 22400 in a system of record, or in a critical KPI, should go through formal change control and, where applicable, validation/qualification.
    • Explain in procedures and training: Supervisors, engineers, and planners should be trained on which OEE is used where and why, especially if incentives or capacity decisions depend on it.

    System and integration implications

    In brownfield stacks, you should assume some systems are “hard-wired” to a specific OEE definition:

    • MES/SCADA: Often configured with a particular OEE logic. Changing this to ISO 22400 can require significant reconfiguration, testing, and potential revalidation. In many plants it is safer to add new ISO 22400 metrics than to replace the existing OEE calculation.
    • ERP/APS: Capacity and cost models may implicitly assume your TPM OEE values. Introducing ISO 22400 OEE without re-aligning planning parameters can distort utilization assumptions.
    • BI tools and data warehouses: You may need separate fields (e.g., oee_tpm and oee_iso22400) with clear metadata, rather than overloading a single “OEE” column.

    Full replacement of TPM OEE logic inside legacy MES/SCADA is often disruptive because of validation burden, regression risk, and limited downtime. Coexistence via new calculated fields or a data layer is usually lower risk.

    How to avoid misuse and confusion

    The main risk of keeping TPM OEE is not technical; it is misinterpretation:

    • Do not mix series in one chart without clear labels. TPM and ISO 22400 OEE on the same trend line create false improvement or deterioration signals.
    • Do not change definitions silently: If you switch a site, cell, or product line from TPM OEE to ISO 22400 OEE, treat it like a method change and mark the historical breakpoint.
    • Clarify what goes into targets: If performance bonuses or corporate KPIs use OEE, lock down which definition is used and avoid changing it mid-cycle.

    When you should not keep TPM OEE

    There are cases where maintaining TPM OEE in parallel is more harmful than helpful:

    • If TPM OEE is heavily customized by team, line, or product such that there is no single, coherent definition.
    • If you are planning cross-site or cross-product benchmarking where ISO 22400 consistency is a requirement from corporate leadership or customers.
    • If TPM OEE is already poorly trusted and you are using ISO 22400 adoption as a credibility reset.

    In those cases, a carefully planned migration to ISO 22400, with clear cutover dates and preserved raw data, is often better than long-term coexistence.

    Pragmatic migration pattern

    A common, lower-risk pattern in regulated, mixed-vendor environments is:

    1. Baseline: Document your current TPM OEE calculation and its data sources line by line.
    2. Design ISO 22400 KPIs: Define OEE and related KPIs strictly per ISO 22400, based on the data you can reliably collect.
    3. Run in parallel: Calculate both TPM OEE and ISO 22400 OEE from the same underlying events for a defined period and compare behavior.
    4. Decide roles: Decide where TPM OEE remains (if at all) and where ISO 22400 becomes the single source of truth.
    5. Harden and validate: Apply change control, update procedures, train users, and, if needed, perform formal validation/qualification of new KPI logic in MES/BI systems.

    This approach allows you to keep TPM-style OEE where it is still useful, while gradually aligning strategic and cross-plant metrics to ISO 22400 without a high-risk, big-bang replacement.

  • Is ISO 22400 suitable for benchmarking OEE across suppliers?

    ISO 22400 can be a good starting framework for benchmarking OEE across suppliers, but it is not sufficient on its own to guarantee comparable numbers. OEE is highly sensitive to how each party defines availability, performance, and quality, and how data is collected and classified in real plants.

    What ISO 22400 actually helps with

    ISO 22400 focuses on standardized definitions and structures for manufacturing KPIs, including OEE-related concepts. In a multi-supplier context, it is useful to:

    In practice, this connects to ISO 22400 KPI governance when teams need to turn the answer into repeatable execution habits.

    • Provide a common vocabulary for availability, performance, and quality components.
    • Align at a high level on what is “planned” time, “unplanned” downtime, rejects, and rework.
    • Support traceability of KPI logic for validation, audits, and change control.

    Using ISO 22400 as a reference can reduce arguments about basic terminology, and it gives you a standard to point to in contracts and technical specifications.

    Where ISO 22400 is not enough for benchmarking

    Cross-supplier benchmarking requires much more detail than the standard provides. In practice, OEE comparability usually fails for reasons like:

    • Different time bases and scope: Some suppliers include planned maintenance in the denominator, some exclude it. Some measure at machine level, others at line or cell level.
    • Different loss modeling: Micro-stops, changeovers, setups, training, and engineering trials may be classified differently (or not captured at all).
    • Different speed assumptions: “Ideal cycle time” can be nameplate speed, validated sustainable speed, or an internal target adjusted for product mix.
    • Quality calculation differences: Some include only scrap, others include rework and sort activity. Some count late defects found downstream, others only at the station.
    • Data collection and integration gaps: Legacy MES, manual entries, and partial automation lead to inconsistent event capture and timestamp quality.
    • Regulatory and validation constraints: In regulated plants, changes to data models and OEE logic require controlled change, so not all suppliers can align at the same pace.

    ISO 22400 does not resolve these implementation choices. Without harmonizing them, two suppliers can both claim “ISO 22400 based OEE” and still produce numbers that are not benchmarkable.

    What you need in addition to ISO 22400

    To use OEE for supplier benchmarking in a regulated, brownfield environment, you need a more prescriptive framework layered on top of ISO 22400:

    1. Explicit KPI specification
      Document, in controlled specifications, exactly how OEE is calculated for the benchmarking program, including:
      • Measurement level (asset, line, process segment, site).
      • Time base and calendar rules (e.g., planned shutdowns, holidays, maintenance).
      • Definitions of “good units,” “scrap,” and “rework.”
      • How micro-stops and speed losses are captured or approximated.
      • How startup, trials, and engineering runs are handled.
    2. Data collection and system mapping
      For each supplier, map your specification to their real systems (MES, SCADA, PLCs, historians, QMS, ERP). Identify:
      • Which tags, events, and transactions drive each OEE component.
      • Where approximations or manual entries are used.
      • Gaps where data is not currently available or reliable.
    3. Validation and traceability
      In regulated contexts, treat the OEE logic as configurable, validated functionality:
      • Maintain version-controlled calculation logic and mappings.
      • Perform sanity checks and sample-based reconciliations against source data.
      • Document changes through formal change control so trends remain interpretable.
    4. Normalization and tiers
      Recognize that strict 1:1 comparability may be unrealistic across very different technologies and product mixes. Many firms use:
      • Benchmarking bands or tiers (e.g., by process type or product family).
      • Relative improvement metrics (e.g., year-on-year improvement) in addition to absolute OEE.
      • Separate KPIs for stability (variance) and loss structure, not just headline OEE.

    Brownfield and long lifecycle realities

    Most suppliers will not be able to fully re-platform MES or SCADA just to align with a standardized OEE model. Full replacement strategies are rarely viable due to qualification burden, validation cost, downtime risk, and complex integrations with legacy ERP, QMS, and historians. In practice you will need to:

    • Work with existing systems and create a mapping layer from local KPIs to your standardized definition.
    • Accept that some suppliers will have “equivalent but approximated” measures where data granularity is limited.
    • Phase alignment over time as systems are upgraded, instead of expecting instant standardization.

    Practical way to use ISO 22400 for supplier OEE benchmarking

    ISO 22400 is suitable as the reference framework, if you use it as part of a broader governance approach:

    1. Adopt ISO 22400 concepts and terminology and reference them in specifications.
    2. Issue a detailed OEE calculation guideline that constrains the choices ISO 22400 leaves open.
    3. Require suppliers to document how their existing systems map to your guideline, including deviations.
    4. Use audits, data reviews, and sample checks to verify that reported OEE matches the defined logic.
    5. Treat OEE numbers as decision-support estimates, not as certified figures, especially when commercial or contractual consequences are attached.

    With that structure, ISO 22400 helps by providing a common foundation and vocabulary, but the actual comparability depends on how rigorously you define, govern, and validate the implementation across suppliers.

  • Does ISO 22400 tell us which KPIs we must track?

    ISO 22400 does not prescribe a mandatory list of KPIs that every plant must track. Instead, it provides a standardized framework and definitions for manufacturing KPIs so different sites, systems, and suppliers can talk about performance in a consistent way.

    What ISO 22400 actually provides

    Across its parts, ISO 22400 focuses on:

    In practice, this connects to ISO 22400 KPI governance when teams need to turn the answer into repeatable execution habits.

    • Common terminology for manufacturing KPIs and related concepts.
    • Reference models for how KPIs relate to manufacturing operations and resources.
    • Standardized formulas and input data definitions for selected KPIs (for example, availability-related indicators, OEE-related components, utilization).
    • Guidance on how to structure and interpret KPIs across equipment, lines, and plants.

    The intent is to make KPI calculations transparent, comparable, and auditable across different vendors and sites, not to dictate your performance management strategy.

    What ISO 22400 does not do

    ISO 22400 does not:

    • Mandate a fixed set of KPIs for all manufacturers.
    • Specify target values or performance thresholds.
    • Guarantee regulatory or customer compliance if you follow its KPIs.
    • Replace customer, program, or regulatory reporting requirements that may define their own metrics.

    This is important in regulated, long-lifecycle environments. Customer contracts, airworthiness authorities, or internal quality procedures often introduce specific indicators or evidence requirements that go beyond (or differ from) ISO 22400 examples.

    How to use ISO 22400 in practice

    Most organizations use ISO 22400 as a reference and alignment tool, not as a checklist:

    • Define a KPI set that matches your risks and constraints: For example, OEE and availability for bottleneck equipment, NPT for systemic downtime analysis, and yield or defect-related KPIs for quality risk. ISO 22400 helps you define and calculate some of these consistently.
    • Align vendors and internal teams: When MES, SCADA, and analytics providers all claim to calculate OEE or availability, ISO 22400 gives you a standard to map their formulas against. This is particularly useful in brownfield plants with mixed vendor stacks.
    • Support traceability and validation: The standard’s explicit formulas and input definitions help you document how KPIs are computed, which data sources are used, and how changes are controlled over time.

    Dependencies and brownfield realities

    Even if you adopt ISO 22400 definitions, the KPIs you can realistically track depend on:

    • Data availability and quality: Legacy machines or partially integrated MES/ERP systems may not provide the required, timestamped signals or accurate state models for some KPIs.
    • Integration maturity: Calculating standardized KPIs often requires reconciling equipment states, orders, and material flows across MES, ERP, and historian/SCADA. In many aerospace-grade plants, this is incremental work, not a quick configuration.
    • Validation and change control: In regulated environments, changing KPI logic, data mapping, or time-bucket rules can trigger validation and documentation updates. This limits how fast you can standardize or refine KPI calculations, even if ISO 22400 provides a clear formula.
    • Operational priorities: Plants with high-mix, low-volume work, heavy rework, or complex routings may prioritize different KPIs than a high-volume line, even when both reference the same ISO 22400 building blocks.

    Because of integration debt and validation burden, trying to “fully replace” existing KPI schemes with an ISO 22400-pure model in one step often fails. Most organizations phase in ISO 22400-aligned definitions where the benefit (e.g., cross-site comparability, cleaner OEE) justifies the integration and validation cost.

    How to decide which KPIs to track

    In practice, you should select KPIs based on:

    • Critical constraints: Where do you actually lose capacity, schedule adherence, or yield?
    • Regulatory and contractual needs: What evidence do customers, auditors, and internal standards require?
    • System coexistence: Which KPIs can be calculated reliably with your current MES/ERP/QMS stack, and which require new integrations or significant rework?
    • Governance capability: Can you maintain traceable definitions, audit trails, and change control for the KPIs you introduce?

    Use ISO 22400 to standardize names, definitions, and calculations where they fit your context, but do not treat the standard as a mandatory KPI menu. It is a framework that you selectively adopt and adapt, grounded in your own risk profile and data reality.

  • How many global KPIs should a manufacturing group standardize?

    In most manufacturing groups, the right answer is not a large number. A practical global standard is often 5 to 12 KPIs, with plant-level and value-stream-level metrics beneath that.

    If you try to standardize 20, 30, or more KPIs globally, the failure mode is usually predictable: plants spend more time arguing about definitions, data extraction, exclusions, and ownership than using the measures to improve execution.

    In practice, this connects to ISO 22400 KPI governance when teams need to turn the answer into repeatable execution habits.

    What should be global

    Global KPIs should be limited to measures that meet all of these conditions:

    • They support enterprise decisions, not just local supervision.
    • They can be defined consistently enough across sites, shifts, products, and business models.
    • They have data sources that are credible and maintainable across your existing systems.
    • They are stable enough to survive change control and system upgrades.
    • Leadership is willing to govern the calculation rules, not just publish a dashboard.

    That usually points to a small core set covering delivery, quality, productivity, flow, and sometimes inventory or service performance. The exact set depends on whether the group is discrete, process, regulated batch, aerospace, MRO, or a mixed portfolio.

    What should stay local

    Many useful metrics should not be forced into a global standard. Examples include cell-level constraints, engineering response times, inspection queue aging, maintenance losses, labor utilization by skill mix, or program-specific rework drivers. Those can be critical locally without being globally comparable.

    A common pattern is:

    • Tier 1: 5 to 12 global KPIs with strict definitions
    • Tier 2: function or network metrics for business unit comparison
    • Tier 3: plant, line, cell, or program metrics optimized for local control

    That structure is usually more realistic than trying to make every site report the same long scorecard.

    What determines the right number

    The number depends less on reporting ambition and more on operational reality:

    • System landscape: Mixed MES, ERP, QMS, CMMS, and spreadsheets reduce how many metrics can be trusted globally.
    • Master data maturity: If calendars, routings, downtime codes, defect codes, or unit-of-measure rules differ by site, standardization breaks quickly.
    • Business model variation: A high-volume assembly plant and a high-mix low-volume repair or aerospace site may not share enough context for broad KPI uniformity.
    • Governance discipline: A KPI is not standardized because the label matches. It is standardized only if scope, formula, timing, exclusions, and ownership are controlled.
    • Validation burden: In regulated environments, metric logic tied to records, traceability, or release decisions may require formal review and change control.

    So the correct answer is not universal. A group with strong data governance and similar plants may support a broader set. A brownfield network with legacy systems may need a smaller global core to avoid false precision.

    Brownfield reality

    In mixed-vendor environments, global KPI standardization is often constrained by integration debt. Two plants may both report scrap, throughput, or schedule attainment while using different event models, different transaction timing, and different reclassification rules. That does not make one wrong, but it does mean the numbers may not be directly comparable without significant harmonization work.

    This is why full replacement strategies are often overestimated. Replacing MES, ERP, QMS, or reporting layers across all plants to force KPI uniformity can fail for predictable reasons: qualification burden, validation cost, downtime risk, integration complexity, and the need to preserve traceability and change control across long-lived assets and processes. In many groups, a federated model with a governed semantic layer is more realistic than a full platform reset.

    Practical guidance

    If you are deciding the number now, start with the minimum set needed for enterprise review and capital allocation. For most groups, that means no more than a dozen. Then document each KPI with:

    • business purpose
    • formal definition and formula
    • included and excluded events
    • source systems and precedence rules
    • owner and approval workflow
    • review frequency
    • change control process

    If you cannot define those cleanly, the KPI is not ready for global standardization.

    So, how many should a manufacturing group standardize globally? Usually a small core set, not an exhaustive one. If you need a simple rule of thumb, start with 5 to 12, prove comparability, and only expand when the data model, governance, and plant adoption are mature enough to support it.

  • Do we need to change our MES or ERP to support ISO 22400?

    You usually do not need to replace your MES or ERP to support ISO 22400. ISO 22400 defines a standardized model for manufacturing KPIs (such as OEE) and supporting data, not a specific software product. In most regulated, brownfield environments, the work is to map and extend what you already have, not to rip and replace core systems.

    What ISO 22400 actually requires

    At a practical level, supporting ISO 22400 means you can:

    In practice, this connects to ISO 22400 KPI governance when teams need to turn the answer into repeatable execution habits.

    • Calculate KPIs according to ISO 22400 definitions (e.g., equipment states, time categories, performance factors).
    • Trace the source data used for each KPI (events, quantities, time stamps) in a way that is auditable.
    • Use consistent terminology and structures so different plants or systems interpret KPIs the same way.

    The standard does not mandate a particular MES or ERP vendor, database, or architecture.

    When you can keep your existing MES/ERP

    In most plants, you can support ISO 22400 by working with your current stack and doing one or more of the following:

    • Data mapping: Map existing status codes, order types, equipment hierarchies, and time buckets in MES/ERP to the ISO 22400 structures and categories.
    • Configuration changes: Add or adjust reason codes, equipment states, shift calendars, or production event types in MES to align with ISO 22400 definitions.
    • Reporting/analytics layer: Implement ISO 22400 logic in a data warehouse, historian, or analytics layer that consumes MES/ERP data, rather than modifying MES/ERP transaction logic.
    • Lightweight extensions: Add edge data collection (e.g., machine connectivity) to fill gaps where MES/ERP lacks sufficient granularity for ISO 22400 KPIs.

    This approach fits regulated environments where full replacement of MES or ERP triggers extensive qualification, validation, and change-control burdens.

    When changes to MES/ERP are actually needed

    You may need to modify (but still not replace) MES or ERP if:

    • Key ISO 22400 base data is not captured at all (for example, no reliable machine state events or production quantity confirmations).
    • Existing status or reason codes are too coarse or overloaded to map cleanly to ISO 22400 categories.
    • Time or quantity stamping is inconsistent across lines, plants, or systems, making standardized KPIs untrustworthy.
    • There is no reliable way to link equipment, orders, and time (e.g., weak traceability between ERP orders and MES execution).

    In these cases, you typically:

    • Introduce new event types, fields, or reason codes in MES.
    • Standardize master data structures (equipment hierarchy, product families, calendars) in MES/ERP.
    • Improve integration so ERP order data and MES execution data can be joined consistently.

    All of this needs to go through formal change control, validation, and regression testing in regulated contexts.

    Why full replacement is rarely the right path

    Replacing MES or ERP solely to “support ISO 22400” is rarely justified in aerospace-grade or similar environments because:

    • Qualification and validation cost: New core systems require extensive validation, documentation, and often regulatory notifications or re-approvals.
    • Downtime and cutover risk: MES/ERP cutovers can disrupt production if anything goes wrong, which conflicts with tight delivery and compliance demands.
    • Integration complexity: Existing MES/ERP are usually integrated with PLCs, historians, QMS, PLM, and LIMS. Rebuilding those integrations only to compute standardized KPIs adds risk with limited benefit.
    • Equipment lifecycle: Many assets and controls are qualified for decades; changing the transactional backbone around them can re-open long-closed compliance questions.

    In practice, most organizations get ISO 22400 alignment by adding a standardized KPI data model and calculation layer on top of existing systems.

    Key dependencies and failure modes

    Whether you can stay on your current MES/ERP depends on:

    • Data quality: If timestamps, quantities, and states are unreliable, ISO 22400 calculations will be unreliable regardless of the software brand.
    • Plant-to-plant consistency: Different code sets and practices across sites can make ISO 22400 rollout difficult without harmonization.
    • Integration maturity: Poor integration between MES, ERP, and equipment will limit how far you can go without infrastructure work.
    • Change governance: Even small MES/ERP changes can be slow in regulated environments; planning and phasing are critical.

    Typical failure modes include treating ISO 22400 as a “tool purchase” instead of a data and governance project, or attempting a big-bang MES replacement that stalls under validation and integration load.

    Practical approach for brownfield environments

    A pragmatic path in most brownfield, regulated facilities is:

    1. Perform a gap analysis: compare current KPI calculations, data sources, and code sets to ISO 22400.
    2. Standardize master data and codes where possible without system replacement.
    3. Add or adjust MES/ERP configuration and integrations to capture missing events and links.
    4. Implement ISO 22400 KPI logic in a reporting/analytics layer, with traceability back to source records.
    5. Validate calculations, data flows, and reports under your existing CSV/validation framework.

    This preserves your existing MES and ERP investments while still moving toward a standardized KPI framework aligned to ISO 22400.

  • What is the difference between a performance indicator and a KPI in ISO 22400?

    In ISO 22400 terminology, a performance indicator and a key performance indicator (KPI) use the same basic building blocks (measured values, times, events), but they differ in how they are selected and used by the organization.

    ISO 22400 view: what they have in common

    Under ISO 22400, both performance indicators and KPIs:

    In practice, this connects to ISO 22400 KPI governance when teams need to turn the answer into repeatable execution habits.

    • Are quantitative measures derived from standardized manufacturing data (e.g., order times, machine states, quantities, scrap counts).
    • Follow defined calculation rules, including numerator, denominator, time base, and aggregation logic.
    • Can be computed by MES, historians, or analytics tools, and then surfaced in dashboards or reports.
    • Must be traceable and reproducible, which is critical in regulated environments and during audits or investigations.

    In other words, the standard does not say that KPIs use a different kind of data or math. The distinction is about relevance and governance, not about arithmetic.

    What is a performance indicator in ISO 22400?

    A performance indicator in ISO 22400 is any defined metric that characterizes some aspect of manufacturing performance. Examples include:

    • Machine utilization percentage for a cell.
    • Number of interruptions per shift.
    • Scrap rate by operation.
    • Average setup time for a machine group.

    Key points about performance indicators:

    • They can be local or narrow in scope (e.g., one resource, one product family, one area).
    • You can have many performance indicators; they are the full toolbox of potential measures.
    • In practice, they are often used by local teams (cell leads, planners, maintenance, quality engineers) to diagnose and optimize processes.
    • They may not be reported to top management or regulators, even if they are well defined.

    What is a KPI in ISO 22400?

    A key performance indicator (KPI) is a performance indicator that the organization explicitly designates as critical for monitoring and controlling its manufacturing operations against strategic, contractual, or regulatory objectives.

    In ISO 22400 terms, a KPI is a selected subset of performance indicators with additional expectations:

    • It is aligned with higher-level goals such as delivery performance, capacity utilization, cost, safety, or quality objectives.
    • It has an agreed target or threshold and typically clear escalation paths when out of tolerance.
    • It is used in formal review mechanisms (e.g., S&OP reviews, management reviews, customer or regulatory reporting) rather than only local troubleshooting.
    • It is more tightly controlled in terms of data integrity, calculation validation, and change control, because it influences decisions and external commitments.

    Operationally, you might compute dozens of indicators in your MES or analytics stack, but only a smaller, governed set is treated as KPIs with documented definitions and owners.

    Practical differences in regulated, brownfield environments

    In a typical aerospace or similarly regulated plant with mixed systems (legacy MES, multiple ERPs, QMS, historians), the difference usually shows up in governance and risk, not technology:

    • Scope and visibility: Many performance indicators never leave the area or department. KPIs are elevated, aggregated, and often cross-plant or cross-site.
    • Governance: KPIs usually have documented definitions, owners, and change control. Any change to a KPI’s formula, data source, or time base may require impact assessment, revalidation, and communication to stakeholders. Most local indicators will not be managed that tightly.
    • Validation expectations: Because KPIs are used in management reviews and sometimes in support of customer or regulatory conversations, their data pipelines and calculations are more likely to undergo formal verification and validation. This is especially true if MES/analytics outputs feed into QMS, audit evidence, or financial reporting.
    • System coexistence: The same underlying data (machine states, order events, quality records) may feed both indicators and KPIs across multiple tools. Full replacement of indicator logic into one platform is rarely realistic in brownfield contexts due to integration debt, qualification burden, and downtime risk. Plants typically layer KPI computation and visualization on top of existing systems rather than rewriting everything.

    How to treat the difference when designing your metrics

    When applying ISO 22400 in your own environment, a practical approach is:

    1. Define a broad indicator library: Based on ISO 22400, identify the performance indicators that your systems can realistically calculate from available, reliable data sources (MES, SCADA, ERP, QMS).
    2. Select a small KPI set: From that library, explicitly select the few that will function as KPIs for plant leadership. These should map clearly to business, customer, or regulatory needs.
    3. Document and control KPIs: For each KPI, maintain a controlled definition that includes:
      • Exact formula and units.
      • Data sources and system of record.
      • Time base and aggregation rules.
      • Owner, review cadence, and targets.
    4. Allow more flexibility for non-key indicators: Local teams can evolve performance indicators faster for improvement work, as long as they are not represented as governed KPIs or used for formal external commitments.

    This separation lets you leverage ISO 22400’s structure for consistency without over-burdening every local metric with full KPI-level validation and change control.

    Summary

    In ISO 22400, a performance indicator is any well-defined quantitative measure of manufacturing performance. A KPI is a performance indicator that has been explicitly selected as “key,” tied to higher-level objectives, and governed more tightly. The calculation logic can be identical; the difference is in criticality, governance, and how the measure is used in decision-making and oversight.