Q: We tried to measure speed losses and minor stops electronically, yet although tons of data where gathered, it was difficult to see what we needed to do. How can I visualize all speed losses, including minor stops, in a way that we can reduce them?
Arno Koch • Electronic data acquisition to detect minor stops and other speed losses, usually consumes quite some effort. And indeed, enormous amounts of data are being gathered. The typical assumption in such an IT approach is that when there is data, this will lead to information, in this case: information what to do. This is at least doubtful, as you discovered. Such systems more often lead to focus at the data, and not at the information that should lead to the needed improvement…
The question I will try to answer here is:
How to proceed with OEE to reduce speed losses?
1. First find the reduced speed losses:
1.1 Define the theoretical maximum speed of the equipment
1.2 Allow the operator to register the ‘Set Speed’; this is the speed he sets the machine to work at
1.3 The difference between the theoretical maximum speed and the set speed will result in ‘reduced speed loss’
The machine has a theoretical maximum of 100 units/min
The operator sets the machine on a set-speed of 80 units/min
Now 20 units will not be produced due to the deliberately reduced speed of the equipment.
Usual causes of “Reduced Speed Losses”
The operator will reduce the speed of his equipment when he experiences
- Quality problems
- Process disturbances
- Technical failures
- Timing problems
An experienced operator might typically tell you: “If I set the equipment to run at 80 units/min, I will have the highest output and few problems”
2. Find ‘visible minor stops’
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 with 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 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?
2.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.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 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.
2.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:
2.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 auditable 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.
3. 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.
3.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.
3.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.