失效模式和影响分析（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？

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

将FMEA程序作为产品开发过程的常规环节，将风险评估移到开发周期的早期。它有助于确保在过程的早期就降低了风险，从长远来看，节省了时间、金钱，并保护了声誉。在过程的早期进行FMEA，让团队在还有可能控制风险、成本和声誉时，对潜在的设计和过程失败进行深思熟虑。

控制成本的时间是在开发过程的早期，即在成本产生之前。失效模式和效应分析帮助公司通过提供一种评估和分析潜在风险和失败的结构化方法，准确地评估和规划成本。

我们应该什么时候进行FMEA？

FMEA是一个主动的工具，适用于以下任何情况：

• 开发全新的设计、技术或过程； 
• 修改现有的设计或过程；
• 改变设计或过程的环境、位置、应用或使用情况；
• 或响应影响设计或过程的法规变更。 

同时，也需要记住，FMEA是一个连续的过程，而不是一次性的事件。事实上，它在不同的时间为不同的目标实施时最有效。为了获得最好的结果，尽可能多地汇集跨职能的人才。这并不是要求公司的每个人在每个阶段都参与，而是要求聚集具有不同观点和见解的人，他们可以一次专注于一个系统或子系统。

FMEA的过程是什么？我们应该如何进行FMEA？

虽然FMEA一开始可能看起来结构过于严密，但实际上，这种结构实际上是它的一大价值所在。在FMEA的结构中，团队有能力提问、提供见解、头脑风暴解决方案，同时为组织捕获知识，提高产品性能和安全性。

但是，虽然结构是FMEA的一大优点，但对于对它不熟悉的团队来说，可能会觉得有些困难。

以下是进行FMEA的有序方式：

步骤1：准备FMEA文件。通常，这个步骤可以由熟悉被分析的设计或过程的人完成，例如设计团队的一员。这里的诱惑是使这个文档过大或过于包罗万象。请记住，它只应该包括一个系统或子系统，甚至一个过程或属性。

步骤2：邀请团队。这一步可以与第一步同时进行。产品团队的一员应该组建一个由开发团队内外四到六人组成的临时团队。你的跨功能团队可能包括来自采购、计划、财务、销售、营销和生产部门的人员，当然，还有客户或最终用户。

步骤3：输入信息。当团队组建完成，文档就位时，就可以开始头脑风暴了。查看所有可能的失效模式。评估可能的原因、风险和失效模式的潜在效应，然后在FMEA文档中相应地填写。

步骤4：分配RPNs。计算和分配RPNs通常可以与信息输入同时进行，但如果没有，确保在优先考虑和头脑风暴解决方案之前进行分配。

步骤5：优先考虑失效模式。RPN最高的失效模式是风险最高的失效模式，应优先评估和审核。

步骤6：与其他团队协调。当然，最好是让许多FMEA团队同时审核系统、子系统和每个级别的其他项目。团队应该确保彼此之间的协调。如果一个团队的解决方案实际上导致了另一个团队的失效模式，或者如果一个团队的效应可能意味着对另一个团队的系统的后果，那么在开发周期尽可能早的时候发现这一点是非常重要的。

步骤7：与需求管理以及合规性和法规指导进行整合。随着FMEA团队完成他们的分析并解决潜在的失效，这些结果应该被整合到需求管理过程和相关的安全和合规指南中。使用如PingCode这样的需求管理工具，团队能够直接将FMEA项目链接到潜在的失效来源以及缓解要求或验证。

是否有软件工具可以帮助产品团队简化 FMEA 流程？

一些专业的需求管理工具可以将FMEA直接整合到设计过程中，通过提供可定制的模板，让团队能够协作、关联缓解措施、跟踪更改、审查和跟踪工作流程状态。

别让匆忙的开发周期使你面临差评、产品召回、诉讼或更糟糕的风险。通过将彻底的FMEA整合到你的开发过程中，你将能够将更好的产品带入市场，并确保安全和合规。

需求管理

 需求管理指南： 

需求管理： 需求管理主要内容  |  需求管理的重要性  |  采用敏捷方法进行需求管理  |  如何克服需求管理的 5 大挑战  |  更多 

需求编写： 功能需求的示例和模板  |  采用 EARS 方法来改进需求工程  |  如何编写一份优秀的产品需求文档（PRD） |  功能性需求与非功能性需求的区别  |  有效需求的特征  |  更多 

需求收集和管理流程： 需求工程概述  |  产品团队的需求分析指南  |  敏捷产品团队的 11 种需求收集技巧  |  定义和实施需求基线  |  更多  需求的可追溯性： 什么是需求可追溯性  |  可追溯性在现代产品和系统开发中的关键作用  |  如何创建和使用需求追溯矩阵  |  更多 

需求确认和验证： 产品团队的需求验证和确认  |  更多 

需求管理领域文章：

 做好需求分析的4大关键认知  |  盘点国内9款热门需求管理系统  |  构建产品路线图的方法与工具  |  做好需求优先级判断的7种主流模型  |  采用敏捷方法进行需求管理  | 更多