建立可测试核实的需求

 

　　如何去写需求的心得，GAMP5中概述起来说有三个关键词：

 

　　定义完整---Fully Defined

 

　　可被核实---Verifiable

 

　　目标明确---Objective

 

01、用户需求不是拍脑袋定义出来的

 

　　应该是基于以下的几点考虑：

 

　　1）对产品工艺知识、业务流程、对产品质量属性的理解，任何自动化的系统都是为了支持工艺或者业务流程的。

 

　　从产品的角度上来讲，产品有哪些关键的质量属性，这些关键的质量属性会受到哪些关键工艺参数的影响，对这些工艺参数要求控制的范围是什么，都是对自动化系统设计的输入；从业务流程的角度去讲，GAMP5用了一个很好的词，challenge against，这不是指人员之间的互掐，而是指对每一条需求的表述都要精心推敲，看和业务流程的要求是否匹配；

 

　　2）明确职责：

 

　　在起草需求的过程中，各方面的职责是不同的，概述起来说，终端的用户部门负责人或者技术部门应该侧重于工艺知识的理解，并将工艺知识的理解转化成需求；供应商对于客户所提出的需求应该进行初步的把关，看自己的设备能否从技术上满足用户需求，或者结合自己产品的特点，给用户提一些改进的建议，而不能单纯为了卖出产品而进行忽悠；质量部门应该把握企业有哪些内部要求和外部法规要求，重点看验证的过程是否合规，而不是把质量部门变成所有领域的专家；

 

　　3）推敲每一条需求，做到需求的完整和准确，技术上可行，逻辑上合理，易于理解。

 

02、采用基于风险的决策法

 

　　基于风险的方法是GAMP5所一直强调的，尽管GAMP5中这段表述其实并不完全符合质量风险管理的理念：

 

　　基于风险：对于验证文件可以有不同的审核轮次及深度的要求，可以决定是否需要进行源代码审核，可以触发供应商评估的活动，可以决定测试内容的深度，可以决定系统变更如何有效管理，对备份和恢复流程如何界定，可以决定在授予系统权限前需要哪些必要的培训，对于周期性回顾的要求也基于风险有所不同。

 

　　基于风险的主要目的不是说定义哪些事情不做，而是应该侧重在哪些事情应该花更多的时间和精力，更有效的去做。

 

03、用供应商的输入

 

　　对于在哪些情况下可以采用供应商的文件，GAMP5给出了几点建议，需要对供应商进行如下的评估，包括对供应商的质量体系，技术能力以及供应商的一些项目的经验和能力评估。

 

　　GAMP5提出的一种观点其实还是比较新颖的，对于供应商的文件，企业的质量体系应该有一定的包容度，不要去过多纠结文件的格式而要关注内容本身。

 

04、引用企业现有的验证文件做参考

 

　　GAMP5中反复强调提可以尽可能多的采用供应商的验证文件支持验证活动，在如何让验证活动更有效这一章节，提出了企业本身的验证文件也可以供参考的说法，比如对于一个与老的系统类似的系统，可以借鉴之前的风险评估文件，用户需求标准文件，验证计划或测试计划，测试标准以及设计审核等，常见的例子包括实验室的设备，第二台同类的生产设备以及包装设备。

 

　　同时，对于一台新的设备而言，我们一直说风险评估应该基于已有的工艺知识，对已有的对工艺的理解也应在验证的过程中参考。

 

05、更加有效的测试

 

　　测试往往是验证生命周期中主要的活动之一，同时也比较耗时，所以GAMP5有如下的几点建议：

 

　　1）重新考虑合理使用之前的测试结果

 

　　FAT并不是法规要求的活动，但在供应商处进行的FAT过程中的一些测试，可以被确认活动所引用，前提是企业能够提前的将相关的要求沟通到供应商，同时有些非GMP法规要求的测试活动，比如安全相关的测试，财务相关的要求，如果法规要求的测试和这些测试重复，也可以考虑使用而不是单纯的重复。

 

　　2）测试的内容应该综合考虑

 

