CIO • 智囊团 | 由“阿里拆中台”思考企业的中台建设之路

国科恒泰CIO 罗骅

企业建中台项目是个系统工程，也不仅仅是个IT的概念，需要结合企业数字化转型的整体规划要求进行规划设计，企业数字化转型是个企业战略的事情，中台建设是支撑这个战略落地的其中一个重要手段，我们对中台的理解是：

从中台的模式来看，建设中台之初，首先需要去梳理和聚合基于未来业务场景的服务能力单元，提炼共性的服务能力支撑未来的业务发展。所以对于中台项目来说，是一个需要充分结合企业发展战略，从上至下的顶层设计思维和体系化的系统工程，是涉及到企业各部门的一把手工程，而非简单的一个技术平台。

从中台的属性来看，企业中台一定是一个行业或者领域的能力沉淀，因此中台一定会具备有行业特点和属性，代表对某个行业或领域的可重用能力，可以快速支撑企业应对市场的业务场景落地，实现组合式创新的目标。对于阿里“拆中台”的做法，我个人持认同的观点，由于阿里是一个多业态的企业，以一个中台去支持所有业态是不现实的，所以阿里希望将中台做薄，更注重前端的行业属性无疑是一个更好的选择。

就我所在企业来讲，我们的中台建设分两个部分，一部分是针对内部业务中台及数据中台建设。由于目前的架构是以ERP为中心的传统架构，稳定运行很多年了，虽然存在很多业务灵活性应对的痛点，但由于集成关系复杂，各系统逻辑相关性强，要全部推翻重来的难度和风险都很大。因此，我们采取的是相对保守的方式，依据中台建设的思路，用微服务架构针对核心业务场景和痛点问题，以小步快跑的方式进行建设。而另一部分，是针对企业建设的产业互联网平台项目，产业生态圈的数字化战略布局，我们全面采用了前中后台架构进行了规划建设，由于是全新的架构和建设内容，因此不存在对旧模式的改造，风险小成功率高。我们希望将医疗行业中遇到的共性问题与能力，沉淀到中台上，满足不同业务场景的需要，最终结合自身的能力和经验，打造出一个医疗行业的产业中台，为行业的合作伙伴提供数字化服务。

关于中台于业务创新领域的作用，在我看来中台是很难有颠覆式创新能力的，阿里的做法源于其本身实力雄厚，具备高素质人才和充足的资金，同时有扎实的行业沉淀。但对于一般企业来说，通过中台进行能力的组合式创新是最佳的选择。

想要提升中台的效率，离不开时间的积累和沉淀，当积累和沉淀达到一定程度以后，随着成熟度的提升，中台的敏捷性和效率也会提升。而且中台前期建设的质量越高，对于敏捷性和效率也越有利。总体来说，中台是个很好的概念，也是一个很好的建设思路，但每个企业的实际情况不同，所以我认为企业要从自身的实际情况出发，来进行中台的建设。比较重要的一点是中台的建设一定是一个“一把手工程”，要求一把手要作为真正的数字化转型的主力军和牵头人，从战略层面、市场层面、公司变革、创新层面有决心和信心支持IT部门做好这件事，只有这样，中台的建设才有可能取得成功。

因此，我们的中台没有豪横的颠覆性规划设计，有的只是从一个业务场景或业务痛点的切入，迈出落实中台概念的一小步。古人云“积土成山，风雨兴焉，积水成渊，蛟龙兴焉”，我们相信从小的业务场景积累和沉淀，不断演进迭代，最终能构成自身特点的企业核心中台。

前百果园高级副总裁 王戈钧

想要了解中台，首先要明确中台产生的背景。随着市场的发展，市场竞争愈发激烈，因此很多企业采取了全渠道营销的策略，以应对市场带来的挑战。此外营销模式也发生了巨大的变化，在销售的过程中，由于渠道并不是单一的，某个时间数据以及订单甚至会呈n倍的增长。从消费者角度来看，当下的消费行为也呈现出多样性的特征。在这样的大背景下，传统的ERP、CRM系统无法支撑企业的发展，企业需要一个更加灵活的支撑——多渠道、多并发、多营销模式的平台。该平台要将商品结构、库存内容等信息都需要集中起来进行管理，实现在同一库存管理下，能够对多个渠道进行整合，因此中台应运而生。

一般来说会有两种中台建设的模式，一种是使用微服务化的结构自主搭建的中台，这类中台具备非常好的灵活性，能够有效满足企业业务形态的特殊性，但人力物力成本较高；第二种是像阿里巴巴一样利用模块化建设中台，以套装工具为基础，通过轻量化代码建设中台系统。这类中台相对灵活性与适应性较差，但是成本较低。二者有所不同。

