Write Standard Operating Procedure

---
name: write-standard-operating-procedure
description: >
  编写符合 GxP 的标准操作程序（SOP）。涵盖法规 SOP 模板结构（目的、
  范围、定义、职责、程序、参考、修订历史）、审批工作流程设计、定期
  审核计划和系统使用的操作程序。适用于新的已验证系统需要操作程序、
  现有非正式程序需要正式化、审计发现引用缺少程序、变更控制触发
  SOP 更新，或定期审核发现程序内容已过时时使用。
locale: zh-CN
source_locale: en
source_commit: 6f65f316
fence_basis_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, sop, procedure, documentation, compliance, quality-management
---

# 编写标准操作程序

创建符合 GxP 的标准操作程序，为受监管活动提供清晰、可审计的指令。

## 适用场景

- 新的已验证系统需要操作程序
- 现有程序需要正式化为 SOP 格式
- 审计发现引用缺少或不充分的程序
- 变更控制触发 SOP 更新
- 定期审核发现程序内容已过时

## 输入

- **必填**：SOP 涵盖的流程或系统
- **必填**：法规背景（GMP、GLP、GCP、21 CFR Part 11、EU Annex 11）
- **必填**：目标受众（将遵循本 SOP 的角色）
- **可选**：现有非正式程序、工作指令或培训材料
- **可选**：与本程序有接口的相关 SOP
- **可选**：推动 SOP 创建的审计发现或法规观察

## 步骤

### 第 1 步：分配文件控制元数据

```markdown
# 标准操作程序
## 文档 ID：SOP-[DEPT]-[NNN]
## 标题：[程序的描述性标题]

| 字段 | 内容 |
|------|------|
| 文档 ID | SOP-[DEPT]-[NNN] |
| 版本 | 1.0 |
| 生效日期 | [YYYY-MM-DD] |
| 审核日期 | [YYYY-MM-DD + 审核周期] |
| 部门 | [部门名称] |
| 起草人 | [姓名，职位] |
| 审核人 | [姓名，职位] |
| 批准人 | [姓名，职位] |
| 分类 | [GxP 关键 / GxP 支持] |
| 代替 | [前一版 SOP ID 或"不适用——新文件"] |
```

**预期结果：** 每份 SOP 都有遵循组织文件编号惯例的唯一 ID。
**失败处理：** 若不存在编号惯例，在继续前建立一个：[类型]-[部门]-[3 位顺序号]。

### 第 2 步：编写目的和范围

```markdown
### 1. 目的
本 SOP 定义了 [具体活动] 的程序，以确保 [法规目标]。

### 2. 范围
**在范围内：**
- [涵盖的系统、流程或活动]
- [适用的部门或角色]
- [处理的具体法规要求]

**不在范围内：**
- [其他 SOP 涵盖的相关活动——引用它们]
- [未涵盖的系统或部门]
```

**预期结果：** 目的为一至两句话。范围清晰定义边界。
**失败处理：** 若范围与现有 SOP 重叠，要么引用现有 SOP 的重叠部分，要么修订两份 SOP 以消除重叠。

### 第 3 步：定义术语和缩写

```markdown
### 3. 定义和缩写

| 术语 | 定义 |
|------|------|
| ALCOA+ | 可归因、清晰、及时、原始、准确 + 完整、一致、持久、可获取 |
| CCB | 变更控制委员会 |
| GxP | 良好 [生产/实验室/临床] 规范——所有受监管质量标准的总称 |
| SOP | 标准操作程序 |
| [添加本 SOP 特定术语] | [定义] |
```

**预期结果：** SOP 中使用的每个缩写和技术术语均已定义。
**失败处理：** 若某术语含义不明确或具有领域特异性，参阅组织词汇表或相关法规指南获取权威定义。

### 第 4 步：分配职责

```markdown
### 4. 职责

| 角色 | 职责 |
|------|------|
| 系统负责人 | 确保 SOP 合规，批准变更，进行定期审核 |
| 系统管理员 | 按本 SOP 执行日常操作，报告偏差 |
| 质量保证 | 审核 SOP 的法规合规性，批准新版本 |
| 终端用户 | 按书面程序操作，向系统管理员报告问题 |
| 培训协调员 | 确保所有相关人员在 SOP 生效日期前完成培训 |
```

**预期结果：** 程序章节中的每个操作均可追溯到负责角色。
**失败处理：** 若某程序步骤没有分配角色，则为孤立职责，在 SOP 批准前分配责任人。

### 第 5 步：编写程序章节

这是 SOP 的核心。编写分步说明：

