精益用戶需求的探討

文/宋啟國

眾所周知，用戶需求說明（URS）是系統驗證生命周期的起點和參考點 [1，2]，一個高質量、精益的URS 對于后續驗證工作非常有價值——但是，行業當前的URS 驗證依然存在很多問題，造成了不必要的浪費和麻煩。已有很多文章對此進行了論述，但還沒有專門的文章對URS 的“度”（條目數量、范圍、深度）如何把控進行探討。本文從五角星模型、前提條件、“以終為始”套路、SMART-UN 原則、項目思維幾個部分出發進行探討，試圖為解決該問題提供一個有參考價值的實用方法。

近年來，生物制品的行業的發展帶動了大量新建生物制藥工廠項目的需求，各地醫藥產業園如雨后春筍般地涌現。醫藥是一個高監管行業，新建廠房設施設備等系統均需經過驗證合格后才可放行用于生物藥品的生產，大量的系統驗證工作隨之而來。此時，編制一個高質量、精益的URS，盡量減少其中的紕繆就顯得尤為重要。實踐中，因為URS 本身的問題給驗證工作造成了很多不必要的浪費和麻煩的情形層出不窮，典型問題可列舉如下[3]：

?不重視URS，認為URS 就是套模板，沒有任何難度；

?直接采用供應商提供的URS而不做任何修訂；

?不考慮需求是否能夠被驗證、后續要付出多大成本、產生多大價值，認為無論是否合理，URS 的條款越多越好；

?拼湊需求，將各種標準原文搬進URS；

?將符合某個法規的寬泛要求寫入具體條款，如“系統符合21 CFR part 11”；

? 條款參考標準不合理，如生物安全柜行業標準為0.25～0.50 m/s，但卻按照GMP指南的A 級指導值0.36～0.54 m/s編寫需求，導致驗收時產生不必要的爭論；

?條款重復、冗余，同樣的需求內容以不同的文字形式反復在不同條款中出現；

?非必要拔高標準，或引用錯誤標準；

?未按照系統的特點考慮URS的詳細度，如為一個標準的簡單設備設置了上百條需求……

諸如此類的問題不勝枚舉，嚴重影響了驗證工作的價值。有時為了去解決某些不合理的需求甚至增加了很多不必要的驗證成本，與當前行業降本增效、追求精益的訴求相違背。截至目前業內對于URS 的度如何把控（條目數量、范圍、深度），即如何做好一個精益URS，還沒有專門的文章或方法進行探討。

筆者認為此問題表現突出，固寫本文進行探討，本文共分為五角星模型、前提條件、以終為始套路、SMART-UN 原則、項目思維幾個部分。希望通過本文的分享能給同行提供一些有價值的參考。

1.五角星模型

做任何一件事的底層邏輯是要建立框架，即建立一個結構化的模型。如此便能擁有宏觀視野，用整體的眼光看待問題，而非以偏概全，URS 也是如此。遺憾的是法規和指南并未提供現成的模型供業內參考使用。筆者結合自身經驗總結形成了一種URS 五角星模型，實踐效果不錯，具體內容如圖所示（見P64）。

對于系統需求來說，主要的期望就是系統功能可用（合規衛生）、性能好用、安全友好、穩定持久、過程和結果信息可追溯；為便于交流，筆者在圖1 中將這五個方面用五角星外形展示，命名為URS 五角星模型。各公司URS的SOP（標準作業程序）或模板無論其格式如何規定，其需求的分類或多或少都有以上模型的影子。此模型可以幫助讀者掌握整體思考方式，確保URS 需求涵蓋的內容不會出現明顯缺失。

2.前提條件

做任何事情都有前提條件，URS 也不例外。寫好URS 不應該寄希望于起草人一個人身上。起草人應該具備一定的驗證理念和系統的基礎知識概念，但更重要的是URS 應該是溝通協調的結果呈現，是團隊智慧的結晶。如果一個URS 在起草前用戶、工程、自控、IT、質量等團隊中存在主題專家缺失的情況，團隊內部、團隊和供應商之間未進行深入溝通，相關的需求、系統的能力極限未被挖掘出來，就不具備起草一個精益URS 的前提。實踐中套模板、抄標準、東拼西湊，為了完成URS 起草任務閉門造車的現象隨處可見，參考點的呈現不好自然就不會有好的驗證生命周期的呈現。我們應該轉變思維，把URS 看作團隊同頻的一個工具，工作重心放在前期資料收集和溝通交流（這點往往會被忽視），URS 文件只不過是同頻后溝通結果自然而然的文字呈現。沒有這種工作重心的轉變，沒有踏實深入的前期溝通，沒有真正有知識的各相關專業的人員的參與，精益URS 無疑是天方夜譚。此時，團隊通常會關注但不限于以下方面：

?質量：質量要求；

?規范：目標市場和遵循的法規；

?供應商：合作經驗；行業口碑，包括年限、行業地位、規模等；技術水平；價格；項目關注度和響應水平；銷售；交貨期：進口或國產；實施和驗證水平；售后服務；

