Connect981 – Content Dev

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

KPI definition, measurement logic, and financial impact modeling.

  • How should OEE, FPY, and on time delivery be formally specified to ensure comparability?

    To make OEE, FPY, and on time delivery comparable across products, lines, plants, and suppliers, you need formal, written metric specifications. These must define the exact formula, data sources, time base, and inclusion/exclusion rules, and be controlled under your normal change and validation processes.

    1. General principles for comparable metrics

    For each metric (OEE, FPY, on time delivery), the formal specification should at minimum define:

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

    • Purpose and scope: Where the metric applies (plant, value stream, product family) and what decisions it is intended to support.
    • Time base: Shift, day, week, month; calendar vs production time; how you handle holidays, shutdown, and rework periods.
    • Numerator and denominator: Exact definitions, including units (parts, orders, hours) and counting rules.
    • Inclusions and exclusions: What is counted and what is explicitly not (e.g., engineering trials, training runs, quarantine stock, rework lots).
    • Data sources and system of record: MES, ERP, QMS, LIMS, historians, manual logs; and which system is authoritative when data conflict.
    • Timestamp rules: Which timestamp is used (planned ship date, ATP date, first good piece time, etc.).
    • Responsibility and governance: Metric owner, change control process, and validation/verification expectations.
    • Known limitations: For example, “OEE excludes unplanned utilities outages” or “On time delivery excludes export holds outside plant control.”

    In regulated environments, treat any metric used for release decisions, regulatory submissions, or management reviews as part of your controlled quality/operations documentation. Changes to definitions should go through documented review, impact assessment, and, where applicable, system revalidation.

    2. Formally specifying OEE

    OEE is frequently inconsistent across sites because each plant interprets Availability, Performance, and Quality differently. To ensure comparability, you must standardize at the factor level.

    A typical top-level formula is:

    • OEE = Availability × Performance × Quality

    Your specification should define at least the following.

    2.1 Availability

    • Formula: Availability = (Planned Production Time − Planned Downtime − Unplanned Downtime) / (Planned Production Time − Planned Downtime).
    • Planned Production Time: Exactly what counts (e.g., scheduled staffed time for that asset or line).
    • Planned Downtime: Preventive maintenance, setup/changeover, cleaning, regulatory inspections; and whether they are excluded from the denominator.
    • Unplanned Downtime: Equipment failures, unplanned maintenance, material shortages, IT outages; and whether external causes (e.g., power failures) are included.
    • Minimum event duration: Threshold for logging an event (e.g., any stop > 1 minute) and how micro-stops are handled.
    • Data sources: Line control system, MES downtime module, manual operator logs, and the hierarchy for conflict resolution.

    2.2 Performance

    • Formula: Performance = (Total Processed Units × Ideal Cycle Time) / Net Operating Time.
    • Ideal Cycle Time: How it is defined (e.g., validated equipment capability at nominal settings) and how often it may be revised.
    • Total Processed Units: Whether this includes reworked units that pass back through the equipment, scrapped units, or test pieces.
    • Net Operating Time: Planned Production Time minus all downtime events counted as “lost time” in Availability.
    • Speed losses: How you treat intentional slow-running for quality reasons or process validation; whether those are considered performance loss or excluded by design.

    2.3 Quality (for OEE)

    • Formula: Quality (OEE context) = Good Units / Total Units Produced in that time window.
    • Good Units: Units that fully meet specification and are not sent to rework, hold, or concession.
    • Defective Units: Whether you count scrap only, scrap + rework, or include units accepted under deviation/concession.
    • Inspection timing: How you handle units that are produced within the time window but inspected later (e.g., batch testing, release by QMS).
    • Data source: MES nonconformance records, QMS, SPC systems, manual quality logs.

    Make clear that OEE can legitimately differ by product mix, batch size, regulatory hold times, and required in-process testing. Comparisons across unlike assets (e.g., high-speed packaging vs manual assembly) should be qualified and not treated as direct benchmarks unless the definitions and operating contexts are closely matched.

    3. Formally specifying FPY

    FPY becomes non-comparable when plants count different stages, use different units, or treat rework differently. A written FPY definition should fix these points.

    3.1 Baseline FPY definition

    • Common formula: FPY = (Units exiting process step without any rework or repair) / (Units entering that process step).
    • Scope: Step-level FPY, line-level FPY, plant-level FPY; and explicit mapping of which steps are included.
    • Unit definition: Piece, assembly, batch, lot, order; define the level for counting and keep it consistent.

    3.2 Treatment of rework and repair

    • Rework policy: FPY usually counts only units that pass the step the first time without rework. Specify that any unit requiring rework, repair, or deviation approval is counted as a fail for FPY.
    • Loops: How you handle units that pass the same station multiple times (e.g., solder touch-up, re-test). Typically, you count them once in denominator at first entry and treat any additional passes as evidence of FPY failure.
    • Concessions/deviations: Whether concession-accepted units are considered good for FPY (many sites still count these as FPY failures, even if shipped).

    3.3 Multi-step FPY / rolled throughput yield

    • Step list: Controlled list of process steps included in the rolled FPY calculation.
    • Aggregation method: Whether you will use direct counting across the full route or the product of step-level FPY values.
    • Exclusions: Engineering runs, validation lots, training batches, NPI prototypes, or certain outside-processing steps.
    • Data sources: MES route data, QMS nonconformance records, test systems, and the convention for mapping defects to the “responsible” step.

    Because FPY is often used in quality management reviews, its definition should be aligned with your nonconformance and CAPA processes. If steps are added, removed, or split in the routing, the FPY specification and any automated calculations must be updated and, where validated systems are involved, reverified.

    4. Formally specifying on time delivery

    On time delivery is often hardest to compare across sites and suppliers because there are many plausible date definitions. The specification must be very explicit about which dates count and what is in scope.

    4.1 Core definition elements

    • Basic formula: On time delivery (OTD) = (Number of orders delivered on or before the committed date) / (Total number of orders due in the period).
    • Object of measure: Order line, shipment, customer order, internal work order; be precise and keep it consistent.
    • Period: Defined by due date or ship date. For example: “Orders with committed ship dates within the calendar month.”

    4.2 Date definitions

    • Requested date: Date requested by the customer or internal demand signal.
    • Committed date: Date the supplier or plant has confirmed (often from ATP or planning/MRP systems).
    • Measurement date: Specify whether OTD is measured against requested date or committed date. For comparability, choose one standard (often committed date) and apply it consistently.
    • Actual date: Define whether this is the ship date from ERP, the receipt date at customer site, or quality-acceptance date at customer.
    • Shipping terms context: Recognize that INCO terms (FOB, DDP, etc.) change what “delivered” means. Your specification should clarify whether plant OTD is based on readiness to ship, handoff to carrier, or confirmed receipt.

    4.3 Scope, partials, and exclusions

    • Partial shipments: Whether a partial shipment counts as on time if at least X% of the quantity is shipped by the committed date, and how follow-on shipments are treated.
    • Rescheduled orders: Rules for when and how a committed date can be changed without being counted as late, and how late reschedules are reported to avoid gaming.
    • Customer-driven changes: How you treat orders where customers pull in, push out, or delay acceptance.
    • External holds: Export control holds, credit holds, customer-site access issues, or regulatory release delays not caused by manufacturing. Define whether these are excluded or reported separately.
    • Cancellations: How customer-initiated and supplier-initiated cancellations affect the numerator and denominator.

    In regulated contexts, you should also specify how batches that pass manufacturing but await quality release or regulatory testing affect OTD. Many organizations keep separate metrics for “manufacturing OTD” and “customer OTD” to avoid hiding systemic release delays inside a shop-floor metric.

    5. Ensuring cross-plant and supplier comparability

    To make these metrics truly comparable, you need more than formulas. You need standardized governance:

    • Global metric specification documents: Controlled documents describing OEE, FPY, and OTD definitions, including worked examples and edge cases.
    • Implementation guides per system: Mapping the metric definitions to specific MES, ERP, QMS, and data warehouse fields, including any transformations or filters.
    • Change control: Any change to definitions, data sources, or logic must go through formal review, alignment across plants, and (where systems are validated) documented verification/validation.
    • Auditability: Ability to trace published metric values back to raw events/transactions, with versioned logic and configuration.
    • Training and examples: Standard training materials, including examples of what is and is not counted as “on time,” “good unit,” “downtime,” etc.
    • Exception reporting: When a site cannot fully follow the global definition (e.g., due to legacy system limitations), require documented exceptions and clear flags in consolidated reports.

    Brownfield environments make strict standardization harder because different sites use different systems and data models. Where full harmonization is not immediately feasible, prioritize:

    • Defining a minimum common specification that all plants can meet, even if some track additional local variants.
    • Documenting site-specific deviations and adjusting cross-site comparisons accordingly.
    • Using data integration layers that normalize field names, units, and event types while preserving traceability back to source systems.

    6. Tradeoffs and failure modes to watch for

    When you formalize these metrics, expect tradeoffs:

    • Strict comparability vs local relevance: A global OEE definition may not reflect important local realities (e.g., long cleaning cycles for aseptic processes). Consider a core global metric plus local supplements, rather than allowing silent local redefinitions.
    • Data quality vs coverage: Some older lines or suppliers may lack the instrumentation or system integration needed to support detailed definitions. Decide whether to invest in data capture upgrades or accept that those operations will be excluded from certain comparisons.
    • Simplicity vs precision: Highly complex rules can be precise but hard to explain and maintain. Balance clarity with enough detail to avoid gaming.
    • Metric gaming: If incentive plans are tied to OEE, FPY, or OTD, ambiguous definitions invite manipulation (reclassifying downtime, shifting due dates, avoiding difficult orders). Clear written rules and periodic audits are essential.

    None of these definitions guarantee better performance, regulatory outcomes, or audit results. They simply make performance measurement more credible and comparable, which is a prerequisite for sound decisions in complex, regulated, multi-site environments.

  • What happens when we need to change a KPI definition?

    Changing a KPI definition in a regulated manufacturing environment is a controlled change, not a cosmetic update. It affects how performance is interpreted over time, how deviations are escalated, and potentially how past decisions are justified. You should expect a formal process that looks more like an engineering change than a dashboard edit.

    1. Start with impact assessment

    Before changing the definition, you typically perform an impact assessment to answer:

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

    • Where is this KPI used? Dashboards, management reviews, tier boards, daily standups, supplier scorecards, CAPA triggers, incentives, contracts.
    • What systems calculate or store it? MES, historian, data warehouse, BI tools, spreadsheets, ERP, QMS, OEE systems.
    • What decisions does it drive? Release vs hold, overtime decisions, capacity planning, maintenance intervals, improvement targets.
    • Who depends on it? Plant leadership, quality, finance, customer-facing teams, suppliers.

    This assessment determines whether the change is minor (e.g., label or formatting) or material (e.g., new numerator/denominator, new time base, inclusion/exclusion rules).

    2. Treat it as a controlled change

    For material changes, most plants handle KPI redefinitions under some form of change control:

    • Formal change request describing the current definition, the proposed new definition, rationale, and risk assessment.
    • Approval workflow including operations, quality, and often IT/data owners, especially if the KPI feeds audits or regulatory reporting.
    • Effective date so everyone knows exactly from when the new definition applies.
    • Communication plan to explain what is changing, why, and how to interpret trends across the change.

    This is particularly important when KPIs are linked to procedures, control plans, or customer agreements.

    3. Version the KPI and preserve history

    You rarely want to overwrite the old definition. Instead:

    • Give the KPI a version or revision (for example, OEE v1 vs OEE v2), or maintain a clear definition history in a master KPI catalog.
    • Record the exact definition for each version including formulas, data sources, filters, time buckets, and exceptions.
    • Tag historical data so it is obvious which definition produced which values.
    • Update meta-data in reporting tools so users can see which version they are looking at without guessing.

    In regulated environments, this definition history becomes part of your traceability and supports explanations in audits and customer reviews.

    4. Decide how to handle historical trends

    Changing a KPI definition breaks simple before/after comparisons. There are three common strategies, each with tradeoffs:

    • Keep history as-is
      Old periods use the old definition, new periods use the new one, with a clear break point. This is the simplest operationally but makes continuous trend lines less meaningful. You must educate stakeholders not to compare values across the change line without context.
    • Recalculate history under the new definition
      Where raw data is available, you recast historical KPI values with the new rules. This gives consistent trends but may be expensive or infeasible if source data is incomplete, or if reprocessing impacts validated reports. You also lose the ability to reconstruct what decision-makers actually saw at the time.
    • Dual view
      Keep the original time series as a record of “what we saw then” and add a second series recalculated under the new definition where feasible. This preserves both decision traceability and analytical consistency but requires more data engineering and clear visualization.

    Which approach is acceptable often depends on your regulatory context, your data model, and your tolerance for rework.

    5. Update all affected systems in a brownfield environment

    In mixed, brownfield stacks, KPIs are rarely calculated in just one place. When you change a definition you may need to:

    • Update logic in multiple systems such as MES calculations, historian transforms, OEE engines, ETL jobs, and BI semantic models.
    • Align master data and code lists so inclusion/exclusion rules (for example, which downtime reasons count as planned vs unplanned) are applied consistently.
    • Check interfaces between MES, ERP, QMS, and data warehouse to ensure the same metric name is not carrying different meanings in different places.
    • Validate reports and dashboards and re-baseline automated alerts, scorecards, and escalation thresholds.

    Full replacement of KPI logic in one new platform while leaving legacy reports untouched often leads to conflicting numbers. In long-lifecycle, regulated plants, this inconsistency can be more damaging than living briefly with a suboptimal old definition, so coordination and staged rollout matter.

    6. Validate and test before making it official

    Once technical changes are implemented, you typically perform validation or at least structured testing:

    • Reconcile sample periods between old and new logic to understand and document the expected delta.
    • Confirm data lineage from source systems through to final KPI, especially where the metric feeds quality or regulatory reports.
    • Update documentation such as SOPs, work instructions, and any references in quality manuals or management review templates.
    • Capture evidence of testing and approvals for audit readiness.

    The level of formality depends on how the KPI is used. A metric used only for internal lean huddles may see lighter controls than one that affects product release or contractual SLAs.

    7. Communicate and manage expectations

    Leadership and teams should be briefed that:

    • Trends and baselines will shift after the change; apparent improvements or degradations may simply reflect new definitions.
    • Targets may need reset because a new denominator or filter set often changes achievable ranges.
    • Comparisons between sites must be checked for alignment; one site on the new definition and another on the old creates misleading league tables.

    Without clear messaging, redefined KPIs can erode trust in data and trigger unnecessary firefighting.

    8. When not to change a KPI definition

    Sometimes the right answer is to keep the existing KPI definition and add a new metric instead. This is preferable when:

    • The KPI is referenced in contracts, regulatory filings, or long-standing customer scorecards.
    • You cannot reliably reconstruct historical data under the new definition.
    • The redefinition would undermine traceability of past decisions.

    In those cases, introduce a new KPI with a new name, document the relationship, and phase out use of the legacy metric over time.

    9. Summary

    When you change a KPI definition in a regulated, long-lifecycle manufacturing environment, you should expect:

    • Formal impact assessment and change control, not just a quick dashboard edit.
    • Versioning of the KPI and preservation of historical meaning.
    • Coordinated changes across MES/ERP/QMS/BI and other systems.
    • Validation, documentation, and clear communication of the break in comparability.

    This approach protects traceability, avoids conflicting numbers across systems, and maintains stakeholder trust in the metrics that drive operational decisions.

  • Legacy KPIs

    Legacy KPIs are key performance indicators that were defined for earlier processes, systems, or business objectives and remain in use even after the operating context has significantly changed. In industrial and regulated manufacturing environments, the term commonly refers to metrics that are still tracked and reported, but no longer align well with current products, technologies, workflows, or strategic goals.

    Legacy KPIs often originate from prior ERP, MES, or reporting setups, earlier quality programs, or past customer and regulatory requirements. They may continue to appear on dashboards, monthly reports, or management reviews because they are embedded in historical reports, contracts, or cultural habits, even when they provide limited decision-making value.

    How legacy KPIs show up in operations

    In manufacturing, legacy KPIs commonly appear in situations such as:

    • Metrics that were defined for a previous product mix or process technology, but are still reported after process changes or automation.
    • Measures that duplicate newer indicators (for example, tracking multiple overlapping yield or OEE variants) without clear ownership or use.
    • KPIs that reflect outdated customer, program, or regulatory expectations that have since been revised.
    • Plant- or department-specific metrics that remain in spreadsheets after formal KPI governance or MES/ERP reporting has been updated.

    Operationally, legacy KPIs can consume reporting effort, confuse operators and managers about what “good” looks like, and complicate integration between OT systems, MES, ERP, and quality systems. They may also create apparent conflicts with more modern KPIs, such as when an older utilization metric incentivizes behavior that contradicts current quality or compliance metrics.

    Common confusion

    • Legacy KPIs vs. historical data: Legacy KPIs refer to the metrics being tracked, not to the underlying historical data itself. Historical data for a well-defined, still-relevant KPI is not “legacy” just because it is old.
    • Legacy KPIs vs. baseline metrics: Baseline metrics are used to establish a reference point for improvement, even if they are no longer actively managed. Legacy KPIs are metrics that remain in regular reporting or systems without a clear, current purpose.
    • Legacy KPIs vs. lagging indicators: Lagging indicators measure outcomes after the fact; they can be current and relevant. A lagging indicator becomes a legacy KPI only when it no longer matches current processes or objectives but is still tracked.

    Relation to KPI governance and system modernization

    During initiatives such as MES upgrades, ERP integration, implementation of performance visibility tools, or adoption of standards-based KPI frameworks, organizations often review and rationalize legacy KPIs. This can involve:

    • Mapping existing metrics to standardized KPI definitions (for example, OEE components, NPT, or quality KPIs).
    • Identifying KPIs that are no longer used for decisions or compliance evidence.
    • Clarifying metric ownership, data sources, and definitions across IT and OT systems.

    In regulated environments, decisions to retire or modify legacy KPIs may be documented to maintain traceability, especially when those KPIs previously supported internal reviews, risk assessments, or quality management activities.

  • What is a manufacturing KPI framework and how is it different from a simple KPI list?

    A manufacturing KPI framework is the structured way a plant or network defines, governs, and uses performance metrics. It connects what you measure to why you measure it, where the data comes from, who owns it, and how decisions are made. A simple KPI list is just the “what” without the surrounding structure.

    What a manufacturing KPI framework includes

    In regulated, brownfield manufacturing, a practical KPI framework usually covers at least:

    • Business and operational objectives: Clear links from KPIs to strategic goals (throughput, quality, delivery, cost, safety, regulatory expectations).
    • Defined KPI catalog: A controlled set of metrics (for example OEE, NPT, COPQ, on-time delivery, yield, first-pass yield) with unambiguous definitions.
    • Standard calculation logic: Documented formulas, inclusions/exclusions, and time-bucket rules, validated against source systems so two plants compute the metric the same way.
    • Data sources and system boundaries: Explicit mapping of each KPI to MES, QMS, ERP, historian, PLM, manual logs, or other systems, including how data is integrated and reconciled.
    • Ownership and accountability: Named process owners for each KPI, with responsibility for data quality, interpretation, and driving actions.
    • Governance and change control: A process to add, retire, or change KPIs, with documented impact on procedures, dashboards, and any validated reports.
    • Review cadence and decision use: Defined routines (tiered meetings, daily huddles, weekly performance reviews) specifying how each KPI is reviewed and what decisions it should inform.
    • Traceability and auditability: Ability to trace reported KPI values back to source transactions, versions, and calculation rules, which is critical in regulated environments.

    In other words, a framework treats KPIs as part of a managed system, not isolated numbers.

    What a simple KPI list looks like

    A simple KPI list is typically:

    • Just the names of metrics and maybe a short description or target.
    • Light or vague on calculation details (for example, “OEE” without defining planned vs unplanned downtime, rework handling, or time base).
    • Silent on where data comes from (MES vs spreadsheet vs ERP) and how inconsistencies are resolved.
    • Missing explicit ownership, governance, or review routines.

    This can be sufficient for a single line or pilot area when one team controls the data and decisions. It usually does not scale across multiple plants, product lines, or regulatory regimes.

    Key differences in practice

    For experienced operations, the important differences between a framework and a list show up in day-to-day behavior:

    • Alignment vs noise: A framework prioritizes a small set of KPIs tied to strategic and regulatory drivers. A list often grows ad hoc, with conflicts and metric overload.
    • Consistency across sites: A framework enforces common definitions, especially for OEE, NPT, and COPQ, so benchmarking is meaningful. A list allows each site to interpret metrics differently.
    • Compatibility with legacy systems: A framework explicitly addresses where metrics live across MES, ERP, QMS, and manual systems, and how integration gaps are handled. A list usually ignores system coexistence.
    • Actionability: A framework ties each KPI to triggers and responses (for example, when NPT exceeds a threshold, launch a structured problem-solving or CAPA process). A list leaves teams to guess how to act.
    • Governance and validation: A framework can be placed under document control and change management, which is necessary where KPI outputs feed validated reports or regulated decisions. A list tends to change informally.

    Why the distinction matters in regulated, long-lifecycle environments

    In regulated or aerospace-grade contexts, the difference between a framework and a list becomes material because:

    • Metrics often span many systems: For example, COPQ may draw from QMS for defects, ERP for cost, MES for scrap events, and manual logs for rework. Without a framework, reconciliation and traceability are weak.
    • Validation and audit expectations: If KPIs inform release decisions, qualification status, or management reviews, auditors may ask how metrics are defined, governed, and traced to source data. A list cannot answer that reliably.
    • Long equipment and system lifecycles: Plants rarely replace MES/ERP/QMS wholesale, so a KPI framework must support coexistence with legacy systems. Trying to “fix” KPI problems purely by replacing systems usually underestimates integration, downtime, and requalification burdens.
    • Change control impacts: Changing a KPI definition after it has been used in regulatory submissions or business cases requires controlled change and clear communication. A framework provides that structure.

    How to move from a simple KPI list to a framework

    For an organization that currently has only a KPI list, a pragmatic path to a framework is to:

    1. Start with a small, critical set of KPIs such as OEE, NPT, yield, and a few quality and delivery metrics, instead of trying to formalize everything at once.
    2. Document precise definitions and formulas, including time base, inclusions/exclusions, and how rework, scrap, and waiting time are treated.
    3. Map each KPI to specific data sources and systems and identify known gaps (for example, manual capture for certain downtime codes, or missing integration between MES and ERP).
    4. Assign metric owners who are accountable for data quality and for explaining deviations in reviews.
    5. Embed KPIs into existing tiered meetings (daily, weekly, monthly) with clear expectations for what actions are taken when thresholds are breached.
    6. Put KPI definitions under basic document control so changes are reviewed, approved, and communicated, especially if metrics appear in validated dashboards or regulatory reports.

    None of this requires a full system replacement. It does require agreement across operations, quality, IT, and finance on how performance will be measured and used.

  • Is ISO 22400 recognized in aerospace standards or regulations?

    ISO 22400 is not a primary or widely mandated standard in aerospace regulations. It is an ISO standard family focused on manufacturing KPIs (including OEE) for automated systems, not an aviation-safety or airworthiness standard.

    How ISO 22400 is typically viewed in aerospace

    In practice:

    • Major aerospace regulatory frameworks (e.g. EASA, FAA regulations) and the AS/EN/JISQ 9100 series do not require or explicitly endorse ISO 22400.
    • Some aerospace and defense manufacturers use ISO 22400 internally to structure OEE and related metrics, but this is an operations choice, not a regulatory mandate.
    • Prime contractors and Tier 1s may recognize it as a reference for metric definitions, but customer contracts more often specify their own KPI definitions or data formats.

    Where ISO 22400 is used, it is usually positioned as:

    • A reference model for KPI terminology and calculation rules.
    • A way to support consistency across plants and vendors when discussing OEE, availability, and performance metrics.
    • A supporting standard in IT/OT integration and MES projects, not in type certification, airworthiness, or safety cases.

    Relationship to AS9100 and aerospace expectations

    AS9100 and related standards require you to define, monitor, and improve processes using appropriate performance indicators, but they do not prescribe ISO 22400 or any specific OEE formula.

    If you adopt ISO 22400 in an aerospace environment, you typically need to:

    • Document the KPI definitions (e.g. how you calculate availability, performance, and quality rates) within your QMS or operations procedures.
    • Show traceability from those metrics to risk, quality, and delivery requirements, including how they support AS9100 clause requirements for performance monitoring and improvement.
    • Align with customer and program requirements when they specify different KPI definitions or reporting structures.

    Use in brownfield, regulated plants

    In existing aerospace plants with mixed MES/ERP/QMS stacks and long-qualified equipment, ISO 22400 usually appears as a guideline for harmonizing metrics, not as a driver for system replacement.

    Typical patterns:

    • Coexistence with legacy metrics: Plants often keep historical KPI definitions for trending and contractual reasons, and map them to ISO 22400-based metrics where practical.
    • Incremental adoption: Instead of a full overhaul, sites may standardize a subset of metrics (for example, how OEE is calculated) while leaving other legacy measures intact.
    • Interface constraints: Existing MES/SCADA systems may not natively support ISO 22400 data structures. Any alignment usually depends on integration quality, data readiness, and available engineering capacity.

    Trying to fully replace established KPI schemes or MES components solely to “be ISO 22400 compliant” often fails in aerospace-grade contexts because of:

    • Qualification and validation burden on validated software and equipment.
    • Downtime risk when touching core production or test systems.
    • Integration complexity across multiple OEMs and internal systems.
    • Change-control and traceability obligations that make sweeping metric changes hard to justify.

    Regulatory and audit implications

    Using ISO 22400:

    • Does not provide any certification or compliance guarantee with aerospace regulations or the 9100-series.
    • Will typically be viewed by auditors as one acceptable framework for defining and using operational metrics, if it is well documented, consistently applied, and aligned with risk and quality objectives.
    • Requires the same change control, validation (where applicable), and data-governance rigor that applies to any change in metric definitions or reporting workflows.

    In summary, ISO 22400 is recognized as a useful technical reference for manufacturing KPIs, but it is not a core aerospace regulatory standard. It can improve internal consistency if carefully mapped to existing QMS, contractual, and system constraints, but it should not be treated as a shortcut to regulatory compliance or audit outcomes.

  • Quality loss

    Quality loss commonly refers to the reduction in usable output or value that occurs when products, components, or processes do not meet specified quality requirements. It captures the impact of defects, rework, scrap, and performance variation on both production results and customer-facing quality.

    What quality loss includes

    In industrial and regulated manufacturing environments, quality loss typically covers:

    • Defective units that cannot be used or shipped as-is (scrap or full rejection)
    • Rework and repair effort required to bring nonconforming items back into specification
    • Yield loss where only a portion of produced units meet acceptance criteria
    • Off-spec performance such as reduced life, accuracy, or reliability even when within broad tolerance
    • Inspection and sorting effort caused by unstable or low-capability processes

    These losses can be tracked in quality systems (QMS), MES, or ERP, and are often translated into cost terms as part of Cost of Poor Quality (COPQ) or yield reporting.

    Quality loss in operational metrics and OEE

    In performance metrics such as Overall Equipment Effectiveness (OEE), quality loss usually corresponds to the share of produced parts that are not good at first pass. It is often expressed as:

    • Quality rate: good pieces divided by total pieces produced
    • Quality loss: the complement of the quality rate, representing scrap and rework pieces

    Standards such as ISO 22400 define how quality loss contributes to OEE variants (for example, through a quality factor or a specific loss category). Plants may configure MES/SCADA to capture quality loss by shift, product, or equipment for continuous improvement and regulatory reporting.

    What quality loss does not include

    Quality loss usually does not include:

    • Availability losses such as unplanned downtime or changeover time
    • Speed or performance losses such as micro-stops or running below target rate
    • Pure schedule or demand effects, like planned idle time

    Those issues may interact with quality performance, but they are typically categorized separately in OEE and other KPI frameworks.

    Common confusion

    • Quality loss vs. COPQ: COPQ (Cost of Poor Quality) expresses the monetary impact of quality problems, while quality loss is the underlying physical or performance shortfall (e.g., defective units, rework hours) that COPQ quantifies.
    • Quality loss vs. scrap rate: Scrap rate covers only units discarded. Quality loss usually covers both scrap and rework, and can also reflect degraded performance within tolerance.
    • Quality loss vs. yield: Yield is a positive measure (percentage of acceptable output), whereas quality loss represents the fraction that fails to meet requirements or needs recovery.

    Link to regulated manufacturing

    In regulated industries, quality loss is often tightly linked to formal nonconformance records, MRB decisions, and CAPA activities. Systems may record each instance of quality loss with traceable data such as lot, serial, routing step, and test results to support investigations, audits, and continuous improvement.