客观来说，中台能够有效帮助企业解决应用场景和业务中的问题，但是在中台的使用过程中往往会出现大量的误差数据。针对这个问题，首先企业应当尝试去打造轻量化的中台，其次要保证部分结构的准确性，最后一定要考量计算引擎的能力，保证算力能够支撑企业的业务。这样才能尽可能降低误差带来的影响。

从中台自身来讲，并不能直接带来企业业绩的提升，但是对于业绩的管理和结构平台的优化能够起到很好的效果。阿里拆中台一定有其原因，我判断可能是因为数据不准，因为阿里的数据量更加庞大、结构性高频更多，因此在将结构产品进行一体化的时候，往往在会员管理等其他方面就会出现多种问题。而且阿里一部分数据在云端，还有部分数据在自己固有的服务器上，渠道结构的不同也导致了数据链的差异，因此“拆中台”是一个必然的动作。

中台的效率与场景有很大关系。如果业务场景和结构在一开始就不是以共享为前提，那这样的中台是没有意义的。因此，要提升中台的效率，首先要保证其实现共享，统一管控。对于正在建设中台的企业，我建议企业可以建设微中台，将企业结构链做成几个动态结构。其次从主数据入手，将企业中的一套主数据做好，而不是通篇进行中台的建设。总的来说，中台的建设不在于做多，而在于做好。如果目前企业的体量不大，是没有必要上中台的，可以进行轻量化的云端运作。中台并不是一个神话，没必要盲目上中台。

目前来看，受到科技等多种条件的限制，中台的发展还有局限，但是随着技术的不断改进、计算引擎的不断优化，算力的不断提升，可能未来中台的建设就不是难事了。

中台虽然不是阿里首创，但阿里是中台最大推手。现在阿里又要把自己推的东西“拆”掉，是否在打自己的脸，确实引发业内热议。其实阿里并没有彻底拆中台，而是把中台变薄，变得敏捷和快速。

要理解阿里为什么现在这样做，要从中台的建设谈起。我们建中台，往往是通过抽象共性，把企业的核心业务能力打造成共享能力和服务，整合后台资源，更好的支持对前端业务的服务和快速响应需要。这个变化对传统企业来说，要做这个改造将涉及组织的大调整，业务分工的重组，流程再造。这个是中台建设最难的部分，弄不好公司的业务管理将乱作一团。对系统建设来说，要将原来单业务线的系统拆解，再把通用的部分微服化、原子化改造。但现实是商品化的系统，很少可以支持微服化改造的，只能替代原有系统，当然这面临着原有的业务逻辑在新系统要重新实现，而且这个投入不会产生任何新的价值，弄不好系统切换的时候还会出很多问题。这是中台建设过程中，技术会面临的最大难题。受限于未来业务发展存在诸多的不可预测性，中台规划时，对业务的抽象也会存在局限性。就是因为这个不可避免的局限性，决定了中台本身的有限适用性。

综上分析，我觉得中台的适用性存在上下限。中台的下限：只有存在多种业务管理形式，或多种管理渠道，在资源上存在重复投入，有统一管理的趋势，而且有较强业务创新的要求。如果当前和未来的业务都不存在上述的情况，没有中台化的必要性（数据中台除外，其实数据中台更适合叫数据中心，是数据资产的统一管理和运营的手段）。中台的上限：更适合管理业务、管理模式比较相近，或共享大量资源的业务综合体。这种情况下中台的投入产出比最高。业态复杂的组织，可以建多个中台。所以大家不要被标题党、被概念族所误导。中台不是不行了，也不是不支持创新，正相反，阿里中台孵化出“盒马鲜生”这样的现象级产品，如果没有中台，不可能半年打造出一整套线上线下新零售系统。但一个中台价值最佳体现的适用业务场景需要有个范围设限，超出这个范围，对业务创新和灵活支撑，以及投入产出比，都会快速下降。 

对于计划上中台或正在进行中的组织来说，如果阿里的行为使你有犹豫的，你可以对照上面的分析，结合所在的组织的复杂度可以再做些评估。如果评估后适合建中台的企业，在建设的过程中有如下几个建议：

1. 中台的建设，是至上而下，从组织到业务再到系统，必须是一把手工程，否则业务和组织上没有中台化，只是系统中台化意义不大；

2. 中台建设过程中的业务和技术的原子化拆解要做得越细越好，对未来灵活的流程变革和局部创新支持越好；但也要考虑当前的中台不兼容的情况下，架构上和流程上如何支持差异化定制也很重要，否则会束缚业务创新；

3. 要联合外部服务商擅于建设中台，引入成功的中台建设经验，但建中台的过程中，必须要有自己未来接管运维中台的技术团队，如果完全依赖外部，响应的及时性和自主性会受限。

从技术角度考虑，中台建设的好，将完全解放现有系统对业务创新的束缚，使技术团队有机会更深入的参与业务和管理创新，但对技术团队中台运维能力的要求，也会提出极大挑战，如果没有一定能级的研发实力，要量力而行。