FMEA（失效模式与影响分析）实用指南

FMEA 的核心工作，是围绕一个关注元素回答三件事：它本来应该做什么，它可能怎样偏离要求，以及这种偏离会向上游或下游造成什么后果。于是每一条有效的 FMEA 记录，至少都要能落回一条清晰的链条：原因导致某种失效模式，失效模式再导致某种影响。

这也是为什么 FMEA 不能从“先打分”开始。没有功能定义，就无法判断什么叫失效；没有结构边界，就无法区分是本层问题还是上游接口问题；没有因果链，后续的预防措施和探测措施也无从落点。

不同类型的 FMEA 共享同一套分析逻辑，但服务的阶段和对象不同。把它们混为一谈，会导致责任错位：设计问题被推给制造，制造问题又被误当成设计缺陷。

DFMEA 关注的是设计本身是否稳健，PFMEA 关注的是制造与交付过程是否能稳定复制这个设计，而 FMEA-MSR 关注的是系统运行阶段如何通过监视与响应降低残余风险。三者不是互相替代，而是从不同阶段接力控制风险。

在汽车电子和功率电子项目里，很多高严重度问题一旦进入样机验证或量产，代价就会从技术讨论迅速放大成设计返工、治具重做、停线或客户投诉。FMEA 的目的，正是把这些后果尽量挪回成本更低、自由度更高的阶段去处理。

因此，FMEA 不只是质量工具，也直接影响功能安全、验证计划和项目交付。比如短路保护窗口过窄、采样链没有诊断冗余、关键工艺参数没有防错，这些问题如果在 FMEA 阶段就被识别，后面的设计验证和控制计划才有明确重点。

IATF 16949 与 VDA 6.3 并不满足于看到一份 FMEA 文件存在，而是要求风险分析在项目流程里真的被计划、执行、评审和更新。AIAG-VDA 七步法之所以成为行业通用语言，就是因为它把体系要求翻译成了可操作的工程链条。

这两套标准背后的共通要求可以概括为几件事：

• 项目启动时就要明确 FMEA 的范围、资源、责任和里程碑。
• 结构分析、功能分析、失效分析和风险分析必须形成可追溯链条。
• 高风险项的措施必须进入控制计划、特殊特性和后续验证活动。
• 设计变更、过程变更、问题解决和市场反馈都应触发 FMEA 更新。

如果一份 FMEA 只在 SOP 前夕为了审计而补做，它最多能证明团队会整理历史，而不能证明团队真正用它控制了风险。

策划与准备阶段决定了这次 FMEA 是不是一项真正的项目活动。这里需要明确分析范围、目标、团队、资源、里程碑和风险阈值，形成最小可执行的《FMEA 项目策划书》。如果没有这一步，后面最常见的问题就是对象不断漂移，会议很多，但没人知道哪些项必须在什么时间前闭环。

结构分析的作用，是把关注元素放回系统层级中去看。常见载体包括方框图、结构树和接口图，它们要回答的不是“长什么样”，而是“上层是谁、下层是谁、接口在哪里、这次分析到底覆盖哪一层”。

结构层级确定以后，功能分析才有抓手。这里通常要从功能分解出发，再通过参数图和功能网络，把输入、输出、约束条件和相互作用梳理清楚。功能分析做得越清楚，后面定义失效模式就越不容易跑偏。

失效分析则是把功能偏离系统化。常见切入维度包括：范围不对、量值偏差、时序不对，以及产生了不希望出现的负面作用。这样得到的失效模式不再是零散抱怨，而是带着功能背景的失效链，能够继续向上追原因、向下看影响。

风险分析阶段的关键，不是把三个数字填满，而是让每个分数都对应一个明确问题。**严重度（S）**回答后果有多严重，**发生度（O）**回答原因出现的可能性，**探测度（D）**回答现有控制在失效流出前发现它的能力有多强。

传统做法常用 $RPN=S\times O\times D$ 做排序，但它的问题在于不同风险形态可能得到相同乘积，从而掩盖高严重度项。AIAG-VDA 更强调行动优先级（Action Priority, AP），因为工程上真正要优先处理的，往往不是乘积最大的一项，而是那些后果极重、现有控制又不够稳的项。

因此，评分时有两个基本原则不能丢：

• 分数评价的是当前状态，不是“措施做完以后希望达到的状态”。
• 高严重度项即使发生度不高、探测度尚可，通常也不能因为乘积不大就降级处理。

FMEA 到这一步才开始体现“实用”二字。前面的分析只是把风险讲清楚，后面的优化才决定风险是否真的下降。最重要的原则是：优先做预防，再用探测兜底。如果团队习惯于一开始就加检测，而不去改设计和工艺本身，FMEA 最终只会把问题从前端推到后端。

