鱼骨图是一种用于分析问题潜在原因的根因分析工具，也叫 Ishikawa 图、石川图，或因果图。它的形状像一条鱼：鱼头写要解决的问题，鱼骨表示主要原因分类，小骨则列出具体的可能原因。
鱼骨图真正有用的地方，不只是把原因画出来，而是改变团队讨论问题的方式。它会把大家从「谁造成了这个问题」带到「什么样的系统、流程或条件让这个问题发生」。
这种图最早常见于制造业和质量管理，但并不只适合工厂。产品缺陷、客服响应慢、网站转化率下降、项目延期、运营流程混乱，都可以用鱼骨图先梳理可能原因，再决定下一步怎么验证和解决。
为什么鱼骨图有效
很多团队遇到问题时，第一反应是找责任人。产品出了瑕疵，就说是操作员不够仔细；客服响应慢，就说客服效率低；网站转化率下滑，就说市场流量质量差。
这些判断有时并非完全错误，但往往太早下结论。一个人的行为背后，可能有培训不到位、工具不好用、流程设计有缺口、指标误导、工作量突然上升等更深层原因。
鱼骨图把讨论从「指责某个人」转向「寻找原因系统」。它要求团队同时看人、工具、流程、材料、测量方式、环境等多个维度。目的不是找一个人背锅，而是理解问题为什么有机会发生。
这很重要，因为不同原因需要完全不同的解决方案。如果缺陷来自作业指导不清，单独提醒某个员工没有用；如果客服慢是因为工单分流规则有问题，让客服「再努力一点」也只是在掩盖瓶颈。
鱼骨图还能避免「单一原因思维」。真实问题经常由多个因素叠加造成：流程不清、系统限制、指标缺失、临时工作量增加同时存在。把这些原因放在同一张图上，团队更容易选择真正匹配问题的解决办法。
主要原因分类
最常见的鱼骨图分类是 6M，最初主要用于制造业：
| 分类 | 关注内容 |
|---|---|
| Man（人） | 人员、技能、培训、沟通、排班 |
| Machine（机器） | 设备、工具、软件、硬件、维护状态 |
| Method（方法） | 流程步骤、操作标准、工作方法、交接方式 |
| Material（材料） | 原材料、零件、供应品、数据、内容、需求输入 |
| Measurement（测量） | 指标、检验方式、监控、反馈机制 |
| Environment（环境） | 工作环境、负载、市场背景、时间压力 |
6M 是一个很好的起点，但不是硬性规定。鱼骨图的目的不是把每个词都套进标准分类，而是帮助团队从足够多的角度看问题。
如果你分析的是服务业、软件团队或内部运营流程，下面这组分类通常更自然：
| 分类 | 可以追问的问题 |
|---|---|
| People（人员） | 人是否有足够技能、上下文、权限和时间？ |
| Process（流程） | 步骤是否清晰？顺序是否合理？责任是否明确？ |
| Technology（技术） | 工具、系统、集成或自动化是否带来阻碍？ |
| Policy（规则） | 审批、激励、限制或制度是否制造了问题？ |
分类要选团队听得懂、用得上的。一个听起来专业但没人能联想到真实原因的分类，不如一个简单直接的分类有效。
真实鱼骨图示例
产品缺陷
一家制造团队发现最终检验时，零件表面划痕比平时明显增多。鱼头可以写成：
问题：最终检验发现零件表面划痕增加
可能原因包括：
- 人： 新员工还没有接受完整的搬运培训
- 机器： 传送带导轨磨损，碰到了零件表面
- 方法： 保护膜贴上之前，零件已经被叠放
- 材料： 新供应商的保护膜比原来更薄
- 测量： 只在最终环节检查划痕，前面工序没有检查点
- 环境： 高峰班次工作台拥挤，临时堆放更多
鱼骨图本身不能证明哪个原因是真的。它的作用是给团队一份完整的调查清单。这个例子里，真正的解决方案可能既包括设备维护，也包括调整贴保护膜的工序顺序。
客服响应慢
一个客服团队连续两周没有达到首次响应 SLA。鱼头可以写成：
问题：首次响应时间超过 SLA
用服务业分类来分析，可能原因包括：
- 人员： 新客服过早处理复杂工单
- 流程： 紧急工单和低优先级请求没有分开
- 技术： 工单系统无法自动识别并分流账单问题
- 规则： 退款需要主管审批，导致部分工单长时间等待
- 测量： 仪表盘只显示日均值，掩盖了上午高峰
如果不做鱼骨图，团队可能只会想到增加客服人数。但原因展开后，可能会发现工单路由和审批规则比人手不足更关键。
网站转化率下降
一个增长团队发现网站改版后，试用注册转化率下降。鱼头可以写成：
问题：试用注册转化率下降
可能原因包括：
- 人员： 销售和市场对目标用户理解不一致
- 流程： 改版后没有完整检查注册流程
- 技术： 移动端表单加载速度变慢
- 规则： 新增必填字段，让表单变长
- 材料： 页面文案强调功能，而不是买家的实际问题
- 测量： 埋点事件发生变化，新旧数据不可直接比较
这个例子说明，鱼骨图不只适合质量管理。一个网站指标下降，可能来自设计、技术、定位、追踪口径或流量结构。鱼骨图能让团队先把可能性展开，而不是太快把它归结为某一个部门的问题。
如何创建鱼骨图
第一步：明确问题。 用一句具体的话写出要分析的问题。「客服体验不好」太宽泛。「过去 10 个工作日，账单类工单首次响应超过 24 小时」才适合分析。
第二步：画出鱼头。 把问题写在图的右侧，画一条横向主干指向它。后面所有原因都应该指向同一个问题，不要在一张图里同时分析多个问题。
第三步：选择原因分类。 制造业、质量管理或实体运营问题，可以从 6M 开始。服务、软件或业务流程问题，可以用人员、流程、技术、规则。只要团队更容易讨论，也可以改成自己的分类。
第四步：头脑风暴可能原因。 让最接近一线工作的人参与，把所有合理可能性先写上去。这个阶段不急着判断对错，目标是尽量覆盖完整。
第五步：不断追问 why。 看到一个原因后，继续问「为什么会这样」。如果原因是「客服回复晚」，继续问为什么。可能是工单难以分类。为什么难以分类？可能是表单没有收集问题类型。这样才能从表层症状逐步接近根因。
第六步：验证关键原因。 鱼骨图列出的是假设，不是结论。需要用数据、现场观察、日志、用户访谈或小实验来验证。没有验证，图画得再整齐也只是整理过的猜测。
常见错误
问题定义太宽。 如果鱼头写的是「质量问题」或「客户体验差」，图很快会变成一张什么都能放进去的清单。把问题缩小到团队能明确调查的程度。
把症状当原因。 「客户很生气」可能是真的，但它通常还是结果，不是根因。继续追问是什么造成了这种情绪：回复太慢、价格不清楚、 onboarding 失败，还是预期不一致。
不验证假设。 鱼骨图会让猜测看起来很有条理，但有条理不等于正确。好的鱼骨图应该引出调查，而不是直接替代调查。
只让管理层填写。 管理层了解流程设计，但不一定了解每天实际发生的绕路、例外和临时处理方式。真正执行工作、处理异常、面对客户、维护工具或检查结果的人都应该参与。
为了分类而分类。 分类是帮助思考的工具，不是考试题。如果一个原因暂时不知道放哪里，先写下来，后面再整理。
鱼骨图 vs. 其他问题分析工具
| 工具 | 最适合 | 区别 |
|---|---|---|
| 鱼骨图 | 展开一个问题的多种可能原因 | 先广泛梳理原因，再决定调查方向 |
| 5 Whys | 深挖一个较可能的原因 | 线性追问，适合原因方向已经比较明确时 |
| 流程图 | 理解流程如何一步步流转 | 展示顺序和交接，不按原因分类 |
| 风险矩阵 | 按可能性和影响评估风险优先级 | 帮助排序风险，但不解释根因 |
| 帕累托图 | 从已有数据中找最大贡献项 | 需要已有计数数据，适合判断优先处理哪类问题 |
这些工具并不互斥。你可以先用帕累托图找出最常见的缺陷类型，再用鱼骨图分析原因；对最可能的一条原因分支使用 5 Whys 深挖；如果根因在流程上，再用流程图重新设计步骤。
常见问题
鱼骨图是用来做什么的？ 鱼骨图用于识别和整理某个具体问题的可能原因。它特别适合原因复杂、涉及多个团队或暂时无法确定根因的情况。
为什么叫鱼骨图？ 因为它看起来像鱼骨架：问题在鱼头，主线像鱼脊，原因分类像一根根鱼骨。
鱼骨图和 Ishikawa 图是同一个东西吗？ 通常是同一个。鱼骨图、Ishikawa 图、石川图、因果图一般都指这类根因分析图。
鱼骨图的 6M 是什么？ 6M 指 Man（人）、Machine（机器）、Method（方法）、Material（材料）、Measurement（测量）和 Environment（环境）。它常用于制造业和质量改进，但不是唯一分类方式。
鱼骨图能自动找到根因吗？ 不能。鱼骨图帮助团队提出和组织可能原因，真正的根因需要通过数据、观察或实验验证。
用什么工具画鱼骨图？ 简单讨论可以用白板；线上协作可以用 draw.io、CodePic 等图表工具。CodePic 的鱼骨图模板适合快速把原因分类、分支和具体假设整理成一张可分享的图。
