How to get operators to log downtime reasons

You get operators to classify stops by making each reason one tap at the machine, letting rules name every stop with one obvious reason, and showing operators every week what their reasons fixed. Keep the gaps small with one weekly check: unclassified hours stay below the gap between the last reason you act on and the next one, and Other stays below that last reason.

This guide is for plant managers and shift supervisors rolling out downtime tracking. It covers why the habit fades, the two targets and the method behind them, a first-week script, and when to change the reason list.

Why do operators stop classifying stops?#

Operators stop classifying when a reason costs them more than it returns. Four causes account for most of the decay, and each leaves its own mark in the data, so you can tell which one you have before you fix it.

A stop with no reason is still downtime, as the downtime glossary entry puts it. Classifying changes what you can say about the hours, not how many there are.

Too many reasons#

A long list makes the operator search, and a searching operator picks the first plausible reason. For example, if Machine issue sits top left on a 30-reason screen and collects a third of all hand-classified stops, the list is choosing for the operator.

No screen at the machine#

A reason typed at a desk an hour later is rebuilt from memory. When the nearest terminal is 60 m away, operators save stops up and classify them in one sitting at shift end, if at all. The sign is a burst of classifications in the last 15 minutes of the shift, spread over the same two or three reasons.

Reasons used against people#

When reporting a problem can cost the reporter, people report fewer problems. OSHA's position on injury reporting is a close parallel: rate-based incentive programs are permitted as long as they are “not implemented in a manner that discourages reporting”.^[2] The same memo warns that a non-retaliation statement alone may not be enough when reporting means losing a substantial reward.^[2]

Downtime reasons behave the same way. If a supervisor reads out who logged the most Breakdown hours, next week's breakdowns turn into Waiting for maintenance or Other. The total stays the same, and the reasons drift toward codes nobody owns.

Nobody acts on them#

Operators keep classifying when they see a reason turn into a fix. Healthcare learned this with incident reporting. AHRQ's patient safety primer puts it plainly: “Failure to receive feedback after reporting an event is a commonly cited barrier to event reporting.”^[1]

The sign is a rate that holds for the first weeks, while the rollout gets attention, and then slides with no change on the floor.

How much unclassified and Other time is acceptable?#

Unclassified time is acceptable while it is too small to change which reasons you work on. Other is acceptable while it stays below the last reason on your action list. Both limits come from your own Pareto each week, not from a fixed percentage, because the question is whether the missing reasons could change the decision.

The ranking test for unclassified time#

Your action list is the set of reasons you assign owners to this week, usually the top two or three by hours. The worst case for unclassified time is that all of it belongs to the first reason off the list. If adding it there still leaves that reason below the last one on the list, the ranking holds.

Divide the allowance by stopped hours to state it as a share. The share moves with your Pareto: a week where the third and fourth reasons sit far apart tolerates more unclassified time than a week where they nearly tie.

Clearing exactly 3.5 h leaves a tie at third place, so clear a little more. When the last reason on the list and the first one off it nearly tie, the allowance shrinks toward zero. The choice between them then barely matters: put both on the list and test against the next gap down.

The ceiling for Other#

Other is classified time with no usable reason. Hold it below the last reason on your action list, because once Other outranks that reason it belongs on the list, and nobody can own it.

In the example, Other is 3.5 h against 9.5 h in third place: 5.8% of stopped time against a 15.8% ceiling. It passes, but the ceiling is a limit, not a goal. Read every Other note each week and sort it three ways:

• Fits an existing reason: the operator couldn't find it. Coach the shift, or rename the reason in the operators' own words.
• Repeats a new cause: the list is missing a reason.
• Says nothing, such as “down”: the operator is rushing. Ask at the machine what happened.

Run the first week with your supervisors#

The first week sets what operators believe the data is for. A supervisor who stands at the machine for the first stops, and says the same thing at every shift, does more than a training slide. The Lean Enterprise Institute describes the andon signal the same way: an operator's signal “summons a quick response from the team leader”.^[3]

