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.

  • Planned downtime

    Planned downtime commonly refers to scheduled periods when production equipment, lines, utilities, or digital systems are intentionally taken out of normal operation. The downtime is known in advance and documented, typically to perform activities such as preventive maintenance, changeovers, calibration, cleaning, system upgrades, or mandated inspections.

    In industrial and regulated manufacturing environments, planned downtime is usually defined and communicated through maintenance systems (for example, CMMS/EAM), production schedules, or MES. It is distinguished from unplanned or unexpected downtime caused by failures, alarms, or process upsets.

    Operational meaning

    In day-to-day operations, planned downtime typically includes:

    • Preventive and predictive maintenance tasks on machines, tools, or facilities
    • Product changeovers, setup, and line reconfiguration
    • Calibration of instruments, test equipment, and gages
    • Cleaning, sanitation, or line clearance activities
    • Software, firmware, or infrastructure upgrades affecting OT and IT systems
    • Regulatory inspections, qualifications, or validation activities that require equipment to be idle

    Planned downtime is often represented as a specific equipment or asset state in MES, SCADA, or OEE systems, separate from states such as RUN, IDLE, or DOWN. Accurate classification affects how time is allocated in KPIs such as OEE, utilization, and non productive time. Some plants exclude certain categories of planned downtime from OEE loss analysis, while others track them explicitly for capacity planning and scheduling.

    Relationship to unplanned downtime

    Planned downtime is intentionally scheduled and approved in advance, usually with a defined start and end time. Unplanned downtime, by contrast, results from unexpected breakdowns, quality holds, material shortages, or safety events.

    Both types of downtime consume available calendar time, but they are typically analyzed differently:

    • Planned downtime is managed through scheduling, maintenance planning, and changeover optimization.
    • Unplanned downtime is managed through root cause analysis, reliability engineering, and corrective actions.

    Common confusion

    Planned downtime is sometimes confused with:

    • Idle or standby time, when equipment is available but not running due to lack of work, operators, or material. Idle is generally not considered planned downtime unless it is deliberately scheduled.
    • Scheduled breaks for operators, which may or may not be modeled as planned downtime at the equipment level, depending on the plant’s KPI and scheduling rules.

    Context from equipment state KPIs

    In systems that track equipment states such as RUN, IDLE, BLOCKED, STARVED, and DOWN, planned downtime is often treated as a separate state or as a specific reason within the DOWN category. Clear definitions, reason codes, and signal mapping help ensure that planned downtime is consistently distinguished from unplanned downtime, so KPI calculations and performance analyses are not distorted.

  • Scorecard

    A scorecard commonly refers to a structured way of summarizing performance against a defined set of measures, targets, or evaluation criteria. In manufacturing and regulated operations, it is often used to monitor how a process, supplier, production line, team, or program is performing over time.

    A scorecard is not the same as a single KPI. It brings multiple indicators together so performance can be reviewed in one place. Depending on the use case, a scorecard may include quality, delivery, cost, responsiveness, safety-related observations, training status, audit findings, downtime, yield, or other operational signals.

    How it is used in operations

    Scorecards appear in both manual and digital workflows. They may be maintained in spreadsheets, BI tools, ERP or MES reports, supplier portals, or quality systems. Common examples include supplier scorecards, departmental performance scorecards, production scorecards, and management review scorecards.

    In practice, a scorecard often includes:

    • Defined metrics or rating criteria
    • A time period such as daily, weekly, monthly, or quarterly
    • Targets, thresholds, or expected ranges
    • Actual results or ratings
    • Trend status or exceptions that need review

    Some scorecards are purely quantitative, while others combine numeric measures with qualitative assessments or review comments.

    What it includes and excludes

    A scorecard includes the presentation and evaluation of selected measures. It does not, by itself, define how the data was collected, whether the metrics are standardized across systems, or what action must be taken when results are off target.

    It is also separate from the underlying transaction records or evidence. For example, a supplier scorecard may summarize on-time delivery and defect rates, but the scorecard itself is not the purchase order history, inspection record, or nonconformance record.

    Common confusion

    Scorecard vs. dashboard: A dashboard usually emphasizes live or near-real-time visibility. A scorecard more often emphasizes evaluation against goals, thresholds, or criteria over a defined review period. In practice, some tools combine both.

    Scorecard vs. KPI: A KPI is one measure. A scorecard is a grouped set of measures or ratings.

    Scorecard vs. report: A report may present detailed data. A scorecard usually condenses that data into a summary used for review or comparison.

    Manufacturing-relevant examples

    • A supplier scorecard tracking on-time delivery, quality escapes, and response time to corrective actions
    • A production scorecard showing output, scrap, downtime, and schedule attainment by shift
    • A quality scorecard summarizing audit findings, CAPA aging, and first-pass yield

  • OTD (On-time Delivery)

    OTD (On-time Delivery) commonly refers to a performance measure showing how often a supplier, production operation, or logistics process delivers an order, job, or shipment on or before its committed due date. It is typically expressed as a percentage over a defined period.

    In manufacturing and supply chain operations, OTD is used to track schedule reliability rather than product quality, cost, or overall throughput. It applies to internal production orders, customer shipments, supplier deliveries, repair turnarounds, and other commitment-based workflows where a promised delivery date exists.

    How it is used in operations

    OTD is commonly monitored in ERP, MES, planning, shipping, and supplier management processes. For example, a manufacturer may track whether finished goods shipped to the customer by the requested date, or whether a supplier delivered material in time to support a work order release.

    The exact calculation can vary by organization. Common variations include whether early deliveries count as on time, whether partial shipments qualify, which date field is authoritative, and whether the metric is based on lines, orders, quantities, or value. Because of this, OTD should be interpreted together with the local business rule used to calculate it.

    What OTD includes and excludes

    • Includes delivery performance against a defined commitment date.

    • May include customer orders, purchase orders, production jobs, service events, or repair completions.

    • Does not by itself measure conformance, yield, cost, or completeness unless those are explicitly built into the metric definition.

    • Does not explain why a delivery was late. Root causes may come from planning, shortages, capacity constraints, rework, logistics, or data issues.

    Common confusion

    OTD is often confused with OTP (On-time Performance), OTR (On-time Release), and OEE. These are not the same. OTD focuses on meeting a delivery commitment. OEE measures equipment effectiveness. A process can have high OEE and still miss OTD if planning, materials, quality holds, or downstream constraints delay shipment.

    OTD is also sometimes confused with OTIF (On Time In Full). OTIF is narrower and usually requires both timeliness and complete fulfillment. OTD may count a delivery as on time even when the shipment is partial, depending on the local definition.

    Manufacturing example

    If a supplier is expected to deliver machined parts by Friday and the shipment arrives Friday under the agreed rule, that order may count as on time for OTD. If it arrives Monday, it would typically count as late, even if the parts meet all quality requirements.

  • OEE (Overall Equipment Effectiveness)

    OEE (Overall Equipment Effectiveness) is a manufacturing performance metric used to describe how effectively a machine, line, or other production asset is being used during planned production time. It commonly combines three factors: availability, performance, and quality.

    In practical terms, OEE is used to show the gap between actual productive output and the output that would be achieved if the process ran as planned, at the intended rate, with only good units produced. It is a measurement framework, not a machine setting, maintenance method, or quality standard.

    What OEE includes

    • Availability: whether the equipment was running when it was supposed to be running, accounting for downtime and stoppages.
    • Performance: whether the equipment ran at its expected speed or cycle rate while it was operating.
    • Quality: whether the units produced met acceptance criteria without scrap or rework being counted as good output.

    These factors are often multiplied together to produce a percentage or index for a defined asset, line, product family, shift, or reporting period.

    How it is used in operations

    OEE commonly appears in MES, SCADA, historian, or production reporting systems as a KPI for equipment and line performance. Teams may use it to review downtime losses, speed losses, and quality losses by shift, order, work center, or product. In regulated or traceable environments, the underlying data often comes from production events, machine states, counts, and quality dispositions recorded in connected systems.

    Because OEE depends on how planned production time, ideal cycle time, and good count are defined, organizations often document calculation rules so results are consistent across assets and sites.

    What OEE does not mean

    OEE does not, by itself, explain why performance was low. It is a summary metric, not a root cause analysis method. It also does not directly measure schedule adherence, labor efficiency, overall plant profitability, or asset health, although those may be analyzed alongside it.

    OEE is also not the same as utilization in the broad financial sense. A machine can show low OEE because of speed loss or quality loss even if it appears heavily used.

    Common confusion

    OEE vs utilization: utilization usually focuses on how much an asset is used over time, while OEE focuses on productive effectiveness during planned production time.

    OEE vs throughput: throughput measures output volume over time; OEE reflects losses that reduce effective output.

    OEE vs TEEP: TEEP extends the concept to all calendar time, not just planned production time.

    OEE vs maintenance metrics: measures such as MTBF or MTTR focus on reliability and repair behavior, while OEE is a broader production effectiveness metric.

  • Global KPI

    A global KPI is a key performance indicator defined at an enterprise or multi-site level so it can be measured and compared consistently across plants, lines, departments, or business units. It commonly refers to a metric with a shared definition, calculation method, scope, and reporting logic.

    In manufacturing and regulated operations, a global KPI is used to create a common view of performance across distributed operations. Examples may include on-time delivery, scrap rate, first pass yield, schedule adherence, or overall equipment effectiveness when those measures are governed with the same business rules everywhere they are reported.

    A global KPI is not just any metric that appears on an executive dashboard. The term usually implies standardization. If each site calculates the metric differently, it may be a corporate report metric, but it is not functioning as a true global KPI.

    How it shows up in operations and systems

    Global KPIs often sit above local operational measures. They may be rolled up from MES, ERP, QMS, CMMS, historian, or reporting platforms and used in enterprise dashboards, review meetings, and cross-site performance analysis.

    • At the site level: teams collect and validate source data.

    • At the enterprise level: organizations apply common definitions and aggregation rules.

    • In governance: owners typically define who can change the formula, time basis, exclusions, and data source hierarchy.

    This helps distinguish a global KPI from a local KPI, which may be useful for a single process or facility but not suitable for enterprise comparison.

    What it includes and excludes

    A global KPI commonly includes:

    • a standard metric name and definition

    • a documented formula or calculation logic

    • defined scope, such as site, line, product family, or enterprise

    • consistent time periods and units of measure

    • rules for exceptions, exclusions, and rollups

    It does not automatically include the full operational context behind performance. Supporting drill-down metrics, event data, and local process indicators are usually still needed to explain why the KPI moved.

    Common confusion

    Global KPI vs local KPI: A local KPI is optimized for a specific process, team, or asset. A global KPI is standardized for enterprise-level consistency.

    KPI vs metric: A metric is any measurable value. A KPI is a metric considered important enough to track against business or operational objectives.

    Global KPI vs benchmark: A global KPI is an internally defined measure used across the organization. A benchmark is a reference point, often external or historical, used for comparison.

    Global KPI vs OEE: OEE is a specific performance metric. It can be a global KPI only if the organization standardizes how it is calculated and interpreted across sites.

  • Quantity-based indicator

    A quantity-based indicator is a performance, quality, or risk metric that is expressed using measurable quantities such as counts, amounts, volumes, or rates. It is based on objective numerical data rather than qualitative judgments, ratings, or descriptive labels.

    In industrial and manufacturing environments, quantity-based indicators are commonly used to track how much of something is produced, consumed, or observed over a defined period, product, process, or location. They are frequently used in dashboards, scorecards, and reports for operations, quality, safety, and planning.

    Typical examples in manufacturing

    • Production and throughput: number of units produced per shift, quantity of work orders completed, pieces per hour.
    • Quality and nonconformance: number of defects per lot, quantity of scrapped parts, rework hours, nonconforming units per million (PPM).
    • Materials and inventory: on-hand quantity, quantity issued to a work order, shortage quantity, backordered units.
    • Safety and reliability: number of incidents, near misses, equipment failures, or maintenance events.

    Quantity-based indicators often feed into higher-level performance metrics, such as OEE, cost of poor quality (COPQ), or service level measures, which may combine several quantities into a single computed KPI.

    Operational use

    In OT/IT and MES/ERP contexts, quantity-based indicators are typically:

    • Recorded automatically from machines, sensors, or counters, or manually by operators and inspectors.
    • Aggregated by time period, product family, line, cell, supplier, or customer.
    • Used to trigger workflows, such as nonconformance investigations, CAPA, or capacity and material planning reviews when thresholds are exceeded.
    • Stored in data warehouses or manufacturing intelligence systems for trend analysis and reporting.

    What it is not

    • It is not a qualitative or descriptive rating such as “high/medium/low risk” or “good/fair/poor” without an underlying measurable quantity.
    • It is not limited to financial measures; it includes any metric that is countable or measurable (units, hours, events, etc.).

    Common confusion

    • Quantity-based vs. qualitative indicators: Quantity-based indicators rely on numeric values (for example, 12 defects), while qualitative indicators use categories or verbal assessments (for example, “frequent defects”).
    • Quantity-based vs. ratio/derived indicators: A basic quantity-based indicator might be a simple count of defects. A derived indicator (ratio or rate) might use that quantity in a formula, such as defects per thousand units or defect rate percentage.

    Relation to risk and safety management

    In risk and safety management for manufacturing operations, quantity-based indicators are used to monitor frequencies and magnitudes, such as the number of incidents, near misses, equipment breakdowns, or safety-critical deviations. These indicators support trend analysis and prioritization of corrective and preventive actions without themselves providing a qualitative judgment of overall risk level.

  • How can we use KPI data to prioritize procedure improvements?

    Using KPI data to prioritize procedure improvements starts with connecting metrics to specific processes and then ranking opportunities by impact and feasibility. In regulated, brownfield environments, this only works if you are honest about data quality, traceability, and validation limits.

    1. Connect KPIs to specific procedures and process steps

    Start by mapping each KPI to the procedures and work instructions it is supposed to reflect.

    In practice, this connects to operational visibility when teams need to turn the answer into repeatable execution habits.

    • For each KPI (e.g. yield, rework rate, NPT, on-time delivery), list the procedures, routings, and work instructions that influence it.
    • Use existing routing, MES, QMS, and training records to identify where in the process the KPI is most sensitive.
    • In a mixed legacy environment, this mapping may live in multiple systems; expect gaps and treat the first pass as a working hypothesis, not a validated model.

    This mapping lets you move from abstract numbers (“yield is down”) to concrete candidates (“these three inspection and setup procedures are likely contributors”).

    2. Use KPIs to localize where the problem actually is

    Once KPIs are mapped, drill down by line, product, shift, supplier, or operation where possible.

    • Compare performance by product family or routing to see which procedures correlate with poor KPIs.
    • Look for patterns across shifts or sites that point to procedure clarity or training issues rather than equipment-only issues.
    • Use NCR, CAPA, and scrap data to see which procedures appear most often as context in investigations.

    In many plants, the limiting factor is data granularity. If your MES or ERP only logs KPIs at a high level, you may have to supplement with manual Pareto analysis of NCRs, logbooks, or audit findings.

    3. Quantify impact: cost, risk, and capacity

    To prioritize procedure changes, translate KPI gaps into a common impact view.

    • Cost of Poor Quality (COPQ): Tie defect rates, rework, escapes, and concessions to direct cost where possible.
    • Risk and compliance exposure: Weigh issues linked to safety-critical characteristics, export-controlled items, or regulatory findings more heavily than minor efficiency losses.
    • Throughput and NPT: Quantify how much non-productive time or lost capacity is associated with ambiguous, outdated, or overly complex procedures.

    This does not need to be perfect finance-grade modeling. Order-of-magnitude estimates are usually enough to rank which procedures, if improved, would yield the most meaningful change in the KPIs that matter.

    4. Screen opportunities with a simple prioritization matrix

    Use a basic scoring approach that operations, quality, and engineering can align on.

    • Score each candidate procedure on dimensions such as KPI impact, regulatory risk, implementation effort, validation/qualification burden, and cross-site complexity.
    • Focus first on items with high KPI impact and low to medium effort and validation cost.
    • Defer or phase high-impact / high-burden changes (e.g. to validated test methods or critical inspection procedures) into controlled projects with formal change control.

    In aerospace-grade contexts, the validation and re-qualification cost of changing some procedures can easily outweigh gains from a marginal KPI improvement. KPI data should inform that tradeoff, not override it.

    5. Use KPIs to separate “procedure problems” from “system or design problems”

    Not every KPI issue can be solved by editing procedures. KPI data can help you decide when a written procedure is the right lever versus when you need equipment changes, design changes, or different staffing.

    • If different operators or shifts following the same procedure produce widely different KPI outcomes, suspect procedure clarity, training, or human factors.
    • If all shifts, lines, and sites show similar problems despite good adherence, the limiting factor may be tooling, design, or capacity, not the procedure wording.
    • If problems cluster around changeovers, introductions, or revisions, look at your change control and training procedures, not just the task-level instructions.

    This avoids wasting effort rewriting procedures that are not actually the bottleneck reflected in your KPIs.

    6. Make KPI-driven procedure changes traceable and reversible

    In regulated environments, every procedure improvement is a change control event, not just a document edit.

    • Document the KPI signal and analysis that justified the change (e.g. trend charts, Pareto charts, audit findings).
    • Version procedures and work instructions in QMS or document control systems with clear effective dates and training records.
    • Plan how you will re-check the KPI after the change, including what “good” looks like and over what period.
    • Be prepared to roll back or further adjust if KPIs do not move as expected or introduce new issues.

    This evidence trail matters both for internal learning and for external audits, but it depends on your existing QMS maturity and system integration quality.

    7. Close the loop: validate that procedure changes actually move the KPI

    After implementing a procedure change, you should explicitly verify its effect on the targeted KPIs.

    • Compare KPI performance before and after the change over a time window long enough to smooth normal variation.
    • Account for confounders such as new products, seasonal volume, supplier changes, or equipment downtime that may mask or mimic improvement.
    • If your data infrastructure is limited, even simple before/after plots and annotated run charts are better than relying on anecdotal feedback.

    In brownfield environments, exact attribution is often impossible. The goal is not perfect statistical proof, but reasonable confidence that the change contributed to the observed KPI movement and did not increase risk.

    8. Work within brownfield system constraints

    Using KPI data effectively typically means stitching together information from ERP, MES, QMS, and spreadsheets, often with inconsistent identifiers and time stamps.

    • Start with what you can reliably measure today (e.g. scrap by operation, NCRs by work center, NPT by category), then refine as integrations improve.
    • Be transparent about data gaps and avoid overfitting your decisions to noisy metrics.
    • Do not wait for a full system replacement; small, well-governed procedure improvements can be justified with imperfect but directionally correct KPI data.

    Full replacement of KPI infrastructure or MES just to improve procedure analytics is rarely justified in high-regulation, long-lifecycle environments due to validation and downtime costs. Incremental integration and targeted data quality fixes are usually more realistic.

    9. Practical starting pattern

    If you need a concrete way to begin using KPIs to prioritize procedure work:

    1. Select 3 to 5 critical KPIs (e.g. yield, scrap cost, NPT, escapes) and define how each is currently calculated and where the data originates.
    2. For each KPI, build a top 10 Pareto of products, operations, or work centers contributing most to the problem.
    3. Within that top 10, identify the associated procedures and work instructions, and assess their age, clarity, and known pain points from operators and audits.
    4. Score and rank these procedures using impact and change burden, then launch a small number of controlled improvements with defined KPI targets.
    5. Review KPI trends and audit feedback after implementation, and standardize the approach as part of your continuous improvement or CAPA process.

    This approach respects traceability, change control, and system coexistence constraints while still using KPI data to focus procedure improvement where it matters most.