name: investigate-capa-root-cause description: > 调查合规偏差的根本原因并管理 CAPA（纠正和预防措施）。涵盖调查方法选择 （5-Why、鱼骨图、故障树）、结构化根本原因分析、纠正措施与预防措施设计、 有效性验证及趋势分析。适用于审计发现需要 CAPA、已验证系统中发生偏差或 事件、法规检查观察需要正式回应、数据完整性异常需要调查，或重复出现的问题 表明存在系统性根本原因时使用。 locale: zh-CN source_locale: en source_commit: 6f65f316 translator: claude-opus-4-6 translation_date: 2026-03-16 license: MIT allowed-tools: Read Write Edit Bash Grep Glob metadata: author: Philipp Thoss version: "1.0" domain: compliance complexity: intermediate language: multi tags: gxp, capa, root-cause, investigation, fishbone, five-why, compliance

调查 CAPA 根本原因

对合规偏差开展结构化根本原因调查，并制定有效的纠正和预防措施。

适用场景

• 审计发现需要 CAPA
• 已验证系统中发生偏差或事件
• 法规检查观察需要正式回应
• 数据完整性异常需要调查
• 重复出现的问题表明存在系统性根本原因

输入

• 必填：偏差、发现或事件的描述
• 必填：严重性分类（关键、重大、轻微）
• 必填：审计或调查期间收集的证据
• 可选：以往相关的 CAPA 或调查
• 可选：相关 SOP、验证文档和系统日志
• 可选：涉事人员的访谈记录

步骤

第 1 步：启动调查

# 根本原因调查
## 文档 ID：RCA-[CAPA-ID]
## CAPA 参考：CAPA-[YYYY]-[NNN]

### 1. 触发原因
| 字段 | 内容 |
|------|------|
| 来源 | [审计发现 / 偏差 / 检查观察 / 监测警报] |
| 参考 | [发现 ID、偏差 ID 或观察编号] |
| 系统 | [受影响系统名称和版本] |
| 发现日期 | [YYYY-MM-DD] |
| 严重性 | [关键 / 重大 / 轻微] |
| 调查员 | [姓名、职务] |
| 调查截止日期 | [日期——按严重性：关键 15 天、重大 30 天、轻微 60 天] |

### 2. 问题陈述
[客观、基于事实描述发生了什么、应该发生什么，以及两者之间的差距。不指责、不臆测。]

### 3. 即时遏制措施（如需）
| 行动 | 负责人 | 完成日期 |
|------|------|---------|
| [如限制系统访问，待调查期间] | [姓名] | [日期] |
| [如隔离受影响的批次记录] | [姓名] | [日期] |
| [如实施手动变通方案] | [姓名] | [日期] |

预期结果： 调查在关键发现后 24 小时内启动，有明确的问题陈述和遏制行动。 失败处理： 若无法立即实施遏制措施，上报 QA 总监并记录延迟遏制的风险。

第 2 步：选择调查方法

根据问题复杂程度选择方法：

### 调查方法选择

| 方法 | 最适用于 | 复杂程度 | 输出 |
|------|---------|---------|------|
| **5-Why 分析** | 单一原因问题、直接失败 | 低 | 线性原因链 |
| **鱼骨图（石川图）** | 多因素问题、流程失败 | 中 | 因果关系图 |
| **故障树分析** | 系统失败、安全关键事件 | 高 | 布尔逻辑树 |

**选定方法：** [5-Why / 鱼骨图 / 故障树 / 组合]
**选择依据：** [为何此方法适用于该问题]

预期结果： 选定方法与问题复杂程度相匹配——不要对简单的程序错误使用故障树，也不要对复杂的系统性失败使用 5-Why。 失败处理： 若第一种方法未能找到令人信服的根本原因，采用第二种方法。多种方法的结论相互印证可加强结论的可信度。

第 3 步：开展根本原因分析

方法 A：5-Why 分析

### 5-Why 分析