　　有很多不同的测试类型，比如Normal Case，Invalid Case，重复性测试，性能测试，负载测试，回归测试，结构测试等，这些不同的测试类型在后面会有详细的解读，用户需求对于企业而言，更多的是通过正确的安装以及系统接收测试实现的，其他的不同层次的测试要求应该取决于不同的风险，如果这些测试已经执行过，并且经过了企业相关的SME的审核，对于关键的与病人安全，产品质量以及数据完整性相关的项目，也经过了质量部门的批准，那么在测试的过程中也可以被引用。

 

　　3） 尽可能少采用纸质的测试证据

 

　　企业应该对相关的测试证明保存的方式进行明确的定义，很多企业要求提供验证过程中的截图，并且这些截图是以打印的形式存在做为证据，但实际上GAMP5的建议是仅在关键的步骤采用截图做为证明，同时如果系统有很好的审计追踪功能，以电子的形式记录下相关的系统操作，那么对于SME而言，审核这些电子的审计追踪也可以取代部分截图的操作。

 

　　4） 是否所有的测试都需要第二人复核

 

　　这其实是一个很值得考虑的问题，如果任何事情都需要两个人去做，那么无论是对企业而言，还是对系统的供应商而言都意味着成本的增加，是否需要第二人在测试时进行复核需要考虑的一个重要的因素在于测试者本身的能力，如果测试者本身有丰富的经验，那么就不一定在测试的过程中需要安排第二个人如影随形，但是如果在设备的操作过程中，需要一个人在控制间中控制设备，一个人在设备前进行操作，那么这种情况下第二人的参与又必不可少，同时对于测试结果的审核，可以采取离线的SME的审核流程或者更多的借助系统中的审计追踪审核的过程，而不是在测试的过程中安排两个人同时进行测试。

 

06、管理好系统移交的活动

 

　　系统的移交应该有预先定义的标准，尤其应该明确运维阶段的职责，同时对项目阶段的问题及偏离应该有必要的追溯，在系统移交的时候还应该考虑到系统移交对于业务的影响，以及是否有可能退回到之前的版本的系统，关于系统的文件、培训、以及不同部门之间的沟通，变更的影响也都应该在移交的时候进行前瞻性的考虑。

 

07、有效的管理变更

 

　　1）需要有书面的关于变更的描述以及变更带来的好处；

 

　　2）需要对现有的资源进行确认；

 

　　3）需要分析变更的影响，包括基础架构，人员培训，以及文件；

 

　　4）需要结合项目初始阶段的风险评估，识别出新的风险点，包括必要的回归测试；

 

　　5）从财务，合规以及技术的角度对变更进行评估；

 

　　6）对于变更的决策进行沟通及记录；

 

　　7）执行并确认变更，将变更相关的内容追溯到相应的测试；

 

　　8）及时关闭变更

 

　　常见的变更过程中容易犯的错误包括：

 

　　1）变更管理与变更的复杂程度不匹配，比如小的系统变更以及常规的基础架构变更管理过重；

 

　　2）变更管理过程中的步骤执行管理不恰当或者顺序不合适；

 

　　3）对于可避免的变更没能防止；

 

　　4）没有及时将标准保持更新；

 

　　5）没有综合采用现有的文件，包括风险分析，追溯矩阵等；

 

　　6）变更关闭时必要的跟踪项跟踪不力；

 

　　7）IT变更与业务变更采用独立的变更体系导致变更中部分活动重复；

 

　　8）对于相似替换的变更原则不恰当的应用；

 

　　9）对于供应商进行的变更没有很好的管理，导致验证生命周期文件和配置管理记录没有及时更新；

 

　　10）紧急变更管理不当；

 

08、有效的预测数据归档及迁移的需求

 

　　1） 对于相同数据架构的数据，如果要求有不同的保留时间，很难对数据有不同的保留时间，这就要求在设计数据结构的时候就要考虑数据的保留；

 

　　2）数据的格式如果采用自定义的格式则在进行数据迁移的时候会造成不必要的麻烦；

 

　　3）静态数据与动态数据的混合