FMEA: the analysis is worth what the actions are worth

FMEA — failure mode and effects analysis — is a structured way of asking, before a product is made or a process is run, what could go wrong, what the consequence would be, and what you are going to do about the combinations that matter. It exists in two main forms: design FMEA, which examines the product, and process FMEA, which examines how it is manufactured or delivered.

It is a team exercise, not a document exercise. The value comes from the argument between the engineer who designed the part, the person who assembles it and the one who fields the complaints — and the document is the residue of that argument. Which is why an FMEA written by one person at a desk, however neatly, is usually worthless.

How an FMEA is built

1. Define the scope: the process steps or the product functions, at a level of detail the team can actually reason about.
2. For each item, state the function or requirement — what it is supposed to do.
3. List the failure modes: the ways it can fail to do that. Not causes yet, and not consequences.
4. For each failure mode, the effects, and how severe they are for the end user or the next process.
5. For each failure mode, the causes, and how often each is expected to occur.
6. The current controls: what prevents the cause, and what detects the failure before it escapes.
7. Rate severity, occurrence and detection, and use them to decide where action is needed.
8. Assign actions with an owner and a date, and re-rate only after the action is verified.

RPN, action priority, and the number that became a target

Older practice multiplied severity, occurrence and detection into a risk priority number, and teams then set a threshold — act on anything above a hundred, say. The predictable happened: ratings were tuned downwards until the number cleared the threshold, and severity-ten failures with low occurrence went untouched because the product was small. The current AIAG-VDA approach replaces the arithmetic with an action priority table that treats severity as decisive rather than as one factor among three. Whichever your customer requires, the rule that matters is unchanged: a high-severity failure deserves attention regardless of how the arithmetic comes out.

Detection ratings measure your controls, not your optimism. If the only control is an operator noticing something, the detection rating is poor no matter how experienced they are — and improving detection is always the weaker answer. Reducing occurrence changes the process; improving detection only catches it more often.

Keeping it alive

An FMEA is meant to be a living document: reopened when the process changes, when a new failure appears in the field, when a customer complaint arrives that is not in the table. In practice most sit untouched from launch to audit, which is visible immediately — a warranty issue that has been happening for a year appears nowhere in the analysis that was supposed to anticipate it. The habit that fixes this is small: whenever a complaint or a scrap event goes through root cause analysis, ask whether the failure mode is in the FMEA, and add it if not.

Where the worksheet lives

FMEA is a table with a lot of columns and a lot of revisions, which makes the tool question mundane: Ettex Sheets holds the worksheet with the ratings and the action list, filterable by severity so the high-severity rows are visible without scrolling, Ettex Records keeps the revisions per part and per process with the linked control plan and complaints, and Ettex Docs holds the meeting notes behind the ratings — the reasoning that nobody can reconstruct two years later.

Being direct: this is a spreadsheet and a record, not FMEA software. There is no AIAG-VDA form template, no automatic action priority table, no linkage to a control plan and no customer submission format. Dedicated tools do those, and where a customer specifies one, that is what you use.