| 层级 | 问题 | 回答 | 证据 |
|------|------|------|------|
| Why 1 | 为什么[问题]发生？ | [直接原因] | [证据参考] |
| Why 2 | 为什么[直接原因]发生？ | [促成因素] | [证据参考] |
| Why 3 | 为什么[促成因素]发生？ | [更深层原因] | [证据参考] |
| Why 4 | 为什么[更深层原因]发生？ | [系统性原因] | [证据参考] |
| Why 5 | 为什么[系统性原因]发生？ | [根本原因] | [证据参考] |

**根本原因：** [对根本原因的清晰表述]

方法 B：鱼骨图（石川图）

### 鱼骨图分析

对六大标准类别中的原因进行分析：

| 类别 | 潜在原因 | 已确认？ | 证据 |
|------|---------|---------|------|
| **人员** | 培训不足、不熟悉 SOP、人员短缺 | [是/否] | [参考] |
| **流程** | SOP 不清晰、缺少步骤、顺序错误 | [是/否] | [参考] |
| **技术** | 系统配置错误、软件缺陷、接口故障 | [是/否] | [参考] |
| **材料** | 输入数据错误、参考文件版本错误 | [是/否] | [参考] |
| **测量** | 指标错误、监测不足、未达到阈值 | [是/否] | [参考] |
| **环境** | 组织变更、法规变更、资源限制 | [是/否] | [参考] |

**促成原因：** [列出已确认的原因]
**根本原因：** [根本原因——可能不止一个]

方法 C：故障树分析

### 故障树分析

**顶层事件：** [不期望发生的事件]

第 1 层（或门——以下任何一项均可导致顶层事件）：
├── [原因 A]
│   第 2 层（与门——两者均需）：
│   ├── [子原因 A1]
│   └── [子原因 A2]
├── [原因 B]
│   第 2 层（或门）：
│   ├── [子原因 B1]
│   └── [子原因 B2]
└── [原因 C]

**最小割集：** [导致顶层事件的最小事件组合]
**根本原因：** [在故障树中识别出的根本失败]

预期结果： 根本原因分析找到根本原因（而非仅症状），每个分析步骤均有支持证据。 失败处理： 若分析只得出症状（"用户出错了"），则继续深挖。追问："为什么用户能犯这个错误？本应存在什么控制措施来防止它？"

第 4 步：设计纠正和预防措施

明确区分纠正、纠正措施和预防措施：

### CAPA 计划

| 类别 | 定义 | 行动 | 负责人 | 截止日期 |
|------|------|------|------|---------|
| **纠正** | 修复当前问题 | [如重新启用批次模块的审计追踪] | [姓名] | [日期] |
| **纠正措施** | 消除根本原因 | [如取消管理员禁用审计追踪的能力；要求所有审计追踪配置变更经过变更控制] | [姓名] | [日期] |
| **预防措施** | 防止在其他领域复发 | [如审计所有系统的审计追踪禁用能力；为审计追踪配置变更添加监测警报] | [姓名] | [日期] |

### CAPA 详情

**CAPA-[YYYY]-[NNN]-CA1：[纠正措施标题]**
- **所针对的根本原因：** [第 3 步中的具体根本原因]
- **行动描述：** [将要做什么的详细描述]
- **成功标准：** [证明行动有效的可测量结果]
- **验证方法：** [如何检验有效性]
- **验证日期：** [何时验证有效性——通常是实施后 3-6 个月]

**CAPA-[YYYY]-[NNN]-PA1：[预防措施标题]**
- **所防范的风险：** [防止什么复发或蔓延]
- **行动描述：** [详细描述]
- **成功标准：** [可测量的结果]
- **验证方法：** [如何检验有效性]
- **验证日期：** [日期]

预期结果： 每项 CAPA 行动均可追溯到特定根本原因，有可测量的成功标准，并包含有效性验证计划。 失败处理： 若成功标准模糊（"改善合规性"），改写为具体且可测量的表述（"连续 6 个月内审计追踪配置变更零例发生在变更控制之外"）。

第 5 步：验证有效性

