FMEA严重度怎么评分FMEA严重度评分依据怎么统一，团队坐下来打分时，最怕的就是各人凭感觉随口给个数字，事先没一把大家认下的尺子。关键是要先看失效闹出来的后果是轻是重，再把评分的口径死死定住。在常见的做法里头，严重度多半照着1到10分去定，1分就是说影响小得几乎叫人觉不着，10分可就代表灾难一级的后果，或是牵涉到人身安全那类事了；要是同一个失效模式拖着好几个不同的后果，一般就捡那个最糟的后果来往上头安分数。

FMEA和控制计划之间，容易出现一种情况，就是风险分析做得很细，到了现场控制那一层，却没有完整地接住，在汽车零部件、电子装配、机加工还有注塑这类项目里面，这个问题尤其常见，FMEA评审的时候，失效的模式、失效带来的后果、背后的原因、预防的措施还有探测的办法，都列了不少，可等到了控制计划这个阶段，现场真正需要去控制的那些尺寸、参数、工装的状态、检测的频次，反而没有完整地衔接上，表面上看，两个文件好像都做完了，可真要仔细一查，就会发现，风险分析还留在当初开会的表格里，控制计划也只是挂在生产现场的表格里，中间那一次认真的传递，被漏掉了。

在研发评审、质量策划以及客户审核这些场合里，大家经常会问到这样一个问题：FMEA的七步法是不是每一个项目都需要完整地做下去，还有，当我们对七步法做裁剪的时候，通常会把哪些步骤保留下来。七步法本身提供的是一套完整的分析路径，但不同的项目，规模不一样，产品的成熟度不一样，变更的范围不一样，客户提出的要求也不一样，如果直接就把整套流程照搬过来，有时候会让简单的问题变得很重；反过来，要是裁剪得太随便了，到评审的时候又很难说清楚为什么有些内容没有去做。所以，真正需要我们搞明白的是，哪些步骤属于风险分析里面的骨架，哪些内容可以适当地简化，又有哪些证据是一定要留下来的。

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

FMEA在很多团队里会越做越乱，根因通常不是方法不会用，而是版本口径不统一：同一个失效模式有人改了评分，有人改了控制措施，还有人把行动项改成了另一套编号，最后评审时只剩下对不上与说不清。把FMEA放进软件里做版本管理与变更追踪，本质是把谁改了什么、为什么改、改完如何验证写成可审计的链路，后续复评与交付才不会靠翻聊天记录。

FMEA做到后期，最耗时的往往不是列失效模式，而是围绕严重度、发生度、探测度的打分拉扯不清，导致同一条风险在不同批次评审里反复改来改去。要让评分争议可控，关键不是谁嗓门大，而是把证据口径、会审节奏、裁决规则提前定死，并把每次结论沉淀为可追溯的记录。

围绕“DFMEA与PFMEA怎么区分，FMEA的不同类型怎么选用”，很多争议并不是大家不懂概念，而是分析对象、时间点、输入资料与评分口径没有统一，导致同一条失效在不同表里被写成了不同故事。把区分点说清楚，再把选型步骤写成可执行动作，你的FMEA才能在评审、变更与再评估时稳定复用。

FMEA做完不复审，很容易变成一次性文档，现场工艺改了、设计变了、客诉来了，表里还是旧结论，评审时就会被追问风险控制有没有跟上。复审和版本管理要一起做，复审负责把风险结论更新到最新事实，版本管理负责让每一次更新都能追溯到原因、批准人和验证证据。

很多团队FMEA做得不差，问题出在措施落地时变成口头承诺，责任边界不清、验收条件不明确、证据分散找不到，最后审核一抽查就露馅。要把“做过FMEA”变成“FMEA能控制风险”，关键是把行动项写成可执行、可验证、可追溯的任务，再用固定节奏与硬性门槛推动按期关闭。下面按落地纠偏、跟踪闭环、审计友好三条线，把做法拆成你可以直接照搬的步骤。

很多人把FMEA当成一款软件在找按钮，其实FMEA首先是一套失效预防的方法论，软件只是把表单、评分、行动项与追溯关系做成可复用的载体。把这点先分清，你后面选工具、建模板、过评审都会顺很多，尤其是在需要证据链与版本管控的质量体系里。