5Why 和鱼骨图怎么结合使用

很多人搜“5Why 和鱼骨图怎么结合使用”，其实就是想把一次问题复盘做得更有效：先别急着拍脑袋定结论，也别开会列一堆原因最后不了了之。

最稳的做法是：先用鱼骨图把可能原因按类别铺开（找全），再从最关键的 1–3 条分支用 5Why 连续追问（找深）。最后你得到的不是一张“看起来很完整”的图，而是一份能执行的清单：先验证什么、谁来负责、怎么预防复发。

为什么很多团队会把 5Why 和鱼骨图一起用

单独用 5Why，优点是路径清晰，容易逼近根因；缺点是如果第一个“为什么”就问偏了，后面可能越问越窄。

单独用鱼骨图，优点是原因覆盖面广，适合多人讨论；缺点是容易停留在“列原因”的层面，最后看起来很完整，实际上没有找到最该处理的点。

所以把两者放在一起，逻辑会更顺：

• 鱼骨图负责展开全貌：先把人、机、料、法、环、测，或者流程、沟通、资源、制度等可能因素列出来
• 5Why 负责继续下钻：从最可疑、最关键、最可验证的原因开始，一层层追问
• 最后形成可执行动作：不是停在“知道原因”，而是落到“怎么改、谁负责、多久验证”

如果你们的场景是质量异常、项目延期、客户投诉、生产事故、线上故障、复盘分析，这种组合基本都比单独用其中一个更实用。

两个工具的分工，先搞清楚就不容易用乱

鱼骨图解决的是“原因有没有找全”

鱼骨图最适合在问题刚被提出的时候使用。因为这时团队往往还不知道真正原因是什么，需要先把可能性展开。

比如“交付延期”这个问题，背后可能牵涉到：

• 需求反复变更
• 人手不足
• 排期不合理
• 上下游依赖卡住
• 测试时间被压缩
• 审批流程过慢

如果一开始不做展开，团队很容易直接认定“就是执行力不够”，这通常会误判。

5Why 解决的是“这个原因到底为什么会发生”

当鱼骨图上已经列出一批可能原因后，就不能继续泛泛而谈了。此时要把注意力收拢到重点分支，使用 5Why 往下挖。

举个简单例子：

• 问题：项目延期
• 鱼骨图中发现一个关键原因：测试阶段反复返工
• 为什么测试阶段反复返工？因为需求理解不一致
• 为什么需求理解不一致？因为评审时没有统一验收标准
• 为什么没有统一验收标准？因为 PRD 只写了功能，没有写边界条件
• 为什么边界条件没有写？因为需求模板里没有强制项
• 为什么模板里没有强制项？因为项目早期没有建立标准化需求评审机制

这时候你就会发现，表面上看是“测试返工”，实际上更深层的问题是“需求管理机制缺失”。这就是 5Why 的价值。

正确的结合顺序：先铺开，再下钻

如果你想把这两个工具真正用顺手，可以直接按下面这个流程做。

第一步：先把问题写具体

不要写“效率低”“质量差”“客户不满意”这种空话。问题越空，后面的分析越飘。

更好的写法是：

• 为什么 3 月份某产线不良率升到 4.8%？
• 为什么这个项目比计划晚了两周上线？
• 为什么最近一个月客户投诉集中在交付时效？

一个能被衡量、能被限定范围的问题，才适合后续分析。

第二步：先画鱼骨图，把可能原因列全

这一阶段不要急着证明谁对谁错，先把原因展开。常见做法有两种：

用通用分类法

适合制造、质量、现场管理场景：

• 人
• 机
• 料
• 法
• 环
• 测

用业务自定义分类法

适合互联网、项目管理、客服、运营场景：

• 需求
• 流程
• 工具
• 协作
• 人员
• 数据
• 外部依赖

关键不是分类多高级，而是让团队能顺着分类把原因说完整。

第三步：圈出最值得深挖的 1 到 3 个分支

鱼骨图列完以后，往往会出现很多候选原因。不要每一条都做 5Why，不然会议会非常散。

更实用的筛选标准是：

• 出现频率最高
• 对结果影响最大
• 最容易被数据或现场证据验证
• 解决后最可能明显改善结果

通常选 1 到 3 个关键分支继续分析就够了。

第四步：对关键分支做 5Why

这里有一个常见误区：5Why 不是机械地一定要问满五次，而是要追到可干预、可验证、可落地的层级。

也就是说，下面这种追问没有意义：

• 为什么员工没注意？
• 因为不够认真。

“因为不够认真”几乎无法改进，也无法验证。更好的追问是：

• 为什么没有注意到？
• 因为交接单没有关键字段提醒。
• 为什么交接单没有提醒？
• 因为模板是早期版本，后来一直没更新。

这样得到的结论才可能转成行动。

第五步：把根因变成整改动作

很多团队分析做到这里就停了，最后只是得到一句“根因是流程不清晰”。这还不够。

真正有价值的收尾应该写清楚：

