The Fault That Keeps Coming Back
Every plant has one. A fault that stops the line, gets fixed, and returns a week later. Each time it is repaired promptly and each time the repair is logged as successful. Over a year it costs more production than any single major breakdown, and nobody has ever sat down to find out why it happens.
Root cause analysis is the discipline of asking that question properly. This guide covers the two most widely used techniques, the 5 Whys and the fishbone diagram, with a worked example from a filling line, and explains how to make the findings stick.
What Root Cause Analysis Is
Root cause analysis is a structured way of working back from a problem to the underlying reason it occurred, so that the fix prevents it recurring. It rests on a distinction between three things.
The symptom is what you see: the filler stopped on a low level alarm.
The direct cause is the immediate technical reason: a valve was slow to open.
The root cause is the reason the direct cause was able to happen: usually a gap in a system, such as maintenance, design, training or documentation.
Repairs address direct causes. Root cause analysis addresses the gap. If you stop at the direct cause you will be back.
The 5 Whys
The 5 Whys is the simplest technique and the one most plants should start with. It came out of the Toyota production system. You state the problem and ask why it happened. You take the answer and ask why again, and continue until you reach a cause that, if corrected, would prevent the problem.
Five is a guide and not a rule. Some problems resolve in three steps and some take seven. The signal that you have gone far enough is that the answer describes something the organisation controls and can change.
A Worked Example From a Filling Line
A can filler has stopped on a low bowl level fault eleven times in a month. Each stop lasted between ten and forty minutes. Each time, maintenance reset the fault and the line restarted.
Why did the filler stop? The product level in the bowl fell below the minimum.
Why did the level fall? The product supply valve was slow to open when the level control called for it.
Why was the valve slow? Its pneumatic actuator was not getting enough air.
Why was it short of air? A filter on the air line to that valve was partly blocked.
Why was the filter blocked? It had never been changed. It was added during a modification three years earlier and was never put on the maintenance schedule or shown on the drawings.
The direct cause is a blocked filter, fixed in ten minutes. The root cause is that modifications to the line were not being captured in the drawings and the maintenance system. Fixing that prevents this fault and an unknown number of others. The obvious next question is what else was added in that modification.
Where the 5 Whys Falls Short
The technique follows a single chain of cause and effect. Real problems often have several contributing causes, and a 5 Whys done by one person tends to follow whichever path that person already suspected. It can also stop too early, at an answer like operator error, which is almost never a root cause. If a person made a mistake, ask why the system made that mistake easy.
For problems with more than one plausible cause, a wider tool is needed first.
The Fishbone Diagram
The fishbone diagram, also called an Ishikawa diagram after the Japanese engineer Kaoru Ishikawa, or a cause and effect diagram, is a way of laying out all the possible causes of a problem before deciding which to pursue. The problem is written at the head of the fish. Bones branch off for each category of cause, and the team adds possible causes under each.
In manufacturing the usual categories are six.
People. Training, experience, fatigue, staffing, handover between shifts.
Machine. Wear, settings, maintenance condition, design limitations, modifications.
Method. Procedures, changeover practice, cleaning routines, work instructions.
Material. Product, packaging, suppliers, batch variation.
Measurement. Sensors, calibration, inspection methods, the data itself.
Environment. Temperature, humidity, washdown, dust, lighting.
The value is breadth. A team that is convinced a fault is electrical will, when made to fill in the material bone, remember that the problem started when the label supplier changed.
Using the Two Together
The techniques complement each other. Use a fishbone to open the question up and collect every credible cause. Use evidence to rule causes in or out, since most can be eliminated quickly with data you already hold. Then run a 5 Whys on each cause that survives.
For the filler example, a fishbone might have raised air supply, valve wear, level sensor drift, a change in product viscosity and a control setting altered after a software change. Checking the air pressure at the valve would have pointed to the first within the hour.
Running a Session That Works
Pick the right problems. Root cause analysis takes time. Reserve it for faults that are expensive, repeated or dangerous. A simple trigger works well: any fault that occurs three times, any stop over a set duration and any safety incident.
Get the right people. The operator who saw it, the tradesperson who fixed it and someone who understands the control system. Three or four people is enough.
Go and look. Hold the session at the machine where possible. Assumptions made in a meeting room are often wrong.
Use evidence. Alarm histories, drive fault logs, trends, maintenance records and the failed part itself. Every why should be supported by something you can point to.
Keep blame out of it. People stop telling the truth when the exercise is about fault. The question is always what allowed this, never who did it.
Write it down. One page: the problem, the chain of causes, the evidence, the actions, an owner and a date for each.
From Cause to Corrective Action
An analysis is only as good as the action that follows. Weak actions are reminders, retraining and instructions to be more careful. Strong actions change the system: a design change that removes the failure, a maintenance task added with a frequency, a drawing corrected, a spare part stocked, a setting locked.
Then check that it worked. Set a date to review whether the fault has recurred. If it has, the root cause was not found and the analysis should be reopened without embarrassment. That is how the method is supposed to work.
Common Root Causes in Production Plants
Across many investigations the same themes recur. Modifications that were never documented. Maintenance tasks that exist on paper and are skipped under production pressure. Settings changed to work around a problem and never restored. Spare parts that are near enough but not identical. Sensors positioned where washdown or product build up defeats them. Knowledge held by one person and lost when they changed shift or left.
None of these is exotic. That is the encouraging part: most root causes are within a plant’s power to fix.
Where BevTech Fits
BevTech is a family owned engineering business in Richlands, Brisbane, with more than 25 years in beverage and FMCG manufacturing. Our industrial electricians, automation engineers and mechanical trades are often called to the faults that keep coming back, and because all three disciplines and a machine shop sit in the same business, we can follow a cause wherever it leads, from a line of PLC logic to a worn change part. We also produce the as-built drawings and documentation that stop undocumented modifications becoming next year’s mystery.
If your plant has a recurring fault that nobody has had time to get to the bottom of, use the contact form at bevtech.com.au/contact.
