本页目录
鱼骨图模板的核心作用
鱼骨图模板用于完整收集“可能原因”，而不是直接证明根因。高质量的鱼骨图应当从可观察的问题出发，按一致的分类组织假设，并为每条重点分支标明事实依据、未知信息和下一步验证方法。
鱼骨图也称因果图或石川图。它把问题写在“鱼头”，把原因类别放在主骨，再把具体候选原因展开为次级分支。这种结构能减少会议被第一种解释主导的风险，但只有后续证据验证才能把候选原因升级为结论。
如何选择6M、8P或自定义鱼骨图模板
| 模板 | 典型分类 | 适用问题 | 使用提醒 |
|---|---|---|---|
| 6M | 人员、机器、方法、材料、测量、环境 | 制造、设备、质量和现场运营 | 不要把同一原因重复放进多个类别 |
| 8P | 人员、流程、政策、地点、产品、价格、推广、证据 | 服务、客户体验和业务流程 | 按实际业务删改，不必机械凑满 |
| 4S | 供应商、系统、技能、环境 | 轻量复盘和跨团队协作 | 适合快速开始，复杂问题需继续展开 |
| 自定义 | 按数据层、流程阶段或责任边界划分 | 软件、数据平台和特殊行业 | 会前定义分类口径，避免分支交叉 |
选择原则：分类应帮助团队覆盖遗漏区域，而不是迫使每个格子都有内容。若讨论对象天然按流程阶段组织，使用“输入—处理—输出—监控”往往比6M更清晰。
先写好问题头部，再讨论原因
问题头部只描述偏差，不夹带解释。建议包含对象、指标、实际值与期望值、时间范围、影响范围和发现位置。例如“8月12日夜班A线封装不良率从0.8%升至3.6%”，比“操作员培训不足导致不良率上升”更适合作为鱼头。
可观察、可度量、有时间边界，并能让不同角色对“发生了什么”形成一致理解。
含有“因为”“缺乏”“不认真”等未经验证的原因词，或只有“质量差”“系统慢”等模糊判断。
如果问题包含多个结果，应拆成多张鱼骨图。把“延迟、错误和客户投诉”放进同一个鱼头，会让原因链和证据口径互相混淆。
填写鱼骨图的六步工作流
- 确定问题与边界确认指标、范围、时段和不纳入分析的对象。
- 选择主骨结构根据问题类型采用6M、8P、4S或自定义分类。
- 先独立发散让参与者先分别记录候选原因，降低权威和从众影响。
- 合并并继续追问去重后追问“什么条件使它发生”，把抽象词改写为可检查陈述。
- 标记证据状态区分已观察事实、待验证假设和当前未知，避免把讨论热度当成证据。
- 建立验证清单为重点分支指定数据、方法、负责人、判定标准与截止日期。
把原因分支写成可验证陈述
“人员”“流程”“系统”只是类别，不是原因。好的分支应描述一个可能改变结果的具体条件，例如“交接班后20分钟内没有完成参数复核”或“重试队列在峰值时段超过容量阈值”。
| 模糊写法 | 可验证写法 | 可能证据 |
|---|---|---|
| 人员失误 | 新班组未执行首件参数复核 | 培训记录、首件表、现场观察 |
| 机器异常 | 温控传感器在高负荷时漂移超过容差 | 校准数据、趋势日志、对照测量 |
| 数据质量差 | 上游字段在版本切换后出现空值激增 | 模式变更、血缘、空值率时间序列 |
| 流程不规范 | 异常工单未经过第二人复核即关闭 | 审批日志、工单状态与抽样记录 |
如何主持一次不跑偏的鱼骨图会议
主持人应控制问题边界和表达质量，而不是替团队选择答案。会前准备问题数据、时间线和参与角色；会上先静默发散，再轮流提交；合并分支时只讨论含义和证据，不急于投票决定“真因”。
- 邀请接近实际流程的人，也邀请能读取关键数据的人。
- 把事实和假设使用不同文字标签，而不是只靠颜色区分。
- 对有争议的分支记录不同解释及需要补充的证据。
- 会议结束前确认验证责任人，避免鱼骨图成为一次性图片。
用影响、证据和可检验性筛选候选原因
候选原因较多时，可以按三个维度评分：若该原因成立，对问题的解释力有多强；目前支持它的证据有多少；团队能否在合理成本内设计区分性检验。评分用于安排验证顺序，不能代替验证本身。
示例：订单处理时间突然上升
假设问题头部为“工作日14:00—16:00，退款订单处理时间中位数从18分钟升至47分钟”。团队按人员、流程、系统、数据、规则和外部依赖六条主骨发散后，得到“新审批规则增加一次人工等待”“查询接口重试导致队列积压”“部分订单缺少渠道代码”等候选原因。
| 候选原因 | 验证数据 | 判定标准 | 负责人 |
|---|---|---|---|
| 审批规则增加等待 | 规则上线前后各两周阶段耗时 | 新增阶段解释主要增量且分组稳定 | 流程负责人 |
| 接口重试造成积压 | 重试次数、队列深度、响应时延 | 重试峰值先于处理时长上升 | 平台工程师 |
| 渠道代码缺失 | 缺失率与订单级处理时长 | 控制订单类型后仍显著相关 | 数据分析师 |
这样的交付物比“系统问题可能是根因”更有价值，因为它明确了如何否定假设，也能在验证失败后继续追踪其他分支。
从鱼骨图交接到根因验证
每个进入验证阶段的分支都应形成任务卡：假设陈述、支持与反对证据、数据来源、分析方法、判定阈值、责任人、完成时间以及结果去向。验证完成后，把状态更新为“支持”“不支持”或“证据不足”，不要删除失败的假设。
当团队需要比较多种根因分析方法时，可阅读根因分析技术指南。方法选择取决于问题结构：鱼骨图偏向原因覆盖，故障树偏向逻辑组合，统计分析偏向量化关系。
把候选原因变成可审计的行动清单
在 InfiniSynapse 中汇总事件、指标、日志与验证记录，让每条原因假设都有来源、负责人和状态，减少讨论结论在会议结束后丢失。
在线使用 InfiniSynapse使用鱼骨图时的常见误区
- 把分支当结论：出现在图上只代表值得检查，不代表因果关系成立。
- 问题头部含原因：这会让后续讨论围绕预设答案展开。
- 只让管理者发言：最接近流程的人掌握大量边界条件，应给所有角色独立输入机会。
- 分类过度重叠：重复分支会虚增某个解释的权重，应明确分类口径并去重。
- 没有验证出口：如果没有责任人、数据和判定标准，鱼骨图只是整理过的猜测清单。
鱼骨图模板常见问题
鱼骨图适合分析什么问题？
鱼骨图适合边界清楚、结果可观察，但潜在影响因素较多的问题。它用于系统收集候选原因，不应被当作根因已获证明的证据。
应该选择6M、8P还是自定义模板？
制造和运营问题通常从6M开始，服务流程可参考8P；如果预设分类会限制讨论，应按业务对象自定义主骨，并在会议开始前说明分类口径。
鱼骨图上的原因需要写到多细？
写到团队能够指定数据、观察或试验来判断真伪的程度。只有抽象标签无法验证，过早写成具体结论又会制造确认偏差。
完成鱼骨图后下一步做什么？
先按影响、证据和可检验性筛选候选原因，再为高优先级分支建立负责人、数据来源、判定标准和完成日期明确的验证计划。
鱼骨图与5个为什么可以一起使用吗？
可以。鱼骨图负责横向覆盖不同原因类别，5个为什么负责沿着一个高价值分支继续追问，两者结合有助于兼顾广度与深度。
官方来源与延伸资料
以下官方资料可用于核对鱼骨图的基本结构、会议用法以及根因分析的后续要求：