1. Before day 1, say what the data is for

   At the start-of-shift meeting, the supervisor says it in their own words: “Every stop gets a reason so we can fix what stops you. Nobody gets ranked on this.” Then name one problem the shift already complains about, such as late material, and say the reasons will prove it.

2. Day 1, classify the first stops together

   Stand at each machine for its first stop of the shift. Let the operator pick the reason, and help only when they hesitate between two. Write down which reasons caused the hesitation.

3. Day 2, check the backlog at mid-shift

   Walk the floor halfway through the shift and ask about any stop still without a reason, at the machine, while the operator remembers. Ask what happened, not why it wasn't classified.

4. Day 3, show the first ranking

   At the start-of-shift meeting, show stopped hours by reason for the first two days. Point at one bar the operators recognize and ask what would remove it.

5. Day 4, fix one small thing

   Fix one thing the reasons showed, the same day if you can: rename a confusing reason, move the screen closer, or stage material for the job that waited. Tell the shift which stops led to it.

6. Day 5, set the weekly rhythm

   Run the ranking test on the first week, clear what is left, and put the weekly check on the calendar. From then on, the start-of-week meeting opens with one fix that came from last week's reasons.

Don't correct reasons in front of the shift. A wrong reason is a coaching point at the machine; a public correction teaches people to pick Other.

Which stops should never reach an operator?#

Every stop with one obvious reason should get it from a rule, not a person. Short pauses under a cutoff, stops at the start and end of a shift, scheduled breaks and a shift with no job all carry a reason the clock already knows. Asking an operator to confirm them adds questions and no information.

Count the adoption cost as questions per shift: the stops an operator must explain by hand. For example, a molding machine with 30 stops in a shift, 25 of them pauses under a 5-minute cutoff, asks its operator 30 questions without a rule and 5 with one. Five questions get answers. Thirty get guesses.

The rules, and the order to turn them on, are worked through in tracking every stop and its reason.

You don't need a rule for a stop with two plausible causes. A 25-minute stop on a press is a die change on Monday and a misfeed on Tuesday, so a rule would be wrong half the time. Watch what the rules hide, too: when the short-pause total climbs on one machine, those pauses have a cause worth a reason of its own.

Check the habit every week#

Four numbers, read before the downtime review, tell you whether the habit is holding and where it slipped.

Read slippage by shift and machine, never by person. A night shift with twice the unclassified hours of days has a cause: no supervisor on the floor, a screen in the wrong place, or a reason list nobody walked them through.

Then close the loop. Take the top reason to a cause and a fix in the weekly downtime review, and tell the floor which stops led to the fix.

Datwyler's injection molding plant made downtime classification part of every shift, and its story notes that “Supervisors who see their shift's numbers improve in the weekly report become advocates for the process.” Within six months the plant cut shift-changeover downtime by 50%, as Datwyler's story describes.

Classify at the machine in a tap#

IoTFlows detects every stop from a sensor on the machine, so operators only add the reason, in a tap. A tablet paired as an operator station boots straight to its machine. Operator View turns any machine page into a full-screen operator page whose All Downtime tab opens on the unclassified backlog.

Operators select a run of stops that share one cause and classify them in bulk, or split a stop that holds two reasons. A reason can require a note, so Other always arrives with one. Four automatic rules name short downtimes, shift starts and ends, and whole shifts down, and break windows cover lunch.

A wallboard on a TV can show any dashboard page to the floor, the Downtimes report included. See how the pieces fit on downtime tracking.

When should you cut or merge reasons?#

Change the reason list when operators' behavior shows it no longer fits the floor. Each signal below points at one change.

Every change costs a little habit, because operators relearn where each reason sits. Change the list at most once a month, tell each shift what changed and why, and rerun the ranking test the week after. The monthly routine for reading Other notes and retiring codes is in which downtime reason codes to log.