Pareto of downtime causes: 80/20 is not a law, it is a starting point

A Pareto analysis turns the hundreds of lines in a downtime log into the question "what do we tackle first". The part that is misunderstood is the expectation that the 80/20 ratio will appear in every data set. It may not; what matters is the ranking, not the ratio.

1. Example log

One month of unplanned downtime in minutes, summed by cause:

• Sensor failure: 420
• Mould change: 310
• Waiting for material: 260
• Conveyor jam: 190
• Label printer: 120
• No operator: 90
• Power cut: 60
• Other: 50

Total 1,500 minutes, that is 25 hours.

2. Share and cumulative share

• Sensor failure 28.0% → cumulative 28.0%
• Mould change 20.7% → 48.7%
• Waiting for material 17.3% → 66.0%
• Conveyor jam 12.7% → 78.7%
• Label printer 8.0% → 86.7%
• No operator 6.0% → 92.7%
• Power cut 4.0% → 96.7%
• Other 3.3% → 100%

The first point to reach the 80% threshold is the fifth cause: the "vital few" are 5 causes, 62.5% of the 8 causes, 86.7% of the total. Not 80/20 but roughly 86/63. This does not mean the data is wrong; it means downtime is spread fairly evenly across causes. On such a line, fixing a single cause reduces the total by at most 28.0%.

3. How to choose the threshold

• 80% is the usual starting point, but the real constraint is how many causes you can work on. If you have capacity for three improvements this month, the first three causes (66.0%) are your list; the threshold comes afterwards.
• If there is no large gap between the first two causes (28.0% and 20.7% in the example), tackling both together is often quicker than finishing one and moving to the next, because the root cause may be shared (in the example, the sensor failure and the conveyor jam may be at the same station).
• Ranking by duration and ranking by frequency give different lists. A single 60-minute power cut and twelve 5-minute label-printer stops per shift add up to the same total but call for different fixes. The tool takes duration; for frequency, run the same log with counts.

4. Record quality distorts the result

• If "Other" comes out as the largest slice, no Pareto is done; the cause list is fixed first. "Other" should not exceed 10%.
• Three spellings of the same cause ("sensor", "Sensor failure", "sensor failure") become three lines and sink in the ranking. The tool merges case and whitespace; it cannot merge spelling differences. The cause list must be fixed and coded.
• Is the mould change unplanned or planned? If planned, it does not belong in this list; in OEE it is a planned stop. If the two are mixed in one log, both the Pareto and the OEE come out wrong.

After Pareto

Pareto says what is large, not why it is large. For the first cause, a root-cause analysis (5 whys or a fishbone); for the second, usually a measurement (is the sensor failure really the sensor, the cable, or the PLC input?). For the money side of downtime there is the unplanned downtime cost tool, for its effect on OEE the OEE calculator.

Try it with your own log

The unplanned downtime Pareto analysis processes "cause;duration" lines in your browser and lets you change the threshold; no data goes to any server. To set up the structure of your downtime log, get in touch.