電腦化系統驗證甘特圖範本：附 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 日完成，而「放行系統使用」要等「驗證報告已批准」和「培訓用戶使用已批准程序」。
何時使用本範本
- 你正在驗證新系統或升級後的系統，需要與業務負責人、資訊科技、品質部門和供應商議定日期。
- 你想知道日程有多大程度取決於及早撰寫腳本，以及一項長時間的偏差會令放行日期移動多少。
- 上線日期已經訂下，你想把圖表的完成日期與所需日期比較。
- 你想要一個可重複使用的驗證項目骨架，讓每個系統團隊按自己的程序調整。
逐項任務嘅計劃
圖表入面每項任務，連同以工作日計嘅工期同佢哋等緊嘅前置任務。依賴用步驟編號表示；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 個工作日，並在運行確認期間開始。如果可能需要重測，就加長它，並留意「執行性能確認」的完成日期如何移動。
加入負責人、分享及匯出
把負責人加入「人員」，與資訊科技、品質部門和業務負責人分享圖表，需要項目檔案副本時匯出 PDF 或 CSV。
常見問題
電腦化系統驗證需要多長時間？
視乎系統、風險和你的程序。範本合共是數個月工作日的計劃，工期只是示例。請換成你自己的工期，並從圖表讀取完成日期。
圖表會驗證系統或證明合規嗎？
不會。它只為工作排程。驗證是你產出的證據和品質部門的決定。圖表顯示各部分預計何時進行。
為甚麼測試腳本與建置並行撰寫？
因為腳本取決於規格和需求，而不是已完成的系統。及早撰寫可以令它們脫離執行前的關鍵等候。如果你的腳本需要已配置的系統，請更改連結。
可以用於雲端或供應商託管的系統嗎？
可以，但要修改。把「配置系統」換成你自己的配置和供應商評估工作，並保留計劃、風險、執行和報告的關卡。
變更後如何規劃再驗證？
複製圖表，並縮減至受變更影響的工作。變更本身如何決定，請看變更控制流程範本；計劃中的重疊工作請看重疊工作指南。