名称: 根因分析 描述: 使用Fishbone（Ishikawa）图和5 Whys技术解决问题。系统地识别根本原因并推荐纠正措施。 参数提示: <问题陈述> [–模式 fishbone|5whys|full] [–输出 yaml|mermaid|both] [–目录 <路径>] 允许工具: Read, Write, Glob, Grep, Task, Skill, AskUserQuestion
根因分析
使用Fishbone（Ishikawa）图和5 Whys技术进行系统性问题解决。识别真正根本原因并推荐有效纠正措施。
什么是根因分析？
根因分析 (RCA) 是一种结构化方法，用于识别问题的根本原因，而不是处理症状。有效的RCA防止问题复发。
| 方法 | 重点 | 最佳适用 |
|---|---|---|
| Fishbone (Ishikawa) | 按类别脑力激荡所有潜在原因 | 具有多个潜在原因的复杂问题 |
| 5 Whys | 通过原因链深入挖掘 | 具有线性因果关系的简单问题 |
| 组合 | Fishbone用于识别，5 Whys用于深入挖掘 | 全面的根本原因识别 |
框架1: Fishbone (Ishikawa) 图
什么是Fishbone图？
Fishbone图（也称为Ishikawa或因果图）将潜在原因组织成类别，类似于鱼骨架，问题作为“头部”。
┌─────────────────────────────────────────────────────────┐
│ │
人 ──┼──┐ ┌──┼── 方法
│ │ │ │
│ └─────────────────────┐ ┌───────────────┘ │
│ │ │ │
│ ▼ ▼ │
│ ┌─────────┐ │
│ │ 问题 │ │
│ └─────────┘ │
│ ▲ ▲ │
│ ┌─────────────────────┘ └───────────────┐ │
│ │ │ │
机器 ┼──┘ └──┼── 材料
│ │
│ │
测量 ────────────────────────────────────────────── 环境
│ │
└───────────────────────────────────────────────┘
6M 类别
| 类别 | 也称为 | 示例原因 |
|---|---|---|
| 人 | 人员 | 培训、技能、疲劳、沟通 |
| 机器 | 设备、技术 | 硬件、软件、工具、维护 |
| 方法 | 流程、程序 | 工作流、文档、标准 |
| 材料 | 输入、数据 | 原材料、组件、信息质量 |
| 测量 | 指标、检查 | 校准、准确性、数据收集 |
| 环境 | 环境 | 温度、湿度、法规、市场 |
替代类别集
| 领域 | 类别 |
|---|---|
| 制造业 (6M) | 人、机器、方法、材料、测量、环境 |
| 服务业 (8P) | 产品、价格、地点、促销、人员、流程、物理证据、生产力 |
| 软件 (5S) | 系统、技能、供应商、环境、安全 |
| 自定义 | 定义与您领域相关的类别 |
Fishbone 工作流
步骤1: 定义问题
## 问题陈述
**问题:** [清晰、具体、可测量的描述]
**影响:** [量化影响 - 成本、时间、质量、安全]
**发现时间:** [日期/时间]
**地点:** [位置、系统、流程]
**频率:** [一次性 / 重复 / 间歇性]
良好问题陈述示例:
- ✅ “客户订单延迟3天以上在第四季度增加了40%”
- ✅ “生产线3的缺陷率在11月从2%上升到8%”
- ❌ “事情很慢” (太模糊)
- ❌ “系统坏了” (不可测量)
步骤2: 组建团队
包括具有直接知识的人员：
| 角色 | 贡献 |
|---|---|
| 流程所有者 | 总体责任 |
| 一线工人 | 直接观察和经验 |
| 主题专家 | 技术知识 |
| 客户代表 | 影响视角 |
| 促进者 | 指导过程 |
步骤3: 按类别脑力激荡原因
对于每个类别，问：“在这个类别中，什么可能导致问题？”
## 原因脑力激荡
### 人 (人员)
| 潜在原因 | 证据 | 可能性 |
|-----------------|----------|------------|
| 培训不足 | 新员工占错误的60% | 高 |
| 疲劳 (加班小时) | 错误在8小时后达到高峰 | 中 |
| 沟通差距 | 交接错误有记录 | 高 |
### 机器 (设备)
| 潜在原因 | 证据 | 可能性 |
|-----------------|----------|------------|
| 设备老化 | 机器7占故障的40% | 高 |
| 软件缺陷 | 版本2.1引入缺陷 | 中 |
### 方法 (流程)
| 潜在原因 | 证据 | 可能性 |
|-----------------|----------|------------|
| 程序不清晰 | 观察到3种不同方法 | 高 |
| 缺少质量检查 | 没有验证步骤记录 | 高 |
### 材料 (输入)
| 潜在原因 | 证据 | 可能性 |
|-----------------|----------|------------|
| 供应商质量问题 | 进料缺陷率上升15% | 中 |
| 规格模糊 | 多种解释可能 | 低 |
### 测量 (指标)
| 潜在原因 | 证据 | 可能性 |
|-----------------|----------|------------|
| 传感器不准确 | 校准超期 | 中 |
| 跟踪错误指标 | 缺少领先指标 | 低 |
### 环境 (环境)
| 潜在原因 | 证据 | 可能性 |
|-----------------|----------|------------|
| 季节性需求高峰 | 第四季度总是最高量 | 高 |
| 法规变化 | 10月新要求 | 低 |
步骤4: 识别最可能的根本原因
基于以下标准优先排序：
| 标准 | 问题 |
|---|---|
| 证据 | 有数据支持此原因吗？ |
| 频率 | 此原因与问题频率相关吗？ |
| 相关性 | 原因时间与问题时间匹配吗？ |
| 控制 | 我们能测试或消除此原因吗？ |
步骤5: 验证根本原因
对于每个高可能性原因：
## 根本原因验证
| 原因 | 验证方法 | 结果 | 确认？ |
|-------|-------------------|--------|------------|
| 培训不足 | 比较不同工作年限的错误率 | 新员工错误率3倍 | ✅ 是 |
| 设备老化 | 分析按机器的故障 | 机器7: 所有故障的40% | ✅ 是 |
| 程序不清晰 | 审查文档 | 找到3个冲突的SOP | ✅ 是 |
Fishbone 输出格式
## Fishbone分析: [问题]
**日期:** [ISO日期]
**促进者:** rca-analyst
**团队:** [参与者]
### 问题陈述
[清晰、具体、可测量的问题]
### 影响
[量化业务影响]
### 原因分析
#### 人 (人员)
- [原因1] - 证据: [X] - 状态: 确认/怀疑
- [原因2] - 证据: [X] - 状态: 确认/怀疑
#### 机器 (设备)
- [原因1] - 证据: [X] - 状态: 确认/怀疑
#### 方法 (流程)
- [原因1] - 证据: [X] - 状态: 确认/怀疑
#### 材料 (输入)
- [原因1] - 证据: [X] - 状态: 确认/怀疑
#### 测量 (指标)
- [原因1] - 证据: [X] - 状态: 确认/怀疑
#### 环境 (环境)
- [原因1] - 证据: [X] - 状态: 确认/怀疑
### 确认的根本原因
| # | 根本原因 | 类别 | 证据 | 贡献度 |
|---|------------|----------|----------|--------------|
| 1 | [描述] | [6M] | [数据] | [问题百分比] |
### 推荐行动
| # | 行动 | 处理 | 所有者 | 截止日期 |
|---|--------|-----------|-------|----------|
| 1 | [纠正行动] | 根本原因#1 | [名称] | [日期] |
Fishbone Mermaid 图
flowchart LR
subgraph Man["👤 人"]
M1[培训差距]
M2[沟通问题]
end
subgraph Machine["⚙️ 机器"]
MA1[设备老化]
MA2[软件缺陷]
end
subgraph Method["📋 方法"]
ME1[程序不清晰]
ME2[缺少QC步骤]
end
subgraph Material["📦 材料"]
MT1[供应商质量]
MT2[规格问题]
end
subgraph Measurement["📊 测量"]
MS1[传感器准确性]
MS2[错误指标]
end
subgraph Environment["🌍 环境"]
E1[季节性需求]
E2[法规变化]
end
M1 & M2 --> Problem
MA1 & MA2 --> Problem
ME1 & ME2 --> Problem
MT1 & MT2 --> Problem
MS1 & MS2 --> Problem
E1 & E2 --> Problem
Problem[❌ 问题:<br/>客户延迟<br/>增加40%]
style Problem fill:#f99,stroke:#900
框架2: 5 Whys
什么是5 Whys？
5 Whys 是一种迭代式询问技术，通过重复问“为什么？”（通常5次，但可能更少或更多）从症状深入挖掘到根本原因。
关键原则: 每个答案成为下一个“为什么？”的主题。
5 Whys 工作流
步骤1: 陈述问题
## 5 Whys 分析
**问题:** [具体问题陈述]
**日期:** [ISO日期]
**分析者:** 5whys-analyst
步骤2: 迭代问为什么
### 为什么链
**问题:** 网站在产品发布期间崩溃。
**为什么1:** 为什么网站崩溃？
→ 服务器内存耗尽。
**为什么2:** 为什么服务器内存耗尽？
→ 应用程序有内存泄漏。
**为什么3:** 为什么应用程序有内存泄漏？
→ 新功能未在负载下适当测试。
**为什么4:** 为什么新功能未在负载下测试？
→ 我们的CI/CD管道中没有负载测试。
**为什么5:** 为什么CI/CD中没有负载测试？
→ 在管道设置时从未优先考虑。
**根本原因:** CI/CD管道初始设置时未包含负载测试。
步骤3: 验证根本原因
| 验证检查 | 问题 | 通过？ |
|---|---|---|
| 具体 | 根本原因是否具体且可操作？ | ☐ |
| 系统性 | 解决此原因是否能防止复发？ | ☐ |
| 可控 | 我们能否实际修复此原因？ | ☐ |
| 链有效 | 每个为什么答案是否逻辑上导致下一个？ | ☐ |
5 Whys 最佳实践
| 做 | 不做 |
|---|---|
| ✅ 关注流程/系统原因 | ❌ 责备个人 |
| ✅ 基于事实和证据回答 | ❌ 没有数据推测 |
| ✅ 持续问直到找到可操作根本原因 | ❌ 在症状处停止 |
| ✅ 记录链以供将来参考 | ❌ 接受“人为错误”作为根本原因 |
| ✅ 考虑多个平行链 | ❌ 假设单一根本原因 |
多5 Whys 链
复杂问题通常有多个促成原因。运行平行5 Whys链：
## 多为什么链
**问题:** 客户投诉增加50%
### 链A: 响应时间
为什么1: 响应时间增加 → 支持队列增长
为什么2: 队列增长 → 可用代理减少
为什么3: 可用代理减少 → 高流动率
为什么4: 高流动率 → 工作条件差
为什么5: 工作条件差 → 没有人体工程学设备
**根本原因A:** 工作场所人体工程学设备缺乏投资
### 链B: 首次接触解决
为什么1: FCR下降 → 代理缺乏知识
为什么2: 缺乏知识 → 培训不足
为什么3: 培训不足 → 产品变化未传达
为什么4: 未传达 → 没有培训更新流程
**根本原因B:** 缺少产品变化培训的流程
### 链C: (根据需要添加更多链)
5 Whys 输出格式
## 5 Whys分析: [问题]
**日期:** [ISO日期]
**分析者:** 5whys-analyst
**问题:** [陈述]
### 为什么链
| 级别 | 问题 | 答案 | 证据 |
|-------|----------|--------|----------|
| 为什么1 | 为什么[问题]? | [答案] | [数据] |
| 为什么2 | 为什么[答案1]? | [答案] | [数据] |
| 为什么3 | 为什么[答案2]? | [答案] | [数据] |
| 为什么4 | 为什么[答案3]? | [答案] | [数据] |
| 为什么5 | 为什么[答案4]? | [答案] | [数据] |
### 根本原因
[最终根本原因陈述]
### 验证
- [ ] 具体且可操作
- [ ] 系统性 (防止复发)
- [ ] 在我们控制范围内
- [ ] 每个步骤逻辑连接
### 纠正行动
| 行动 | 所有者 | 截止 | 状态 |
|--------|-------|-----|--------|
| [针对根本原因的行动] | [名称] | [日期] | 开放 |
5 Whys Mermaid 图
flowchart TD
P[❌ 问题:<br/>网站在发布期间崩溃]
W1[为什么1: 服务器内存耗尽]
W2[为什么2: 应用程序有内存泄漏]
W3[为什么3: 新功能未负载测试]
W4[为什么4: CI/CD管道中无负载测试]
W5[为什么5: 负载测试初始未优先考虑]
RC[🎯 根本原因:<br/>CI/CD设置中缺少负载测试]
P --> W1
W1 --> W2
W2 --> W3
W3 --> W4
W4 --> W5
W5 --> RC
style P fill:#f99,stroke:#900
style RC fill:#9f9,stroke:#090
组合方法
对于全面分析，组合两种技术：
- Fishbone 按类别脑力激荡所有潜在原因
- 5 Whys 对每个高可能性原因深入挖掘
- 验证 找到的多个根本原因
- 优先排序 纠正行动
## 组合RCA: [问题]
### 阶段1: Fishbone脑力激荡
[按类别识别所有潜在原因]
### 阶段2: 5 Whys深入挖掘
对于每个来自Fishbone的高可能性原因：
#### 原因A: [来自Fishbone]
[5 Whys链]
根本原因A: [结果]
#### 原因B: [来自Fishbone]
[5 Whys链]
根本原因B: [结果]
### 阶段3: 根本原因总结
| # | 根本原因 | 来源 | 验证？ | 优先级 |
|---|------------|--------|------------|----------|
| 1 | [RC-A] | Fishbone + 5 Whys | 是 | 高 |
| 2 | [RC-B] | Fishbone + 5 Whys | 是 | 中 |
### 阶段4: 纠正行动计划
[基于验证根本原因的CAPA计划]
纠正行动计划 (CAPA)
行动类型
| 类型 | 目的 | 示例 |
|---|---|---|
| 立即/遏制 | 停止损失 | 禁用故障功能 |
| 纠正 | 修复具体发生 | 补丁缺陷 |
| 预防 | 防止复发 | 添加自动化测试 |
| 系统性 | 解决组织因素 | 更新培训计划 |
CAPA 模板
## 纠正行动计划
**问题:** [参考RCA]
**根本原因:** [列出确认的根本原因]
### 行动
| # | 行动 | 类型 | 根本原因 | 所有者 | 截止日期 | 状态 |
|---|--------|------|------------|-------|-----|--------|
| 1 | [描述] | 纠正 | RC-1 | [名称] | [日期] | 开放 |
| 2 | [描述] | 预防 | RC-1 | [名称] | [日期] | 开放 |
| 3 | [描述] | 系统性 | RC-2 | [名称] | [日期] | 开放 |
### 验证
| 行动 | 验证方法 | 标准 | 结果 |
|--------|---------------------|----------|--------|
| 1 | [如何验证] | [成功标准] | 待定 |
### 跟进
- **审查日期:** [日期]
- **负责人:** [名称]
- **监控指标:** [KPI]
结构化数据 (YAML)
根因分析:
版本: "1.0"
日期: "2025-01-15"
分析者: "rca-analyst"
问题:
陈述: "客户订单延迟在第四季度增加了40%"
影响: "退款$500K, 流失率增加15%"
发现时间: "2025-01-10"
频率: 重复
fishbone:
类别:
人:
- 原因: "培训不足"
证据: "新员工错误率3倍"
可能性: 高
确认: 是
机器:
- 原因: "生产线3设备老化"
证据: "机器7占故障的40%"
可能性: 高
确认: 是
方法:
- 原因: "程序不清晰"
证据: "3个冲突的SOP"
可能性: 高
确认: 是
材料: []
测量: []
环境:
- 原因: "第四季度需求高峰"
证据: "量增加60%"
可能性: 高
确认: 是
五为什么:
- 链名称: "培训差距"
问题: "新员工高错误率"
为什么:
- 问题: "为什么高错误率？"
答案: "培训不足"
- 问题: "为什么培训不足？"
答案: "培训计划未更新"
- 问题: "为什么未更新？"
答案: "没有分配所有者"
- 问题: "为什么没有所有者？"
答案: "流程未建立"
根本原因: "没有维护培训计划的流程"
根本原因:
- id: "RC-1"
描述: "没有培训计划维护流程"
来源: "Fishbone + 5 Whys"
验证: 是
贡献度: 40
capa:
- 行动: "分配培训计划所有者"
类型: 纠正
根本原因: "RC-1"
所有者: "HR总监"
截止日期: "2025-02-01"
状态: 开放
何时使用RCA
| 场景 | 使用RCA？ | 方法 |
|---|---|---|
| 重大事件 | 是 | 完整Fishbone + 5 Whys |
| 重复缺陷 | 是 | 聚焦5 Whys |
| 客户投诉模式 | 是 | 组合方法 |
| 轻微一次性问题 | 可能 | 快速5 Whys |
| 主动改进 | 部分 | Fishbone用于创意 |
集成
上游
- 事件报告 - RCA触发
- 质量指标 - 识别问题
- 利益相关者分析 - 识别团队成员
下游
- 流程改进 - 实施纠正行动
- 培训计划 - 处理人员相关原因
- 价值流映射 - 消除系统性浪费
相关技能
决策分析- 评估纠正行动选项风险分析- 评估根本原因风险价值流映射- 流程改进利益相关者分析- 识别RCA参与者
用户界面
当用户直接调用时，此技能操作如下。
参数
<问题陈述>: 要分析的问题描述--模式: 分析技术 (默认:full)fishbone: Fishbone图与6M类别 (~4K tokens)5whys: 5 Whys深入挖掘技术 (~3K tokens)full: 两种技术组合 (~8K tokens)
--输出: 输出格式 (默认:both)yaml: 结构化YAML供下游处理mermaid: Mermaid图可视化both: 两种格式
--目录: 输出目录 (默认:docs/analysis/)
执行工作流
- 解析参数 - 提取问题陈述、模式和输出格式。如果没有提供问题，询问用户要分析的问题。
- 定义问题 - 澄清问题陈述、影响、频率、首次观察到日期、当前与期望状态以及可用证据。
- 基于模式执行:
- Fishbone: 探索所有6M类别的潜在原因（人、机器、方法、材料、测量、环境），评分可能性，并识别关系。
- 5 Whys: 渐进式问题深入挖掘根本原因。可能需要少于或多于5个为什么。
- Full: 生成
问题解决者代理用于组合Fishbone + 5 Whys分析和CAPA计划。
- 合并根本原因 - 总结发现与证据和置信度评分。
- 开发CAPA计划 - 创建立即纠正、纠正行动（处理根本原因）、预防行动（防止复发）和验证计划。
- 生成输出 - 产生YAML结构、Mermaid鱼骨/流程图和摘要报告。
- 保存结果 - 保存到
docs/analysis/root-cause-analysis.yaml和/或docs/analysis/root-cause-analysis.md(或自定义--目录)。
版本历史
- v1.0.0 (2025-12-26): 初始发布