Connect981 – Content Dev

RSC Topic: Operational Performance Metrics (OEE, NPT, COPQ)

KPI definition, measurement logic, and financial impact modeling.

  • 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.

  • How long does it realistically take to implement a manufacturing KPI framework?

    In most plants, a manufacturing KPI framework takes 3 to 12 months to become operational, trusted, and used in routine management. A limited pilot can often be launched in 6 to 12 weeks, but that is not the same as having a durable framework that supports decisions across shifts, lines, sites, and functions.

    The main constraint is usually not dashboard development. It is agreeing on metric definitions, proving data quality, mapping data across existing systems, and putting governance around changes so the numbers remain traceable over time.

    In practice, this connects to implementation and adoption playbooks when teams need to turn the answer into repeatable execution habits.

    What the timeline usually looks like

    • 6 to 12 weeks: initial assessment, KPI selection, definition workshops, source-system review, and a basic pilot for a narrow scope.
    • 2 to 4 months: first production use for one area or value stream, assuming the required ERP, MES, historian, quality, and manual data sources are accessible and reasonably clean.
    • 4 to 9 months: KPI framework becomes repeatable, with agreed definitions, owner assignments, review cadence, and exception handling.
    • 9 to 18 months: broader rollout across multiple plants, programs, or product families, especially where data models, local practices, and legacy systems differ.

    Those ranges vary materially by process maturity, integration quality, master data consistency, and how much of the current reporting process depends on spreadsheets or manual interpretation.

    What makes it slow

    In regulated and brownfield environments, the time is usually consumed by coexistence work:

    • ERP, MES, PLM, QMS, historian, and maintenance systems use different identifiers and timestamps.
    • Operators and supervisors may record similar events differently by shift or department.
    • Legacy equipment may not expose reliable machine-state data.
    • Existing reports often use unofficial logic that no one documented formally.
    • Any KPI tied to product disposition, quality status, or release decisions may require tighter validation and change control.

    This is why full replacement is often the wrong assumption. Replacing core systems just to get cleaner KPIs usually fails in long lifecycle, regulated operations because the qualification burden, downtime risk, integration complexity, and traceability impact are too high. In practice, most plants build the KPI framework around coexistence with current systems and improve data quality incrementally.

    What determines the timeline most

    • Scope: one line is faster than enterprise standardization.
    • Definition discipline: if teams do not agree on what counts as downtime, rework, schedule attainment, or first-pass yield, implementation will stall.
    • Data readiness: missing timestamps, inconsistent part or work-order keys, and weak genealogy slow everything down.
    • Integration method: direct point-to-point extracts may be quick initially but create maintenance debt later.
    • Governance: without formal ownership and change control, KPI disputes continue after go-live.
    • Validation needs: if metrics feed regulated reporting, batch review, deviation analysis, or quality escalation, more verification is needed.

    What is realistic to expect

    A realistic goal is not to have every KPI perfect at once. It is to establish a small set of trusted metrics, define calculation logic clearly, document source systems, identify known limitations, and create a controlled process for changes.

    If you want a framework that leaders actually rely on, expect at least:

    • a documented KPI dictionary,
    • source-to-metric mapping,
    • data quality checks,
    • named metric owners,
    • review cadence and escalation rules,
    • and a managed process for revising definitions.

    Without those controls, implementation can appear fast but usually turns into recurring argument about whose number is correct.

    Bottom line

    Realistically, plan for 3 to 12 months for a credible manufacturing KPI framework, with 6 to 12 weeks for a narrow pilot and 9 months or more for cross-site standardization. If your environment is heavily manual, highly customized, or fragmented across legacy systems, it can take longer.

  • 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.

  • Why do our OEE numbers differ between plants even with the same formula?

    Because using the same OEE formula does not mean the plants are measuring the same thing.

    In most multi-plant environments, the gap is caused by differences in definitions, data capture, and operating context rather than the arithmetic itself. Two sites can both calculate Availability × Performance × Quality and still produce materially different numbers if they classify time, downtime, scrap, startup loss, rework, or planned stops differently.

    In practice, this connects to operational visibility when teams need to turn the answer into repeatable execution habits.

    What usually causes the mismatch

    • Different time bases. One plant may calculate against scheduled production time, another against staffed time, and another may exclude meetings, preventive maintenance, changeovers, or engineering holds.

    • Different stop classifications. Microstops, waiting on material, first-piece inspection, tooling changes, quality holds, and operator breaks are often treated differently by site, line, or even shift.

    • Different ideal cycle assumptions. Performance depends heavily on the standard rate or ideal cycle time. If one plant uses engineered standards and another uses historical averages, the comparison is not equivalent.

    • Different quality counting rules. Some sites count only final scrap in Quality. Others include rework, yield loss at intermediate steps, or inspection rejects at different points in the routing.

    • Different automation levels. A highly instrumented line will capture short stops and speed loss that a manual line may never record consistently.

    • Different production models. High-mix, low-volume operations, batch processes, continuous processes, and heavily regulated inspection steps do not generate losses in the same pattern. OEE can still be useful, but direct cross-plant comparison may be misleading without context.

    • Different master data and routing discipline. Inaccurate work centers, obsolete cycle times, inconsistent part-family setup rules, and weak maintenance of routings will distort OEE even if plant teams believe the metric is standardized.

    • Different exclusion rules. Plants often remove special causes from reporting after the fact, such as customer holds, trial runs, validation batches, qualification work, or ERP scheduling gaps. Those choices change the number substantially.

    • Different system integration behavior. MES, SCADA, historians, machine gateways, ERP, and manual logs may not agree on order status, start and stop timestamps, scrap posting timing, or completed quantity. The formula only reflects the data it receives.

    Brownfield reality

    In mixed-vendor environments, cross-plant OEE differences are common. Plants often run different MES versions, different machine connectivity layers, different ERP posting patterns, and different local workarounds. That means the metric definition may look standardized in a slide deck while the source events are still inconsistent at the shop floor level.

    This is also why full replacement is often not the practical answer. Replacing every execution and reporting system to force metric consistency can fail due to validation cost, qualification burden, downtime risk, integration complexity, and the fact that long-lived equipment often cannot be modernized uniformly. In regulated operations, a controlled semantic alignment effort is usually more realistic than a wholesale platform reset.

    What to standardize if you want comparable OEE

    If the goal is true cross-plant comparison, standardize the operating definitions before debating the formula:

    • The production time model and what is included or excluded

    • A canonical event taxonomy for downtime, speed loss, startup loss, and quality loss

    • Rules for microstops, changeovers, preventive maintenance, inspection, and waiting states

    • The source of ideal cycle time or standard rate

    • How rework, scrap, and first-pass yield relate to Quality

    • How manual overrides are approved and traceable

    • Version control and change control for KPI definitions, routings, and master data

    • Data reconciliation rules across MES, ERP, historians, and machine data sources

    Without that governance, cross-site OEE becomes a local reporting convention, not a reliable enterprise KPI.

    What OEE can and cannot tell you

    OEE is useful for identifying loss within a given operating context. It is much less reliable as a raw leaderboard across plants with different product mix, labor models, inspection intensity, automation maturity, and data quality. A lower OEE does not automatically mean a plant is performing worse. It may mean that site records losses more honestly, runs more complex work, or includes regulated activities another plant excludes.

    So the short answer is yes, your numbers can differ even with the same formula, and that is normal when definitions, data readiness, and process discipline are not harmonized. If executive decisions depend on plant-to-plant comparison, standardize semantics, trace the data lineage, and validate the calculation logic by site before treating the output as comparable.

  • 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.

  • 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.