- \n
- 5 Whys, Ishikawa and Pareto are only as good as the stops you feed them.<\/li>\n
- Short, repetitive stops almost always escape manual logging.<\/li>\n
- The machine detects, the operator qualifies: read the Pareto by duration and by count.<\/li>\n
- Four weeks are enough to compare the declared Pareto with the measured one.<\/li>\n<\/ul>\n<\/div>\n
The 5 Whys, the Ishikawa diagram and the Pareto chart have proven themselves. When a root cause analysis goes around in circles, the method is almost never to blame. The problem is the data you feed it.<\/p>\n
The methods are not the problem<\/h2>\n
In Managing your production and identifying the root causes of your losses<\/a> (in French), R\u00e9mi Doyen, founder of Pilote Expertise, sets out the framework clearly. Managing production means spotting a gap early enough to act the same day, whereas reporting only records it a month later. To avoid treating symptoms, he combines the 5 Whys, Ishikawa and the Pareto principle, then closes the loop with PDCA.<\/p>\n
His warning sums up what is at stake: “The most expensive mistake in production is treating the visible symptom.” He also points out that a machine running all day can still show an OEE of 55%. Nearly half of the available time is then lost without anyone noticing.<\/p><\/blockquote>\n
That is where everything plays out. A loss nobody notices never shows up in any analysis.<\/p>\n
A Pareto only ranks what was reported<\/h2>\n
A downtime Pareto sorts causes by weight. It says nothing about what was never logged. Yet in most plants, downtime is logged by hand: on a shift sheet, in an Excel file or on a terminal at the end of the shift.<\/p>\n
A forty-minute breakdown always gets logged. So does a changeover. A two-minute jam, cleared by the operator without calling anyone, almost never does. Neither do forty jams in a single day.<\/p>\n
The result: the Pareto puts long, rare losses at the top, because they are the only ones it sees. Micro-stops, frequent and short, get diluted into the speed gap with no cause attached. The problem-solving team goes after April’s breakdown while the real loss repeats every hour.<\/p>\n
![\"Comparison](\"https:\/\/teeptrak.com\/wp-content\/uploads\/2026\/10\/teeptrak-backlink-a1-en.png\")
<\/figure>\nThree biases that distort root cause analysis<\/h2>\n
- \n
- The logging threshold.<\/strong> Most shop floor instructions set a minimum duration below which stops are not reported. Everything under that threshold disappears from the analysis, however much it adds up to.<\/li>\n
- The catch-all cause.<\/strong> “Miscellaneous”, “Other”, “Adjustment”: when the cause list is long or poorly designed, operators pick whatever is fastest to tick. The Pareto then shows a “Miscellaneous” bar that no 5 Whys can fix.<\/li>\n
- Logging after the fact.<\/strong> Filled in at the end of the shift, from memory, the sheet rounds off durations and lumps events together. The exact time of the stop is lost, and with it any chance of correlating it with a shift change, a new batch or a product change.<\/li>\n<\/ol>\n
None of these biases is the operators’ fault. They come from a system that asks people to produce and document at the same time.<\/p>\n
Bring downtime data up to the level of the method<\/h2>\n
The fix comes down to two principles: the machine detects, the human qualifies.<\/p>\n
- \n
- Detection is automatic.<\/strong> Every stop, even a few seconds long, is time-stamped with its start, end and duration. No more threshold, no more rounding, no more relying on memory.<\/li>\n
- Qualification stays human.<\/strong> The operator picks the cause from a short list built with them. They are the one who knows why the line stopped.<\/li>\n
- Read the Pareto twice.<\/strong> Once by cumulative duration, once by number of occurrences. Micro-stops, invisible in the first, often dominate the second.<\/li>\n<\/ul>\n
The 5 Whys and Ishikawa keep their full value. They are simply working on the right target.<\/p>\n
A four-week approach<\/h2>\n
- \n
- Week 1: measure without changing anything.<\/strong> Run automatic detection on a pilot line without changing the instructions. You get an honest picture of your stops.<\/li>\n
- Week 2: compare the two Paretos.<\/strong> Put the Pareto from the manual sheets next to the one from the measurement. The gap between them is often the best argument for launching the project.<\/li>\n
- Week 3: dig into a single cause.<\/strong> Take the most frequent cause and run it through the 5 Whys, then Ishikawa, with the shop floor team.<\/li>\n
- Week 4: act and check.<\/strong> Implement the action and track the same cause with the same measurement. The PDCA loop closes on a fact, not an impression.<\/li>\n<\/ol>\n
This is the logic TEEPTRAK follows in more than 700 plants across more than 30 countries. The module is wired into the electrical cabinet, a sensor is mounted at the edge of the line, and installation takes about an hour per machine, with no production stop and no PLC connection. At Hutchinson, OEE went from 47% to 72%.<\/p>\n
Further reading<\/h2>\n
- \n
- Managing your production and identifying the root causes of your losses<\/a>, R\u00e9mi Doyen, Pilote Expertise: the full method, from SQDCP indicators to PDCA.<\/li>\n
- Micro-stops: the invisible killer of your OEE<\/a><\/li>\n
- The 6 big losses: what your manual log doesn’t see<\/a><\/li>\n<\/ul>\n
FAQ<\/h2>\n
What is root cause analysis in manufacturing?<\/strong> It is an approach that looks for the underlying origin of a loss instead of correcting its visible effect. The most common tools are the 5 Whys, the Ishikawa diagram and the Pareto chart.<\/p>\n
Why isn’t my downtime Pareto reducing losses?<\/strong> Often because it only ranks reported stops. Short, repetitive stops, rarely logged by hand, are missing from it even though they add up to a lot.<\/p>\n
Should we stop having operators log causes manually?<\/strong> No. Stop detection and duration should be automatic, but the cause is still qualified by the operator, who knows the reality of the workstation.<\/p>\n
\nYour real OEE within days<\/div>\nModule wired in the electrical cabinet, sensor at the edge of the line, about one hour of installation per machine, no MES project and no production stop.<\/div>\n - Micro-stops: the invisible killer of your OEE<\/a><\/li>\n
- Week 2: compare the two Paretos.<\/strong> Put the Pareto from the manual sheets next to the one from the measurement. The gap between them is often the best argument for launching the project.<\/li>\n
- Qualification stays human.<\/strong> The operator picks the cause from a short list built with them. They are the one who knows why the line stopped.<\/li>\n
- The catch-all cause.<\/strong> “Miscellaneous”, “Other”, “Adjustment”: when the cause list is long or poorly designed, operators pick whatever is fastest to tick. The Pareto then shows a “Miscellaneous” bar that no 5 Whys can fix.<\/li>\n
- The logging threshold.<\/strong> Most shop floor instructions set a minimum duration below which stops are not reported. Everything under that threshold disappears from the analysis, however much it adds up to.<\/li>\n