“中台”这两年在大数据圈里颇为盛行，讨论度居高不下。作为大数据的下一风口，各大头部企业等都很重视，如今也渗透到各个传统行业。
那么，
l 什么是中台？
l 我们为什么倡导做中台？
l 中台什么时候做？
l 中台怎么做？
笔者有幸见证了中台在中国从0到1的过程，并在其中实践多年，基于过往的工作沈淀与经验积累，今天和大家聊聊中台。
王俊杰：
英国普资茅斯IT经营管理硕士，东南大学仪器科学与工程学院博士
曾任苏宁零售技术研究院院长、大润发/飞牛网首席技术官
亚太智慧零售产业联盟理事长、江苏省互联网协会可信区块链工作委员会副主任
全球著名创业实践项目「Startup Weekend」导师、上海大学生基金会评委
中欧国际工商学院、上海交通大学客座教授获中国企业数字化联盟”2020全国优秀CIO ”、CTDC首席技术官领袖联盟2019年度最具影响力技术领袖奖；参与编写的《中国智慧零售门店数字化白皮书》获中国管理实践至高荣誉——拉姆•查兰管理实践奖
以下内容节录于2021第五届零售消费品领袖影响力峰会，王俊杰个人的演讲分享
01
卓越的CIO更关注战略与IT相结合的方法论
提到CIO，你能想到什么？
对于公司内部信息技术做项目的管理与执行 ？
不！这是过去式了。
现在的CIO，眼里有战略，手里有技术，肩能扛业务，甚至主导整个公司发展与变革也不在话下。
过往可能我们对CIO的期待，可能是对于公司内部技术或者是对于IT做一些执行的项目与管理，但是现在大家对于CIO的期待越来越高，甚至希望CIO能够主导整个公司的发展跟变革。
我对CIO做了三个不同的层面的解读：
我们传统的CIO更多的是关注在技术层面，但很多优秀的CIO，他已经从技术层面开始扩展到业务层面的；而卓越的CEO更能够关注战略跟IT互相结合的方法论。
如果IT跟战略脱离，CIO可能会面临到问题是，公司决策层会觉得所花的钱不是在刀上，且所做的事情跟战略没有直接相关。反之，这个CIO是非常有成就的。
四十多年前，BCG布鲁斯·亨德森提出了增长份额矩阵，从市场的占有率、高增长率这两个维度去区分公司的业务产品。而这一管理工具时至今日，仍非常适用于当下的商业环境。
举个例子来讲，如果产品占有率和增长率都很高，那么我们定义这个产品为“明星产品”；而如果一个产品市场占有率相对较高，但是增长率已经趋缓，表示这是一个成熟产品，也是一个厚利产品；对于一些可能增长率很高，但市场占有率不是特别高的的产品，可能面临着成功或者失败，我们称之为“潜力产品”；最后是增长率低，市场占率也低的产品，我们称之为“衰退产品”，是需要淘汰的产品。
增长份额现在需要更快速的应用，并且要更加注重战略实验(strategic experimentation),以适应越来越难以预测的商业环境。由于市场份额不再是业绩预测的有力指标，所以矩阵需要一种新的竞争力衡量标准。
成功的公司需要更频繁地探索新的产品、市场和商业模式，通过有纪律性的实验不断更新他们的优势，并更加系统地完成这些工作，以避免资源浪费。现在要求公司以一种比竞争对手更快、更经济的方式投资更多的“问题产品”，并系统地将有潜力的“问题产品”发展成为“明星产品”。与此同时，公司需要准备好应对市场的变化，更快地将“明星产品”变现，让“现金牛产品”退出市场，并最大化"瘦狗产品"的信息价值。
从这个角度来看，IT就是CIO的“产品”，为了提升产品的市场占有率和增长率，CIO就需要从企业战略、人员、技术等方面考虑，从整体性出发，适应企业发展需求，以更高的价值获取“占有率”——也就是我们说谈论的“数字化战略”。
中台建设，就是CIO支撑企业内部战略和产品落地的重要手段。
02
中台是什么？
在数字化浪潮几乎席卷了所有行业的时代大环境下，中台成为数字化转型的重要抓手之一，有人就会盲目将数字化等同于中台。事实上，中台其实不等于数字化。
另外要提醒的一点，中台建设并不适用于初创企业，应该是高速发展的企业阶段，例如扩展期、突破期、成熟期阶段的企业。
以及，如果不从战略切入数字化，极有可能犯错。再次提醒这点。
所谓中台，从业务的角度来说，就是从若干垂直业务流程当中，把相同的或者相似的地方，拿出来抽象提炼，变成一个共享的独立的业务单元对外提供服务。中台的出现，解决了企业随着公司业务高速发展，组织不断膨胀的过程中，暴露出的种种问题。
比如阿里巴巴的数字中台：
阿里巴巴的中台前身其实就是阿里巴巴共享事业部。
为什么会衍生出中台？阿里巴巴中台又是怎么诞生的？
主要还是基于阿里巴巴庞大且复杂的业务。
举个例子来说，阿里巴巴有电商业务，电商业务下面又有一手电商、二手电商，比如天猫、咸鱼，如果每个业务单元都独立运作，就会出现业务部门和it部门重复相似的交易工作业务。那么这个时候企业就要考虑：怎么样可以把交易中心，变成一个共享中心，支持不同的交易场景——这就是中台的初步概念。订单拆分、创建订单付款、修改价格、关闭订单、删除订单、确认收货、自动发货，订单查询，等等这些业务也是同样的道理。
再继续深挖下去，就会发现，这些业务底层的运维逻辑、数据逻辑、安全逻辑都是相通的，我们把这些单独拉出来做一个交易中心。
这就是中台。
03
什么时候做中台？
那么什么时候做中台呢？
我的建议是：导入中台之前，除了考虑自己的企业，在现阶段是否适合做中台，企业要先对自己做灵魂拷问，问自己如下的问题：
是否效率不彰了？
是否能够复用？
企业是否是在成熟阶段？
是否理解中台面临的就是“组织”问题，也就是“人”的问题？
阿里巴巴的董事长兼CEO张勇就曾提到一个概念：如果一个企业是奔着中台去做中台，那就是死。
盲目做中台，之所以大概率会失败，是因为中台不是一个单纯的IT问题，它面临更多的是组织的问题，组织的问题就是人的问题。盲目导入中台，最终将会面临发展难、借鉴难、兼容难三大难题，如果没有解决这三个难点，整个业务变化耗时很长，业务中台会越做越重，最后导致这业务状态没有人用就被抛弃了。
01
借鉴难：对未来业务发展的预见。
企业新的变化，变化本身也没有太多规律可循，没有太多历史可鉴。可能今天想着不会发生的场景，第二天就发生了，造成业务流程和系统建设的缺失，还是快不起来；曾经想着大概率会发生，且为之耗时耗力的业务场景从未发生，造成建设的浪费，结果是付出发展的机会成本。
02
兼容难：对已有业务的兼容。
要针对某业务需求写出一堆代码来实现并不难，难的是做出通用的模式，来兼容已有的，和已知将要有的业务场景；从零开始做一个系统其实要比改一个已有的系统要容易，增加一段代码还能保证原有的逻辑不出问题比较难。
03
发展难：业务快速发展的压力。
中台的好处是实现快、成本低，有利于业务快速发展。这是有前提条件的，新业务和已有业务要足够相似，甚至相同。如果新业务和已有业务有较大的差异，那改造的时间更长，成本更高。
这三个难点凑到一起，导致三种可能的不良后果：
1.变化耗时长，越做越重
2.中台被抛弃，越做越小
3.“伪”中台，越做越笨
所以，做中台，应该要先思考两个问题：
1、业务是否趋于稳定？
稳定不是指业务不变化，而是指业务在既定的范围内发生变化，业务的变化是否有规律可循。比如前面说的销售管理中台，经常针对某个渠道开放或关闭一个保险产品的销售资格，这就是稳定的。但是如果在销售资格上经常出现不可预知的限制条件，就是不稳定。稳定不稳定，其实要看设计的人和设计的目标，不同抽象层次和归纳方法，对于稳定还是不稳定也会出现判断上的差异。
2、业务是否快速发展？
快速扩张新的同类业务条线，或者经常发生多业务条线变更，都视为快速发展。比如，经常增加新的第三方平台销售保险产品，销售流程和已有的销售渠道一致，就符合业务快速发展的特征。如果销售渠道就是一两个，比如有些公司主要是线下代理人渠道，发展再快，有没有销售管理中台意义不大。如果要拆出一个子系统，也不是中台，其目的是为了系统解耦、瘦身，并不是为了共享、通用。
正如我们前面所说，中台更多面临的是组织问题、人的问题，所以，做中台应该首先考虑在业务流程固化之后，再依据业务流程去设立相应的组织，最后才去做中台，即从整个业务模型导入到人，再到组织，最后才是业务状态。
另外一提，中台并不适用于每家公司的每个阶段。在独立业务拓展期、突破期，“一定用独立团、独立师、独立旅建制来做”，否则就会变成瓶颈；但发展到一定阶段，出现太多山头，就要“关停并转、要合并同类项。问管理要效率，取消重复性建设。”
比如苏宁科技的组织架构模式：在苏宁科技的组织架构中，每一个BU或是研发中心就是一个独立业务，同时它又是一个研发中心，整个业务跟研发部门有非常高度的重合：
另一个实践案例是苏宁零售的“智慧零售大脑”概念，叫做“Retail as a Service”。这么多人在谈数字化，有没有一个零售公司是有科技能力、可以赋能整个零售产业的？因此我们提出 RaaS。
大家可能不太了解苏宁现在的研发实力，比较强大，这在零售行业中也是很少见的，我们把他们聚集起来，不仅仅是工程师，更是零售专家。
单独把人工智能、大数据这些基础设施拉出来，做成一个服务；在平台在PaaS层面，我们将一些共同业务，比如会员、交易、供应链等内容单独拉出来做成一个平台。
以AI来说，有三个基础算法平台，可以让我们的算法工程师在上面开发很多应用，也让我们有80个以上的 AI 零售场景、150个 AI 技能可以调用。
同时会基于业务中台基础创建一个大数据中台，可以承载非常多SaaS应用，比如金融、物流、供应链、营销，以及基于用户的种种SaaS服务：
所以，业务中台定义应该是一个充满生命力的个体，它能够承载你整个公司的所有的业务流、逻辑，也能够把业务的数据沉淀下来以后，当你需要数据的时候，有业务数据可以用，而且这个中台应该要对企业产生业务价值。
基本上，一家企业能够做中台，都表明这家企业度过了萌芽期和初创期，处于较为成熟的阶段或高速发展的阶段。
04
业务中台怎么做？
我们说，业务中台要基于业务战略来做。
那么我们怎么样从一个战略的方向出发，再到信息化，把这整个点线，面都关联起来？
应该去思考如下的问题：
如何判断当前已有数据的价值，规划并继续深入思考数字化转型如何为企业创造价值
如何制定数据中台落地的策略和路线
如何精确评估数据中台的ROI
如何设计相应的组织架构及划分责权利
如何进行合适的技术选型，以及把握购买产品和自主研发之间的平衡
企业在遇到一些商业机会时，如果从数字化的角度，应该从两个层面来考虑，第一个是企业的战略商业机会，另外一个是技术的实用性，这两个要完整结合。首先基于企业的商业机会和战略方向去进行企业架构设计、业务活动制定，最后才导出业务中台的建设方向。
另外，业务中台是个充满生命力的个体，它承载业务逻辑、沉淀业务数据、产生业务价值，并随着业务不断发展进化。设计者也应该考虑一些原则，并且在一开始就定好这些原则，避免以后做无用功：
服务松耦合原则
面向接口实现
异步事件解耦
服务提供者位置解耦
版本松耦合
服务依赖原则
有价值的领域模型
服务间最小依赖
能力实体具有层次性
延迟对技术组件的依赖
服务设计原则
优化远程调用
去掉冗余数据
设计粗粒度的服务接口
识别并设计通用的服务接口
隔离服务内部的变化
服务接口先行
服务接口向下兼容
服务命名原则
服务颗粒度原则
服务的无状态性原则
服务操作设计原则
服务约束原则
坊间有很多专家写类似的原则，我这里不多说。
企业在做商业机会跟战略时，应该要把业务战略跟信息技术战略结合在一起。简而言之，建立战略目标与信息化支撑的关联，为战略目标的实现提供有力保证。而业务架构跟IT架构其中的重合点，就是中台成型的可能性。
这里还是以苏宁为案例：苏宁有个叫做零售云的产品，主要聚焦在县镇为主的“下沉市场”，以3C为主的消费品类，在各种惠民措施的带动下，激活了县镇消费的新势能。
苏宁零售云就是通过数字化把零售能力赋能输出，让乡镇的传统实体店店长在加盟的时候，从系统中获取成功经验和能力，以降低加盟运营的风险。这里面的做法就是结合业务中台、数据中台以及人工智能做成通用的状态，赋能对外输出：
此外，我们在谈论中台的时候可能指的是业务状态，也有可能指的是数据状态。以阿里云为例子，阿里云现在主要推的是数据中台，而不是业务状态，原因是阿里云目前没有办法满足所有的业务场景，每个产业的业务场景是不一样的。而数据能够通用，所以数据中台成了企业里面更容易推动的计划。
那什么样的情况企业需要数据中台？
数据重复开发
数据使用成本高
浪费存储与计算资源
业务数据孤岛问题严重
数据标准不统一
数据利用效率
然而，在实际运作过程中，还是有很多企业面临推动数据中台没有成功。那这里面的主要原因有什么？
数据标准建立和协调困难
数据需求多变
数据安全管理复杂
技术选型困难
数据正确性难以确定
数据权限管理
数据需求多样
数据管理复杂
数据成本高，难以量化
如果把数据中台一言说完，其实其本质就是“数据仓库+数据服务中间件。
05
去中心化
基于上述，我个人更推崇大家思考的概念，即去中心化的数据状态。
Twitter、Facebook、Airbnb等硅谷公司的做法是，大数据部门提供足够好用的工具，赋能业务部门共享数据能力。而有些公司的情况又不一样，它们将某项能力抽取出来由专门的组来负责。这个概念，其实在很多优秀的头部互联网公司都能看到了，比如国内像阿里、京东、苏宁等等。
去中心化的数据状态，跟集中式的数据状态有什么不一样？
从业务上来讲，集中式的数据状态，通常数据中台业务团队还要肩负起去梳理整个公司的业务逻辑，这对于数据团队的挑战性是非常高的。
而去中心化则不一样，数据中台业务团队主要是工具提供者，具体的开发能力会由业务部门的数据研发工程师来负责，这样的优势在于数据中台业务团队要保证整个中台的功能跟稳定性，而业务部门不仅是数据中台的使用者，同时也是贡献者。
在数据中台建设，除了传统大数据团队以外，还需要业务部门的积极参与。因为共享的数据能力是与业务相关，且开发迭代的流程需要与各个业务部门、IT部门协调沟通，所以在建设数据中台时，需要对参与人员进行统筹安排。这也是我们在数据中台规划过程中经常碰到的问题。下面列出了数据中台建设过程中一般会涉及的人员及其主要职责：
业务部门主管：深入了解业务流程和优先级，能够将业务场景与数据对应，指导建模的流程。
业务系统架构师：了解企业的系统架构、技术框架。l 业务流程工程师：对业务流程非常熟悉，通常是技术部门与业务部门的纽带。
数据平台工程师：通常有系统工程师背景，负责建设和运维数据平台，安装和运维各种大数据组件，以及保证数据平台的性能和稳定性。
数据开发工程师：以数据仓库技能为背景，懂业务，负责建模、数据清洗和编写ETL程序。
数据应用开发工程师：以应用开发为背景，开发服务于业务部门的数据应用。
数据中台架构师：全面掌握数据平台的功能，对公司的产品提出数据的支持和要求，负责公司产品与数据平台的集成、与业务系统进行衔接的架构规划以及公司的数据标准推动和把控。
数据分析师：以统计学背景为主，能够从数据中产生合理、准确的商业智能报表。
数据科学家：以机器学习为背景，提供基于机器学习和人工智能的数据分析产品和结果。
数据产品经理：负责公司内部数据能力的规划和开发流程的协调，有时这个角色由数据架构师承担。
数据中台业务团队主导技术制定、业务部门共同研发应用层，这个优势在很多头部企业的核心能力上都已经得到了体现。
总而言之，我们做业务中台，需要从设计开始就思考业务状态，一个成功的业务状态，应该第一天开始就设计一些原则，这个原则有助于业务中台在后面发展的时候不至于走偏，有一个基准的方向可以遵守。
如果要评估中台需要花多钱，这是很多人都会问我的问题，我一般有三个维度可以介绍给大家，大家可以从这三个维度来回答这个问题：
01
依照实际需求进行估算，以大润发为例，可导入严谨的研发流程。
简单来说，企业一定要界定完自己的需求是什么，才好进入到研发，否则可能导致的是项目需求变更，预算增加等等风险。
这个维度就是让大家好好思考中台的真正需求在哪里。而严谨且高效的研发流程，可以透过人天来评估成本。
优点：依据企业发展具体需求而定，能充分说明做一个中台实际上需要多少成本。
02
依照年度IT预算来测算，以年收入百亿的公司来估算。
我们来算一笔帐，假设一个年收入百亿的公司，企业的净利润为一个亿，年度IT预算一般落在2-7%，假设这个企业是一个重视数字化建设的企业，其IT预算高达7%。等于是把百亿收入的7%，也就是700万投入在年度的数字化项目中，而中台又是当年的重点项目，占了30%的预算，那中台预算的30%，即是210万。
但问题来了，若以210万来说，中台只能外包，且由于预算问题，失败率较高。毕竟这是一个百亿收入的成长型企业，所以估计要做些适度的调整，不能全盘按照这个维度来制定计划，但这个维度的评估方法有一定的参考价值。
优点：依据企业发展具体需求而定，能充分说明作一个中台实际上需要多少成本。
03
依照过往经验，并结合企业现况，预估一个自研的数据中台所需成本。
在数据中台的建设中，除了传统的大数据团队以外，还需要业务部门的积极参与。
这张图，就是依据实际的情况，去算出成本应该要多少。结果算出来，可能预估每年8000万支出，假设以平均工资40万计算，一年约需要4200万的人工支出，加上硬件与运维费用，约莫8000万。
优点：依据过往经验评估判断，有一定的参考价值。
最后提醒一点，数据中台建起来困难，维护起来更困难。
最后，回归到CIO对于建设数字中台的需求方面，我的建议是：
更合理的估算，将数字化纳入战略规划沟通
依据数字化的投入产出及可能的带来的价值进行充分的研究与分析
取得董事会成员及高层的共识
最终依据实际需求评估投入实施
召开会议对项目进行总结
为什么会做这个分享，是因为太多朋友问我中台的建设问题，因此系统性的做一次分享。最后，不论是数字化，还是中台的问题，都欢迎各位与我交流，王俊杰个人微信号jawinjawin。
1、苏宁数字员工：在人力资源体系部署RPA
2、如何在配送履约环节，做到极致优化？
5、“到家业务”如何从线下拉流量盘活用户？
扫码关注公众号
阅读更多报告文章
点击在看，好报告要分享哦~
1547
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
