建立可測試核實的需求

 

　　如何去寫需求的心得，GAMP5中概述起來說有三個關(guān)鍵詞：

 

　　定義完整---Fully Defined

 

　　可被核實---Verifiable

 

　　目標(biāo)明確---Objective

 

01、用戶需求不是拍腦袋定義出來的

 

　　應(yīng)該是基于以下的幾點考慮：

 

　　1）對產(chǎn)品工藝知識、業(yè)務(wù)流程、對產(chǎn)品質(zhì)量屬性的理解，任何自動化的系統(tǒng)都是為了支持工藝或者業(yè)務(wù)流程的。

 

　　從產(chǎn)品的角度上來講，產(chǎn)品有哪些關(guān)鍵的質(zhì)量屬性，這些關(guān)鍵的質(zhì)量屬性會受到哪些關(guān)鍵工藝參數(shù)的影響，對這些工藝參數(shù)要求控制的范圍是什么，都是對自動化系統(tǒng)設(shè)計的輸入；從業(yè)務(wù)流程的角度去講，GAMP5用了一個很好的詞，challenge against，這不是指人員之間的互掐，而是指對每一條需求的表述都要精心推敲，看和業(yè)務(wù)流程的要求是否匹配；

 

　　2）明確職責(zé)：

 

　　在起草需求的過程中，各方面的職責(zé)是不同的，概述起來說，終端的用戶部門負(fù)責(zé)人或者技術(shù)部門應(yīng)該側(cè)重于工藝知識的理解，并將工藝知識的理解轉(zhuǎn)化成需求；供應(yīng)商對于客戶所提出的需求應(yīng)該進行初步的把關(guān)，看自己的設(shè)備能否從技術(shù)上滿足用戶需求，或者結(jié)合自己產(chǎn)品的特點，給用戶提一些改進的建議，而不能單純?yōu)榱速u出產(chǎn)品而進行忽悠；質(zhì)量部門應(yīng)該把握企業(yè)有哪些內(nèi)部要求和外部法規(guī)要求，重點看驗證的過程是否合規(guī)，而不是把質(zhì)量部門變成所有領(lǐng)域的專家；

 

　　3）推敲每一條需求，做到需求的完整和準(zhǔn)確，技術(shù)上可行，邏輯上合理，易于理解。

 

02、采用基于風(fēng)險的決策法

 

　　基于風(fēng)險的方法是GAMP5所一直強調(diào)的，盡管GAMP5中這段表述其實并不完全符合質(zhì)量風(fēng)險管理的理念：

 

　　基于風(fēng)險：對于驗證文件可以有不同的審核輪次及深度的要求，可以決定是否需要進行源代碼審核，可以觸發(fā)供應(yīng)商評估的活動，可以決定測試內(nèi)容的深度，可以決定系統(tǒng)變更如何有效管理，對備份和恢復(fù)流程如何界定，可以決定在授予系統(tǒng)權(quán)限前需要哪些必要的培訓(xùn)，對于周期性回顧的要求也基于風(fēng)險有所不同。

 

　　基于風(fēng)險的主要目的不是說定義哪些事情不做，而是應(yīng)該側(cè)重在哪些事情應(yīng)該花更多的時間和精力，更有效的去做。

 

03、用供應(yīng)商的輸入

 

　　對于在哪些情況下可以采用供應(yīng)商的文件，GAMP5給出了幾點建議，需要對供應(yīng)商進行如下的評估，包括對供應(yīng)商的質(zhì)量體系，技術(shù)能力以及供應(yīng)商的一些項目的經(jīng)驗和能力評估。

 

　　GAMP5提出的一種觀點其實還是比較新穎的，對于供應(yīng)商的文件，企業(yè)的質(zhì)量體系應(yīng)該有一定的包容度，不要去過多糾結(jié)文件的格式而要關(guān)注內(nèi)容本身。

 

04、引用企業(yè)現(xiàn)有的驗證文件做參考

 

　　GAMP5中反復(fù)強調(diào)提可以盡可能多的采用供應(yīng)商的驗證文件支持驗證活動，在如何讓驗證活動更有效這一章節(jié)，提出了企業(yè)本身的驗證文件也可以供參考的說法，比如對于一個與老的系統(tǒng)類似的系統(tǒng)，可以借鑒之前的風(fēng)險評估文件，用戶需求標(biāo)準(zhǔn)文件，驗證計劃或測試計劃，測試標(biāo)準(zhǔn)以及設(shè)計審核等，常見的例子包括實驗室的設(shè)備，第二臺同類的生產(chǎn)設(shè)備以及包裝設(shè)備。

 

　　同時，對于一臺新的設(shè)備而言，我們一直說風(fēng)險評估應(yīng)該基于已有的工藝知識，對已有的對工藝的理解也應(yīng)在驗證的過程中參考。

 

05、更加有效的測試

 

　　測試往往是驗證生命周期中主要的活動之一，同時也比較耗時，所以GAMP5有如下的幾點建議：

 

　　1）重新考慮合理使用之前的測試結(jié)果

 

　　FAT并不是法規(guī)要求的活動，但在供應(yīng)商處進行的FAT過程中的一些測試，可以被確認(rèn)活動所引用，前提是企業(yè)能夠提前的將相關(guān)的要求溝通到供應(yīng)商，同時有些非GMP法規(guī)要求的測試活動，比如安全相關(guān)的測試，財務(wù)相關(guān)的要求，如果法規(guī)要求的測試和這些測試重復(fù)，也可以考慮使用而不是單純的重復(fù)。

 

　　2）測試的內(nèi)容應(yīng)該綜合考慮

 

