FMEA做了等于没做？这5个误区，坑了多少工程师

导语

每次质量评审，FMEA报告厚厚一摞。但返修单还是照样来，客户投诉还是照样有。

FMEA到底哪里出了问题？

做了十几年可靠性咨询，我们发现：问题不在于"做没做"，而在于"做没做对"。

以下5个误区，你中了几个？

误区一：FMEA是"填表任务"，完成就行

常见场景： 项目评审节点快到了，工程师连夜赶出一份FMEA，格式齐全、栏目填满，顺利通过审核。然后这份文件……就再也没有被打开过。

问题在哪里： FMEA的价值不在于"有这份文件"，而在于分析过程本身。

真正的FMEA是一个跨部门团队坐在一起，逐条讨论"这个地方会不会坏？坏了怎么办？怎么防止它坏？"的过程。

如果只是一个人对着模板填写，那这份FMEA就只是一份格式正确的废纸。

正确做法： 建立跨职能团队（设计、工艺、质量、制造至少各出一人），把分析过程变成真正的集体讨论会。

误区二：RPN值越高，风险就越大

常见场景： 工程师把RPN（风险优先数）作为唯一判断标准，RPN = 200的项目重点关注，RPN = 60的项目直接放过。

问题在哪里： RPN = 严重度 × 发生率 × 探测度

一个 严重度10 × 发生率1 × 探测度1 = RPN 10 的失效， 和一个 严重度1 × 发生率2 × 探测度5 = RPN 10 的失效， RPN值相同，但前者可能导致人员伤亡，后者几乎无关紧要。

RPN低不代表风险低，严重度才是第一道红线。

正确做法： 严重度 ≥ 9（安全/法规相关）的失效模式，无论RPN多低，都必须优先采取措施。不能只看总分，要先看分项。

误区三：FMEA做一次就够了

常见场景： 设计定型时做了一份FMEA，此后产品迭代、工艺调整、供应商更换……FMEA文件一直是三年前的版本。

问题在哪里： 产品在变，风险也在变。原来不存在的失效模式，可能因为一次材料替换就出现了。原来已受控的风险，可能因为工艺调整而重新暴露。

一份静态的FMEA，面对动态的产品，就是一张过期的地图。

正确做法： 建立FMEA动态维护机制——设计变更、工艺变更、重大客诉发生时，必须触发FMEA复审。建议每年至少一次全面回顾。

误区四：控制措施写"加强检验"就万事大吉

常见场景： 分析到某个风险点，控制措施一栏填上："加强过程检验""100%检验出货"，然后RPN重新计算，分数降下来了。

问题在哪里： 检验是发现问题的手段，不是预防问题的手段。

依赖检验意味着：问题已经发生了，只是希望在出厂前把它抓住。这不叫风险控制，这叫"亡羊补牢"。更何况，100%检验本身也存在漏检概率，尤其是疲劳检验、主观判断类项目。

正确做法： 优先从设计源头消除失效原因（预防措施），其次是防错装置（Poka-Yoke），最后才考虑检验手段。措辞应具体可执行，而不是"加强"这样的模糊表述。

误区五：FMEA是质量部门的事，研发不参与

常见场景： FMEA被视为质量部门的"分内事"，研发工程师最多配合填几个参数，核心分析由质量人员完成。

问题在哪里： 最了解产品设计意图和潜在失效的人，是研发工程师，而不是质量工程师。

一份没有研发深度参与的FMEA，很可能遗漏关键失效模式，分析深度也严重不足。质量部门更擅长的是推动流程、核查覆盖度，而非替代研发做技术判断。

正确做法： FMEA的主导者应该是产品工程师或系统工程师，质量部门负责方法论支撑和流程把控。两者协作，缺一不可。

总结

做FMEA不难，做对FMEA才难。

如果你的FMEA只是在走流程，那它确实等于没做。

真正有效的FMEA，是工程师们在白板前争论不休的那一个小时，是那张贴满便利贴的风险清单，是那份被反复修改、版本号已经到了v12的活文档。

国可工软专注于可靠性分析软件研发与技术服务，提供FMEA系列、Weibull分析等工具，以及企业内训与咨询支持。