The downtime reason-code card behind a trustworthy OEE review

The first vague Other code tells me more about an OEE review than the 71% score.

A score can be calculated while the event log still mixes Other, Waiting, Changeover, and Line stop. That is enough ambiguity to send maintenance, staffing, continuous-improvement, quality, and planning conversations in different directions.

I do not use OEE to assign action until the reason-code layer explains the loss.

Problem

An OEE score compresses several operating questions into one number. For the narrow metric frame, NIST AMS 300-11 describes OEE as the product of availability, performance rate, and quality rate.

The formula does not decide whether a lunch window belongs outside planned production time, whether a changeover was planned, or whether slow running was recorded as downtime. Those are operating rules owned by the line and the teams supporting it.

The event table can also have normal volume while its reason codes are unusable. Row counts are not enough when 41 minutes of loss still sit under Other and nobody can say which action is safe.

A review needs to make the loss layer visible before the score becomes an instruction.

Default approach

I use one review card as the gate between calculation and action. It covers one line and one shift so the discussion cannot hide behind plant-wide averages or a future taxonomy cleanup.

• Treat the score as a candidate for action, not the decision itself.
• Let the card—not meeting memory—hold the classification rules, owners, clearance work, and action boundary.
• Clear the review only when each blocking signal has a usable classification and a named owner, or stays explicitly unresolved.

The thresholds in the card are examples for this review, not universal OEE rules. The line’s production and engineering owners still set the actual thresholds.

Example

This is a simplified Packaging Line 03 review scenario supplied by the source brief, not a client story or a reported plant result. I would put its observed signals and operating boundaries into one card:

Downtime reason-code review card
Line: Packaging Line 03
Shift: 2026-06-22 day shift
Production order: WO-7781
Metric affected: OEE, availability, performance, quality

Observed shift signals
- OEE: 71%
- availability loss: 96 minutes
- performance loss: 8%
- quality loss: 2.4%
- downtime coded as Other: 41 minutes
- changeover without planned/unplanned split: 28 minutes
- quality hold without defect family: 17 minutes
- micro-stops not rolled up: 62 events

Planned production time rule
- include: scheduled run time for WO-7781 after schedule-loss windows are removed
- exclude: no-order window, no-labor window, plant shutdown, approved meal break
- owner: manufacturing analytics

Schedule loss / excluded time
- examples: no production order, no labor scheduled, plant shutdown, approved meal break, no-intent-to-run window
- review rule: exclude only when there was no intent to run

Planned stops inside planned production time
- examples: scheduled changeover, sanitation, planned PM, approved trial setup
- review rule: keep planned and unplanned stops visible inside the production window

Stop classification rules
- planned stop: scheduled changeover, sanitation, preventive maintenance, approved trial setup
- unplanned stop: equipment fault, material jam, operator call, quality hold, upstream starvation
- micro-stop: stop below the line threshold; repeated events roll up by hour, zone, and fault family
- speed loss: line running below the approved standard rate without a full stop
- quality loss: scrap or rework tied to production order and defect family

Rate standard
- source: approved product-family line-rate table
- owner: manufacturing engineering / industrial engineering
- review rule: stale or missing rate blocks performance-loss interpretation

Micro-stop rule
- example threshold: stop under 3 minutes
- actual threshold owner: production + manufacturing engineering
- review rule: roll up repeated events by hour, zone, and fault family

Ambiguous code rules
- Other: fails review above the shift threshold unless an owner note exists
- Waiting: split into material unavailable, quality hold, operator unavailable, upstream starvation, or approval wait
- Changeover: label planned changeover, changeover overrun, or unplanned format recovery
- Maintenance: label planned PM, reactive repair, or maintenance handback delay
- example threshold: Other/Uncoded above 10 minutes per shift fails review
- actual threshold owner: production supervisor + CI lead

Owner boundary
- production supervisor: shift reason-code completeness
- maintenance: equipment-fault classification and repair handback notes
- quality: hold, scrap, rework, and defect-family classification
- material flow: material-starvation classification
- manufacturing engineering: standard-rate table and rate exceptions
- manufacturing analytics: OEE calculation and review note

Review result
- status: fail
- reason: 41 ambiguous minutes exceed the 10-minute example threshold; changeover, quality-hold, and micro-stop classifications remain incomplete

Clearance required
- split the 41 Other minutes into owned reason families or attach an owner note
- classify the 28 changeover minutes as planned, overrun, or unplanned recovery
- tie the 17-minute quality hold to a defect family
- roll the 62 micro-stops up by hour, zone, and fault family
- confirm the approved product-family rate source

Action boundary
- blocked: line comparison, staffing change, CI project selection, broad maintenance priority
- conditionally allowed: repeated fault-family maintenance follow-up after the fault family is confirmed

The card is the gate. The query below is only an illustrative flag for shifts that cross the example ambiguous-minutes threshold.

select
  line_id,
  shift_id,
  sum(duration_minutes) as ambiguous_downtime_minutes
from mes_line_events
where event_type = 'downtime'
  and reason_code in ('OTHER', 'UNCODED', 'WAITING_UNSPECIFIED')
group by 1, 2
having sum(duration_minutes) > 10;

This is the same separation I use when I keep domain rules visible beside coded data-quality checks: code detects the failed condition; the readable card records clearance and the action boundary. The query can flag Packaging Line 03, but it cannot clear the review.

Tradeoffs

• Breaks when: each line uses a different threshold and the review still compares their scores → Mitigation: use local thresholds for within-line control, then align the classification boundary before cross-line comparison.
• Breaks when: reason-code completion becomes a labeling exercise with no operating evidence → Mitigation: require the named owner to confirm the reason family or leave the signal unresolved.
• Breaks when: the card grows into a plant-wide governance catalog → Mitigation: keep it to one line, one shift, and the decisions in the current review; store supporting detail elsewhere.
• Breaks when: the OEE discussion asks the card to prove more than the event data can support → Mitigation: keep the affected action blocked and route the unresolved question to the maintenance, quality, production, engineering, or planning owner who can clear it.

Close

Next step: Pick one production line and complete the review card for the last shift before the next OEE discussion.

If you are drawing this boundary on a line, I am always interested in comparing the reason-code card you require before OEE turns into maintenance, staffing, CI, quality, or planning action.