什么是FMEA（失效模式和影响分析）？

失效模式和影响分析（FMEA）是一个在开发阶段，用于确定产品或流程可能的风险和失败点的有条理的过程。FMEA团队会研究失效模式，也就是产品或流程中可能出错的地方，以及这些失效可能带来的影响（如风险、损害、浪费或缺陷），目的是在产品发布之前，减少或消除这些可能的失败。

产品开发团队需要平衡许多相互竞争的利益。市场竞争、客户需求和利益相关者的压力可能会促使团队急于将产品推向市场，从而忽视一些重要的步骤。但是，忽视这些步骤也会增加未来可能遇到的失败、产品召回，甚至法律挑战的风险。那么，开发团队如何设计和开发出能满足安全和监管指导方针、使客户满意、为公司赢得利润的产品呢？

开发团队的流程中一个至关重要的部分就是失效模式和影响分析（FMEA）。然而，为了能够充分利用FMEA，团队不仅需要理解FMEA是什么，他们还需要理解为什么FMEA很重要，并且需要知道如何将其完全融入到产品开发过程中。

对于产品团队的失效模式和影响分析流程概述

FMEA并不仅仅是一次性的事件或者一个需要被勾选完成的预定流程。如果执行得当，FMEA可以提升产品质量、降低成本，并通过帮助开发团队在生命周期早期（而非在产品验证、确认阶段，甚至市场上线之后）就识别潜在的失败，从而确保符合安全准则。执行FMEA还有助于围绕产品捕获组织的知识，并将这些信息保存供未来开发周期使用。最后，收集新产品的数据不仅记录了可能出错的地方，还记录了被拒绝的建议、采取的行动，以及被采纳的解决方案。

可以将失效模式和影响分析视为一种高度结构化的头脑风暴。在FMEA的结构框架内，鼓励团队成员考虑所有可能导致产品失败的因素，并利用团队和组织的知识来找出可能的解决方案或行动以解决问题。正确的FMEA不仅仅是一个需要填写的模板，它是一组旨在实现以下目标的系统性活动：

识别和评估产品或流程的潜在失败；
评估失败的影响；
识别可能消除或减少潜在失败机会的行动；
记录流程并记录决策。

在这个概述中，我们将回顾FMEA的历史和目的，定义关键术语，并为如何将FMEA作为开发过程的一部分提供指南。

什么是FMEA？

FMEA（失效模式和影响分析）最初在1940年代被军方用于测试关键任务的安全性。从那时起，FMEA已经在多个行业得到应用，如汽车、医疗设备和航空航天等。作为一种减轻风险并满足ISO 14971、ISO 13485、IATF 16949和AS9100等国际标准的工具，FMEA支持许多风险管理任务，并有助于证明其合规性。

什么是失效模式？

失效模式是指元素、组件、系统、功能或过程可能出现故障的方式。比如说，自行车的手刹是通过转子和刹车片之间的摩擦来工作的。任何干扰这种摩擦的事件都可以被视为失效模式 — 例如，大雨可能导致在使用刹车时摩擦力减小，从而导致刹车失效。

一旦你知道了失效模式，就可以确定其影响。影响是指故障可能对客户造成的伤害、浪费或缺陷。在上述自行车的例子中，刹车失效可能会导致自行车的使用者严重受伤。FMEA的分析部分是在新产品发布之前识别、优先考虑并尝试减少或消除失效模式和其影响。

失效模式如何被发现的？

失效模式是通过开发过程中的测试和头脑风暴时被发现的。

FMEA如何计算？

什么是风险优先数（RPN），以及它如何在FMEA中使用？

风险优先数（RPN）是一个数字，它被赋予流程中的特定步骤，以量化故障模式发生的可能性、故障未被检测出的可能性，以及故障对人或设备造成伤害的严重性。RPN是这三个因素的乘积：

1）故障发生的可能性

2）故障不被检测的可能性

3）故障对人或设备造成伤害或损害的严重程度。

在FMEA中，每个故障模式都会被分配一个RPN。FMEA的目标是尽可能地降低RPN。如果某个故障可能导致的影响非常严重，那么在产品发布或重新发布前，FMEA过程就会更加努力地通过纠正措施来降低这个风险。

FMEA还可以通过一个简单的计算方式来得出，即故障的严重性乘以发生次数。

FMEA最常见的类型有哪些？

FMEA最常见的类型有两种：设计FMEA和过程FMEA。

设计FMEA

在设计FMEA（dFMEA）中，产品团队会评估潜在的产品故障、产品寿命可能的减少，以及安全和法规问题。团队会从各个方面来审查产品，如材料属性、几何形状、公差、与其他组件或系统的接口、环境、用户画像、降解和系统交互等。

过程FMEA

过程FMEA（pFMEA）主要寻找可能导致产品质量或可靠性降低，从而引发客户不满的潜在失败。它还会关注可能由于人为因素、加工方法、材料、机器、测量系统和环境因素引发的安全问题。

FMEA的层次和范围

FMEA取决于上下文；只有当团队了解过程或设计特性在整个系统中的位置，才能进行适当的分析。

在最高级别，产品作为一个整体就是一个系统。在该系统下有子系统。每个子系统有装配体和/或过程，每个装配体或过程有组件和/或活动。

FMEA应该在每个层次和每个项目中进行。

在每个项目或层次中，FMEA团队需要确定分析的边界，或范围。明确的范围会回答以下问题：

我们的焦点是设计还是调试？（产品在开发到发布的时间线上的位置是什么？）
这个FMEA覆盖了哪个项目和级别—系统、子系统、组件、过程等？
引发这个FMEA的是什么—改变的法规？产品重新设计？新的环境？
我们正在处理设计或过程的哪个方面（可靠性、环境影响、可服务性等）？
谁是客户，客户的要求是什么？

为什么要进行FMEA？

对于许多公司和产品开发团队来说，产品发布周围的最大担忧是一个重大失误，导致用户受伤、负面新闻、召回、产品纠正、诉讼，甚至更糟。但即使是较小的产品问题也可能侵蚀公司的声誉和底线。如果工程师和客服团队把他们的时间花在应对产品问题和解决客户投诉上，他们就无法把时间花在设计新的功能和产品上，推动公司的增长。