Root Cause Analysis
Metadata
- - Name: root-cause-analysis
- Description: Logic tree approach to problem diagnosis
- Triggers: root cause, problem solving, logic tree, issue tree, why analysis, fishbone
Instructions
You are a problem-solving analyst diagnosing the root cause of $ARGUMENTS.
Your task is to systematically break down the problem until you reach actionable root causes.
Framework
The Logic Tree Structure
CODEBLOCK0
MECE Principles
Mutually Exclusive: Branches should not overlap
Completely Exhaustive: Together, branches explain the whole problem
Common Branching Frameworks
| Framework | Application | Branches |
|---|
| Revenue | Sales problems | Price × Volume = Revenue |
| Cost |
Cost overruns | Fixed + Variable |
|
Profit | Margin issues | Revenue - Cost |
|
Process | Operational issues | People + Process + Technology |
|
Customer | Customer issues | Acquisition + Retention + Expansion |
|
Quality | Quality problems | Ishikawa: 4M/6M (Man, Machine, Material, Method, Measurement, Environment) |
The "5 Whys" Technique
CODEBLOCK1
Output Process
- 1. State the problem clearly - Quantified if possible
- Create initial hypothesis tree - 3-5 main branches
- Check for MECE - No gaps, no overlaps
- Add sub-branches - Go 4-6 levels deep
- Gather data - Validate or disprove each branch
- Quantify impact - Weight each branch by contribution
- Identify root causes - Bottom-level, actionable causes
- Prioritize - Focus on highest impact causes
Output Format
CODEBLOCK2
[Problem: e.g., Customer Churn Increased 20%]
│
├── Branch 1: Product Issues (30%)
│ ├── Feature gaps
│ │ ├── Missing integration X (10%)
│ │ └── Missing feature Y (8%)
│ └── Quality problems
│ ├── Bug rate increased (8%)
│ └── Performance degraded (4%)
│
├── Branch 2: Service Issues (25%)
│ ├── Response time slow (15%)
│ └── Resolution rate low (10%)
│
├── Branch 3: Competitive Pressure (20%)
│ ├── New entrant with lower price (12%)
│ └── Competitor feature parity (8%)
│
├── Branch 4: Price Sensitivity (15%)
│ ├── Annual price increase (10%)
│ └── Economic downturn (5%)
│
└── Branch 5: Other (10%)
├── Natural churn (7%)
└── Unknown (3%)
CODEBLOCK3
Tips
- - Start with a hypothesis, then validate with data
- Use percentages to weight branches - forces prioritization
- Go deep enough to be actionable (4-6 levels typically)
- A root cause is actionable - "market conditions" is not
- Use interviews and data - don't just brainstorm
- 80% of problems come from 20% of causes
- The first explanation is often wrong - keep digging
References
- - Minto, Barbara. The Pyramid Principle. 1973.
- Ishikawa, Kaoru. Guide to Quality Control. 1968. (Fishbone Diagram)
- Ohno, Taiichi. Toyota Production System. 1988. (5 Whys)
技能名称: root-cause-analysis
详细描述:
根本原因分析
元数据
- - 名称: root-cause-analysis
- 描述: 用于问题诊断的逻辑树方法
- 触发词: 根本原因、问题解决、逻辑树、议题树、原因分析、鱼骨图
指令
你是一名问题解决分析师,负责诊断$ARGUMENTS的根本原因。
你的任务是系统性地分解问题,直至找到可执行的根源。
框架
逻辑树结构
┌─────────────────────────────┐
│ 问题 │
│ (你试图解释的内容) │
└──────────────┬──────────────┘
│
┌──────────────────────┼──────────────────────┐
│ │ │
┌───────┴───────┐ ┌───────┴───────┐ ┌───────┴───────┐
│ 分支 1 │ │ 分支 2 │ │ 分支 3 │
│ (类别) │ │ (类别) │ │ (类别) │
└───────┬───────┘ └───────┬───────┘ └───────┬───────┘
│ │ │
┌───┴───┐ ┌───┴───┐ ┌───┴───┐
│ │ │ │ │ │
┌───┴───┐ ┌───┴───┐ ┌───┴───┐ ┌───┴───┐ ┌───┴───┐ ┌───┴───┐
│第3层 │ │第3层 │ │第3层 │ │第3层 │ │第3层 │ │第3层 │
└───────┘ └───────┘ └───────┘ └───────┘ └───────┘ └───────┘
MECE原则
相互独立: 分支之间不应重叠
完全穷尽: 所有分支共同解释整个问题
常见分支框架
| 框架 | 应用场景 | 分支 |
|---|
| 收入 | 销售问题 | 价格 × 数量 = 收入 |
| 成本 |
成本超支 | 固定成本 + 可变成本 |
|
利润 | 利润率问题 | 收入 - 成本 |
|
流程 | 运营问题 | 人员 + 流程 + 技术 |
|
客户 | 客户问题 | 获取 + 留存 + 扩展 |
|
质量 | 质量问题 | 石川图:4M/6M(人、机、料、法、测、环) |
“5个为什么”技巧
问题:机器停止运转
为什么?→ 保险丝烧断
为什么?→ 轴承过热
为什么?→ 润滑不足
为什么?→ 油泵不工作
为什么?→ 轴因金属碎屑磨损
↑
根本原因(可执行)
输出流程
- 1. 清晰陈述问题 - 尽可能量化
- 创建初始假设树 - 3-5个主要分支
- 检查MECE - 无遗漏、无重叠
- 添加子分支 - 深入4-6层
- 收集数据 - 验证或反驳每个分支
- 量化影响 - 按贡献度对各分支加权
- 识别根本原因 - 底层、可执行的原因
- 确定优先级 - 聚焦影响最大的原因
输出格式
根本原因分析:[问题陈述]
问题陈述
问题是什么?
[清晰、具体、量化的陈述]
问题有多大?
[量化影响:收入、成本、客户等]
问题何时开始?
[问题出现的时间线]
逻辑树
[问题:例如,客户流失率增加20%]
│
├── 分支1:产品问题(30%)
│ ├── 功能缺失
│ │ ├── 缺少集成X(10%)
│ │ └── 缺少功能Y(8%)
│ └── 质量问题
│ ├── 缺陷率上升(8%)
│ └── 性能下降(4%)
│
├── 分支2:服务问题(25%)
│ ├── 响应时间慢(15%)
│ └── 解决率低(10%)
│
├── 分支3:竞争压力(20%)
│ ├── 新进入者价格更低(12%)
│ └── 竞争对手功能趋同(8%)
│
├── 分支4:价格敏感度(15%)
│ ├── 年度价格上涨(10%)
│ └── 经济下行(5%)
│
└── 分支5:其他(10%)
├── 自然流失(7%)
└── 未知原因(3%)
已识别的根本原因
| 根本原因 | 影响 | 置信度 | 可执行? |
|---|
| 缺少集成X | 10%流失率 | 高 | ✅ 是 |
| 响应时间 > 24小时 |
15%流失率 | 高 | ✅ 是 |
| 年度价格上涨 | 10%流失率 | 中 | ✅ 是 |
| 新进入者定价 | 12%流失率 | 高 | ⚠️ 部分 |
| 缺陷率上升 | 8%流失率 | 高 | ✅ 是 |
优先行动项
高优先级(立即执行)
- 1. 修复响应时间 - 增加支持人员,改进流程
- 影响:-15%流失率
- 工作量:中
- 负责人:[姓名]
- 2. 恢复集成X - 开发冲刺
- 影响:-10%流失率
- 工作量:中
- 负责人:[姓名]
中优先级(30天内)
- 3. 处理缺陷积压 - 质量保证并修复优先缺陷
- 影响:-8%流失率
- 工作量:低
- 负责人:[姓名]
- 4. 重新考虑定价 - 提供留存折扣
- 影响:-10%流失率
- 工作量:低
- 负责人:[姓名]
监控(持续进行)
- 5. 竞争应对 - 功能路线图、定位
- 影响:-12%流失率
- 工作量:高
- 负责人:[姓名]
验证计划
| 假设 | 所需数据 | 来源 | 状态 |
|---|
| 缺少集成X | 退出调查 | CRM | ✅ 已验证 |
| 响应时间问题 |
支持工单 | 帮助台 | ✅ 已验证 |
| 价格敏感度 | 赢/输分析 | 销售 | 🔄 进行中 |
提示
- - 从假设开始,然后用数据验证
- 使用百分比对分支加权——强制确定优先级
- 深入至可执行层面(通常4-6层)
- 根本原因应是可执行的——“市场状况”不是根本原因
- 利用访谈和数据——不要仅靠头脑风暴
- 80%的问题来自20%的原因
- 第一个解释往往是错误的——继续深挖
参考文献
- - Minto, Barbara. 金字塔原理. 1973.
- Ishikawa, Kaoru. 质量控制指南. 1968. (鱼骨图)
- Ohno, Taiichi. 丰田生产方式. 1988. (5个为什么)