鱼骨图适合分析哪些问题

很多人搜“鱼骨图适合分析哪些问题”，核心其实是想判断：我现在遇到的这个麻烦，到底值不值得画鱼骨图？画了会不会更快找到原因，而不是做一张“看起来很专业但没用”的图。

直接结论：鱼骨图（因果图）最适合用在“结果很明确、可能原因很多、需要把思路摊开讨论并逐一验证”的问题。典型是质量异常、交付延期、投诉增多、效率下降这类“看得见的结果”，但背后往往牵扯人、流程、工具、标准、环境等多条线。

先用 30 秒判断：你的问题适不适合画鱼骨图

你可以用下面 3 个问题快速筛选：

1. 结果是否足够清楚？

• 清楚：比如“3 月份退货率从 2% 升到 6%”“A 工序不良率连续 3 天超标”“这个迭代延期 2 周”。
• 不清楚：比如“团队氛围不好”“公司变慢了”“做事没效率”——先把它具体化再说。

2. 原因是否可能“多条并行”而不是单点故障？

• 如果你隐约感觉不止一个原因（沟通、流程、培训、系统、供应、需求变更都可能），鱼骨图很合适。
• 如果几乎可以确定就是某个单一因素（比如服务器宕机一次导致不可用），鱼骨图价值不大，直接复盘即可。

3. 你是否需要“拉齐认知 + 形成可验证假设”？

• 鱼骨图的强项不是“灵感一闪找到真相”，而是把大家的猜测变成一组可验证的假设，然后用数据/现场去证伪。

满足以上 2 条以上，通常就值得画。

鱼骨图特别适合的 8 类问题（附例子）

下面这些场景，是鱼骨图最常见、也最容易落地的用法。

1）质量问题/不良率异常（制造、交付、内容质量都算）

适用原因：质量通常受多因素影响，且“看起来像原因”的东西很多。

例子：

• “某型号返修率突然升高”
• “出库漏检次数上升”
• “文章发布后被频繁反馈‘看不懂/错误多’”

常用主干分类（制造业常见 6M）：

• 人（Man）/ 机（Machine）/ 料（Material）/ 法（Method）/ 环（Environment）/ 测（Measurement）

2）交付延期/项目进度失控

例子：

• “迭代总是延期”
• “测试周期越拖越长”
• “跨部门项目推进卡住”

常用分类（更贴近项目）：

• 需求与范围 / 人员与分工 / 流程与节奏 / 工具与系统 / 沟通协作 / 外部依赖

3）客诉/投诉增加、满意度下降

例子：

• “客户投诉响应慢”
• “售后满意度降低”
• “退款理由集中在某几项”

常用分类：

• 预期管理（宣传/承诺）/ 服务流程 / 人员能力与话术 / 工具系统 / 产品体验 / 交付与质量

4）效率下降/返工变多/产能不足

例子：

• “同样工作量，最近总做不完”
• “返工率高”
• “审批流程越来越慢”

常用分类：

• 标准与规范 / 流程与等待 / 工具与自动化 / 人员熟练度 / 协作与切换成本 / 任务优先级

5）数据指标异常（运营/增长/转化）

鱼骨图并不是只能用在制造业。只要结果明确、原因可能多，就能用。

例子：

• “注册转化率下降”
• “某渠道留存突然变差”
• “自然流量下滑”

建议分类（更贴近互联网/内容）：

• 流量来源（渠道）/ 页面与路径（体验）/ 内容与价值（供给）/ 价格与门槛 / 信任与风险 / 竞品与外部变化

注意：这类问题最后一定要回到数据验证，否则很容易变成“大家各说各的”。

6）安全事故/差错事件（但需要边界）

例子：

• “误操作导致数据丢失”
• “权限配置出错”

适用点：可以把人的行为、流程缺陷、工具设计、权限策略等拆开。

边界：如果已经明确是单点 bug/单次人为失误，且没有复发风险，鱼骨图不一定是最高效的；但如果你要做机制性改进，鱼骨图很有价值。

7）培训与能力问题（新人上手慢、出错多）

例子：

• “新人上手周期越来越长”
• “同类错误重复发生”

常用分类：

• 培训材料 / 指导方式 / 任务设计 / 工具与权限 / 标准与检查 / 反馈闭环

8）重复出现的“疑难杂症”（定位困难、反复发作）

例子：

• “偶发卡顿/偶发崩溃”
• “某工序偶发异常但无法复现”

鱼骨图能帮助你把可能的触发条件列全，形成排查清单，再配合日志、监控、抽样验证。

哪些问题不太适合用鱼骨图（别硬画）

鱼骨图不是万能的，以下情况通常收益不高：

