简介：这份资源是一套面向制药企业QA、设备工程、IT及验证相关岗位的GMP计算机化系统验证管理规程文档，适用于物料控制、实验室设备、生产工艺及公用设施等与GMP相关的计算机控制系统验证场景，帮助读者建立从用户需求到系统验收的全生命周期验证思路。压缩包内共1个doc文件，约230KB，内容涵盖验证目的与范围、各职能部门职责划分、验证小组组成、软硬件分类及对应验证方法、验证清单与实施流程等模块，并附有验证流程图与风险评估步骤说明。目前已有56人学习下载。读者可据此了解质量保证部、使用部门、物料部与工程部信息管理岗在验证中的具体分工，掌握基础软件、非配置软件、可配置软件与用户定制软件的分类逻辑及差异化验证策略，同时获取URS、DQ、IQ、OQ、PQ等环节的执行要点，为实际验证方案编制与偏差变更管理提供可参照的规程模板。
1. 一份 19 页的验证规程，为什么值得制药 IT 和 QA 反复翻
如果你在制药、生物制品或者医疗器械行业做 IT、QA、设备工程，大概率听过这句话：“这个系统要不要做计算机化系统验证？”每次项目立项、设备采购、系统上线，这个问题都会被重新翻出来吵一遍。吵到最后往往不是技术问题，而是没人能拿出一份说得清“什么系统该验、验到什么程度、谁签字负责”的规程。
这份《GMP认证计算机化系统验证管理规程》就是干这个的。它把与 GMP 相关的计算机控制系统从用户需求、风险评估、供应商评估、设计确认、安装确认、运行确认、性能确认，一直到系统引退和回顾验证，整条生命周期串成了一条可执行的流程。适用对象包括物料控制、实验室设备、生产工艺控制、公用设施控制这几类系统，PLC、SCADA、LIMS、ERP 都在射程内。
它适合三类人：一是制药企业里被拉进验证小组的 IT 和工程人员，需要知道自己在 URS、IQ、OQ 各阶段到底要交什么；二是 QA，需要一套能落地的分类和分级判断依据；三是做 GMP 合规咨询或者准备供应商审计的人，需要一份能对照检查的清单。下面我按“怎么用”的顺序，把这份规程拆开讲。
2. 软硬件分类与验证清单：先搞清楚你的系统该验到什么程度
2.1 GAMP 五类软件分类的实操判断
规程里最核心的一张底牌，是引用了 GAMP5 的软件分类逻辑。它不是让你背概念，而是直接决定验证工作量和文件范围。分类依据是三个维度：风险性、复杂性、创新性。落到实操上，我一般按下面这个顺序问自己：
- 这个软件是市售成品，还是为你们定制的？
- 能不能配置？配置程度有多深？
- 有没有自定义代码或者宏？
按规程的划分，软件分五类。第 I 类是基础软件，比如操作系统、数据库引擎、中间件，验证方式就是确认名称、版本号，按批准的安装规程确认安装正确。第 III 类是非配置软件，比如基于中间件的应用程序、COTS 软件、仪表仪器，这类只能用默认配置，验证方式是简化生命周期，记录版本号、确认安装、基于风险做供应商评估、基于风险测试。第 IV 类是可配置软件，比如 ERP、LIMS、SCADA、DCS、CDS，这类能配置业务流程，验证要走完整生命周期，供应商评估要证明其有质量控制体系，还要做基于风险的测试。第 V 类是用户定制软件，包括定制梯级逻辑、定制固件、带宏的电子表格，这类要贯穿整个生命周期的文档资料，供应商评估审计更严格。
这里有个血泪经验：很多团队把“可配置”和“定制”混为一谈。一个 LIMS 如果只是改改字段标签、配配工作流，那是第 IV 类；但如果供应商给你们写了一段专用接口代码，那部分模块就要按第 V 类处理。规程里专门写了一句“部分结构较复杂的计算机控制系统，不能简单的划分为某一类，应根据其每一个模块开发程度进行分类”，这句话是整份文件里最容易被忽略、但审计时最容易被抓的点。
硬件分类相对简单，分标准硬件和客户定制组件。标准硬件就是市售的 PC、打印机、条码扫描仪、PLC、服务器、网络硬件，验证方式是记录厂家、序列号、版本号，做 IQ 安装确认，适用配置管理和变更控制。客户定制组件是按用户需求特殊设计生产的硬件，要做设计说明 DS、验收测试，基于风险对供应商审计。
2.2 验证清单表怎么读、怎么用
规程里有一张“计算机验证清单”表，横轴是软件分类 I、III、IV、V 和硬件分类 I、II，纵轴是 URS、DQ、风险评估、供应商选择和评估、FAT、IQ、OQ、PQ、回顾验证、系统引退报告。打勾的格子代表该类系统需要做这项验证活动。
我把它翻译成一句人话：基础软件（I 类）只需要做 URS、IQ、回顾验证和引退报告；非配置软件（III 类）在 I 类基础上增加风险评估、供应商评估、OQ、PQ；可配置软件（IV 类）几乎全做，包括 DQ、FAT；定制软件（V 类）也是全做，而且文档要求更严。硬件方面，标准硬件（I 类）做 URS 之外的 IQ、回顾验证、引退；定制硬件（II 类）要做 DQ、风险评估、供应商评估、IQ、回顾验证、引退。
注意表里 URS 那一行，软件 I 类打勾，硬件 I 类和 II 类都是叉。这意味着标准硬件不需要单独写用户需求，但定制硬件需要。这个细节在写验证方案时经常被搞反。
提示：这张表是“可以省略、合并，并根据具体设备或系统进行适当调整”的。也就是说它不是死规矩，但任何省略和合并都要在方案里写清楚理由。审计员不会因为你省略了某项而开缺陷，但会因为你说不清为什么省略而开缺陷。
2.3 用 Python 快速生成一份分类判断辅助表
实际项目里系统模块多，靠人脑记分类容易乱。我一般会写个小脚本，把每个模块的属性和对应的验证活动列出来，方便在验证方案里直接引用。下面这段代码不依赖任何第三方库，输入模块信息，输出该模块需要执行的验证项。
# 根据 GAMP5 软硬件分类，输出每个模块对应的验证活动清单 # 分类依据：软件 I/III/IV/V，硬件 I/II # 验证活动矩阵：key 为分类，value 为该分类需要执行的活动集合 software_activities = { "I": {"URS", "IQ", "回顾验证", "系统引退报告"}, "III": {"URS", "风险评估", "供应商评估", "IQ", "OQ", "PQ", "回顾验证", "系统引退报告"}, "IV": {"URS", "DQ", "风险评估", "供应商评估", "FAT", "IQ", "OQ", "PQ", "回顾验证", "系统引退报告"}, "V": {"URS", "DQ", "风险评估", "供应商评估", "FAT", "IQ", "OQ", "PQ", "回顾验证", "系统引退报告"}, } hardware_activities = { "I": {"IQ", "回顾验证", "系统引退报告"}, "II": {"DQ", "风险评估", "供应商评估", "IQ", "回顾验证", "系统引退报告"}, } def get_activities(module_name, sw_class=None, hw_class=None): """输入模块名和软硬件分类，返回需要执行的验证活动""" result = set() if sw_class: result |= software_activities.get(sw_class, set()) if hw_class: result |= hardware_activities.get(hw_class, set()) return sorted(result) # 示例：一个 LIMS 系统，软件为 IV 类可配置，硬件为标准服务器 I 类 activities = get_activities("LIMS 主模块", sw_class="IV", hw_class="I") print("LIMS 主模块需执行：", "、".join(activities)) # 示例：一个定制 PLC 控制逻辑，软件 V 类，硬件 II 类定制组件 activities2 = get_activities("PLC 定制控制逻辑", sw_class="V", hw_class="II") print("PLC 定制控制逻辑需执行：", "、".join(activities2))这段代码的逻辑很直白：用两个字典分别存软件和硬件的验证活动矩阵，get_activities函数把两个集合做并集，最后排序输出。参数sw_class和hw_class分别对应规程里的软件分类和硬件分类，取值就是字符串"I"、"III"、"IV"、"V"和"I"、"II"。实际使用时，你可以把系统拆成若干模块，每个模块调一次，把结果贴进验证方案的范围章节。这样写出来的方案，分类依据和验证活动是一一对应的，审计时经得起追问。
3. 风险评估与供应商评估：把“就高不就低”落到表格里
3.1 从 GxP 关键性到功能影响识别
规程里的风险评估流程分五步：初步风险评估并确认系统影响、确认对患者安全/产品质量/数据完整性有影响的功能、功能性影响评估并识别控制措施、实施并核实控制措施、审查风险与监控控制措施。这五步不是让你写五份文件，而是五个判断动作，最终落到几张表上。
第一步是 GxP 关键性评估。规程给了一张表，六个问题，只要有一个回答“是”，就是 GxP 关键系统。这六个问题分别是：是否生成/处理/控制用于支持法规安全性和功效提交文件的数据；是否控制临床前、临床、开发或生产相关关键参数和数据；是否控制或提供有关产品放行的数据或信息；是否控制与产品召回相关要求的数据或信息；是否控制不良事件或投诉的记录或报告；是否支持药物安全监视。
我见过最常见的翻车现场，是把“实验室用来跑中控的 HPLC 工作站”判成非 GxP 关键。理由听起来很合理：“它只是中控，不直接放行。”但只要它产生的数据用于支持工艺决策或者最终放行判断，第一个问题就踩中了。判断的时候不要问“这个数据重不重要”，要问“这个数据会不会进入放行决策链”。
第二步是影响分级。对患者安全、产品质量、数据完整性三个维度分别评高、中、低。规程里写了一条原则：“可能有多个原因，采取‘就高不就低’原则。”这句话是护身符，也是紧箍咒。护身符是说，当你拿不准的时候，往高了评不会错；紧箍咒是说，你不能因为想省事就故意往低了评，审计员会拿这条原则反问你。
第三步是功能影响识别。把系统拆成功能，比如密码权限、打印功能、审计追踪、软件控制功能、数据备份及存储功能，每个功能单独判断是否 GxP 关键、影响级别是什么。这一步的产出直接决定后面 OQ 测试的深度。影响级别高的功能，测试要更严、重复次数要更多。
3.2 供应商评估的四种方式和选择逻辑
规程里列了四种供应商评估方式：通过自身经验评估、通过公司外的参考意见评价、调查表-信函审核、通过第三方审核进行评价、通过用户所在的公司进行供应商审核。实际选择哪种，取决于风险评估结果，评价标准包括供应商风险和产品风险。
我的经验是：第 I 类基础软件（操作系统、数据库）基本不用做供应商现场审计，记录版本号就行；第 III 类非配置软件，如果供应商有公开的质量体系认证，可以做调查表审核；第 IV 类可配置软件，尤其是 LIMS、ERP 这种，建议做调查表加参考意见，关键供应商要做现场审计；第 V 类定制软件，必须做现场审计，而且要审开发过程文档。
规程里有一句话很关键：“系统所有者应证明并记录归档选择的程序。”也就是说，你选了哪种评估方式，理由要写下来。不能因为“一直这么做的”就跳过。
3.3 用表格把风险评估结果结构化
下面这张表是我根据规程里的表 5 和表 6 整理的实操模板，把功能、风险和可预测故障、严重性 S、可能性 P、可检测性 D、风险等级 RPN、控制措施、措施处理人、处理时间、措施核实串在一起。RPN 的计算方式常见做法是 S×P×D，但规程没有强制公式，你可以用定性分级，也可以用定量乘积，关键是前后一致。
| 功能 | 风险和可预测故障 | S | P | D | RPN | 控制措施 | 处理人 | 处理时间 | 核实 |
|---|---|---|---|---|---|---|---|---|---|
| 密码权限 | 未授权用户访问 | 高 | 中 | 低 | 高 | 强制密码策略、权限分级、审计追踪 | IT | 上线前 | QA 复核 |
| 审计追踪 | 数据修改无记录 | 高 | 低 | 中 | 中 | 开启审计追踪、定期审查 | QA | 持续 | 季度审查 |
| 数据备份 | 备份失败导致数据丢失 | 高 | 中 | 低 | 高 | 双备份、定期恢复演练 | IT | 每月 | 演练报告 |
| 打印功能 | 打印内容与实际不符 | 中 | 低 | 中 | 中 | 打印模板校验、打印日志 | 使用部门 | 上线前 | QA 复核 |
这张表的用法是：先填功能和风险，再评 S/P/D，算出 RPN，然后针对高风险项写控制措施。控制措施不是写“加强管理”这种空话，要写到能验证的程度。比如“强制密码策略”要写明密码长度、复杂度、更换周期；“定期恢复演练”要写明频率和成功标准。
注意：规程里明确写了“影响级别高或影响级别中的系统进行功能影响识别”。也就是说，如果影响分级评出来是低，功能影响识别这一步可以跳过。但跳过要有依据，不能因为想省事就评低。
4. 从 URS 到 PQ：验证执行阶段的文档与测试要点
4.1 URS 里必须写清楚的五类内容
用户需求 URS 是整个验证的起点，由使用部门和工程部人员制定。规程里列了五类内容：系统说明、物理要求、硬件文件标准、软件文件标准、测试要求、对供应商的其他要求。
系统说明要写清楚系统要做什么、各单元之间如何连接及相互作用、控制方式（逻辑控制、分选控制、互锁控制、报警控制、位置控制、速度控制、温度控制、压力控制、时间控制、计数等）、执行过程、操作人员对接口的要求及安全性要求。物理要求包括有效空间、位置、所处环境。硬件文件标准包括图纸、流程图、手册、部件清单。软件文件标准包括程序编号及修订号、输出程序及详细解释、复制件的提供及贮存条件、系统框图及配置清单。测试要求包括系统开发过程中所要求进行的测试项目及记录，包括单独模块测试及集成测试。对供应商的其他要求包括对已完成的系统验证要求、关于在设计开发过程中的质量控制和变更控制要求。
我一般会在 URS 里加一条“可追溯性矩阵”，把每条需求编号，后面 DQ、IQ、OQ、PQ 的测试项都引用这个编号。这样审计的时候，审计员随便挑一条需求，你能在几分钟内找到对应的测试记录。没有这个矩阵，验证报告就是一堆散装文件。
4.2 IQ、OQ、PQ 的测试项拆解
安装确认 IQ 的核心是确认系统安装符合设计标准，所需技术数据俱全。规程里列了文件确认、安装过程确认、环境和公用系统确认、系统测试及确认四块。文件确认包括用户技术指南、标准操作规程、培训计划、售后服务协议、安全程序、设备清单、硬件确认、软件确认、原代码、仪器仪表清单、技术标准及图纸、仪器仪表校验程序、PID 图、控制回路图、I/O 设备清单及接线图、备品备件清单、预防维修程序。环境和公用系统确认包括清洁度、射频/电磁干扰、振动、温湿度、噪声、照明，以及火警通告/抑制、冷却系统、电力及调节、不间断供电、广域网连接、局域网连接、灾难恢复接线、电话数码/模拟等。
运行确认 OQ 的核心是在现场操作环境下对系统所有功能进行确认测试。规程里列了系统安全性测试、过程控制功能测试、报警和互锁功能测试、定时器和序列发生器测试、数据处理和存储功能测试、断电/恢复功能测试。系统安全性测试要挑战所有逻辑系统，比如各工作层的使用权限，证明未经授权的操作得到禁止。过程控制功能测试要在最高特定条件下进行，比如最高通讯负载、大型数据文件的处理。断电/恢复功能测试要复查断电之前、期间和之后的数据采集状况，证明资料没有破坏或丢失，还要测试后备供电、不间断供电和动力调节器、发电机功能恢复是否正常。
性能确认 PQ 的核心是确认系统在正常生产环境下运行过程的有效性和稳定性。如果系统是生产、实验设备或公用设施的一部分，PQ 应与设备（设施）的 PQ 结合在一起完成。当计算机控制系统取代人工系统时，可以进行平行的验证试验。对于生产设备，应对生产出的产品质量特性进行检验，应该在相同生产条件下连续重复 3 次以上。对于连续过程处理的设备，如空气净化系统，应在一定时期内对尘埃粒子、微生物、温湿度、空气流向、压差、换气次数等指标进行监测。
4.3 用 bash 脚本管理验证文档的版本和编号
规程里规定了编号方式：计算机系统评估报告编号为 RA-CS-部门代号-流水号（三位数字），例如实验室计算机系统第一个评估报告 RA-CS-03-001。计算机系统验证方案及报告编号为车间/部门+文件类别+验证类别+序列号，验证类别用 CS 表示，例如实验室计算机系统第一个验证方案 03VPCS001，第一个验证报告 03VRCS001。
实际项目里文件版本多了容易乱，我一般用一段 bash 脚本做命名检查和归档。下面这段脚本不依赖外部工具，输入部门代号和流水号，生成标准文件名并检查目录里是否已存在。
#!/bin/bash # 生成 GMP 计算机化系统验证文件的标准编号 # 用法：./gen_doc_id.sh <部门代号> <流水号> <类型> # 类型：RA 表示评估报告，VP 表示验证方案，VR 表示验证报告 DEPT=$1 SEQ=$2 TYPE=$3 # 流水号补零到三位 SEQ_PADDED=$(printf "%03d" "$SEQ") case "$TYPE" in RA) DOC_ID="RA-CS-${DEPT}-${SEQ_PADDED}" ;; VP) DOC_ID="${DEPT}VPCS${SEQ_PADDED}" ;; VR) DOC_ID="${DEPT}VRCS${SEQ_PADDED}" ;; *) echo "未知类型：$TYPE，请使用 RA / VP / VR" exit 1 ;; esac echo "生成的文件编号：${DOC_ID}" # 检查当前目录是否已有同名文件 if ls "${DOC_ID}"* 1> /dev/null 2>&1; then echo "警告：当前目录已存在以 ${DOC_ID} 开头的文件，请检查是否重复。" else echo "当前目录无同名文件，可以创建。" fi这段脚本的逻辑是：接收三个参数，部门代号、流水号、类型，根据类型拼接不同的编号格式。printf "%03d"把流水号补成三位数，保证 001 而不是 1。最后用ls检查当前目录有没有同名文件，避免重复编号。参数说明：DEPT是部门代号，比如实验室是 03；SEQ是流水号，从 1 开始；TYPE是文件类型，RA 对应评估报告，VP 对应验证方案，VR 对应验证报告。实际使用时，可以在验证方案起草前先跑一遍，确认编号没被占用。
5. 避坑与排查：验证执行中最容易翻车的五个点
5.1 偏差处理不及时，关键项未确认就进入下一步
现象：验证执行过程中发现某个测试项没通过，但为了赶进度，先做下一步确认，打算后面补做。原因：规程里写了“某些非关键项目的测试未进行前可执行下一步的确认，该项目应作为偏差进行描述并在报告中明确解释。关键项目未进行确认前进行下一步确认是不允许的。”但实际操作时，很多人分不清关键项和非关键项，或者故意把关键项说成非关键项。解决：在验证方案里提前列出关键项清单，任何关键项未通过，必须走偏差管理规程，不能跳过。偏差报告要写清楚原因、影响评估、纠正措施和再验证计划。
5.2 变更控制漏掉数据库关键参数
现象：系统升级或者硬件更换后，只做了软件版本确认，没有检查数据库里的关键参数是否被重置。原因：规程里明确写了变更类型包括“数据库中关键参数的变更”，但很多人只盯着软件和硬件，忘了数据库。解决：变更申请时，要求供应商提供数据库参数清单，变更后逐项核对。如果参数被重置，要评估是否影响已验证状态，必要时做再验证。
5.3 回顾性验证周期一刀切
现象：所有计算机化系统都按 3 年做回顾性验证，不管分类。原因：规程里写了“对于 III、IV 类计算机控制系统，回顾性运行验证的周期一般为 3 年，其他计算机控制系统可以适当延长至 5 年。”但实际执行时，有人图省事全部按 3 年，有人全部按 5 年。解决：按分类定周期，III 类和 IV 类 3 年，I 类和 V 类可以 5 年。回顾性验证以数据分析为主，可以把周期均分为数个区间，分阶段进行数据分析，最后汇总。
5.4 系统引退时数据迁移不完整
现象：旧系统停用，新系统上线，但旧系统里的历史数据没有完整迁移，或者迁移后没有验证。原因：规程里写了“原系统数据必须被完整地转移到新系统中，这是新系统验证的一部分。”但实际操作时，数据迁移往往被当成 IT 项目，没有纳入验证范围。解决：引退计划里要包含数据迁移方案和迁移验证方案，迁移后要做数据完整性检查，确认记录数、关键字段、审计追踪都完整。
5.5 供应商审计流于形式
现象：供应商审计报告只有一页纸，写着“供应商质量体系符合要求”，没有具体审核记录。原因：规程里写了“供应商审查应在报告中详细记录并给出最终水平。其他评估也应在报告概述中记录并给出最终水平。”但实际执行时，审计人员可能没有接受过培训，或者时间不够。解决：供应商审计报告要包含审核范围、审核发现、不符合项、纠正措施、最终结论。对于第 IV 类和第 V 类软件供应商，建议做现场审计，审核开发过程文档和质量控制记录。
6. 回顾验证与系统引退：验证状态维持的最后一公里
回顾性验证是很多团队容易忽略的环节。规程里写得很清楚：所有验证的计算机控制系统都必须进行回顾性验证，以确认计算机控制系统的状态始终处于验证状态。回顾内容包含六项：计算机控制系统的维护、变更、数据统计分析、硬件检查、软件的安全性稳定性检查及评估、偏差处理及统计分析。
我一般会把回顾性验证做成一个年度检查表，按下面这个结构组织：
| 回顾项 | 数据来源 | 检查要点 | 输出 |
|---|---|---|---|
| 系统维护 | 维护工单 | 维护频率、故障类型、修复时间 | 维护趋势分析 |
| 系统变更 | 变更记录 | 变更数量、变更类型、再验证情况 | 变更影响评估 |
| 数据统计分析 | 系统日志 | 数据完整性、审计追踪审查 | 数据完整性报告 |
| 硬件检查 | 硬件清单 | 序列号、版本号、配置一致性 | 硬件状态确认 |
| 软件安全性稳定性 | 版本记录、补丁记录 | 版本一致性、补丁安装、漏洞修复 | 软件状态确认 |
| 偏差处理 | 偏差记录 | 偏差数量、根本原因、纠正措施 | 偏差趋势分析 |
回顾性验证的周期，III 类和 IV 类一般 3 年，其他可以延长到 5 年。为了避免一次性分析大量数据，可以把周期均分为数个区间，分阶段进行数据分析，最后汇总。比如 3 年周期可以按每 6 个月一个区间，分 6 次做数据分析，最后汇总成一份回顾报告。
系统引退是验证生命周期的终点，也是最容易出问题的地方。规程里写了引退计划的制定、数据转移、通知相关部门、撤销系统特殊程序、切断系统通道、整理系统所有逻辑值符号和菜单参考、删除所有软件和工作环境下存档的电子记录。最后要写引退报告，总结整个引退工作的实际执行结果。
我自己的习惯是：每次系统引退前，先做一次数据完整性检查，确认所有需要保留的数据已经迁移到新系统或者归档到指定的电子记录存储位置。然后做一次权限清理，确认所有旧系统的账号、角色、访问通道都已经关闭。最后做一次文档归档，把引退计划、数据迁移记录、引退报告一起交给文件 QA 归档。从那以后我每次做系统引退，都强制走一遍“数据迁移验证、权限清理确认、文档归档检查”这三步，少一步都不签字。希望帮到你。
本文还有配套的精品资源，点击获取
