5why-sop

name	5why-sop
description	5Why 根因分析标准操作 SOP。当问题已明确发生、具有重复性、需要找到可行动的系统性根本原因（Root Cause）而非治标时使用——覆盖制造业停机/不良、软件开发线上故障、医疗/服务流程失误、8D报告 D4 根因分析、质量与流程问题的永久对策制定等场景。触发词：5Why、根因分析、为什么、Root Cause、根本原因、因果链、追溯原因、为什么又发生了。来源：腾讯文档《总结5Why分析法的标准操作过程SOP》（牛红亮）。
agent_created	true

5Why 根因分析标准操作 SOP

本 Skill 由腾讯文档《总结 5Why 分析法的标准操作过程 SOP》知识工程化而来，内容与该指导书严格一致。 5Why 的核心目标：通过连续追问"为什么"，穿透问题表象，找到可行动的系统性根本原因（Root Cause），并制定永久性对策。它看似只需问"为什么"，但要做到"问对问题、问到底、问向系统而非个人"，需要刻意练习。

---

一、技能名称与定位

• 技能名称：5why-sop（5Why 根因分析标准操作 SOP）
• 本质：一套通过连续追问"为什么"穿透问题表象、找到可行动的系统性根本原因（Root Cause），并制定永久性对策的可执行纪律。
• 核心理念：拒绝停留在表象，用"打破砂锅问到底"的耐心，找到那个一旦解决、问题就再也不会复发的系统性根因。

---

二、适用场景描述

5Why 适用于：

• 问题已明确发生，需要找到根因而非治标
• 问题具有重复性（"怎么又发生了"）
• 因果关系相对线性，可沿单一逻辑链追溯

典型落地场景：

• 制造业装配线停机 / 不良品根因追溯
• 软件开发线上服务故障根因分析
• 医疗 / 服务流程失误根因追溯
• 8D 报告 D4 阶段（根因分析）的核心工具
• 质量 / 流程问题的永久对策制定
• 复盘与经验固化（防呆机制沉淀）

---

三、触发条件

满足以下任一条件即触发本 SOP：

• 用户明确要求做 5Why / 根因分析 / 因果链追问
• 问题已发生且重复出现，需要找到根本原因而非表面解决
• 用户给出已明确定义的问题，需要向下深挖因果链
• 触发词命中：5Why、根因分析、为什么、Root Cause、根本原因、因果链、追溯原因、"为什么又发生了"

前置拦截（不适用场景判定）

在执行前必须先做适用性判定。若属于以下场景，不要直接套用单一 5Why 链，改走替代路径：

• 问题原因复杂多元 → 应先配合鱼骨图做原因分类（见第十节"多路径 5Why"），避免单一因果链遗漏
• 问题尚未明确定义 → 应先做问题描述（4W1H，见 Step 1），不可用模糊议题直接追问
• 纯创意 / 发散类问题 → 应使用头脑风暴或世界咖啡

若问题既复杂又未定义，先"定义问题"（Step 1）→ 再"鱼骨图分类"（第十节）→ 最后"对各类别分别 5Why"。

---

四、核心定义回顾（执行前必读）

5Why = 连续追问"为什么"，直到找到可行动的系统性根因。

概念	含义
Root Cause（根本原因）	流程 / 制度 / 设计层面的系统性原因；改变它，问题不再复发
临时对策（Containment）	立即止血，防止问题扩大（如更换保险丝、人工每班检查）
永久对策（Corrective Action）	消除 root cause，防止复发（如工程改造、建立 SOP）
防呆（Poka-Yoke）	让错误难以再次发生的机制

两个到达 Root Cause 的判定标准（必须同时满足）：

标准	说明
可行动性	针对该原因采取的措施，能永久防止问题复发
系统性	原因是流程 / 制度 / 设计层面的，而非偶发或个人失误

检验问句："如果我们改变了 X，问题还会再发生吗？" —— 答"不会"则 X 是 root cause；答"可能还会"则继续追问。

---

五、前置条件与会前准备（所需工具、人员、材料、规则）

本节对应 SOP"会前准备"，是执行的前置条件与工具清单。团队版强烈建议按此准备；单人版可简化，但"事实数据"与"朝系统而非个人"两条规则不可省略。

1. 组建分析小组（3–6 人为宜）

• 问题发生现场的当事人 / 目击者
• 了解流程的工程师 / 管理者
• 数据分析人员（提供事实证据）
• 指定 facilitator（主持人）：主持追问过程，避免跑题

2. 准备材料 / 工具

• 白板或大张便利贴（用于可视化因果链）
• 马克笔
• 问题相关的事实数据：时间、地点、频率、影响范围
• 必要时调取：现场记录、日志、检测报告

3. 明确规则（执行纪律，不可违反）

