计算机系统验证 第一篇（持续更新中...........）

tooseven

时间过的飞快，一晃就过了6年（截至到上一次回复本贴的问题），周末跑到论坛来检索资料，看到了楼上蒲友们的回复，鼓励和期待，感谢你们的鼓励。在这6年间，我经历了大外资、大私企、初创公司。这6年虽然很多时候不直接负责计算机化系统验证，但一直关注着这个领域。看着那些同事或下属在忙活CSV的时候的从初始接触时面对未知的纠结或者表现出的无知无畏的精神，到面对我的挑战时的异常焦虑和解惑后的豁然开朗，然后再面对现实的无奈和妥协。我也有一些莫名的焦虑。因此觉得有些事情还是跟大家解释一下，如果对大家又帮助，或许对这个行业有点用处。我知道这些过程都是每一个做CSV的人的必经过程，至于是否能修成正果，确实需要机遇和个人努力。因此也建议刚入行的同仁，如果要从事CSV最好去大企业学习各个岗位的业务知识，然后再从事验证和CSV的工作，经历过若干项目后再去看GAMP5方能对指南中的文字有比较深刻的理解，没有一个好的业务基础（一万小时定律），指南中的文字也仅仅是一堆文字而已。我为什么这么建议，是因为计算机化系统本身就是一个系统化的工具不是制药公司的主营业务。但这个工具很多时候是要结合制药公司的各种具体业务流程去进行设计、开发、配置和管理，如果做CSV却不懂公司的业务流程以及业务流程配套的法规要求/技术要求和公司要求，那么做CSV更多的只能依赖供应商或“别人说”。
下面就结合业务流程去分享一下我个人对SDLC的理解。一个新的软件是如何依据业务流程来开发的。也就是SDLC的整个过程是怎样的。
要开发一个软件，首先要想清楚这个软件的目的是什么。也就是 bingo101 提到的GAMP5中说的“公司主要考虑将哪些过程进行自动化，并且综合成本、利益等考虑一些初步的需求及可能的解决方案“。我对这句话的解读就是：首先公司要描述清楚我要用这个软件来做什么，期望达到什么结果。比如公司期望引入LIMS系统来解决实验室的资源计划管理、从安排检验活动到出局报告和后期数据分析统计的管理，从而减少线下人工管理的人力资源成本、时间计划成本和信息错误导致的返工成本。实验室管理的核心要求等同于一个制造型企业的管理要求。它的管理要素涉及了人机料法环。直白一点说一个制造企业应该管理的要素在实验室都有充分的体现。所以LIMS实际是一个小型的ERP+MES的结合体。首先实验室有物料管理，物料管理通常的理解就是库房和现场的物料管理，我说它是库房是用类比的方法帮助大家理解，实验室的库房分为试剂的库存管理、样品的管理、留样样品的管理、稳定性样品的管理，这个试剂和样品都保存在一个一个小型库房中，并且需要根据业务需求（企业产品生产检验计划、留样和稳定性考察计划）息息相关，其次实验室有各种各样的管理和操作人员，有根据计划管理库存的（比如万一要进行检验发现试剂不够了怎么办？），要管理好这些库存就要管理检验计划。实验室要有人员的管理，除了资质还要根据检验任务（物料、产品、留样、稳定性）配备足够的人员才能支持企业的业务顺利进行。实验室要有设备仪器的管理，仪器故障或者未验证也不能使用，如果要采用LIMS管理，这些管理流程也要事先明确，至于方法这一块，在LIMS中也需要对检验方法进行管理，同时还有一系列的实验室本身的管理方法也就是我们通常说的SOP/质量标准等也要体现在LIMS系统中，以方便指导操作和结果判定，环境这一块LIMS通常不进行管理。
所有这些人、机、料、法方面的管理一定有一套合理的有逻辑的流程来支持，这些流程就是我们说的业务流程。在使用LIMS系统来解决企业的问题之前，第一步就是梳理这些流程，包括当前的做法和管理要求是什么，未来期望LIMS怎么做，怎么管。
抛开商业合同业务谈判的流程不谈，要开发一个LIMS系统，供应商的第一个关键人物也就是产品经理，Business Analyst就要出场了。他的职责就是要梳理业主的业务流程，然后规划设计未来LIMS运行管理的业务流程并跟业主达成一致，这个阶段包含了需求分析，流程调研，规划设计，相当于工程项目的概念设计和基础设计阶段。这需要供应商的产品经理、了解实验室当前流程和法规要求的业主人员或专家顾问一起来完成这个业务流程的梳理和设计。如果大家都是很专业的人员，这个时间会很快并且未来交付的流程也会很好，如果大家都不专业，那么这个流程很可能为未来的测试和使用管理埋下“祸根“。这个祸根如果在后期阶段有专业的测试也能弥补，如果测试也不专业，那么在未来的使用阶段更改的成本可能要大于项目的实施成本，最差的结果就是这个系统停用报废。所以建议各位需要上马大型的计算机化系统的时候，一定要成立一个专业的项目团队，如果没有这个能力请一些外部专家是非常有必要的。否则出来混迟早是要还的。业务流程确定了以后，要有书面的业务流程图，并且要经过项目团队和业主的审核。这个阶段是一个反复讨论争吵的过程，实际上就是在确定业务需求。如果这个阶段业务没有争论，完全以供应商意见产品经理的意见为主或完全交给供应商的产品经理去完成这个设计，甚至于听信供应商销售经理的话，那么项目结束后基本上用户都会骂项目组说这个系统怎么设计成这个样子。主要原因是前面缺少了争论和讨论。前面不争吵，后面就扯皮互骂。反正争执扯皮互骂是早晚都要发生的，正所谓出来混迟早要还的。
流程图确定以后，后面就是去设计系统的架构，功能模块了，这个时候有架构经理（架构师）和系统分析师的角色就要出场了。系统架构师、系统分析师是一个根据业务流程需求最终确认和评估系统需求，给出开发规范，搭建系统实现的核心构架，并澄清技术细节、扫清主要难点的技术人员。可以考虑为工程项目的详细设计。从工程项目的角度去看，可以简单的把IT系统的产品经理理解为设计师，而架构师就是土木工程师。这个架构师的结果决定着架构师工作的好坏决定了整个软件开发项目的成败。月薪4个零以上的美元起步。知乎上说，产品经理相当于建筑设计师，设计师设计了一个“大裤衩”的建筑，而架构师则是土木工程师，是决定着这个“大裤衩”未来能不能立得住。你能想象用木料搭建苏州的大裤衩建筑吗？这就是架构师的作用。这一部分太专业，我个人是不懂的，在系统结构师和系统分析师对系统架构设计完毕后，系统的网络拓扑架构，功能逻辑结构，功能架构，各软件模块的流程图，用户界面等各种软件硬件的功能标准和设计标准也就确定了，同时业主的URS中最重要的模块-系统要求也就随即确定，这个模块是未来验证测试的重点。
简单的来说，业主老板提出业务的期望，供应商的产品经理和项目团队将其转化为“业务需求”，通过业务流程图等一系列交付物来表达业务需求是否被满足。架构师和系统分析师，用技术语言设计整个系统，将业务需求转化为系统要求，通过各种设计说明表现出来，对标的业主的文件是URS中的系统要求。设计完成以后，将URS的系统要求和设计说明对比，也就形成了我们通常说的DQ文件。

