Shopfloor Dashboard KPI Pack (OEE, Downtime, Throughput, Quality)

Purpose and how to use this pack

This pack provides canonical definitions, calculation rules, implementation recipes, visualization patterns, and governance guidelines for common shopfloor KPIs: OEE (and its components), downtime, throughput/cycle time, and quality escapes. Use it to standardize metrics across teams, avoid conflicting dashboards, and deploy displays that clearly map to who must act and what they should do.

Quick guidance

• Start by aligning owners for each KPI (data, calculation, and consumer).
• Validate one machine or line end-to-end before scaling.
• Prefer simple, actionable visuals for operators and aggregated trend/diagnostic views for supervisors.
• Use this pack’s event table schema and SQL examples as starting points—adapt to your MES/ERP/EQ event model.

Canonical OEE definitions and formulas

Quality professionals sometimes call OEE the combined measurement of Availability, Performance, and Quality. Use these canonical formulas so everyone measures the same thing.

• OEE = Availability × Performance × Quality (expressed as a percent)
• Availability = Run Time / Planned Production Time

  Where Run Time = Planned Production Time − Downtime (excluded planned breaks as defined by schedule).

• Performance = (Ideal Cycle Time × Total Pieces Produced) / Run Time

  Alternatively: (Actual Cycle Time / Ideal Cycle Time) inverted. Cap at 100% unless tracking over‑speed is intentional.

• Quality = Good Pieces / Total Pieces Produced

  Define Good Pieces and Rejects (scrap vs rework) in your quality taxonomy so counts are consistent.

Common pitfalls: mismatched time windows, ambiguous "planned time" definitions, double-counting downtime, and mixing shift vs calendar time without clear labels.

Event schema (recommended fields)

Example minimal event table (from MES / PLC event stream):

• event_id
• machine_id / line_id
• event_type (production_start, production_stop, downtime_start, downtime_end, quality_event)
• reason_code (mapped to downtime taxonomy)
• start_ts, end_ts
• total_count, good_count
• ideal_cycle_time (seconds)
• shift_id, operator_id, work_order_id

Sample SQL snippets (illustrative)

Compute downtime per reason (pseudo‑SQL):

SELECT reason_code,
       SUM(UNIX_TIMESTAMP(end_ts) - UNIX_TIMESTAMP(start_ts)) AS downtime_seconds,
       COUNT(*) AS events
FROM machine_events
WHERE event_type = 'downtime'
  AND start_ts >= :from_ts AND end_ts <= :to_ts
GROUP BY reason_code
ORDER BY downtime_seconds DESC;

Compute OEE components for a machine over a shift window (simplified):

WITH totals AS (
  SELECT machine_id,
         SUM(CASE WHEN event_type = 'production' THEN (UNIX_TIMESTAMP(end_ts)-UNIX_TIMESTAMP(start_ts)) ELSE 0 END) AS run_time_seconds,
         SUM(CASE WHEN event_type = 'downtime' THEN (UNIX_TIMESTAMP(end_ts)-UNIX_TIMESTAMP(start_ts)) ELSE 0 END) AS downtime_seconds,
         SUM(COALESCE(total_count,0)) AS total_pieces,
         SUM(COALESCE(good_count,0)) AS good_pieces,
         MAX(ideal_cycle_time) AS ideal_cycle_time
  FROM machine_events
  WHERE start_ts >= :from_ts AND end_ts <= :to_ts
  GROUP BY machine_id
)
SELECT machine_id,
       (planned_prod_time_seconds - downtime_seconds) / planned_prod_time_seconds AS availability,
       (ideal_cycle_time * total_pieces) / NULLIF(run_time_seconds,0) AS performance,
       good_pieces / NULLIF(total_pieces,0) AS quality
FROM totals;

Adapt the queries to your schema and handle nulls/divisions defensively.

Downtime taxonomy (recommended canonical categories)

1. Planned: Scheduled changeovers, planned maintenance
2. Unplanned: Equipment breakdowns (mechanical, electrical)
3. Process Stops: Jam, tooling fault, material jam
4. Setup & Changeover
5. Quality Stop: Awaiting inspection, rework/containment
6. Material Shortage / Supply
7. Operator / Staffing
8. External / Utilities (power, compressed air)

Assign each reason_code to one canonical category. Capture free-text root cause only as supplemental notes—use structured reason codes for dashboards and Pareto analyses.

Throughput & cycle-time metrics

• Throughput = Good Pieces Produced / Time Window (pieces/hour)
• Average Cycle Time = Run Time / Total Pieces (seconds per piece)

  Show both instantaneous rolling throughput (e.g., last 5 min) and shift-to-date averages.

Quality metrics and escapes

Define defect categories (critical, major, minor) and capture where escapes are found (in‑line, end‑of‑line, customer). Track escapes by defect type and by lot/work order to identify patterns.

Visualization recipes

Operator screen (single machine / cell)

• Large, single-value OEE % and component gauges with color banding.
• Current job, remaining pieces, target throughput per hour.
• Active stop banner (if stopped) with reason code, time stopped, and single-step corrective action.
• Simple trend sparkline for last hour and last shift.
• Refresh cadence: 5–30 seconds depending on cycle times.

Supervisor screen (line / plant)

• Line OEE trend (shift, day, week) and comparison to target.
• Downtime Pareto by reason and by machine.
• Throughput vs plan heatmap across lines.
• Quality escapes list (most recent) with defect type and containment status.
• Refresh cadence: 1–15 minutes depending on operational tempo.

Alert thresholds and escalation rules (examples)

Define three alert tiers and attach owners and time windows:

• Info — Visibility only. Example: OEE < target by 2% for a single 5‑minute window. Notify operator dashboard.
• Warning — Operator action required. Example: Availability < 90% for 10 consecutive minutes. Notify line supervisor after 5 minutes.
• Urgent — Escalation. Example: Unplanned downtime > 30 minutes or safety/quality stop. Notify maintenance manager + plant manager and create work order.

Include automatic suppression rules to avoid alert storms (throttle repeat alerts for the same event for a configurable cool‑down period).

Governance and validation checklist

1. Assign metric owners: data owner, calculation owner, consumer owner.
2. Document canonical definitions and publish in a central repository.
3. Validate data at source: compare MES counts vs PLC counters for a test period.
4. Run parallel reports for a pilot shift and reconcile differences.
5. Lock calculation code in version control and require review for changes.
6. Set refresh cadences and confirm acceptable latency for each screen type.
7. Schedule quarterly reviews of thresholds and dashboard usefulness with operators, supervisors, and maintenance.

Deployment checklist

• Map event fields from source systems to the event schema above.
• Implement calculation SQL or ETL transforms in a test schema.
• Validate against manual logs for at least three shifts.
• Deploy operator view for a pilot cell with supervisors in the loop.
• Adjust visuals, thresholds, and escalation rules based on feedback.
• Scale to additional lines after acceptance criteria are met.

Where this pack can go next (capability ideas)

Package the canonical definitions and queries as an adoptable toolkit that plants can copy and tailor. Consider adding an interactive KPI Builder form (to save local threshold choices, owners, and validation evidence) and a deployable alert-rule template that can be pushed into your alert engine or MES.

References & next steps

Start by testing OEE calculation on one machine for one shift. Use the governance checklist and the sample SQL above. If you want, capture pilot results and iterate thresholds with frontline users—small adjustments based on real noise levels will increase trust and adoption.