• 追问朝向流程 / 系统，而非个人责任
• 每一层"为什么"必须有事实证据支撑
• "5"是经验值，问到可行动的 root cause 为止（可能 3 次，也可能 7 次）

---

六、标准执行流程（6 步）

整体节奏（团队版参考工时）：Step1 10min → Step2 5min → Step3 每层 3–5min（共 15–25min）→ Step4 5min → Step5 10min → Step6 验证跟踪。

Step 1 ｜ 清晰定义问题（约 10 分钟）

动作：用客观、具体的语言描述问题，遵循 "4W1H"：

维度	含义
What	发生了什么？（具体现象）
Where	在哪里发生？
When	何时发生？频率如何？
How much	影响范围 / 程度？
Who	涉及对象？（注意：是"涉及"而非"责任"）

✅ 好的问题定义： "X 型号轴承在装配线上，过去一周每班停机 3 次，每次平均 12 分钟，导致日产能下降 18%。"

❌ 差的问题定义（拒绝此类，要求改写）： "质量不好"、"机器经常坏"

关键：问题定义必须基于事实数据，避免模糊定性。

本步产出：一句符合 4W1H、基于事实数据的问题陈述。

---

Step 2 ｜ 第一次追问"为什么"（约 5 分钟）

动作：针对已定义的问题，问第一个"为什么"。

• 例：为什么机器停了？ → 因为保险丝烧断了。

记录要求：

• 将问题与答案以**"因果对"**形式写在白板左侧
• 答案必须是可验证的事实，而非推测
• 若答案存疑，facilitator 应要求**"拿证据来看"**

本步产出：第 1 个因果对（问题 → 原因 1）。

---

Step 3 ｜ 逐层追问（每层 3–5 分钟，共 15–25 分钟）

动作：把上一层的答案作为新的问题，继续问"为什么"。

• 为什么保险丝烧断了？ → 因为轴承润滑不足，过热导致。
• 为什么润滑不足？ → 因为润滑油泵不工作。
• 为什么油泵不工作？ → 因为泵轴严重磨损。
• 为什么泵轴磨损？ → 因为没有安装过滤网，金属屑进入造成磨损。

每层追问的检查点（逐项确认，否则不准进入下一层）：

• ✅ 答案是否有事实支撑？
• ✅ 因果关系是直接的吗？（A 直接导致 B，而非间接）
• ✅ 我们是否在朝**"系统 / 流程"**方向深入，而非停在"个人"层面？

Facilitator 控场要点：

• 当有人回答"因为操作员疏忽"时，继续追问："为什么流程允许这种疏忽发生？"
• 当有人跳跃式回答时，拉回："我们先把这一层搞清楚，再往下走"
• 当因果链出现分支时，可标注备用路径，主线继续深入

本步产出：逐层因果对链（问题 → 原因 1 → 原因 2 → … → 候选根因）。

---

Step 4 ｜ 识别根本原因（约 5 分钟）

动作：用第四节的两个标准判断是否已经到达 root cause。

• Root Cause 示例：润滑系统未安装过滤网（可通过工程改造永久解决）
• 非 Root Cause 示例：操作员忘记检查油泵（这是表象，流程未强制要求定期检查才是根因）

判定：用检验问句"如果我们改变了 X，问题还会再发生吗？"

• 答"不会" → X 就是 root cause，进入 Step 5
• 答"可能还会" → 继续追问，回到 Step 3

本步产出：锁定的 Root Cause（满足可行动性 + 系统性）。

---

Step 5 ｜ 制定对策（约 10 分钟）

动作：针对 root cause 制定两层对策。

对策层	目的	示例
临时对策（Containment）	立即止血，防止问题扩大	更换保险丝、人工每班检查油泵
永久对策（Corrective Action）	消除 root cause	加装过滤网 + 建立预防性维护 SOP + 将过滤网检查纳入点检表

对策设计原则：

• 针对 root cause，而非 symptoms（表象）
• 可落实到具体负责人与时间表
• 包含**防呆（Poka-Yoke）**机制，让错误难以再次发生

本步产出：临时对策 + 永久对策（含负责人、时间表、防呆机制）。

---

Step 6 ｜ 验证与闭环（后续跟踪）

动作：实施对策后，监控问题是否复发。

• 设定验证期（如 30 天 / 90 天）
• 若未复发 → 根因正确，对策有效，流程固化
• 若仍复发 → 返回 Step 2，重新审视因果链（可能根因未找准，或存在多根因）

本步产出：验证结论（复发 / 未复发）+ 流程固化或重新分析动作。

---

七、SOP 可视化模板

白板上的标准形式（左侧因果链 + 右侧对策区）：

【问题】机器停了，每班 3 次，每次 12 分钟
  ↑ Why?
【原因1】保险丝烧断了
  ↑ Why?
