Connect981 – Content Dev

RSC Cluster: Performance Visibility (OEE, NPT, Shift Variance)

The Performance Visibility cluster translates execution data into outcomes leadership actually cares about. It focuses on OEE, nonproductive time, downtime, and shift-to-shift variance, with an emphasis on high-mix, low-volume aerospace environments. The content clearly distinguishes meaningful metrics from vanity KPIs and explains how to calculate, interpret, and act on performance data. The goal is to help teams move from anecdotal explanations to evidence-based improvement tied directly to execution reality.

  • production visibility

    Production visibility commonly refers to how clearly and how quickly an organization can see what is happening in its manufacturing operations, from order release through execution, quality checks, and shipment. It is about having accurate, timely, and usable information on the status of work, equipment, materials, and quality on the shop floor and connected processes.

    What production visibility includes

    In industrial and regulated environments, production visibility typically covers:

    • Real-time work status: knowing which orders, lots, or serial numbers are running, waiting, or blocked at each operation or cell.
    • Material and WIP status: tracking where material is, how much work-in-process exists, and whether shortages or holds are affecting production.
    • Equipment and line performance: seeing utilization, downtime, speed, and basic performance indicators such as OEE or NPT drivers.
    • Quality status: visibility into inspections, test results, nonconformances, rework, and holds tied to specific operations or units.
    • Schedule and promise alignment: comparing actual progress to planned schedules, customer due dates, and capacity assumptions.
    • Traceability context: linking what is happening now to the related travelers, work instructions, revisions, batches, and serials.

    Production visibility is usually enabled by systems such as MES, SCADA/ICS, quality systems, and ERP, combined with data collection at machines and workstations. In regulated sectors, visibility also depends on disciplined document control, traceability, and event logging.

    What production visibility does not include

    The term generally does not refer to:

    • Detailed supply chain visibility beyond the plant or immediate suppliers, which is often discussed separately as multi-tier or supply chain visibility.
    • Purely financial visibility, such as accounting-only views of cost or margin, unless directly tied to operational performance data.
    • High-level BI dashboards only without a clear link to actual shop floor states, events, and identifiers.

    Operational meaning in manufacturing systems

    From a systems perspective, production visibility usually means that operational data is:

    • Timely: updated close to real time as operators, equipment, or sensors report events.
    • Granular: available at the level of work order, operation, batch, or serial number, not just at an aggregated shift or plant level.
    • Contextualized: linked to work instructions, revisions, part numbers, routings, and quality records so events can be understood and audited.
    • Accessible: visible to the relevant roles (operators, supervisors, planners, quality, maintenance, and management) through appropriate interfaces.

    Examples include a supervisor seeing which jobs on a line are causing non-productive time, or quality teams seeing open NCRs by operation and their impact on throughput.

    Use in regulated environments

    In regulated manufacturing, production visibility is closely tied to:

    • Traceability and genealogy of parts, assemblies, and repairs.
    • Evidence for audits, including time-stamped events, approvals, and deviations connected to specific production steps.
    • Exception management, such as early detection of nonconformance trends, scrap drivers, and process drifts.

    Here, visibility is not only about performance; it is also about being able to reconstruct what happened, where, when, and under which controlled documents or revisions.

    Common confusion

    • Production visibility vs. supply chain visibility: Production visibility focuses on internal manufacturing execution and immediate supporting processes. Supply chain visibility extends upstream and downstream across suppliers, logistics, and customers.
    • Production visibility vs. reporting: Static or delayed reports can describe what happened, but production visibility usually implies near real-time, operations-level information that reflects current conditions.
    • Production visibility vs. control: Having visibility does not automatically provide control. Control requires the ability to intervene in processes, adjust plans, or change system behavior; visibility is about seeing reliable information to support those decisions.

  • loss model

    A loss model is a structured definition of how production, quality, or capacity losses are categorized, quantified, and linked to data sources for performance measurement. In industrial operations, it provides the formal way of describing where and why potential productive time, output, or value is lost.

    Core meaning in manufacturing

    In a manufacturing context, a loss model commonly refers to:

    • A set of loss categories (for example, planned stops, unplanned downtime, speed losses, minor stops, scrap, rework, startup losses).
    • Clear rules for how events, quantities, or time are assigned to each category.
    • Mappings from those categories to data sources (such as MES events, PLC signals, lab results, or manual entries).
    • Calculation logic that shows how each loss contributes to KPIs such as OEE, availability, performance, or quality yield.

    The loss model defines the boundary between what is considered effective production time and what is considered loss. It is typically documented in KPI frameworks, manufacturing playbooks, or MES configuration specifications.

    Operational use

    Operationally, a loss model shows up in:

    • OEE and related KPIs: specifying which losses count in availability, performance, and quality, and which are excluded or treated as planned.
    • System configuration: aligning equipment states, downtime codes, and quality codes in MES/SCADA/OT systems to standardized loss buckets.
    • Reporting and analytics: providing consistent loss breakdowns across lines, products, or plants so comparisons and trend analyses are interpretable.
    • Governance: defining who can create or change loss categories and how changes are versioned and communicated in regulated environments.

    Scope and boundaries

    A loss model typically includes:

    • Losses related to equipment operation (downtime, speed loss, minor stops).
    • Losses related to quality (scrap, rework, holds) when they impact effective output.
    • Losses related to planning or logistics if they are in scope for the KPI (for example, waiting on material if defined as a stoppage code).

    It typically excludes:

    • Pure financial adjustments that are not traceable to operational events.
    • Losses outside the defined KPI scope window (for example, maintenance in a shutdown that is explicitly out of scope).

    Relation to standardized KPI frameworks

    When comparing KPIs such as OEE across plants or lines, the loss model is a critical part of the KPI framework. Two sites may report similar OEE values yet use different loss models, for example:

    • One site treats changeovers as planned time and excludes them.
    • Another site classifies changeovers as a loss within availability.

    Without a shared, documented loss model, cross-plant comparisons are often not technically equivalent, even if the KPI label is the same.

    Common confusion

    • Loss model vs. KPI formula: The KPI formula (for example, OEE = Availability × Performance × Quality) describes how high-level metrics are calculated. The loss model describes how real-world events, time, and quantities are categorized so they feed into those formulas.
    • Loss model vs. downtime codes: Downtime codes are one input to a loss model. A complete loss model goes further and defines all relevant loss categories, the mapping of codes and data sources to those categories, and the calculation rules.

  • unplanned downtime

    Unplanned downtime commonly refers to any period when equipment, a production line, or a supporting system is unexpectedly not available for its intended use, and this stop was not scheduled in advance. It typically captures failures or interruptions that occur during planned production time.

    What unplanned downtime includes

    In industrial and regulated manufacturing environments, unplanned downtime usually covers:

    • Equipment failures, such as mechanical breakdowns, electrical faults, or automation/PLC malfunctions
    • Process-related stops, for example quality holds that stop a line unexpectedly or unplanned cleaning due to contamination risk
    • IT/OT system outages, such as MES, SCADA, network, or database failures that prevent production from continuing
    • Utility interruptions, such as loss of compressed air, steam, power, or HVAC needed for compliant operation
    • Unplanned material or staffing issues that halt running operations, like sudden raw material shortages discovered mid-run or unplanned operator unavailability

    Unplanned downtime is usually recorded only within scheduled production or operation time. Time when no production is planned, such as planned shutdowns or holidays, is normally tracked separately as non-scheduled time.

    Operational use and metrics

    Unplanned downtime is a core input to operational performance metrics, especially in standards-aligned KPI models such as those based on ISO 22400 and OEE calculations. It is often used to:

    • Determine actual availability of equipment or lines
    • Identify top loss categories for maintenance and reliability programs
    • Support root cause analysis and corrective actions for recurring failures
    • Differentiate between planned stops (such as changeovers or preventive maintenance) and unscheduled production losses

    Manufacturing execution systems (MES), historians, and OT monitoring tools often capture unplanned downtime automatically from state changes, with operators assigning standardized codes (for example, breakdown, jam, fault, IT outage) for consistent reporting.

    Relationship to ISO 22400 time categories

    Within ISO 22400 style equipment time models, unplanned downtime is typically treated as a subset of time when the equipment is not producing during scheduled operation. It is separated from:

    • Operation time, when the equipment is running as intended
    • Standby or waiting time, when the equipment is available but waiting (for example, for material or orders) according to defined rules
    • Non-scheduled time, when the equipment is not planned to run at all

    The exact mapping of specific stop reasons to “unplanned downtime” versus “standby” or other categories depends on plant configuration, data sources, and agreed classification rules.

    Common confusion

    • Planned vs unplanned downtime: Planned downtime covers scheduled events like preventive maintenance, planned changeovers, or validated cleaning windows. Unplanned downtime covers unexpected interruptions during those planned production windows.
    • Unplanned downtime vs reduced speed: Unplanned downtime is a complete stop in availability. Periods where equipment runs below target speed or with minor stops that do not fully halt the line are often tracked separately as performance losses, not as unplanned downtime.

    Clear definitions and coding rules are important so that all teams categorize downtime consistently across shifts, lines, and sites.

  • Visualization layer

    The visualization layer is the part of an industrial or enterprise software stack that transforms raw or processed data into graphical views that humans can easily interpret. It typically sits on top of data sources such as MES, ERP, historians, OT systems, or data warehouses and focuses on presentation rather than storage or complex computation.

    In manufacturing and regulated environments, the visualization layer commonly includes dashboards, reports, real-time status boards, and analytic views that display information such as production status, work-in-progress, OEE, nonconformance trends, maintenance status, quality metrics, and supply chain indicators. It may be implemented through dedicated visualization tools, embedded reporting modules in MES/ERP, SCADA HMIs, or browser-based operations intelligence platforms.

    Key characteristics

    • Presentation-focused: Converts underlying data and KPIs into charts, graphs, alerts, and interactive screens, rather than performing primary control or heavy data processing.
    • Data-source agnostic: Can pull from multiple systems such as MES, ERP, QMS, LIMS, PLM, historians, and IoT platforms, often through APIs or data integration layers.
    • Role-specific views: Supports different perspectives for operators, supervisors, quality engineers, planners, and leadership, often via configurable dashboards and permissions.
    • Near real-time updates: In OT and MES contexts, often refreshes frequently so users can monitor equipment state, line performance, alarms, and exceptions.
    • Limited write-back: Some visualization layers are read-only; others allow limited interactions such as acknowledging alarms, adding comments, or triggering workflows in underlying systems.

    Operational context in manufacturing

    • On the shop floor: Andon boards, line status displays, and station-level HMIs that visualize machine state, takt time adherence, defect counts, or work instructions.
    • In quality and compliance: Dashboards for nonconformance rates, CAPA cycle times, audit findings, and inspection results, often sourced from MES, QMS, or SPC systems.
    • In planning and supply chain: Views of material availability, work order progress, shortages, and supplier on-time performance, typically fed by ERP and MES.
    • In performance management: KPI boards tracking OEE, downtime categories, throughput, and scrap, used in daily standups and continuous improvement reviews.

    Relationship to other layers

    The visualization layer is often distinguished from:

    • Data acquisition and control layers: PLCs, DCS, and low-level SCADA functions that directly interact with equipment and signals.
    • Application logic layers: MES, QMS, ERP, or workflow engines that implement business rules, sequencing, and approvals.
    • Data storage and integration layers: Databases, historians, data lakes, and integration middleware that store and move data between systems.

    In many architectures, the visualization layer consumes curated, contextualized data from these layers rather than connecting to all raw sources directly.

    Common confusion

    • Visualization layer vs. MES/QMS: An MES or QMS may include dashboards, but the system itself is not only a visualization layer. The visualization layer is specifically the presentation component, which may sit inside or outside those systems.
    • Visualization layer vs. HMI: HMIs are operator interfaces tightly coupled to specific machines or lines. A broader visualization layer often aggregates data from many assets and systems and serves multiple roles beyond local machine control.
    • Visualization layer vs. data warehouse or historian: Data warehouses and historians store and organize data; the visualization layer reads from them and renders it for human use.

    Use in regulated environments

    In regulated operations, the visualization layer is often used to monitor quality indicators, traceability coverage, backlog of reviews or approvals, and audit-relevant metrics. While it may surface compliance-related information and evidence, formal records and audit trails usually reside in underlying transactional systems and their databases, not in the visualization layer itself.

  • KPI store

    A KPI store is a centralized data layer, database, or service that is dedicated to calculating, storing, and serving key performance indicators (KPIs) in a consistent way across an organization. In industrial and manufacturing environments, it is commonly implemented as part of an operations intelligence, MES, or data platform architecture.

    Core characteristics

    A KPI store typically includes:

    • Standardized KPI definitions with agreed formulas, time bases, and filters (for example, a single definition of OEE, NPT, or yield).
    • Pre-calculated metrics at common grains such as shift, line, work center, asset, product, or work order.
    • Historical retention of KPI values for trend analysis, benchmarking, and audit support.
    • Programmatic access through APIs, queries, or analytic tools so that dashboards, reports, and MES or ERP screens all pull from the same values.
    • Data lineage and traceability that connect KPIs back to underlying event, production, quality, or transactional data.

    The KPI store may be implemented in a data warehouse, data lakehouse, time-series database, or as KPI-focused tables within an MES or historian, as long as it acts as the designated source of truth for KPI values.

    Operational usage in manufacturing

    In regulated or complex manufacturing, a KPI store commonly supports:

    • Shop-floor visibility by feeding consistent KPIs to operator boards, andon systems, and daily management reviews.
    • Management reporting on OEE, throughput, scrap, rework, schedule adherence, and other operational metrics across plants or value streams.
    • Quality and compliance monitoring through standardized defect, NCR, CAPA, and COPQ-related indicators.
    • Cross-system alignment so that MES, ERP, QMS, and BI tools all use the same KPI values and definitions, reducing reconciliation effort.

    What it is not

    A KPI store is not:

    • Raw data storage only. It is more than a simple data lake or historian; it focuses on curated, computed indicators.
    • Just a dashboard tool. Visualization tools may consume data from the KPI store but do not replace the store itself.
    • A full MES or ERP. Those systems generate events and transactional data; the KPI store organizes and standardizes metrics derived from that data.

    Common confusion

    • KPI store vs data warehouse: A data warehouse holds broad subject-area data, whereas a KPI store is scoped to standardized metrics (sometimes implemented as a layer inside the warehouse).
    • KPI store vs historian: A historian captures high-frequency time-series data from equipment; a KPI store typically uses aggregated or processed data, often including non-OT sources such as ERP and QMS.