investigate-capa-root-cause

pjt222

更新于 2 days ago

6 次查看

其他general

关于

This skill helps developers conduct structured root cause investigations for compliance deviations and manage CAPA (Corrective and Preventive Actions). It guides users through selecting analysis methods (5-Why, Fishbone, Fault Tree), designing corrective measures, and verifying effectiveness. Use it when addressing audit findings, system deviations, regulatory observations, data integrity issues, or recurring problems requiring formal investigation.

快速安装

Claude Code

技能文档

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 可能看似无关，但趋势分析往往揭示系统性问题（如多个系统的"培训"根本原因可能表明培训计划存在缺陷）

GitHub 仓库

pjt222/agent-almanac

路径: i18n/zh-CN/skills/investigate-capa-root-cause

agentsagentskillsai-assisted-developmentclaude-codeskillsteams