鼎康生物 信息数字化高级总监 彭玉洁 先生分享主题是：“敏捷精益在企业数字化中的良好实践”的分享，彭总从制药行业数字化的需求背景，快速敏捷的信息化推进需求、甲方公司信息化团队的技术能力培养目标、精益和敏捷概念下的内部开发理念、低代码平台的业务需求场景和优势劣势、对比外部供应商信息化的得与失、项目推进的路线图和业务场景的优先级、项目的风险和收益分析等多个角度为大家进行数智化经验分享。
人物简介：
彭总是鼎康生物 信息数字化高级总监，深耕生物制药领域信息化工作，布局搭建实施从市场销售、研发、生产等全产业链条下的GXP系统体系，丰富的生物制药信息化项目管理和实施的经验，构建面向智能化工厂的IT和OT融合组织，搭建企业数字化，领导企业数字化转型，引导业务部门对IT需求的有效转化，实现IT对业务的协助和推动作用。
今天我演讲的主题是敏捷精益在企业数字化中的良好实践。在正式分享之前，先简单的介绍一下我们公司鼎康生物是一家致力于生物医药制造的一家CDMO公司，我们帮客户从细胞培养到原液制剂，然后研发，包括我们帮助客户做一些注册服务，欢迎大家如果有这方面的需求，可以联系我们公司的销售部门.
今天话题是包括以下几个内容，第一个是制药行业数字化需求背景的精益视角，我们看一下在精益的视角下，我们制药行业的数字化有什么不一样的趋势。
我们如何从组织的优化上做好从精益到数字化的这样一个准备，然后我们如何去培养我们传统IT团队它的敏捷开发能力，在培养过程中我们整个能力发展的路线图是什么样的？其中低代码平台作为敏捷经济在制药企业的信息化团队中的一个应用实践，还有它的一个收益分析，大概这几个方面。
我们从制药行业数字化需求背景的精益视角，首先我们从公司业务信息化的需求，我们知道是传统的我们从IT信息化这个角度，我们一直在推动无纸化，其实无纸化重点是不是去节省纸张，而是我们要在这个过程中，怎么样让我们传统停留在纸面上的业务数据，让他在系统中去流动，从而去发掘数据的价值，真正让我们的数据去达到信息化，这才是我们真正的一个目的。
你看无论我们这个公司的一个信息化程度有多高，我们相信大家都会观察到，每家公司不光是甲方乙方的，我们都会有大量的纸面的或者是公司，不光是甲方乙方的，我们都会有大量的纸面的或者是电子表格的工作在做。
那么在这个过程中就会发现我们各个部门人他们总会去做一些数据的筛选或者一些计算，还是依赖于人工的比较多，总会有这样的机会。那么在这个过程中其实是浪费了很大的工作量，然后它效率是远远没有说是我让系统去完成这方面的一个功能效率提升的高，这就是从经济的角度我们会发现这个问题。
另外就是我们大家可能还有体验我们我们很多业务场景中，现在在用表单就纸单添一个纸单，然后需要几个人去签字，然后不断的传递需要5个人去签字的一个表单，基本上这个东西物理的传递大概就5场所。所以这个过程中实际上都是浪费，我们从经济角度来说，只要走动，全部都是浪费。那你放到一个人的桌子上，他再去签这个东西，不可能在第一时间给你签掉，所以他会让你等等待的时间那也是一种浪费。
但是如果我们通过IT应用，IT系统去给他做了数字化以后，我们可以想象这个时间能够大大缩短，他收到及时通知对吧？他就会很快把它签掉，或者去审批这个过程，从而能够提高我们内无论是内部顾客和外部顾客，他满意度都会大幅度提升。
另外从我们制药行业应该是绕不开的一个话题，就是合规了。我们知道说只要是落在纸面上的，现在不管是FDA还是中国药监局，其实对这一块都有很大的一个担心或者疑问或者监管说只要你在纸面上，我就花的精力，监管的精力就很大，对不对？不管是产品医药产品本身还是财务内控方面其实都一样的，主要是纸面的，他就不是特别信任。我们在这方面如果是能做了信息化数字化的工作，他在数据完整性上有很大的提升，对公司质量竞争力肯定是要有很大提高的。
所以信息化其实推动公司全面的降本增效的功劳是肯定是不可埋没的，这是我们从公司业务信息化方面的一个需求。
另外我们每天可能作为IT部门会收到大量从业务部门发来的说我这个事情我想做个系统，那个事情我想做一个系统，这种需求非常多，但是我们其实是不能期望，当我们收到个系统的时候，我们传统上意义上我们去找一家今天很多来的我们一个第三方的供应商，我们传统思路去找他家看了有没有合适的一个方案，但是其实上我以我的经验，大的场景没有问题，一定可以找到现成的还不错的方案。
但是中小场景就很难说每个公司有它自己的特色，我们很难去就是说找到一个非常匹配自己的这样一个方案，于是就有了一些妥协或者讨论，这里面可能通过大量的和外部供应商的沟通去展示我们的流程是什么样的。即便这样，我们觉得很多东西最终落地也不一定是完全符合我们最终用户的需求，对吧？
再不要说一旦落地以后，我们用户需求在一直在抱怨，就是说你怎么又变了需求了，对不对？但是当它变的时候有部分是不合理的，但总有合理的部分在里边，我们怎么能够更快的让我们业务合理的需求转化成新的版本，这就是一个能不能实现就是快速迭代。
另外从小型的如果是个很小型的一个场景的话，我们可能也要做非常类似的这样一个沟通和实施成本，这对于我们公司来说应该是一个浪费。
然后如果我们公司内部的IT团队有一定的开发能力，其实我们能够对我们公司这种不断的业务需求能够提出更加快速的一个有反应，所以我觉得这都是从经济视角，我们能够看到说我们制药行业的数字化需求应该怎么样？
要去应对。前面说了我们有这样的一个一些需求背景。那么从组织上、组织上，我在这家公司我大概是目前做了一年半多，我把除了IT以外，我会把公司的经营部门从零搭建起来。当然对于不算大的一个规模，我们大概400多人左右这样一个规模，对于规模的公司其实很难精益一般是大公司在做，他很难去支持说你有一个专门的经济团队，有专门经济工程师去做这个事，团队有专门经济工程师去做这个事，这个不太可能。
所以我们采取的模式说我们去选掉一些兼职的业务部门的骨干，作为一个虚拟团队，然后我们在各个部门其实都选了我们叫经济代表，然后给他们做一些能力的培养，给他们培养以后具有一定的经济理念，从而推动公司的这种精益的发展。
要建立一个持续的能力的经营体系，我们更觉得以下三个方面是重要的。
第一个我们要建立与业务匹配业务战略匹配的经济文化，你离开了整个公司的核心业务战略，你做任何事情其实都没有意义了，包括IT的战略也是一样的。第二个我们是从下往上，通过我们的分布在各个业务部门的精益代表，他们去通过自己的经济理念去影响到各个周围的同事，从而去做持续改善，去分析自己身边的工作流程，去做持续的改善。
而且我们发现我们的从去年10月份开始做这个事情，三个月时间大概有300多个改善提案，说这个量还是蛮大的，最后到现在为止我们基本上落地在一半多就已经完成了，其他还在进行过程中，但是也有最后经过研究发现这个可能是这个思路不太合适的，可能也会有，但是我们发现绝大部分的改善，我们现在的员工普通员工他们第一思路说如果要来一个IT的方案或者IT的系统，或者是让现在的IT系统它能做一些改善，一些优化，我们就能实现这样一个流程上的改善，这是很好的思路。
这种其实是对我们数字化的快速实现体现提出一个需求。另外一个就是我们从上到下，要想实现持续改善的这种文化，或者是这种行为思路，我们需要各级的领导，他们在定期要对自己的业务部门进行一个现场管理，一个现场核查，我们给他设计了一个经济的核查表，领导他会拿这个表对自己的他所管理的业务区域的一线要进行定期的核查，不要总坐在办公室里边。
我见过的公司无论从因为我前两家公司其实都是一家蛮大的两家跨国公司，很大的公司，但是他们的很高层级的领导，不管是总监还是VP也好，有定期到一线去看的习惯，这个我觉得是一个非常好的习惯，我们在这个公司我们要这样推，各级领导都要去一线去看，并且他会留下表格，留下他检查的清单，所以这样也会给一线的员工有一个你可以说是督促或者监督或者是动力，这样让他能够持续的去看自己身边的流程。
好，这是我们建的我们的一个经济体系。然后左边是一个核心团队，这其实是从高管到中间的经济部门，包括经济代表，然后下面是我们业务部门这样一个金字塔型，在这样一个组织架构的驱动下，我们从战略上从从与战略远景上直到最终是落地实践的行动项，最后达成我们的目标，我们要从用精益的眼光去看整个业务流程，实现持续的改善。
我们要始终注意成本的控制，只关注业务用户的价值，最终消除一切浪费。我这边是我们能够实现的希望实现的业务目标。
最上面是我们实际上是我们公司的一个远景，希望以卓越精益运营打造竞争力的一个CDMO文化。下面从成本和质量，还有我们的运营上怎么样去推动经济的发展。这边是我刚说的管理层要到现场去做核查，然后这个是我们持续改善的一个活动。
还有一个重要的是我们要对这是我们现在正要做计划，做的是对关键的流程进行一个分析，从而找到它其中的可以改善的机会。实际上指的是现场管理，我们在现场管理中也发现不断改善的机会，最后是一个成本，我们说培养一个这样其实这种经济的需求对我们打造一个不同的IT的数字化团队提出需求，那么这边说传统的IT运维团队实际上是尤其是规模比较小的公司，不太有开发的能力，我们希望通过这种培养，我们有适当的一个开发能力，开发主要是指的什么？
我们先通过一些人员的升级和置换，不需要太多，一两个其实够了，你要小团队的话，团队其实有两两三个就足够了。我们通过一些Python的简单的工具入手，处理一些简单的业务场景的数字化，这样我们就在这方面我们摆脱对供应商的依赖，大的系统我们还是需要供应商的对吧？
然后从IT项目管理，我们要走向IT产品管理。其实在IT药企的不管其他行业一样，IT的定位很重要，那么IT到底是说我只管这个系统能不能用，还是说我要说我的IT人要去理解我的业务流程，这个是一个不同的观点，但我个人觉得我们应该走向业务，我们只有走向业务的时候才能去，因为所有的其实你建立好系统，所有的业务流程其实都在IT系统里，你只要想了解就一定可以了解到。
然后我们是通过这种通过和业务部门的交流讨论，然后找到用户痛点用户他会知道自己痛点，但他不一定能找到合适的方案，他有各种想法，但其中有很多其实是不靠谱的，我们要再结合IT技术给他提出真正的IT解决方案，然后和用户一起构建的时候，构建我们的基础应用模块，这就是敏捷的思路，我们要先用起来，然后再不断的实现快速迭代。
对我们来说，我们的发展策略是这样的，以rpa和Python这些开发工具为起点，建立信任，就是说我们先做出来一些很小的场景，然后我们的业务部门觉得我们的IT团队好像跟以前不一样了，不只是去做运维了，他们也能做一些自己开发一些东西，就有了信任感，我们自己团队觉得我们自己能做一些东西，我们自己的这种对业务部门的信心支持的信心也提升了。
其实通过rpa这些能够快速的替代人工的简单的重复操作，不同的系统之间的接口或者定期的这些执行的任务，都是可以通过rpa轻松去解决掉ERP。
开发基本上在几天的时间。所以然后如果是需要这简单的UI，在UI上可能rpa就它的能力会差一点，所以我们希望通过Python来增加一些 UI的功能。
另外我们同时还要去不断的拓展我们这个叫平民开发者，什么叫平民开发者？我们希望去看看我们有些业务部门，他们这里边的员工也会对IT感兴趣，大家知道其实对IT感兴趣的人不止在IT，他们也感兴趣我们好我们去看看他们有没有兴趣，因为这些低代码的 rpa Python这些很多人都在学对不对？
他们如果能有机会去学的话，去看他们最了解自己的业务，也最有可能开发出最有价值的一些小的东西。好，这时候it可能更专注于什么？专注于更复杂的场景了。然后我们的和我们对这些IP的一个管控，合规上的管控，好，最后我们再往深走一步，就提到了低点码平台的事情了。我们因为它会有更复杂的，包括审批流这些，这时候我们要通过和经济部门结合调研业务需求，从适当的规模的场景去入手。
简单说一下第二第三种平台，大家应该是非常清楚，但总结起来应该是非常清楚，但总结起来其实把让我们开发人员从传统的大量的代码编写中解脱出来，然后我们更更加专注我们的更加专注于我们的业务复杂度，而把很大家看这张图，其实我们把更多的低代码开发平台的职责，让他去承担我们软件开发的复杂程度，而我们更我们甲方的IT团队去承担更多的业务复杂度的分析，和我们业务部门一起，这是我们我们大概分析了一下说，如果外购一个系统和内部开发低代码开发的话，这个流程的区别大家能看到，其实左边后面的区别在哪？
左边更加复杂一点对不对？它多在哪？多在和供应商的沟通上，商务流程上招标比价不管，从十几二十万总会有的，这样的话招标采购还有迭代上，所以它的要蛮复杂的这部分。
当然这个流程不一定说我所有的系统刚才说过了，有些大系统还是要还需要走这个流程的，但是中小的我们可以考虑通过这种方式来实现内部低代码，敏捷开发的要点，我们觉得还是对于中小型的IT系统的需求，完了我们会购置一些低档的开发平台公司，IT团队是人力部开发，成本适中，跟规模有关系，然后我们更熟悉公司的业务，业务内部沟通也会更加简单顺畅，从基本模块开始做，一旦启动了我们快速迭代，这是我们基本的我去总结的一个场景，比如档案系统或者是一一个logbook、ppm资产管理，这些都是不是大的场景，有的甚至在市面上是买不到的，因为它太小了，有些公司专业的公司不会太去做这个事情。
然后但是我们需要考虑开发平台可能需要付年费或者是一次性的费用，这是我们需要在买上的时候考虑到开发这本身要这个平台需要是技术熟悉的过程，每个代码平台是不一样的，我们我们总结了一下低档平台选型的一个评估的模型，从应用性上合规结束或代码迁移，你哪天你不用它了，你这代码就不能用了，这也是不行的，要比较容易解耦合规性怎么去做验证对吧？
这是我们绕不开的，我们怎么样能开发不光按摩的APP，还有是寄苹果的APP是可以做的，然后还有一些手机端的发布这些东西，好。从收益上来说，我举个例子就是我们rpa，我们半个人基本上一年收获5000也好，这是累计效应以后一直会多的，还是第二平台，我们觉得可以有当年就可以收回投资，团队能力肯定是提升的，也触发了我们企业数据中台的一个建立的需求。
大家看一下基本就是我们这样一个模型去不断的去循环，从精益来触发IT再去完善我们的经济体系。这样最后是一些经验的要点，小小规模的公司有一些开发经验，然后要有主动去拓展业务的这种期望，公司对IT是有期望才可以，精益是一个保证持续不断的这样一个需求，否则就没有需求了对不对？
然后敏捷开发是能够实现快速迭代，最后不要忘了开发成本的一个控制，好吧？好，今天分享到这里。
