FMEA: Turn Vague Process Worries Into Ranked, Owned Actions

FMEA stands for Failure Mode and Effects Analysis. It asks three questions about every way a process step can fail. How bad is the effect. How often does the cause occur. How likely are you to catch it before the customer does. You score each question, multiply the three scores, and get a Risk Priority Number.

The tool in Ci Flow assesses current risk, separates prevention controls from detection controls, plans action with an owner and a due date, then confirms residual risk after that action. That last part matters. Many risk registers stop at the first score and never close the loop.

Use FMEA in the Analyse phase of RDMAICS. By then you have defined the problem and measured the process. You have data on where the pain lands. FMEA takes that evidence and turns it into a ranked list of what to fix first. Use it earlier and you are guessing. Use it later and you have already chosen your improvements.

The example used throughout this guide is fictional. It ships with the tool as sample data so you can see the mechanics before you load your own process.

The case is a food delivery operation. Customers order, the kitchen prepares, a driver collects, the food arrives. Complaints cluster around cold food and late arrival. The team has measured the problem and now wants to know which failure to attack first.

Two process steps are loaded. The first is order dispatch. The failure mode is that a driver is assigned too late, and the effect is late delivery. The second is kitchen handoff. The failure mode is that a completed order waits, and the effect is food cools. Both sound serious. Scoring tells you which is more serious.

Start with the process step and the failure mode. Keep the failure mode specific. Driver assigned too late is a failure mode. Poor dispatch is not. The tool needs something you can observe and count.

Next comes severity, scored from the customer's point of view. Order dispatch scores 8 for severity because a late delivery is a direct customer harm. Kitchen handoff scores 7 because cooling food is bad but slightly less visible than a missed time window.

Then the cause and occurrence. For order dispatch the cause is manual assignment, scored 7 for occurrence. For kitchen handoff the cause is FIFO not visible, scored 6. Note that the cause is a mechanism, not a person. Manual assignment is a design choice. Naming a slow dispatcher would give you nothing to improve.

Now the two control columns. This is the part teams most often rush. Prevention controls stop the cause from happening. Detection controls catch the failure after it has happened. Order dispatch has queue review as prevention and a late-order alert as detection. Kitchen handoff has a standard handoff shelf as prevention and a verbal check as detection. Detection is scored 6 for both, which is a high number. A high detection score means you are unlikely to catch the failure in time.

The tool multiplies severity by occurrence by detection. Order dispatch gives 8 times 7 times 6, which is 336. Kitchen handoff gives 7 times 6 times 6, which is 252. Both land in the High priority band.

The chart plots current and residual Risk Priority Numbers side by side on a scale running 0, 85, 170, 255, 340. Driver assigned too late sits highest at 336. Completed order waits follows at 252. The visual gap is the point. Two problems that felt equal in the meeting room are not equal once scored.

The tool also offers an AI review that explains the result in plain language if you want a second read on the numbers.

With 336 against 252, order dispatch goes first. The recommended action is to pilot nearest-driver auto-dispatch, owned by the dispatch lead, due 2026-10-15, currently In progress. The kitchen action is a visual handoff kanban, owned by the kitchen lead, due 2026-10-01, status Planned.

Now look at the post-action scores. For order dispatch, post severity stays at 8 while post occurrence drops from 7 to 3 and post detection drops from 6 to 3. Residual RPN is 72. For kitchen handoff, post severity stays at 7, post occurrence drops from 6 to 3, post detection drops from 6 to 3, and residual RPN is 63.

Severity does not move in either row. That is correct and it is one of the most useful lessons FMEA teaches. A late delivery is just as bad for the customer whether it happens weekly or yearly. You reduce risk by changing how often the cause occurs and how reliably you catch it. You rarely change how much it hurts.

Both actions also attack prevention and detection together. Auto-dispatch removes the manual assignment cause. A visual kanban makes FIFO visible instead of relying on a verbal check. That is why both occurrence and detection scores fall.

The first mistake is scoring as a group by consensus pressure. One confident voice anchors everyone else. Score independently, then discuss the gaps. The disagreements are where the learning sits.

The second is treating detection as a fix. A late-order alert tells you an order is late. It does not make the order on time. If all your actions sit in the detection column, your residual RPN will barely move, and your customers will still feel the failure.

The third is inflating severity to win attention for a pet project. Severity is anchored to customer harm. If everything scores 9 or 10, the ranking collapses and the tool stops helping you choose.

The fourth is filling in post-action scores and then never checking them. Those numbers are a forecast. After the kitchen kanban is in place, go back and score the real process. If occurrence did not actually drop to 3, you have learned something worth knowing.

FMEA will not tell you whether your scores are right. Severity 8 and severity 7 is a judgement made by your team. Change the people and the numbers move. The tool multiplies what you give it. It cannot audit your inputs.

The Risk Priority Number is a blunt instrument. A score of 336 is not four times worse than a score of 84. The scales are ordinal, so the arithmetic is a sorting aid, not a measurement. Treat the ranking as a conversation starter. Do not defend a decision purely because one number beat another by a small margin.

FMEA will not find failure modes you did not think of. It is only as complete as the process map and the people in the room. If nobody mentions a step, that step carries no risk in the analysis, which is not the same as carrying no risk in reality.

The post-action scores are predictions, not results. The residual RPN of 72 for order dispatch is what the team expects after the pilot. It is not evidence that the pilot worked. Evidence comes later, in Control and Sustain, when you measure the live process again.

Finally, FMEA will not do the improvement. It will not implement auto-dispatch or build a kanban. It ranks, it assigns, it forecasts. The work still belongs to the owners named in the rows, and so does the follow-up.