| 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（复杂问题变体）
当问题存在多个可能根因时，单一因果链会遗漏。此时：
- 先用鱼骨图发散原因类别（人 / 机 / 料 / 法 / 环 / 测）
- 对每个主类别分别做 5Why
- 识别主因与次因，制定综合对策
示例框架：
问题：客户投诉产品表面划痕
├─ 人：为什么操作员没发现？→ 为什么检验标准不清？→ ...
├─ 机：为什么设备产生划痕？→ 为什么夹具设计有锐角？→ ...
├─ 料：为什么包装材料硬度过高？→ 为什么供应商变更未评估？→ ...
└─ 法：为什么 SOP 未规定防护步骤？→ 为什么 SOP 过时？→ ...
十一、与其他工具的配合
| 工具 | 配合节点 |
|---|
| 鱼骨图 | 5Why 之前先做原因分类，避免单一因果链遗漏 |
| 帕累托图 | 5Why 之前先识别关键少数问题，聚焦 TOP3 做分析 |
| 8D 报告 | D4 阶段（根因分析）的核心工具就是 5Why |
| PDCA | 5Why 找到根因后，在"Do"阶段实施对策，"Check"阶段验证 |
| Gemba Walk | 5Why 每一层追问都应到现场确认事实，而非会议室臆测 |
典型组合流程：帕累托识别关键问题 → 鱼骨图分类 → 5Why 深挖根因 → PDCA 实施并验证。
十二、单人 5Why SOP（精简版）
当只有自己分析时，按顺序执行 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 的调用约束）
- 先判定后执行：每次触发必先走"第三节触发条件 / 前置拦截"，不适用则明确告知替代路径（鱼骨图 / 问题描述 / 头脑风暴），不硬套单一链。
- 忠于 SOP：步骤、4W1H、根因双标准、两层对策、防呆、验证闭环均以上文为准，不增删核心纪律。
- 强制事实支撑：每一层"为什么"必须要求可验证的事实 / 证据，禁止无依据的推测式因果链。
- 朝系统而非个人：出现"人因"回答时必须继续深挖流程 / 系统层面的根因。
- 可视化交付：最终必须输出因果链（第七节模板）+ 两层对策 + 验证机制，缺失任一项视为未完成。
- 迭代校验：验证复发时回到 Step 2 重审因果链，不在首轮通过后放松。
- 引用来源：本 Skill 内容严格对应腾讯文档《总结 5Why 分析法的标准操作过程 SOP》，如文档更新，以文档最新版为准同步本 Skill。
