中台这一概念，在近几年在国内大热，不少企业接连开始组织架构的调整，意图建设中台。但建设中台，并非这么容易，可能投了不少钱，最后也没有什么水花，那么中台为什么难做？作者在这篇文章中给出了解答，一起来看看吧。

01 中台到底是什么？

狭义上来讲：我们知道前台是一个个面向用户的可视化操作界面。

后台是包含代码、中间件、数据库等一系列框架代码集。

后台搭建完，前台就会展现出来，一个闭环就形成了。

那什么是中台？顾名思义中台其实就是在夹在前台和后台之间的一个东西。

那为啥前后台已经能形成闭环了还需要中台？

大家一定听过一个被讲了很多次的故事：阿里在发展业务的过程中发现，随着业务线的快速增加，一开始只有一个1688，后来出现了淘宝、阿里妈妈、支付宝、咸鱼、口碑等等大量的内部项目。

每个项目都需要开发一个所谓的前后台闭环，阿里内部100个业务，就得搞至少100个闭环，1个闭环算他50个人的开发测试团队，大业务线还不止，就得5000个员工，这在以人员成本为最大成本的互联网公司，简直是要命。

当然成本还不是最关键的，最关键的是效率，在互联网快速发展的阶段，效率是生命线，你比别人上线晚、迭代晚，可能就玩不过人家了。

所以只能拼命堆人做，与时间赛跑。

虽然这个思路是对的，但是抵不过几个问题啊：

1. 那会很多项目都是通过市场测出来能不能成的，失败率很高，很可能跑不出来，这样这个团队怎么办，调到其他部门？流动性太高，团队成本也打水漂了
2. 很多项目的重复性很高，其中的很多模块都可以通用，每次都重新做一遍成本太高了
3. 如果每次都要从0开发，哪怕堆人搞，其实响应效率也很低，一般一个从0启动的项目打底1个月起上线

于是马云大腿一拍，搞中台，中台能全部解决上面的问题，还能大大降低成本。

怎么搞呢？

就是把一些通用性很高的模块，抽出来，作为公共库的一个个“能力”，然后A业务需要这个了，来拿一下直接用，B业务需要那个了，来拿一下直接用。

大家一定会说，很像开放平台啊！对，本质上其实就是个对内的开放平台。

于是每个新业务就不需要那么多研发人员了，通用的模块就不用重新开发了，在既有的中台能力库上做功能，对业务的响应效率也会高出一个层次。

这么一想，中台简直是一个大杀器啊！

于是阿里就大刀阔斧的开始搞中台建设，花了几年时间，终于陆续建成了。

这期间，随着阿里的如日中天，江湖上吹中台的声音到处都是，管他大公司、小公司、做业务、还是做平台，做全品类，还是做垂直，都是在鼓吹应该要做中台。

不少公司投入了好多钱，也没做出个什么水花来。甚至阻力重重，推到一半就推不下去了。

然而后来阿里又亲自“推倒”了自己的中台计划，把中台的服务能力拆分的更小。

一时间唱衰中台的声音又此起彼伏。

02 中台为什么难做？

归根到底，看似预期很强大的中台建设，存在以下巨大的难点。

1、中台对人的要求太高

搭建中台的产品技术，必须高度了解业务，你想业务A的人只要了解业务A，业务B的人只要了解业务B，中台的人既得了解业务A，也得了解业务B，100条业务线，得了解100条，甚至他要比A更懂A，不然咋抽象对吧

这其中涉及到多个环节：

1）看的准？

你得看的准这个业务是怎么在跑得，他的核心流程是怎么样的，他的功能模块有哪些、具体包含了哪些功能？其中哪些模块适合被抽出来？

随便举个例子，很多东西都会伪装，都会变种，举个最简单的例子，一个盲盒功能，你觉得这个盲盒是什么东西？不会真抽象一个叫盲盒的能力吧？那你就完蛋了

过两天来了一个大转盘需求，你去资源池里找了一圈，发现刚做的盲盒能力根本用不了？？

算了，再做一个大转盘吧。

