Connect981 – Content Dev

RSC Topic: ISO 22400 KPIs

  • How should we label KPIs that are not part of ISO 22400?

    KPIs that are not part of ISO 22400 are fine to use, but they should be clearly distinguished from the ISO-defined indicators so people do not confuse local metrics with standardized ones.

    Use a clear naming convention

    In most plants, the simplest approach is to treat ISO 22400 KPIs as a “core” set and layer everything else on top:

    • Label standard KPIs explicitly, for example: “OEE (ISO 22400-2)” or “Availability (ISO 22400-2)”.
    • Label non-standard KPIs as custom or site-specific, for example: “Custom KPI – Setup Adherence” or “Site KPI – Rework Hours per Shipset”.
    • Avoid implying ISO backing for anything not actually defined in ISO 22400. Do not call it “OEE” or reuse ISO KPI IDs unless the calculation matches the standard.

    Differentiate by KPI family or domain

    For clarity in dashboards and data models, group labels by type rather than trying to force everything into the ISO 22400 structure:

    • ISO 22400 KPIs: Keep the names and calculation logic aligned with the standard wherever you claim ISO conformity.
    • Operational extensions: Metrics that are plant-specific but still process/production focused (for example: “Fixture Changeovers per Day”, “NCR Cycle Time”). Label them as “Operational KPI – <name>”.
    • Financial/COGS metrics: For example, COPQ, overtime cost, expedited freight cost. Label as “Financial KPI – <name>” and do not present them as ISO 22400 indicators.
    • IT/availability metrics: For example, “MES Uptime”, “Interface Error Rate”. Label as “IT/Systems KPI – <name>”.

    This makes it easier for quality, operations, and IT leadership to see what is standardized versus what is local or cross-functional.

    Document definitions and data sources

    In regulated and audit-prone environments, labeling alone is not enough. For any KPI outside ISO 22400:

    • Maintain a KPI catalog with a unique ID, name, owner, calculation formula, data sources, and refresh frequency.
    • Log differences from ISO 22400 where names overlap. For example, if you use a local definition of OEE, explicitly note that it is not the ISO 22400 calculation.
    • Track system of record (MES, ERP, historian, QMS) so that disagreements about numbers can be traced back to a specific system and transformation logic.

    This catalog should be under change control, especially if KPIs are used in management reviews, incentive schemes, or customer reporting.

    Handle brownfield system coexistence

    Because most plants already have KPIs baked into legacy MES/ERP/BI reports, you will often need to relabel existing metrics rather than redesign them:

    • Map, do not overwrite: Keep legacy KPI names visible for a transition period, but add a label such as “Legacy KPI – <name> (not ISO 22400)” in your catalog and dashboards.
    • Use calculated views in your BI layer to expose ISO 22400-aligned indicators alongside existing ones, each clearly labeled.
    • Avoid disruptive renames in source systems (MES/ERP) that would require revalidation or extensive regression testing; adjust labeling and definitions in the reporting layer instead.

    Full replacement of existing KPI logic in core systems is often high risk in regulated environments due to validation burden, traceability expectations, and the need to preserve long-term trending. It is usually safer to introduce ISO 22400 as an overlay and converge over time.

    Practical labeling pattern

    A pragmatic pattern that works across mixed-system environments is:

    • Prefix or suffix all ISO KPIs with an “ISO 22400” tag in the name or description.
    • Tag all others as custom/site-specific in both the data model and the dashboard (for example, description field: “Type: Custom KPI, not defined in ISO 22400”).
    • Use KPI IDs (for example, “KPI-ISO-001”, “KPI-CUST-017”) so users can reference them consistently across MES, ERP, and BI tools.

    This keeps the distinction auditable and reduces confusion when people compare metrics between plants, systems, or customer reports.

    Governance and change control

    Whatever label scheme you choose, treat it as part of your KPI governance model:

    • Approve new custom KPIs through a cross-functional review (operations, quality, IT/data) before production use.
    • Place KPI definition changes under formal change control if they affect regulatory submissions, customer SLAs, or management incentives.
    • Version KPI definitions so you can explain historical shifts in trend lines when formulas or source data change.

    This approach keeps flexibility for site-specific needs while maintaining clarity about which KPIs are ISO 22400-based and which are not.

  • How many KPIs are formally defined in ISO 22400-2?

    ISO 22400-2 formally defines 34 standardized manufacturing KPIs. These are grouped across areas such as equipment utilization, time management, quantity, and quality, and are intended as a common reference set for manufacturing operations.

    What this means in real plants

    Although 34 KPIs are defined, most regulated, brownfield environments do not implement all 34 as-is. Instead, they typically:

    • Select a subset that aligns with existing OEE/NPT dashboards, MES/SCADA data structures, and reporting requirements.
    • Map ISO 22400-2 definitions onto existing MES/ERP tags, data models, and time-state categorizations.
    • Adapt calculation rules where legacy data models or event taxonomies do not match the standard exactly.

    Applying the standard in a regulated environment also requires attention to:

    • Traceability: Documenting how each KPI is sourced and calculated, especially when used in quality or management reviews.
    • Validation and change control: Treating KPI logic changes like any other software or configuration change, with appropriate testing, approvals, and versioning.
    • System coexistence: Avoiding “rip and replace” of existing KPI frameworks where they are already embedded in QMS, procedures, or customer reporting. In many plants, it is more realistic to cross-reference existing metrics to ISO 22400-2 than to fully replace them, given the validation burden and downtime risk.

    In summary, ISO 22400-2 specifies 34 KPIs, but the operational value comes from carefully integrating a practical subset into your current MES/ERP and reporting stack, with clear mappings, governance, and documented assumptions.

  • How should ISO 22400 KPIs be labeled on aerospace dashboards?

    They should be labeled conservatively and precisely, not loosely.

    If a dashboard metric actually conforms to the ISO 22400 definition, calculation method, time basis, and underlying data assumptions, label it with the ISO 22400 KPI name and make the plant-specific scope visible. If it does not match, do not label it as the ISO KPI. Use a local name such as an internal KPI name or a qualified label like “OEE-like” or “local throughput metric” only if your governance allows that wording.

    Practical labeling rule

    Use the ISO 22400 label only when all of the following are true:

    • The metric definition matches the standard, not just the general intent.

    • The formula and numerator and denominator logic are controlled and documented.

    • The time model is explicit, including planned time, scheduled time, downtime categories, and shift boundaries.

    • The asset, line, cell, or work-center scope is stated on the dashboard.

    • The data sources and transformations are traceable across MES, ERP, historian, SCADA, QMS, or manual inputs.

    • The version of the calculation logic is under change control.

    If any of those conditions are missing, the safer choice is to keep the metric visible but label it as an internal KPI, not an ISO 22400 KPI.

    What good dashboard labels look like

    For aerospace dashboards, the label should usually include more than the KPI name:

    • KPI name

    • Scope or object measured, such as line, asset class, area, program, or site

    • Time basis, such as shift, day, week, or rolling 30 days

    • Calculation version or definition reference when the audience is cross-site

    • Any material exclusion or local rule that affects comparability

    Example pattern: “Overall Equipment Effectiveness, Cell A, Shift Basis, Definition v3.2”.

    That is less elegant than a simple label, but it is usually more honest and more useful in regulated, mixed-system environments.

    What to avoid

    • Do not use ISO 22400 names as a branding shortcut for metrics that are only roughly similar.

    • Do not present cross-plant comparisons as standardized if each site maps downtime, scrap, rework, or schedule loss differently.

    • Do not hide exclusions, manual overrides, or late ERP postings that materially affect the KPI.

    • Do not assume a BI layer alone can standardize semantics if source systems disagree on status codes, production states, or master data.

    Why this is harder in aerospace

    Aerospace operations often combine long cycle times, high-mix production, manual steps, rework loops, outside processing, and strict traceability requirements. That means two dashboards can show the same KPI name while measuring different operational realities.

    For example, a metric may look standardized but still vary because one plant counts MRB hold time as downtime, another excludes first article runs, and a third relies on ERP completions posted after shift close. In that case, the label alone is misleading unless the definition and scope are governed.

    This is also why full replacement strategies often fail as a shortcut to KPI standardization. Replacing MES, ERP, PLM, QMS, and edge data collection across qualified environments usually brings high validation cost, downtime risk, integration complexity, and change-control burden. Most organizations have to standardize KPI semantics across existing systems first, then improve labels and comparability over time.

    Best practice for brownfield environments

    In a mixed-vendor stack, treat KPI labels as governed master data, not dashboard cosmetics.

    • Create a canonical KPI catalog with approved names, definitions, formulas, units, exclusions, and ownership.

    • Map each dashboard metric to that catalog.

    • Flag whether the metric is fully conformant, locally adapted, or not comparable across sites.

    • Review label changes under normal change control, especially if dashboards are used in performance reviews, investigations, or management reporting.

    The short answer is this: label ISO 22400 KPIs with the standard name only when your metric truly matches the standard and the mapping is governed. Otherwise, use a local label and say exactly what it measures.

  • How do we handle KPIs that have no direct ISO 22400 equivalent?

    It is normal to have KPIs that do not map cleanly to ISO 22400. You do not need to discard them, but you should treat them as controlled, plant-specific extensions and make the gaps and translations explicit.

    1. Keep the KPI, but make its status explicit

    Separate your KPI catalog into at least two groups:

    • ISO 22400-aligned KPIs: KPIs that directly match an ISO 22400 KPI or can be expressed as a clear variant.
    • Non-standard (local) KPIs: KPIs with no direct ISO 22400 equivalent.

    For each non-standard KPI, document that it is not ISO 22400-defined. This avoids people assuming comparability or compliance that is not actually present, especially in audits or cross-site reviews.

    2. Decompose the KPI into ISO 22400 building blocks where possible

    Even if your KPI is unique, its components often align with ISO 22400 elements. For each KPI:

    • Identify which base measures or concepts come from ISO 22400 (time categories, quantity types, states, etc.).
    • Express your KPI, if possible, as a function of those ISO elements, for example:
      Local KPI X = f(ISO 22400 utilization time, ISO 22400 scrapped quantity, cost per unit time).
    • Note any intentional deviations (e.g., a different way of classifying downtime or losses).

    This decomposition supports traceability, cross-plant comparison, and future integration with MES/BI tools that are built around ISO 22400 structures.

    3. Define and control the KPI like a spec

    For any KPI without a direct ISO 22400 equivalent, manage it with similar rigor to a specification:

    • Purpose: Why the KPI exists, what decision it supports.
    • Exact formula: Numerator, denominator, units, aggregation period, and rounding rules.
    • Inclusions/exclusions: What time, quantities, or events are counted vs excluded.
    • Data sources: Systems of record (MES, ERP, historian, QMS, manual logs) and any transformations.
    • Ownership: Who can change the definition, and how changes are approved and communicated.

    In regulated environments, tie KPI definitions and changes to existing change control and validation processes. If KPIs feed into release decisions, quality metrics, or management reporting reviewed in audits, changes must be traceable.

    4. Flag non-standard KPIs in tools and reports

    In brownfield system landscapes, KPIs are often rendered through multiple tools (MES dashboards, data warehouse, BI, spreadsheets). To prevent misuse:

    • Label KPIs as ISO 22400 or Local in data catalogs and semantic models.
    • In reports and dashboards, include a short description or hover text clarifying when a KPI is non-standard or site-specific.
    • For cross-site or corporate scorecards, restrict non-standard KPIs to local views unless you have harmonized definitions across sites.

    This reduces the risk that management or auditors assume KPIs are comparable across plants or aligned to ISO 22400 when they are not.

    5. Avoid forcing artificial mappings

    Do not relabel a custom KPI as an ISO 22400 KPI just to “fit the model.” If the meaning, data set, or calculation does not actually match:

    • Keep the KPI as local and clearly named.
    • At most, reference the closest related ISO 22400 concept for context, explaining the differences.

    Artificial mappings can create audit exposure, misinterpretation of performance, and confusion for new plants or teams trying to align to standards.

    6. Plan for coexistence with legacy KPIs and systems

    Most regulated plants already have entrenched KPI definitions embedded in:

    • Legacy MES/SCADA logic and reports.
    • ERP or planning rules.
    • Quality dashboards and management reviews.
    • Excel-based operational scorecards.

    Full replacement of KPI logic to match ISO 22400 is rarely practical due to validation burden, re-training, and downtime risk. A more realistic approach is:

    • Layered mapping: Introduce ISO 22400-aligned metrics alongside existing ones, rather than replacing everything at once.
    • Dual reporting period: For a defined time, report both the legacy KPI and the nearest ISO-aligned KPI so stakeholders can understand differences.
    • Controlled migration: If you decide to retire or modify a legacy KPI, treat it as a formal change with risk assessment, validation (where required), and documented impact on historical trends.

    This approach respects brownfield constraints and reduces the risk of breaking established decision processes or audit trails.

    7. Use governance to prevent KPI proliferation

    Non-standard KPIs tend to multiply. To keep this under control:

    • Maintain a central KPI catalog with ISO-22400-aligned and local KPIs, including version history.
    • Require a minimal business case and governance review before adding new KPIs that are not in ISO 22400.
    • Periodically review local KPIs to retire obsolete ones or align them more closely with ISO 22400 if practice has converged.

    Strong governance helps keep metrics understandable to auditors, leadership, and new plants, while still leaving room for site-specific needs.

    8. Connecting this to ISO 22400 adoption efforts

    If you are adopting ISO 22400 into an existing environment, treat local KPIs without direct equivalents as part of your gap analysis. For each such KPI, decide whether it should be:

    • Maintained as a local extension with clear documentation.
    • Gradually converged towards an ISO 22400 metric over time.
    • Retired because its purpose is now covered better by a standard KPI.

    This incremental, documented approach keeps you aligned with ISO 22400 where it adds value, without disrupting validated systems or embedded operational practices.

  • Which organizational levels should ISO 22400 KPIs be reported at in aerospace plants?

    ISO 22400 KPIs should generally be reported at multiple organizational levels, not at a single level only.

    In an aerospace plant, the practical reporting hierarchy usually includes:

    • equipment, machine, or work center level for local execution control
    • cell, line, department, or value-stream level for supervision and short-interval management
    • site or plant level for operations leadership
    • program, business-unit, or enterprise level only when KPI definitions and data lineage are consistent enough to support valid comparison

    The key point is that the standard supports structured KPI calculation and aggregation, but it does not make every rollup equally meaningful. A KPI that is useful at a machine or cell level can become misleading when aggregated across mixed processes, different product families, outside processing steps, rework loops, or highly variable routings that are common in aerospace.

    What usually works best

    For most aerospace environments, the most defensible model is a layered approach:

    • report detailed KPIs close to execution, where supervisors and engineers can act on them
    • roll up only a smaller set of normalized KPIs to plant leadership
    • use enterprise rollups selectively, with clear definitions, inclusion rules, and context by site, program, and process type

    This matters because aerospace plants are often high-mix, low-volume, rework-sensitive, and routing-variable. A single plantwide number can hide whether a bottleneck sits in machining, composites, inspection, special processing, kitting, or final assembly.

    What determines the right reporting levels

    The right organizational levels depend on several plant-specific factors:

    • how consistent your master data is across MES, ERP, QMS, historians, and machine sources
    • whether work centers, routings, shifts, calendars, and downtime states are governed consistently
    • whether the KPI is intended for operational control, performance comparison, capacity planning, or management review
    • whether products and processes are similar enough that rolled-up values remain comparable
    • whether rework, nonconformance, concession, and outside processing flows are included or excluded in a controlled way

    If those controls are weak, enterprise-level reporting may create false precision. That is common in brownfield environments where plants run mixed vendor systems, legacy MES models, spreadsheet supplements, and locally defined downtime or quality codes.

    When not to roll up aggressively

    No, it is not automatically appropriate to report every ISO 22400 KPI up to the corporate level.

    Some KPIs lose meaning when aggregated too far. In aerospace, this often happens when:

    • different sites define production events differently
    • inspection-intensive and touch-labor-intensive areas are compared to automated areas without normalization
    • program-specific qualification constraints distort cycle or utilization results
    • manual data capture quality differs by department or shift
    • legacy systems cannot preserve full calculation lineage

    In those cases, cross-plant scorecards can drive the wrong behavior unless each KPI has a governed definition, calculation logic, and exception handling process under change control.

    Brownfield reporting reality

    In many aerospace plants, KPI reporting ends up being tiered because full replacement of MES, ERP, QMS, and plant data infrastructure is rarely practical. Qualification burden, validation cost, downtime risk, integration complexity, and long asset lifecycles usually make rip-and-replace strategies hard to justify.

    That means ISO 22400 reporting often has to coexist with existing systems. A workable approach is to standardize KPI semantics and mapping first, then improve source-system alignment over time. This is slower than a greenfield design, but it is usually more realistic and more auditable.

    So the short answer is: report ISO 22400 KPIs at the level where action is taken, then roll up only those measures that remain comparable and traceable at higher organizational levels.

  • Should every KPI in our catalog be ISO 22400-based?

    No. ISO 22400 is a useful reference for manufacturing KPIs, but forcing every KPI to be ISO 22400-based is usually neither realistic nor desirable, especially in regulated, long-lifecycle environments.

    Where ISO 22400 adds real value

    ISO 22400 is strongest when you want consistency and comparability for core operations metrics across lines, plants, or sites, for example:

    • Overall equipment effectiveness (OEE) and related availability, performance, and quality rates
    • Utilization, load, and throughput measures for equipment and lines
    • Standardized definitions of time categories (planned/unplanned downtime, changeover time, etc.)

    Using ISO 22400 for these types of KPIs can help:

    • Ensure a common vocabulary between OT, IT, engineering, quality, and finance
    • Reduce arguments over definitions during audits, investigations, and performance reviews
    • Simplify integration across MES, historians, and reporting tools by converging on standard data elements

    Where strict ISO 22400 alignment breaks down

    In regulated and complex operations, there are many important KPIs that do not map neatly to ISO 22400 definitions or require tailoring. Common examples include:

    • Regulatory and quality KPIs such as batch release lead time, CAPA cycle time, deviation recurrence, and defect escape rates
    • Product- and process-specific KPIs like first-pass yield by special process, qualification cycle time, or rework on critical characteristics
    • Customer- and contract-driven KPIs such as on-time delivery definitions set by SLAs, or performance metrics linked to penalties/bonuses
    • Safety and EHS KPIs that follow corporate standards or regulatory conventions rather than ISO 22400
    • Legacy KPIs with long history where changing the definition would break trend comparability that management and regulators rely on

    Trying to force these KPIs into ISO 22400 terminology can create confusion, weaken traceability to existing procedures, or misrepresent what the metric actually measures.

    Practical approach: a layered KPI catalog

    A more sustainable approach is to structure your KPI catalog in layers:

    1. Tier 1: ISO 22400-aligned KPIs where it fits cleanly
      Define a core set of site-wide operations KPIs based on ISO 22400 (e.g., OEE, availability, performance, quality rate, production volume). Use the ISO terminology and calculation logic as the reference, with documented local clarifications where needed.
    2. Tier 2: Enterprise-standard KPIs that reference ISO concepts but are adapted
      For example, you may use ISO 22400 time categories but define your own composite KPI for business reasons (e.g., a specific variant of schedule adherence that ties to MRP). Treat ISO 22400 as a building block, not a straightjacket, and document the differences explicitly.
    3. Tier 3: Local or domain-specific KPIs not covered by ISO 22400
      Allow plant-, product-, or regulator-specific metrics when justified by risk, compliance, or customer requirements. For these, you still need clear definitions, data sources, and change control, even if there is no ISO 22400 anchor.

    Key constraints in brownfield, regulated environments

    In existing plants with mixed MES, historians, and reporting stacks, full conversion to ISO 22400 for every KPI is constrained by:

    • Data model and historian limitations: Time categories and events may not be captured in ways that match ISO 22400 without re-engineering tags, interfaces, and calculations.
    • Validation and qualification burden: In GxP or aerospace-grade contexts, any change to a KPI used in release decisions, investigations, or risk assessments may require revalidation, updated procedures, and retraining.
    • Long trend baselines: KPIs with 5–10+ years of history used for risk justification or capacity planning cannot be redefined lightly without clear bridging logic and documented impact analysis.
    • Downtime and integration risk: Reworking KPI logic at the MES/OT layer to fully match ISO 22400 may require changes in multiple systems and interfaces, raising the risk of misalignment between shop-floor reality and reported numbers.

    These constraints mean that a “full replacement” strategy, where every existing KPI is forced into ISO 22400 forms, often fails or stalls. A targeted, incremental approach tends to be more realistic and less risky.

    How to decide when to base a KPI on ISO 22400

    For each KPI in your catalog, ask:

    • Is there a clear, relevant ISO 22400 equivalent? If yes, adopting or aligning to it may reduce ambiguity.
    • Will changing this KPI’s definition impact regulated decisions? If the metric supports release, deviation/complaint handling, or safety-related decisions, treat changes as controlled and justified.
    • Does cross-site comparability matter? Where you benchmark across plants or suppliers, ISO 22400 alignment can be useful, but only if data collection and context are comparable.
    • Can existing systems and data support the ISO definition reliably? If your event modeling, timestamps, or equipment states cannot be mapped cleanly, forcing ISO 22400 may result in misleading numbers.
    • Is there a strong legacy or contractual definition? If yes, you might keep the current KPI and introduce a parallel ISO-aligned metric, clearly differentiated.

    Governance and documentation

    Regardless of whether a KPI is ISO 22400-based, in a regulated environment you should:

    • Maintain a controlled KPI catalog with version history and approval traceability
    • Document for each KPI: the calculation, data sources, system of record, purpose, owner, and whether it aligns with ISO 22400 (and how)
    • Route KPI definition changes through appropriate change control, including impact assessment on procedures, validated systems, and reports
    • Keep mapping documents that show how local KPI definitions relate to any ISO 22400 elements used (time categories, states, base measures)

    This allows you to gain the benefits of ISO 22400 where it fits, without creating unrealistic standardization requirements or undermining existing traceability.

  • How do we label KPIs that are not part of ISO 22400?

    It is completely acceptable to define and use KPIs that are not part of ISO 22400, but they should be labeled and governed so that nobody confuses them with the standard ISO indicators.

    Keep a clear distinction from ISO 22400 KPIs

    The first rule is to avoid implying that non-standard KPIs are part of ISO 22400. In practice, this usually means:

    • Do not reuse ISO 22400 names or identifiers for different formulas.
    • Do not describe non-standard KPIs as “ISO 22400 compliant” or “ISO KPIs” when they are not.
    • Document explicitly when a KPI is site-specific, division-specific, or customer-specific.

    Use a simple, explicit naming convention

    Many regulated plants use a two-tier or three-tier convention so people and systems can distinguish standard vs local metrics at a glance. Examples (adapt the pattern, not the exact codes):

    • ISO KPIs: Prefix or flag them clearly, such as ISO22400-xx plus the official name where relevant.
    • Extended KPIs: Use a different prefix like EXT-, SITE-, or LOCAL-, for example SITE-OEE-variant or EXT-ReworkCostPerLot.
    • Customer / program KPIs: If you have customer- or program-specific KPIs, use a distinct code such as CUST- or a contract reference.

    The exact pattern is less important than consistency and clear differentiation from ISO identifiers. Be cautious about reusing common names like “OEE” without qualifiers if your formula diverges from ISO 22400 definitions.

    Maintain a KPI catalog with metadata

    In brownfield environments with multiple MES, BI, and reporting tools, label confusion often comes from missing documentation rather than the label itself. For non-ISO KPIs, keep a central catalog (spreadsheet, MDM, CMDB, or a dedicated KPI repository) that records at least:

    • KPI ID and label: The code and human-readable name.
    • Classification: For example, ISO22400, extended/site, customer/program, pilot/experimental.
    • Definition and formula: Precise formula, data sources, units, and any filters or exclusions.
    • Owner and approver: Who maintains the definition, and who approved it (important for change control).
    • Scope: Sites, lines, products, or programs where it applies.
    • Change history: Effective dates and rationale for any formula or label changes.

    In validated or audited environments, treat this catalog like controlled documentation: versioned, reviewed, and change-controlled, even if it sits outside your QMS as a technical reference.

    Be explicit about deviations from ISO definitions

    Some organizations adapt ISO 22400 KPIs to fit historical practices or data limitations. When you deviate, you should:

    • Use a modified name or suffix such as _adj, _legacy, or _site, rather than the plain ISO label.
    • Document clearly how the formula differs from the ISO definition, including any missing states, approximations, or alternate time bases.
    • Flag these KPIs in dashboards so users cannot mistake them for ISO-pure values.

    If your goal is to migrate towards ISO definitions over time, keep both KPI versions for a defined overlap period and label them distinctly (for example, OEE_legacy and OEE_ISO22400) until the transition is complete.

    Consider system coexistence and integration

    In a brownfield stack, the same KPI label may be implemented differently in MES, historian, and BI tools. For non-ISO KPIs:

    • Use the same ID and classification across systems wherever possible, even if the implementation details differ by vendor.
    • Map local vendor-specific measures to your catalog IDs in integration layers, not in people’s heads.
    • Validate that different systems produce consistent values for the same KPI ID within agreed tolerances.

    Full replacement of existing KPI logic in legacy MES or reporting systems often fails or stalls because of validation burden, downtime risk, and the need to requalify metrics used in procedures or customer reports. A more realistic path is to overlay a KPI catalog and labeling scheme that can coexist with legacy definitions and be gradually harmonized.

    Governance and change control

    For KPIs that affect batch release, capacity decisions, or regulatory submissions, treat label and definition changes as controlled changes:

    • Route changes through your existing change control processes.
    • Assess impact on SOPs, work instructions, and validated reports.
    • Maintain traceability between historical KPI series and new definitions so trend analyses remain interpretable.

    Where the same non-ISO KPI is used across multiple plants or business units, agree on a shared definition and label before deploying to avoid conflicting local variants under the same name.

    Practical starting pattern

    If you do not already have a scheme, a pragmatic baseline that usually works is:

    • ISO 22400 KPIs: ISO22400-[number]_[short-name]
    • Extended/site KPIs: SITE-[site-code]_[short-name]
    • Customer/program KPIs: PRG-[program-code]_[short-name]
    • Pilot/experimental KPIs: PILOT_[short-name] (explicitly not for formal reporting)

    Adapt these to your environment, but keep the main principle: make it impossible to confuse non-ISO KPIs with ISO 22400 indicators, and provide enough documentation that auditors, engineers, and managers can trace exactly what each label means and how it is calculated.