
在质量管理中,所谓“根本原因(Root Cause)”并不是换一种说法描述问题,也不是找到某位犯错的员工,更不是一路追问“为什么”直到无法继续。真正有价值的根本原因,应当与问题存在清晰的因果关系,并且能够通过具体措施加以控制或消除。判断根因是否找对,一个很实用的标准是:针对这个原因采取措施后,同类问题再次发生的可能性是否会实质下降?
一、为什么质量管理如此强调“根本原因”?
现场出现异常以后,最快的处理方法通常是解决眼前的问题。
发现不良品,就挑出来;设备参数错了,就重新调整;操作员拿错物料,就提醒他以后注意;客户收到错误产品,就赶快补发。
这些措施可能都是必要的,却未必属于真正的纠正措施。
问题在于,如果造成异常的机制仍然存在,那么今天处理完,明天换一个人、换一个班次、换一批产品,同样的问题仍可能再次出现。
这正是根本原因分析(Root Cause Analysis,RCA)的价值:它关注的不是“这一次怎样恢复正常”,而是“什么机制使这类问题能够发生,以及怎样改变这个机制”。

在8D、CAPA、客户投诉处理以及DMAIC改善项目中,这种区别尤其重要。围堵措施(Containment)可以控制当前风险,纠正(Correction)可以处理已经发生的不符合,但真正有效的纠正措施(Corrective Action)必须针对导致问题发生的原因。
二、把问题重新描述一遍,不叫根本原因
假设供应商交付了5000个塑料外壳,检验发现产品正面存在明显划痕。
问题描述是:
“塑料外壳正面出现划痕。”
如果供应商提交的原因分析写成:
“根本原因:产品表面被刮伤。”
这实际上没有提供任何新信息。
客户已经知道产品有划痕。真正需要回答的是:
划痕是怎样产生的?为什么会产生?为什么没有在出货前发现?
继续调查后,可能得到这样的因果链:
成品表面出现划痕
↓
产品周转过程中发生相互摩擦
↓
周转箱内产品之间没有有效隔离
↓
现行包装规范没有规定隔离方式
↓
新产品导入时,包装设计没有进行表面损伤风险评估
到了这里,改善方向已经完全不同。
如果把“划痕”当根因,几乎不知道该改善什么;如果找到包装规范和产品导入流程上的缺口,就可以修改包装标准、增加隔离材料,并在新产品导入检查项目中加入表面防护要求。
这才开始具有预防再次发生的意义。
三、“员工操作失误”为什么通常不是一个好的根本原因?
质量问题调查中最常见的结论之一是:
Human Error——人为错误。
例如:
“操作员忘记检查。”
“员工选错了物料。”
“检验员没有发现缺陷。”
“仓库人员贴错标签。”
这些描述可能是事实,但通常只是直接原因,并没有解释为什么系统允许一次普通的人为失误直接演变成质量事故。
假设仓库员工 Fred 发错了一批非常重要的货物。
一种处理方式是:
原因:Fred 工作失误。
措施:批评 Fred,加强培训,要求以后认真检查。
极端一点,甚至可以直接辞退 Fred。
可是第二天换成 Max 操作,如果订单界面仍然容易混淆、两个料号仍然非常相似、拣货系统没有扫码验证、出货前没有独立核对,Max 完全可能犯同样的错误。
所以更有价值的问题不是:
“Fred 为什么犯错?”
而是:
“为什么 Fred 的一次错误能够一路通过整个流程,最终到达客户?”
这会把调查方向从“找责任人”转向系统设计。
四、真正的根本原因需要具备哪些特征?
一个值得采取纠正措施的根因,通常至少应该通过下面几个检验。
1. 与问题存在合理的因果关系
原因不能只是与问题同时出现,也不能仅仅因为“听起来有道理”就被认定为根因。
一个简单方法,是把分析结果反过来读。
假设分析得到:
A问题 ← B原因 ← C原因 ← D原因
那么应该能够合理地表达为:
因为D,所以导致C;因为C,所以导致B;最终导致A。
如果反过来以后逻辑明显断裂,就说明因果链中可能混入了猜测、相关因素或者未经验证的假设。
在正式的质量改善中,重要原因最好进一步通过数据、现场重现、对比试验或假设检验等方法验证,而不是仅凭会议讨论决定。
2. 不能只是问题本身的另一种说法
“尺寸超差”的原因不能只是“尺寸太大”。
“焊接强度不足”的原因不能只是“焊点不牢”。
“客户收到错误产品”的原因不能只是“发错货”。
一个实用判断方法是问自己:
知道这个所谓的“根因”以后,我们是不是比调查前多知道了某些可以指导行动的信息?
如果答案是否定的,通常还没有挖到真正有用的原因。
3. 不应停留在责怪某个人
“张三粗心”“员工责任心不足”“检验员不认真”都是非常危险的根因表述。
这类结论不仅容易把原因分析变成追责会议,而且很难形成可靠的预防机制。
当然,这并不意味着人员行为永远不能成为因果链的一部分。
“操作员选择了错误程序”完全可能是事实。接下来真正值得调查的是:
为什么设备允许选择错误程序?
程序名称是否容易混淆?
不同型号是否能够通过条码自动调用程序?
错误程序运行以后有没有报警?
首件确认为什么没有发现?
工作指引是否清楚?
这里可以借助5 Why继续追问,但重点不是机械地问满五次“为什么”,而是找到具有改善价值的系统原因。
4. 原因应该能够采取行动
假设分析某次火灾,发现燃烧能够持续是因为空气中存在氧气。
从物理意义看,这当然存在因果关系。
但“地球大气中有氧气”显然不是一个有实际管理价值的根本原因,因为企业无法把消除地球氧气作为纠正措施。
好的根因应该最终连接到可以管理的对象,例如设备设计、工艺参数、材料要求、维护机制、检验方法、软件逻辑、作业标准、培训机制、防错设计或管理流程。
根因分析不是寻找宇宙中最底层的原因,而是寻找足够深入、因果成立并且能够产生有效对策的原因。
五、“培训员工”和“以后注意”为什么经常效果有限?
很多纠正措施报告最后都会出现类似内容:
“已对相关人员重新培训。”
“要求员工提高质量意识。”
“提醒操作人员严格按照SOP执行。”
培训当然有价值。如果调查确认员工确实没有接受必要培训,那么补充培训完全合理。
问题在于,培训经常被当成一种万能纠正措施。
例如员工把A零件装到了B产品上。如果两个零件外形高度相似,而且都放在相邻料架上,仅仅要求员工“仔细辨认”,实际上是在要求人长期保持100%的注意力。
更可靠的措施可能是改变料架位置、采用明显不同的容器、扫描物料条码验证、增加工装防错,使错误零件无法装入,或者让系统自动检查产品型号与物料编号是否匹配。
这里体现的是质量管理一个非常重要的思想:
不要把系统可靠性建立在“人永远不会犯错”的假设上。
真正成熟的系统会假设人可能疲劳、分心、记错、看错和按错,并通过流程和防错机制降低错误发生的概率,或者阻止错误继续流向下一道工序。
六、根本原因要追到多深才算结束?
这是RCA中最容易争论的问题。
使用5 Why时,有人认为一定要问五次;有人不断向下追问,最后所有问题似乎都可以归结到“管理体系”“企业文化”甚至更宏观的因素。
两种做法都没有必要。
根因分析应该追到能够解释问题,并能够产生合理、有效、可验证纠正措施的深度。
例如:
客户收到错误标签
↓
包装人员选择了错误标签模板
↓
系统同时显示多个外观近似的模板
↓
模板通过人工名称选择,没有绑定产品料号
↓
标签系统设计时没有建立产品料号与唯一模板的自动映射
如果证据支持这条因果链,那么“没有建立料号与标签模板的自动映射”已经能够产生非常明确的系统改善方案。
继续问:
“为什么当年负责系统的人没有设计这个功能?”
“为什么公司当时没有想到?”
未必还能产生更有价值的措施。
所以,不是问得越深越专业,而是找到能够改变问题发生机制的层级。
七、别忘了分析“为什么发生”和“为什么逃逸”
实际质量问题往往不只有一个根因。
特别是客户投诉,至少值得从两个方向调查:
发生原因(Occurrence Cause):为什么缺陷会产生?
逃逸原因(Escape Cause):为什么现有控制没有发现它?
仍以前面的塑料外壳划痕为例。
发生原因可能是包装过程中产品相互摩擦;逃逸原因则可能是最终检验采用抽样方式,而检查规范没有要求在特定光照角度检查外观。
如果企业只改善包装,却没有检讨检测系统,那么其他类型的外观异常仍可能逃逸到客户。
反过来,如果只是加强最终检验,虽然短期能够拦截不良品,却没有消除产生划痕的机制。
所以成熟的根因分析往往需要同时问:
它为什么会发生?我们的控制系统为什么没有阻止或发现它?
八、怎样判断自己找到的是不是“真正的根因”?
完成分析以后,可以用几个问题进行自检:
- 这个原因是否解释了问题是怎样发生的,而不是重新描述问题?
- 因果链从原因到结果能否顺畅地读通?
- 有没有现场证据、数据或实验支持这个判断?
- 是否把“某个人粗心”错误地当成分析终点?
- 针对这个原因,是否能够制定具体的纠正措施?
- 措施实施以后,能否降低同类问题再次发生的概率?
- 如果换一个员工、换一个班次,原来的风险是否仍然存在?
- 对于流到客户的问题,是否同时调查了发生原因和逃逸原因?
如果所谓的纠正措施最后仍然只有“加强培训”“提高意识”“要求员工注意”,值得重新检查一次:是不是根因分析停得太早了?
九、根因分析的目标不是找到一个漂亮答案,而是改变系统
根本原因分析最容易走偏的地方,是把“找到Root Cause”本身当成任务终点。
真正的终点其实是防止问题再次发生。
鱼骨图、5 Why、故障树、Pareto分析等都只是帮助思考和验证原因的工具。工具用得再完整,如果最后没有改变导致问题发生的机制,RCA仍然没有完成它的任务。
优思学院在六西格玛及质量改善课程体系中,会把根因分析放在完整的问题解决逻辑中理解:从问题定义、数据测量、原因分析,到改善方案及控制,而不是孤立地学习某一种分析工具。对于需要系统掌握这套方法的质量工程师和改善人员,可以进一步学习六西格玛绿带课程中的DMAIC问题解决体系。
记住一个简单的判断标准即可:
好的根因,不是“最深”的原因,也不是最方便写进报告的原因,而是经过证据支持、能够解释问题发生机制,并且针对它采取行动后,可以实质降低问题再次发生概率的原因。
如果今天解决的是这一件不良品,明天同样的问题还可能原样发生,那么处理的很可能只是症状;如果改善之后,即使换了人、换了班次,系统本身也更难产生同类错误,这才是根因分析真正想达到的结果。




