鱼骨图一级原因怎么分类

很多人画鱼骨图卡在“第一根大骨头”：一级原因（主骨）到底怎么分？分得少，怕漏关键方向；分得多，又像在做目录，会议很快陷入“你这个该放哪一类”的争论。

更省时间的结论是：一级原因没有唯一标准。你要追求的不是“最正确的分类”，而是这套分类能不能让团队更快把原因拆到同一层级、可验证、可行动。

下面我会把“一级原因是什么、怎么选分类、怎么落到可用的鱼骨图”讲清楚，并给你可直接照抄的分类模板和判断清单。

一级原因到底是什么：它是“讨论框架”，不是结论

鱼骨图（因果图）通常可以理解为三层：

• 鱼头（问题/结果）：你想解释的现象，比如“本月不良率从 1% 升到 3%”。
• 一级原因（主骨/大类）：用来组织讨论的类别框架，比如“人/机/料/法/环/测”。
• 二级、三级原因（小骨）：更具体、可检查的原因，比如“新员工未按作业指导书执行”“量具未校准”。

一级原因的价值在于：

1. 把大家的发言放到同一套语言里（否则有人讲流程，有人讲态度，有人讲客户，你永远对不齐）。
2. 把原因粒度管住（一级写“类别”，二级再写“具体事”）。
3. 让复盘可复用（下次换个问题，你还可以沿用这套骨架）。

所以，一级原因不需要“完美”，但必须“好用”。

适用场景 / 不适用场景（先确认你是不是该画鱼骨图）

适用场景

• 跨岗位一起找原因：质量异常、客诉上升、项目延期、成本超支、线上事故复盘
• 你知道“问题是什么”，但不确定“原因集中在哪”，需要先把可能性系统铺开
• 你希望最后能收敛到：关键原因 + 证据/验证方式 + 改进行动

不太适用的场景

• 原因已被日志/数据锁定：例如监控明确指向某次配置变更，直接修复 + 复盘变更流程更有效。
• 问题定义太空：比如“效率低”“体验差”。先把指标、边界、时间范围、对比基线写清，否则越画越玄。
• 你要的是快速排查清单：小问题用 checklist 更快；鱼骨图更适合需要共识与追责边界的复杂问题。

一级原因怎么分类：先按“场景”选一套常用主骨

没有哪套分类放之四海皆准。实践里最稳的是：按你这次问题的领域选一个大家最熟的骨架，先把会开顺，再根据实际增减。

1）制造/质量类：6M（最常见、最通用）

• 人（Man）：技能、培训、疲劳、交接、执行偏差、责任边界不清
• 机（Machine）：设备状态、维护、参数漂移、治具夹具、故障
• 料（Material）：来料批次、供应商差异、储存条件、替代料、混料
• 法（Method）：工艺方法、作业指导书、流程、节拍、换线/换型方法
• 环（Environment）：温湿度、粉尘、震动、照明、现场布局、ESD
• 测（Measurement）：量具校准、测量方法、抽检方案、检验一致性、数据口径

适合：良率波动、返工报废、尺寸偏差、产能异常等。

2）项目/协作/管理类：人-流程-工具/系统-沟通-外部（更“办公室友好”）

• 人：角色缺失、能力/经验不足、资源不足、负责人不清
• 流程：需求/评审/验收/变更是否清晰，节奏是否合理
• 工具/系统：协作工具、权限、系统稳定性、数据口径
• 沟通：信息不同步、反馈慢、跨部门协作成本高、决策链条长
• 外部：客户、供应商、依赖团队、政策、不可控事件

适合：项目延期、交付失控、跨部门协作卡顿、复盘会上总是吵不清的情况。

3）服务/运营/客诉类：人-产品/服务-流程-渠道-规则（贴近用户链路）

• 人：客服培训、排班、响应、话术一致性
• 产品/服务：质量差异、稳定性、功能缺陷、承诺与实际不一致
• 流程：工单流转、升级机制、退款/补偿流程、售后入口
• 渠道：平台规则、展示信息、触达链路、入口变更
• 规则/政策：收费条款、口径一致性、合规限制

适合：投诉率上升、差评增加、退款率高、转化下滑。

4）IT/线上事故复盘：人-流程-技术-变更-外部（更容易对齐“可控项”）

• 人：值班/交接、告警疲劳、误操作、经验缺口
• 流程：发布、回滚、审批、演练、应急预案
• 技术：架构、容量、依赖、代码质量、监控覆盖
• 变更：版本、配置、依赖升级、灰度策略
• 外部：云服务、第三方 API、网络、供应商

