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