计算机系统验证甘特图模板：含IQ、OQ和PQ
可编辑的计算机系统验证甘特图：验证计划、需求、风险、配置、随构建同步编写的IQ/OQ/PQ脚本、偏差、可追溯性审核、报告与放行。
什么是计算机系统验证甘特图模板：含IQ、OQ和PQ流程
验证一个计算机化系统很少是因为测试本身而慢。慢在脚本是构建之后才写，失败的步骤开出一个没人有时间处理的偏差，最后的可追溯性检查又发现某条需求没有任何测试覆盖。时间线无法解决这些问题，但能在项目走到那里之前就显示这些等待在哪里。
这个模板有四组：规划与风险、规格与构建、测试脚本与执行、报告与放行，共20项任务和四个里程碑：“验证计划已批准”、“执行完成”、“验证报告已批准”和“放行系统投入使用”。“编写验证计划”（5个工作日）和“起草用户需求”（6）是两项起始任务。“评估对患者和数据的风险”（4）在需求进行2天后开始，所以风险评估看到的是初稿而不是等完成稿，两者都汇入“验证计划已批准”。
计划是构建的关口，而不是脚本的关口。“编写功能规格”（6）要等“验证计划已批准”。“配置系统”（10）在规格进行3天后开始，“起草操作规程”（5）在配置进行4天后开始。脚本在这些工作进行时编写：“编写安装确认脚本”（3）和“编写运行确认脚本”（5）要等规格，而“编写性能确认脚本”（5）只等风险评估，所以可以在系统就绪之前针对需求编写。
执行阶段，顺序最重要。“执行安装确认”（3）既需要配置好的系统，也需要它的脚本。“执行运行确认”（8）跟在其后，并需要自己的脚本。“解决测试偏差”（5）在运行确认进行3天后开始，因为失败的步骤很早就会出现，而“执行性能确认”（8）既要等偏差，也要等自己的脚本。“审核需求可追溯性”（3）在运行确认之后开始，在性能确认执行结束1天后结束，随后是“编写验证总结报告”（4）和“验证报告已批准”。“放行系统投入使用”要等该批准和“就已批准规程培训用户”（3）。所有工期均为示例。
时间线只负责为工作排期。它不能让一个系统通过验证、合规或获批，也不能代替你的验证程序、质量部门的决定或你保存的记录。相邻的计划请看质量管理体系实施甘特图（体系周边）、软件发布甘特图（软件变更的放行方面）和变更控制流程（已验证系统的变更如何决定）。规划方法请看甘特图依赖关系指南。
本流程图涵盖的内容
本模板包含
- 四组：规划与风险、规格与构建、测试脚本与执行、报告与放行，共20项任务和四个里程碑：“验证计划已批准”、“执行完成”、“验证报告已批准”和“放行系统投入使用”。
- 提早开始的风险：“评估对患者和数据的风险”在“起草用户需求”开始2天后开始，“验证计划已批准”要等它和“编写验证计划”。
- 与构建同步编写的脚本：“编写安装确认脚本”、“编写运行确认脚本”和“编写性能确认脚本”在“配置系统”进行期间编写。
- 测试窗口内的偏差循环：“解决测试偏差”在“执行运行确认”开始3天后开始，“执行性能确认”要等它。
- 带重叠的收尾审核：“审核需求可追溯性”在“执行性能确认”结束1天后结束，“放行系统投入使用”要等“验证报告已批准”和“就已批准规程培训用户”。
何时使用本模板
- 你正在验证一个新系统或升级后的系统，需要在业务负责人、IT、质量和供应商之间商定日期。
- 你想看看进度有多大程度取决于提早编写脚本，以及一个很长的偏差会对放行日期造成什么影响。
- 上线日期已定，你想把图表得出的完成日期与你需要的日期比较。
- 你想要一个可重复使用的验证项目骨架，让每个系统团队按自己的程序调整。
逐项任务的计划
图表中的每项任务，含以工作日计的工期及其前置任务。依赖关系用步骤编号表示；SS 为开始到开始，FF 为完成到完成，+n 为以工作日计的延迟。
| # | 任务 | 分组 | 工作日 | 依赖于 |
|---|---|---|---|---|
| 1 | 编写验证计划 | 规划与风险 | 5 | |
| 2 | 起草用户需求 | 规划与风险 | 6 | |
| 3 | 评估对患者和数据的风险 | 规划与风险 | 4 | 2SS+2 |
| 4 | 验证计划已批准 | 规划与风险 | 里程碑 | 1, 3 |
| 5 | 编写功能规格 | 规格与构建 | 6 | 4 |
| 6 | 配置系统 | 规格与构建 | 10 | 5SS+3 |
| 7 | 起草操作规程 | 规格与构建 | 5 | 6SS+4 |
| 8 | 编写安装确认脚本 | 测试脚本与执行 | 3 | 5 |
| 9 | 编写运行确认脚本 | 测试脚本与执行 | 5 | 5 |
| 10 | 编写性能确认脚本 | 测试脚本与执行 | 5 | 3 |
| 11 | 执行安装确认 | 测试脚本与执行 | 3 | 6, 8 |
| 12 | 执行运行确认 | 测试脚本与执行 | 8 | 9, 11 |
| 13 | 解决测试偏差 | 测试脚本与执行 | 5 | 12SS+3 |
| 14 | 执行性能确认 | 测试脚本与执行 | 8 | 10, 13 |
| 15 | 执行完成 | 测试脚本与执行 | 里程碑 | 14 |
| 16 | 审核需求可追溯性 | 报告与放行 | 3 | 12, 14FF+1 |
| 17 | 编写验证总结报告 | 报告与放行 | 4 | 15, 16 |
| 18 | 验证报告已批准 | 报告与放行 | 里程碑 | 17 |
| 19 | 就已批准规程培训用户 | 报告与放行 | 3 | 7, 15 |
| 20 | 放行系统投入使用 | 报告与放行 | 里程碑 | 18, 19 |
运作方式
让计划和需求同时开始
让“编写验证计划”和“起草用户需求”保持为两项独立的起始任务，并把工期换成你自己的审批人实际所需的时间。
让风险从初稿开始
“评估对患者和数据的风险”与需求以2天延迟做开始到开始链接。如果评估人员需要先看到更多需求，就修改延迟。
让构建以计划为关口
“编写功能规格”要等“验证计划已批准”。如果你的程序允许设计更早开始，就移动这条链接，并添加你自己的任务，例如供应商评估或数据迁移。
在构建期间编写脚本
让三项脚本任务与“配置系统”并行，使执行开始时它们已经就绪。如果你的脚本需要配置好的系统才能编写，就把它们链接到系统上。
给偏差留出空间
“解决测试偏差”有5个工作日，在运行确认期间开始。如果可能需要复测，就加长它，并观察“执行性能确认”的完成日期如何变化。
添加负责人，分享并导出
在“人员”中填入负责人，把图表分享给IT、质量和业务负责人，需要副本时导出PDF或CSV存入项目文件。
常见问题
计算机系统验证需要多久？
这取决于系统、其风险和你的程序。模板以示例工期加起来共几个月的工作日。换成你自己的数字，再从图表读出完成日期。
图表会验证系统或证明合规吗？
不会。它只为工作排期。验证是你产生的证据和质量部门作出的决定。图表显示各部分计划何时进行。
为什么测试脚本与构建并行编写？
因为它们依赖规格和需求，而不是已完成的系统。提早编写可以让它们不再成为执行前的关键等待。如果你的脚本需要配置好的系统，请修改链接。
可以用于云系统或供应商托管的系统吗？
可以，但需要调整。把“配置系统”换成你自己的配置和供应商评估任务，保留计划、风险、执行和报告这几道关口。
变更后如何规划再验证？
复制图表，并缩短到变更所影响的任务。变更本身如何决定请看变更控制流程，计划中任务重叠的做法请看甘特图重叠任务指南。