CAPA 实施后，验证这些行动是否真正起到了作用：

### 有效性验证

**CAPA-[YYYY]-[NNN] — 验证记录**

| CAPA 行动 | 验证日期 | 方法 | 证据 | 结果 |
|---------|---------|------|------|------|
| CA1：[行动] | [日期] | [方法：审计、抽样、指标审查] | [证据参考] | [有效 / 无效] |
| PA1：[行动] | [日期] | [方法] | [证据参考] | [有效 / 无效] |

### 有效性标准检查
- [ ] 自 CAPA 实施以来，原始问题未复发
- [ ] 纠正措施已消除根本原因（证据：[参考]）
- [ ] 预防措施已应用于类似系统/流程
- [ ] CAPA 行动未引入新问题

### CAPA 关闭
| 字段 | 内容 |
|------|------|
| 关闭决定 | [已关闭——有效 / 已关闭——无效 / 延期] |
| 关闭人 | [姓名、职务] |
| 关闭日期 | [YYYY-MM-DD] |
| 下次审查 | [若为周期性问题，何时重新检查] |

预期结果： 有效性验证证明根本原因确实被消除，而不仅仅是行动已完成。 失败处理： 若验证表明 CAPA 无效，重新启动调查并制定修订后的行动。不得关闭无效的 CAPA。

第 6 步：分析 CAPA 趋势

### CAPA 趋势分析

| 时间段 | CAPA 总数 | 按来源 | 前 3 位根本原因类别 | 是否复发？ |
|--------|---------|------|----------------|---------|
| 20XX 年 Q1 | [N] | 审计：[n]，偏差：[n]，监测：[n] | [类别1]、[类别2]、[类别3] | [是/否] |
| 20XX 年 Q2 | [N] | 审计：[n]，偏差：[n]，监测：[n] | [类别1]、[类别2]、[类别3] | [是/否] |

### 系统性问题
| 问题 | 频次 | 受影响系统 | 建议行动 |
|------|------|---------|---------|
| [如培训差距] | [12 个月内出现 N 次] | [系统] | [系统性计划改进] |

预期结果： 趋势分析识别出个别 CAPA 所遗漏的系统性问题。 失败处理： 若趋势揭示出尽管已有 CAPA 但根本原因仍反复出现，则说明这些 CAPA 只是在治标。上报管理层审查以进行系统性干预。

验证清单

• 调查在规定时间内启动（关键：24 小时内，重大：72 小时内）
• 问题陈述基于事实且不指责任何人
• 调查方法与问题复杂程度相匹配
• 根本原因分析找到根本原因（而非仅症状）
• 每个根本原因分析步骤均有证据支持
• CAPA 明确区分纠正、纠正措施和预防措施
• 每项 CAPA 均有可测量的成功标准和验证计划
• 关闭 CAPA 前已有证据证明其有效性
• 趋势分析至少每季度审查一次

常见问题

• 止步于症状："用户出错了"不是根本原因。根本原因是系统或流程为何允许错误发生
• CAPA = 再培训：再培训只针对一种可能的根本原因（知识）。若真正的根本原因是系统设计缺陷或 SOP 不清晰，再培训无法防止复发
• 未经验证就关闭：完成行动并不等同于验证其有效性。未经有效性验证就关闭 CAPA 是在等待法规引用
• 以责任为导向的调查：专注于谁犯了错误而非什么允许了错误的调查，会破坏质量文化并阻碍问题上报
• 不做趋势分析：个别 CAPA 可能看似无关，但趋势分析往往揭示系统性问题（如多个系统的"培训"根本原因可能表明培训计划存在缺陷）

相关技能

• conduct-gxp-audit — 审计产生需要 CAPA 的发现
• monitor-data-integrity — 监测发现触发调查的异常
• manage-change-control — CAPA 驱动的变更需经过变更控制
• prepare-inspection-readiness — 未结和逾期的 CAPA 是检查的主要目标
• design-training-program — 当根本原因与培训相关时，改善培训计划