精益用户需求的探讨

文/宋启国

众所周知，用户需求说明（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和精益验证找到切实可行的实操方法。