适合：宕机、延迟飙升、接口大量报错、容量事故。

5）拿不准时：用“可控性 + 链路”的 5 类通用法

如果团队成员背景很杂、你又不想太行业化，可以用这套：

• 人（谁在做）
• 流程/过程（怎么做）
• 工具/设备/系统（用什么做）
• 数据/测量/标准（怎么判断对错）
• 环境/外部（受什么影响）

它的好处是：不容易漏掉“标准/口径”和“测量方式”这种经常被忽视但又很致命的原因。

怎么选一套“最合适”的一级分类：给你一个判断清单

你可以按下面顺序快速决定，避免在“选分类”上耗时间。

1. 先看问题类型

   • 质量/生产异常 → 6M 起步
   • 项目延期/协作卡顿 → 人-流程-工具/系统-沟通-外部
   • 客诉/运营问题 → 人-产品/服务-流程-渠道-规则
   • 线上故障/事故 → 人-流程-技术-变更-外部

2. 再看参会角色（共同语言优先）

   • 一线 + 工艺 + 质量：6M 往往最顺
   • 产品/运营/客服：按用户链路（产品/流程/渠道/规则）更好聊清
   • 技术/运维：按“技术 + 变更 + 流程”更容易落到行动

3. 控制一级原因数量：建议 4–8 类

   • 少于 4：容易漏方向
   • 多于 8：容易散，最后变成“分类讨论”而不是“原因收敛”

4. 强制层级一致

   • 一级写“类别”：人/流程/设备/数据/外部
   • 二级写“具体事”：培训不足、参数漂移、需求频繁变更、口径不一致

5. 允许调整：发现不顺就现场重排

   • 如果大家把 90% 原因都写在同一类里，而且说不清楚，很可能是分类不贴合场景；当场换骨架比硬撑更快。

方法步骤：从 0 到 1 画出一张“能用”的鱼骨图

下面这套流程适用于多数团队复盘，重点是让鱼骨图不止停留在“讨论”，而是能自然走到“验证与行动”。

第 1 步：先把问题写成可验证的句子

用“对象 + 指标 + 时间 + 基线/目标 + 偏差 + 影响范围”写法：

• 不要：效率低、质量差、体验不好
• 尽量：
  • “A 型号本月不良率 3%，目标 1%，主要集中在工序 X”
  • “本周登录接口 P95 从 200ms 升到 800ms，影响 30% 用户”
  • “里程碑延期 2 周，导致发布窗口错过，影响营收预期”

问题越具体，一级分类越好选，后面也更容易靠证据收敛。

第 2 步：选一级分类，先搭骨架（别急着写细节）

把 4–8 个类别写到主骨上，先把讨论边界立住。

第 3 步：先独立写原因，再集中归类（避免被强势观点带跑）

建议做法：

• 每个人先独立写 5–10 条可能原因（便利贴/文档都行）
• 集中贴到鱼骨图上
• 先不争对错，先把“可能性”铺开

第 4 步：把原因放到正确层级（必要时把句子重写得更标准）

两个常见的“纠偏动作”：

• 你写的是现象（比如“返工多”）→ 继续追问：返工为什么多？是流程、设备、材料、测量口径，还是培训？
• 你写的是评价/情绪（比如“配合差”）→ 重写成可观察行为：信息不同步？回复超过多久？接口人缺失？决策链路太长？

第 5 步：对重点分支继续拆 2–3 层（用 5Why 控粒度）

一个简单判断：拆到能验证、能改就停。

• 能验证：有日志/数据/记录/抽样可查
• 能改：能提出明确动作（改参数、补培训、加校验、改流程、加监控）

第 6 步：给原因贴“证据标签”，把讨论推到收口

给每条关键原因标注（写在原因后面就行）：

• ✅ 已有证据支持
• ⚠️ 目前是猜测，需要补证据
• 🧪 可以用小实验/抽样验证

最后只对 ✅ / 🧪 绑定行动项：责任人、截止时间、验证方式、复测指标。

例子 1：质量异常的一级原因怎么分、怎么往下拆

假设问题是：“某产品本月不良率从 1% 升到 3%，主要集中在焊接工序”。

一级原因（选择 6M）

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

往下拆（示例）

• 人
  • 新人上岗未完成焊接培训（⚠️：查培训记录）
  • 夜班疲劳，关键动作漏检（🧪：抽样观察 + 返工原因分布）
