前言中国第一家沪市主板上市连锁药房——益丰大药房是全国大型药品零售连锁企业，连续多年位列全国药品零售行业综合实力和综合竞争力五强，从2001年创立到2019年，在全国拥有连锁药店近5000家，员工20000多人。益丰不仅注重快速扩张，更注重精细化标准化运营管理，打造了六大核心运营系统，涵盖新店拓展、门店营运、商品管理、信息管理、顾客服务、绩效考核等，成功地实现了跨省经营和快速高效复制。
苏衡（广州市CIO协会秘书长）：益丰大药房对数字化转型做了哪些思考和实践？是什么契机下促使益丰做出了向中台化转变？
孙浩（益丰大药房CIO）：益丰是从2017年底开始想做中台，跟很多供应商做了交流，也做了很多企业实际案例的考察和沟通。在过程中，我们形成对整个中台，以及整个数字化的转型和对整个数字化技术团队组织的认知和实践。
只有整个企业的数字化水平、企业的人才结构以及企业的业务需求达到一定的阶段以后，才需要去考虑往中台化进行发展，这是我的第一个观点。
对于传统的信息化来讲，并不是每个企业都要做中台。在企业规模不大，数据量不大，业务变化不太快，整个数字化人员并不多的时候，中台其实并不适合这一类的企业。因为中台是需要有很多的服务中心，它需要以自研的体系为主，而不是以商业套件的供应商体系为主。如果为了中台而中台，就象是大炮打蚊子，其实会带来一系列后期维护的难度，还有很多资源的无谓消耗。对于传统的信息中心来讲，普通制造型企业或者是规模不够大的零售、快消，他们信息化体系很简单，自研需求不多，IT人员也不多，有些项目也可以用套件商品或者定制开发完成。我觉得这种团队并不适合往中台化这方面发展，因为公司的体量、业务需求以及人员储备，都不适合他们去为了做中台而做中台。
益丰也是从一个规模相对不大的公司发展而来，最初只有三五个IT人员，最早用一些ERP的财务体系、门店管理的系统就可以支撑。但是外购的门店管理系统是单体结构的，只支持单店，多店的话就很难去进行管理。因为连锁化以后，对多店模式开始产生了一些要求。这个情况下我们就有四、五个开发人员做了一系列开发，基于以前单体化结构上让它能够连锁化，当时它的数据传输都不是实时传输的。接下来我们发现，零售要非常贴合它的业务，对系统的要求会很高。我们开始做整个零售营运这一块的内容，以前的软件已经没办法支持了。我们在考虑，是继续找一套能够满足需求的商业软件，还是我们开始走自研的路？我们也看了很多的产品，后面发现这些产品都不可能完全满足我们，而且它的贴合度也不会特别高。如果选商业套件，就需要大量的二开，并且我们也做了一些案例企业的调研，发现他们在选用商业套件以后，它的迭代速度是很慢的，它可能一年才迭代几次，而且供应商这边的成本也会很高，它的响应效率是很低的。
在2012年，我们研究了一些产品后，发现益丰整个的门店营销跟核心经营相关的系统，不应该依赖于外部，应该走自研的这套体系。我们当时才十一二个人，我们还是决定要把这套体系自研出来，加上供应商做了一个项目外包，花了8个月的时间把这套系统做出来。随之以后那套系统在整个公司的经营过程中起到了非常大的作用，因为我们是完全量身定制的，可以非常快速地响应业务需求，每周进行迭代。
在这个基础上面，整个研发团队就越来越壮大。到现在已经不是基于那一套系统了，我们把整个公司已经演变成了一个与业务紧密结合的数字化研发体系。目前来讲，益丰自主研发的人员已经有一百多人，包括产品人员有二十多个，开发测试有一百多个人，还有运维、套件类、外包的人员，加起外包人员已经超过两百个人了。所以规模及业务复杂度到了一定程度，就必须要考虑中台化。因为中台化一定是把现有业务的复用性抽象出来，而不是单个单个的商业套件。商业套件为主的这种已经很难中台化了。如果你的核心系统、核心经营相关的系统都是商业套件，即使在中间再做一层，难度也是相当巨大，相当于多了一套系统。
而益丰中台化了以后，会通过中台的能力，来接管以前那些老系统的业务。所以我觉得必须要企业的业务、团队的能力、公司的业务需求达到一定的层面，大家彼此产生共振才有这种中台化的需求。
苏衡：共振这个词非常好。在过程中是有什么契机让产生企业内部产生共振的呢？
孙浩：其实在决定自研开始的时期，内部有很多不同的意见，担心自研的风险。后面我用了很简单的几个原因去说服老板：
1、目前套件迭代的速度太慢，企业不能忍受一个月迭代一次；
2、套件是按终端收费，每开一家连锁店都要两三千的高额成本；
3、套件包括开发和后续运维二开，自研的起始成本是比较高的，但是后续的开发成本比供应商低。
后面我们就把整个系统全搞定，包括会员、门店收银到后台的管理。现在回想起来都觉得特别值。当时才500多家店，我做这套体系的时候，跟老板拍胸脯说，我保证你可以支持3000家店；现在这套系统已经支持了5000家店了。虽然我们在这上面有很多的不停的迭代，不停的性能优化，但是用的还是以前的基础，而且现在新架构在慢慢的小步迭代的过程当中，老架构还要支持到8000家店。从500家到8000家，这是一个很夸张的数量级的变化，我们现在一年的数据量比前面四五年的数据量都要多。
还有财务方面，财务我们会分为很多方面，ERP有财务体系，资金管理系统都是成熟的套件，我们就不会做自研。但是门店有很多的支付方式，我们有一百多种支付方式，有医保、现金、第三方支付等等收入要汇到总部。我们发现销售和收入的对账体系是没有套件能够解决的，像我们现在对接银行应该有六十几家，有些店可能在乡镇，基本就是农商行。而农商行的信息化系统可能还不完善，对接的成本很高。我们现在的做法就全部用RPA，匹配数据到我们的系统里面后再进行对账。银行相对结构化还更好一点，但是其实还有另外一块会更麻烦的，是医保。每个地方的医保政策都不太一样，系统也不太一样，有的是有接口的，有的是没有接口的，有的是不可能给你做接口，有些可能还限制了，比如医保系统只能在某一台机器上面，并且绑定医保的专线。以前在这种情况下，需要通过门店拍照上传，然后我们通过人眼去确认数值，并跟后台的结账数据进行匹配，这消耗我们大量的人力，以前是二十五家店，对应的一个财务人员，而且只能一个月对账两次甚至一次，这个劳动效率是非常低的。我们现在已经在做RPA了，医保的数据已经全部匹配到我们的系统做自动对账。自动对账以后，差异额大的部分做人工重点审查。这样对公司财务人员的人力节约，是非常可观的，财务可以去完成更多的工作。这些都是数字化所带来的一些优势。
整个疫情是对于零售行业的影响是比较大的，但是药店是作为零售行业里面，在疫情期间既有正影响，又有负影响的一个行业。这种情况下技术需要快速响应业务的需求，才能在这期间转“危”为“机”。
苏衡：有没有哪些典型事件是让高层也产生共振的决心的？
孙浩：首先第一个，去年遇到大促的时候，技术在支持业务的时候，应该是流水上传的时候，业务量太大了，导致可能延时了一两个小时，然后才能同步。当看不到及时的销售数据时，老板就会容易失去目标感，就会思考现有系统怎么样能够快速的解决类似数据压力的问题。第二个，公司上市以后，老旧的组织体系已经变成制约着我们快速发展，老板也找很多的外部公司专门做这方面进行沟通交流。了解到美团它是一个中台部门，它这个中台部门里面就包含了企划的、营运的、人力的、信息的，能够及时的去响应前台的需求，当它需要的时候再来去调集团的炮火。老板也意识到了我们的组织要中台化，我们正好在前面在推我们的技术中台化，他也明确知道我们还在快速发展，要支持未来更长远的业务的发展，因为未来我们可能几万家店，所以你技术体系一定要迭代。组织中台化就很触动老板，我们数字化中心就是第一个往这方面要走的部门，接下去很多的部门都会往这方面走。
孙浩：中台成功的要素，是我们做完了一些案例调研以后总结出来的。首先你要做好一个中台的话，你的高层领导一定要认识到这个问题，它不是一个项目，更不是一个IT部门主导的项目，需要企业进行长期的资源整合，随着业务变化，部门的组织都会产生变化，所以像我们在做中台的时候，我们当时组织了所有集团高管参加了很多场中台的培训，跟他们讲清楚中台会对他们产生什么样的影响。组织也是要变革的，就像我们现在的组织体系，因为要做中台，组织就需要中台化。我们合并集团内的线上线下分离的研发团队成立数字化中心，中心内有一块做共享服务的团队，有共享的产品经理和研发。当我们发现这个能力能够沉淀和复用，是用这个团队来承接的，而不是在之前的业务研发团队，所以他们会有一些可以复用的能力。组织没有到位，项目式的推进，中台很容易就走歪了，我们也总结了像一把手的工程、长期运作、组织的变革、容错率等等经验，其中容错率是因为变革过程中一定会有阵痛的，所以企业要容许这种创新过程当中的错误，只要不是责任心导致的错误就可以了。苏衡：因为中台最后是业务价值的体现，决定我们技术的价值，这个风险上你觉得是怎么样？或怎么控制它？孙浩：风险其实最核心的第一个，一定是领导要深度的去参与，业务部门才会配合协作。我们会设计一些东西，跟业务去探讨，这个过程中业务要跟技术部门真的是同频共振，大家一起形成一个最终的设计思路，然后把原型做出来，大家一起确认，而不是一味等着技术部门自己搞，然后全盘否定，甚至我们在全程中会不断地约业务的老大一起复查，如果没有一起确认的沟通结论，我们是不会进入研发的。产品设计评审采用会议方式，包括业务副总裁、业务部门负责人等，每次发会议纪要，记录每人意见。这样减少不认账，也保证了核心管理者对产品的逻辑思考和确认。苏衡：在数字化这种转型的情况下，是否对团队的要求就开始不一样了？孙浩：是的，对于整个数字化转型，我认为要从项目管理型转变成为产品研发型的团队。它的侧重点是完全不一样，项目管理型的对业务和技术的把控能力都是不够的，会变成是借助不同的乙方利用各自的技术体系，打造成一个个烟囱，而且可能会被供应商绑架。产品研发型的团队，自己会掌控整个技术底层，并让技术底层是通用的，不要变成一个个不同的技术栈，导致资源无序的消耗。产品研发型的团队会比较掌控自己的产品跟业务紧密结合，从而创造价值，并且能够持续不断地迭代。也许1.0的版本，能够简单的满足业务的需求，并不特别好用。当能做到持续快速迭代的时候，每两周迭代一次，也许产品迭代一个五到十次以后，你会发现这个产品对业务来讲已经离不开它了，对于项目管理型来说，这段时间也许还没有找到合适的供应商，合同都还没签，立项都还没到，所以这是最大的问题。像我们现在自己掌握了技术，自己掌握了产品，自己有研发团队的时候，当业务有需求，我们很快可以满足他们。包括像疫情期间，门店做口罩预约，用了三天我们就把整个口罩预约的系统做出来了，导致很多政府部门就找我们支持。后面变成了益丰的系统是在给整个城市来做预约的服务的，包括口罩领取核销系统也是一样的。我认为我们这样数字化的团队，已经必须要互联网化了，因为互联网公司的迭代非常迅速。苏衡：那项目增多了，延伸而来的就是交付周期的问题，特别是遇到一些大型项目的时候，益丰是怎么解决这块的？孙浩：对于交付周期来说，有两种方式，一种方式是前期考虑充分，产品设计完了以后做一个充分的评审，再进入研发，这样研发速度会很快，产品消耗的时间会比较长，但是做出来的产品会比较完善。第二种方式是业务需求比较紧张，那就不能想太多，先在做一个MVP的版本。先跑起来，中间会发现有很多不完善或前期遗漏的细节；这个时候就开始做产品的迭代，迭代的过程会发现产品在不断优化。利用你以前的旧版本当时积累的这种经验和能力，很快地把新版本做出来，再去把旧版本给替换掉。这个过程当中虽然会浪费掉一部分研发成本，就是旧版本的一些研发成本，但是首先很好的满足了业务的一个及时性的诉求。并且在这个过程中，其实我们用一个比较小的成本在试错，最终做了一个更好的产品，更好地满足整个业务的需求。我觉得这个是跟以前是不一样的，以前传统的我们也是项目制，供应商只要交付了需求范围之内的产品，验收通过了，供应商撤场了。最初你可能这样想的，但是到了交付完的时候，也许这个产品就必须得束之高阁，因为它已经跟当前情况完全不太一样了，它已经满足不了你现状需求了。现在我们做这些东西，就要跟业务绑在一起来干。孙浩：数字化转型团队更重视的是业务架构的设计、需求的分析、产品的设计、UI、UX、对用户的美观体验，已经从以前满足功能,到变成对产品外观，交互体验的需求上。一开始我们是没有产品经理的概念，我们只有一个需求分析的概念。实际上就是我们自己对业务比较了解，IT人员里面就去负责需求分析的；我们其实连架构人员也没有，开发人员也是Delphi，就会找外包一起探讨，沟通我们的思路，确定了需求，然后开发落地外包。在过程当中，就可以培养内部的人。我们从一个JAVA都没有，到项目做完了以后可能就有十个JAVA了；再把他们留一段时间，然后慢慢的我的团队有二十几个JAVA了；供应商就可以不用了，就自己可以持续不断的迭代。这个时候会发现，不同企业的选择不太一样的时候，后续的发展是完全不一样的。孙浩：从管理上来讲，我们做了几次迭代。刚开始集团是管理信息化的部门，后面因为互联网的发展，又成立了线上的团队。但是两个团队的互联互通、协同，效率是存在一定的问题，会造成更多的烟囱，所以我们按照团队的能力把它合并，做成了不同的团队。运作了半年以后，我们发现这个也有问题，会发现业务的一个需求会经常跨产品线，业务就不知道找谁了，然后会有很多的灰色地带。我们发现必须要以业务为导向来做整个团队的这种组织结构的设置，所以现在整个的组织体系都是按照BU去建设，数字化中心的实体组织还是跟着我们的能力去建设的，实体组织不变。举例子，线上新零售的虚拟组织，会有产品团队和研发团队；营运和商品是我们的核心业务，面向于营运的、营商的产品团队和技术团队，也是分开的；会有面向职能的，比如像人力、行政、财务，这些后台部门的产品团队和研发团队。资源是在自己的BU里面是来讲是相对独立的，独享的。这样的话，业务跟我们的技术相当于是紧密结合的关系。我们的产品经理都已经放到了业务部门一起办公，业务的老大可以随时跟产品经理进行交流，然后产品经理也受业务老大的指挥。我们产品经理的能力会比较强，整个素质会比一些管理人员的素质还要高；例如让产品经理去店里面去考察调研，当他在看到问题的时候，会给出很多的解决方案；业务的老大就能够通过这些解决方案的建议，很快知道怎么样去解决这个问题。其实我们可能都已经想好了，我只要让他做选择题就可以了，你不要让他去做这种思考题。苏衡：这个可能已经不是传统的矩阵式的管理了，特别是产品经理，会面临着虚拟组织、业务部门、IT岗位职能的角度等等三个维度的评价。孙浩：是的。我们现在的考核体系变成了一个矩阵式考核体系。我们以前就是传统的KPI。现在有OKR。对于IT团队这种非标的工作，考核其实有一定的难度。传统的 KPI或者新的OKR，都会涉及到考核人是以上级对下级考核评价为主，在这个评价过程当中，就没有标准可以支持评定。所以我们现在矩阵制考核就是上级对下级有一个考核权重，主要以内部协同、整个数字化中心对个人技术质量的考核、对应的业务线负责人的考核。这样业务人员的目标和IT的目标就很容易对齐，响应也会更加及时。孙浩：也不完全，我们有权重。我们不同的业务导向是不太一样，像我们新零售不停在创新，它跟技术是强关联的，这些创新都是依赖于跟我们的技术要紧密结合的，都要靠技术落地的；这个时候，可能业务这项的指标会给六成的考核权重。而像营商这种线，就没有必要要这么多的考核权重；因为技术部门还是以服务为主，跟他们的结合度会稍微弱一点点，不会那么像新零售那边的紧密度，所以这边就是倒过来，数字化中心占六成，整个业务占四成。你所对应业务线的财务指标，比如营运做得好，销售完成率很高，毛利和完成率很高，但营运的指标就会跟着高。新零售做得很好，新零售财务指标好，我们也会跟着好，大家都是共赢的。所以IT部门也背了一定的业务指标，通过绩效差也调动了部门的积极性。我们当时是定了一个指标，叫做业务部门对IT的综合评价,通过用户思维、业务思维、团队协作解决问题和及时响应等等相关的内容，然后进行打分，最终得到标准分值，在一定的范围内进行强制排名。苏衡：那其实对于团队的领导者来讲还是很辛苦的，你有一大半的时间要放在人的角度去考虑问题了，就不再是技术架构这些或者去处理技术上这些问题了。孙浩：是的，但其实还好了，这些一个季度做一次,占用的时间不会特别长，有系统来协助管理。但其实跟绩效考核相比，我认为一个数字化中心的管理者，花一半的时间在人的身上，这是一个好事。因为有好的人，你才能创造好的成果和好的业绩，所有做的不好的地方，大部分是因为你人没有用对，所以像我现在一半的时间，我要调整人员，要跟人谈话，要激活人。另外一半的时间就是我要过产品的设计，去解决日常过程的协同，团队优秀了，他们已经可以把问题消灭在萌芽状态。孙浩：其实我们之前想说找外部供应商，我们把整个中台切分一二三期，一起去共建，双方各出一半人，大家共同来设计研发，最终落地。以前想的是在现有体系上面跑，从0-1搭一套整个中台，包括前端的业务，再把老的废掉，全部切到新的体系里面来。这个动作太大了，风险也很高，时间也很长，也没有这么多空余资源投入。我们现在逻辑就改变了，我们叫做小步迭代，去实现我们整个的中台。今年可能就做几个中心，我把这几个东西抽象出来，再去把我前端和中心接管过来；这样一个个中心去做。如果我的资源不够，我就找外部供应商去协同一些资源，核心的资源就可以了。那就不会导致说需要很长时间才能见到一个效果。也许我做了一个中心，像我刚才讲的促销中心，我们现在已经在研发过程当中了，7月份就会做完，然后把整个前端切掉，那从业务上他就有感了，他会发现说我们以前整个的促销是不完善的，有很多的问题在新的版本里面都解决掉了。那这个中心其实我已经能够对外提供能力了，就会把以前需要用到促销的所有能力替换掉。苏衡：每个企业都必须选择一个符合自己的自身定位和自身环境的一个路径，尽可能降低失败的概率。孙浩：我也看过那些文章，那些人为什么他会失败？我认为几个点。第一个他的项目化的运作方式。然后第二个他自身的能力储备没有达到，想依赖于供应商帮你去建设一个中台，我认为这个东西真的是叫做还没有理解中台的真正的含义。第三块就是很多的中台供应商，他还是只是在给你提供产品，然后再按照你的思路进行二开。所以从我的角度上来讲，我们有一个观点，就是说我一定不会用供应商之间的已有的东西，我一定是基于现有的业务和现有公司的情况，以及我未来的想法，然后重新从产品层面做抽象，然后在抽象的过程当中，我可以借鉴供应商的模块思路，最终从0-1做代码的研发。就是从产品到整个的设计到落地，都是应该为我量身定制的，中台真的一定是每个企业不太一样的。我认为中台是一个企业发展到一定阶段，你的人员、外部环境、内部环境都准备好的时候，水到渠成的一个东西，它并不是一个项目。也不要想着说因为做了中台，整个公司的数字化水平有一个天翻地覆的变化。当你没有准备好的时候，其实这个东西对你来讲一点用都没有，只会变成你的负担。