CSV形式主义陷阱：测试用例、风险评估、变更控制与供应商验证包四类常见问题

在医药计算机化系统合规领域，CSV本应是保障数据完整性和系统正常合规运维的核心防线，但在太多企业里，它却慢慢变成了“文档工程”——验证团队忙于制造厚厚的文件，却离实际风险控制越来越远。

今天，我们就来聊聊CSV验证中最常见的4个“形式主义”陷阱。这些坑，我陪不少药企趟过，有的及时爬出来了，有的却深陷其中，直到收到483观察项才痛定思痛。

放心，我不会给你念法规条款（那些东西你肯定比我熟）。咱们就从真实案例出发，看看这些陷阱到底长什么样，以及怎么才能让你的CSV验证回归“风险控制”的本质。

陷阱一：测试用例“纸上谈兵”

真实案例：完美测试用例 vs 实际业务漏洞

有一次SAP项目，甲方项目经理被我和甲方CSV搞的头疼，就反问我们。你们要求做这么多测试，会保证上线后没有bug吗？

我当时的回答是不能，因为引起bug的原因是由数据、功能、操作、配置、流程等一系列因素决定的，我们只能确保功能、配置、流程这些被测试到。但是数据有问题，导致系统流程走不下去。或者用户一番神操作导致系统进入死循环，这些我们是无法保障的。

但是说实话，我也知道这个我们只是辩解。因为我们测试的时候只测功能和流程，无法把所有的业务场景都测试到，只是从逻辑上保障了这个流程的没有问题。但是SAP的MIGO对应那么多物料类型，如果使用穷举法测试的话，将是一个很大的工作量。并且CSV的核心是识别风险，降低风险到可接受程度。风险不会消失，只会降低和转移。

很多人会问，你振振有词的看起来说的很有道理。

那为什么说这是陷阱？

CSV验证的核心目的，是确保系统在其真实业务环境中能够持续合规运行。但“纸上谈兵”式的测试设计，往往只验证了“系统能做什么”，而忽略了“用户实际怎么用”。

GAMP 5第二版特别强调：“测试策略应基于风险评估结果，聚焦于对患者安全、产品质量和数据完整性最关键的功能。”

但现实中的偏差常常很微妙：

1.测试环境“太干净”：使用标准测试数据，避开了实际业务中的复杂场景（如多批次并发、异常数据格式）。本质是没有根据风险评估的结果做一些挑战测试

2.权限设置“太理想”：PQ所有测试都用管理员账号执行，忽略了不同角色用户的真实权限限制。尤其是管理型系统，对于权限的设置是由多个维度决定的（功能权限、数据权限、流程权限）

3.业务流程“太简化”：只验证“主干流程”，不覆盖“分支场景”（如紧急变更、数据复查、交接班）

陷阱二：风险评估“闭门造车”——变成验证顾问一个人的工作

曾经有个制药集团推行“标准化CSV流程”，要求所有计算机化系统使用同一套风险评估模板。乙方验证团队如获至宝，效率大大提高：新上一个ERP？把上次给LIMS做的风险评估复制过来，改改系统名称、部门名称、把对应的功能说明加上，无需业务部门参与，闭门造车，两天就能“完成”。

审核时甲方QA指着ERP系统的MM模块问：“这个模块处理直采供应商资质数据，属于GxP相关，为什么风险评估里没有任何关于供应商的控制措施？”

验证负责人翻开那份“标准化”风险评估报告，确实没有——因为他根本不懂业务，在风险评估的时候就拍脑袋定义了其为非GXP。

为什么这是陷阱？

风险评估是CSV验证的导航地图，它决定了资源应该投向哪里。模板化的风险评估，就像拿着北京地图在上海找路——路名可能差不多，但你要去的地方根本不在图上。

ICH Q9（质量风险管理）明确指出：“风险评估应是系统性的、基于科学知识和最终与患者保护相关联的。”

这种参与度低的评估往往会有两个结果，验证顾问凭着自己的风险接受意识忽略了很多风险，或者加强了很多风险。而和实际的业务部门的风险接受程度不一致。例如一个只做过原料药企业的CSV顾问，接了一个做医疗器械行业的项目。他会觉得法规的要求都是一样，做CSV没差别。但是从流程型转到离散型企业做项目，他们对于风险的关注点和可接受程度是不一样的。这样脱离业务做出来的风险评估势必就是一厢情愿的结果。

陷阱三：变更控制“断档”

这个例子就是昨晚刚发生的。某药企的系统，我们写CS的时候是三级签名。做第一套紫外的时候也是三级签名。而做后续两套的时候发现在没有变更的前提下就改为二级签名了。

然后今天早上我们提出了需要走一个变更，才发现他们根本没有内部沟通好，就是一个人的个人想法。

这就是变更控制和权限控制没有管理好下系统合规管理失控的最真实的表象。

陷阱四：过度依赖供应商验证包的“信任陷阱”

某企业采购了一套专业的MES（制造执行系统），供应商来自知名厂商。

我们审计的时候，甲方验证人员推来一车装订精美且崭新的验证文档。

结果我们审核的时候发现了一个问题：系统的审计追踪功能，虽然“开启”了，但只记录“成功操作”，对“失败尝试”（如密码错误、越权访问尝试）完全不记录。并且这种在测试中只做自己有的功能，而不做法规要求的功能在验证文件中屡屡发生。

为什么这是陷阱？

供应商验证包是有价值的，但它永远不能替代基于自身业务需求的风险评估和测试。过度依赖供应商文档，就像请别人替你体检——报告可能很漂亮，但真正威胁你健康的隐患，只有你自己最清楚。

我经常说，CSV出警告信的目前我只看到一例，就是北方某企业直接用了IOQ当做验证文件，没有风险评估，没有PQ。就签字上线使用了。

WHO TRS 996（计算机化系统验证指南）提醒：“企业应对供应商提供的验证文档进行严格审核，确保其适用于本组织的业务流程和风险特征。”

解决方案：实施“供应商验证包+定制验证”双轨策略

第一步：供应商验证包的“去水分”审核 - 逐项核对：供应商的测试用例是否覆盖了你识别出的所有高风险点？ - 环境匹配度评估：供应商测试环境（数据库版本、操作系统、网络配置）与你实际环境是否一致？ - 假设条件审查：供应商文档中是否有“假设用户会正确操作”这类隐藏假设？

第二步：定制验证补充 针对高风险或环境敏感的功能，必须增加企业自身的验证活动。

最后，说几句务虚但是有用的话

CSV验证的真正价值，从来不在文档的厚度里，而在风险控制的深度中。

当你下次面对又一份CSV文档时，不妨问自己：“我是在制造文件，还是在建立防线？”

答案的不同，可能决定了你收到的是客户持续性的给你项目，还是客户收到警告信以后对你的投诉。