在功能安全、质量策划、过程审核和设计评审这些工作里面，我们常常会碰到两个连在一起的问题，一个是FMEA的失效影响到底要展开到多细才合适，另一个是，如果对失效链路的梳理做得太深，又会带来什么样的麻烦，FMEA做得太粗，评审的时候就会被认为没有把风险给讲透，后面的控制办法也容易落空；可要是做得太细，又可能把整个团队拖进大量价值不高的推演当中，表格越写越厚，而真正需要优先去处理的高风险项，反而被淹没了，更稳当的一种做法，是把失效影响展开到“能判断风险、能定义控制、能分配责任”这个程度，而不是把每一个细枝末节都拆解成一条独立的失效链。
一、FMEA失效影响要展开到多细才合适
在FMEA里面，失效影响的描述并不是写得越长就越好，当然，也不能只用一句“功能失效”就算完成了，它要为后面的严重度评判、原因分析、预防控制还有探测控制提供依据，因此，展开的深度要能够支撑团队做出比较一致的判断。
1、要展开到用户或者系统能够察觉到的后果
失效影响至少要写到最终受影响的那一方可以感知的层面，像客户使用出现了异常、整车的功能受到了限制、设备停掉了、标签信息出错、数据没有办法追溯等等这些情况；如果只是写下“信号异常”“零件损坏”“程序报错”这类的话，那通常还是停留在内部的表面现象上，并没有把这个问题会造成什么样的后果给讲明白，评审的人一看到这种描述，就很难去判断严重度给得是不是合理。
2、要展开到能够把严重度区分开来的程度
假如两个失效模式所写出来的后果完全一样，可是后面给出的严重度评分却又不同，这就说明失效影响还没有被真正地讲清楚，比如“无法识别条码”和“条码识别延迟”，它们的后果都不能很简单地用一句“影响生产”就带过去，前者也许会带来误发、漏检或者追溯链条的中断，而后者，可能只是让生产的节拍稍微变慢了一点点，所以，影响的描述需要把风险之间的层级给拉开才行。
3、要展开到控制措施能够对应上去的位置
失效影响写完之后，要能够反过来推出控制措施应该怎么去设置，就拿“装配方向错误导致功能失效”来说，把影响写成这样，后面就能对应到防错的治具、装配的检测、作业的指导书和首件的确认这些具体的动作；如果只是很笼统地写上“质量异常”，那后面的措施就很容易变成一句空泛的“加强检查”，所以，一般只要写到控制措施能够具体落地的那一步，基本上就足够了。
4、不要把失效的原因和它带来的影响混到一起
失效影响是在说“会造成什么样的后果”，而失效原因是在解释“为什么会发生这件事”，比如“螺丝扭矩不足导致连接松动”，这句话其实更像是在描述原因再加上局部的现象，它真正所造成的影响，也许是在振动之后部件脱落了、信号中断了，或者是客户现场停了机，只有把这两层意思拆解清楚，FMEA的表格往后才不会越填越乱。
二、FMEA失效链路梳理过深会带来什么问题
FMEA是需要有链路思维的，可要是对链路的梳理做得太深，也一样会引出一些问题，在实际的项目里面，很多表格之所以会失控，并不是因为团队不够认真，而是因为他们把所有的可能性都当成了同等重要的分析对象，这么做的结果就是，文档变得越来越厚，可风险呢，却并没有因此而变得更加清楚。
1、表格会变得很膨胀，让评审抓不住重点
如果硬把一个失效模式拆成十几条非常细小的链路，表面上看着是挺详细的，可真到了评审的时候，反而很难快速判断出到底哪几条才需要被优先处理，这样一来，评审的会议就容易被一堆低风险的、发生概率很小的、很难去验证的推演给占满了，而那些真正后果严重、发生频率又很高的问题，反而被挤到了后面去。
2、责任之间的界限会变得很模糊
因为把链路拆得太深，就很容易把设计、工艺、供应商、检测，还有客户的使用场景，一股脑儿地全塞进同一张表格里，等到后面要去讨论措施的时候，每个部门都会觉得自己只需要对其中一小段负责，谁也不想把完整的闭环给接过去，FMEA原本是用来把风险的责任给讲明白的，可过度展开之后，反倒容易让责任变得很分散。
3、措施也会变成一种走形式的补丁
链路分得越细，措施就越容易被写成“加强培训”“增加检查”“优化流程”这类模糊的表述，因为好多被细分出来的链路，本身并没有独立去控制的价值，它只不过是主链路下面附带出来的一些现象，团队为了让表格看着完整，就只能给每一行都勉强补上一条措施，这样文档倒是能交付出去了，可现场并不会真的照着去执行。
4、维护的成本也会明显地往上涨
当产品发生了变更、工艺进行了调整，或者供应商被替换掉之后，那些做得太深的FMEA链路，都需要跟着做同步的更新，链路数量越多，漏掉修改的可能性也就越高，等到了客户审核或者内部复盘的时候，旧的风险、新的工艺、老的办法全都搅和在一起，反而会让这份FMEA的可信度大打折扣。
三、FMEA怎样判断分析深度是否合适
那么，要怎样去判断一份FMEA的分析深度是不是合适的呢，这不能只去数表格的行数有多少，也不能只看它的措辞是不是显得很专业，一种更管用的判断办法，是去看这份FMEA到底能不能帮着项目组把风险识别出来，把风险处理掉，并且在后面发生变更的时候，还可以继续被维护下去。
1、看严重度能不能被解释得清清楚楚
每一条失效影响，都应当能够撑得起严重度的打分，要是评分的人需要不停地追问“这个失效到底会影响到谁，又会影响到一个什么样的程度”，那就说明影响的描述，还需要再往深里展开一些；反过来，如果一条影响已经足够把后果说清楚了，我们还去继续追到很远的间接场景上，那就可能是做得过深了。
2、看原因能不能对应到团队可以控制的对象上
在顺着失效链路往下拆的时候，应当停在团队有能力去控制、可以去验证、也可以着手去改善的那个位置上，像材料的选型、参数的设定、装配的工序、检测的方法、软件的运行逻辑、供应商来料的质量，这些都是能够对应出具体行动来的；可要是继续往下拆到一些很难去验证的偶然情景里，那价值就不大了。
3、看那些措施是不是真的能够被执行下去
一份分析深度恰当的FMEA，它后面的措施，应当是能被具体的人员去执行的，并且能在图纸上、在规范里、在检验的记录中、在测试的报告里，或者在作业的文件里面留下痕迹，要是那些措施只能够被写成一些空洞的口号，那往往就说明，前面拆解链路的办法是不太合适的，需要把它们合并起来，或者重新去归一下类。
4、看后期的维护工作团队是不是承受得住
一份FMEA并不是评审结束就算完了，后面还要跟着设计上的改动、过程上的变化、客户的投诉，还有现场冒出来的问题，继续去更新它，分析所保持的深度，要能让团队维护得动才行，一份能够被长期更新的FMEA，比起那种一次性写得很细、但后面再也没人去看的FMEA，价值要大得多。
总结
总的来说，关于FMEA失效影响要展开到多细才合适，以及失效链路的梳理如果做得过深会带来哪些问题，核心的判断其实并不复杂：影响，要写到能够用来判断严重度；链路，要拆到能够用来定义控制措施；而原因呢，则要停在团队有能力处理的那个位置上，如果做得太粗，风险就会被轻描淡写地带过去；可要是做得太深，又会让文档膨胀起来，责任变得分散，措施也走了形式，一份好的FMEA，并不是要把所有的可能性都一股脑儿地写进去，而是要把那些真正会影响到产品质量、安全、交付，还有使用体验的风险给讲清楚，并且让后面跟进的行动能够稳稳地接得住。
