上周帮一家做电驱总成的一级供应商看他们的 DFMEA，结构分析那一页翻开我就愣了一下：整棵"结构树"就是一张物料清单的截图，"系统—子系统—零件"三个级别分别写着"电机总成—定子—铜线"。再往后翻功能分析，功能栏里填的还是"定子""铜线"，要求一栏是空的。这份文件拿去交审核，七步法一页不落，格式漂亮得很，可实际上一步都没走。新版 FMEA 最要命的地方就在这儿——它不像老版那样用一张表框着你，填错了数字一眼就能看出来；它把逻辑藏在了"上中下"三层的对应关系里，填得不对照样能生成一份看起来完整、挑不出格式毛病的报告。
这也是为什么"新版 FMEA 常见错误"这个话题值得单独聊一次。老版 FMEA 的错误大多停留在"分打高了""漏了一行"，新版 FMEA 的错误往往整份文件从头到尾都是错的，但表面上一点破绽都没有。我带过几个项目的 FMEA 评审，也见过供应商被打回来重做三四轮的，出问题的地方高度集中在下面这几块：结构树与功能网脱节、失效链只写两层、S/O/D 的定分依据拍脑袋、AP 判出来之后不了了之。这篇就把这些错误一个一个拆开讲，说说错在哪、为什么会错、以及怎么改。不管你是刚接手 FMEA 的工程师，还是被拉进评审会要签字的人，都能对得上号。
1. 新版FMEA和旧版之间，真正变的是三个动作
很多人以为新版就是把表格换了换样子、多了几个字段。真做起来才发现，AIAG-VDA 这套手册（2019 年发布）是把整个推演方式重做了一遍。如果你的团队还在用"找个人把 Excel 填满然后大家签字"的方式做事，那基本上可以确定，出来的文件是不合格的。新版真正变的地方，其实集中在三个动作上。
1.1 七步法的重点不在"七"，在链条能不能推到底
七步法是新版最显眼的一个标志：规划和准备、结构分析、功能分析、失效分析、风险分析、优化、结果文件化。绝大多数人的第一反应是"哦，七张表"，于是按顺序填完就交差。问题就出在这儿——七步法不是七个孤立的步骤，它是一条单向可追溯的链路：
- 结构分析确定了"关注要素"以及它的上一较高级别、下一较低级别；
- 功能分析把客户要求逐层分解成每一层要素的功能和量化要求；
- 失效分析沿着同一条链，把上一级的功能失效作为失效影响、关注要素的功能失效作为失效模式、下一级的功能失效作为失效原因；
- 风险分析对每一个"失效原因—失效模式—失效影响"的组合打分；
- 优化针对的是高优先级的那几条；
- 文件化输出的是整条链的证据。
你只要拿这条链路回去卡一遍自己的文件，问题立马现形。我见过最常见的场景是：结构分析只写了三层五个格子，功能分析却冒出来八条功能，到了失效分析又变成十二条失效模式，三层之间数字对不上。这不是格式问题，是链路断了。评审的时候只要问一句"这条失效原因对应下一级的哪个要素、哪个功能"，答不上来，这份 FMEA 就得重做。
提示：判断一份 FMEA 是否合格，最省事的办法不是看打分，而是随手挑一条失效原因，顺着往上问三层：它是哪个下级要素的什么功能失效？它导致关注要素哪个功能失效？再往上影响哪一级客户的什么使用场景？三句话能答上来，链路就是通的。
1.2 AP 取代 RPN 之后，"阈值思维"必须丢掉
老版 FMEA 最深入人心的一个东西就是 RPN 阈值，比如"RPN 大于 100 就要采取措施"。新版把手册里的 RPN 换成了措施优先级 AP（Action Priority），分 H、M、L 三档，而且明确说明：AP 不是数值，不设阈值，不能简单排序了事。
这件事的杀伤力比想象中大。我见过不止一个团队，把 AP 先映射成数字（H=3、M=2、L=1），再跟严重度相乘，自己造了一个"综合风险分"出来，然后按分数从高到低挑几条做改进。这等于把新版改成的东西又改回去了。
AP 的逻辑是：严重度 S 决定天花板，频度 O 和探测度 D 决定落点。S 越高，能落到 L 的空间越窄；S 打到 9 或 10（涉及安全、违反法规），基本上只要是正常的 O 和 D，AP 就会顶到 H。这时候不存在"我打的分不高所以先放着"这种操作空间。
更关键的一点是，新版要求AP=H 的项要么采取措施，要么给出书面理由说明为什么不采取。也就是说，H 项必须有一个交代，不能靠"分数不高"偷偷溜过去。这一条如果不落实，整套 AP 就退化成了一个装饰品。
1.3 5T 里的 Timing 和 Team，是最先被牺牲的两项
5T 是第一步"规划和准备"里的东西：InTent（意图/目的）、Timing（时间/时机）、Team（团队）、Tasks（任务）、Tools（工具）。听起来很虚，实际上是最容易出事的两项就是 Timing 和 Team。
Timing 说的是 FMEA 要在设计冻结之前做、在工艺定型之前做。它是事前工具，不是事后文档。现实里大量企业的做法是：设计图已经出了、样件已经做了、产线已经跑了，然后让工程师回头补一份 FMEA 填进审核包。补出来的东西有个共同特征——严重度和失效模式是照着现有设计反推的，逻辑上看着通，但它对设计决策零影响。审核员只要问一句"这份 FMEA 里的哪条措施改变了设计"，就露馅了。
Team 说的是跨职能。新版反复强调 FMEA 不是一个人的活，团队里要有设计、工艺、质量、采购、售后服务，涉及外购件还要有供应商。我见过最典型的一种做法是：让一个刚入职两年的工程师把 Excel 从头填到尾，然后开会的时候找了七八个人签字。签字的人里有一半根本没看过内容。这种 FMEA 在评审会上撑不过三个问题。
Tools 这一项也常被理解偏。它不只是"用哪个软件"，还包括你用不用基础 FMEA、家族 FMEA、内部的失效案例库、售后数据、试验失效记录。这些才是打分和判断的真实依据，没有它们，S/O/D 就只能靠感觉。
2. 结构分析和功能分析：最容易"看着对"的几类错
从评审经验看，一份 FMEA 最终能不能站得住，八成取决于第二步和第三步。这两步做扎实了，后面只是顺着走；这两步塌了，后面写得再漂亮也是空中楼阁。偏偏这两步最不容易看出问题，因为它们的输出都是文字描述，没有数字可以卡。
2.1 结构树直接拿 BOM 顶包，边界和接口全丢了
结构分析要输出的是结构树，不是物料清单。这两者的差别在于视角：BOM 回答的是"这个东西由哪些零件组成"，结构树回答的是"这个关注要素在系统里承担什么角色、它的上下边界在哪里、它和谁有接口"。
拿 BOM 顶包最直接的后果就是接口全丢。我举个实际例子：某变速箱的换挡执行机构做 DFMEA，结构树里列了电机、丝杠、拨叉、位置传感器，看起来挺全。但评审的时候问了一句"位置传感器和拨叉之间的信号接口在哪个要素上体现"，全场沉默。接口失效恰恰是这类机构最容易出问题的地方——信号漂移、标定偏差、迟滞，全都发生在接口上，而结构树里根本没有接口的位置，这些失效模式也就永远不会被识别出来。
正确的做法是：结构树的第一层要写清关注要素的上一较高级别（谁在用它、它的上级系统是什么），第三层写清下一较低级别（谁构成了它），同时在每个要素上标注接口和边界。如果关注要素是"换挡执行机构"，那么上级就是"变速箱总成"，这个层级决定了失效影响的表述要落到变速箱甚至整车上；下级是各个分零件，这个层级决定了失效原因的落点。
另一种常见错误是层级挑错。关注要素选得太高（比如直接选"整车"），FMEA 会写得非常空，全是"动力性下降""舒适性变差"这类没法落地的描述；关注要素选得太低（比如选"一颗螺栓"），又会导致失效影响写不出来，因为你根本不知道这颗螺栓失效之后对上一级意味着什么。选层级的原则很简单：选你真正能改动、且失效影响能被明确描述的那一层。
2.2 功能栏写零件名，量化要求凭空消失
功能分析里最普遍的错，就是把功能写成了零件名。"定子""铜线""轴承"——这不是功能，这是名词。功能必须是动词加名词，并且带可衡量的量化要求。
我拿一个车载充电机的散热结构举例。写成"散热片"，这是零件名；写成"散热"，这是动词但没量化；合格的功能描述应该是"在环境温度 45 摄氏度、持续输出 11 千瓦工况下，将功率模块结温维持在 125 摄氏度以下"。只有后面这半句的量化要求存在，失效模式才可能被明确定义——结温超过 125 摄氏度就是失效，你才知道要防什么。
功能分析里另一个高频错误是漏掉功能的条件维度。任何一个功能，都要在三种条件下分别描述：
| 维度 | 要写清的内容 | 漏掉之后的后果 |
|---|---|---|
| 环境条件 | 温度、湿度、振动、介质、电磁环境 | 环境相关的失效原因全部漏掉 |
| 运行条件 | 载荷、转速、电压、电流、占空比 | 边界工况失效识别不出 |
| 寿命阶段 | 磨合期、稳定期、老化期、存储期 | 老化类失效、存储类失效无人负责 |
这三条漏掉任何一条，后面失效分析的输入就是残缺的。很多团队抱怨"想不出失效模式"，根子上不是经验不够，是功能描述写得不够细——功能描述的信息量决定了失效模式能推出来多少。
提示：判断功能描述是否合格，有个很土但很好用的办法——把功能描述念出来，看能不能凭这句话直接写出对应的失效判据。写得出，说明量化到位；写不出，说明还停在"散热""支撑""传动"这个层级。这一步不返工，后面全是白干。
2.3 功能网对不上结构树：三种典型断链
功能不是平铺的，它是一张网——上级功能由下级功能支撑，下级功能失效会导致上级功能失效。新版强调功能网，就是要求把这个支撑关系显式地画出来。实际做的时候，断链有几种典型形态。
第一种是层级数量不一致。结构树上关注要素有三层，功能网上却只有两层功能，中间的传递关系凭空消失了。第二种是功能归属混乱，某个功能同时被挂在两个要素上，谁都说是自己负责。第三种最隐蔽，下级功能的总和撑不起上级功能。比如上级要求"在零下 30 摄氏度可靠启动"，下级列了七八条功能，全是常温下的电气和机械功能，没有一条跟低温相关。这种情况下，上级功能要求根本没有被分解下去，也就谈不上被保障。
自查的办法很直接：把上级功能的量化要求抄一份，然后在下级功能里逐条找对应项，找不到的就是断链。这个动作花不了二十分钟，但能捞出一堆问题。
3. 失效分析和打分：错得最深、也最难自查的地方
到了第四、第五步，问题开始变得隐蔽。因为这里的输出是失效描述和评分，两类内容都有一个共同特点——它看起来"差不多对"。失效描述写得像模像样，评分打了 6、7、8，没有明显离谱的地方，但背后的依据是空的。这类错误在评审会上往往要靠追问才能暴露。
3.1 FE/FM/FC 只写两层，因果链从中间折断
失效分析的核心是三要素：失效影响 FE、失效模式 FM、失效原因 FC。新版要求这三者严格对应三个结构层级：
- 失效影响 FE对应上一较高级别，描述的是关注要素失效之后，上级要素或客户会感受到什么；
- 失效模式 FM对应关注要素本身，描述的是关注要素没有实现它的功能；
- 失效原因 FC对应下一较低级别，描述的是下级要素为什么会导致关注要素失效。
最常见的错误是只写两层。大量文件里只有失效模式加失效原因，或者只有失效模式加失效影响。只写两层意味着因果链是断的：有失效原因却没有对应的失效影响，说明你不知道这个原因最终会伤到谁；有失效影响却没有失效原因，说明你只知道坏了但不知道为什么坏。这两种情况都做不出有效的优化措施。
第二类错误是层次串位。把"轴承磨损"这种下一级的现象写成了失效模式，把"电机异响"这种上级现象写成了失效原因。串位之后，打分就会跟着错——严重度是对失效影响打的，你拿失效模式去打分，出来的数字没有意义。
第三类错误是一条失效模式对应多个失效原因时关系不清。新版要求每一个"失效原因—失效模式"对都要独立评估，因为它们对你上游的影响路径、预防控制、探测控制都不一样。常见做法是把三个原因挤在一格里共用一个 S/O/D，这在逻辑上是站不住的。
自查办法：随便挑一条失效原因，问三个问题——它属于哪一级要素？它导致的失效模式属于哪一级？这个失效模式的失效影响写给了哪一级客户？三层的层级归属清清楚楚，才算合格。
3.2 严重度 S 被打成"客户抱怨等级"
严重度 S 是整套评分里权重最高的一项，也是最容易被误用的一项。最常见的误用是把它当成"客户抱怨等级"来打：被投诉过的打 8，没被投诉过的打 4。这完全是反的——严重度评的是失效影响一旦发生时的后果严重程度，跟历史上发生频率毫无关系。低频但后果致命的事件，S 照样是 9 或 10。
新版手册里 S 是 1 到 10 的十档，锚点大致是这样的：
| 分值区间 | 后果特征 |
|---|---|
| 1 | 无可辨识的影响 |
| 2-3 | 客户能感知到轻微不适，功能基本不受影响 |
| 4-6 | 客户明显不满意，主要功能降级或需要返修 |
| 7-8 | 主要功能丧失，车辆/设备无法正常运行 |
| 9-10 | 影响安全、违反法规要求；10 对应失效发生前无任何预警 |
第二类误用是把 DFMEA 和 PFMEA 的严重度表搞混。这两张表的评价视角不一样：DFMEA 的严重度是从整车/最终用户的角度评的，PFMEA 的严重度要先看这个失效会不会流出到客户，还要看它在制造过程内部的影响（比如对下游工序、对操作人员、对设备的影响）。拿 DFMEA 的表去打 PFMEA 的分，出来的结果必然偏。
第三类误用是严重度被打成"可以协商"的数字。我参加过一场评审，同一个失效模式，设计方打 6，质量方打 8，最后折中成 7。这个处理方式是错的。严重度的分歧必须回到评分表的锚点去对，看失效影响到底落在哪一档的行为描述上，对不上就去找客户要求或法规原文来定，而不是靠商量。严重度的定分权应该落在跨职能团队的共识上，而不是某一个部门。
提示：如果团队内部对严重度的定分分歧很大，最快的收敛办法是把评分表里那一档的行文原文念出来，逐句对照失效影响描述。多数分歧不是因为标准不清，而是因为失效影响本身写得含糊——把失效影响写具体了，分自然就统一了。
3.3 把预防控制和探测控制塞进同一格
这是新版 FMEA 里我认为最值得单独拿出来讲的一个变化。老版只有一列"现行控制"，新版拆成了预防控制和探测控制两列，而且这两列服务的是不同的对象：
- 预防控制针对的是失效原因，作用是降低失效原因发生的概率，它影响的是频度 O；
- 探测控制针对的是失效原因或失效模式，作用是在失效传递出去之前把它发现，它影响的是探测度 D。
把这两者塞进同一格，后果是 O 和 D 都没法评。因为 O 要评的是"预防控制的有效性"，你没写预防控制，O 就只能凭感觉；D 要评的是"探测控制的有效性"，你写的是预防措施，D 同样只能凭感觉。
还有一个更隐蔽的错误：把"要求"当成"控制"写进去。比如预防控制栏里写"供应商需保证来料合格"，探测控制栏里写"操作员需按要求自检"。这不叫控制，这是要求。合格的控制描述必须包含具体的手段、频次、判定标准，例如"每批次来料按抽样方案做硬度检验，硬度超出范围即判退"。前者无法评估有效性，后者才可以。
顺带说一句，新版对探测度的评估维度比老版细，除了探测方法本身能不能发现，还要看探测发生在哪一环——是在失效原因产生的工位内就被发现，还是流到下游工位才被发现，还是到了最终检验甚至客户手里才发现。同样是"有检验"，发生的位置不同，探测度可以差出好几档。很多团队打分时只看"有没有检"，把这三个维度全忽略了，D 分自然偏乐观。
3.4 频度 O 靠感觉、探测度 D 只看"有没有检"
频度 O 的评分依据，新版说得很明确：一是预防控制的成熟度和有效性，二是同类产品、同类过程的实际数据。这两条在有数据的企业里不难办，难的是很多团队这两条都没有，于是 O 分就变成了"我觉得这个不太会发生，打个 3 吧"。
这里有个很实际的做法：把售后数据、试验失效记录、产线不良统计、供应商来料不良记录都翻出来，按失效原因归类，看每一类在历史上的实际发生情况。哪怕样本量不大，这个动作也能把 O 分从"感觉"拉回到"有依据"。同时把预防控制的具体措施写清楚——是不是有防错装置、是不是有过程能力监控、是不是有供应商侧的管控——措施越硬，O 分越低，这个对应关系必须能说清。
D 分的误用前面提了一部分，再补一个：把 D 和"问题被发现的概率"混为一谈。探测度评的不是"这个问题会不会被发现"，而是"现有的探测控制在失效传递出去之前把它发现的能力有多强"。这两个描述的差别很关键：前者是在赌运气，后者是在评控制手段。
还有一种是惯性打分。同一个团队做十几个项目，发现所有项目的 O 和 D 分布几乎一模一样，都是 3、4、5 这几个数。这种情况基本可以断定打分是照抄的。新版要求的是针对本项目的实际情况评估，照抄出来的分数没有任何决策价值。
4. AP 判出来之后的动作：优化、控制计划、文件化
前面几步做得再好，如果优化阶段糊弄，整套 FMEA 就还是个文档摆件。而这一阶段恰恰是企业最容易松懈的地方——风险都识别出来了，措施也列了，感觉上就算完成了。
4.1 AP=H 之后，两种典型的糊弄法
AP 判出 H 之后，处理方式有两种典型糊弄法，都挺常见。
第一种是用"已有控制"当挡箭牌。写上一句"现有控制措施已足够，无需额外措施"，然后就没有下文了。这句话本身不违规——新版确实允许对 H 项不采取措施，但前提是给出充分的技术理由。"已有控制"不是理由，"现有预防控制包含防错装置且经过 5000 次循环验证，实测失效率低于百万分之三"才是理由。区别在于前者是态度，后者是证据。
第二种是措施全是"加强培训""提高检验频次""要求供应商改善"。这三句话在优化阶段出现频率极高，但它们都属于软措施，既没有验证方式，也不知道做完之后 O 和 D 会变成多少。合格的措施要能回答四个问题：改什么、改到什么程度、谁来做、什么时候做完。对应到评分上，措施完成后要重新评估 O 和 D，写出措施后的分值。
还有一种更隐蔽的糊弄：措施写了很多，但一条都没落地。文件上措施状态全是"计划中"，落款日期还是三年前。这种情况评审的时候不用细看内容，扫一眼状态栏就能判断。措施状态必须如实标注，进行中就是进行中，取消就要写清为什么取消。
4.2 责任人写部门、措施没有验证闭环
责任人写"质量部""工艺部""供应商"，这是几乎每份不合格 FMEA 都会有的特征。原因也好理解——写部门不会得罪人，写人就要担责任。但责任人不落到具体的人，措施就没有推进的压力，也没有验收的对象。
这条其实很好改：责任人一栏填姓名，完成日期填具体日期，措施完成后由提出人验证并签注。措施有效性验证不是"文件上打了勾"，而是要看有没有客观证据——试验报告、过程能力数据、试产不良率、售后跟踪数据，什么形式都行，但必须是能查到的实物证据。
这里我想多说一句关于闭环的判断标准。措施闭环不是"措施执行完了"，而是"措施执行后，对应的 S/O/D 重新评估并确认风险已降到可接受水平"。有些团队措施做完了，分数没改，或者分数改了但没有任何证据支撑，这两种都不算闭环。
4.3 FMEA 与控制计划、特殊特性清单的联动断点
FMEA 不是终点，它的下游至少连着两样东西：控制计划和特殊特性清单。
先说控制计划。新版明确 FMEA 是控制计划的输入。FMEA 里识别出来的预防控制和探测控制，应该原样落到控制计划的操作步骤、控制方法、抽样频次、反应计划里。实际做的时候，这条链经常断——FMEA 改了一版，控制计划还是老版本，车间按老版本执行。这种断链在审核时是硬伤，因为它意味着整套风险分析没有转化成现场动作。
再说特殊特性。严重度高、或者涉及安全和法规要求的失效模式，对应的产品特性或过程参数应该被标为特殊特性，并在图纸、控制计划、检验规范里保持一致的标识。最常见的错误是三份文件各标各的：图纸上标了关键特性，控制计划里没体现，FMEA 里也没做对应的标注。这三者对不上，现场就不知道哪个参数必须重点管控。
提示：我一般会在 FMEA 定稿前做一次"三件套对齐"——把 FMEA 里的特殊特性清单、控制计划里的控制项、图纸上的特性标识摆在一起逐条比对。这个动作花半天时间，省掉的是几个月后的整改。
5. 我带队自查时用的几个问法和做法
讲了这么多错误，最后分享几个我实际带团队自查时用的办法。这些不是手册里的内容，是踩过坑之后自己总结出来的。
5.1 评审会上我一定会问的六个问题
评审会最怕开成朗读会——一个人从头念，其他人点头。我一般会跳过叙述部分，直接问下面这六个问题：
- 随机挑一条失效原因，请说出它对应下一级的哪个要素、哪个功能？
- 这条失效模式的失效影响，是写给哪一级客户的？对应哪条客户要求或法规？
- 严重度这个分，对应评分表里哪一档的行为描述？请念出来对一下。
- 这条 AP=H 的项目，如果不采取措施，理由是什么？有证据吗？
- 列出的措施完成后，O 和 D 预计变成多少？验证方式是什么？
- 这个失效模式对应的特殊特性，在控制计划里是哪一行？
这六个问题覆盖了链路完整性、评分依据、措施闭环、文件联动四个维度。能全部答上来的文件，基本可以放心。答不上来的，不用往下看了，直接返工。
这套问法还有个副作用：它能让"挂名签字"的人坐不住。因为问题不是问一个人，是问团队，谁答不上来谁尴尬。几轮下来，参与度会明显提高。
5.2 家族FMEA和基础FMEA：把重复劳动砍掉一半
最后说一个能显著提效的做法。新版在第一步里提出了基础 FMEA和家族 FMEA的概念，用大白话说就是：同一个平台、同一类结构的零部件，把共性的结构树、功能、失效模式、控制措施沉淀成模板，新项目在此基础上做增量修改，而不是每次都从空表开始。
我见过一家做电驱的企业，用这个思路把新项目的 DFMEA 起草时间从三周压到了一周左右。他们的做法是：按产品族（比如同功率段的电机控制器）建基础 FMEA，把通用失效模式和通用控制措施固化下来，新项目开工时先拷一份，再针对差异点（新的散热方案、新的芯片、新的封装）做局部重做。这样既保住了质量，也把重复劳动砍掉了大半。
但这个做法有个前提不能破：复用不等于照抄。拷过来的每一条都要过一遍，确认在当前项目的功能、环境条件、控制措施下依然成立。我就见过直接照抄导致失效原因跟实际设计完全对不上的情况——上一版用风冷，这一版改成水冷，照抄下来的"风扇失效"整条链全是废的。复用的价值在于省下搭框架的时间，不在于省下思考的时间。
真要说这几年在新版 FMEA 上最深的一点体会：这套方法的难点从来不在打分，而在于你愿不愿意把每一层关系真的推一遍。打分是最容易被看见的部分，也是最容易糊弄的部分；结构、功能、失效这三张网才是真正决定这份文件有没有用的东西。我见过太多团队在打分上反复纠结，却在结构树上随手画三个框，最后拿着 8 分的严重度不知道该怎么改——因为根子上就没推清楚这个失效到底伤到了谁。把前三步走扎实，后面的分其实是水到渠成的事；前三步糊弄过去，后面无论怎么调分数，都补不回来。
