中台一词很火，很多人一看可能觉得新瓶装旧酒，又卖概念。
我认为中台不是营销噱头，也不是技术专业词，大可不带偏见地去看它，更不要神化它。
一、什么是中台
讲到中台，一定要定义清楚什么是中台。由于中台的“始作俑者”没有给它很好的定义，以至于很多人对它的定义各不相同，自然也就有了各种不同的见解。到头来发现不是自己想的那么一回事，就唱衰中台啥也不是。
首先想一下什么是中台？
- 从产品来看，Thoughtworks王健总结到位——企业及能力复用平台。中台是快速响应前端业务的能力中心。
- 从技术来看，中台是前端需求快速变化与后端能力加强稳定之间的缓冲带。
- 从业务来看，中台是将前台的灵活业务和后台的成熟能力连接起来。
- 从管理来看，中台是盈利中心和成本中心的平衡。
可以看出，中台不只是简单的将系统共性部分抽象出来，中台是要区别于前后台而言的。那么定义中台前就先定义前台后台是什么，然而前台后台在不同维度看，也有不同的定义。
其实中台在业务中由来已久，看下当年IBM对银行业务的分析总结：
银行前台：前台是经营体系，经营体系是面向客户的，以客户为中心的。 前台是负责业务拓展的、直接面对客户的部门和人员，为客户提供一站式、全方位的服务。 作为银行的客户，常常接触到的柜员、客户经理、大堂经理，都是前台岗位。
银行中台：中台是通过分析宏观市场环境和内部资源的情况，制定各项业务发展政策和策略，为前台提供专业性的管理和指导，并进行风险控制。 中台往往包括风险管理（信贷管理）、计划财务、产品开发、渠道管理、人力资源管理、战略规划等职能。
银行后台：后台主要是业务和交易的处理和支持，以及共享服务，包括会计处理、IT支持、呼叫中心等，集中处理贷款审批的中心也可以纳入后台范畴。 后台，就是银行支持和支援部门。后台作业的集中和服务的共享是国际上的趋势。 https://wenku.baidu.com/view/79b30c74f46527d3240ce065.html 《商业银行流程再造中的误区》
在业务中，前台业务拓展，中台业务管理，后台业务支撑，跟现在中台很像了。这种模式，早在2012年国内银行推广“流程银行”改造，当时有这种概念，但还未被发散到其他业务。直到2015年中台被提出（笔者猜测“中台”是阿里做银行时从银行业务和模式带过来的词），大家才开始在IT领域探索实践之。
我尝试更抽象地对中台做个定义：中台是一个平衡的单元，处于前台与后台之间，介于动与静之间的半稳态单元。（换句话说，当中台稳定下来时，中台已死。）这个半稳态单元，向稳态的后台能力输入“编译后”的前台诉求，向动态的前台需求输出“业务化”的后台能力。
二、中台的应用
很多关于中台应用的故事，是从一家游戏公司开始的，然后才是一家电商公司。
Supercell把游戏所用到的系统，一个个做成可复用的模式。当新做一款游戏时，结合策划的游戏玩法，从“仓库”拿出系统来搭建游戏架构（未有部分则补充新做），制作终端界面，大大加快游戏研发过程。当这款游戏在市场的表现不如期望，直接关停推倒，投入的资源迅速迁移到其他下一款游戏中继续试验，直到成功。
这种模式主要解决的是在技术上复用系统，大大节省重复开发相似系统的成本。我定义这种模式为中台1.0。
阿里巴巴集团旗下，有阿里巴巴、淘宝、天猫、聚划算等等平台产品，他们共同点都是电商业务，都需要做商城、商品管理、库存管理、营销管理、订单管理等等系统或模块。按照中台1.0的启发，既然有共性系统，那能不能做一套系统然后各自复用呢？这样除了节省大量成本，更是加速电商平台的经营和灵活化企业组织的管理。
合久必分分久必合，阿里内部形成商品中心、订单中心等中心能力服务。不管你是什么平台的业务数据，最终归集到同一个业务中心，在业务上集合专业的力量提供服务。
这里发生了一点变化：“复用能力”从技术到业务转移，本来分开的同类业务系统合并为一个业务中心。
对外输出为业务中台甚至数据中台等等。我定义这种模式为中台2.0。
中台的特点
稍稍总结一下中台的特点。
中台1.0：技术组件化，组件复用，快速搭建，快速试验，组织灵活调整
中台2.0：业务组件化，业务能力复用，数据中台
抽象一下，中台的特点包括：通用组件，可复用，可共用，可扩展。
中台的作用
基于以上特点，中台可以为企业带来这些作用：
1、减少重复投入，降低边际成本
2、快速响应市场，避免对内冲击
3、精细化管理，专业化培养
4、业务变革，组织变革
5、拓展盈利中心，固化成本中心
三、中台的局限性
故事仍在继续，很多企业听了这些故事，意识到中台带来的效益，都不愿落后希望拥有自己的中台。但企业适不适合用中台呢？很多企业被一些软件提供商忽悠，花了很多钱搞了很久，但没达到期望的效益，这主要是没搞清楚中台的适用条件。
从前面中台的应用中，也能看到中台的适用条件，并稍稍感受中台带来的变革冲击。企业在选择中台前必须了解适用条件和带来的冲击，才判断自己是否适合做中台。
中台的适用条件
怎么样的企业适合做中台呢？其实这与企业规模无关，应该要回归到企业的业务，结合中台的特点和作用来分析。
1、企业有高代价的重复投入
可以看到无论中台1.0、中台2.0，都因为某些东西重复了，而且重复的代价很大，借助中台让重复的成本得到了释放。因此企业若想引入中台，要先看自己有哪些高代价的重复投入，可能系统也可能业务。
举个例子，一家酒店集团通过自创和收购等运作，旗下拥有了很多酒店品牌。但各个品牌用不同的酒店管理系统，开发维护成本很大，这就是重复投入。倘若各个品牌独立经营，并且系统维护成本占经营收益比例很小，这还不必要做中台，毕竟做中台也需要不小的代价。
当各个品牌在系统维护成本比例较大，或者随着独立经营导致集团在整体品牌和体验方面得不到提升，那就有必要规范酒店管理体系，提升酒店集团一致的品牌形象和体验价值，同时提升经营效率和降低整体成本。在这时企业才需要考虑做中台。
因此这个适用条件需同时满足两点：重复投入，重复投入带来的代价很大。
2、有平台化发展的规划
从中台1.0、中台2.0看到，中台要应对多个或多种前台的动态业务，那就需要具有平台特性。平台和单业务的区别在于，前者重视的是不同业务的共性和业务间的平衡，相比单业务，具有更高的价值和更广的适应性。
以前面酒店集团的例子看，旗下某品牌是针对商旅的酒店，为出差人士提供了多渠道房源、一分钟订房、房源保留整晚、车机接送、快速发票等服务，在房间内还有自动擦鞋、按摩椅、以及为出门见客准备的全身360度镜子等等。这样的垂直业务做的很精细，链条很全，体验很好，在未来可见的发展期暂未有平台化的规划。这样的品牌自身暂时并不需要中台，而集团即便需要中台，也可能会考虑不将此品牌纳入范围内。
随着集团收购其他商旅酒店，希望基于商旅酒店品牌建立商旅平台，涵盖出行、酒店、会客、活动、宴会等业务，并且这些业务独立于酒店集团的其他业务开展。这时就可以考虑引进中台，让商旅服务同时面向不同业务的需求，提供稳定的预订、履约、执行、发票等商旅服务。
因此企业要考虑当某项业务升级平台化，才具备“复制”的需要，才有考虑中台的需要。
3、能接受变革的冲击
从中台1.0、中台2.0页可以看到，做完中台之后，组织关系也发生了变化。这除了做项目需要捆绑业务绩效外，更重要的是当形成中台后，业务分工发生了变化，自然带来组织和绩效的变化。
还是以酒店集团的例子。由于不同品牌的经营是差异化的，因此其职能分工和组织安排都有差别，不能硬性推行一套系统就了事。由于统一了管理系统，各个品牌原来的技术团队都收归了集团总部；原来各个品牌各管各的订单，现在变成统一的订单团队管理来自不同品牌的订单。除了把人员按链条上的业务单元进行调整外，一下子扎堆了这么多技术团队必然也会做出优化。
另一方面，原来有的品牌安排了营销和市场投放人员有的品牌却没有。在规范管理体系时后，集团重新考虑营销和市场投放的业务安排，根据投产比最后去掉了市场投放只保留营销。而原来没有做营销的品牌，现在也要启动这一业务。这些业务变革，对有些品牌有利，但也对有的品牌带来冲击，很多利益相关方也会随变革流失。
因此引入中台前，企业要考虑清楚组织调整和进行业务变革，如果不能接受这个冲击，就很难发挥中台的价值。
中台的代价
中台既然能为企业释放低效成本，并提升业务效益，但与之相应，做中台的代价也不小。下面讲讲中台有多大代价。
1、业务变革与组织变革
从上面的应用和案例可以看出，中台在改变原来业务关系的过程中，随之而来绩效和组织变革。原来各管各的时候看菜吃饭，有多少收益就安排多少人，而且一般是一人多岗。在全集团统筹业务后打破了这个关系，管订单的，不是简单将所有订单管理的人拉一起，而是需要原来的一半，负责全部订单的维护和履约跟踪。这样一调整，就需要安排订单中心及其负责人，绩效对全集团订单负责。其他模块也类似进行了变革，无论做得好不好，都会呼啦一下，洗走一大波人。
2、中台落地周期与风险
中台变革是体系化的，涉及很多业务的调整，相应的IT系统需要重新研发或兼容更新，有大量的技术实施工作，需要很多技术人员花很长时间做方案，各种评审，开发实施，数据切换，业务验证等等工作，这些工作投入人力大，周期长。很多业务甚至颠覆性地重做，一年半年才能完全落地。而在落地过程中，技术水平和成员流动性带来质量和交期的风险。这个时期很不稳定，各方面的责任人心都是悬着的，生怕其中一环断掉带来连环效应。
3、中台成本高
从前面两点就能看得出，做中台需要投入很多人力、时间实施，以及实施后带来的业务重塑和组织团队重建，整体投入的成本非常高。一般来说，中台的投入换算为人民币的话，都是数以千万的。
因此企业要进行中台变革，必须慎重衡量业务长远价值、适用条件与中台的代价，毕竟考虑到业务和组织的变革，损失了钱事小，万一破坏了原来稳定的业务后，要重建就相当艰难。
四、中台的未来
前面讲了两代中台的特点，如果把两代中台抽象来看：
- 中台1.0，一次开发的技术组件重用在多个技术系统中。重用的是技术组件。
- 中台2.0，一次开发的业务组件及业务能力覆盖多个同类业务。重用的是业务组件及业务。
那么中台3.0应该走向何方？Salesforce给我带来启发。
中台2.0将重复投入的同类业务进行了融合，多个同类业务可共用一套服务体系，大大减少了在技术上的投入。但仍需投入资源去开发和维护这套被共用的体系，而且为了兼顾共性和个性，对技术的要求更高。
因此对中台3.0的第一个思考方向，就是连技术投入都不需要。业务人员根据业务需要，拿着技术组件和业务组件，通过像堆积木一样的方式，搭建出一个个“业务系统”，这种中台被称为aPaaS（应用平台服务）或SaaS加速器，即面向业务应用的搭建平台。
这种虽然业务人员即可操作，但是为了更好开展业务，业务人员需要对背后的数据逻辑有一定的了解，才能让各个积木连通起来。
对中台3.0的第二个思考方向，就是连搭建都不需要，直面向业务团队提供现成的业务组件，仅需进行一些业务化的配置，即可直接拿来用。这种既不是标准的SaaS，又不是需要搭建的PaaS，可以看作是提供了很多定制点配置的SaaS。这要求业务人员专注在业务，不需关心技术实现和数据逻辑。这也似乎更符合用户对体验觉醒的要求，以及业务精细化的趋势。
我认为中台3.0，必定是跟着业务跑，但不需跟得太紧，而是通过扩展能力，不断丰富定制配置的SaaS。
五、关于中台思维启发
至今大家仍在探索和实践中台，但很少人将它继续抽象和发散，因而在与别人交流中台时，最常听到的是中台架构、技术架构、微服务、重复造轮子等技术领域的描述。随着各种实践落地，大家对中台的理解应从技术工程思维抽象出来形成面向业务、技术通用的业务架构思维，并且贯穿业务架构和技术架构来实现业务和组织的变革。
1、多元的合作
在传统IT架构中，很多系统是烟囱式构建，从数据、存储底层，到系统基础保障，到系统核心业务逻辑，再到终端用户的业务应用，深扎进去似乎一气呵成，但每个系统如此构建，难以维护和重构，也就难以得到发展。而且也使得每一个烟囱都难以跟其他烟囱连接起来，建立业务关联。
中台的模式为这中结构带来突破，原来每个系统单独建设的每个层次，都可以根据需要共建共用，从底层就实现平台式的打通，到业务层逐渐个性化面向终端业务。除了底层的融通，很多上层的业务也可以互通，实现塔桥模式，让业务之间产生多元的碰撞和合作，给业务带来更多发展的可能。多元碰撞能极大提升单体的效能。正如世界从多个独立体走向联盟，超越两个单体的能力形成1+1＞2的效益。
2、组合化思想
在多元合作的基础上，结合组合化思想做发展，就能更好的延伸单体的价值。在个人成长方面，以前我们总以为全才的人才算优秀，结果十几年下来会发现，世间全才如达芬奇特斯拉少之又少，而常见的优秀大多是某一方面的专家。而所谓的“全才”实际上是什么都懂但什么都不精，就像产品经理，普通不过。而事实上，将不同领域的专家组合起来互补长短，能给社会带来更大的进步。
可以感知到，中台架构在物理层面上首先是一个个独立提供服务的组件。通过组件化的设计，让每一个服务犹如一块积木，拥有自己的专长，再通过组合共同支撑前台的业务。组合化思想也是做产品的思想，不要想着要做一个多完美多强大的产品，而是尝试将产品在自己一个细分领域上做专业，然后提供扩展组合的能力与其他同样优秀的产品进行组合。就像不同乐高积木之间的组合能搭建出不同的物件，在不同产品的组合过程中，也能带来美妙的共鸣。
3、半稳态
灵明无着，物来顺应。“世界上不变的东西是变”，所以我们要“拥抱变化”，在不断改变的世界中不断调整自身去适应这个变化。相信很多人都听过类似的话，这其实也就是半稳态，也叫反脆弱性。中台还给我们能带来这种反脆弱的启发。
一方面，中台提供的专业能力是比较稳定的，而相比趋于稳定健壮的后台，中台又显得要灵活。另一方面，中台不断巩固多种专业能力的储备，又要快速响应前台快速变化的业务。这就不得不处于一个半稳态。中台的半稳态，不是说什么都有但什么都不专业，恰好相反是通过长期储备将很多相对专业的能力沉淀下来，然后在响应时通过一个灵活的分发组合机制将多个专业能力组合起来提供能力和价值。
写在最后
本人热衷于中台的学习和布道，但碍于知识阅历尚浅，还不能非常深入浅出把中台说简单。希望有更多热爱中台的人交流，让我不断优化完善思考。
声明：上文除引用外均原创内容，发布于语雀。如有引用，请提前交流。
若有收获，就点个赞吧
0 人点赞