结果文件化的目的，也不是归档一张表，而是形成可执行的交付包。高风险摘要、措施清单、责任人与截止时间、验证方式、管理层评审记录，以及与控制计划和质量管理系统（QMS）的映射，必须一起存在，FMEA 才算真正闭环。

预防措施的目标，是直接降低原因发生的机会，或者通过架构和约束把失效后果限制在可接受范围内。探测措施的目标，则是在失效扩散前尽快识别并触发处置。两者都重要，但优先级不能颠倒。

常见的预防措施包括：

• 设计规则、参数降额和接口约束
• 经验教训复用与标准化设计规范
• 因果研究、试验验证和设计优化
• 防错设计、冗余设计和失效安全机制

常见的探测措施包括：

• 零件、模块和整机测试
• 制造过程中的在线检测与末端检测
• 系统运行阶段的监视、诊断和响应逻辑

一个常见误区是把“计划中的措施”提前写成“现有控制”，从而人为拉低风险等级。FMEA 里只能按当前已落地、已证实有效的控制来评分；未来措施应该进入行动计划，而不是直接计入现状。

FMEA 能否在项目里长期存活，很大程度上取决于它是否形成了一套可追溯的文档链。单独一张工作表无法承担策划、分析、行动和管理评审的全部职责，因此实际项目里至少需要以下几类交付物共同工作：

• FMEA 项目策划书：定义范围、目标、资源、里程碑和责任分配。
• 结构分析表：明确关注元素、上下层关系和关键接口。
• 功能分析表：定义功能、输入输出和性能要求。
• 失效分析表：记录原因、失效模式、影响及其关联功能。
• 风险评估矩阵：记录 S、O、D、AP、当前控制和剩余风险判断。
• 优化改进计划：记录措施、责任人、完成时间和验证方法。
• 结果报告：面向管理层总结高风险项、措施状态和遗留风险。

这些文档的价值，不在于格式统一，而在于它们能让后续的控制计划、特殊特性、验证计划、PPAP 交付和 CAPA 闭环都能追溯回同一套风险判断。

PT-C、ALM、Excel 模板、结构图工具、实验室资源和仿真环境，都会影响 FMEA 的执行效率，但不会改变 FMEA 的本质。一个团队如果没有统一的结构边界、功能定义和因果链口径，再高级的软件也只会更快地产生不一致的数据。

相反，真正有用的工具标准应当回答两个问题：它能不能让跨职能团队对同一条失效链看到同一份上下文；它能不能让措施、责任、验证和后续更新被持续追踪。只要这两点做不到，工具再复杂，FMEA 也很难落地。

一项成熟的 FMEA 通常至少需要三类角色：项目负责人负责进度和资源，方法负责人负责会议组织与方法一致性，内容负责人负责技术判断和措施定义。三者混成一人时，常见后果要么是会议流于形式，要么是技术细节很多但无人推动闭环。

项目节奏也需要固定里程碑，否则 FMEA 很容易无限拖延。一个常见的里程碑链条是：

• 启动：范围、团队、计划确认
• 里程碑 A：结构分析和功能方案完成
• 里程碑 B：失效分析和风险分析完成
• 里程碑 C：高风险措施落实并完成验证
• 交付与关闭：文档归档，遗留风险和后续动作明确

FMEA 作为项目活动，确实需要管理指标，但指标应该服务于风险闭环，而不是制造“已开展工作”的假象。真正有用的指标往往聚焦在覆盖率、完成率和逾期状态上。

常见监控指标包括：

• 已评估失效占目标失效总量的覆盖率
• 高风险项的措施完成率
• CAPA 关闭时效和逾期项数量
• 遗留高风险项是否在管理层显式接受或升级处理

像“开了多少次会”“填了多少行表格”这类指标，最多说明活动存在，不能说明风险真的被控制。

FMEA 如果只在项目初期做一次，就会很快失真。设计变更、供应商切换、工艺参数调整、验证失败、客户投诉、现场失效、8D 闭环结果，以及审计中发现的新风险，都会改变原先对原因、控制和后果的判断。

因此，FMEA 应当被当作活页文档，而不是归档文件。一次问题解决如果没有回写到 FMEA，团队就等于失去了把经验转成组织记忆的机会。

许多 FMEA 失效，并不是因为团队完全没有投入，而是因为投入被用在了错误的层面。下面这些反模式尤其常见：

• 把 FMEA 放到项目后期补文件，高风险项只能靠检测和返工兜底。
• 只有评分，没有清晰的原因、模式和影响链条，导致分数无法辩护。
• 直接复制旧项目内容，不重建本项目的结构边界和功能网络。
• 措施没有映射到控制计划、特殊特性、验证活动和 CAPA。
• 只看 RPN 大小，不看严重度和实际工程后果。
• 把软件字段填满当成分析完成，忽略跨职能团队的共识建立。