```markdown
### 5. 程序

#### 5.1 [第一项主要活动]
1. [动作动词] [具体指令]。参考：[表单、系统界面、工具]。
2. [动作动词] [具体指令]。
   - 若 [条件]，则 [操作]。
   - 若 [其他条件]，则 [其他操作]。
3. [动作动词] [具体指令]。
4. 在 [表单/系统/日志] 中记录结果。

#### 5.2 [第二项主要活动]
1. [动作动词] [具体指令]。
2. 验证 [具体标准]。
3. 若验证失败，启动 [偏差程序——参考 SOP-XXX]。

#### 5.3 偏差处理
1. 若任何步骤无法按书面执行，停止并记录偏差。
2. 在 [时限] 内通知 [角色]。
3. 填写偏差表单 [表单引用]。
4. 在 [角色] 提供处置意见之前不得继续。
```

GxP SOP 编写规则：
- 每个步骤以动作动词开头（验证、记录、输入、批准、通知）
- 具体到经培训的操作人员无需解释即可遵循
- 包含含有每条路径明确标准的决策点
- 引用确切的表单名称、系统界面或工具标识符
- 包含工作必须暂停等待批准或验证的保持点

**预期结果：** 不熟悉该具体流程的受培训人员能够正确遵循这些步骤。
**失败处理：** 若主题专家认为程序存在歧义，增加细节或将步骤拆分为子步骤。SOP 中的歧义是反复出现的审计发现。

### 第 6 步：添加参考资料、附件和修订历史

```markdown
### 6. 参考资料
| 文档 ID | 标题 |
|--------|------|
| SOP-QA-001 | 文件控制 |
| SOP-IT-015 | 用户访问管理 |
| [法规参考] | [如 21 CFR Part 11] |

### 7. 附件
| 附件 | 描述 |
|------|------|
| Form-001 | [表单名称和用途] |
| Template-001 | [模板名称和用途] |

### 8. 修订历史
| 版本 | 日期 | 起草人 | 变更描述 |
|------|------|--------|---------|
| 1.0 | [日期] | [姓名] | 初始发布 |
```

**预期结果：** 所有引用文件对用户可访问，修订历史从 1.0 版本开始。
**失败处理：** 若引用文件尚不存在，要么创建它们，要么删除引用并在 SOP 审核中记录该差距。

### 第 7 步：路由审核和批准

```markdown
### 批准签名

| 角色 | 姓名 | 签名 | 日期 |
|------|------|------|------|
| 起草人 | [姓名] | | |
| 技术审核人 | [姓名] | | |
| QA 审核人 | [姓名] | | |
| 批准人（部门负责人） | [姓名] | | |

### 培训要求
第 4 节列出的所有人员必须在生效日期前完成本 SOP 培训，培训必须在培训管理系统中记录。

### 定期审核
本 SOP 必须至少每 [2 年 / 每年] 审核一次，或在以下情况时触发：
- 变更控制影响涵盖的流程或系统
- 与涵盖流程相关的审计发现
- 影响涵盖要求的法规指南更新
```

**预期结果：** SOP 在生效前经主题专家审核并由质量部门批准。
**失败处理：** 若审批工作流程延迟，生效日期必须相应推迟。未完成审批的 SOP 不能生效。

## 验证清单

- [ ] 文档 ID 遵循组织的编号惯例
- [ ] 目的具体且简洁（1-2 句话）
- [ ] 范围清晰定义了在范围内和不在范围内的边界
- [ ] 所有缩写和技术术语均已定义
- [ ] 职责章节中的每个角色均映射到程序步骤
- [ ] 程序步骤以动作动词开头，具体到无需解释即可遵循
- [ ] 决策点对每条路径均有明确标准
- [ ] 已定义偏差处理
- [ ] 所有引用文件均存在且可访问
- [ ] 修订历史从 1.0 版本开始完整记录
- [ ] 批准签名包含起草人、审核人和批准人
- [ ] 已定义定期审核计划

## 常见问题

- **过于模糊**："确保数据质量"不是程序步骤。"按附录 A 验证 Form-001 中所有 15 个字段均已填写且在范围内"才是
- **过于详细**：为每种可能的错误加入故障排除使 SOP 难以阅读。将复杂的故障排除引用至单独的工作指令
- **无偏差处理**：每份 SOP 必须定义当程序无法按书面执行时应如何处理，对偏差保持沉默意味着不可能出现偏差
- **生效前未完成培训**：在所有用户培训之前生效的 SOP 会立即产生合规差距
- **孤立 SOP**：从不审核的 SOP 会变得过时且不可靠。设置审核日期并在文件控制系统中追踪

## 相关技能

- `design-compliance-architecture` — 确定哪些系统和流程需要 SOP
- `manage-change-control` — 流程变更时触发 SOP 更新
- `design-training-program` — 确保用户接受新的和更新的 SOP 培训
- `conduct-gxp-audit` — 审计评估 SOP 的充分性和遵守情况
- `write-validation-documentation` — SOP 和验证文档共享审批工作流程