Root Cause Analysis
Root cause analysis is the stage where the record stops describing the symptom and starts explaining it. The module supports three methods; the one in force is chosen on the progress report and decides what the root cause screen expects from you.
Root causes can only be entered while the record is in the root cause & action plan stage. This is stricter than actions, which remain editable while the record waits on them.
The three methods
Standard
A free-text cause description with no imposed structure. Appropriate when the cause is genuinely obvious and documenting the reasoning would be ceremony rather than analysis.
With the standard method the analysis tree is not available — the screen accepts the cause description and nothing else.
5 Why
A chain of "why?" questions, each one asked of the previous answer, drilling from the symptom to something you can actually act on.
The batch was rejected
└─ Why? The mixing time was 4 minutes instead of 8
└─ Why? The operator started the next step early
└─ Why? The timer alarm was not audible over line noise
└─ Why? The alarm volume was reduced during a previous complaint
└─ Why? There is no change control on machine alarm settings ← actionable
The chain is entered as analysis tree items. Stop when you reach something a corrective action can change — not at a fixed count of five.
Fishbone
A cause-and-effect diagram that groups candidate causes by category. Use it when several contributing factors are plausible and you want the analysis to be visibly complete rather than a single line of reasoning.
Unlike the other two methods, a fishbone is drawn once for the whole nonconformity rather than per root cause record. Its panel sits on the nonconformity screen and shows the diagram; Edit opens the canvas over it, so whatever you had already typed on the form behind stays where it was.
The canvas splits in two. On the left, one collapsible panel per bone category, each showing how many causes it holds; on the right, the diagram those causes draw, updating as you type. Clicking a bone in the diagram opens its panel.
Causes are entered under a category rather than being tagged with one afterwards — the bone is decided by which panel you added from. A cause can in turn own sub-causes, added from the cause's own row, which the diagram draws as finer secondary lines. Two levels is enough for most analyses; the third is there when you need it. Order no decides where a cause sits along its bone.
On a phone the diagram is hidden and only the category panels are shown.
The head of the spine
The box at the head of the fish is the main root cause — what the analysis concluded, not the problem it started from. Write it from the pencil on the box itself. It is a root cause by definition, so it is confirmed automatically and needs no bone.
Confirming a cause
A cause on a bone is a candidate until someone says otherwise. The cause entry form carries Is this a root cause?; switching it on is what turns a candidate into a finding.
Confirmed causes — including confirmed sub-causes — are written into the record's root cause list when you save the canvas. Everything else stays on the drawing. This is what keeps the action screen honest: the causes offered there are the ones the team actually confirmed, not every idea raised in the session.
Removing a confirmation deletes the root cause record written from it. If that record already carries actions, the save is refused instead — the link between an action and its cause is the evidence, at close approval, that the cause was treated.
Where the bones come from
The categories are not fixed in the product. They are the top-level entries of the root cause catalogue, which ships with the classic six — Man, Machine, Method, Material, Measurement and Environment — already defined. Adding a top-level catalogue entry adds a bone; deactivating one removes it from new analyses.
The root cause definition offered on a cause is scoped to the bone it hangs from: a cause under Man can only be named by an entry beneath Man. The head of the spine is the exception — it answers the nonconformity rather than a branch, so the whole catalogue is open to it.
Linking to the root cause catalogue
Each root cause on a record can optionally reference a definition from the root cause catalogue.
This matters for reporting. A free-text cause is readable but not countable; a catalogue-linked cause lets you answer "how many nonconformities in the last year were caused by inadequate change control" without reading every record.
Write the cause in the record's own words and link the catalogue entry. The text explains this specific case; the link makes it aggregable.
Fields
- Root cause description — the cause in this record's terms.
- Root cause definition — optional link to the catalogue.
- Analysis items — the 5 Why chain, when the method requires it.
- Attachments — supporting analysis: data, photographs, test results.
The two structured methods do not share their data. A 5 Why chain is entered as analysis items on a root cause record; a fishbone is a single drawing held on the nonconformity. Changing the method on a later progress report therefore cannot reinterpret an analysis that is already written.
Viewing the analysis
On the nonconformity's view screen the root cause section adapts to the method: Standard and 5 Why show the root cause cards, and Fishbone shows the diagram read-only, with the confirmed causes ticked and the catalogue entry beside each one.
From cause to action
Root causes exist to be acted on. Each action can be linked to the specific root cause it addresses, which is what allows you to show at close approval that every identified cause was actually treated — rather than that some actions were performed.
A root cause with no linked action is a finding nobody is going to fix. Before leaving the analysis stage, check that every cause you recorded has at least one action against it.