Key takeaways
  • If your root cause is "operator error" or "lack of attention", you stopped early. Those are symptoms of a system that permitted the error.
  • 5 Whys works for linear problems with one dominant cause. Fishbone is better when several factors combine.
  • A root cause is only valid if removing it would have prevented the event, and you can test that claim.
The test of a real root cause
Would removing this have prevented it?

Apply that question to your conclusion. If the answer is "probably not, the person would still have had to remember", you have found a contributing factor, not a root cause, and the corrective action will not hold.

Running 5 Whys without fooling yourself

Start from a factual problem statement with a number and a time, not a judgement. "Line 2 stopped for 47 minutes at 04:10" is a problem statement. "Line 2 keeps having issues" is not.

  • Ask why the stated event happened, and answer with evidence you can point to rather than a theory.
  • Test each answer by reversing it: if this were not true, would the event still have occurred?
  • Stop when you reach something you can change: a procedure, a design, a schedule, a training gap, a control that did not exist.
  • Five is a guideline. Three is sometimes enough; seven is sometimes necessary.

The common failure is a chain that arrives at a person. "Why was the guard not refitted? The technician forgot." That is where most analyses stop, and it explains nothing you can fix. Keep going: why was forgetting possible, why did nothing catch it, why could the machine run without it.

When to use fishbone instead

5 Whys assumes a single chain. When a problem appears intermittently, or several conditions have to coincide, a fishbone diagram is a better tool because it forces breadth before depth.

  • Method. Is the procedure ambiguous, out of date, or different across shifts?
  • Machine. Wear, calibration, settings, a modification nobody documented.
  • Material. A new supplier, a substituted grade, storage conditions.
  • Measurement. Is the instrument right, and is the reading being taken the same way by everyone?
  • Manpower. Training, handover quality, workload at the time.
  • Environment. Temperature, humidity, lighting, noise, time of day.

Fill every branch before ranking. The value is in being forced to consider measurement and environment, which are the two most commonly skipped and the two that most often explain an intermittent fault.

Turning a cause into a corrective action that holds

  • Prefer changes that remove the possibility over changes that ask for more care. A physical interlock beats a reminder.
  • Assign one owner and one date. Actions owned by a department are owned by nobody.
  • Define how you will know it worked, and when you will check.
  • Verify at that date. An unverified corrective action is a hope.

Why analyses stop early

Usually pressure. The line is down, an answer is needed, and "operator error" is available immediately. It is worth separating the immediate fix from the analysis: restart the line, then run the analysis properly within 48 hours while the evidence and memories are fresh.

Keeping the follow-up from evaporating

Most root cause work is lost not in the analysis but in the weeks afterwards, when the corrective action sits in a spreadsheet nobody opens. Whatever you use, the action needs an owner, a date, an automatic reminder and a verification step. In RakuOps a failed check can raise the action automatically, chase it when it is overdue, and hold the verification as a step of its own.