Shopfloor KPI Streams — Definitions & Data Requirements

Purpose

These canonical KPI streams provide unambiguous definitions, minimal required data, calculation examples, common pitfalls, and suggested operator-screen visuals. Use them to align shopfloor teams, reduce argument over numbers, and support fast, evidence-based daily management and escalation.

Guidance for all KPIs

Before implementing: agree on time window (shift/hour/day), rounding rules, timezone, and authoritative data source (MES, SCADA, PLC log, or validated manual entry). Record data-source mappings so teams can trace every value back to raw fields.

1) OEE (Overall Equipment Effectiveness)

Definition: OEE = Availability × Performance × Quality. It measures how effectively equipment is used relative to its theoretical maximum.

Required data points:

• Planned production time (minutes)
• Unplanned downtime (minutes)
• Planned stops/turns accounted for (if excluded from planned time)
• Ideal cycle time per good part (seconds or minutes)
• Total pieces produced
• Good pieces produced

Sampling interval: 1 minute or event-driven with rollups to 5/15/60 minutes and shift/day.

Calculations (example):

1. Availability = (Planned production time − Unplanned downtime) / Planned production time
   • Example: (480 − 60) / 480 = 420/480 = 0.875 (87.5%)
2. Performance = (Total pieces × Ideal cycle time) / (Operating time)
   • Example: 8,400 pieces × 0.05 min = 420 min; Operating time = 420 min → Performance = 420/420 = 1.00 (100%)
3. Quality = Good pieces / Total pieces
   • Example: 8,190 / 8,400 = 0.975 (97.5%)
4. OEE = 0.875 × 1.00 × 0.975 = 0.853 (85.3%)

Common pitfalls: Not normalizing ideal cycle time for product mix; excluding minor stops inconsistently; using scheduled time vs. planned production time inconsistently.

Suggested operator display: Present OEE with the three component gauges (Availability, Performance, Quality) plus trend sparkline and target band. Show recent loss categories (top 3 reasons) and a one-click link to the raw event log.

MES/SCADA mapping (typical fields): planned_production_seconds, downtime_seconds (by reason), ideal_cycle_time_sec, produced_count, good_count, event_timestamps.

2) Downtime (Loss & Event Stream)

Definition: Accumulated time when equipment is unable to produce during planned production time, broken down by loss reason.

Required data points:

• Event start timestamp
• Event end timestamp
• Loss reason code (standardized list)
• Is planned or unplanned (boolean)
• Affected asset/line/shift

Sampling interval: event-driven (every downtime event) with rollups to 5/15/60 minutes and shift/day.

Calculation example: Two unplanned stops: 12 min + 28 min = 40 min downtime for the shift.

Common pitfalls: Free-text reason fields, inconsistent reason taxonomy, failure to adjust events spanning shift boundaries, and not capturing whether time is chargeable to production or scheduled maintenance.

Suggested operator display: Timeline showing events along the shift clock, stacked bars by reason, cumulative downtime number, and the top 3 current / historical reasons. Include a quick ‘log reason’ action with predefined reason list and optional comment.

MES/SCADA mapping: event_id, downtime_start_ts, downtime_end_ts, downtime_reason_code, machine_id, report_source.

3) Throughput (Parts per Time)

Definition: Rate of parts completed (or batches) per defined time window. Use to monitor capacity and detect slowdowns.

Required data points:

• Part completion timestamps (or batch completion counts)
• Part identifier / SKU
• Shift or production window

Sampling interval: event-driven (each part or batch) with aggregation to minute/5/15/60 minute intervals.

Calculation example: 1,200 finished parts in an 8-hour shift → Throughput = 150 parts/hour.

Common pitfalls: Counting reworked pieces as throughput, not accounting for product mix changes, or using inconsistent part definitions (assembly vs. subcomponent).

Suggested operator display: Current rate (parts/hour) vs. target rate, 15-minute moving average sparkline, and expected vs. actual cumulative production curve for the shift.

MES/SCADA mapping: part_finished_ts, part_id, quantity_finished, production_order_id.

4) Quality (Yield, First Pass Yield, Scrap & Rework)

Definition: Measures the proportion of output meeting quality requirements without rework. Use multiple KPIs: First Pass Yield (FPY), Yield, Scrap Rate.

Required data points:

• Total inspected pieces
• Good pieces on first inspection
• Pieces reworked and inspected again
• Scrap count
• Inspection timestamp and inspector or automated inspection ID

Sampling interval: event-driven at inspection time, aggregated to shift/day.

Calculation examples:

• FPY = Good on first inspection / Total started into process
  • Example: 9,700 good first-pass out of 10,000 started → FPY = 97.0%
• Scrap rate = Scrap / Total produced
  • Example: 100 scrap / 10,000 produced = 1.0%

Common pitfalls: Failing to track rework separately (double-counting good parts), delayed inspection entries, lack of standardized defect codes, and mixing in-line automated checks with final inspection without normalization.

Suggested operator display: FPY percentage, scrap count, top defect codes (with images if possible), and a list of parts requiring rework with current status. Allow filtering by SKU and shift.

MES/SCADA mapping: inspection_ts, inspection_result_code, part_id, inspector_id, rework_flag, scrap_flag.

Implementation & Governance Tips

• Standardize and document all reason and defect code lists centrally and version them.
• Agree on authoritative sources per KPI (e.g., PLC pulse counts for throughput, MES events for downtime, inspection system for quality).
• Timestamp normalization is critical — use a consistent timezone and clearly document how cross-shift events are attributed.
• Provide drill-down links from KPI widgets to raw events so teams can immediately validate and act.
• Start with a minimal viable data set for each KPI and iterate—avoid over-instrumenting before the definitions are stable.

Operator Screen Visual Recipe (common patterns)

1. Header: Line / Asset name, shift, local time, and current target (simple text).
2. Primary KPI row: OEE big number with component mini-gauges beneath it (Availability, Performance, Quality) and green/amber/red target bands.
3. Secondary row: Throughput (rate and cumulative), Downtime (minutes and top reasons timeline), Quality (FPY and scrap count).
4. Context row: Top 3 active loss reasons (clickable), recent events (last 6), and one-click log action (downtime reason or quality defect).

Quick validation checklist

• Can each KPI be traced to specific MES/SCADA/raw data fields?
• Are reason and defect code lists standardized and version-controlled?
• Is timestamping consistent across sources and normalized in the pipeline?
• Are definitions documented and agreed by operations, maintenance, and quality owners?

Next steps

Use these canonical definitions to create a single data-contract document for each line/asset. Pilot one line, validate values against manual logs for a week, refine mappings and rounding rules, then roll out more broadly.