上周帮一家做电驱总成的一级供应商看他们的 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 换成了措施优先级 APAction Priority分 H、M、L 三档而且明确说明AP 不是数值不设阈值不能简单排序了事。这件事的杀伤力比想象中大。我见过不止一个团队把 AP 先映射成数字H3、M2、L1再跟严重度相乘自己造了一个综合风险分出来然后按分数从高到低挑几条做改进。这等于把新版改成的东西又改回去了。AP 的逻辑是严重度 S 决定天花板频度 O 和探测度 D 决定落点。S 越高能落到 L 的空间越窄S 打到 9 或 10涉及安全、违反法规基本上只要是正常的 O 和 DAP 就会顶到 H。这时候不存在我打的分不高所以先放着这种操作空间。更关键的一点是新版要求APH 的项要么采取措施要么给出书面理由说明为什么不采取。也就是说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 APH 之后两种典型的糊弄法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 评审会上我一定会问的六个问题评审会最怕开成朗读会——一个人从头念其他人点头。我一般会跳过叙述部分直接问下面这六个问题随机挑一条失效原因请说出它对应下一级的哪个要素、哪个功能这条失效模式的失效影响是写给哪一级客户的对应哪条客户要求或法规严重度这个分对应评分表里哪一档的行为描述请念出来对一下。这条 APH 的项目如果不采取措施理由是什么有证据吗列出的措施完成后O 和 D 预计变成多少验证方式是什么这个失效模式对应的特殊特性在控制计划里是哪一行这六个问题覆盖了链路完整性、评分依据、措施闭环、文件联动四个维度。能全部答上来的文件基本可以放心。答不上来的不用往下看了直接返工。这套问法还有个副作用它能让挂名签字的人坐不住。因为问题不是问一个人是问团队谁答不上来谁尴尬。几轮下来参与度会明显提高。5.2 家族FMEA和基础FMEA把重复劳动砍掉一半最后说一个能显著提效的做法。新版在第一步里提出了基础 FMEA和家族 FMEA的概念用大白话说就是同一个平台、同一类结构的零部件把共性的结构树、功能、失效模式、控制措施沉淀成模板新项目在此基础上做增量修改而不是每次都从空表开始。我见过一家做电驱的企业用这个思路把新项目的 DFMEA 起草时间从三周压到了一周左右。他们的做法是按产品族比如同功率段的电机控制器建基础 FMEA把通用失效模式和通用控制措施固化下来新项目开工时先拷一份再针对差异点新的散热方案、新的芯片、新的封装做局部重做。这样既保住了质量也把重复劳动砍掉了大半。但这个做法有个前提不能破复用不等于照抄。拷过来的每一条都要过一遍确认在当前项目的功能、环境条件、控制措施下依然成立。我就见过直接照抄导致失效原因跟实际设计完全对不上的情况——上一版用风冷这一版改成水冷照抄下来的风扇失效整条链全是废的。复用的价值在于省下搭框架的时间不在于省下思考的时间。真要说这几年在新版 FMEA 上最深的一点体会这套方法的难点从来不在打分而在于你愿不愿意把每一层关系真的推一遍。打分是最容易被看见的部分也是最容易糊弄的部分结构、功能、失效这三张网才是真正决定这份文件有没有用的东西。我见过太多团队在打分上反复纠结却在结构树上随手画三个框最后拿着 8 分的严重度不知道该怎么改——因为根子上就没推清楚这个失效到底伤到了谁。把前三步走扎实后面的分其实是水到渠成的事前三步糊弄过去后面无论怎么调分数都补不回来。
新版FMEA常见错误：结构树、功能网与AP闭环的七步法落地指南
上周帮一家做电驱总成的一级供应商看他们的 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 换成了措施优先级 APAction Priority分 H、M、L 三档而且明确说明AP 不是数值不设阈值不能简单排序了事。这件事的杀伤力比想象中大。我见过不止一个团队把 AP 先映射成数字H3、M2、L1再跟严重度相乘自己造了一个综合风险分出来然后按分数从高到低挑几条做改进。这等于把新版改成的东西又改回去了。AP 的逻辑是严重度 S 决定天花板频度 O 和探测度 D 决定落点。S 越高能落到 L 的空间越窄S 打到 9 或 10涉及安全、违反法规基本上只要是正常的 O 和 DAP 就会顶到 H。这时候不存在我打的分不高所以先放着这种操作空间。更关键的一点是新版要求APH 的项要么采取措施要么给出书面理由说明为什么不采取。也就是说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 APH 之后两种典型的糊弄法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 评审会上我一定会问的六个问题评审会最怕开成朗读会——一个人从头念其他人点头。我一般会跳过叙述部分直接问下面这六个问题随机挑一条失效原因请说出它对应下一级的哪个要素、哪个功能这条失效模式的失效影响是写给哪一级客户的对应哪条客户要求或法规严重度这个分对应评分表里哪一档的行为描述请念出来对一下。这条 APH 的项目如果不采取措施理由是什么有证据吗列出的措施完成后O 和 D 预计变成多少验证方式是什么这个失效模式对应的特殊特性在控制计划里是哪一行这六个问题覆盖了链路完整性、评分依据、措施闭环、文件联动四个维度。能全部答上来的文件基本可以放心。答不上来的不用往下看了直接返工。这套问法还有个副作用它能让挂名签字的人坐不住。因为问题不是问一个人是问团队谁答不上来谁尴尬。几轮下来参与度会明显提高。5.2 家族FMEA和基础FMEA把重复劳动砍掉一半最后说一个能显著提效的做法。新版在第一步里提出了基础 FMEA和家族 FMEA的概念用大白话说就是同一个平台、同一类结构的零部件把共性的结构树、功能、失效模式、控制措施沉淀成模板新项目在此基础上做增量修改而不是每次都从空表开始。我见过一家做电驱的企业用这个思路把新项目的 DFMEA 起草时间从三周压到了一周左右。他们的做法是按产品族比如同功率段的电机控制器建基础 FMEA把通用失效模式和通用控制措施固化下来新项目开工时先拷一份再针对差异点新的散热方案、新的芯片、新的封装做局部重做。这样既保住了质量也把重复劳动砍掉了大半。但这个做法有个前提不能破复用不等于照抄。拷过来的每一条都要过一遍确认在当前项目的功能、环境条件、控制措施下依然成立。我就见过直接照抄导致失效原因跟实际设计完全对不上的情况——上一版用风冷这一版改成水冷照抄下来的风扇失效整条链全是废的。复用的价值在于省下搭框架的时间不在于省下思考的时间。真要说这几年在新版 FMEA 上最深的一点体会这套方法的难点从来不在打分而在于你愿不愿意把每一层关系真的推一遍。打分是最容易被看见的部分也是最容易糊弄的部分结构、功能、失效这三张网才是真正决定这份文件有没有用的东西。我见过太多团队在打分上反复纠结却在结构树上随手画三个框最后拿着 8 分的严重度不知道该怎么改——因为根子上就没推清楚这个失效到底伤到了谁。把前三步走扎实后面的分其实是水到渠成的事前三步糊弄过去后面无论怎么调分数都补不回来。
