FMECA: the failure catalogue your site already paid for.

Most sites have a FMECA somewhere — built for commissioning, filed, and never opened again. This guide covers what it's for, FMEA vs FMECA, and what it takes to keep one alive.

FMECA (Failure Mode, Effects and Criticality Analysis) extends FMEA by ranking every failure mode by severity and likelihood, so engineering attention goes to the failures that are both plausible and painful. It should drive the preventive-maintenance plan, spares strategy and condition-monitoring budget — and it stays accurate only while it is fed by the site's real failures.

FMEA vs FMECA

FMEA — Failure Mode and Effects Analysis — is the systematic walk through an asset asking: what parts can fail, how, and what happens when they do. FMECA adds the C: criticality analysis, ranking each failure mode by how severe it is and how often it happens, so the site knows which of the hundred possible failures deserve engineering attention this quarter.

The output is a catalogue of an asset's failure behaviour: mode, cause, effect, detection, criticality, and the mitigation in place. Built honestly, it's the single most valuable reliability document a site owns — it's the map of where the pain will come from.

What criticality buys you

Without the ranking, a failure catalogue is just a long list, and long lists get ignored. Criticality — whether scored as severity × occurrence, a full RPN including detectability, or a criticality matrix — turns the list into a priority: the handful of modes that are both plausible and painful. That's what should drive the preventive maintenance plan, the spares strategy, and the condition-monitoring budget.

Why FMECAs go stale

The typical FMECA is built once — at commissioning, or for a customer audit — as a spreadsheet on a file share. From that day it decays:

  • It never hears about real failures. The plant's actual breakdowns land in the CMMS and the downtime log; nothing feeds them back. Within a year, the document says the belt is the risk while the plant knows it's the bearing.
  • Nobody owns it. It was a project deliverable, not a living record, so no one's job is to keep it true.
  • It's disconnected from the day. The team investigating this morning's seizure doesn't open the FMECA, because it's four clicks and a file share away — so the analysis that predicted this exact mode contributes nothing to the response.

A living FMECA

In Lumen, the FMECA sits on the asset in the same reliability tree as everything else that happens to it — its issues, its downtime events, its RCPS cases. That changes its life cycle in both directions. Downward: when a case opens on a failure, the asset's FMECA is already on the table — the investigation starts from the predicted modes instead of rediscovering them. Upward: every real failure is evidence against the catalogue, so the criticality ranking reflects what the plant actually does, and the asset reliability view can say which assets to act on in the next seven days with the interpretation sitting in the row.

Asset reliability — next seven daysLive
Asset reliability view in Lumen — assets ranked for action over the next seven days, informed by the asset's failure history and FMECA
FAQFMECALumen IOI
What is the difference between FMEA and FMECA?
FMEA identifies failure modes and their effects; FMECA adds criticality analysis — ranking each mode by severity and likelihood so attention goes to the failures that are both plausible and painful. Every FMECA contains an FMEA; not every FMEA ranks criticality.
How often should a FMECA be updated?
On evidence, not on a calendar. Every significant failure, repeat issue or completed investigation is new information about the asset's real behaviour. A FMECA reviewed annually but fed continuously beats one rebuilt every three years from scratch.
Who should own the FMECA?
The reliability or area engineer who owns the asset's performance — the same person who sees its breakdowns and runs its investigations. Ownership fails when the FMECA belongs to a project team that disbanded.
Is RPN still the right way to rank criticality?
RPN (severity × occurrence × detection) is common and workable, but many sites now prefer a severity–occurrence criticality matrix because detection scores are subjective and RPN arithmetic can hide high-severity modes. Whichever scheme you use, consistency matters more than the formula.

See it on a running site.

Let us show you what Lumen would look like in your facility.

Thirty minutes, on a live board — no slide deck.