- 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? The ‘minor stops’ concept solves this dilemma.
Stop, Small Stops or Minor Stops?
By definition, many OEE registrations have a threshold somewhere between 1 and 10 minutes, to detect a machine stop. This means: when 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’. A minor stop will not be identified with a stop-code.
Stops: Individually identified or not
This means minor stops do not pop up as individually identified stops. They are not seen 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 handle this?
The amount of minor stops can be really frightening high. Since many machines are loaded with sensors we can pull a nifty little trick. We can bring the majority of such short stops to the availability rate without bothering the operator. This is how:
Determine (minor) stops thresholds
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 e.g. 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].
Grasp the bulk of short stops in availability
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. This is relevant because the machine each time 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.
The real minor stops go into Performance
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…?
And what if the machine did not really go to a speed of zero, when it just drops back and goes up again? Your sensor may not even noticed an actual stop, yet you miss output against what was expected!
Of course you NEED to know there where a lot of such minor stops. However 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…(been there, seen it all). So let’s look at a better alternative:
Calculate the real minor stops!
4. If you know the speed the machine was set to run, and you know the time the machine was running, you 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. Simple and 100% accurate!
The machine was running 10 minutes at a set speed of 80 units/min.
We now expect an output of 10 x 80 = 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 often 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, and no single stop can be seen or identified, and yet only 78 units come out, we have to find the invisible minor stops.
- Is the set speed (that 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.
- Solve root causes instead of registering more of the same
In all the 3 stages I described here, there is an opportunity to find ‘small irregularities’. Those lead to a process which is not fully stable. make sure to understand the power of ‘Heinrichs Pyramid’ (or Burt’s Law). Then you know that whenever you solve a detail that popped up in your ‘gemba walks’ (searching for speed losses), you not only solve that detail.
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.