Failure Mode and Effects Analysis (FMEA)

Goal

FMEA answers a question asked before go-live: how can this process or system fail, and which failures must be treated first? It replaces listing fears in a meeting with a sweep through the functions, one by one, followed by a ranking.

The method supports two decisions. The first concerns go-live: is the risk left after the actions acceptable? The second concerns resources: which actions to fund, in what order, with which owner. The ranking settles this second question, where the failure discussed loudest would otherwise win.

The deliverable is the FMEA register, a table with one row per failure mode or per cause. Each row carries the mode, its effect, its cause, the controls in place, the three ratings, the priority, the action decided, its owner, its due date and the ratings recalculated after the action. The register lives as long as the product or the process: every change reopens it.

The method comes from the US military, which described it as early as 1949 in procedure MIL-P-1629. NASA took it up for the Apollo programme, then the automotive industry made it a supplier standard. Two texts define it today: the international standard IEC 60812, which is generic, and the joint handbook of AIAG and VDA, published in 2019 for the automotive industry and read well beyond it.

Usage

When to use it

• Before a production release: fixing a failure on paper costs less than fixing it after its first incident.
• Changed process, system or interface: list what the change can break in the existing functions.
• Costly failure: personal safety, legal compliance, irrecoverable financial loss or damage to reputation.
• Risk list too long to treat in full: the ranking shows where to spend the improvement budget.
• Knowledge spread across business, IT and operations: the session brings these people together on one register, row by row.
• Automotive supplier: the customer expects a register built to the AIAG-VDA handbook.
• Incident data available: tickets, complaints and field returns base the occurrence ratings on facts.

When not to use it

• Failure that has already happened and needs explaining: look for its cause with root cause analysis.
• Strategic or portfolio risks, with no object to decompose: keep them in a risk register, as in risk analysis and management.

Description

The classical method, as IEC 60812 describes it, runs through decomposition, failure identification, rating, ranking and actions. The 2019 AIAG-VDA handbook splits the same work into seven steps and makes explicit what the classical form left implicit: no failure enters the register before the fourth step. The seven steps also apply to an administrative process, as the example shows.

A design FMEA covers a product, a system or a piece of software. A process FMEA covers a sequence of steps: manufacturing, administrative processing, IT operations. The AIAG-VDA handbook adds a third family, for the monitoring functions of a vehicle in service. Business analysts mostly meet the process FMEA and the FMEA of an application or an interface.

1. Plan and prepare

Preparation sets the scope: where the analysed object starts and ends, which interfaces the analysis includes. It also sets the team. Four to six people are enough, provided they include those who know the process day to day, those who know the system and someone from quality or risk. The business analyst facilitates the sessions and keeps the register.

The three rating scales are fixed before the first session. The AIAG-VDA handbook publishes scales for the automotive industry; outside it, the organisation writes its own. Each level carries a criterion that two people apply without conferring: "9, irrecoverable loss of funds or legal breach" rather than "9, very serious". A scale negotiated during the session drifts from row to row, and the final ranking compares ratings that cannot be compared.

2. Decompose the object

Structure analysis breaks the object down into levels. In a design FMEA, the system breaks down into subsystems, then into components. In a process FMEA, the process breaks down into steps, and each step into work elements. The work elements are the cause categories of the step: people, machines or software, consumed materials and the working environment. A context diagram, a process model or a functional decomposition provides the basis. If that basis is missing, the team builds it before the first session.

Skipping this step is the most expensive mistake in the method. A team that lists "what can go wrong" straight away produces failures at mixed levels, duplicates and gaps, and nobody knows what has not been examined. The decomposition lists the elements to sweep, so it tells the team when the analysis is complete.

3. Establish the functions

Each element is given its function, phrased as a verb and an object, with a performance criterion: "send the approved payment order to the bank, once only, by the 23rd of the month". Functions link from one level to the next: the function of a step contributes to that of the process. Without a criterion, a failure cannot be defined, because a failure is a deviation from that criterion.

4. Analyse the failures

A failure mode is the way an element fails to perform its function. For each function, the team looks for absence, partial performance, excess, delay and unintended performance. The order is not sent, or it goes out incomplete, twice, too late or altered. Each of these modes forms a row.

The effect is the consequence of the mode, seen at the level above and up to the customer, the user or the regulator. The cause is what produces the mode at the level below. The AIAG-VDA handbook links these three terms into a failure chain: the mode of an element is the cause of a failure at the level above and the effect of a failure at the level below. The chain links the rows of the register across the levels of the decomposition, whereas a flat list only sets them side by side.

A mode often has several causes. Each cause takes its own row, because it has its own occurrence and its own controls. A row that groups three causes gets a single occurrence rating, and that rating describes none of the three.

5. Analyse the risk

Rate

The team rates each row three times, from 1 to 10. The three ratings measure different things, and confusing them distorts the register.

Severity (S) rates the most severe effect of the mode. It depends neither on the cause nor on the control: a salary payment to a third party stays severe, whether it is rare or frequent. Occurrence (O) rates the likelihood that the cause occurs and produces the mode, given the prevention controls in place, those that prevent the cause. Detection (D) rates the ability of the detection controls to spot the mode or its cause before the effect reaches the customer. The detection scale is inverted: 1 means that the control is certain to detect the mode, 10 that no control exists or that it does not see this mode.

Rating D on the rarity of the mode counts occurrence twice. A control that acts after the effect has occurred, such as a bank reconciliation the day after the payment, gets a high detection rating: it limits the damage without stopping the effect.