　　有很多不同的測試類型，比如Normal Case，Invalid Case，重復(fù)性測試，性能測試，負(fù)載測試，回歸測試，結(jié)構(gòu)測試等，這些不同的測試類型在后面會有詳細(xì)的解讀，用戶需求對于企業(yè)而言，更多的是通過正確的安裝以及系統(tǒng)接收測試實現(xiàn)的，其他的不同層次的測試要求應(yīng)該取決于不同的風(fēng)險，如果這些測試已經(jīng)執(zhí)行過，并且經(jīng)過了企業(yè)相關(guān)的SME的審核，對于關(guān)鍵的與病人安全，產(chǎn)品質(zhì)量以及數(shù)據(jù)完整性相關(guān)的項目，也經(jīng)過了質(zhì)量部門的批準(zhǔn)，那么在測試的過程中也可以被引用。

 

　　3） 盡可能少采用紙質(zhì)的測試證據(jù)

 

　　企業(yè)應(yīng)該對相關(guān)的測試證明保存的方式進行明確的定義，很多企業(yè)要求提供驗證過程中的截圖，并且這些截圖是以打印的形式存在做為證據(jù)，但實際上GAMP5的建議是僅在關(guān)鍵的步驟采用截圖做為證明，同時如果系統(tǒng)有很好的審計追蹤功能，以電子的形式記錄下相關(guān)的系統(tǒng)操作，那么對于SME而言，審核這些電子的審計追蹤也可以取代部分截圖的操作。

 

　　4） 是否所有的測試都需要第二人復(fù)核

 

　　這其實是一個很值得考慮的問題，如果任何事情都需要兩個人去做，那么無論是對企業(yè)而言，還是對系統(tǒng)的供應(yīng)商而言都意味著成本的增加，是否需要第二人在測試時進行復(fù)核需要考慮的一個重要的因素在于測試者本身的能力，如果測試者本身有豐富的經(jīng)驗，那么就不一定在測試的過程中需要安排第二個人如影隨形，但是如果在設(shè)備的操作過程中，需要一個人在控制間中控制設(shè)備，一個人在設(shè)備前進行操作，那么這種情況下第二人的參與又必不可少，同時對于測試結(jié)果的審核，可以采取離線的SME的審核流程或者更多的借助系統(tǒng)中的審計追蹤審核的過程，而不是在測試的過程中安排兩個人同時進行測試。

 

06、管理好系統(tǒng)移交的活動

 

　　系統(tǒng)的移交應(yīng)該有預(yù)先定義的標(biāo)準(zhǔn)，尤其應(yīng)該明確運維階段的職責(zé)，同時對項目階段的問題及偏離應(yīng)該有必要的追溯，在系統(tǒng)移交的時候還應(yīng)該考慮到系統(tǒng)移交對于業(yè)務(wù)的影響，以及是否有可能退回到之前的版本的系統(tǒng)，關(guān)于系統(tǒng)的文件、培訓(xùn)、以及不同部門之間的溝通，變更的影響也都應(yīng)該在移交的時候進行前瞻性的考慮。

 

07、有效的管理變更

 

　　1）需要有書面的關(guān)于變更的描述以及變更帶來的好處；

 

　　2）需要對現(xiàn)有的資源進行確認(rèn)；

 

　　3）需要分析變更的影響，包括基礎(chǔ)架構(gòu)，人員培訓(xùn)，以及文件；

 

　　4）需要結(jié)合項目初始階段的風(fēng)險評估，識別出新的風(fēng)險點，包括必要的回歸測試；

 

　　5）從財務(wù)，合規(guī)以及技術(shù)的角度對變更進行評估；

 

　　6）對于變更的決策進行溝通及記錄；

 

　　7）執(zhí)行并確認(rèn)變更，將變更相關(guān)的內(nèi)容追溯到相應(yīng)的測試；

 

　　8）及時關(guān)閉變更

 

　　常見的變更過程中容易犯的錯誤包括：

 

　　1）變更管理與變更的復(fù)雜程度不匹配，比如小的系統(tǒng)變更以及常規(guī)的基礎(chǔ)架構(gòu)變更管理過重；

 

　　2）變更管理過程中的步驟執(zhí)行管理不恰當(dāng)或者順序不合適；

 

　　3）對于可避免的變更沒能防止；

 

　　4）沒有及時將標(biāo)準(zhǔn)保持更新；

 

　　5）沒有綜合采用現(xiàn)有的文件，包括風(fēng)險分析，追溯矩陣等；

 

　　6）變更關(guān)閉時必要的跟蹤項跟蹤不力；

 

　　7）IT變更與業(yè)務(wù)變更采用獨立的變更體系導(dǎo)致變更中部分活動重復(fù)；

 

　　8）對于相似替換的變更原則不恰當(dāng)?shù)膽?yīng)用；

 

　　9）對于供應(yīng)商進行的變更沒有很好的管理，導(dǎo)致驗證生命周期文件和配置管理記錄沒有及時更新；

 

　　10）緊急變更管理不當(dāng)；

 

08、有效的預(yù)測數(shù)據(jù)歸檔及遷移的需求

 

　　1） 對于相同數(shù)據(jù)架構(gòu)的數(shù)據(jù)，如果要求有不同的保留時間，很難對數(shù)據(jù)有不同的保留時間，這就要求在設(shè)計數(shù)據(jù)結(jié)構(gòu)的時候就要考慮數(shù)據(jù)的保留；

 

　　2）數(shù)據(jù)的格式如果采用自定義的格式則在進行數(shù)據(jù)遷移的時候會造成不必要的麻煩；

 

　　3）靜態(tài)數(shù)據(jù)與動態(tài)數(shù)據(jù)的混合