【原因2】轴承润滑不足，过热
  ↑ Why?
【原因3】润滑油泵不工作
  ↑ Why?
【原因4】泵轴严重磨损
  ↑ Why?
【根本原因】未安装过滤网，金属屑进入  ★ROOT CAUSE

右侧对应对策区：
【临时对策】更换保险丝，人工每班检查油泵（负责人：XX，完成时间：今日内）
【永久对策】加装过滤网 + 建立 PM SOP（负责人：XX，完成时间：2 周内）
【验证机制】30 天内监控停机次数，目标：0 次

本步产出（交付物）：可视化因果链 + 对策区（带负责人 / 时间表 / 验证机制）。

---

八、5Why 自检清单（完成拆解后逐项核对）

#	检查项	判定标准
1	问题定义	是否基于事实数据（4W1H），而非模糊定性？
2	因果对	每一层是否以"因果对"记录，答案可验证？
3	事实支撑	每层是否有事实 / 证据支撑，而非推测？
4	直接因果	每层是否 A 直接导致 B，无跳跃？
5	朝系统	是否朝流程 / 系统深入，而非停在个人？
6	根因判定	是否同时满足可行动性 + 系统性？
7	对策分层	是否同时有临时对策 + 永久对策？
8	防呆	永久对策是否含防呆（Poka-Yoke）机制？
9	验证闭环	是否设定验证期并监控复发？

任一项不通过 → 回到对应步骤修正后重新校验。

---

九、常见误区与纠正（即异常处理核心依据）

#	误区	纠正
1	把"5"当教条——机械地问 5 次，到次数就停，哪怕根因还没找到	问到"可行动的 root cause"为止，可能 3 次，也可能 7 次
2	追问到"人"就停止（"因为他疏忽了"）	继续问"为什么流程允许疏忽发生？"——根因通常是系统性漏洞
3	主观臆断因果链——每一层都靠"我觉得"，没有事实核查	每一层都要有证据，facilitator 应要求"拿数据 / 现场记录来"
4	混淆"为什么"与"怎么办"——把"怎么解决"当成"为什么发生"	5Why 阶段只问"为什么"，对策制定在 root cause 找到之后
5	跳跃式追问——从"机器停了"直接跳到"因为设计有缺陷"	因果链必须逐层直接关联，每一层都是上一层的最直接原因
6	只做临时对策——换了保险丝就结束，不解决过滤网问题	必须制定永久对策消除 root cause，否则问题必复发

---

十、多路径 5Why（复杂问题变体）

当问题存在多个可能根因时，单一因果链会遗漏。此时：

1. 先用鱼骨图发散原因类别（人 / 机 / 料 / 法 / 环 / 测）
2. 对每个主类别分别做 5Why
3. 识别主因与次因，制定综合对策

示例框架：

问题：客户投诉产品表面划痕
├─ 人：为什么操作员没发现？→ 为什么检验标准不清？→ ...
├─ 机：为什么设备产生划痕？→ 为什么夹具设计有锐角？→ ...
├─ 料：为什么包装材料硬度过高？→ 为什么供应商变更未评估？→ ...
└─ 法：为什么 SOP 未规定防护步骤？→ 为什么 SOP 过时？→ ...

---

十一、与其他工具的配合

工具	配合节点
鱼骨图	5Why 之前先做原因分类，避免单一因果链遗漏
帕累托图	5Why 之前先识别关键少数问题，聚焦 TOP3 做分析
8D 报告	D4 阶段（根因分析）的核心工具就是 5Why
PDCA	5Why 找到根因后，在"Do"阶段实施对策，"Check"阶段验证
Gemba Walk	5Why 每一层追问都应到现场确认事实，而非会议室臆测

典型组合流程：帕累托识别关键问题 → 鱼骨图分类 → 5Why 深挖根因 → PDCA 实施并验证。

---

十二、单人 5Why SOP（精简版）

当只有自己分析时，按顺序执行 6 步：

1. 纸面定义问题：写出具体事实（时间 / 地点 / 频率 / 影响）
2. 连续追问：在纸上逐层写"为什么"，每层必须有依据
3. 自问检验："如果改变这一层，问题还会发生吗？"
4. 锁定根因：写到无法再问或改变它能根治问题为止
5. 两层对策：临时止血 + 永久消除
6. 设定验证：30 天后回顾问题是否复发

---

十三、实战示例（行业应用）

🏭 制造业

• 问题：装配线停机
• 5Why → 根因：润滑系统缺过滤网
• 对策：加装过滤网 + PM SOP

💻 软件开发

• 问题：线上服务宕机
• 为什么宕机？→ 数据库连接耗尽
• 为什么连接耗尽？→ 连接未释放
• 为什么未释放？→ 异常分支未关闭连接
• 为什么异常分支未关闭？→ 代码 review 未覆盖该路径
• 为什么 review 未覆盖？→ CI 流程缺少静态检查规则
• 根因：CI 流程缺静态检查
• 对策：引入静态分析工具 + 强制异常路径 review 清单

