建立可測試核實的需求

 

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

 

　　定義完整---Fully Defined

 

　　可被核實---Verifiable

 

　　目標明確---Objective

 

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

 

　　應該是基于以下的幾點考慮：

 

　　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）明確職責：

 

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

 

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

 

02、采用基于風險的決策法

 

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

 

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

 

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

 

03、用供應商的輸入

 

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

 

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

 

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

 

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

 

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

 

05、更加有效的測試

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

07、有效的管理變更

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

　　4）沒有及時將標準保持更新；

 

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

 

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

 

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

 

　　8）對于相似替換的變更原則不恰當?shù)膽�用�?/div>