Root cause analysis: 5 Whys, Ishikawa diagram, Pareto analysis
The root cause is the deepest cause whose removal stops the problem from coming back. Treating the symptom (for example sorting out defective parts) is quick but not lasting. The three most common methods complement each other well: Pareto analysis shows which problem to tackle, the Ishikawa diagram collects possible causes, and 5 Whys follows the most likely cause down to the root.
Pareto analysis: where to start?
The Pareto principle says that most of the effect (often about 80%) comes from a small share of the causes (about 20%). Sort defect types in descending order and plot the cumulative percentage. The first few bars make up most of the problem, so they deserve resources first. Besides frequency, a Pareto by cost or severity can also be useful.
Ishikawa (fishbone) diagram
The Ishikawa diagram groups possible causes into categories so the team does not stop at the first idea. In manufacturing the 6M categories are the most common: man, machine, method, material, measurement and environment (mother nature). The diagram is a brainstorming tool: the causes written on it are hypotheses that must be confirmed or ruled out with data or experiments.
5 Whys
The 5 Whys method starts from the problem and keeps asking why the previous step happened until it reaches a cause that can be fixed at system level. Five is only a guide: sometimes three questions are enough, sometimes seven are needed. A classic example is a machine stoppage:
- Why did the machine stop? A fuse blew because of an overload.
- Why was there an overload? The bearing was not lubricated enough.
- Why was it not lubricated enough? The lubrication pump was not delivering enough oil.
- Why was the pump not delivering enough? Its shaft was worn.
- Why was the shaft worn? There was no strainer, so metal chips got into the pump.
So the root cause is the missing strainer; replacing the fuse would only remove the symptom.
Tips for a good analysis
- Check every answer with facts on the shop floor (gemba), not assumptions.
- If more than one answer is true, branch the analysis.
- Look separately for the occurrence cause (why the defect was made) and the escape cause (why it was not detected).
- Do not stop at human error: ask what allowed the error to happen (for example a missing poka-yoke or an ambiguous instruction).
- Verify the root cause: once it is removed, the problem must not recur.