做FMEA时，发生度最容易被打分打偏。真正常见的问题，不是团队不会填1到10，而是把“故障后果严重不严重”和“原因出现得频不频繁”混到了一起。公开资料里对这件事说得很清楚，FMEA风险排序本来就是围绕严重度、发生度和探测度三维展开，而发生度评的是发生频次，不是影响大小；在DFMEA和PFMEA的公开评分表说明里，发生度也都直接写成了“Cause的发生”以及“基于已知数据或缺少数据的估计”。

　　一、FMEA分析怎么做发生度

　　做发生度时，不要先看客户抱怨大不大，而要先把“哪一个原因在发生”说清楚。发生度不是给失效模式整体打感觉分，更不是给后果打情绪分，它对应的是某个失效原因在当前设计或过程里出现的频次。公开PFMEA资料里把这一点写得很直接，发生度是对原因发生概率的估计，而且要结合已知数据、相似技术经验或新技术的不确定性来判断。

　　1、先把原因写到能计数

　　像“装配不良”“设计不好”这种写法太虚，后面没有办法量化。更稳的写法，是把原因落到能统计的对象上，比如某工序漏装、某尺寸漂移、某焊点虚焊、某软件条件判断失效。原因写得越具体，发生度越容易建立在数据上。这个做法和PFMEA公开资料里“先定义Failure Cause，再评Occurrence”的逻辑是一致的。

　　2、再判断是相似技术还是新技术

　　如果当前产品、工艺或设计和历史项目高度相似，发生度就应该优先参考已知历史；如果属于新设计、新工艺或新技术，评分就不能假装自己“有很多成熟经验”。公开评分表里对known or similar technology和new technology是分开写的，这一步其实就是在判断你该走哪条评分口径。

　　3、最后才把频次映射成等级

　　发生度的本质不是拍脑袋选数字，而是先有频次判断，再去对照等级表。公开表格里已经给出了典型频次区间，例如相似技术场景下从1 in 1,000,000到1 in 10的梯度，以及新技术场景下从isolated、occasional到no experience with technology的分档。也就是说，数字只是最后一步，前面一定先有频次依据。

　　二、FMEA发生度基于数据怎么量化

　　基于数据量化时，重点不是把数据堆得很多，而是把口径统一。公开资料已经说明，发生度是基于已知数据的估计，而且典型表格本身就是按发生频次来划档，所以最实用的落地方式通常是：先选一个固定统计口径，再把历史数据换算成“每多少次机会发生一次”，最后映射到等级表。

　　1、先定分母，不要边算边换

　　你可以按件数、批次、工位操作次数、测试次数或使用循环数来统计，但一张FMEA里同一类原因最好只用一种分母。因为公开表格给的是发生频次区间，如果分母今天按台数、明天按工单，最后再高明的评分表也会被带乱。这里的“统一分母”是根据公开频次表作出的量化原则。

　　2、再把历史记录换成频次

　　更实用的算法通常就是“某原因发生次数÷对应机会总数”。算完以后，不要直接把小数写进FMEA，而是换算成“约每多少次出现一次”，再去对照发生度等级。因为公开表格本来就是按这种频次表达方式展开的。

　　3、数据不足时要写明依据

　　公开资料里已经明确提到，发生度可以基于known data，也可能是在lack of data的情况下做估计。所以当样本量还不够、项目又很新时，最稳的做法不是装作精确，而是在表里注明是类比数据、试验数据还是专家估计，并在后续量产或验证后回头修订。

　　4、量化结果要能回到原因本身

　　如果一条数据只能证明“这个失效模式以前出过”，却不能对应到当前正在评分的那个原因，那这条数据就不够干净。发生度评的是Cause的发生，不是Effect的热度，所以真正有用的数据必须能回到那条具体原因，而不是只停在投诉总量或不良总量。

　　三、FMEA发生度数据先看哪些口径

　　真正把发生度做稳，关键不在表格本身，而在你先拿什么数据来支撑。比较稳的做法，通常不是一上来就翻所有质量报表，而是先抓最贴近原因的几类数据：相似产品或工艺的历史失效频次、开发验证中的重复问题、当前过程里的实际异常记录。这样做的逻辑很简单，因为公开资料已经把发生度定义成基于已知数据或缺少数据情况下的原因发生估计，所以越贴近原因的数据，越值得优先用。

　　1、先看相似技术历史

　　如果产品和工艺不是全新方案，历史项目数据通常最有参考价值。它最大的好处不是“多”，而是口径相对稳定，容易直接映射到发生度表。

　　2、再看开发和验证阶段暴露的问题

　　公开表里对occasional failures in development and verification testing也给了典型分档，这说明验证阶段的问题本来就可以拿来支撑发生度，而不是只能等量产后再评分。

　　3、最后再看量产和现场反馈

　　量产和现场数据当然重要，但前提是它能回到具体原因。只要能把投诉、返修、不良和失效分析结果对应到同一原因，它们就不是“后果数据”，而是发生度的真实输入。这里是把公开定义里的cause occurrence落到项目实践中的最直接用法。

　　总结

　　FMEA里的发生度，说到底评的不是后果有多吓人，而是原因有多常见。真正做的时候，先把原因写具体，再判断是相似技术还是新技术，接着把历史或验证数据换成频次，最后再映射到等级表，这条路最稳。要是数据不够，也不是不能评，但要老老实实写清是估计还是类比，并在后续拿到真实数据后及时回调。这样做出来的发生度，才不是一串“看起来专业”的数字，而是真能被团队复核、被项目更新、也能在后续改进里用得上的评分。