Rank by risk priority number

The classical method multiplies the three ratings: the risk priority number (RPN) equals S × O × D and runs from 1 to 1000. Of those thousand values, the product reaches only 120. The team sorts the register by descending RPN and assigns an action to the top rows.

Donald Wheeler has shown the flaws of this product. The three ratings are ordinal: they rank without measuring. An 8 is not twice a 4, and the product of three ranks has no arithmetic meaning. Different risks get the same RPN.

The worst flaw lies in how the RPN weighs severity. A catastrophic but rare failure, or a well-controlled one, gets a modest RPN and ends up below frequent nuisances. A fixed threshold makes the problem worse: an "action above 100" rule pushes the team to rate just below it, and it lets the first row of the table through. A team that keeps the RPN also sets a severity rule: every row with a severity of 9 or 10 gets an action, whatever its rank.

Rank by action priority

The AIAG-VDA handbook replaces the RPN with an action priority (AP). A table in the handbook maps each combination of S, O and D to a high, medium or low priority. The table puts severity first, then occurrence, then detection. The handbook allows a company to replace the values in the table with its own. The table multiplies nothing: two combinations of ratings no longer merge because their products happen to match.

6. Decide the actions

For each action, the register records the factor it targets. The team first seeks to remove or mitigate the effect, then to prevent the cause, then to detect the failure: a prevention action stops the failure, a detection action catches it.

The team assigns each action an owner, a due date and a status. Once the action is done, the team checks its effect and re-rates the row. The new ratings give the residual risk. An action that reads "staff training" and changes no rating has not treated the mode. It has documented it.

Some project teams apply a two-factor variant, S × O, when there is no control to rate. This variant is not the standardised method. It takes the detection lever away from the team, even though an added control, such as a review or a reconciliation, is sometimes the cheapest action.

7. Document and communicate

The team presents the register, sorted and annotated, to those who decide on go-live or on the budget. The presentation shows the high-priority rows, the actions under way and the accepted residual risk, with the name of whoever accepts it. A process change, a new supplier, an added interface or a real incident reopens the register. An incident also supplies an occurrence data point and, if it was not in the register, a forgotten mode. The root cause analysis of that incident supplies the content of the missing row.

An FMEA written after go-live to satisfy an audit no longer decides anything. It copies the existing controls and rates them favourably. An FMEA serves its purpose while a row of the register can still change the design.

AI considerations

A language model speeds up the sweep. From the list of functions, it proposes for each one the modes of absence, partial performance, delay or duplication. It also proposes a first list of causes per work element. The team starts from a list to sort instead of a blank page. The model also reviews the register: it spots two rows that describe the same mode in different words, the same cause rated 3 here and 7 there, an action with no owner or a row with no target factor.

On incident data, a text analysis tool groups tickets and complaints by failure mode. It gives the occurrence ratings a factual basis. Without it, the team rates from what it remembers.

The ratings stay human. The severity rating states what the organisation accepts toward its customers and the regulator, and a named person owns that judgement. A model knows neither the controls the organisation practises nor their failure rate: a detection rating it assigns measures plausibility. FMEA registers also describe the weak points of a system. A consumer AI service that receives them holds the list. The chosen tool stays under the organisation's control.

Examples

The step analysed belongs to the payroll process of an SME with sixty employees.

Sorted by RPN, the register handles the diverted funds last, because their cause is rare. The team's severity rule moves the row to the top. The full register also carries the owners and the due dates.

Visualisations

A filled-in register shows as a table. The three ratings can also be compared criterion by criterion in a table. Two ideas in the method, by contrast, are spatial. The decomposition is a tree: the process, its steps, then the work elements of each step. The failure chain links three levels of that tree with two arrows, and the position of each link tells whether it is cause, mode or effect. The seven steps form a sequence in which the first failure enters only at the fourth.

Cost

Tooling

A spreadsheet is enough for a first FMEA and for most FMEAs of administrative processes. The columns of the register fit in it, sorting by RPN takes one click and the file is easy to share. It reaches its limits when the rows run into the hundreds or when several registers share elements: the failure chain does not appear in it, and a change has to be carried over by hand into every copy.

Specialised software holds the decomposition, the functions and the failure chain in a single database and generates the register from it. APIS IQ-RM, widespread in German-speaking industry, PLATO e1ns and Relyence are examples. They pay off at an automotive or medical-device supplier, where the registers number in the dozens and the customer audits their form.

For the decomposition, a whiteboard, physical or digital such as Miro, holds the structure tree during the session. The team then fills in the register in the chosen tool.

Sources

• International Electrotechnical Commission, IEC 60812:2018, Failure modes and effects analysis (FMEA and FMECA), 3rd edition: the definition of the method, its extension to criticality and its scope, which covers products, processes, software and interfaces.
• AIAG and VDA, FMEA Handbook, 1st edition, 2019: the seven steps, structure analysis, the failure chain and the action priority that replaces the RPN.
• Wheeler, Donald J., "Problems With Risk Priority Numbers", Quality Digest, 2011: the ordinal nature of the three ratings and the flaws of their product that follow from it.
• Kluse, Christopher, "A critical analysis of the AIAG-VDA FMEA; does the newly released AIAG-VDA method offer improvements over the former AIAG method?", Journal of Management & Engineering Integration, 13(1), 2020: the order of severity, occurrence then detection that the action priority and the choice of actions follow.
• NASA, Procedure for Failure Mode, Effects, and Criticality Analysis (FMECA), RA-006-013-1A, 1966: the procedure written for the Apollo programme.