Minor Stops

Q: What are Minor Stops? How can we identify then?

Arno Koch •    A machine that is not running is not ‘available’, thus it is suffering an availability loss. However the question may be: when is a machine not running? If it has a 1 second hick-up, did it stop?

By definition, many OEE registrations have a threshold somewhere between 1 and 10 minutes, to detect a machine stop. If the machine stops longer than the threshold value (usually 5 minutes) the stop is considered to be an availability loss and needs to be identified: the operator assigns the stop to i.e. a failure- or an idling- code. If the stop is shorter than the threshold, it is considered to be a ‘minor stop’ and will not be identified with a stop-code.

This means minor stops do not pop up as availability losses, but they show as a speed-loss. This makes sense, because if we ask the operator to tell us the reason for each machine stop, even the very small ones, the registration-stress will become unbearable.

How to proceed?

1 Define a threshold that is small enough to see as many as possible stops in the Availability analysis, yet large enough to prevent operator stress. In doubt: 5 minutes will mostly do.

2 define a second threshold at ie 1 minute. If there is an automatic data collection, allow every stop between (in this example) 1 and 5 minutes to be gathered as a separate time category in the availability losses. When running a pareto analysis on time losses, one category will be [Small stops between 1 and 5 min].

You now created a time category that collects all kind of stops with potentially many different reasons. However: when they occur you cannot miss them. The machine really stops for a considerable time-span. If this category pops up high in your pareto you know what to do: Go to Gemba and talk to the production team; ask the operator, teamleader, technicians and for all: make your own observations. In the vast majority of the situations I investigated this gave enough input to start eliminating the right root-causes.

3 Stops smaller than the lower threshold can of course also be registered by your automated data collection system. The problem is: What do you know if the system tells you there were 7856 stops between 0,11 sec and 1 min…? Of course you NEED to know there where a lot of such minor stops, but I see no value in the precise registration of those minor stops. They can occur anywhere in the equipment and have a multitude of reasons which can impossibly all be collected automatically, do not even start trying it… So let’s look at a better alternative:

4 If we know the speed the machine was set to run, and we know the time the machine was running, we can calculate how much output could be expected during the time the machine was running at this set speed. If the actual output is less, the difference can only be explained by the presence of minor stops.


The machine was running 10 minutes at a set speed of 80 units/min.
We now expect an output of 10X80 = 800 units
If the actual output was 780 unit, we lost 20 units in minimal 1 minor stop of 15 seconds (at a set speed of 80 per min it takes 15 sec to make 20 units) and maximal 20 stops of 0,75 seconds

If the minor stops are really stops, this is visible and mostly audible if you go to the machine. Even at high speed machines like a filler in a bottling line where 700 or more bottles per minute pass by, the empty positions that represent a minor stop of 0,085 seconds (!) can be seen.

As soon as you can see what happens, you can start a Small Group Activity (‘kaizen team’) to observe the phenomena and make a root cause analysis.

Find ‘invisible minor stops’

If the machine is set to run 80 units per minute, however no single stop can be seen or identified and yet only 78 units come out, we have to find the invisible minor stops.

1 Is the set speed you read on the scale or display really the speed the machine runs? Calibrate this setting if you like to be sure.

2 If the machine is really set to 80, there are no stops and yet only 78 units come out, the only explanation can be the machine is not running at a constant speed. Due to fluctuations in friction, electricity, pressure etc. the speed incidentally goes a little down, resulting in the end in some lost cycles.

What to do?

In all the 3 stages I described here, there is an opportunity to find ‘small irregularities’ that lead to a process which is not fully stable. If you understand the power of ‘Heinrichs Pyramid’ (or Burt’s Law) you now know that whatever detail that pops up in your ‘gemba walks’ searching for speed losses, you will not only be solving that detail, but much more: you are eliminating the chance of other problems that will occur when this detail comes in conjunction with some other details, leading to a potentially bigger problem.


Do not spend too much time on trying to detect each and every minor stop. Detecting they are there is enough. This should be the signal to go at the machine and LOOK, observe, feel and hear. Any irregularity you observe is an indicator for process disturbances and should be eliminated.

Start picking the majority of minor stops as low hanging fruits by applying plain standardization of those process topics that seem to have irregular behavior.

Also see: Visualising speedlosses, including minor stops

Bookmark the permalink.

Comments are closed.