Root Cause Analysis（根本原因分析）

知识库位置：FDE Knowledge Base/02 Business/06-Root-Cause-Analysis.md

Definition（定义）

Root Cause Analysis（根本原因分析）的目标是：

不解决症状（Symptom，表面现象），而解决导致问题反复出现的真正原因。

例如：

客服响应慢。

只是症状。

可能的根因：

信息分散
权限复杂
CRM 太慢
流程需要三级审批
培训不足
数据不完整

不同根因对应完全不同的解决方案。

Basic Model（基本模型）

Symptom（症状）
↓
Problem（问题）
↓
Contributing Factors（促成因素）
↓
Root Cause（根本原因）
↓
Intervention（干预措施）

5 Whys（五问法）

一个简单但有效的方法。

例如：

Problem（问题）

客户支持平均处理时间过长。

Why 1（第一问）

为什么？

客服花大量时间找答案。

Why 2（第二问）

为什么找答案需要很久？

知识存在多个系统。

Why 3（第三问）

为什么多个系统没有统一搜索？

不同团队分别维护知识。

Why 4（第四问）

为什么没有统一知识治理？

没有明确 Knowledge Owner（知识责任人）。

最终发现：

搜索技术只是问题的一部分，知识治理也是根因。

Fishbone Categories（鱼骨图维度）

复杂问题可以从多个维度分析（Fishbone Analysis，鱼骨分析）：

People（人员）
Process（流程）
Technology（技术）
Data（数据）
Policy（政策）
Organization（组织）
Environment（环境）

例如 AI 项目表现差：

People（人员）

用户不会正确使用。

Process（流程）

AI 没有嵌入工作流程。

Technology（技术）

系统延迟高。

Data（数据）

知识过期。

Policy（政策）

自动化权限过低。

Root Cause vs Contributing Factor（根本原因 vs 促成因素）

要注意区别。

例如：

High latency（高延迟）

可能是问题。

原因：

CRM API slow（CRM 接口慢）

但 CRM API 慢可能只是一个 Contributing Factor（促成因素）。

业务层根因可能是：

一个用户请求需要串行调用 8 个系统。

因此最终解决方案可能是：

Cache（缓存）
Parallel Calls（并行调用）
Data Aggregation（数据聚合）

而不是单纯要求 CRM 团队提速。

Evidence-based RCA（基于证据的根本原因分析）

不要只凭感觉。

使用：

User Interviews（用户访谈）
Logs（日志）
Metrics（指标）
Process Timing（流程计时）
Data Analysis（数据分析）
Error Records（错误记录）
Support Tickets（支持工单）

FDE Principle（FDE 原则）

不要从：

我们能用什么技术？

开始。

先问：

为什么这个问题会发生？

Output（产出）

推荐产出：

Problem（问题）:
Root Cause（根本原因）:
Evidence（证据）:
Business Impact（业务影响）:
Candidate Intervention（候选干预措施）:
Validation Method（验证方法）: