在之前的几篇信息化相关的文章中,都提到过一部分关于需求上的理解,最近参与的正在实施的几个项目里都遇到了类似的问题,所以,还是想系统性的聊一下这方面的内容。理解或有偏颇,欢迎交流。
系统实施上线的需求主要有3个阶段,售前、实施、维保,不同阶段的参与方、心理状态、代价不同,需要考虑问题的维度也就会不一样。
售前选型
在当前阶段,甲方掌握绝对主动权,在选型的时候可以从以下几个方面考虑:
1 根本目的的建立可以为系统选型定下基调,不至于在系统实施过程中走错了方向。最常见的应该还是为了提高工作效率,减少业务流转信息差,降低企业运行的人工成本和时间成本。也有一部分实验室是为了与时俱进,紧跟现代化的脚步,实现无纸化运营。还有一部分企业可能是因为想要通过上线信息化系统来提高公司的合规符合度,比如疫苗行业和血液制品行业。但如果企业本身有不合规的因素,缺少合规意识,妄图通过信息化软件来改变现状那大概率是天方夜谭。
合规的信息化系统会将更多的业务细节及业务逻辑嵌入到系统中,不合规的操作要么会在系统中会有更加明显地体现,要么就会成为日常操作地妨碍,阻止不合规操作地执行。
在信息化项目沟通中,不同客户对于人工智能和大数据表现出极大兴趣。对于研发实验室希望可以有制药行业专业方向的chatgpt作为实验设计和结果分析的助手,对于专业数据库(如科睿唯安)的接入提供强大的知识资源助力药物研发。虽然某些想法对于当前商业化的系统来说可以说是对系统功能的一种幻想,但这种客户需求才是系统更新的源动力,找到可以合作的供应商,互助前行,才能让系统焕发出更强的生命力。
2 系统架构及页面形式,这方面更多是体现在用户使用使用体验上以用户学习成本上。系统设计逻辑与企业的思维习惯是否一致,同时会影响系统上线推广难度。无论如何,要使用新的系统替换旧的工作方式,其推行难度取决于系统本身的复杂程度,并与系统使用范围和使用人员数量正相关。良好的用户交互界面可以显著减少这类问题。具体如何决择,参见[color=var(--weui-LINK)]以LIMS系统为例,浅谈制药行业信息化系统实施上线的影响因素
3 系统实施范围,范围决定功能,以LIMS为例,制药企业、CRO、药检所会有各自的功能范围和偏向,药企的基本模块包含批次检测、稳定性、环境、留样,各模块具体需要多少功能也应该根据自己的环境决定。CRO的企业相对制造型药企来说,因为项目制的方式,需要系统运维上有更多的灵活性,以便于不同品种的快速通用。药检所因为自生业务属性,更加批次检测流程,对于不同类型的检测发起和检测流程可能会不一样,但对于环境、稳定性、留样则无需考虑。
4 系统原型,信息化在国内虽起步较晚,但也执行了多年,也借此诞生了许多信息化公司,各有所长。售前说的再天花乱坠,也不及一个稳定使用的用户推荐来的让人信服。了解目标系统的实施成型原型,进行现场演示及实地考察,积极交流。除了关注成功上线的客户,还应该去关注失败项目,了解项目失败原因,也可以为后续项目选择提供另一维度的经验。
实施阶段
从完成合同签署进场实施开始,该阶段乙方的主要负责人也由售前变成实施,人员角色的变化带必然会引入更多新的磨合,甲方与乙方之间在某些方面就变成了利益共同体,相互理解、相互配合,大家聚在一起的目标应该是要让项目高质、高效地执行,并保障项目长期、稳定、高效运行,同时甲乙双方完成各自的KPI,也增长了工作经验。
工作方式:在此阶段,需求会更加明确和细化。甲方作为金主爸爸,在协同工作中大概率还是会更加强势一些,某些客户会对甲方实施人员的作息时间提出要求,比如必须现场实施、不接受远程。这得视具体情况而定,对于不同产品的情况也会不同,关键还是看在此过程中需要甲乙双方来回沟通的频率及现场沟通的必要性。完全驻厂实施会增加乙方的实施成本,同步也会增加项目成本到项目上,并最终传递给甲方。
但同时需要从另一个角度考虑的是,甲方为何会有此要求,一方面:担心因为不在现场导致沟通不及时,从而影响系统实施效率和实施质量。另一方面:因为乙方给出的人天数超出预期,因而质疑甲方工作安排合理性,是否虚报人天数,对应人天数下的工作是否在执行甲方项目工作,而不是在为其他项目上出力。作为乙方,应该有合适的管理流程及澄清方式,打消甲方疑虑。
参与人员:熟悉软硬件的IT可以保障网络质量,让软件流畅运行。熟悉业务的基础人员作为软件系统的终端用户,其实操需求对于系统建设很重要。中上层管理人员了解业务流程,但不一定能了解每一个流程细节下实操的习惯和操作便利性的问题。熟悉业务流程的管理人员可以从更加整体的面去考虑流程设计的合理性。QA的合规人员参与主要是为了保障整个业务流程设计的合规性,避免产生审计缺陷。
需求:我简单列出了现场沟通中可能遇到的3中类型的需求
用户憧憬:因为当前系统大多都是已经定型的商业化成品,项目组成员不一定全部都参与到售前项目沟通,因为不了解信息化系统而对其功能产生无限想象,某些需求已经远超当前产品的功能范围,可以作为后期升版的考虑。
实际需求:用户的实际需求除了与业务人员沟通,应该可以从当前已经存在的文件记录中找到。
纠错逻辑:对于生产MES、实验室ELN有着大量业务信息产出并需要记录在系统中,因为系统记录操作的具体时间,因此可能会存在许多时间业务逻辑,纸质记录因为一般只写到年月日,不记录时分秒,导致在系统中增加部分出错的可能。用户可能会因此而提出将纠错逻辑加入到系统中,但这种逻辑是海量的,不可能面面俱到,具体那些该做,那些不该做,我觉得可以从风险评估的角度去考虑:出错可能性*发现错误可能性*出错后果。不能一概拒绝,给客户一种过于强硬,造成后续沟通障碍问题;也不能一律接收,最终因为层出不穷的逻辑防错问题使得项目周期严重拖长,并拖垮整个项目。
运维阶段:
系统进入运行维护阶段后,可能会因为使用而产生新的需求,需要定期进行风险审查,在GAMP5中也有对应的介绍[color=var(--weui-LINK)]思维导图:GAMP5计算机化系统验证。但进入此阶段后,甲方应该也会随着系统实施完成,建立自己的系统流程管理方式,对于bug类的问题,及时联系厂家,责成处理;对于新需求或者新的产品录入,按照流程评估并执行,考虑需要投入的资源,如:是否需要厂家协助参与、是否需要补充CSV等。
文章来源:微信公众号:PharmaInformatic