Equipment failure investigation process flowchart (RCFA)

What the equipment failure investigation process flowchart (rcfa) process is

An equipment failure investigation asks a different question than the repair does. The repair puts the asset back into production; the investigation finds out why it failed at all, so the same failure mode does not put it back down again in three months. The chart below follows one investigation from the failure event to a closed record: the trigger decision that decides whether this failure earns a formal investigation, the failed parts tagged and preserved before anyone repairs or scraps them, an investigation team pulling maintenance history and operating conditions, the failure mode identified, a structured cause analysis, corrective actions proposed, funded and implemented, and a monitoring period that has to pass before the record closes.

This chart starts after the asset has already been made safe, and it is not the repair procedure. Restoring the machine to service, whatever parts and labour that takes, is corrective maintenance and belongs to its own process; this one runs alongside it and can finish later. It is also not a personal injury investigation: if anyone was hurt or nearly hurt, that follows a safety incident investigation process with its own regulator-notification and interview steps, run in parallel where the two overlap. And it is not the generic quality investigation either. A root cause analysis process for a customer complaint or a nonconforming batch asks the same analytical questions, but this chart is built around an asset: a maintenance history, an asset register entry, a failure mode, and a PM programme the findings feed back into. This template, like every process here, is a starting point for you to adapt to your organisation's own procedures and any classification or reporting rules that apply to your equipment.

Three decisions carry the process, and they are the ones a repair-only procedure skips. 'Meets criteria for formal investigation?' sits with the reliability engineer, not the technician who attended the breakdown, because the decision to invest investigation hours has to be made against a threshold, not against how busy the shift was. 'Root cause confirmed by evidence?' is what stops a plausible theory becoming the recorded cause: an unproven hypothesis loops back to the analysis rather than being written up as fact. And 'Failure recurred during monitoring?' is the decision most procedures leave out entirely, closing the file the moment the action is implemented instead of after it has been shown to work. Put together, those three decisions are what separate a root cause failure analysis from a repair with a form attached to it.

What this flowchart covers

In this template

• Five swimlanes (Operations, Maintenance, Reliability engineer, Investigation team and Management) across six phases: Failure event, Screen and preserve, Investigate, Determine cause, Corrective action, and Verify and close
• A 'Meets criteria for formal investigation?' decision after the asset is made safe, so routine failures exit onto ordinary corrective repair and only the ones that clear a safety, cost, downtime or repeat-failure threshold open a full RCFA
• Evidence handled before analysis starts: the failed parts tagged and preserved, an 'Evidence sufficient to analyse?' decision with a loop back into further data collection when the maintenance history or operating conditions on file are too thin
• The analysis sequence in the Reliability engineer's lane: the failure mode identified, a structured method such as 5 whys or a fishbone run against it, and root cause separated from contributing factors before anything is written up
• A 'Root cause confirmed by evidence?' decision that only proceeds to the investigation report on a cause the evidence actually supports, otherwise looping back to revisit the hypotheses rather than recording a guess as a finding
• Funding and proof at the end: a 'Management approve and fund the actions?' decision with an interim-controls loop when budget is deferred, then implementation, a PM programme update, a monitoring period, and a 'Failure recurred during monitoring?' decision that reopens the case on a repeat

When to use this template

• You are writing or revising an RCFA procedure and need one picture of the handoffs between operations, maintenance, reliability and management
• The same failure mode keeps coming back on an asset, and repairs keep being logged without anyone establishing why the failure started
• You are deciding which failures earn a formal investigation and want the threshold decision and the routine-repair exit drawn explicitly
• Corrective actions from past investigations were agreed but never checked, and you need a monitoring step before the record can close
• An auditor, insurer or reliability review has asked how your organisation investigates equipment failures and proves the fix worked

How it works

1. Rename the lanes to your roles

   Replace Operations, Maintenance, Reliability engineer, Investigation team and Management with the functions you actually have. On a smaller site the reliability engineer role is often carried by a senior technician or the maintenance planner: merge lanes rather than drawing a handoff nobody performs.

2. Write your investigation threshold onto the first decision

   State what sends a failure into a formal RCFA rather than a routine repair: a safety consequence, a cost or downtime figure, or a repeat failure on the same asset or failure mode within a defined period. Put the actual numbers your organisation uses on the node, and review them periodically, because a threshold set once and never revisited under-triggers as production changes.

