Connect981 – Content Dev

RSC Cluster: ISO 22400 Manufacturing KPIs for Modern Plants

  • Real-Time View

    A real-time view is a live, continuously updated display of operational data that shows the current status of systems, equipment, materials, or processes with minimal delay. In manufacturing and industrial operations, it typically appears as dashboards, HMI screens, or monitoring pages that refresh automatically as new data arrives from shop-floor or enterprise systems.

    What a real-time view includes

    In regulated and complex manufacturing environments, a real-time view commonly presents:

    • Current machine and line status (running, idle, down, alarm)
    • Recent production counts, yield, and scrap as they are recorded
    • Live quality checks, test results, or in-process inspection outcomes
    • Current work order progress, lot/batch status, and key timestamps
    • Environmental or process parameters, such as temperature, pressure, or humidity
    • Current alarms, deviations, and exceptions that require action

    The underlying data may come from OT systems (PLCs, SCADA, data historians), MES, LIMS, QMS, ERP, or other enterprise systems, often combined into a single operations or manufacturing intelligence layer.

    What it is not

    • It is not a static report or an exported spreadsheet that must be refreshed manually.
    • It is not necessarily “instant” in the strict technical sense; a small delay (for example, seconds to a few minutes) is typically still described as real time in operations contexts.
    • It is not the same as historical analysis views that focus on trends over long periods, even though a real-time view may also show short-term trends.

    Operational use in manufacturing

    Real-time views are used by operators, supervisors, engineers, and quality staff to monitor current production and make timely operational decisions. Examples include:

    • A line status dashboard in the control room showing each station and its current performance.
    • A quality dashboard highlighting current nonconformances or open holds for the active shift.
    • An MES work center screen showing which orders are running now and their live completion percentages.

    In regulated environments, real-time views are often used alongside controlled records and audit trails, but they are not themselves a substitute for formally approved batch records or quality documentation.

    Common confusion

    • Real-time view vs. real-time control: A real-time view displays current data; real-time control involves automated decision and response loops. Many operations use real-time views for human decision-making without fully automated control.
    • Real-time view vs. dashboard: A dashboard may show static or periodically refreshed data. A real-time view is a dashboard or screen specifically designed and configured to update continuously with current data.
    • Real-time view vs. report: Reports usually summarize completed activity over a time period. Real-time views emphasize what is happening now, even if they also show recent history for context.

    Relation to other systems and standards

    Real-time views often sit on top of ISA-95 style architectures that separate control systems, MES, and enterprise systems. They consume data from these layers and present it in a consolidated, human-readable form, supporting shop-floor visibility, operational performance tracking, and, in some cases, evidence gathering for audits and investigations.

  • Do I need new software to adopt ISO 22400 KPI definitions?

    You usually do not need new software to adopt ISO 22400 KPI definitions. In most regulated manufacturing environments, the critical work is in data modeling, integration, and governance, not in replacing tools.

    What ISO 22400 requires in practice

    Adopting ISO 22400 is primarily about standardizing how you define and calculate KPIs such as OEE, availability, performance, and quality rate. That means you need to:

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

    • Map existing metrics and naming conventions to ISO 22400 terms and structures.
    • Standardize KPI formulas and calculation rules across lines, plants, and systems.
    • Ensure your source data (events, counts, time states) is complete, time-synchronized, and traceable.
    • Document and control the calculation logic under your change control and validation processes.

    All of this can usually be done on top of existing MES, historians, SCADA, data warehouses, and BI tools.

    When you probably do not need new software

    You can typically implement ISO 22400 with your current stack if:

    • Your MES or historian can record core production events (start/stop, order, equipment state, counts, scrap).
    • You have some form of analytics or reporting layer (BI, data warehouse, MES reports) that lets you define calculations.
    • You can configure or script KPI logic without breaking validated functions or vendor support terms.
    • You can place KPI definitions and changes under formal configuration management and, where required, validation.

    In these cases, adopting ISO 22400 is mostly an internal project: aligning definitions, updating reports, retraining users, and adjusting interfaces and documentation.

    When you might need new or upgraded components

    New software or modules may be justified if one or more of the following are true:

    • Data is missing or incomplete: Your current systems cannot capture the necessary time states, counts, or contextual data at the required granularity.
    • Rigid or opaque KPI logic: KPI formulas are hard-coded in a vendor module that you cannot reconfigure without a major upgrade or revalidation effort.
    • Poor interoperability: You cannot reliably integrate data from multiple plants, lines, or systems into a common KPI model.
    • Weak governance and traceability: Existing tools do not adequately support versioning of KPI logic, audit trails, or documentation that your quality and validation teams require.

    Even then, wholesale system replacement is usually high risk in regulated, long-lifecycle environments. It often triggers extensive revalidation, complicated cutover plans, and integration work that can stall or fail. In many cases, a lighter approach is more realistic:

    • Add a data integration or analytics layer that can implement ISO 22400 definitions on top of existing systems.
    • Extend current MES or historian via configurable modules, not full replacement.
    • Use pilot areas to prove the model and integration before any broader rollout.

    Key dependencies and constraints

    Whether you need new software depends on your specific environment:

    • System configuration: Some MES products support flexible KPI modeling; others require vendor involvement for changes.
    • Process maturity: Plants with disciplined data governance and clear equipment state models can adopt ISO 22400 faster with existing tools.
    • Integration quality: If each line or plant has a different way of logging events or downtime, harmonizing to ISO 22400 may require integration and normalization work.
    • Regulatory expectations: In highly regulated environments, even report logic changes may require formal impact assessment, documentation, and possibly validation.

    Pragmatic adoption path without major new software

    A common path in brownfield environments looks like this:

    1. Baseline: Catalog existing KPIs, data sources, and calculation logic for a few representative lines.
    2. Map to ISO 22400: Align current metrics to ISO 22400 definitions and identify gaps in data or logic.
    3. Prototype: Implement ISO 22400-compliant KPIs in your existing reporting or analytics layer for a pilot area.
    4. Validate and document: Put KPI formulas, data mappings, and test evidence under configuration and change control.
    5. Scale selectively: Roll out to additional lines/plants, addressing data collection or tooling gaps case by case.

    This approach respects existing validated systems and minimizes downtime, while still moving you toward standardized performance metrics.

    If you are in a heavily regulated, long-lifecycle environment

    Be cautious about full replacement strategies justified only by ISO 22400 adoption. Replacing a MES or historian solely to standardize KPIs typically:

    • Introduces substantial qualification and validation burden.
    • Creates downtime and cutover risks for production.
    • Requires re-implementing integrations to ERP, QMS, PLM, and other systems.
    • Can disrupt established traceability, audit trails, and change histories.

    In most cases, it is more realistic to treat ISO 22400 as a data and governance initiative layered onto current systems, only adding or upgrading components where clear gaps exist.

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

    ISO 22400 does not prescribe a single, mandatory reporting level for KPIs. Instead, it defines standard KPI concepts, structures, and relationships that you can apply across different organizational levels. In regulated, multi-plant environments, ISO 22400 KPIs are typically reported at several layers, with different audiences and decisions in mind.

    Core levels where ISO 22400 KPIs are usually reported

    Most organizations that adopt ISO 22400 in a manufacturing setting use a tiered approach:

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

    1. Equipment / cell / line level

      • Audience: Operators, line leads, maintenance.
      • Typical KPIs: Equipment availability, microstops, cycle time, NPT, OEE components, alarms, changeover time.
      • Purpose: Real-time control, troubleshooting, short-interval control, and root cause capture.
      • System reality: Often sourced directly from MES/SCADA/PLC and may not match ERP-level quantities without good integration and reconciliation rules.
    2. Work center / value stream / area level

      • Audience: Supervisors, process engineers, industrial engineering, maintenance planners.
      • Typical KPIs: Area OEE, throughput, WIP, rework rate, first pass yield, schedule adherence for the line or cell cluster.
      • Purpose: Bottleneck identification, staffing and changeover planning, cross-shift comparison, continuous improvement.
      • System reality: This is where MES, LIMS, QMS and manual logs often need to be reconciled; data models and time-bucketing rules matter.
    3. Plant / site level

      • Audience: Plant management, operations excellence, quality leadership, plant IT/OT.
      • Typical KPIs: Aggregated OEE, capacity utilization, on-time delivery versus plan, scrap and rework cost, customer escape rate, deviation volume, energy per unit.
      • Purpose: S&OP alignment, capital planning, labor planning, CI program tracking, risk and resilience discussions.
      • System reality: Requires consistent KPI definitions across areas and a governed interface between MES, ERP, QMS, and maintenance systems. Without this, plant-level KPIs are not trusted.
    4. Business unit / corporate level

      • Audience: Executive operations leadership, finance, program leadership.
      • Typical KPIs: Aggregated OEE or capacity indices, COPQ, OTIF, backlog risk, major program adherence, site comparison indices.
      • Purpose: Portfolio decisions, investment prioritization, risk assessments, cross-plant benchmarking.
      • System reality: Best handled through a data warehouse or analytics layer that can harmonize ISO 22400-based metrics from multiple, heterogeneous MES and ERP systems.

    How ISO 22400 helps across levels

    ISO 22400 is most valuable when you use it to standardize definitions and calculation logic across levels, rather than trying to force the same dashboard everywhere. For example:

    • OEE and its components (availability, performance, quality) use the same formulas at equipment, area, and plant levels, but with different aggregation windows and audiences.
    • NPT, downtime categories, and loss models are defined once, then applied consistently across lines and sites, improving comparability.
    • Traceability to source events (e.g., specific machines, orders, deviations) supports root cause analysis and regulated evidence requirements.

    The key is that while the calculation is standardized, the granularity and consumption are tailored to each level.

    Constraints and dependencies in brownfield environments

    In mixed-vendor, legacy environments, how far you can push ISO 22400 across levels depends on:

    • Data completeness and resolution: If some equipment lacks reliable run/stop or quality signals, line-level OEE will be uneven and plant-level rollups misleading.
    • Integration quality: Misaligned work order, routing, and time-bucket logic between MES, ERP, and QMS will produce conflicting KPIs at different levels.
    • Validation and change control: In regulated plants, changing KPI calculations or data sources may trigger revalidation, SOP updates, and retraining. This slows down “big bang” KPI redesigns.
    • Long equipment lifecycles: Older assets may never produce all the signals envisioned by ISO 22400. You may need proxies, manual classifications, or partial adoption.

    Because of these realities, full replacement of existing KPI frameworks with a pure ISO 22400 implementation rarely happens in one step. Most sites layer ISO 22400 concepts on top of existing systems and then converge definitions over time.

    Practical guidance: deciding which levels to start with

    When introducing or formalizing ISO 22400 KPIs, many regulated manufacturers follow a staged approach:

    • Start at equipment/line and work center level where operators and supervisors can act on short-interval metrics.
    • Stabilize definitions and governance for a small number of KPIs (for example, OEE, NPT, scrap rate) and validate them against existing reports.
    • Then extend to plant-level aggregation, ensuring that rollup logic is documented, version-controlled, and tested against historical data.
    • Only after plant-level adoption should you standardize corporate-level KPIs for cross-site comparison, to avoid driving decisions on noisy or inconsistent data.

    The question is therefore less “which single level” and more “which <strongcombination of levels” you can support with trustworthy, traceable data today, while planning for broader coverage later.

    Tradeoffs in reporting at multiple levels

    Reporting ISO 22400 KPIs across many levels introduces clear tradeoffs:

    • More levels: Better local decision-making and traceability, but higher burden on integration, master data, and governance.
    • Fewer levels: Easier to manage and validate, but weaker linkage between corporate metrics and shop-floor reality, and limited root cause capability.
    • Highly standardized KPIs: Strong comparability across lines and sites, but may require compromises for special processes or legacy equipment.
    • Locally customized KPIs: Better local fit, but weak cross-plant benchmarking and more confusion at senior levels.

    For regulated operations, a typical compromise is to standardize a small set of ISO 22400 KPIs end-to-end (equipment to corporate), while allowing additional local KPIs for specific technologies, programs, or customers.

  • Raw Signal

    Raw signal commonly refers to unprocessed data or measurements captured directly from sensors, instruments, or equipment, before any filtering, scaling, aggregation, or interpretation has been applied.

    What a raw signal includes

    In industrial and manufacturing environments, raw signals typically include:

    • Analog readings from field devices, such as temperature, pressure, vibration, or flow sensors
    • Digital states from equipment, such as on/off, open/closed, or fault bits
    • Electrical waveforms or time-series data captured by PLCs, data historians, or condition monitoring systems
    • Unprocessed network or protocol frames captured from OT or industrial communication buses

    The raw signal is usually stored as-is, using engineering units or device counts (for example, voltage levels, ADC counts, or raw integer register values), depending on the source device and interface.

    What a raw signal is not

    A raw signal is not:

    • A calibrated, scaled, or validated measurement (for example, a temperature value adjusted for sensor drift)
    • A derived metric or KPI, such as OEE, cycle time, or scrap rate
    • A summarized or aggregated value, such as hourly averages or batch totals
    • A contextualized event record, such as a quality deviation or maintenance work order

    Operational use in manufacturing systems

    Raw signals are the starting point for many OT and IT workflows, including:

    • Real-time control in PLCs and DCS, which read raw sensor values to make control decisions
    • Condition monitoring and predictive maintenance, where vibration or current signals are analyzed for anomalies
    • Data collection in historians and IIoT platforms, storing raw time-series data for later analysis
    • Transformation layers feeding MES, quality, and ERP systems, where raw signals are converted into counts, states, or events aligned with ISA-95 style models

    In regulated or high-compliance environments, retaining or being able to reconstruct the raw signal can be important for traceability, investigations, and independent verification of derived values or decisions.

    Processing and transformation

    Raw signals often go through one or more processing steps before they are used in operations, reporting, or compliance records:

    • Filtering and cleaning: Removing noise, invalid readings, or communication artifacts
    • Scaling and calibration: Converting counts or voltages into engineering units with calibration factors
    • Feature extraction: Turning high-frequency signals into features like peaks, RMS, or frequencies
    • Contextualization: Linking processed values to equipment, products, batches, operators, and time windows

    After these steps, the signal is no longer considered raw; it becomes processed data or derived information used by MES, quality systems, or analytics tools.

    Common confusion

    • Raw signal vs raw data: Raw signal is often used when the data directly reflects a physical measurement or real-time equipment state. Raw data can be broader and may include unstructured logs, files, or text not tied to a specific physical sensor.
    • Raw signal vs event: A raw signal is continuous or sampled data over time. An event is typically a discrete occurrence derived from the signal, such as a limit exceeded, a machine start, or a fault code logged.
    • Raw signal vs KPI: KPIs (such as OEE or yield) are calculated metrics built from multiple processed data points. They never refer to raw signal values.

  • Custom KPI

    A custom KPI is a performance indicator that an organization defines and configures for its own specific objectives, instead of using only standard, pre-defined metrics such as OEE or throughput. It is typically implemented in reporting, MES, OT dashboards, or business intelligence tools to track performance against locally relevant goals.

    In industrial and regulated manufacturing environments, custom KPIs often combine data from production equipment, MES, quality systems, ERP, or maintenance systems. They are usually parameterized in a configuration layer, not hard-coded in software, so that operations, engineering, or quality teams can adjust definitions as processes and requirements change.

    Typical characteristics

    • Organization-specific definition: Based on the site, product family, process, or regulatory context, rather than a generic industry formula.
    • Explicit calculation logic: A clearly defined formula or rule set (for example, a weighted score of scrap, deviations, and rework hours).
    • Defined data sources: Input data fields and systems are specified, such as MES production records, LIMS results, or ERP order data.
    • Governed ownership: A responsible function (operations, quality, engineering, or finance) owns the definition, thresholds, and update process.
    • Configured in tools: Implemented in dashboards, reports, or KPI engines where users can filter by line, product, shift, or batch.

    Examples in manufacturing

    • A batch-release timeliness index that combines laboratory lead time, QA review duration, and documentation cycle time.
    • A supplier performance KPI that weights on-time delivery, incoming defect rate, and response time to nonconformances.
    • A line stability KPI calculated from unplanned stoppages, minor stops, and speed-loss events captured by OT systems.
    • A training effectiveness KPI linking operator qualification status to first-pass yield on a regulated process.

    Operational considerations

    • Traceability of definition: Documenting the formula, thresholds, and change history is important in regulated environments.
    • Data quality: Custom KPIs are sensitive to missing, delayed, or inconsistent source data from MES, ERP, historians, or QMS.
    • Alignment with standard metrics: Custom KPIs often supplement, not replace, standard measures such as OEE, NPT, or COPQ.
    • System integration: Calculation may require integration across OT data sources, MES, and enterprise reporting platforms.

    Common confusion

    • Custom KPI vs. standard KPI: A standard KPI uses widely accepted formulas (for example, OEE). A custom KPI is defined locally, even if it reuses some standard components.
    • Custom KPI vs. raw metric: A raw metric is a direct measurement (for example, “number of batches”). A custom KPI usually combines or normalizes multiple metrics into a single indicator.
    • Custom KPI vs. alert or rule: An alert is a system response (for example, a notification when a limit is exceeded). The custom KPI is the underlying measured value that may drive that alert.

  • Busy Time

    Busy time commonly refers to the period during which a manufacturing resource is actively performing assigned work. It is used in production, maintenance, and capacity analysis to distinguish productive engagement from idle, waiting, or down states.

    What busy time includes

    Depending on the context and data model, busy time typically includes:

    • Active machine processing, such as cutting, molding, filling, or testing parts or batches.
    • Setup and changeover work that is planned and required to support production runs.
    • Direct operator work, such as assembly, inspection, adjustment, or supervised automated runs.
    • Planned maintenance work when the tracked resource is a maintenance team or technician.

    Busy time is usually measured at the level of a specific resource, such as a machine, production line, workstation, operator, or work center.

    What busy time excludes

    Busy time normally excludes:

    • Idle or waiting time, for example when a machine is ready but waiting for material, tooling, or instructions.
    • Unplanned downtime, such as breakdowns, IT/OT outages, or safety stops.
    • Planned downtime, such as scheduled breaks, shutdowns, or holidays, unless the model explicitly counts these separately.
    • Non-utilized capacity where a resource is available but not loaded with work.

    Operational use in manufacturing systems

    In industrial operations and regulated environments, busy time appears in several places:

    • MES and OT systems: Machine states (such as Running, Setup, or In Cycle) are aggregated into busy time for performance analysis.
    • OEE and utilization metrics: Busy time is a key input for calculating utilization, availability, and overall equipment effectiveness, by comparing it to total calendar or planned time.
    • Capacity planning: Planners compare historical busy time to available capacity to identify constraints, load balancing needs, or scheduling limits.
    • Labor tracking: In time and attendance or electronic batch records, operator busy time against specific orders, batches, or tasks is used for costing, traceability, and compliance documentation.

    Relationship to other time categories

    Busy time is often one of several standardized time categories, such as:

    • Available time: The period a resource is scheduled or technically able to run.
    • Busy (productive) time: Subset of available time when the resource is performing assigned work.
    • Idle or standby time: Available but not actively working.
    • Downtime: Not available due to faults, changeovers, or planned shutdowns, depending on how the model is defined.

    Exact boundaries between these categories depend on the site’s data model and standards but should be documented consistently in MES, SCADA, or reporting tools.

    Common confusion

    Busy time is sometimes confused with:

    • Utilization: Utilization is usually a percentage (busy time divided by available time). Busy time is the absolute time value itself.
    • Cycle time: Cycle time refers to the time to complete one unit or batch. Busy time is the aggregate period the resource is actively working, which may cover many cycles and tasks.
    • Run time: Some systems define run time as only in-cycle processing, while busy time may also include setup, adjustments, or inspections. The local definition should clarify whether these are the same or different.

    Typical example in a regulated plant

    On a filling line in a regulated facility, busy time might include the minutes the line is filling product, performing in-process checks, and running validated cleaning cycles. Time waiting for QA release, waiting for components, or under corrective maintenance would be tracked separately as waiting or downtime, not as busy time.