• 要改什么
• 谁负责
• 什么时候完成
• 用什么指标验证有没有改善

比如：

• 需求模板新增“验收标准”和“边界条件”必填项
• 由产品负责人本周内完成模板更新
• 下个迭代开始强制评审使用新模板
• 连续两期统计返工率是否下降

一个更容易照着做的实战示例

下面用“客户投诉发货慢”举一个更完整的例子。

问题定义

最近 30 天客户关于“发货慢”的投诉增加了 35%。

先做鱼骨图发散

可以先列出几个方向：

• 人：仓库新人操作不熟练
• 流程：订单审核后才能出库，审批链路长
• 系统：库存同步延迟，导致人工二次确认
• 物料：热销商品缺货，需要等待补货
• 协作：客服承诺时效和仓库真实能力不一致
• 外部：快递揽收时间调整

再挑关键分支做 5Why

假设数据发现“库存同步延迟”最突出：

• 为什么发货慢？因为很多订单出库前需要人工确认库存
• 为什么要人工确认库存？因为系统库存和实际库存经常不一致
• 为什么经常不一致？因为退货入库后没有实时回写
• 为什么没有实时回写？因为退货系统和 ERP 没打通
• 为什么没有打通？因为历史上一直靠人工导表处理
• 为什么一直靠人工导表？因为业务量小时还能撑住，后来没有及时升级流程

最终结论与动作

这时真正的问题就不是“仓库慢”，而是“退货库存回写流程无法支撑当前订单量”。

后续动作可以是：

• 优先打通退货系统与 ERP 的库存回写
• 过渡期设定固定回写批次，减少人工零散处理
• 客服侧同步调整承诺时效
• 两周后复盘库存差异率与发货时效

这种写法就比简单说“加强管理”有用得多。

哪些场景特别适合这么用

1. 质量问题分析

比如产品不良率上升、返修率升高、批次异常。这类问题往往涉及多因素叠加，先用鱼骨图展开，再用 5Why 深挖关键分支，非常适合。

2. 项目延期或复盘

项目延期通常不会只有一个原因。需求变更、资源安排、沟通效率、依赖方交付，都可能有关。鱼骨图能防止遗漏，5Why 能避免讨论停留在“大家都很忙”。

3. 客诉与服务问题

客户投诉看似是前台问题，根因可能在系统、流程、培训、交接、规则设计。只凭经验拍脑袋容易误判。

4. 线上故障与运营异常

例如转化率突然下跌、活动执行出错、接口故障频发。这类问题也很适合先发散再收敛。

常见误区，很多团队会卡在这里

误区一：鱼骨图上写的全是现象，不是原因

比如“延期”“投诉多”“返工多”这些都更像结果，不是真正原因。原因需要更具体，例如：

• 需求评审缺少验收标准
• 测试环境和正式环境不一致
• 仓库班次安排与订单高峰不匹配

误区二：5Why 变成“追责工具”

如果每问一次为什么，最后都落到“某个人没做好”，团队就会下意识自我保护，分析质量会很差。

更好的做法是优先找：

• 流程有没有漏洞
• 标准是否清晰
• 信息是否透明
• 工具是否支持
• 机制是否能防错

误区三：每条鱼刺都想做 5Why

这样会非常耗时，而且最后没有重点。正确做法是先筛选最关键的分支。

误区四：停在“找到根因”，没有后续验证

没有行动项、责任人、时间点和验证指标，再好的分析也只是会议纪要。

如果你是第一次用，可以直接照这个简版模板走

你可以把流程压缩成下面 6 步：

1. 写清楚问题，带时间、范围、指标
2. 先画鱼骨图，把可能原因铺开
3. 挑 1 到 3 个最关键分支
4. 对关键分支做 5Why
5. 把根因转成整改动作
6. 约定复盘时间，看结果有没有改善

如果你已经有一个明确问题，直接把这个框架套进去，通常比空白开会更容易推进。

FAQ

5Why 一定要问五次吗？

不一定。问到能够找到可验证、可改善的根因层级就可以。有时三次就够，有时可能要六七次。

鱼骨图和 5Why 应该谁先谁后？

大多数情况下建议先鱼骨图、后 5Why。先发散再聚焦，更不容易遗漏关键因素。

能不能只用其中一个？

可以。如果问题非常单一、路径很明确，只用 5Why 也行；如果只是做初步头脑风暴，只画鱼骨图也行。但只要问题稍微复杂，两者结合效果通常更好。

会议里大家意见很多，怎么避免越讨论越乱？

先统一问题定义，再限定分类，再给原因做优先级排序。不要一边发散一边下结论，否则很容易混乱。

最后一句实用建议

如果你想把 5Why 和鱼骨图用得真正有效，重点不是画得多漂亮，而是按顺序做三件事：问题写具体、原因先找全、关键分支再深挖。 只要这三步不乱，分析质量通常就不会太差。

如果你想直接把思路整理成图，也可以试试鱼骨图制作工具，先把问题和关键分支搭出来，再继续补充细节，做复盘或团队讨论会更省时间。