Connect981 – Content Dev

RSC Cluster: ISO 22400 Manufacturing KPIs for Modern Plants

  • Do we need to change our MES or ERP to support ISO 22400?

    You usually do not need to replace your MES or ERP to support ISO 22400. ISO 22400 defines a standardized model for manufacturing KPIs (such as OEE) and supporting data, not a specific software product. In most regulated, brownfield environments, the work is to map and extend what you already have, not to rip and replace core systems.

    What ISO 22400 actually requires

    At a practical level, supporting ISO 22400 means you can:

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

    • Calculate KPIs according to ISO 22400 definitions (e.g., equipment states, time categories, performance factors).
    • Trace the source data used for each KPI (events, quantities, time stamps) in a way that is auditable.
    • Use consistent terminology and structures so different plants or systems interpret KPIs the same way.

    The standard does not mandate a particular MES or ERP vendor, database, or architecture.

    When you can keep your existing MES/ERP

    In most plants, you can support ISO 22400 by working with your current stack and doing one or more of the following:

    • Data mapping: Map existing status codes, order types, equipment hierarchies, and time buckets in MES/ERP to the ISO 22400 structures and categories.
    • Configuration changes: Add or adjust reason codes, equipment states, shift calendars, or production event types in MES to align with ISO 22400 definitions.
    • Reporting/analytics layer: Implement ISO 22400 logic in a data warehouse, historian, or analytics layer that consumes MES/ERP data, rather than modifying MES/ERP transaction logic.
    • Lightweight extensions: Add edge data collection (e.g., machine connectivity) to fill gaps where MES/ERP lacks sufficient granularity for ISO 22400 KPIs.

    This approach fits regulated environments where full replacement of MES or ERP triggers extensive qualification, validation, and change-control burdens.

    When changes to MES/ERP are actually needed

    You may need to modify (but still not replace) MES or ERP if:

    • Key ISO 22400 base data is not captured at all (for example, no reliable machine state events or production quantity confirmations).
    • Existing status or reason codes are too coarse or overloaded to map cleanly to ISO 22400 categories.
    • Time or quantity stamping is inconsistent across lines, plants, or systems, making standardized KPIs untrustworthy.
    • There is no reliable way to link equipment, orders, and time (e.g., weak traceability between ERP orders and MES execution).

    In these cases, you typically:

    • Introduce new event types, fields, or reason codes in MES.
    • Standardize master data structures (equipment hierarchy, product families, calendars) in MES/ERP.
    • Improve integration so ERP order data and MES execution data can be joined consistently.

    All of this needs to go through formal change control, validation, and regression testing in regulated contexts.

    Why full replacement is rarely the right path

    Replacing MES or ERP solely to “support ISO 22400” is rarely justified in aerospace-grade or similar environments because:

    • Qualification and validation cost: New core systems require extensive validation, documentation, and often regulatory notifications or re-approvals.
    • Downtime and cutover risk: MES/ERP cutovers can disrupt production if anything goes wrong, which conflicts with tight delivery and compliance demands.
    • Integration complexity: Existing MES/ERP are usually integrated with PLCs, historians, QMS, PLM, and LIMS. Rebuilding those integrations only to compute standardized KPIs adds risk with limited benefit.
    • Equipment lifecycle: Many assets and controls are qualified for decades; changing the transactional backbone around them can re-open long-closed compliance questions.

    In practice, most organizations get ISO 22400 alignment by adding a standardized KPI data model and calculation layer on top of existing systems.

    Key dependencies and failure modes

    Whether you can stay on your current MES/ERP depends on:

    • Data quality: If timestamps, quantities, and states are unreliable, ISO 22400 calculations will be unreliable regardless of the software brand.
    • Plant-to-plant consistency: Different code sets and practices across sites can make ISO 22400 rollout difficult without harmonization.
    • Integration maturity: Poor integration between MES, ERP, and equipment will limit how far you can go without infrastructure work.
    • Change governance: Even small MES/ERP changes can be slow in regulated environments; planning and phasing are critical.

    Typical failure modes include treating ISO 22400 as a “tool purchase” instead of a data and governance project, or attempting a big-bang MES replacement that stalls under validation and integration load.

    Practical approach for brownfield environments

    A pragmatic path in most brownfield, regulated facilities is:

    1. Perform a gap analysis: compare current KPI calculations, data sources, and code sets to ISO 22400.
    2. Standardize master data and codes where possible without system replacement.
    3. Add or adjust MES/ERP configuration and integrations to capture missing events and links.
    4. Implement ISO 22400 KPI logic in a reporting/analytics layer, with traceability back to source records.
    5. Validate calculations, data flows, and reports under your existing CSV/validation framework.

    This preserves your existing MES and ERP investments while still moving toward a standardized KPI framework aligned to ISO 22400.

  • What are the main time categories used in ISO 22400?

    ISO 22400 defines a common time model for manufacturing equipment and lines so that KPIs such as OEE and availability are calculated consistently. At a high level, it splits the calendar into a small set of top-level time categories, which are then refined into subcategories. Naming in implementations can vary, but the core structure is:

    1. Non-scheduled time

    Periods when the equipment is not planned to be available for production. Typical examples:

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

    • Planned plant closure (weekends, holidays, shutdowns)
    • Outside the defined shift pattern

    Non-scheduled time is usually excluded from OEE calculations but is part of the full calendar time budget.

    2. Operation time (productive time)

    Periods when the equipment is scheduled and actually being used for value-adding production or directly supporting it. ISO 22400 further refines this into categories such as:

    • Processing / execution time: The machine is actively processing a workpiece or batch.
    • Manual production-related time: Operator actions directly needed for production (loading/unloading, in-cycle inspections, etc.).
    • Production-related setup and adjustment: Activities required to prepare equipment for the next product, batch, or order when considered part of effective operation for KPI purposes.

    Implementations differ on whether some setup and changeover elements are counted in operation time or classified separately, but ISO 22400 gives reference categories and definitions to keep this transparent.

    3. Standby time (planned interruptions within scheduled time)

    Periods within scheduled time when equipment is not producing but is not in failure. Typical reasons include:

    • Lack of input material, tooling, or components
    • No order currently dispatched to the equipment
    • Downstream blockage or buffer full
    • Planned micro-breaks or organized pauses that are not modeled as non-scheduled time

    ISO 22400 distinguishes standby from failures so that availability losses driven by planning or flow issues are not conflated with technical downtime.

    4. Planned downtime within scheduled time

    Time during which the asset is scheduled in the overall plan but intentionally taken out of production. Examples:

    • Planned preventive maintenance
    • Planned cleaning or sanitation cycles
    • Planned changeovers and setups, when modeled as a separate category
    • Planned engineering trials or qualification runs

    Whether this is included or excluded in OEE calculations depends on your agreed KPI definition, but ISO 22400 provides explicit categories so that decisions are visible and traceable.

    5. Unplanned downtime (failure time)

    Unscheduled loss of capability during scheduled time. This covers:

    • Equipment failures and breakdowns
    • Quality-driven stops (e.g., out-of-spec product requiring stoppage)
    • Unplanned safety or compliance-related stops
    • Unplanned maintenance interventions

    ISO 22400 encourages subcategorization (mechanical, electrical, automation, external utilities, quality block, etc.) to support root cause analysis and consistent KPI reporting.

    6. Supporting and ancillary time

    Some ISO 22400 categories capture time that is not strictly direct processing but is necessary to keep operations running, for example:

    • Calibration or verification activities carried out during scheduled time
    • Operator training on the machine during scheduled time
    • Engineering tests, software updates, or minor adjustments

    Plants differ in whether these are rolled into planned downtime, operation time, or tracked as a distinct ancillary bucket. ISO 22400’s value is in giving a standard vocabulary so such decisions are explicit.

    How this plays out in real plants and brownfield MES

    In practice, most regulated and brownfield environments do not implement ISO 22400 literally as printed. Existing MES, SCADA, historian, and CMMS systems often have legacy time and state codes that only partially align.

    Common realities:

    • Mapping, not replacement: You typically map existing machine states to ISO 22400 categories rather than redesigning the whole state model. Full replacement can be risky due to validation effort, integration impacts, and operator retraining.
    • Configuration- and data-dependent: The accuracy of each category depends on how well automation signals, operator inputs, and schedule data are integrated. Ambiguous or manual state changes can blur the lines between standby, planned downtime, and failures.
    • Traceability and change control: Any reclassification of time categories affects trend data and KPIs. In regulated environments this usually requires documented change control, impact assessment, and in some cases revalidation of KPI reports and dashboards.
    • Different KPI conventions: Some sites include certain planned downtimes in OEE; others exclude them and track a separate KPI (e.g., loading or TEEP). ISO 22400 helps standardize definitions, but your corporate KPI standard and regulatory expectations will drive the final choices.

    For new projects, it is often safer to align new equipment and interfaces to ISO 22400 from the start, then progressively harmonize legacy areas, rather than attempting a big-bang replacement of all time-state logic across the plant.

  • Can I extend an ISO 22400 KPI model with custom indicators?

    Yes. ISO 22400 does not forbid adding custom KPIs, as long as you do not relabel, redefine, or obscure the standard indicators. In most regulated, brownfield environments, you should treat extensions as a controlled, documented configuration layer on top of the reference model rather than a free-form customization exercise.

    What you can safely extend

    Typical, low-risk extensions include:

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

    • Additional KPIs that are clearly labeled as non-standard (for example, “Custom: Rework Cost per Good Unit”).
    • Refinements or sub-KPIs that decompose an ISO 22400 KPI into components (for example, breaking availability into planned vs unplanned loss buckets) while keeping the base KPI definition unchanged.
    • Context dimensions such as product family, cell, operator group, shift, or batch, if they do not alter the mathematical definition of the ISO 22400 indicators.
    • Mappings to local terminology (for example, local names for downtime categories), provided the underlying category mapping remains traceable to the standard structure.

    What you should not change

    To preserve comparability and avoid audit confusion, avoid:

    • Redefining calculation logic of a standard KPI (for example, changing how availability or OEE is computed) and still calling it by the ISO 22400 name.
    • Mixing data scopes (for example, sometimes including setup time in operating time, sometimes not) under the same KPI identifier.
    • Hiding which elements are custom, for example by presenting a custom KPI in dashboards as if it were a standard ISO 22400 metric without any qualifier.
    • Overloading fields (for example, using a standard data field to store unrelated local attributes) in MES/SCADA/BI data models, which breaks interoperability.

    Governance and traceability requirements

    In regulated environments, custom indicators should be introduced under formal governance:

    • Document the KPI catalog: For each KPI, record whether it is ISO 22400 standard or custom, the exact formula, data sources, filters, time base, and units.
    • Maintain change history: When you modify a KPI definition or its data sourcing, version it and log when the change took effect. This is important for auditability and trending analysis.
    • Establish ownership: Define who can approve new KPIs (for example, an operations analytics or performance management board including quality and IT).
    • Ensure data lineage: Map each KPI to its originating systems (MES, SCADA, LIMS, ERP) and transformations used (ETL, calculations in the data warehouse, BI logic).

    Integration with existing MES/ERP/QMS stacks

    In brownfield environments, how you extend the model is constrained by existing systems:

    • MES limitations: Many MES products come with a fixed KPI set or opinionated OEE / performance calculations. Extending ISO 22400 often means adding logic in a data warehouse or BI layer rather than modifying the MES itself.
    • ERP/financial alignment: Cost-related custom KPIs must reconcile with ERP data. Differences in time buckets, posting delays, and valuation methods need to be clearly documented.
    • QMS and batch records: If quality or batch-release decisions rely on KPIs, be careful about introducing or changing indicators without revalidating procedures and documentation.
    • Long equipment lifecycles: Some legacy controls or data historians cannot easily provide all data needed for certain ISO 22400 KPIs. You may need proxy metrics or manual data collection until upgrades occur.

    Validation and regulated use

    If KPIs affect release decisions, quality risk assessments, or regulatory submissions, adding custom indicators can trigger validation and documentation obligations:

    • Treat KPI logic as configurable software behavior in your validation framework if it influences GMP/GxP or safety-relevant decisions.
    • Test and verify that new calculations are accurate, consistently sourced, and robust to missing or delayed data.
    • Control configuration so that changes to KPI definitions, thresholds, or filters go through formal change control with impact assessment.
    • Avoid dual definitions (for example, two groups computing “availability” differently); this is a common source of audit questions and root cause analysis noise.

    Cross-plant and cross-vendor comparability

    One of the main reasons to follow ISO 22400 is comparability across plants, lines, and vendors. Extensions can erode this benefit if not handled carefully:

    • Keep a core set of strict ISO 22400 KPIs used for benchmarking and external reporting, without local modifications.
    • Layer plant-specific or product-specific KPIs as a separate namespace (for example, prefix with “PLANT-A:” or “PRODUCT-X:”) so they are obviously non-standard.
    • Ensure vendor-neutral definitions so that if you swap or add systems, you can still compute the same KPIs from new sources with minimal rework.

    Why full replacement of existing KPI schemes is risky

    Replacing legacy KPI schemes wholesale with an ISO 22400-only model rarely works smoothly in high-regulation, long-lifecycle environments:

    • Qualification burden: Replacing existing OEE / performance metrics may require requalifying reports, dashboards, and sometimes procedures.
    • Downtime risk: Re-engineering KPI logic inside MES or historian layers can disrupt production monitoring or line startup procedures.
    • Integration complexity: Upstream and downstream systems (ERP, PLM, QMS) often embed assumptions based on existing KPIs, time buckets, and data semantics.
    • Traceability and trending: A hard switch to new KPI definitions can break comparability with historical trends unless you maintain mappings and dual reporting for a transition period.

    In practice, most organizations adopt a hybrid approach: keep critical legacy KPIs where required, introduce ISO 22400 as the reference baseline, then extend that model with custom indicators under tight governance.

  • How should equipment state events be modeled for ISO 22400 KPIs?

    ISO 22400 KPIs assume that every equipment resource has a clear, time-based history of states (e.g., producing, setup, idle, failure). Modeling equipment state events is about making that history explicit, consistent and queryable across heterogeneous equipment and systems.

    1. Start from a canonical state model, not vendor tags

    Do not model states directly from each machine’s native status bits or OEM naming. Instead, define a canonical state model for your site that is aligned to ISO 22400 notions of:

    In practice, this connects to data mapping and system interoperability when teams need to turn the answer into repeatable execution habits.

    • Operating / producing (planned production, good parts, may include controlled rework)
    • Planned downtime (scheduled maintenance, planned changeover, planned breaks)
    • Unplanned downtime (failures) (breakdowns, safety stops, unplanned maintenance)
    • Setup / changeover (if modeled separately from planned downtime)
    • Idle / starved / blocked (equipment available but not producing)
    • Testing / calibration / qualification (often non-productive but planned and required)

    Use this canonical model as the target and then map equipment-specific signals into it. ISO 22400 leaves room for site-specific detail; the critical point is consistency across assets so KPI calculations remain comparable.

    2. Represent states as time-bounded events

    For KPI calculation, each state must be represented as an event with:

    • Equipment identifier (logical resource, not just a PLC address)
    • State code (from your canonical model)
    • Start timestamp (ideally from a synchronized time source)
    • End timestamp (or an explicit “open” marker until the next state)
    • Origin / source (SCADA, MES, manual, CMMS, etc.)
    • Reason / cause code where applicable (for downtime, reduced speed, planned vs unplanned)

    ISO 22400 KPIs like availability, performance and OEE rely on aggregating state durations over a time window. That aggregation breaks down if events do not have well-defined start and end times.

    3. Enforce “one active state per resource”

    To avoid ambiguous KPI calculations, model states so that for any point in time and any given resource:

    • There is at most one active primary state (e.g., operating, planned downtime, failure, idle).
    • Optional secondary attributes (e.g., reason codes, product, order) are attached to that primary state, not modeled as separate overlapping primary states.

    In practice this means you need logic in your MES/event processor to:

    • Terminate the previous state when a new primary state starts.
    • Detect and resolve overlaps coming from different systems (e.g., SCADA vs CMMS vs operator terminals).
    • Handle “unknown” or “undefined” states explicitly if data is missing.

    Overlapping primary states are a common failure mode when integrating multiple legacy systems and will lead to double-counted or under-counted time in ISO 22400 KPIs.

    4. Separate “what” (state) from “why” (reason)

    For analysis of losses, model the “what” and “why” distinctly:

    • The state captures the high-level category aligned to ISO 22400 (e.g., “unplanned downtime”).
    • The reason code captures the specific cause (e.g., “tool breakage”, “material shortage”, “operator not available”).

    Reason codes can be hierarchical and site-specific, but should be governed under change control, because they directly impact KPI interpretations and trend analysis over multi-year equipment lifecycles.

    5. Define clear rules for planned vs unplanned time

    ISO 22400 KPIs depend heavily on how you distinguish planned from unplanned time. Your model should include explicit rules, typically configured in MES or scheduling systems:

    • Link planned downtime to the site’s production calendar, shift patterns, and planned maintenance windows.
    • Ensure triggers from the CMMS (e.g., planned PM) are correctly mapped to planned states, not failures.
    • For changeovers, decide whether you treat them as planned downtime or as a distinct category and apply that consistently.

    If calendar or planning data is unreliable or not integrated, you will struggle to compute ISO 22400 KPIs consistently across lines and plants.

    6. Explicit modeling of reduced speed and microstops

    For performance-related ISO 22400 KPIs, you need to model:

    • Operating at nominal speed
    • Operating at reduced speed
    • Frequent, short stops (microstops), if your measurement granularity and process justify it

    There are two common patterns:

    1. State-based: distinct states for “operating” vs “reduced speed” vs “microstop” (with minimum durations or count thresholds to avoid noise).
    2. Rate-based: a single “operating” state with a throughput attribute (actual vs nominal rate), and microstops inferred from short, frequent transitions to non-operating states.

    Choose one approach and implement it consistently. Changing approaches mid-stream without migration will break trendability and auditability of KPIs.

    7. Handle manual interventions and overrides carefully

    In regulated or high-mix environments, operator-initiated state changes and corrections are common. Model them so that:

    • Manual changes are tagged as such (who, when, from which interface).
    • Original machine-derived states are retained for traceability, not overwritten in-place.
    • There is an audit trail capturing reason for the override, especially when it changes planned vs unplanned categorization.

    This is important for ISO 22400 KPI credibility and for internal and customer audits. It also limits the risk that performance metrics are “massaged” without traceability.

    8. Brownfield reality: normalize and reconcile across systems

    In most plants, equipment state information is fragmented across:

    • PLC/SCADA/IIoT signals
    • MES operation states
    • CMMS work orders and maintenance status
    • Operator HMI / terminals / andon systems

    For ISO 22400 KPIs you generally need an event consolidation layer (often in MES or a dedicated event store) that:

    • Maps raw signals into the canonical state model.
    • Reconcilers conflicting inputs using deterministic rules (e.g., safety trip overrides “operating” states).
    • Resolves overlaps and fills gaps (with “unknown” state if necessary, not silent assumptions).
    • Stores state history in a structure optimized for time-based queries and traceability.

    Full replacement of legacy systems just to unify state modeling is rarely practical in regulated, long-lifecycle environments. A normalization and reconciliation layer lets you keep existing MES/SCADA/CMMS while still computing ISO 22400 KPIs consistently.

    9. Validation, governance and change control

    Because KPI outputs may influence maintenance, capacity planning, and in some cases customer reporting, treat the state model as a controlled asset:

    • Document the canonical state definitions and mapping rules from each equipment/vendor.
    • Version-control the state catalog and reason code hierarchies.
    • Apply formal change control when altering state definitions or mappings.
    • Validate KPI calculations when mappings change (e.g., before/after comparisons on representative lines).

    Without this discipline, KPI trends can shift due to modeling changes rather than actual performance, which is hard to detect in long equipment lifecycles.

    10. Typical failure modes to avoid

    Common pitfalls when modeling equipment state events for ISO 22400 include:

    • Multiple overlapping primary states per resource from different systems.
    • Implicit assumptions about planned time when the production calendar is not integrated.
    • No clear distinction between “operating” and “reduced speed” when performance KPIs are critical.
    • Inconsistent mapping across assets or plants (e.g., the same OEM signal mapped differently).
    • Loss of history when manual overrides overwrite raw data instead of appending corrections.

    Detecting these issues early requires both data checks (e.g., no gaps/overlaps) and pragmatic line-walks with operators and maintenance to confirm that modeled states reflect real behavior.

    Connecting to ISO 22400 KPIs

    Once state events are modeled as above, ISO 22400 KPIs translate to time-based calculations on that state history. For example:

    • Availability: time in operating states / planned production time.
    • Performance: actual output vs theoretical output given time in operating states and nominal rates.
    • Loss analysis: aggregation of unplanned downtime and reduced-speed durations by reason code.

    The quality of these KPIs is only as good as the underlying event model and its alignment across equipment, lines, and plants.

  • Does ISO 22400 specify how KPIs must be visualized on dashboards?

    No. ISO 22400 does not prescribe specific dashboard layouts, chart types, colors, or interaction patterns for KPI visualization.

    What ISO 22400 actually covers

    ISO 22400 defines a common language and structure for manufacturing performance indicators, especially for areas like OEE, availability, performance, and quality. In particular it focuses on:

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

    • Definitions of KPIs and related terms.
    • Logical data relationships and aggregation levels.
    • Calculation methods and input data requirements.
    • Use cases for comparing performance across machines, lines, or plants.

    The standard is primarily about what to measure and how to calculate or categorize it, not how it must be rendered on screen.

    What remains your responsibility

    Because ISO 22400 does not fix the presentation layer, each organization must make design and validation decisions around:

    • Visualization patterns: gauges vs time-series charts vs tables; use of thresholds and color coding; drill-down behavior.
    • Audience and hierarchy: what is appropriate at machine/line dashboards vs supervisor vs plant leadership views.
    • Update cadence and latency: how frequently KPIs refresh and how lag is communicated, especially when source data comes from mixed MES/ERP/PLC layers.
    • Context and traceability: how an operator or auditor can trace a displayed KPI back to its underlying data set, time window, and calculation method.
    • Alarm and escalation logic: when KPIs trigger alerts, and whether these are advisory vs integrated into formal workflows.

    In regulated environments, these design decisions typically require documented requirements, change control, and, where applicable, validation or qualification. ISO 22400 does not remove that burden and does not guarantee that any specific visualization is appropriate for your process, safety profile, or regulatory regime.

    Coexistence with existing MES/ERP and dashboards

    In brownfield environments, you are unlikely to replace all existing dashboards simply to align with ISO 22400. More common approaches include:

    • Harmonizing definitions: mapping existing KPIs to ISO 22400 concepts and calculations, then updating labels and documentation while leaving most of the visual layout intact.
    • Incremental redesign: standardizing visual patterns for a subset of KPIs (for example, OEE and downtime) in an existing MES or BI tool, then phasing in similar patterns elsewhere as systems are upgraded.
    • Integration constraints: accepting non-uniform visualization across legacy systems while using ISO 22400 as the canonical definition in data models, data warehouses, and documentation.

    Full replacement of established dashboards solely for visual standardization often fails in aerospace- or pharma-grade contexts due to validation cost, risk of misinterpretation during transition, limited downtime for deployment, and the complexity of requalifying user training and work instructions. ISO 22400 can guide KPI semantics without forcing a wholesale UI replacement.

    Practical use of ISO 22400 for dashboards

    In practice, organizations tend to use ISO 22400 to:

    • Standardize KPI names, formulas, and time bases across plants and vendors.
    • Align data models feeding MES, historians, and BI dashboards.
    • Document assumptions so that different dashboards can be compared reliably even if they look different.

    The visual design itself is then driven by safety, usability, site conventions, and tool limitations, and must be validated within each plant’s quality system where required.

  • How do we document KPIs so they align with ISO 22400?

    ISO 22400 defines a common language and structure for manufacturing KPIs, especially around OEE and related performance metrics. Aligning with it is less about inventing new KPIs and more about documenting what you already use in a way that is traceable to the standard.

    1. Decide which ISO 22400 KPIs actually apply

    Do not try to implement every KPI in ISO 22400 by default. Start by identifying which of the standard’s KPIs are relevant for your products, equipment and regulatory context. Typical candidates:

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

    • OEE and its components (Availability, Performance, Quality)
    • Equipment utilization and loading
    • Production throughput and lead time metrics
    • Scrap, rework and first-pass yield metrics

    Document this scoping decision explicitly so it is clear why some ISO KPIs are in scope and others are not.

    2. Create a standard KPI specification template

    Use a controlled template so every KPI is documented consistently. At minimum, each KPI record should include:

    • Name and identifier: Local KPI name and a unique ID. Reference the corresponding ISO 22400 KPI ID where applicable.
    • Purpose and decision use: What decisions this KPI informs (e.g., shift-level dispatching, weekly performance review, CAPA effectiveness checks).
    • ISO mapping: Which ISO 22400 part and KPI it aligns with, and whether it is a direct match, a partial match, or an extension.
    • Formal definition: Plain-language description of what is being measured and the scope (plant, line, cell, asset, product family, time bucket).
    • Formula: Exact formula with units, including how each term is defined (e.g., what counts as planned vs unplanned downtime, what is excluded from good units).
    • Data sources: Systems, interfaces and, if needed, manual inputs (e.g., MES events, PLC tags, ERP order data, QMS defect records).
    • Aggregation rules: How the KPI is rolled up across lines, shifts, products and periods, and what is not allowed (e.g., why you cannot average OEE percentages directly across lines).
    • Calculation timing and latency: Real-time, near-real-time, end-of-shift, end-of-day, etc., and expected update delay.
    • Filters and exclusions: Maintenance windows, engineering trials, non‑standard products, or restricted operations that are excluded from the KPI.
    • Responsible owner: Role accountable for definition, correctness and change control.
    • Validation and testing: How the KPI is validated when first implemented and after each change (test cases, sample calculations, reconciliation checks).

    This template should itself be a controlled document, linked to your document control and change management process.

    3. Map existing KPIs to ISO 22400 terms

    Most brownfield plants already track OEE-like metrics, but with local names and variations. To align with ISO 22400:

    • Catalogue current KPIs: List the KPIs used in production reviews, management dashboards and regulatory reporting.
    • Compare definitions: For each KPI, compare your definition and formula to the ISO 22400 definition.
    • Classify the relationship:
      • Exact match: Same meaning, scope and formula as ISO.
      • Partial match: Same intent but different scope or components (e.g., your OEE excludes certain losses that ISO includes).
      • Local KPI: Not defined in ISO 22400 but useful internally.
    • Document gaps and deviations: For partial matches and local KPIs, explicitly describe how and why they differ from ISO 22400.

    This mapping avoids confusion when auditors, customers or corporate functions reference ISO 22400 terminology.

    4. Normalize definitions and terminology carefully

    Alignment with ISO 22400 often means cleaning up legacy definitions that vary by plant, product or even supervisor. To document KPIs consistently:

    • Standardize key terms: For example, what counts as “good units”, “planned downtime”, “setup”, “micro-stops” or “rework” must be defined once and used consistently across sites where you claim ISO 22400 alignment.
    • Resolve local variants: If different plants use “OEE” differently, consider renaming local metrics (e.g., “Line OEE (legacy)”) and defining an ISO-aligned version explicitly.
    • Use a glossary: Keep shared definitions for terms used across multiple KPIs, and reference that glossary from each KPI spec instead of redefining terms each time.

    In regulated environments, apply change control if you change definitions, because historical trends and any prior analyses may no longer be directly comparable.

    5. Document data lineage and system coexistence

    In mixed MES/ERP/SCADA/QMS landscapes, two plants can implement the “same” KPI very differently unless data lineage is explicit. For each KPI:

    • Identify system of record: E.g., equipment state from MES vs SCADA, quantity produced from MES vs ERP, quality disposition from QMS vs LIMS.
    • Describe transformations: Any filtering, time alignment, or reclassification performed in data warehouses, analytics tools or custom scripts.
    • Note known limitations: For example, legacy machines that do not provide fine-grained downtime codes, or manual quality logs that limit timeliness.
    • Clarify multiple implementations: If two plants use different data paths for an ostensibly common KPI, document both and state whether they are considered equivalent for corporate reporting.

    This level of documentation is often necessary to support auditability, investigations and cross-plant benchmarking.

    6. Put KPI definitions under document control and change management

    In regulated settings, KPI definitions and their formulas should be treated like any controlled method specification:

    • Version control: Assign version numbers, maintain change history and archive prior definitions.
    • Impact assessment: Before changing a KPI, assess impact on regulatory reports, SLAs, management targets and incentive schemes.
    • Effective dates: Record when a new definition goes live so analysts know where historical comparisons may break.
    • Communication: Ensure operations, quality and IT teams know which KPI versions are active in which systems and dashboards.

    If KPI logic is implemented in software (MES reports, data models, dashboards), link the controlled KPI document to implementation artifacts and tickets, and require re-validation after changes.

    7. Validate KPI implementations against the documentation

    To claim alignment with ISO 22400, you should be able to show that what the system calculates matches the documented definition:

    • Define test cases: Use realistic scenarios with known downtime, counts and scrap to compute expected KPI values by hand or in a spreadsheet.
    • Compare system output: Run the same scenarios through MES reports or analytics tools and reconcile differences.
    • Check boundary conditions: Very low volumes, partial shifts, overlapping downtime, mixed product runs, and backdated transactions.
    • Re-validate after changes: Treat KPI logic changes like any other validated computation: regression tests, documented approvals and sign-off.

    Without this step, you may have beautifully documented KPIs that are not actually used or computed as specified.

    8. Be explicit about where you do not fully align with ISO 22400

    Full, literal alignment is not always realistic in brownfield environments. Common constraints include:

    • Legacy equipment without granular event data, forcing approximations.
    • Integration gaps that prevent clean separation of some loss categories.
    • Existing contractual or regulatory reporting formats that conflict with ISO structures.

    Where this happens, document the deviation from ISO 22400, the rationale, and any mitigation (e.g., additional local KPIs or annotations in reports). This is usually more credible than claiming full compliance when underlying data does not support it.

    9. Why “rip-and-replace” KPI systems usually fails in regulated plants

    Teams sometimes propose replacing all existing metrics with a “pure” ISO 22400 set. In long-lifecycle, regulated environments this often fails because:

    • Qualification and validation burden: Reworking KPIs across MES, ERP, data warehouses and reports can trigger significant re-validation and re-qualification work.
    • Downtime and change risk: Deep changes to production and quality reporting logic can disrupt operations and confuse decision-making if cut over abruptly.
    • Traceability impact: Abruptly changing KPI definitions complicates investigations, CAPA trending and audit trails that rely on historical continuity.

    A more workable approach is to converge definitions toward ISO 22400 over time, starting with documentation and mapping, then gradually aligning formulas and data flows as systems are upgraded or re-validated.

    10. Practical next steps

    To move toward ISO 22400-aligned KPI documentation:

    1. Publish a KPI specification template under document control.
    2. Catalogue current KPIs used in operations, quality and management reviews.
    3. Map each to ISO 22400 where applicable and classify as exact, partial or local.
    4. Prioritize 5 to 10 critical KPIs and fully document them using the template.
    5. Work with IT and MES/ERP owners to verify system calculations against the documented formulas.
    6. Plan a phased roadmap to address the biggest gaps and inconsistencies, aligned with existing maintenance, upgrade and validation cycles.

    This approach respects existing systems and constraints while moving you toward a traceable, ISO 22400-aligned KPI framework.

  • What is the main purpose of ISO 22400 in manufacturing?

    ISO 22400 is a family of standards that defines a common, structured way to measure and describe manufacturing performance. Its main purpose is to standardize key performance indicators (KPIs), especially around Overall Equipment Effectiveness (OEE) and related metrics, so different plants, systems, and stakeholders can use a consistent language and calculation basis.

    What ISO 22400 is trying to solve

    In most brownfield environments, every site and vendor calculates “OEE” and other KPIs slightly differently. ISO 22400 addresses this by:

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

    • Defining standard KPIs for manufacturing operations (e.g., availability, performance, quality, OEE-related metrics).
    • Specifying how those KPIs are derived from underlying events and time states.
    • Providing common terminology so MES, SCADA, historians, and reporting tools can align.

    The intent is not to dictate how you run operations, but to make measurement and comparison more reliable within and across plants, vendors, and programs.

    How it is used in regulated and brownfield environments

    In regulated, long-lifecycle manufacturing, ISO 22400 is typically used as a reference framework rather than a drop-in solution. Common uses include:

    • Harmonizing KPIs across sites and vendors: Selecting a subset of ISO 22400 KPIs as your corporate standard, then mapping existing plant-specific metrics to those definitions.
    • Designing or upgrading MES/OEE solutions: Using ISO 22400 definitions when specifying requirements for new MES modules, OEE tools, or data models.
    • Improving traceability and auditability of metrics: Documenting how each KPI is calculated, the data sources used, and how time states are categorized.

    In most brownfield cases, you will not fully replace legacy KPI logic overnight. Instead, ISO 22400 provides a target model to converge toward, subject to:

    • Data readiness: Many ISO 22400 KPIs assume clean, well-typed event and time-state data. Plants with manual logging or partial automation may need incremental improvements.
    • Integration quality: Misaligned timestamps, partial connectivity, and inconsistent downtime coding can limit how far you can apply the standard without remediation.
    • Validation and change control: In regulated environments, any change to KPI definitions used in release decisions, batch review, or management reports often requires impact assessment, validation, and documented approvals.

    What ISO 22400 does not do

    • It does not guarantee compliance, audit outcomes, or product quality.
    • It does not replace your MES, historian, ERP, or OEE systems.
    • It does not remove the need for site-specific configuration, engineering judgment, or local work instructions.
    • It does not solve integration debt or data-quality issues on its own; it only defines how metrics should look when those issues are managed.

    Key tradeoffs when adopting ISO 22400

    When you align to ISO 22400, you typically face tradeoffs such as:

    • Standardization vs. legacy continuity: Tight adherence may require changing long-used KPI definitions, which can disrupt historical comparisons and require re-education of stakeholders.
    • Precision vs. implementation cost: Implementing the full granularity of time categories and events can be expensive in brownfield plants with limited instrumentation.
    • Cross-plant comparability vs. local flexibility: ISO 22400 helps with cross-plant benchmarking, but some sites may need additional local metrics that do not map neatly into the standard.

    Because of validation burden and downtime constraints, most organizations phase adoption: start with a core set of ISO 22400-aligned KPIs and progressively refactor underlying data and calculations as systems are upgraded.

    Bottom line

    The main purpose of ISO 22400 in manufacturing is to provide a common, standardized framework for defining and calculating manufacturing KPIs, particularly OEE and related measures. It supports comparability, clearer specifications for MES/OEE tooling, and better traceability of performance data, but its value depends heavily on data quality, integration maturity, and disciplined change control in your existing environment.

  • What is the best way to manage time zones in global manufacturing KPI reporting?

    The best approach is to use UTC as the system record for timestamps, while calculating KPIs against the relevant plant-local business calendar for operational reporting.

    In practice, that means:

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

    • Store raw event times in UTC in your data platform or integration layer.
    • Retain the source plant time zone, including daylight saving behavior where applicable.
    • Map events to the plant’s production calendar and shift schedule before calculating shift, day, week, or month KPIs.
    • Expose the reporting basis clearly, such as local plant day, regional rollup day, or enterprise UTC day.

    For most manufacturers, a single global reporting time zone is not the best answer for all use cases. It simplifies some enterprise dashboards, but it can distort shift performance, daily attainment, downtime buckets, and handoff analysis at the plant level.

    What usually works best

    Use a dual-view model:

    • Operational KPIs such as OEE, downtime by shift, schedule attainment, first pass yield, and labor utilization should usually be calculated in the plant’s local time context.
    • Enterprise rollups can be aggregated in UTC or another governed corporate reporting standard, but the rule must be explicit and consistently applied.

    This avoids a common failure mode where headquarters sees a clean global dashboard, but plant leaders reject it because the numbers do not align with local shift books, MES totals, or daily production meetings.

    Key design rules

    • Separate timestamp storage from KPI logic. UTC is a storage and ordering standard, not automatically the right business reporting context.
    • Version control calendars and shift definitions. If shifts change, holidays move, or overtime windows are added, historical KPI calculations may change unless calendar logic is governed.
    • Define the time boundary for each KPI. Some KPIs should align to machine event time, some to work order completion, and some to posting time in ERP or quality systems.
    • Handle daylight saving transitions explicitly. Ambiguous or duplicated hours can break shift-based metrics if the system only stores local timestamps without offset metadata.
    • Show time zone context in the report. Users should be able to see whether a metric is based on local plant time, UTC, or a corporate financial close calendar.

    Brownfield reality

    In brownfield environments, time zone issues are often less about reporting tools and more about inconsistent source systems. MES, SCADA, historians, ERP, QMS, maintenance platforms, and manual logs may all treat time differently. Some store UTC correctly, some store server local time, some store operator-entered local time with no offset, and some change behavior after upgrades or site migrations.

    That means the best answer depends on data readiness and integration quality. If source timestamps are inconsistent or shift calendars are not governed, changing the dashboard alone will not fix KPI credibility.

    A practical pattern is to establish a canonical timestamp policy in the integration or analytics layer rather than trying to replace every source system. Full replacement is often not realistic in regulated, long-lifecycle operations because of qualification burden, validation cost, downtime risk, integration complexity, and the need to preserve traceability through controlled change.

    Tradeoffs to expect

    • UTC-only reporting improves technical consistency but can reduce operational trust at the plant level.
    • Local-only reporting fits plant execution better but makes cross-plant comparison harder if calendars and KPI definitions differ.
    • Dual reporting models are usually more credible, but they require stronger semantic governance, master data discipline, and change control.

    So the best way is usually not to force one universal display rule. It is to standardize timestamp storage in UTC, govern plant-local business time for operational KPIs, and make aggregation rules explicit for cross-site reporting.

  • Does ISO 22400 define manufacturing operations management (MOM) differently from MES?

    ISO 22400 does not create a new, conflicting definition of Manufacturing Operations Management (MOM) compared with MES. Instead, it largely follows the IEC 62264 / ISA‑95 view: MOM is a functional scope, and MES is one of the main categories of systems used to implement that scope.

    How ISO 22400 treats MOM vs MES

    ISO 22400 is a standards family focused on manufacturing KPIs (for example OEE and related metrics) and how to structure them. When it refers to MOM and related layers, it aligns with the ISA‑95 / IEC 62264 concept of a MOM level that sits between enterprise planning (ERP) and shop-floor control (SCADA, DCS, equipment controllers).

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

    Within that structure:

    • MOM is the collection of business and technical functions that manage production, quality, logistics, and maintenance execution at the plant level.
    • MES is typically the primary software category that implements many MOM functions, but not the only one. LIMS, APS, maintenance systems, and custom applications can all be part of the MOM layer.

    ISO 22400 does not redefine MES itself; it assumes the widely used industry notion of MES as an execution system that carries out a subset of the broader MOM responsibilities.

    The practical difference in real plants

    In a regulated, brownfield environment, the gap between MOM scope and what your MES actually does can be significant:

    • One MES may handle electronic travelers, work-in-process tracking, and basic quality, but leave maintenance, detailed scheduling, or laboratory workflows to other systems.
    • Some sites run multiple MES-like systems by line, plant, or product family, which together fulfill MOM functions.
    • Legacy or homegrown tools (Access databases, spreadsheets, custom web apps) may carry key MOM functions that are not reflected in the vendor MES brochure.

    Seen through the ISO 22400 / ISA‑95 lens, all of these systems, integrations, and procedures form your actual MOM environment. MES is one important implementation component, not the full definition of MOM.

    Why this matters for KPIs and ISO 22400

    Because ISO 22400 is about KPIs and their relationships, its use of MOM is primarily to:

    • Clarify where KPI data should originate in the architecture (for example, MOM vs ERP vs control systems).
    • Distinguish between KPIs describing execution (MOM/MES layer) and those about higher-level planning or business performance.

    For an aerospace or other regulated operation, that means:

    • You should not assume that adopting an MES product automatically gives you a complete MOM layer as envisioned in ISO 22400.
    • KPI design and data lineage need to reflect the actual mix of MES, QMS, LIMS, PLM, maintenance, and custom tools in use.
    • Traceability, validation, and change control have to be applied across the full MOM scope, not just the MES application.

    Coexistence with existing MES and other systems

    In long-lifecycle, highly regulated plants, fully replacing MES or rebuilding the MOM layer around a single new platform is rarely straightforward. Qualification burden, integration complexity, downtime risk, and the need to maintain historical traceability often make incremental change the only viable path.

    In that context:

    • Use ISO 22400 and the MOM concept to map functions and data ownership across your existing MES, ERP, PLM, QMS, and maintenance tools.
    • Identify which MOM functions are not covered by your current MES and where KPI data is fragmented or unreliable.
    • Plan integrations and changes under formal change control and validation, focusing first on the MOM areas that most affect safety, quality, and regulatory exposure.

    This approach treats MOM as the functional blueprint and your MES as one (important) building block, consistent with how ISO 22400 and ISA‑95 use the terms.

  • State-Based KPI

    A state-based KPI is a performance metric that is calculated and analyzed separately for specific, defined states of equipment, production lines, or processes. Instead of averaging performance across all time, a state-based KPI isolates performance during particular states, such as running, changeover, maintenance, standby, or fault.

    What it is

    In industrial and manufacturing environments, equipment and processes are commonly modeled in distinct states (for example: Producing, Setup, Planned Downtime, Unplanned Downtime, Starved, Blocked). A state-based KPI uses these state definitions as a filter or dimension when computing metrics.

    Typical examples include:

    • Yield when the line is in a “Producing” state only
    • Mean time to repair (MTTR) for the “Unplanned Downtime” state
    • Changeover duration KPI tied to the “Setup” or “Changeover” state
    • Energy consumption per hour in “Idle” vs “Running” states

    Operational meaning

    In OT and MES environments, equipment state comes from machine signals, PLC tags, or manual operator inputs. State-based KPIs are then calculated in historians, MES, operations intelligence tools, or data warehouses by:

    • Classifying each time segment into a discrete state
    • Aggregating production, quality, or downtime data within those states
    • Reporting KPIs by state, often as time-series, dashboards, or Pareto views

    This approach is frequently used to refine high-level metrics such as OEE, NPT, or capacity utilization by making it clear which states are contributing to losses, variability, or nonproductive time.

    What it includes and excludes

    Included:

    • KPIs explicitly segmented by defined machine or process states
    • KPIs driven by state models from MES, SCADA, historians, or event logs
    • Analysis that compares performance across different states (for example, quality in warmup vs steady-state running)

    Excluded:

    • Simple time-based averages that ignore state (for example, daily average throughput without state segmentation)
    • Business KPIs not tied to operational state models, such as monthly revenue or total plant headcount

    Common confusion

    State-based KPI vs. event-based KPI: A state-based KPI is segmented by continuous states over time (for example, 14:00–14:15 in Running). An event-based KPI is calculated from discrete events (for example, individual alarms or work orders), which may or may not be tied to a state model.

    State-based KPI vs. condition-based monitoring: Condition-based monitoring focuses on asset health indicators (vibration, temperature). A state-based KPI focuses on performance metrics partitioned by operational state, which can use condition data but is not limited to it.

    Use in regulated and integrated environments

    In regulated manufacturing, state-based KPIs are often used to distinguish between productive and nonproductive time, classify downtime reasons, and support investigations or continuous improvement. When integrated with MES, ERP, or quality systems, state-based KPIs can be correlated with batches, work orders, or material lots to understand performance in specific operational states during a given order or batch.