Operator KPI Pack: Ready-to-use Visuals for Shift Management

Purpose

This dashboard pack gives operators uncluttered, role-specific real-time displays that surface the few signals they need to act fast—stop a line, start a recovery, call a huddle—while preserving essential context for troubleshooting and continuous improvement. It includes widget templates, calculation rules, required signals, suggested thresholds, escalation guidance, layout patterns for different screen sizes, and HMI/Andon integration notes.

When to use this pack

• Small operator panels and mobile views where rapid decisions matter.
• Andon/HMI screens that must minimize false alarms and reduce unnecessary escalations.
• As a starting toolkit for plants adopting standard operator KPIs and escalation patterns.

Included widgets and templates

1. OEE Tile (compact)

   Shows OEE percentage, color band (Green/Amber/Red), and small sparklines for availability, performance, and quality.

   Calculations (per shift or running order):

   • Availability = (Planned Production Time − Downtime) / Planned Production Time
   • Performance = (Total Count) / (Ideal Cycle Time × Running Time)
   • Quality = Good Count / Total Count
   • OEE = Availability × Performance × Quality

   Required signals: planned_production_time, downtime_seconds, produced_count, good_count, ideal_cycle_time, running_time

   Sample thresholds (example — adapt locally): Green ≥ 70%, Amber 50–69%, Red < 50%. Adjust to target and product mix.

2. Current Run Rate & Cycle Time

   Displays live pieces per minute, target cycle time, and a deviation indicator (on-target / slow / fast).

   Calculations: run_rate = produced_count / elapsed_run_minutes. Show percent of target cycle: (actual_cycle_time / target_cycle_time) × 100.

   Required signals: produced_count, elapsed_run_minutes, actual_cycle_time, target_cycle_time

3. Immediate Alarms (action list)

   List of active exceptions with clear verbs (e.g., STOP: jam detected; RECOVER: splice needed). Each alarm includes one-click containment actions and required acknowledgement.

   Design rules: limit to top 3–4 active alarms; show elapsed time and assigned owner; require operator containment action before escalation.

4. Downtime Log (quick entry)

   Compact form to record downtime events with reason code, start/stop, short note, containment action, and owner. Auto-suggest common codes.

   Data captured: event_id, start_time, stop_time, reason_code, short_note, containment_action, owner_id.

5. Quality Exceptions

   Counts of defects by category, recent defect examples, immediate containment status, and first-pass yield metric.

   Calculations: first_pass_yield = good_count_after_first_pass / total_count_including_rework.

Suggested alert thresholds & escalation per widget (example)

• OEE drops into Amber: operator verifies immediate containment within 2 minutes; if unresolved in 10 minutes, notify line lead.
• OEE Red or machine stop: immediate operator action; if machine remains stopped after 2 minutes, auto-page maintenance and line lead.
• Quality exception above threshold: operator applies containment and calls QA within 5 minutes; stop order if severity high.

Example screen layouts and layout rules

Design principle: prioritize actionability and legibility. Use a single-column mobile layout and a two- or three-column small panel layout.

• Small panel (landscape): Left: OEE tile (large). Center: Current run rate + cycle time. Right: Immediate Alarms list (top) and Downtime quick-add (bottom).
• Mobile / operator handheld: Top: immediate alarms (compact list). Middle: run-rate card with large numeric readout. Bottom: quick log button for downtime/quality.
• Visual rules: one dominant numeric per panel, color only to signal state, consistent iconography, and consistent placement of acknowledgement buttons.

HMI / Andon integration notes

• Map raw machine states to normalized state codes before feeding widgets (RUN, IDLE, STOP, SETUP, MAINT).
• Debounce short transient stops (e.g., ignore stops < 5 s) to prevent alarm storms—use a configurable hold-off.
• Require operator confirmation for automatic escalations to avoid noise; log confirmations for improvement teams.
• Expose a containment-action field that can be pushed to the CMMS or ticketing system via integration.

Implementation checklist

1. Verify required signals are available and well-defined (see signal list in each widget).
2. Implement normalization layer for machine states and reason codes.
3. Deploy dashboard templates to pilot line with default thresholds; collect operator feedback for 2 shifts.
4. Tune debounce and escalation timings to local context to prevent alarm storms.
5. Train operators on containment actions, acknowledgement flow, and quick logging.

Common pitfalls & how to avoid them

• Too many KPIs: keep the operator view to the 3–5 signals they need to act.
• Unverified calculations: test each KPI against manual counts before going live.
• Inconsistent reason codes: standardize codes and provide an auto-complete code list on the downtime form.

Next steps & tailoring

Use this pack as a canonical starting point. Tailor thresholds, reason-code lists, and escalation timings to your product mix, shift patterns, and maintenance availability. Consider bundling the templates into a reusable site domain that plants can copy and adapt.