🏥 医疗

• 问题：给药错误
• 为什么错误？→ 护士拿了错的药
• 为什么拿错？→ 药品包装相似
• 为什么包装相似？→ 采购时未评估辨识度
• 为什么未评估？→ 采购流程缺少安全审查节点
• 根因：采购流程缺安全审查
• 对策：建立药品采购安全评估清单 + 相似药品物理隔离

---

十四、输入 / 输出规范

输入（INPUT）

字段	必填	说明
问题陈述	视情况	已发生的问题；若用户给的是模糊议题，先按 Step 1（4W1H）澄清为基于事实的定义
事实数据	否（但强烈建议）	时间、地点、频率、影响范围、现场记录 / 日志 / 检测报告
协作模式	否	团队（走完整 6 步 + 会前准备）/ 单人（走精简 6 步）
复杂度预判	否	原因是否多元（决定是否走第十节"多路径 5Why"）

输出（OUTPUT）

字段	说明
问题定义	符合 4W1H、基于事实数据的问题陈述
因果链	逐层"因果对"，每层含事实支撑与直接因果说明
Root Cause	锁定的根本原因（满足可行动性 + 系统性，附检验问句结论）
两层对策	临时对策（Containment）+ 永久对策（Corrective Action），含负责人、时间表、防呆机制
可视化模板	第七节白板标准形式（因果链 + 对策区）
验证机制	验证期设定（如 30 天）+ 复发监控目标
自检清单结果	第八节 9 项逐项通过情况

标准输出格式（因果链示例）：

<问题陈述>（4W1H）
  ↑ Why? → <原因1>（事实依据：…）
  ↑ Why? → <原因2>（事实依据：…）
  ↑ Why? → <原因3>（事实依据：…）
  ★ ROOT CAUSE：<根本原因>（可行动✅ / 系统性✅）
临时对策：<Containment>（负责人：X，完成：…）
永久对策：<Corrective Action>（负责人：Y，完成：…，防呆：…）
验证机制：<验证期> 内监控 <指标>，目标 <值>

---

十五、异常处理说明

异常情形	识别信号	处理动作
问题过于宽泛 / 无焦点	命中 Step 1 差的定义（如"质量不好""机器经常坏"）	退回要求用 4W1H 重写，补全事实数据（时间 / 地点 / 频率 / 影响）
套用单一链于复杂多元问题	原因多源、单一链明显遗漏	改走第十节"多路径 5Why"（先鱼骨图分类，再各类别分别追问）
问题尚未明确定义	用户只给模糊议题	先执行 Step 1 问题描述，不得直接追问
纯创意 / 发散类问题	无明确已发生问题	改用头脑风暴或世界咖啡
因果对无事实支撑	答案靠"我觉得"，无证据	facilitator 要求"拿数据 / 现场记录来"，补齐证据再继续
因果跳跃	从表象直接跳到深层原因	拉回逐层直接关联，每一层都是上一层最直接原因
追问停在"人"	出现"操作员疏忽"式回答	继续追问"为什么流程允许疏忽发生？"——导向系统性根因
把"5"当教条	问满 5 次即停，根因未达	以"可行动 root cause"为准，可能 3 次也可能 7 次
混淆"为什么"与"怎么办"	在分析阶段就给解决方案	5Why 阶段只问"为什么"，对策留到 Step 5
只做临时对策	换保险丝即结束	强制制定永久对策消除 root cause，否则问题必复发
验证仍复发	验证期内问题再现	返回 Step 2 重新审视因果链（根因未找准或存在多根因）

---

十六、执行守则（给 Agent 的调用约束）

1. 先判定后执行：每次触发必先走"第三节触发条件 / 前置拦截"，不适用则明确告知替代路径（鱼骨图 / 问题描述 / 头脑风暴），不硬套单一链。
2. 忠于 SOP：步骤、4W1H、根因双标准、两层对策、防呆、验证闭环均以上文为准，不增删核心纪律。
3. 强制事实支撑：每一层"为什么"必须要求可验证的事实 / 证据，禁止无依据的推测式因果链。
4. 朝系统而非个人：出现"人因"回答时必须继续深挖流程 / 系统层面的根因。
5. 可视化交付：最终必须输出因果链（第七节模板）+ 两层对策 + 验证机制，缺失任一项视为未完成。
6. 迭代校验：验证复发时回到 Step 2 重审因果链，不在首轮通过后放松。
7. 引用来源：本 Skill 内容严格对应腾讯文档《总结 5Why 分析法的标准操作过程 SOP》，如文档更新，以文档最新版为准同步本 Skill。