• 机
  • 焊接设备温控漂移（✅：温度曲线/报警记录）
  • 治具磨损导致定位偏差（🧪：治具对比试验）
• 料
  • 来料批次焊锡膏粘度波动（⚠️：抽检来料 + 供应商批次对比）
• 法
  • 作业指导书版本未更新，参数仍按旧料设置（✅：版本记录 + 变更通知）
  • 换线后首件确认流程未执行（✅：首件记录缺失）
• 环
  • 湿度异常导致吸潮（⚠️：湿度记录 + 吸潮检测）
• 测
  • 检测治具校准过期，误判率上升（✅：校准台账）

这样画完你会发现：鱼骨图的重点不在“写满”，而在于把精力投到最可能且能验证的那几条上。

例子 2：项目延期的一级原因怎么分（更适合非制造团队）

假设问题是：“A 项目延期 2 周，导致上线窗口错过”。

你可以用“人-流程-工具/系统-沟通-外部”做一级原因：

• 人：关键模块只有 1 个熟手；临时被抽调；资源评估偏乐观
• 流程：需求变更没有冻结点；评审走形式；验收标准反复改
• 工具/系统：测试环境不稳定；CI/CD 权限审批慢
• 沟通：依赖团队反馈慢；风险未提前同步；决策链条太长
• 外部：客户临时新增合规要求；第三方接口频繁改动

在这个场景下，如果你硬用 6M，往往会让大家觉得别扭；反过来，用更贴近协作链路的分类，讨论会更容易落到“我们可以怎么改”。

常见误区：最容易把鱼骨图画废的 7 件事

1. 一级原因写成具体事件

   • “没培训”“设备坏了”更像二级原因；一级应写“人/机/流程”这种类别。

2. 一级类目开太多

   • 超过 8 类，会议经常变成“分类争论”，而不是“原因收敛”。

3. 把结果/感受当原因

   • “客户不满意”“质量不稳定”通常还是结果，需要继续拆。

4. 只在一条骨头上狂写，其它骨头空着

   • 可能是偏见，也可能是问题定义偏了。对空骨头做一次反向提问：如果真是设备/口径/环境导致，会有哪些证据？

5. 没有证据就直接定结论

   • 先写假设可以，但要安排验证动作；否则鱼骨图只能当会议记录。

6. 原因粒度不一致

   • 有人写“流程不清”，有人写“按钮颜色不对”，这会让后续行动无法比较优先级。

7. 拆到不可行动的层级

   • “态度不行”“文化不好”通常难落地。要把它翻译成具体行为与机制，比如“交接没有固定模板”“发布没有回滚演练”。

FAQ（至少看完前 3 条，能少走很多弯路）

1）一级原因一般分几类合适？

通常 4–8 类比较舒服。拿不准就从 6M 或“人-流程-工具/系统-沟通-外部”起步。

2）必须用 6M 吗？

不必须。6M 在制造/质量很通用，但在项目/运营/技术复盘里未必顺手。选择大家能快速对齐、并且能落到行动的分类更重要。

3）同一个原因感觉同时属于两类，怎么办？

优先按“主要归因”放一处，避免重复；如果确实跨类，可以在另一类写一句“关联影响提示”，但别把同一条原因复制两遍。

4）一级原因选错了要重画吗？

不一定。一级分类是框架，不是结论。如果发现讨论一直卡住、原因分布很怪（例如全部挤在一类里且说不清），就当场换骨架、重排几分钟，比硬撑更有效。

5）没有数据还能画鱼骨图吗？

可以先画“假设版”，但要明确标注 ⚠️，并为每条关键假设安排一个最小验证动作：看日志、抽样 20 条记录、复盘 10 个工单、现场观察 30 分钟等。

6）怎么判断原因拆得“够深”了？

拆到同时满足这三条通常就够：

• 能被证据验证（现在或很快能拿到证据）
• 能提出明确动作（改什么、谁来改、什么时候改）
• 能设计复测（改完怎么确认有效）

7）鱼骨图和 5Why 的关系是什么？

鱼骨图负责“把可能原因系统铺开”，5Why 负责“在某条链路上追到可行动层级”。常见做法是先铺开，再选 2–3 条最可能的分支深挖。

最后一句建议

一级原因分类的目标不是“看起来专业”，而是让团队更快对齐、把原因拆到可验证可行动，并最终落到改进。

如果你想在会议里快速搭骨架、随时拖拽调整主骨/小骨，再把证据与行动项补进去，可以顺手用一下在线鱼骨图制作工具：https://yugu.cengxuyuan.cn/。