Augos Factory / Learn / Root-cause analysis
Learn · root cause analysis
Root cause analysis starts with every stop recorded.
In short
Root cause analysis (RCA) is a structured way to find the underlying reason a problem happens, so the fix stops it coming back. You define the problem, collect the facts, test the possible causes, act on the root cause and check that the fix held. The common tools are the 5 whys, the fishbone (Ishikawa) diagram and Pareto analysis. All of them depend on an accurate record of when, where and how often the problem happened.
What it is
Root cause analysis asks why until you can act
Root cause analysis is a method for finding the deepest cause of a problem that the team can still change. Fix that cause and the problem stops recurring. Fix only the symptom and it comes back, often on another shift.
Most problems have more than one root cause, at three levels. Physical causes are parts and materials. Human causes are what someone did or didn't do. Organisational causes are the rules and habits that allowed it. A good RCA reaches that third level, because that is where a fix lasts.
When to use it
When should you run a root cause analysis?
Not every stop needs one. Set your triggers in advance, so the record decides rather than the loudest voice.
A fault that keeps coming back
Repetition means the cause is still there.
The top of the Pareto
The reasons that cost the most hours in total.
A breakdown at the bottleneck
An hour lost there is an hour lost for the whole line.
A safety incident or near miss
Even when nobody was hurt. The near miss is the cheap warning.
A quality escape or complaint
A check failed as well as a process.
A fix that did not hold
The first analysis found a cause, not the root cause.
A one-off with an obvious cause needs a record, not an RCA. If it repeats, it qualifies.
The process
How to do a root cause analysis in six steps
The order matters more than the count: facts before causes, causes before actions, and a check before anyone closes the file.
Run it with the people closest to the problem: the operators and artisans on the line, the technician who answered the calls and a facilitator.
Define the problem
What happened, where, when, how often and what it cost. No causes and no blame yet.
Collect the record
Every event with its timestamp, duration, shift, product and machine. Then go and look at the machine.
List the possible causes
Use a fishbone or a change analysis before settling on one.
Find and test the root cause
Ask why until you reach something you can change. A true root cause explains when the problem happens and when it doesn't.
Act on it
Contain, correct and prevent. Each action gets an owner and a date.
Check and standardise
Measure the same way after the fix. When it holds, write it into the standard.
Know where to look
Start with your greatest loss
Before any why, pick the problem worth solving. Performance Overview splits every paid hour into its losses and ranks what each one could give back.
1
Find the biggest band
The time account sums to 100% of paid time. Rank the KPIs by Potential Gain: the largest is where to start.
2
Open its top five
Every KPI opens the stop reasons and the people behind it, largest first, with the share the top five explain.
3
See the full record
Open one reason for its stop history, month by month, then filter by operator and product in the stoppage analysis.
One line, two months, in three steps
IllustrativeOperators
Technicians
Assist rows come from maintenance calls: who evaluated, how long the line waited for a technician, and how long the repair ran or stood still. Without Assist, that time sits in one Operator Resolution figure.
Illustrative data, not a customer. Recreated screens of the Augos platform: Performance Overview, its Top 5 detail and the Planned Stoppage Analysis. Rows marked Assist need maintenance calls.
Start from the record
Pareto by hours, then why
Rank stops by hours lost, not by count. In the week shown, interruptions (short stops) were 95% of stops (3,175 of 3,334) but 38% of the hours (14.8 of 38.6).
Then look at the faults that are both frequent and long: they cost most in total. Timestamps show when each one clusters, after changeovers, at shift start or on one product, which is often half the answer.
Variation helps too. If a fault takes four minutes to clear on one shift and twenty on another, look at the method before the machine.
One week on one line
MeasuredAugos platform, Downtime Report · one anonymised line · one week in 2026 · site, products and people removed.
Run RCA on the record
From every unplanned stop to one fault in three clicks
Rank the reasons by hours, open the biggest, and repeat. At the last level, open the fault's event log: when each stop started, on which product and which shift.
One month of unplanned stops on one line
IllustrativeBreakdown is the biggest reason: 84.3 h, 65% of unplanned stop time. Breakdown and waiting make up 88%.
Show the numbers as a table
| Reason | Hours | Stops |
|---|---|---|
| Unplanned stops | 130.3 h | 415 |
| Breakdown | 84.3 h | 349 |
| Seal station | 30.8 h | 97 |
| Pouch filler | 22.0 h | 113 |
| Retort loader | 10.8 h | 35 |
| Case packer | 8.8 h | 59 |
| Checkweigher | 5.2 h | 14 |
| Outfeed conveyor | 4.0 h | 14 |
| Coder | 2.7 h | 17 |
| Waiting | 29.9 h | 29 |
| Quality | 6.5 h | 7 |
| People | 5.5 h | 7 |
| Pending | 4.1 h | 23 |
Illustrative month on demo data. Datahound Pet Foods is an illustrative plant, not a customer. Unplanned stops of 5 minutes or longer; shorter interruptions are timed but carry no reason. The same month appears as a timesheet on How it works.
In the toolbox
Step one
How to write a problem statement the team can test
A good problem statement describes the gap in facts: what, where, when, how often and what it cost. It names no cause, culprit or fix.
Add an "is and is not" line. Where could the problem happen but doesn't? The contrast often points straight at the cause.
If a line can't be filled in from the record, the first action is to start recording it.
The same problem, written two ways
Illustrative| Part | Weak | Strong |
|---|---|---|
| What | "The wrapper keeps jamming" | Film jams at the sealing jaw |
| How often | "All the time" | 14 stops this week |
| When | "Mostly nights" | 12 of 14 on night shift |
| Is | Not stated | One product on one wrapper |
| Is not | Not stated | Other products on the same wrapper |
Illustrative stop, not a customer.
Facts, not memory
Facts the team should not have to remember
A complete stop record answers the questions most RCAs stall on, before the meeting starts.
| The question | From memory | From the stop record |
|---|---|---|
| How often does it happen? | "All the time" | A count per shift, day and week |
| How long does each one take? | "A few minutes" | Every stop timed by the sensor |
| When does it happen? | "Mostly nights, I think" | Timestamp, shift, product and the operator signed in |
| What about the short ones? | Never written down | Counted and timed below your stop threshold |
| Since when? | Nobody is sure | The date it first appears, ready for change analysis |
| Did the fix hold? | An opinion | The same measure, before and after |
With Augos Factory, a count sensor times every stop and the operator gives the reason on an Augos Operator Terminal. Supervisors can reclassify a stop, and the original stays on record. How Augos Factory works ›
Worked example from the record
One fault, 18 stops: what the record already says
In one week, one anonymised line recorded 3,334 stops and lost 38.6 hours. The worst single fault repeated 18 times, for 2.6 hours: one for maintenance to fix at the root.
Before anyone meets, the record has done step one and most of step two. What it cannot say is why. That is the RCA's job, with the technicians who answered the calls in the room.
Questions to take into the room
- Do the 18 stops cluster by shift, product or time since a changeover?
- Does the time to clear it vary, and with whom?
- When did it first appear, and what changed that week?
One fault, one line, one week
MeasuredWorking: 2.6 h is 156 minutes, and 156 minutes over 18 stops is 8.7 minutes each. 2.6 h of the week's 38.6 h is 6.7%.
Augos platform, Downtime Report · one anonymised line · one week in 2026 · site, products and people removed.
The tools
Which root cause tool should you use?
| Tool | What it does | Use it when |
|---|---|---|
| Pareto analysis | Ranks causes by their total effect, usually hours lost | Choosing which problem to work on first |
| 5 whys | Asks "why" repeatedly until the answer is something you can change | One clear problem with a short causal chain |
| Fishbone (Ishikawa) | Sorts possible causes under method, machine, material, people, measurement and environment | Several possible causes, and a team to test them |
| Change analysis | Compares a period with the problem against one without it, and lists what changed | A problem that started on a date: a new supplier, product, crew or setting |
| Fault tree | Maps the combinations of events that lead to a failure | Safety-critical or complex equipment faults |
| FMEA (failure mode and effects analysis) | Rates how each step could fail, before it does | Planning a new line or product, or checking for similar risks after an RCA |
Combine them. Pareto picks the fault, a fishbone lists the candidates, change analysis narrows them and the 5 whys reaches the root.
Worked example
5 whys on a recurring jam
Check each answer against the record before you ask the next why.
Film jam at a wrapper
IllustrativeWhy did the line stop 14 times this week?
Film jammed at the sealing jaw. The record: 12 of 14 on night shift, all on one product.
Why does the film jam at the jaw?
The film wanders off the guide at speed.
Why does it wander?
The night shift runs a different film roll supplier for that product.
Why a different supplier at night?
Stores issue the oldest stock first, and the old supplier's rolls are kept for nights.
Why does that matter?
The old rolls have a wider core tolerance. Fix: issue by supplier per product, and check at least ten events after the change.
Illustrative stop, not a customer.
Actions
Corrective or preventive: which action fixes it?
An RCA ends in actions, not a report. Most need three kinds, each with an owner and a date.
"Retrain the operator" and "be more careful" rely on memory, so they fade. Stronger actions change the method, the material or the machine. Error-proofing (poka-yoke) is strongest, because the mistake can no longer happen.
Three actions on the film jam
Illustrative| Action | What it does | On the film jam |
|---|---|---|
| Containment | Protects the line and the customer now, without removing the cause | Check each roll's core before loading it on nights |
| Corrective | Removes the root cause, so this problem does not recur | Stores issue film by supplier for each product |
| Preventive | Stops the same cause appearing on other lines, products or materials | Add core tolerance to the film specification for every supplier |
Illustrative stop, not a customer.
Verification
Did the fix hold?
Decide the check before you act: the stop reason, the line and the measure, from the same record that found the problem.
Watch frequency first. Clearing a fault faster is welcome, but the root cause is gone only when the fault stops happening.
Give it enough events to tell a real change from a quiet spell. If it holds, update the work instruction, the specification and the training. If not, go back to step three.
When every stop is already recorded, the check needs no separate study.
Where RCA goes wrong
Six traps in plant RCA
Starting from memory
"It jams all the time" is not a frequency. Without times and counts, the team can't tell a daily nuisance from a weekly disaster.
Stopping at "operator error"
It is rarely the root. Ask why the error was possible: method, tooling, training or material.
Fixing the symptom
Clearing a jam faster is not fixing the jam. Check whether the fault's frequency falls, not just its duration.
Settling on one cause
Most problems have several. Stop at the first, and the others keep the fault alive.
Actions with no owner
An action without a name and a date is a wish.
No check afterwards
Without the same measure after the fix, nobody knows if it worked or for how long.
Questions
Root cause analysis, answered
What is a root cause analysis used for?
To find why a problem keeps happening, so the fix prevents it. Plants use it for repeat breakdowns, interruptions, quality escapes, safety incidents and near misses.
What are the 5 core principles of RCA?
Fix causes, not symptoms. Expect more than one cause. Ask how and why, not who. Base findings on evidence. Check that the action prevented a repeat.
What are 7 different root cause analysis techniques?
Pareto analysis, the 5 whys, the fishbone (Ishikawa) diagram, change analysis, fault tree analysis, FMEA and the scatter diagram. Most plant RCAs need only the first three or four.
What is an RCA document?
The written record of one analysis, often a one-page A3. It holds the problem statement, the evidence, the root causes, the actions with owners and dates, and the check result.
When do you stop asking why?
When the answer is something the team can change and check. Five is a guide, not a rule.
What's the difference between RCA and CAPA?
RCA finds the cause. Corrective and preventive action (CAPA) is the fix and the check that it held. RCA without CAPA is a report; CAPA without RCA is a guess.
Related
Stoppage analysis in the knowledge base › How the platform sorts planned stops, unplanned stops and interruptions, and ranks them by who can win them back.
See root cause analysis on your line.
A free Excel template with a shift log, your stop reasons and a Pareto by hours.
- Pareto by hours, not counts
- Planned and unplanned split
- Ready for your next RCA
A manufacturing specialist replies within two business hours to set a 30-minute call.