报表的验证需要考虑哪些？？

beiwei5du

报表（比如水晶报表）的验证需要考虑哪些？？问题先抛出来，希望有经验的老师能分享分享。

ztzhang

谢邀

对于任何计算机化系统的验证，首先都需要识别用户需求。像水晶报表这种，灵活性很大且可配置性很高的软件，更要充分考虑用户需求。以SAP Crystal Reports为例，首先是系统如何部署？公司内部服务器和局域网模式，还是公有云软件服务SaaS？这两种情况下，需要考虑的风险点就不一样。如果是第一种情况，公司IT应充分理解软件的运行和维护需求，必要情况下供应商应提供设计标准或类似文件阐述软件核心功能的实现原理和方法。如果是第二种情况，公司与供应商之间应明确职责（具备质量协议）和服务级别（服务级别协议），并由公司组成评审小组对供应商进行评估。系统的验证过程，与其它软件没有很大区别，由风险评估，确认测试（3Q/4Q）方案报告，最终放行报告确认URS得到满足（可追溯矩阵）几部分组成。验证之后，用于维护已验证的状态，特别需要配置管理这个程序。因为不同于常见COTS，报表系统的配置项特别多，而且可能进行多次的更改。配置管理SOP的作用是，1-固化已验证状态（GAMP 5中所谓的“配置识别”），2-配置控制（怎么更改配置，需要考虑的因素以及怎么记录，GAMP5中的配置控制和配置状态台账），3-配置确认（怎么确认更改后的配置的效果，GAMP5中的配置评估）。配置SOP可以与针对计算机化系统的变更控制程序（如果有的话）结合考虑。

关于Trackwise,我们公司19年会有这个系统在国内的验证项目，到时候我针对这个系统的验证写一个培训文件。像Trackwise这样的EQMS，作为制药公司自动化进程中优先上线的系统，我们还是比较推荐的。因为它的可配置程度高，但是应用范围可控（比如可以先从质量意识较高的QA部门开始实施），且模块化，对于没有大型系统使用经验的公司来说，成功率比较高。
另外，就计算机化系统验证这个主题，其中的风险评估针对的是系统在公司的使用流程。所以不同公司使用Trackwise系统，风险评估并不通用。当然，Trackwise用于质量流程的管理，偏差，变更，OOS，CAPA，投诉等等，公司之间的差别并不会很大，主要的风险点还是可以借鉴的，比如偏差分类的判定，根原因的分类，影响评估等。就系统本身而言，非常灵活，是方是圆取决于用户需求。

beiwei5du

@ztzhang 老师能否针对于报表（比如水晶报表））验证说一说呢？？？
还有关于相关的trackwise的风险评估讲一讲呢？？

山顶洞人

坐等答案，

来自安卓APP客户端