系统设计满足要求了，就转到软件开发阶段了，软件开发经理就要出场了，他的职责就是要组建团队把前面的系统要求（技术要求）转化为具体的硬件和软件。前面的产品经理是设计师，架构经理架构师是土木工程师，那么软件开发经理就是施工经理。他主要负责的工作就是把前面的设计变成实实在在的硬件和软件代码，并通过测试。复杂的项目中还需要一个配置经理，就是部署不同的测试环境，并管理配置变更。前面说了，系统的各种设计说明，对标的是业主URS中的系统要求。而软件开发经理，就是将各种设计说明转化为开发说明和具体的技术标准语言。包括各个模块标准。项目经理把不同的模块分给不同的程序猿。程序猿用代码语言把模块标准转化为单元模块的程序。标准的做法就是程序猿A写好了程序，程序猿B审核。我们称之为源代码审核。审核通过，进行测试，我们称之为单元模块测试。单元模块测试完毕，将不同单元模块集成，然后进行集成测试。集成测试完毕后配置经理根据配置标准搭建测试系统环境。当然前面的开发环节也有开发测试环境，也是需要配置经理干活的。系统测试完成通过以后，软件开发过程的工作基本完成，剩下的工作就是业主验收阶段了，行业中称之为用户验收测试（UAT）。也就是验证领域通常说的OQ工作。业主和供应商的扯皮大戏也就此开始。
整个这个环节，代码审核，单元测试和集成测试，基本不需要业主参与通常为供应商完成。如果是GxP行业中的5类软件，而且是高风险的功能模块，那么业主的IT专家和QA审核供应商源代码审核的总结报告和测试汇总报告就好了。不需要每一个测试环节都参加的，大部分工作业主方的人员是看不懂的，并且这些工作都是在供应商处完成的。业主就是懂，也没时间去参与监督和管理，也提不出什么具体问题来。通过审核测试计划和汇总报告已经算是比较好的管理手段了，让供应商承诺他们做好了，没有问题。
系统测试和用户验收测试（UAT）完成以后，供应商的团队也基本可以收工了，系统的使用说明书也可以提供给业主了。因为项目得到了业主的认可。供应商也因此信心满满获得了新的领域的经验，供应商可能会把这些成熟的项目经验固化下来，比如标准模块包保存下来，未来再通过迭代逐渐形成标准模块。今后再遇到新客户可以直接调用或配置，就无需重新开发了。
这些过程测试是最简单的工作，很多人的理解CSV就是测试，这是最肤浅的理解。测试只能证明“它”就是“它”。仅仅通过测试无论如何也不能把郭德纲验证成为林志颖。
良好的合作和成功的交付，建立了供应商和业主之间的信任。未来的工作就是日常运行维护和技术迭代了。这也是供应商未来的一个盈利点。有的大企业业主在项目结束后会直接把项目团队部分成员包下来，专门做未来的运行维护。因为这些人了解整个项目的过程和系统的设计，并且了解业主的需求,维护起来也得心应手。
以上就是我了解的SDLC，其中的描述大部分是从非软件开发专业的角度去描述的软件开发的整个过程。其中有太多的细节，我个人也没有全部参与，所以也是略知一二，不当之处还请专业人士拍砖。用非专业的语言描述专业的事情，目的是站在制药企业人能听得懂的语言解读整个过程，以帮助大家了解一个全新的计算机化系统是怎么来的大概过程。
这些过程描述了系统开发的过程。中间省去了太多的扯皮场景和业主应该做什么，以及如何才能防止扯皮确保项目成功的环节。了解这些过程对于制药企业来说是有必要的，但所有的业主都能理解也是不可能的。说到这我又想起了我的一位英籍的同事的一句总结非常到位的话“我理解绝大部分扯皮是源于Knowledge gap！”，是的，我非常同意，认知认识知识的不同是扯皮的根源。
今后有机会再跟大家分享业主应该怎么做。

002007008

谢谢老师，学习中

小金库

谢谢分享，下载学习