?系統本身：標準；通用功能；定制；復雜性；新穎性；系統和軟件邊界以及同其他系統之間的關系；

?采購策略：質量定位；項目周期；價格預算；最終用戶；

?工藝和產品：工藝和產品要求，包括CQA（關鍵質量屬性）、CPP（關鍵工藝參數）、KPP（重要工藝參數）等；復雜性；技術能力；經驗水平；偏好；自動化和信息化水平；

?EHS（環境、健康、安全）方面；

?未來可能的初級和擴展。

3.以終為始套路

驗證活動中，URS 中的需求條目最終都需要被一個個的測試項目證明。既然如此，可以使用逆向工程的思維，在起草URS時把五角星模型中的每個角最終會形成的測試項目先寫出來，然后再在此基礎上擴展具體需求條目內容。分別用金字塔原理的MECE(相互獨立且窮盡)原則對測試項和測試項下的需求條目這兩層進行復核，確認滿足此原則，即不漏項。

使用MECE 原則核對需求條目內容時還應把握的一個原則是寧缺毋濫，即不要添加一些不能增加明顯質量價值的需求條目，若條目不滿足此原則就應該毫不猶豫地刪除。要清楚認識到每一個條目都需要后續進行大量的驗證活動來證明此需求被滿足，會消耗金錢、時間、人力及物力。如果增加某條需求并沒有明顯的質量價值的增值，那么就意味著它是多余的需求，應刪除。如仍要保留，不僅僅會帶來無意義的浪費，還有可能會產生更多的問題，進而帶來新的合規風險。

URS 五角星模型

另外，還有一種結構方式是以系統的工藝步驟作為主線起草URS，此時工藝步驟就是URS 條款多寡的參照點，可以使用五角星模型和工藝步驟進行交叉驗證確認。

4.SMART-UN 原則

當以上兩個要點均具備時，就到了URS 起草的階段了。如何更好地呈現前期工作成果，比較考驗起草人語言文字的組織能力。URS 行文應簡潔明了，言之有物。應遵守SMART-UN 原則，具體表述如下：

?“S”代表“Specific”，具體的：用戶需求的表述應該是明確的和詳細的。語言應言簡意賅，需求明確，避免拖沓和模棱兩可的描述，建議采取“xxx 應xxx”的句式。所要達到的標準應為量化或具體化的描述方式，盡量避免使用不易量化的或抽象的標準，如應避免使用“xxx 應足夠”“xxx 應符合要求”“xxx 應美觀大方”等描述。前后行文應一致、條理及邏輯清晰，避免沖突和不必要的重復；

?“M”代表“Measurable”，可測試的、可衡量的：用戶需求應是能夠被測試或衡量的，應確保測試或衡量的方法是可獲得的與可實現的；

?“A”代表“Achievable”，可實現的：用戶需求應是能夠實現的。制定用戶需求前，應對需求與供方的反饋做出評估和權衡，確保所有的需求是必要的且可實現的，避免提出不是出于需求本身的、不切實際的需求；

?“R”代表“Realistic”，現實的：用戶需求應是現實而非想象出來的，所依據的指標應是科學合理并令人信服的；

?“T”代表“Traceable”，可追溯的：用戶需求應是可追溯的；

?“U”代表“Unique”，唯一的：即需求是不重復的，具有唯一性；

?“N”代表“Necessary”，必需的：即需求條款是必需的，不是為了湊篇幅加上來的。

5.項目思維

系統驗證生命周期過程實際上是一個項目過程，所以它必然符合項目的一些特點，如一次性、漸進明細，即一開始不清楚，但越做越清楚，所以指望一開始就能寫一個清清楚楚、明明白白的URS 其實是不理智的。那么對于前期不太確定的內容該如何處置呢？以下原則可供參考：

?強關系原則：測試項只追溯最能體現因果關系的需求，抓關鍵，不求巨細無遺；

?緩沖墊原則：初始起草時不能寫得具體的需求可以先宏觀描寫，在設計資料或測試案例里進一步細化，不單獨去看URS 一個文件的詳細度，不強求一步到位；

?可追溯原則：用RTM（需求追溯矩陣）工具來進行管理和追溯，項目是一次性的，需求是漸近明細的，URS 可以通過RTM 來追溯確保需求都被滿足。反過來如果后續發現某個點很重要但沒有提需求，可以以升版URS 的方式逐步細化。

6.總結

雖然URS 是系統驗證生命周期的參考點和起點，但它不是唯一的產出物，不應孤立地對待URS，評估系統驗證活動時應把系統驗證生命周期內的所有產出物作為一個整體來看待。驗證本身是有成本的，多余的需求無用且不能產生明顯額外的質量價值，是一種浪費；為了實現此無價值需求的閉環甚至還會產生新的合規風險，得不償失。

驗證應該培養一種以“瘦”為美、以精簡為美的風氣，這對個人、對行業、對社會都是一種有價值的貢獻。希望本文分享的內容能夠幫助同行為精益URS和精益驗證找到切實可行的實操方法。