做FMEA时，最容易写虚的一栏就是“影响”。很多表格里把影响写成一句笼统的“功能异常”就往下走，结果后面严重度打不准，措施也落不实。FMEA的基本逻辑并不复杂，先找失效模式，再看这个失效会带来什么后果，然后再评后果有多严重。VDA的公开资料把FMEA定义为一种结构化、系统化的方法，用来尽早识别失效及其风险，并通过措施把风险压下去；而APIS的FMEA表单说明也明确把effects放在失效模式之后、严重度评价之前。

　　一、FMEA失效分析影响怎么评

　　影响怎么评，先要把评价顺序收对。更稳的做法不是一上来就打分，而是先把影响写完整，再去判断严重度。VDA白皮书强调，FMEA的核心是尽早识别风险并定义减缓措施，这意味着“影响”这一栏首先要服务于风险判断，而不是只为了把表填满。

　　1、先从失效模式往后推后果

　　影响不是写失效动作本身，而是写失效发生后会造成什么结果。APIS的表单说明里把failure modes、effects和causes明确分开，这本身就在提醒一件事，失效模式和影响不能混着写。比如“信号丢失”是失效模式，“下级控制失效”才更接近影响。

　　2、尽量按层级把影响展开

　　FMEA实务里常见的影响层级包括local effect、next-higher level effect和end effect。相关可靠性资料把它们分别解释为本层影响、上一层系统影响以及最终对顶层系统或终端用户的影响。你在分析时就不会只停在局部零件，而会顺着失效一路往系统和用户端推。

　　3、严重度看的是影响，不是原因

　　严重度评分针对的是effect，不是cause。APIS手册在FMEA表单说明里把S rating明确放在effects之后，这说明严重度应该围绕“这个后果有多重”来评，而不是围绕“这个原因多常见”来评。

　　4、影响描述要能支持后续措施

　　如果影响写得太空，比如只写“性能下降”，后面很难决定到底该改设计、加控制还是补检验。VDA的白皮书强调，FMEA的目标是识别风险后定义合适的减缓措施，所以影响必须写到足以支撑后续行动的程度，而不是一句模糊结论。

　　二、FMEA对客户影响与对系统影响怎么区分

　　这两类影响最容易混。更直接一点说，系统影响看的是失效对上一层装配、子系统或整机功能造成了什么结果，客户影响看的是用户、整车客户、下道工序或外部使用者最终感受到什么问题。关于effect的分层资料把next-higher level effect和end effect区分得很清楚，前者是对上一级系统的后果，后者是对顶层系统和最终用户的后果。

　　1、系统影响先写功能链怎么断

　　系统影响更偏技术语言。它要回答的是，这个失效会不会让上一级模块功能缺失、性能降低、控制失步、保护失效，或者让整机的某项功能偏离设计目标。它首先面对的是工程团队，用来判断功能传播路径。

　　2、客户影响再写外部感知到什么

　　客户影响更偏使用结果。它要回答的是，用户会不会感到无响应、误动作、舒适性下降、质量缺陷、法规风险，或者安全风险。AIAG与VDA口径变化的解读资料也特别提到，effects的定义里要关注customer-user和制造过程客户等不同客户层次。

　　3、不要把客户影响写成内部术语

　　像“PWM丢失”“CAN超时”“执行器闭锁”这类说法更像系统影响，不是客户影响。客户影响更应该落到“功能不可用”“车辆无法启动”“制动辅助失效”“装配工位无法继续”等外部结果上。只有这样，严重度才容易统一。这个区分和end effect面向顶层系统及终端用户的定义是一致的。

　　4、同一条失效通常两层都要写

　　真正写表时，系统影响和客户影响往往不是二选一，而是前后两层都要有。先写系统层功能怎么受影响，再写最终用户或外部客户感知到什么，逻辑才完整。相关资料也说明，不同FMEA口径下可能只要求end effect，但把local和next level一并串出来，后续措施会更好落地。

　　三、FMEA影响描述怎么写清

　　很多FMEA到后面越做越散，不是团队不会分析，而是影响描述没有统一写法。更稳的做法，是先固定一条句式，再统一口径。可以按“本层发生了什么，上一级功能受到什么影响，最终客户会感受到什么”去写。这样做的好处，是同一团队看到不同条目时，能按同一结构理解和打分。相关资料对local effect、next-higher level effect和end effect的分层，本身就给了这种写法的基础。

　　1、先写清对象

　　先说明是哪一层对象出问题，比如零件、模块、工步或工序。对象不清，后面的影响就容易飘。

　　2、再写清后果链

　　不要只写一个终点，要写出后果是怎样往上游或下游传递的。这样做出来的effect才能支持团队讨论措施。

　　3、最后写到客户可感知层

　　只停在系统层，严重度常常打不准。把最终客户或最终使用场景写出来，风险高低才容易统一。

　　4、团队内部最好保留样例库

　　高频失效、高频客户影响和常见系统影响，最好沉成样例句库。这样新项目写effect时，不会每个人都用不同语言表达同一件事。这个做法虽然不是某一条标准原文，但和VDA强调方法输入、结果和统一应用方式的思路是一致的。

　　总结

　　FMEA失效分析影响怎么评，关键不是先打分，而是先把影响按后果链写完整，再围绕effect去评严重度。FMEA对客户影响与对系统影响怎么区分，关键则是分清系统影响面对的是功能链和上一层装配，客户影响面对的是最终用户或外部客户的感知结果。把这两层写开，再把本层、上层和终端层串起来，FMEA里的影响分析通常就会清楚很多。