FMEA失效模式怎么识别FMEA失效模式写得太宽泛怎么办，在做项目的风险分析时，不少人就是卡在了这个地方。光把表格填满，并不等于分析已经管用了，经常见到的一个问题是，失效模式被写成了很空泛的大话，比如“功能异常”“性能下降”“系统失效”，这些说法看上去没有错，可是一到了后面要去展述原因、影响和控制手段的时候，就很难再往下展开了。FMEA如果要真正派上用处，失效模式是必须落到具体的对象和具体的表现上的，不能只是浮在“坏了”“不工作了”“没有达到要求”这种含糊的层面上。

　　一、FMEA失效模式怎么识别

　　在识别失效模式的时候，不应该一开头就问“这个零件它会怎么坏”，更合适的问法是先去想“这个对象原本是要完成什么功能的”，等到功能被说清楚了，再来写失效模式，这时候才容易写得准确一些，要不然就很容易把原因、表现出来的现象，还有后面造成的影响，这些东西全搅和到一起，表格越是往后填，就越显得没有条理。

　　1、先从功能出发

　　要围绕【功能要求】到【失效表现】这个思路来拆，先把对象应该完成的功能给确认下来，接着再去判断它可能会通过什么方式偏离这些功能上的要求。就用一个传感器来作例子，它的功能是向外提供准确的位置数据，那么失效模式就可能被写成“位置数据完全丢失”“位置数据卡死在一个数值上不动”“位置数据漂移出去了允许的范围”，这些写法就比笼统地写一句“传感器故障”要明白不少。同样是出了毛病，数据是丢了、卡住了、漂走了、还是反应慢了，它们给系统带来的冲击，以及后面要跟上去的控制办法，其实都是有差别的。

　　2、把失效模式和失效原因区分开

　　有不少FMEA写得模糊，就是因为直接把发生的原因当成了失效模式。例如“焊点虚焊”这话就更像是原因，而“信号出现间歇中断”才更像失效模式的样子；“软件逻辑存在错误”偏于讲原因，“输出的状态出现了差错”才是那种能从外部观察到的失效表现。失效模式最好是去描述对象在外面显露出来的不正常状态，而不要一下子就把内部的原因给写了出来。

　　3、结合接口和边界来进行检查

　　把【输入信号】、【输出结果】、【通信接口】还有【工作条件】都一块儿拿进来查一查，别光把眼睛盯在单个零件自身上。有些时候，失效倒不见得是那个对象完全坏掉了，而是在接口的位置上才暴露出来，比如说输入信号是正常的，可是输出的响应却慢了很多；通信虽然能接收到东西，但数据老是不见更新；模块自己明明还在运转，偏偏没有给下游提供正确的状态。这些存在于边界上的地方是很容易被漏掉的，在系统FMEA和软件FMEA里面，就更加明显一些。

　　二、FMEA失效模式写得太宽泛怎么办

　　当失效模式被写得太宽泛了，后面常常就要跟着冒出三个毛病：影响写不细，原因分析散成了一片，预防和探测的措施也跟着变得空洞。像“功能异常”这种话，后面可以对接上随便哪一个原因，也可以引出随便哪一种影响，弄到最后，这一条记录就失掉了分析的价值。处理这种情况，并不是把句子加长，而是要把对象、偏差的方向，还有条件，一样一样地交代明白。

　　1、把那些“大词”拆分成能够观察到的表现

　　像“异常”“失效”“错误”“不稳定”这一类的词，不宜拿来单独使用，最好再往下拆分一层。比如“通信异常”，可以给拆成“通信中断”“通信出现延迟”“报文整个丢失”“报文里的内容发生了错误”“报文的周期不太稳定”，等拆分完了之后，哪一类情况需要去检测超时，哪一类需要去校验数据，哪一类又该进入降级运行的那套策略，就会变得清楚很多了。

　　2、补充上偏差的方向

　　很多失效模式只是写了“压力异常”“电压异常”“温度异常”，却没有点出来到底是变得过高、过低、来回波动、反应滞后，还是一直僵在那里不动。偏差的方向只要不一样，背后的风险往往是完全不同的。电压过高也许就会把器件给打坏，电压过低则有可能会引发复位的动作，而电压来回波动说不定又会造成那种间歇性的故障，这些情况实在不应该被统统合并成一条“电压异常”来处理。

　　3、不要把多个问题硬塞进同一条里面

　　一条失效模式，最好是只去表达一种主要的异常。要是写成了“信号丢失或者错误或者延迟”，那后面跟着的原因和措施就会变得非常驳杂，很难着手去处理。比较稳妥的办法，是按照主要的失效表现拆分成几条，然后再各自去分析它的严重程度、发生的频度，还有被探测到的可能性。FMEA的目的并不是为了在表格里省下几行字，而是为了把风险给讲得清晰一些。

　　三、FMEA失效模式怎么写得更能落地

　　失效模式写得好不好，最终还是要看它能不能支撑得住后面的措施。如果一个失效模式，总是没办法对应到具体的原因、检验它的方法，还有改善的动作上，这就说明了它还不够具体。在项目评审的时候，与其去追着表格在形式上是不是完整，还不如狠狠地盯住几条风险比较高的失效，看看它们是不是真的被分析到了位。

　　1、让对象的名称出现在开头

　　写失效模式的时候，尽量把对象的名字给带出来，比如“阀门已经无法关闭了”“传感器吐出来的数值偏高”“控制信号被延迟了才往外送”，这样一来，看的人就用不着去猜这一条记录到底说的是哪一个环节，对象越是清楚，后面去分配责任，还有去跟踪措施的路线，也就会跟着方便不少。

　　2、要让措施能够接得上

　　拿【失效模式】去和【现有控制措施】放在一起比对，要是那些措施根本解释不清楚这条失效是怎么被事先预防住的，或者是怎么被事后探测到的，那就要回过头去，再把失效模式的描述给调整一下。比方说失效模式写的是“系统异常”，措施写的是“增加测试”，这样的话基本上没什么判断上的用处；如果改写成“温度采样的数值老是在一个数上僵着不动”，措施就可以对应到合理性的检查、变化率的监控、传感器的诊断，或者是故障的提示了，后面再去验证的时候也会更有方向一些。

　　3、留下必要的评审痕迹

　　FMEA这件事，并不是靠着一个人闷头填表就能把它做好的，搞设计的、做测试的、管工艺的、负责质量的，还有那些售后的人，他们各自看到的问题常常是不一样的。尤其是对于已经做了有些年头的项目，可以把历史故障、现场返回来的问题，还有维修的记录都拿出来翻一翻，有一些失效模式其实并不是凭空想象出来的，而是过去就已经实实在在发生过的，只不过当时在表格里面没有被写清楚罢了。

　　总结

　　总的来看，FMEA的失效模式应该怎么样去识别，以及当失效模式被写得太宽泛的时候又该怎么样去处理，这里面关键的地方并不是要把表格填得有多么满当，而是要把失效的表现写到能够进行分析、能够做出判断、能够顺势推出措施的程度。在识别的时候，要先从功能那里起步，然后再把原因、模式和影响给区分开；等碰到描述太过宽泛的情况时，就去把具体对象拆出来，把偏差的方向拆出来，把可以观察到的表现也拆出来。这样一路写下来的FMEA，才不至于变成一份只用来走形式的文件，而是真的能帮着项目，提前一步把那些还藏着的风险给翻找出来。