看到这里，大部分小伙伴已经看出来了，盲盒本质上不就是抽奖么，这两个理应是“一样的东西”，大盘转的需求，“盲盒”的能力理应能被使用啊。

本质上它们都等同于“抽奖”。

2）抽的对？

看准后，就要抽的对，抽的对包含几层意思。

i、边界清晰

边界清晰有多重要？不清，是要命的！直接决定了中台的失败。

你到底抽到什么程度？

还是盲盒的例子，盲盒活动的整个业务链路，涉及到了用户、支付、订单、抽奖。

你难道把这些都抽出来了？还是只抽抽奖那部分？

抽的太多，中台就太厚，你让业务干嘛；抽的太少，中台就太薄，失去了意义。

ii、模块的能力合理拆分

既然我们觉得把抽奖 抽出来，那么抽出来，怎么变成一种可灵活调用的能力？

如果拆的好，那么能满足很多额外的场景需求。

哪天来了个新需求是：直接积分兑换奖品。

用抽奖其实是可以满足的，比如你把抽奖分成3块：【抽奖资金获取抽奖资格】、【抽奖核心算法】、【中奖后用中奖券兑换奖品】

那么积分兑换奖品，是不是就可以使用3）的能力？

积分和中奖券，本质上都属于一种虚拟资产，是不是能力就通用了？

iii、如何权衡

中台也面临需求越来越复杂的情况，比如抽奖的时候直接开奖，也有抽奖后某一时间一起开奖；比如算法策略是大家一起开奖，还是部分用户可以优先开奖；比如是必中，还是可不中等等。

这些多样性，在业务的发展中一定会越来越复杂。

和普通产品迭代一样，中台也得不断强化和迭代能力，不然就满足不了业务需求了。

就好比你做了可以直接开奖的能力，结果另一条业务线抛过来一个一起开奖的需求，完犊子了，又满足不了。

所以和普通的业务迭代一样，中台的需求，也面临大量决策问题。

依然需要有效甄别真需求，还是伪需求，需求优先级怎么样，重要或是紧急，最后判断出来该不该做，怎么做，什么时候做，做了价值大不大等等。

2、中台的协同成本很高

中台的协同成本高，这个很好理解，毕竟原来只要前台和后台配合就能完成的事，硬生生的插了一层，变成了3方配合才能完成，难度直接增加50%。配合开发难度PLUS，相应的迭代和找问题的难度也PLUS了

尤其是中台搭建初期能力还不完善的时候，人家根本不想用你，但又碍于公司战略，不得不用你。就变成了一种非市场机制下被迫的行为。

所以中台早期是很难的，中台人也是比较惨的，因为他必须要服务好每个业务线的前后台团队 ，而不是单一的一个需求方。

这种协同复杂度，是几何级的上升，我给你们举个例子：

还是拿抽奖，比如A需要有一起开奖的需要，B要算法是随机中奖算法，C要必中。

而且大家都很急，要求尽快上线，A要求5天后，B要求7天，C要求8天内给到。

这个时候，不单单是判断需求应该先做什么，怎么做的问题了？

还面临着复杂的项目管理问题，资源怎么安排，来保证ABC三方都能满意，结果开发一评估，发现A能在5日内给到，B、C怎么赶时间都不能在7、8天内给到。

于是吭哧吭哧去找B、C商量，能不能缓一缓，结果BC不同意，于是只能考虑优先排BC的需求，再找A去商量，想把A的需求后置，A当然不同意啊，凭什么我要给BC让路，噼里啪啦一顿沟通……大家都不妥协，于是只能向上反馈，要更多的资源。

这其中，也有因为协调不好，有些业务线撇开中台，自己去做了，因为等着误了业务发展，业务始终是第一考虑。

这只是其中一个很小的场景，解决方式也只是举了一个例子，但是管中窥豹，可以看出中台在服务多业务线的过程中，所面临的巨大协作成本和难度。

中台从广义上来讲：从业务中来，又到业务中去。

做的好的中台对业务一定是有帮助的，但确实因为其难度很大，真正做的好的公司少之又少。