编写标准操作程序

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

适用场景

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

输入

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

步骤

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

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

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

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

第 2 步：编写目的和范围

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

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

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

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

第 3 步：定义术语和缩写

### 3. 定义和缩写

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

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

第 4 步：分配职责

### 4. 职责

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

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

第 5 步：编写程序章节

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

### 5. 程序

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

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

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

GxP SOP 编写规则：

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

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

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

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

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

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

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

第 7 步：路由审核和批准

### 批准签名

| 角色 | 姓名 | 签名 | 日期 |
|------|------|------|------|
| 起草人 | [姓名] | | |
| 技术审核人 | [姓名] | | |
| 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 和验证文档共享审批工作流程