• 问题定义不清：比如“大家都很累”“最近很乱”。先把它变成可观察的现象（加班时长？缺陷数？延期次数？）
• 只需要做决策取舍：比如“要不要进入新市场”。这是战略选择，不是因果排查。
• 强数据建模更合适：比如“哪些变量对销量贡献最大”。先回归/AB/因子分析，再用鱼骨图做补充讨论。
• 已确认单点原因且无复发价值：比如“一次断电导致停机”。直接复盘+改进即可。

画鱼骨图时怎么选“主骨架分类”（选对比画得漂亮更重要）

很多人卡在第一步：主骨架到底用什么分类？其实没有唯一标准，关键是能覆盖你这个场景的主要变量。

常见选择：

• 制造/质量：6M（人机料法环测）
• 项目/研发：需求、人员、流程、工具、协作、依赖
• 服务/运营：流程、人员、工具系统、产品体验、规则政策、外部因素
• 内容/交付：选题与定位、生产流程、审核机制、数据反馈、工具模板、协作分工

如果你不确定，优先用“人员-流程-工具-标准-环境/外部”这种通用骨架，够用且不容易跑偏。

一套更容易落地的鱼骨图步骤（从“列原因”走到“能改进”）

下面这套做法，能避免鱼骨图常见的“画完就算了”。

第 1 步：把问题写成“可验证的一句话”

建议结构：

• 指标/现象 + 时间范围 + 影响范围

例子：

• “过去两周，A 产品退货率从 2% 升到 6%，主要集中在华东仓。”
• “最近 3 个版本，测试周期平均从 3 天变成 6 天，导致迭代延期。”

第 2 步：确定边界与目标

至少说清两件事：

• 要解决到什么程度：临时止血？还是机制性避免复发？
• 这次不讨论什么：避免会议无限扩散。

第 3 步：先填“一级原因”，再填“二级原因”

顺序建议：

1. 先把一级原因写满（覆盖面）
2. 再对最可能的几条往下拆（二级、三级）

拆分时可以用“5 Why”辅助追问，但别为了凑层级硬往下钻。

第 4 步：把“猜测”标出来，配套验证方式

鱼骨图里很多条目本质是猜测。建议在每个关键原因后面补一句：

• 需要什么证据验证？数据/现场/抽样/日志/访谈？
• 验证成本多高？多久能做？

这样团队会从“观点对撞”转向“验证行动”。

第 5 步：收敛优先级，形成行动清单

收敛时不要只看“大家觉得像”，可以用简单的三维筛选：

• 影响大不大
• 发生频率高不高
• 可控性强不强（能不能改）

最后输出 3 样东西：

• 需要立刻止血的措施
• 需要机制改进的措施
• 需要持续监控的指标

第 6 步：一周后复盘一次（闭环）

鱼骨图最怕“画完没人跟”。建议设一个回访时间：

• 验证结果是否支持假设？
• 哪些原因被证伪？
• 哪些改进有效、哪些无效？

常见误区（很多团队画鱼骨图没效果就栽在这里）

1. 把结果当原因

• “客户不满意”是结果，不是原因。要继续问：因为什么不满意？响应慢？质量波动？承诺不清？

2. 把解决方案当原因

• “加人”“上系统”“加强培训”是措施，不是原因。原因要描述“为什么需要这些措施”。

3. 问题写得太大

• “效率低”太大，先缩到具体环节：需求评审慢？测试排队？上线审批？

4. 只靠主观，不做验证

• 鱼骨图不是结论，它是“假设地图”。没有验证，就只是在记录大家的感觉。

5. 层级越深越好

• 不是。层级深但没证据，反而会让人误以为“已经分析透了”。

FAQ：你可能还关心这些

鱼骨图和 5 Why 有什么区别？

• 鱼骨图更像“横向铺开”，把可能原因列全。
• 5 Why 更像“纵向钻下去”，沿着一条链路追根。

很多时候的最佳组合是：先鱼骨图列全，再对最可能的 2–3 条用 5 Why 深挖。

个人能不能用鱼骨图？一定要开会吗？

可以个人先画一版，用来整理思路和准备讨论。等到需要验证、需要跨部门协同时，再把图拿出来开会效率更高。

模板到底有没有用？

模板的价值是让你不用从零搭骨架。真正关键的是：

• 你的问题够具体
• 你选的分类能覆盖这个场景
• 你愿意做验证与闭环

画完鱼骨图之后，怎么避免“停在 PPT 上”？

最有效的做法是：

• 每条关键原因都写上验证方式
• 把行动项落到负责人和截止时间
• 用一个指标跟踪效果（比如不良率、周期、投诉率）

想更省事：先把骨架搭出来再补细节

如果你已经有一个明确问题，通常最省时间的方式是：先用一个顺手的分类把主骨架搭出来，再把原因逐层补全、标注验证方式。

需要快速在线绘制和修改的话，可以试试这个工具：https://yugu.cengxuyuan.cn/（先把骨架画出来，再边讨论边补细节会更快）。