不过，现实情况，或许与绝大多数人想象不太一样，中台的产生，并非完全是自顶向下的战略设计，也并非是为了追随某种行业风口，而是随着公司业务高速发展、组织不断膨胀的过程中暴露的种种问题需要被解决。而这时，中台的概念恰好对应了这个问题，所以大家接受了中台。
过去几年中，借着移动互联网的红利，许多公司都高速发展，进行大规模业务拓展，业务拓展的速度足够快，对公司自然是好事，但是随着而来的问题就是，公司内部出现了大量的重复建设和资源浪费的现象。
阿里的共享服务部发展历程就是如此。
公司刚开始只有淘宝，后来意识到B2C模式的业务也会是电商领域重要的组成部门，所以出现了天猫，随着天猫的不断发展，逐渐独立成一个部门，但是这两套都包含订单、商品、库存、价格、仓储、物流等基本业务系统。这两个系统互相独立，各自运行。
等到 10 年左右，阿里开始上线1688、聚划算等业务的时候发现，这些业务针对的领域虽然各不相同，但是他需要用到的系统功能也高度类似，主要也是订单、商品、库存、价格、仓储、物流等系统。如果这些新业务的系统也都要全部重新开发一遍，这无疑是很大的资源浪费。明明既有的系统调整一下就可以满足新业务的需求，为什么还要继续开发新系统呐?
在这个大的背景之下，阿里内部将共享服务部的职权不断提升，统一将各个业务业务部门重复使用，反复建设的功能和系统统一规划和管理。
△ 阿里供应链中台/图源网络
其实，很多公司的中台部门，或者平台业务部门的出现都有类似的背景和情况。
比如说，滴滴在 15 年末开始启动自己的中台战略，这与滴滴当时的业务发展阶段也是相关的。
2015 年末，滴滴在短时间内形成了包括快车、出租车、专车、顺风车、代驾等多业务的垂直化架构。
这些业务虽然会有一些差别，但是核心系统和流程都是类似的。如果各自独立开发，也会出现各种各样的问题。
比如说，开发成本过高，滴滴旗下的每个业务，其实都是可以单独支撑起一家公司的，如果每个业务都独立做到极致，那么开发成本和人力成本就会非常巨大，而如果为了控制成本，就把系统的建设放缓，则意味着，无论是核心系统本身的质量，还是对外的用户体验都不太好。
在这样的背景下，滴滴也开始考虑将诸多业务，以及各个城市的系统统一规划，统一建设，提升服务前台的能力。