3. Set the evidence-preservation rule

   Name what gets tagged and held before repair work starts: the failed component itself, photographs of the as-found condition, and any process data around the failure time. State how long parts are held and who authorises their release, so evidence is not disposed of before the investigation team has seen it.

4. Choose your analysis methods

   Replace 'Run structured analysis' with the methods your team will actually use and when each applies: 5 whys for a single causal chain, a fishbone for a failure with several plausible categories, a fault tree where multiple conditions combine to cause it. Naming the method on the node stops the choice defaulting to whichever one the last investigator used.

5. Define what 'confirmed' means

   Set the bar behind 'Root cause confirmed by evidence?': the proposed cause has to explain the failure mode and the operating conditions found, and removing it would plausibly have prevented the failure. Name who has the authority to send a hypothesis back for more work rather than sign off a theory that only sounds right.

6. Rank your corrective action options

   Decide the order your organisation applies when proposing actions: design or specification changes first, then a procedure or PM interval change, with added training or a warning label treated as the weakest option rather than the default one. State who approves each tier and at what cost or downtime figure it needs management sign-off.

7. Set the monitoring period, then walk a closed case

   Decide how long an asset is watched after the fix before the file can close, and what counts as a recurrence versus an unrelated fault. Then take a completed investigation, ideally one where the first fix did not hold, and trace it through the chart. Any step people describe from memory that is not drawn, or drawn but skipped in practice, is the finding worth acting on before you publish it.

Frequently asked questions

What are the steps in an equipment failure investigation process?

Once the asset has been made safe, the failure is checked against the investigation threshold; failures below it go to routine corrective repair and the rest open a formal investigation. The failed parts are tagged and preserved, an investigation team is assembled, and it pulls the maintenance history and the operating conditions at the time of failure. The failure mode is identified and run through a structured method such as 5 whys or a fishbone, with an evidence check along the way that can send the team back for more data. Root cause is separated from contributing factors and, once confirmed by the evidence, written up in an investigation report. Corrective actions are proposed, ranked from a design fix down to training, and put to management for approval and funding, with interim controls covering any gap while that is agreed. The actions are implemented, the asset register and PM programme are updated, and the asset is monitored for a defined period before the investigation closes and the findings are shared.

What is the difference between an equipment failure investigation and corrective maintenance?

Corrective maintenance is the repair: diagnosing the immediate fault and restoring the asset to service, however long that takes. An equipment failure investigation is a separate, parallel process that asks why the failure happened at all, using root cause failure analysis to find the mechanism behind it rather than just the symptom that stopped the machine. A site can run both at once: the technician gets the asset back into production while the reliability engineer and investigation team work the cause in the background. Not every repair earns an investigation, which is why this chart puts a threshold decision at the front; routine, low-consequence failures are usually handled as corrective maintenance alone.

What is the difference between root cause failure analysis (RCFA) and a general root cause analysis process?

The analytical steps overlap: define the problem, gather evidence, generate and test hypotheses, confirm the cause, propose actions. RCFA is that same method applied specifically to a physical asset, which is what pulls in equipment-specific inputs a generic investigation does not have: a maintenance and failure history from the CMMS, the operating conditions logged at the time of failure, a named failure mode, and a PM programme and asset register that the findings feed back into so the fix changes how the asset is maintained going forward, not just what happened this one time. A generic RCA process for a customer complaint or a nonconforming batch asks the same questions of a process or a product rather than a machine.

How do you decide which equipment failures get a formal investigation?

Set the threshold before the failure happens, not while people are standing around the machine deciding. Typical criteria are a safety or environmental consequence, the cost or downtime the failure caused, and whether it is a repeat of the same failure mode on the same asset within a defined period. Criticality of the asset itself matters too: a failure on a single point of failure for the whole line earns a lower bar than the same fault on a redundant unit. Write the criteria down and apply them consistently, because a threshold that only gets used for the failures someone happens to remember produces an investigation record that is not representative of what is actually going wrong.

Why does this chart include a monitoring period before the investigation can close?

Because an unverified corrective action is a hypothesis, not a fix. A design change, a revised PM task or added training can look right on paper and still fail to address the actual mechanism, and the only way to know is to watch the asset for a defined period afterwards and check that the failure mode has not recurred. This template puts that check as its own decision, with a reopen path if it fails, specifically because closing the file the moment the action is implemented is the single most common way investigations end up recording a fix that never worked.