Connect981 – Content Dev

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

KPI definition, measurement logic, and financial impact modeling.

  • Why are equipment states so important for KPI definitions?

    Equipment states matter for KPI definitions because they are the foundation for how time and losses are classified. Most performance KPIs in manufacturing are ultimately time-based. If equipment states are unclear, inconsistent, or implemented differently across systems, then the KPIs built on top of them will be misleading and hard to trust.

    1. KPIs are only as good as time classification

    Metrics like OEE, availability, utilization, NPT, and capacity adherence depend on how each minute is labeled. Typical high-level buckets include:

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

    • Productive time (running in spec, making good product)
    • Planned loss (changeovers, PM, validated cleaning, scheduled idle)
    • Unplanned loss (breakdowns, waiting on material, IT issues, rework)
    • Non-manufacturing time (no order, decommissioned, engineering trials)

    The equipment state model is how these buckets are operationalized in MES, SCADA, historians, and line control. If state definitions are weak or inconsistent, the same reality can show up as very different KPIs.

    2. Consistent states prevent KPI gaming and misinterpretation

    Without clear state rules, teams can “improve” KPIs simply by relabeling time instead of improving execution. Examples:

    • Classifying a long microstop as “planned maintenance” instead of a breakdown to avoid hurting OEE.
    • Using “no demand” whenever there is a material or paperwork issue, hiding true supply or process problems.
    • Marking engineering troubleshooting as normal production time, inflating utilization while masking yield and quality risk.

    Clear, enforced state definitions make it harder to shift time into more convenient buckets and help ensure KPI movements reflect real operational change.

    3. State models provide traceability and auditability

    Regulated environments need evidence for how KPIs were constructed and what underlying data they use. A well-governed equipment state model provides:

    • Traceability from KPI back to time buckets and underlying events.
    • Clear definitions that can be reviewed with quality, operations, and compliance.
    • A stable frame of reference when systems, teams, or reporting tools change.

    If equipment states are informal, undocumented, or changed without control, then KPI histories become hard to defend in audits and management reviews.

    4. Cross-plant and cross-system comparability depends on states

    Many organizations try to compare OEE, downtime, or NPT across lines and sites. In brownfield environments, the reality is often:

    • Different control vendors with different state models and event streams.
    • Legacy MES instances that use different naming and logic for downtime states.
    • Manual logs in some areas and automated detection in others.

    Without a harmonized state model and mapping across these systems, comparing KPIs across plants can be misleading. A 75% OEE in one plant might be more stringent than an 85% OEE in another simply because they classify standby, microstops, or rework differently. Investing in a consistent, documented state model (with careful mapping from each local system) is often more realistic and sustainable than attempting a full system replacement.

    5. States separate planned from unplanned losses

    Operations leaders need to see where they can realistically gain capacity. That usually means:

    • Reducing unplanned losses (failures, supply issues, operator delays).
    • Optimizing planned losses (shorter changeovers, leaner cleaning and setups).

    If equipment states do not cleanly separate planned from unplanned time, it becomes hard to see whether improvements are coming from better reliability, better planning, or just shifting work to different windows. This is critical when justifying investments in maintenance, automation, or headcount.

    6. Quality and scrap KPIs often depend on state context

    Yield, right-first-time, and scrap rates depend on understanding under what conditions product was made. Equipment states can indicate:

    • Production under deviation, trial, or engineering mode.
    • Startup and shutdown windows where quality is known to be less stable.
    • Production during maintenance-induced transients or partial outages.

    If KPIs do not respect these states, you can either over-penalize the base process by including exceptional conditions, or understate risk by hiding the impact of these conditions. Clear state models help define which periods are included in “normal” quality KPIs and which are analyzed separately.

    7. Integration and validation depend on stable state definitions

    In regulated environments, KPIs are often built from multiple systems: MES, historians, CMMS, LIMS, QMS, and sometimes spreadsheets. To integrate data meaningfully, you need:

    • A stable vocabulary of equipment states that each system can map to.
    • Versioning and change control for state definitions and mappings.
    • Documented assumptions about how each state is treated in each KPI.

    Any time you change state logic or mapping, historical KPIs may become non-comparable. In validated environments, those changes may require impact assessment, revalidation of calculations, and updated documentation. Full replacement of MES or historian solely to “standardize KPIs” often fails because the cost and risk of revalidating all state and KPI logic across assets is underestimated. Harmonizing state definitions and mappings within existing systems is usually a more practical and defensible path.

    8. Clear states help prioritize improvements

    When states are consistent, downtime and loss analyses can reliably show:

    • Top loss categories by equipment, line, product, or shift.
    • Where to focus root cause analysis and CAPA work.
    • Which losses are structurally planned (policy decisions) versus operational (execution issues).

    If states are ambiguous or misused, Pareto charts and performance dashboards become noisy and can direct improvement teams to the wrong problems.

    9. Practical implications for KPI design

    When defining or revising KPIs, it is usually necessary to:

    • Start from the equipment state model, not from the desired dashboard.
    • Document which states are included or excluded from each KPI (for example, whether to include planned idle or engineering trials).
    • Align on definitions across sites, at least at a coarse-grained level, and map local states to these shared categories.
    • Establish change control for state definitions and ensure KPI documentation is updated when state logic changes.

    This approach does not guarantee perfect comparability, but it makes KPI interpretation transparent and reduces surprises in leadership reviews and audits.

    In summary, equipment states are important for KPI definitions because they are how reality is segmented into the time buckets that KPIs measure. Inconsistent or poorly governed states lead directly to unreliable KPIs, weak comparability, and fragile auditability, especially in complex brownfield and regulated environments.

  • How can we estimate the cost of a non-conformance?

    Estimating the cost of a non-conformance (NCR) is fundamentally a modeling exercise. There is no universally correct number, only a range that depends on your data, system integration, and process maturity. A usable approach is to define a standard cost model, connect it to your NCR workflow, and refine it as better data becomes available.

    Start by defining a cost model structure

    Most organizations break non-conformance cost into at least three buckets:

    In practice, this connects to non-conformance management when teams need to turn the answer into repeatable execution habits.

    • Direct costs: clearly attributable to the specific NCR.
    • Indirect / overhead costs: shared impacts that can be reasonably allocated.
    • Risk / consequential costs: infrequent, high-impact outcomes modeled with assumptions.

    The structure should be documented, version-controlled, and consistent with how your finance and quality teams define Cost of Poor Quality (COPQ).

    Direct cost components per NCR

    These are usually the most defensible and can often be tied to ERP/MES/QMS data:

    • Scrap material: unit material cost × quantity scrapped or downgraded. This should come from ERP or item master, not guesses.
    • Added labor (rework / repair): actual or standard labor hours × fully burdened labor rate. When actuals are not captured, use time-tracking from MES or standard times with a clear assumption.
    • Machine / cell time: rework or remake runtime × machine burden rate. This may require a plant-agreed hourly burden rate by area or asset category.
    • Disposition and MRB effort: engineering, quality, and MRB review time × burdened rates. At minimum, use standard times (e.g., 0.5–2 hours per MRB review) with documented assumptions.
    • External fees directly tied to the NCR: special inspection at a supplier, third-party lab tests, expedited freight for replacement parts, etc.

    If your systems are weakly integrated, you may initially apply standard cost values (e.g., a default MRB cost per NCR type) and then refine these as you improve data capture.

    Indirect and overhead-related cost components

    These are more approximate and should be handled transparently to avoid overstating benefits:

    • Schedule disruption: estimated hours or days of delay × a standard cost of delay. In aerospace and defense, this may be modeled as additional overtime, rescheduling overhead, or penalties when relevant.
    • Capacity loss: lost available hours on constrained assets due to rework and MRB queues. Often modeled at a cell/line level using average contribution margin per hour rather than detailed NCR-level calculations.
    • Quality administration overhead: QMS administration, internal audits triggered by chronic issues, and extra documentation. Common practice is to allocate a percentage overhead factor to all NCRs instead of trying to track at the record level.

    Because these allocations are subjective, they should be agreed with finance, documented, and periodically revisited.

    Risk and consequential costs

    In regulated environments, some impacts are rare but severe and cannot be cleanly assigned to each NCR. Examples include:

    • Customer escapes and field failures.
    • Regulatory or customer investigations.
    • Warranty claims, chargebacks, or liquidated damages.
    • Increased customer surveillance or source inspection.

    These are often handled as part of an annual COPQ model instead of per-NCR costing. A practical approach is:

    • Compute historic annual cost from such events (claims, service bulletins, concessions) with finance.
    • Allocate a portion of that to internal NCRs by category (e.g., special cause vs systemic, escape vs contained).
    • Keep this as a separate line so per-NCR reports can show both tangible cost and allocated risk cost.

    All risk allocation methods should be treated as estimates for management insight, not as audit-grade financials.

    Practical estimation workflow for an individual NCR

    A realistic plant-level workflow might look like:

    1. Classify the NCR: defect type, station, part family, containment action, and severity. This drives which cost fields and default assumptions apply.
    2. Capture the direct data you actually have: material quantity, scrap vs rework decision, added labor hours if tracked, MRB steps taken.
    3. Apply standard costs where direct data is missing: e.g., standard MRB review time per NCR, typical rework time per defect code, default machine rate for the area.
    4. Compute a conservative cost: use only well-supported direct costs in the base figure; track overhead/risk separately to avoid inflating savings claims.
    5. Tag the NCR for learning: note where assumptions were used and whether the data should improve (e.g., add time tracking at a critical station).

    This is inherently approximate. The value is in consistent, comparable costing across NCRs, not in perfect precision for any single record.

    System integration and brownfield realities

    In mixed ERP/MES/QMS environments, estimating NCR cost is often limited by data fragmentation:

    • ERP holds item, material, and sometimes labor standards, but not detailed rework effort.
    • MES or digital travelers may have timestamps, rework routing, and operator IDs, but not financial rates.
    • QMS / NCR system has defect, disposition, and MRB details, but limited cost fields.

    Replacing all of these systems purely to get better costing is usually not viable in aerospace-grade environments due to validation burden, integration risk, and downtime. It is more practical to:

    • Define a minimal data set for costing (scrap quantity, rework yes/no, hours if available, MRB involvement).
    • Map existing fields from ERP/MES/QMS into that model, even if partially.
    • Use a lightweight integration or reporting layer to join data for costing, starting with a subset of high-impact NCRs.
    • Improve fidelity iteratively as you automate more of the data capture.

    Where integration is weak, you may need periodic offline analyses (e.g., quarterly) for more accurate costing of chronic issues, using sample time studies and engineering logs.

    Governance, validation, and use of NCR cost estimates

    Because these estimates are often used to justify investments and process changes, governance matters:

    • Document assumptions: burden rates, standard times, overhead percentages, risk allocation methods.
    • Version control the model: keep a record of when standard costs, labor rates, or formulas change.
    • Align with finance: ensure your model is consistent with how the business measures COPQ and margin.
    • Validate at a sample level: periodically compare estimated vs actual cost for a handful of NCRs using detailed time and material review.
    • Clarify intended use: operational decision support and prioritization, not regulatory or financial reporting.

    In regulated environments, any automation of cost calculation inside MES/QMS should follow your normal change control, testing, and validation practices to maintain traceability and avoid unintended impact on qualified processes.

    How accurate do we really need to be?

    Trying to make every NCR cost exact to the dollar generally fails and adds non-value work. A practical target is:

    • High fidelity for major NCRs (e.g., customer escapes, high-cost assemblies, chronic defects).
    • Standardized estimates for routine, low-impact NCRs based on defect code and disposition.
    • Trend reliability over time rather than absolute precision for a single record.

    The priority is to get consistent, defendable numbers that help you rank issues, justify corrective actions, and track whether your non-conformance and CAPA program is actually reducing the real cost of poor quality.

  • time series data

    Time series data is a sequence of data points collected and stored in time order, where each value is associated with a specific timestamp. In industrial and manufacturing environments, it commonly refers to time-stamped measurements from equipment, sensors, control systems, and software applications.

    Unlike transactional data, which describes discrete business events (such as a purchase order or a work order release), time series data captures how a variable changes over time. Typical examples include machine temperatures sampled every second, line speed every minute, OEE components per shift, or the count of good and bad parts by time interval.

    Key characteristics

    • Time-stamped: Each record has an explicit time reference (date/time), often in a standardized time zone.
    • Ordered: Data is logically and usually physically ordered by time, enabling sequence and trend analysis.
    • Often high-volume: Industrial sensors or control systems may generate values every second or faster.
    • Typically numeric: Most time series values are numeric (e.g., pressure, counts, KPIs), though status codes or categorical states can also be recorded over time.
    • Granularity-dependent meaning: The interpretation depends on the sampling interval (per second, per cycle, per batch, per shift, etc.).

    How time series data is used in manufacturing

    In regulated and industrial operations, time series data commonly supports:

    • Operational performance metrics: Calculating KPIs such as OEE, availability, performance, and quality over defined time windows.
    • Compliance and traceability: Providing evidence of process conditions (temperatures, pressures, cycle times) during production of specific lots or serial numbers.
    • Condition and asset monitoring: Tracking vibration, current, temperatures, or error codes to assess equipment health.
    • Alarm and event analysis: Correlating alarms, mode changes, or recipe changes with process variables and product outcomes.
    • Capacity and utilization analysis: Using time-stamped machine states (run, idle, down, setup) to analyze downtime and throughput patterns.

    Systems that generate and store time series data

    Multiple layers of the industrial stack generate and manage time series data, including:

    • PLC/SCADA and distributed control systems, capturing real-time process signals.
    • Historians and time series databases, optimized for high-frequency time-stamped data.
    • MES and production tracking systems, recording states, counts, and KPI values by time.
    • Quality and test systems, logging measurement results and test outcomes over time.
    • IoT platforms or data lakes, aggregating time series data from multiple plants or assets.

    Time series data and KPI auditability

    For auditable KPIs, such as those aligned with ISO 22400, time series data provides the raw evidence for calculations. Each KPI value (for example, OEE for a shift) can be traced back to the underlying time-stamped events and measurements from which it was computed. This often requires:

    • Consistent timestamping and time zones across data sources.
    • Versioned and documented aggregation or transformation logic from raw time series to KPIs.
    • Retention and controlled access to historical time series used in past KPI calculations.

    What time series data is not

    • It is not limited to financial data, although finance and forecasting are common uses.
    • It is not the same as master data (such as part numbers or BOMs), which generally does not change at high frequency over time.
    • It is not just event logs; events may be part of a time series, but continuous or regularly sampled measurements are typical.

    Common confusion

    • Time series data vs. event logs: Event logs capture discrete occurrences (e.g., a batch start), each with a timestamp. Time series data often involves continuous or periodic measurements. In practice, both can be combined for analysis.
    • Time series database vs. historian: In manufacturing, a plant historian is a specialized form of time series database. The terms are sometimes used interchangeably, but historians are typically tuned for OT and process data.

  • Can I keep my existing KPI names and still comply with ISO 22400?

    In most cases, yes. ISO 22400 focuses on how manufacturing KPIs are defined, structured, and calculated, not on forcing every plant to adopt identical KPI labels. You can typically keep your existing KPI names if you can demonstrate a clear and controlled mapping to the ISO 22400 model.

    What ISO 22400 actually expects

    ISO 22400 defines concepts, KPI structures, and calculation methods (for example, for OEE, availability, and performance). It does not require you to rename every KPI in your MES, ERP, or BI tools. Instead, it expects:

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

    • Consistent KPI definitions and formulas for a given term.
    • Clear understanding of which signals and time bases are used.
    • Traceability from raw data to KPI output.
    • Ability to compare like-for-like KPIs across lines, plants, or partners that also reference ISO 22400.

    Keeping your current names: conditions and guardrails

    You can usually keep existing KPI names and still align with ISO 22400 if you:

    • Document a mapping from your KPIs to ISO 22400 KPIs (or justify why a KPI is out of scope).
    • Clarify semantics where your historical names differ from ISO 22400 usage (for example, your “OEE” might exclude some losses that ISO 22400 includes).
    • Align formulas and data sources to the ISO 22400 definitions, even if the on-screen label stays the same.
    • Control changes through your existing change control, validation, and IT/OT governance processes.

    If you cannot reconcile your formula, data filters, or time base with ISO 22400 without confusing users, keeping the old name may be more misleading than changing it.

    When keeping names causes problems

    Keeping legacy KPI names can create risk in some situations:

    • Different formulas, same label: If your local “OEE” does not match ISO 22400 OEE, calling it OEE in external reports can be misleading. In that case, you may need distinct labels such as “OEE (Plant A definition)” and “OEE (ISO 22400)” or clear qualifiers in documentation.
    • Multi-plant comparisons: If plants use the same name but different loss models, the data is not truly comparable. You either standardize the logic or explicitly treat them as separate KPIs.
    • Brownfield system constraints: Older MES/SCADA may not support nuanced naming or the data segmentation needed to cleanly implement ISO 22400 semantics. Workarounds (for example, calculated KPIs in a data warehouse) must be clearly documented.
    • Audit and customer expectations: If you claim ISO 22400 alignment, you need to show how your KPIs map to the standard. Inconsistent naming with no mapping or evidence will be hard to defend.

    Practical way to approach this in brownfield environments

    In mixed-vendor, multi-plant stacks, full renaming across MES, ERP, historians, and BI tools is often disruptive and high risk due to validation, re-training, and downtime constraints. A more realistic approach is:

    1. Inventory your KPIs by system, plant, and owner, including formula and data source.
    2. Map to ISO 22400 KPIs in a controlled reference (for example, a KPI catalog under document control).
    3. Tag ISO-aligned KPIs in your data warehouse or semantic layer, even if the front-end labels stay legacy.
    4. Gradually harmonize naming and formulas as you update systems, rather than attempting a one-time global rename.
    5. Train users so they understand which KPIs are ISO 22400 aligned and what caveats exist for legacy ones.

    This lets you achieve functional ISO 22400 alignment without the risk and cost of a wholesale KPI renaming program across validated or safety-critical systems.

    Evidence you should be prepared to show

    If you reference ISO 22400 in internal standards, customer discussions, or audits, you should be able to produce:

    • A KPI catalog that defines each KPI, its formula, time base, and data source.
    • A mapping of each catalog entry to the relevant ISO 22400 KPI or a clear “not applicable” rationale.
    • Change history and approvals for modifications to KPI logic, stored under your normal change control.
    • Validation or verification records for any re-implemented KPI logic in MES, data warehouses, or BI tools.

    With that in place, keeping legacy KPI names in user interfaces is usually compatible with ISO 22400 alignment, as long as the underlying definitions and mappings are controlled and transparent.

  • How do we separate rework cost from normal production labor in our ERP data?

    Yes, but only if you design for it. In most ERPs, rework cost does not separate itself automatically from normal production labor. You need a distinct way to collect rework transactions, and that method has to be used consistently on the shop floor.

    The practical options are usually:

    In practice, this connects to scrap and rework reduction when teams need to turn the answer into repeatable execution habits.

    • separate rework operation numbers within the routing
    • dedicated labor codes for rework versus standard production
    • a separate rework work order, traveler, or order type
    • nonconformance-driven transactions tied to NCR, MRB, or repair disposition records
    • reason codes that distinguish planned work, unplanned rework, troubleshooting, inspection repetition, and scrap handling

    If labor is booked only to the original production operation with no reason code or secondary identifier, the ERP record will usually blend normal labor and rework labor together. Once that happens, reporting can estimate rework cost, but it generally cannot reconstruct it accurately enough for operational or quality decisions.

    What usually works best

    The most reliable pattern is to create a controlled rework path that operators or supervisors can actually use during execution:

    • Trigger rework from a quality event, such as an NCR or defect record.
    • Route the item to a designated rework step, rework cell, or rework order.
    • Require labor, material, and outside service charges related to that activity to post against the rework identifier.
    • Maintain linkage back to the original work order, serial, lot, or batch so cost and traceability stay connected.

    This gives you cleaner reporting for cost of poor quality, but it adds transaction discipline. If the process is too cumbersome, people will bypass it and your data quality will degrade.

    What to separate

    If your goal is meaningful ERP reporting, separate more than labor hours where possible:

    • direct labor used to rework or repair
    • additional inspection and test labor caused by the defect
    • replacement material and consumables
    • machine time if your costing model uses it
    • outside processing or supplier rework charges
    • administrative quality effort if your organization chooses to track it

    Whether all of that belongs in ERP depends on your costing model and system design. Some plants track only direct manufacturing impact in ERP and use QMS or BI layers for broader COPQ analysis.

    Key dependencies and failure modes

    This depends heavily on system configuration, operator workflow, and master data quality. Common failure modes include:

    • rework and normal production sharing the same operation and labor code
    • operators booking time after the fact from memory
    • supervisors moving parts informally without transaction updates
    • quality systems and ERP not sharing a common defect or disposition identifier
    • no clear distinction between rework, repair, concession, and scrap paths
    • variance accounting masking execution problems until period close

    If any of those are true, your reported rework cost may be directionally useful but not decision-grade.

    Brownfield reality

    In a mixed ERP, MES, QMS, and paper traveler environment, the answer is usually not to replace everything. Full replacement often fails because of qualification burden, validation effort, downtime risk, integration complexity, and the fact that long-lived assets and established processes cannot be swapped out cleanly.

    A more realistic approach is to add a minimal rework capture model that coexists with current systems:

    • keep ERP as the financial system of record
    • use MES or digital travelers to enforce rework step booking where available
    • link QMS nonconformance records to ERP work orders or cost objects
    • add reason codes and governance before attempting broader system redesign

    That approach is less elegant than a greenfield model, but it is often more achievable in regulated operations.

    How to tell if your setup is good enough

    Your setup is usually good enough if you can answer these questions without manual spreadsheet reconstruction:

    • Which labor hours were spent on first-pass production versus rework?
    • Which defects or dispositions drove those hours?
    • What material and outside service cost was added because of rework?
    • Can you trace rework cost by part, order, serial, work center, supplier, or defect type?
    • Can you explain the postings during review without relying on tribal knowledge?

    If not, the issue is usually process design and transaction discipline before it is analytics.

    So the short answer is yes: separate rework cost by creating a distinct, auditable transaction path for rework and enforcing its use. If you do not capture rework distinctly at the point of execution, ERP reporting alone will not solve it later.

  • Can we add custom aerospace or MRO KPIs alongside ISO 22400 metrics?

    Yes, in most environments you can define aerospace- or MRO-specific KPIs alongside ISO 22400 metrics, but it is never “just add a field.” You need to design how those KPIs coexist with the standard model, how they are calculated, and how they are governed across systems.

    What “alongside ISO 22400” usually means

    In a regulated aerospace or MRO context, “alongside ISO 22400” typically means:

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

    • Keeping ISO 22400 metrics (e.g., OEE-related KPIs) as a stable, reference baseline.
    • Layering additional KPIs that are specific to aerospace or MRO, such as turnaround-time buckets, maintenance lineage adherence, concession rate, or AOG-related measures.
    • Ensuring the new KPIs do not alter the definition or calculation of the ISO 22400 indicators without explicit change control.

    Most MES, data historians, or analytics layers can support this, but they vary widely in how cleanly they handle custom KPIs and hierarchies.

    Typical aerospace and MRO custom KPIs

    Common examples that organizations add on top of ISO 22400 include:

    • MRO turnaround metrics: TAT by tail/serial, by check type, by customer, or by station; proportion of work completed on first scheduled slot.
    • Maintenance lineage and configuration KPIs: percentage of tasks with fully documented part lineage; defect recurrence on same tail/assembly; repairs without full trace to prior event or SB/AD.
    • Scrap, rework, and concession KPIs: MRO scrap and waste by assembly or ATA chapter; percentage of jobs requiring deviation/repair dispositions; cost of poor quality specific to rework in shop visit.
    • Fleet- and safety-focused metrics: repeat discrepancies on same tail within X cycles; findings per flight hour; ratio of unscheduled vs scheduled findings.
    • Contractual and AOG metrics: on-time release vs contract TAT; jobs driving AOG exposure; hours in AOG state by root cause category.

    These can coexist with ISO 22400 metrics if the data model and calculation rules are clearly separated and traceable.

    Key design constraints and tradeoffs

    When adding custom KPIs, the most important design questions are:

    • Scope vs standardization
      If every site or program defines its own MRO KPIs, cross-site comparison becomes impossible. If you over-standardize, you may lose program- or platform-specific insight. Most organizations end up with a small “global” set plus limited local extensions.
    • Data source alignment
      ISO 22400 metrics might be calculated primarily from MES or machine states, while aerospace/MRO KPIs often require combining MES, ERP, MRO software, and sometimes PLM or fleet systems. Poor data integration leads to inconsistent numbers and erosion of trust in the KPIs.
    • Impact on OEE/OLE and capacity metrics
      If you redefine availability, performance, or quality to bake in fleet or MRO concepts (e.g., AOG penalties) you may break comparability with ISO 22400 baselines. A safer approach is to keep ISO 22400 calculations intact and create related, but distinct, derived KPIs.
    • Overhead vs insight
      Every additional KPI adds work: data quality monitoring, explanations for auditors, change control, and retraining. A narrowed set of high-value KPIs is usually more sustainable than dozens of overlapping metrics.

    Brownfield and system coexistence considerations

    In brownfield aerospace and MRO environments, KPIs are rarely controlled by a single system. You typically have a mix of:

    • Legacy MES or homegrown execution tools.
    • Aviation MRO systems or customized ERP modules.
    • Separate quality / NCR / CAPA and maintenance lineage tools.
    • Fleet or airline systems with actual flight and utilization data.

    Because of that:

    • Full replacement is uncommon: Ripping out legacy MES or MRO systems just to “standardize metrics” is rarely feasible given validation cost, downtime risk, and the effort to requalify processes and integrations.
    • Analytics or data hub layer is typical: Many organizations implement KPIs in an analytics or data warehouse layer that sits over MES/ERP/MRO, rather than inside each operational system. ISO 22400 metrics and custom aerospace/MRO KPIs are then calculated from harmonized data models.
    • Multiple truths risk: If individual sites calculate KPIs locally in spreadsheets or custom reports while corporate analytics uses a central model, you can end up with conflicting values for “the same” indicator. Alignment on a single source of calculation logic is critical.

    Traceability, validation, and change control

    In regulated environments, adding or changing KPIs is not just a reporting decision. You should expect at least:

    • Documented definitions for every KPI: purpose, formula, time bases, data sources, and inclusion/exclusion rules.
    • Version control for KPI logic: when a formula changes, you need to be able to explain historical vs current calculations.
    • Validation and verification of calculations: spot checks against raw transaction and event data, especially for metrics that drive capacity, cost, or safety-related decisions.
    • Change control across systems: if you adjust a KPI definition in analytics, associated reports and operational dashboards must be updated in sync, with appropriate approvals.
    • Audit trail for KPI usage: who accessed which KPI reports, and how those metrics feed management review, NCR, or CAPA decisions.

    Practical implementation approach

    A pragmatic pattern for adding aerospace/MRO KPIs alongside ISO 22400 is:

    1. Lock down ISO 22400 definitions as your baseline set. Document them and map each one to concrete system fields and states.
    2. Identify a small set of aerospace/MRO essentials that you cannot get from ISO 22400 alone (e.g., TAT, maintenance lineage completeness, MRO scrap and waste, AOG exposure).
    3. Design a harmonized data model that can calculate both ISO 22400 metrics and the new KPIs from the same underlying event, routing, and quality data where possible.
    4. Prototype in a non-production analytics environment and reconcile results against existing site reports to catch integration and definition mismatches.
    5. Run change control: approve, document, and train users on the new KPI set; update procedures for performance reviews, problem solving, and management review.
    6. Iterate slowly: retire unused KPIs and refine definitions rather than continuously adding more metrics.

    Linking back to ISO 22400

    As long as you preserve the standard ISO 22400 metrics as a stable baseline, you can add aerospace/MRO KPIs on top, referencing them as derivatives or complements rather than replacements. This allows you to keep comparability across plants and vendors while still capturing aerospace-specific realities like turnaround, maintenance lineage, and MRO-specific scrap and waste.

  • Do I need new software to comply with ISO 22400?

    ISO 22400, as it exists today, does not mandate any specific software or technology. It defines standardized manufacturing KPIs (e.g., OEE-related measures) and how they should be calculated and interpreted. Whether you need new software depends on how well your current systems can support those definitions in a traceable, repeatable way.

    What ISO 22400 actually expects

    In practical terms, ISO 22400 expects that you can:

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

    • Use standardized KPI definitions and terminology (e.g., availability, performance, quality rate) consistently across the plant or network.
    • Calculate those KPIs using the formulas and data groupings defined by the standard.
    • Show where the underlying data comes from (machines, MES, ERP, manual logs) and how it is transformed.
    • Maintain stability and governance around KPI definitions over time so that reports are comparable and auditable.

    None of this inherently requires a specific vendor or a new platform. It does require that your data and processes are coherent and controlled.

    When existing systems are usually enough

    In many regulated, brownfield environments, you can align to ISO 22400 using your current stack, assuming:

    • MES / SCADA / historian already capture machine states, production counts, scrap, and downtime with timestamps.
    • ERP holds order, schedule, and shift information that can be joined to shop-floor data.
    • Reporting / BI tools (or MES reports) can implement ISO 22400 formulas and clearly document them.
    • Governance exists to control changes to KPI definitions, queries, and calculations under formal change control.

    If you can configure your existing MES or analytics tools to implement ISO 22400 KPI logic and preserve an audit trail, you do not need new software purely for ISO 22400 alignment.

    When gaps in current tools become a problem

    New software becomes relevant when current systems have structural gaps that you cannot close safely or cost-effectively, for example:

    • Incomplete or unreliable data: No consistent recording of downtime categories, scrap reasons, or machine state transitions; manual spreadsheets with poor controls.
    • No clear data lineage: KPIs built from opaque Excel logic or one-off scripts that no one can fully explain or validate.
    • Inflexible legacy MES/SCADA: KPI logic is effectively hard-coded, and modifying it risks breaking validated production or requires vendor customizations you cannot maintain.
    • Lack of traceability: You cannot show who changed KPI definitions, when, and why, which undermines trust and auditability.
    • Fragmentation across plants: Each site uses different definitions and tools, and existing systems cannot be harmonized without major rework.

    In these cases, adding a focused layer (for example, a standard KPI calculation and visualization layer on top of MES/ERP/historian) can be more realistic than trying to retrofit everything into each legacy system.

    Brownfield reality: replacement vs coexistence

    Completely replacing MES, ERP, or SCADA just to support ISO 22400 KPIs is rarely justified in aerospace-grade, regulated environments. Full replacements often fail or stall because of:

    • Qualification and validation burden: New core systems must be validated and requalified across equipment, products, and regulatory contexts.
    • Downtime risk: Cutover windows are constrained, and failures can impact deliveries or flight-critical programs.
    • Integration complexity: Existing interfaces to QMS, PLM, SPC, and test systems are costly to rebuild and revalidate.
    • Long asset lifecycles: OT equipment and legacy controllers may not integrate cleanly with new platforms without additional gateways.

    As a result, ISO 22400 is more often implemented through coexistence:

    • Keep core MES/ERP in place.
    • Add or configure a metrics layer (MES module, historian, or BI platform) to implement ISO 22400 KPI logic.
    • Standardize data mapping and definitions across sites, using documented calculation rules and change control.

    Key questions to decide if you need new software

    To determine whether you truly need additional tools, ask:

    • Can we implement ISO 22400 KPI formulas in our existing MES/BI, with clear documentation and validation?
    • Do we have reliable, time-aligned event and count data to feed those formulas without excessive manual entry?
    • Can we trace each KPI back to raw data sources and logic, and subject changes to change control?
    • Can we apply the same definitions across lines/plants without each site inventing its own logic?

    If the answer to most of these is yes, new software is likely optional. If the answer is no and the gaps cannot be closed by configuration, you may need either:

    • A dedicated performance metrics / OEE layer integrated to existing systems, or
    • Targeted upgrades to specific legacy components that cannot deliver required data or traceability.

    Constraints and tradeoffs

    Regardless of whether you use existing or new tools, ISO 22400 alignment depends on:

    • Data quality: Poorly classified downtime, inaccurate counts, and inconsistent scrap recording will undermine any KPI standard.
    • Process maturity: Operators and supervisors must actually follow the event coding and reporting processes the KPIs rely on.
    • Validation and governance: KPI logic and interfaces should be validated at a level consistent with your QMS and regulatory expectations, with documented ownership and change control.
    • Integration quality: KPI calculations that join MES, ERP, and historian data must handle clock drift, missing data, and order boundary issues explicitly.

    Software alone does not create ISO 22400 compliance. It is an enabler, but the substance is in how you define, calculate, and govern KPIs using the tools you have.

  • How does ISO 22400 define equipment availability and utilization?

    ISO 22400 treats equipment availability and utilization as distinct but related manufacturing KPIs. It does not prescribe specific targets, but provides standardized definitions and formulas so different plants and systems can calculate these metrics consistently.

    Equipment availability in ISO 22400

    In ISO 22400, availability is a time-based indicator that compares the time equipment is actually capable of producing to the time it is planned to be available.

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

    At a simplified level, for a given period:

    • Planned time: Time the equipment is scheduled to be available for production (excluding planned long shutdowns such as major holidays or extended overhauls, depending on your site convention).
    • Operating time: Time the equipment is in a state where it can produce (often called “available” or “up” in many MES/SCADA models). This typically includes running and short stops that do not put the equipment in a down state.

    A commonly used ISO 22400-style form is:

    Availability = Operating time / Planned time

    ISO 22400 distinguishes between different equipment states (e.g., planned shutdown, unplanned downtime, setup, minor stops). How each state is included or excluded from “operating” and “planned” must be configured in your system and aligned with your site’s interpretation of the standard.

    In many implementations, this aligns with the “availability” component of OEE, but ISO 22400 formalizes the underlying time categories and KPIs, rather than only the OEE composite.

    Equipment utilization in ISO 22400

    ISO 22400 defines utilization as a capacity-related indicator. It expresses how much of the equipment’s available capacity is actually used for productive operation during a period.

    There are two common patterns depending on the specific ISO 22400 KPI variant you implement:

    • Time-based utilization: Effective production time compared with some larger time base.
      Typical form: Utilization = Effective production time / Calendar time or / Planned time, depending on configuration.
    • Capacity-based utilization: Actual output compared to theoretical maximum capacity for the period.
      Typical form: Utilization = Actual output / Theoretical maximum output.

    ISO 22400 provides definitions for these KPIs and the underlying concepts (e.g., calendar time, operating time, net operating time, capacity), but it does not enforce one single utilization formula for all plants. Your organization must choose and document which ISO 22400 utilization KPI is being used, and how it maps to equipment states and order data.

    Key differences: availability vs utilization

    • What they measure:
      • Availability measures time readiness: How much of the planned time was the equipment able to run.
      • Utilization measures capacity usage: How much of the time or capacity base was actually used to produce.
    • Primary inputs:
      • Availability is driven by equipment states and downtime categorization.
      • Utilization also depends on production schedules, order loading, and rated capacity or theoretical maximum rates.
    • Typical interpretation:
      • Low availability usually indicates maintenance, reliability, or changeover issues.
      • Low utilization with good availability usually indicates scheduling, loading, mix, or demand issues.

    Dependencies and implementation caveats

    The standard definitions only become meaningful if they are implemented consistently across your systems and sites. In regulated and long-lifecycle environments, several realities affect how ISO 22400 availability and utilization behave in practice:

    • State modeling and integration: SCADA/PLC, MES, and CMMS often use different equipment state models. How a state like “setup” or “warmup” is mapped into ISO 22400 categories (operating vs planned shutdown vs unplanned downtime) is site-specific and must be explicitly configured and validated.
    • Brownfield coexistence: Many plants already have OEE logic embedded in legacy MES or custom reports. A strict ISO 22400 implementation often changes the numbers people are used to seeing. Running both side-by-side for a period, with clear mapping, is usually necessary to avoid confusion and claims that the data is “wrong”.
    • Capacity definitions: Utilization requires credible definitions of rated speed and theoretical maximum output. In high-mix, low-volume operations, or with manual and semi-automated stations, these values are often approximate. You may need product-family or routing-step level capacities rather than a single number per machine.
    • Regulatory constraints: Any change in KPI calculation logic that drives maintenance intervals, staffing, or qualification decisions may need documented change control, impact assessment, and potentially revalidation of associated reports and automated rules.
    • Time-base alignment: Calendar time, shift time, and planned production time are not the same. ISO 22400 allows different KPI variants; if you mix them (for example, comparing one line on calendar-based utilization and another on shift-based utilization) you can easily misinterpret relative performance.

    Relation to OEE and existing MES/ERP metrics

    ISO 22400 does not require you to replace OEE or your current KPIs. It provides a standardized KPI framework that can sit under or alongside existing OEE implementations.

    • OEE availability vs ISO 22400 availability: They are similar but not guaranteed to be identical. Many legacy OEE implementations treat some planned stops differently than ISO 22400. If you migrate to ISO 22400 definitions without careful mapping, historical comparisons will be distorted.
    • Use as a reference model: A practical approach in brownfield environments is to:
      • Map current MES/SCADA state codes and KPIs to ISO 22400 categories.
      • Document any deliberate deviations from the standard (e.g., including certain planned micro-stops in availability).
      • Gradually converge toward ISO 22400-compliant logic as systems are upgraded, rather than trying a big-bang replacement of all KPI logic.

    What this means in a regulated, long-lifecycle plant

    In aerospace, defense, and similar regulated environments, adopting ISO 22400 definitions for availability and utilization is less about installing a new KPI and more about establishing a traceable and auditable calculation method:

    • You need clear documentation of definitions, formulas, and state mappings used at each asset and line.
    • Changes to those definitions should go through change control, with impact analysis on any KPIs that feed maintenance planning, capacity commitments, or customer-facing performance reporting.
    • Full replacement of existing KPI engines in MES, historians, and reporting tools is rarely feasible in one step due to validation burden, integration complexity, and downtime risk. A phased coexistence model, with ISO 22400 as the reference, is usually safer.

    Used in this way, ISO 22400 provides a common language for availability and utilization across sites and vendors, while still allowing for local configuration where justified and documented.

  • Quality cost

    Quality cost refers to the total cost associated with achieving, assuring, and failing to meet specified quality requirements for products, processes, or services. In manufacturing and other regulated operations, it is a structured way of categorizing how resources are spent to prevent defects, inspect and verify quality, and deal with nonconformities when they occur.

    Main categories of quality cost

    Quality cost is commonly broken into four groups:

    • Prevention costs: Costs incurred to avoid defects and nonconformances. Examples include training, process engineering, mistake-proofing (poka-yoke), preventive maintenance, document control, and quality planning activities.
    • Appraisal costs: Costs related to evaluating and inspecting products and processes to verify they meet requirements. Examples include incoming inspection, in-process checks, final inspection, testing, calibration, audits, and verification activities in MES or QMS workflows.
    • Internal failure costs: Costs that arise when defects are found before the product is delivered to the customer. Examples include scrap, rework, re-inspection, downgrading, line stoppages, MRB reviews, and updating records or travelers after a nonconformance is found.
    • External failure costs: Costs that arise when defects are found after delivery to the customer. Examples include returns, warranty work, field repairs, rework at customer sites, complaint handling, investigations, potential penalties, and disruptions to supply or production schedules.

    Operational use in manufacturing and regulated environments

    In industrial operations, quality cost is often tracked as part of broader cost of poor quality (COPQ) and continuous improvement efforts. Data may be captured across systems such as MES, ERP, QMS, and maintenance systems, then analyzed to:

    • Understand how much of total cost is tied to failures versus prevention and appraisal.
    • Identify high-impact sources of scrap, rework, and nonconformances.
    • Support decisions on investments in process controls, training, or automation.
    • Align quality performance metrics with financial reporting and operational KPIs.

    In regulated industries, documenting and categorizing quality costs can also support internal reviews, management reporting, and evidence for audits, without implying any specific compliance outcome.

    Common confusion

    • Quality cost vs cost of poor quality (COPQ): Quality cost usually includes all four categories (prevention, appraisal, internal failure, and external failure). Cost of poor quality commonly focuses on failure costs only (internal and external), or on the portion of quality cost that is considered avoidable. Usage varies by organization.
    • Quality cost vs general production cost: Quality cost is a subset of total production and operating cost, specifically related to quality activities and outcomes. It does not include unrelated expenses such as general administration or sales and marketing.