Root cause and corrective actions

Investigating why something keeps happening, and tracking whether what you did about it worked.

Where a repeating problem is investigated, and where the actions that came out of it are followed until somebody can say whether they worked.

The screen opens on the register rather than on the investigations, because an investigation that reached a root cause changes nothing on its own. What changes something is an action, done, checked, and found afterwards to have worked.

What the header counts

Figure	Meaning
Investigations	How many are on record
Actions overdue	Actions past their due date and not done
Did not work	Actions somebody reviewed and found had not fixed the problem

The third is the one the screen exists for. An action that was completed, confirmed and then reviewed as ineffective is the register saying the investigation was wrong — and no open/closed column can express it.

Two chips sit above the tabs whenever they apply: actions reviewed and found not to have worked, and actions completed that nobody has confirmed. Both jump to the Actions tab.

Opening an investigation

An investigation is opened against an asset — usually because the same thing has gone wrong more than once. Reliability raises an Investigate recommendation when it spots one.

1. Name the asset

   The machine the investigation is about.

2. State what is being investigated

   One sentence, agreed before anybody starts. This is the problem statement and it stays at the top of the investigation.

3. Choose a method

   Five Whys — a chain. Fishbone — causes grouped by category. Fault tree — branches carrying gates. Or something else, if none of them fits how your team works.

4. Set a due date

   Optional, and worth setting. An investigation with no date is one nobody is waiting for.

Findings

The investigation screen draws the findings the way the method reads. A Five Whys is a chain of indented steps, with an And why is that? button under each one. A fishbone is one level grouped by category. A fault tree is branches.

Each finding carries:

• The statement — what you believe.
• The evidence — what makes it more than a guess.
• Root cause, if you mark it as one. More than one finding can be marked.

A finding whose evidence has been confirmed shows as evidenced. Change its evidence afterwards and it stops being evidenced, because the person who confirmed it confirmed something else.

Concluding

Write what the investigation concluded and press Conclude.

Concluding is refused unless at least one finding is marked as the root cause. The refusal comes from the server, not from the button — a conclusion with nothing behind it is an opinion.

A concluded investigation that still has actions open is flagged on the list. That is a diagnosis nobody treated.

Actions

An action belongs to an investigation, and may be attached to one finding or to the investigation as a whole. It is either corrective — fix this one — or preventive — stop it recurring.

Each action carries a description, an owner and a due date. Its effectiveness review is set ninety days after the due date unless you say otherwise, because a review dated the day the work finished asks whether a change worked before anything has had time to recur.

Standing

The register is sorted by what an action is waiting for rather than by date, so the rows that need a decision come first.

Standing	What it means
Outstanding	Not done yet, still within its date
Overdue	Not done, past its date
Awaiting verification	Completed, and nobody has confirmed it
Verified	Somebody confirmed it was done
Awaiting effectiveness review	Confirmed, and the review is now due
Effective	Reviewed, and the problem stopped
Did not work	Reviewed, and it did not
Closed	Finished with

Verifying, and reviewing

Verify records that you have seen the action done. It is deliberately a separate act from completing it.

Did it work? asks the other question, weeks later: not whether the action was carried out, which is already recorded, but whether the problem stopped. Both answers are recorded the same way, with room for a note on what has happened since. It did not is a result, not a failure to record one.

Failures

The third tab lists work orders that have been classified — what kind of failure it was, what caused it, and by what mechanism. A work order only becomes a failure when somebody says what kind of failure it was; until then the product can count downtime but can say nothing about modes.

Each row carries the failure mode, the cause, the mechanism and the severity, and is marked happened before where the same thing has occurred on that component already. That mark is worked out across the whole history rather than across the page you are looking at.

Failure modes, causes and mechanisms are three separate lists, and your organisation owns all three. A new organisation starts with a working draft of each so the first failure classified goes somewhere sensible; every entry can be renamed, added to or retired. They are edited in Administration — see administered lists.

Keeping the three axes apart is the point. Bearing seized is a mode, misalignment is a cause and fatigue is a mechanism. Collapse them into one list and you get a chart of “bearing failure” that tells nobody whether to buy a better coupling or train a fitter.

Who can do what

Reading the register follows your reliability permissions. Opening an investigation, adding findings and actions, verifying and reviewing all need permission to edit investigations — Maintenance Manager and the two administrator roles, by default. Classifying a failure is a separate and much wider permission, held by supervisors and technicians too. See roles.