09 好 FMEA 与坏 FMEA——常见陷阱

开篇除恐

很多人做完 FMEA，觉得自己"做完了一张表"就够用了。其实差的 FMEA 和不差的 FMEA 之间的差距，往往不是填表对不对，而是你有没有踩到这三个坑：

1. 数据凑数，不是真数据
2. 小组讨论变成了自保打分会
3. 做完了报告，没变成行动

这一章逐个拆。

白话化：三个坑的日常版本

坑一：数据凑数。 这相当于考试时没有复习，考试时凭感觉填一个数。没有历史数据的团队最容易出这种问题。凑数的后果是：后来用这张表做决策时，发现 RPN 排名可靠度很低，信任度下降，从此大家都觉得 FMEA 没用。

坑二：小组讨论变自保会。 人多的时候本来的目的是汇集信息，结果变成"我惹不起各部门，每个缺陷我给个中位数吧"。这也是行为实验里反复出现的现象。安全感强的文化可以打分居中，安全感弱的文化则容易走向两个极端。

坑三：做完报告没行动。 分析做得很好，表格很整齐，大家心里也觉得有用处——但一散会就没人跟进。最常见的原因：表里的"建议措施"是空的，或者写了"加强监控"这种没有人可以接任务的条目。

避开坑一：数据从哪来

最诚实的分级：

• 等级 1：有准确的领域历史数据（生产记录、缺陷日志、用户投诉统计）。直接引用。
• 等级 2：有类似产品或同行业的参考数据。用行业公开数据集、白皮书里的统计，附上来源。
• 等级 3：没有数据，但有工程师的主观判断。通过多人独立打分+小组讨论收敛。注明"基于专家判断，待后续验证"。
• 等级 4：完全没有依据。这种方式不要出现在严肃的 FMEA 里，最多用于第一阶段快速识别风险区域的非常初步的工作。

拿软件测试的场景来说，累积了缺陷跟踪系统（Jira、禅道等）记录的团队，可以从频次统计里提取 O 值。探测度如果没有自动化监控，靠的是 QA 流程的覆盖度——弱网测试覆盖了几种场景。

避开坑二：讨论怎么开

几个可操作的建议：

1. 讨论前先独立打分。每个人填好自己的 S、O、D，再开口。
2. 主持人的角色不是定标准，是问"为什么"。"为什么你给这个打 7 分"比"你打太高了"有用十倍。
3. 禁止在打分前争论"这个失效模式存不存在"。先把模式列完，再打分。边讨论边打字效率最低。
4. 不追责。FMEA 不是绩效考核，是找盲区，不是找背锅的人。

避开坑三：行动怎么跟

FMEA 表的后三列——"建议措施""负责人""跟进日期"——是这张表最有价值的部分。填了才有用。

具体怎么填：

• 建议措施要具体，可验证。"增强监控"不够，要写"在登录接口增加失败率告警，阈值 >20% 持续 3 分钟触发 P1 告警，负责人 @张三，截止日期 7 月 15 日"。
• 不能落空：高风险项如果没有负责人和日期，等于这个项死了。圈出 RPN 前 20% 的项，每一行必须有人认领。
• 不是所有高 RPN 都要立刻修：有些高 RPN 是"阶段性重点"，需要在下一个迭代里安排，不是今天下班前。

好 FMEA 的 Checklist

完成一次 FMEA 之后，对照下面几条自检：

• [ ] 每行的 S、O、D 有出处或标注来源级别（1–4）
• [ ] 讨论前有独立打分环节
• [ ] 最高 RPN 的 20% 项都有具体的建议措施、负责人、日期
• [ ] 表中有至少一项"可被验证"的改进指标
• [ ] 参与人来自跨职能（开发、测试、产品），不是单一部门
• [ ] 结论里面有"我们决定暂时不处理哪些项，以及为什么"

这六条，满足四条以上就是一张有用的 FMEA 表。少于两条，那它充其量是一份看起来像 FMEA 的文档。

例子

☼☼ 正经：两张对照表（自编）

坏 FMEA 摘录

问题：模式不具体，S/O/D 默认中间数，建议措施是空话。"有问题"三个字等于什么都没说。

好 FMEA 对照

看出区别了。好的写的是"哪里的问题、量化标准是什么、怎么改、谁改、什么时候改"。

这一章要带走的东西：

• 坏的 FMEA 不是表写错了，是过程出了问题。
• 三个核心坑：凑数数据、自保讨论、没行动。
• 数据的诚实度分四级，写 FMEA 时标注你的数据属于哪一级。
• 讨论前先独立打分，主持人问"为什么"，不追责。
• 建议措施要具体：谁做、什么时候做完、怎么验。

就这样。