Connect981 – Content Dev

RSC Cluster: ISO 22400 Manufacturing KPIs for Modern Plants

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

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

  • Trend Direction

    Trend direction commonly refers to the overall movement of a measured value or metric over time, such as whether it is generally increasing, decreasing, or remaining stable. In industrial and manufacturing environments it is used to interpret time-series data from production, quality, maintenance, and environmental monitoring systems.

    What trend direction includes

    In operational and manufacturing analytics, trend direction typically addresses:

    • Upward trend: a metric is generally increasing over a defined time window (for example, rising temperature, defect rate, or throughput).
    • Downward trend: a metric is generally decreasing (for example, falling yield, cycle time, or equipment health index).
    • Stable or flat trend: a metric fluctuates within a band without a significant long-term increase or decrease.

    The direction can be assessed visually (charts and control charts) or algorithmically (slope calculations, statistical trend tests, or SPC rules) in systems such as MES, historians, or quality management applications.

    Operational usage in manufacturing and regulated environments

    Trend direction is used to understand process behavior and performance over time, for example:

    • Process control: identifying whether a critical process parameter is drifting toward or away from its target or limits.
    • Quality monitoring: detecting increasing defect rates, rework, or nonconformances that may trigger investigation.
    • Equipment and maintenance: observing trends in vibration, temperature, or run time that may suggest wear or need for intervention.
    • Compliance and oversight: demonstrating that key parameters are not trending toward specification limits or that corrective actions have reversed an undesirable trend.

    Many operations-intelligence tools and dashboards explicitly label trend direction (for example, arrows indicating up, down, or neutral next to a KPI) to support quick interpretation.

    What trend direction does not imply

    • It does not by itself explain the root cause of a change in a metric.
    • It does not guarantee that a change is statistically significant unless supported by appropriate analysis.
    • It is not the same as volatility or variation; a metric can be highly variable yet have no clear trend direction.

    Common confusion

    • Trend direction vs. trend magnitude: Direction is about whether the metric is moving up, down, or sideways. Magnitude is how fast or how much it is changing.
    • Trend direction vs. one-off change: A single spike or drop does not establish a trend. Trend direction usually considers multiple points over a defined period.
    • Trend direction vs. control limits: Trend direction describes the movement; control limits describe acceptable bounds. A parameter can trend upward while still being within limits.

  • KPI Catalog

    A KPI catalog is a structured, centrally maintained list of key performance indicators (KPIs) used across an organization. It typically documents each KPI’s name, definition, calculation method, data sources, ownership, and usage rules so that performance is measured consistently across sites, systems, and teams.

    What a KPI catalog includes

    Although formats vary, a KPI catalog commonly contains for each KPI:

    • Standard name and description so teams refer to the same metric in the same way.
    • Category or domain, such as safety, quality, delivery, cost, maintenance, or compliance.
    • Formula and units, including numerator, denominator, time base, and any filters or exclusions.
    • Data sources, such as MES, ERP, LIMS, QMS, historian, or manual logs.
    • Measurement frequency, for example real-time, shift, daily, weekly, or monthly.
    • Process scope and applicability, such as which plants, product families, or lines the KPI covers.
    • Roles and ownership, including a business owner and technical owner for the metric.
    • Governance notes, such as approval date, version, and change history of the definition.

    Use in industrial and regulated environments

    In manufacturing and industrial operations, a KPI catalog is often used to align metrics between OT and IT systems, such as MES, ERP, and business intelligence tools. It helps ensure that:

    • Sites use the same definitions for metrics like OEE, scrap rate, on-time delivery, and deviation closure time.
    • Regulated processes have traceable, documented definitions for KPIs related to quality, safety, and compliance.
    • Dashboards, reports, and performance reviews draw from a consistent set of metrics.
    • New systems or integrations map their data to existing KPI definitions rather than inventing duplicates.

    Operational role

    Operationally, a KPI catalog may be managed as a controlled document, a database, or part of a performance management or analytics platform. Typical workflows include:

    • Proposing new KPIs and reviewing them for clarity, relevance, and data availability.
    • Approving and versioning KPI definitions when processes or data models change.
    • Providing a reference for engineers, analysts, and system integrators when building reports or configuring MES/ERP interfaces.
    • Supporting audits by showing how performance metrics are defined and maintained.

    Common confusion

    A KPI catalog is related to, but distinct from:

    • KPI dashboard: A dashboard visualizes metrics in charts and tables. The KPI catalog defines what those metrics mean and how to calculate them.
    • KPI library in a software tool: Some applications ship with a set of predefined metrics. A KPI catalog is typically an organization-wide reference that can include, extend, or override such built-in libraries.

  • Do I need to abandon my current OEE calculation to adopt ISO 22400?

    No. You do not need to abandon your current OEE calculation to adopt ISO 22400, but you do need to be explicit about what is and is not ISO 22400 aligned. In regulated and long-lifecycle environments, most plants run a coexistence and mapping approach rather than a hard cutover.

    How ISO 22400 and your current OEE can coexist

    ISO 22400 defines a standardized set of manufacturing KPIs (including OEE and related indicators) with specific terms, numerators, denominators, and time bases. Your legacy OEE implementation is almost certainly different in at least some of these details.

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

    Common coexistence patterns:

    • Dual reporting: Keep your current OEE for continuity and add an ISO 22400-compliant OEE view in parallel for selected lines, products, or customers.
    • Mapping and translation: Maintain your existing data structures, but document and implement a mapping layer (in MES, data warehouse, BI tool, or scripts) that outputs ISO 22400 KPIs from the same raw events.
    • Phased convergence: Start with dual definitions, then converge to ISO 22400 where the benefit (benchmarking, customer expectations, multi-site comparability) outweighs re-training, re-baselining, and validation costs.

    When you do need to change your OEE definition

    You do not have to “abandon” your current OEE, but you cannot call it ISO 22400-compliant if:

    • You classify time buckets differently than ISO 22400 (for example, treating planned changeovers as loss in one system and as non-productive but not loss in another).
    • You use non-standard or site-specific formulas (for example, embedding quality yield into availability, or counting rework as good output).
    • You mix shift, order, and calendar bases without clear rules that match ISO 22400’s KPI definitions.

    In those cases, you have two options:

    • Keep your legacy OEE as-is and label it clearly as “Plant OEE” or “Site OEE”, separate from any ISO 22400 metrics.
    • Refactor your calculation and data model so that at least one OEE metric matches ISO 22400 exactly, while keeping the old metric for historical comparison during a transition period.

    Key dependencies and risks in regulated environments

    Transitioning to ISO 22400 is not just a math change; it affects systems, records, and sometimes validated reports:

    • Data model and event taxonomy: Your MES, SCADA, or historian must capture the states and timestamps that ISO 22400 assumes. If downtime reasons, changeover codes, or quality states are incomplete or inconsistent across cells, you may not be able to implement ISO 22400 cleanly without rework.
    • Validation and change control: If OEE or related KPIs are used in validated reports or formal decisions (capacity, release criteria, maintenance triggers), changing definitions may require documented impact assessment, change control, regression checks, and potentially re-validation of calculations and reports.
    • Historical comparability: Once you change the definition, historical trend lines break. You either maintain both calculations for a defined overlap period or run a back-calculation project from raw data (if those raw events are complete, consistent, and retrievable).
    • System coexistence: Legacy MES/ERP/BI stacks often hard-code OEE logic. Replacing that wholesale can be high-risk due to qualification burden, downtime risk, and integration complexity. A separate analytics layer that computes ISO 22400 metrics from existing signals is usually lower risk than ripping out embedded OEE logic everywhere.

    A practical migration approach

    A pragmatic path in brownfield, regulated environments typically looks like this:

    1. Document your current OEE definition: Precisely define how you calculate availability, performance, and quality today, including time bases, exclusions, and data sources.
    2. Compare to ISO 22400: Identify exact differences: which time buckets differ, which loss categories are merged or split, and whether your good/bad classifications align.
    3. Run a dual-calculation pilot: On a small scope (one line or cell), compute both “legacy OEE” and “ISO 22400 OEE” from the same raw events. Quantify the delta and its drivers.
    4. Decide on your target set: Choose where strict ISO 22400 alignment is necessary (multi-site benchmarking, OEM/customer reporting, corporate dashboards) and where local definitions are acceptable for internal problem-solving.
    5. Implement a mapping layer: Prefer adding a calculation/mapping layer in a data warehouse or analytics tool over re-implementing every MES/ERP screen, especially when those systems are validated or have long upgrade cycles.
    6. Manage change and training: Communicate clearly which numbers are ISO 22400, which are legacy, and how they should be used. Lock this into procedures or playbooks so interpretations do not drift.

    How to communicate OEE metrics after adopting ISO 22400

    To avoid confusion and unrealistic expectations:

    • Label KPIs unambiguously: For example, use names like “OEE (ISO 22400)” vs “OEE (Plant Definition)” in dashboards and reports.
    • Keep lineage and traceability: Maintain controlled documentation describing the formulas, inputs, and changes over time. In audits or customer reviews, this is more valuable than claiming compliance without detail.
    • Avoid partial claims: If you only align some metrics to ISO 22400, say so. Do not imply “full ISO 22400 adoption” when only OEE was harmonized and other KPIs remain custom.

    In summary: you do not need to abandon your current OEE to adopt ISO 22400. You can run both in parallel, use mapping to bridge differences, and then selectively converge where it supports cross-site comparability and stakeholder expectations without creating unnecessary re-validation work or disrupting established performance management routines.

  • What are the main benefits of moving from ad-hoc KPIs to ISO 22400?

    Moving from ad-hoc KPIs to ISO 22400 mainly improves consistency, comparability, and governance of manufacturing performance metrics. The benefits are significant, but they depend on data quality, integration maturity, and how rigorously the model is implemented and maintained.

    1. Common language across plants, systems, and vendors

    Ad-hoc KPIs often mean each plant, department, or integrator defines metrics differently. ISO 22400 provides standardized definitions (for example, for OEE-related KPIs, availability, performance, quality) so that:

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

    • Operations, quality, engineering, and IT are talking about the same thing when they say “availability” or “performance loss”.
    • Different plants, lines, and products can be compared without re-translating local KPI definitions.
    • Vendors (MES, SCADA, historians, analytics tools) have clearer requirements for how to calculate and expose KPIs.

    This reduces time spent arguing over KPI definitions and re-building reports when organizations or systems change.

    2. Better comparability and benchmarking

    With ad-hoc KPIs, cross-plant comparisons are often not credible because each site has its own assumptions. ISO 22400 improves:

    • Internal benchmarking between shifts, cells, or plants, because definitions and calculation logic are aligned.
    • External benchmarking against industry references or partners using the same standard, subject to each side implementing the standard faithfully.
    • Change impact assessment, because you have consistent baselines before and after process, equipment, or software changes.

    This does not eliminate the need to normalize for product mix, routing complexity, or regulatory overhead, but it makes those adjustments more transparent.

    3. Clearer data requirements for MES/ERP and OT integration

    ISO 22400 explicitly links KPIs to underlying data elements and events. Moving away from ad-hoc metrics helps you:

    • Identify which machine states, production counts, quality results, and schedule data must be captured and time-aligned.
    • Specify more precise integration requirements for MES, ERP, PLM, QMS, and historian systems.
    • Expose data gaps early (for example, no reliable planned vs unplanned downtime codes, or ambiguous shift boundaries).

    In brownfield environments with mixed vendors, this structure helps prioritize realistic integrations instead of attempting full replacement of existing systems, which often fails due to validation cost, downtime risk, and requalification burdens.

    4. Stronger governance, traceability, and change control

    In regulated and long-lifecycle environments, uncontrolled KPI definition changes can undermine traceability and auditability. ISO 22400 helps by:

    • Providing a reference model so changes to KPI logic are documented as deviations from the standard.
    • Making it easier to version-control KPI definitions and link them to MES/ERP configuration changes.
    • Supporting clearer evidence trails when regulators, customers, or internal auditors ask how performance metrics are computed.

    The standard does not replace change control, validation, or documented procedures. It gives you a stable baseline so those controls are easier to apply.

    5. Reduced rework in analytics and reporting

    Ad-hoc KPIs lead to repeated one-off report builds and conflicting dashboards. By adopting ISO 22400:

    • Analytics teams can design reusable data models and calculations rather than bespoke logic for every site or stakeholder.
    • Unified semantic layers (in BI tools or data warehouses) are easier to maintain and test.
    • System migrations and upgrades are less disruptive because KPI definitions are decoupled from specific tools.

    These benefits only materialize if the ISO 22400 model is actually implemented at the data and calculation level, not just mentioned in documentation.

    6. More reliable performance-driven decision making

    When KPI logic is ad hoc or opaque, decisions about capacity, staffing, capital projects, and continuous improvement are harder to justify. ISO 22400 can improve decision quality by:

    • Making loss structures (availability, performance, quality) more visible and consistently categorized.
    • Allowing leadership to see whether improvements are real or artifacts of changed definitions.
    • Enabling more confident use of performance data in A3s, 8D/RCCA, and portfolio-level investment discussions.

    It does not guarantee better performance; it improves the reliability of the information you base actions on.

    7. Practical constraints and tradeoffs

    There are real limitations and costs in moving from ad-hoc KPIs to ISO 22400:

    • Data readiness: If basic signals (run/stop, scrap, rework, changeovers, planned stops) are unreliable, standardization alone will not fix KPI quality.
    • Legacy system limitations: Some older MES/SCADA or custom tools may not support ISO 22400-caliber event granularity without invasive changes.
    • Validation and change control: In regulated environments, changing KPI logic can trigger validation and documentation needs; this slows down the transition and must be planned.
    • Partial adoption: Many organizations implement a subset of ISO 22400 aligned to their constraints. This is workable, but you should be explicit about which definitions you use and where you deviate.
    • Training burden: Leadership and engineers must be trained on the standard; otherwise, people will keep interpreting KPIs through old ad-hoc definitions.

    In most aerospace-grade and similarly regulated environments, incremental adoption layered on existing MES/ERP stacks is more realistic than attempting a clean-sheet implementation or full system replacement.

    8. How this coexists with existing ad-hoc KPIs

    Moving to ISO 22400 does not require throwing away every current KPI overnight. A practical approach is:

    • Map current KPIs to the closest ISO 22400 equivalents.
    • Identify gaps where current metrics are not aligned or are missing critical loss categories.
    • Run both versions in parallel for a period, document differences, and communicate impacts to stakeholders.
    • Formally retire legacy definitions via controlled change once users trust the ISO 22400-based metrics.

    This coexistence strategy helps control risk, manage validation scope, and maintain credibility with skeptical operations and quality leaders.