写这篇文章不是为了博眼球，阿里虽然“创造”了中台这个概念并且在内部广泛地实践，对外更是以专家的姿态“指点江山”，但当我们细细推敲时就会发现中台难，阿里的中台更难。

大家也许觉得我想说阿里拆中台的事并以此论证阿里做不好中台，但这事情上还真是无可非议的，5年的时间，市场不同面临的技术、组织、运营的策略也不同，这也算是中台置于阿里的演化进程，并不能说明问题。本文我要说的是阿里对外输出的业务中台做得并不好。

为表达严谨性我特别强调下文说的是“业务”中台，阿里的数据中台做得非常不错，合理的规划与使用可以大大助力企业的提质增效，并且目前几乎没有可与之全面对标的产品。但是作为产出成果更直接的业务中台阿里就显得力不从心了。

为什么这么说？我们先看个案例：

政务中台问题解析

阿里政务中台官网：https://govpaas.aliyun.com/ ，其核心是打造了业务与数据的两大中台以支撑政府工作的开展，而业务中台又主打事项中心的“售办分离”模式，详见它的白皮书 https://govpaas.aliyun.com/help-center/index.html （由于白皮书中强硬的法律声明我就不复制，大家可自行查阅）。这一切看上去都是那么得“完善”，但当大家有机会真正接触就会发现这么被重视被做典型的政务中台却存在着许许多多的问题，我们以该业务中台的事项中心及开放平台两大核心系统举例：

事项中心：

• 无法形成开发闭环，新增或修改事项时对于事项的测试环节缺位，无法实现完全基于该平台的一体化构建
• 可视化配置过少，稍微复杂些的功能就需要使用脚本完成
• 容错设计不足，缺少规范化的服务降级、回滚能力，出现技术问题时可能导致业务异常

开放平台：

• 与阿里CSB类似，疑似重复造轮子，阿里的解释是CSB是标品无法支撑这一中台的需求，哈哈，原来还可以这么玩，阿里内部产品都不要求复用了？
• 权限体系薄弱，与各企业的用户权限无法很好的兼容，需要二次开发

这些是我与阿里的同学几次沟通后发现的，也许实际的情况有出入，仅作为参考吧。

当然我说阿里做不好业务中台更直接的原因是因为工作上的多次接触，无论是我们的业务还是技术都反馈阿里的中台产品不好用、理论不适用，但由于商密的限制，我不方便说。

阿里及政府的典型工程尚有如此多的问题，大家可以想想看要是阿里中台用在您的企业中会如何呢？

那么问题来了，为什么会这样？

做不好的原因

1. 中台比平台更贴近业务，但阿里没有一手业务资料，对政务、能源、水利等行业知之甚少，要做好中台需要懂业务的人做顶层设计，但是每个行业都有产业单位，大家都有利益诉求，阿里与这些单位合作时很难获得到一手资料，阿里搞业务中台可谓是无本之木，无源之水
2. 阿里原厂人力成本过高，阿里原厂的人力成本往往3倍于一般公司的人力成本，而在不少行业的项目招投标时用的是人头数反推项目额，导致在中台上阿里只得找一帮“小弟”来实施，但无奈这些小弟或能力有限或“各怀鬼胎”，导致交付远不如预期
3. 业务中台无法沉淀产品，阿里搞过好些行业的中台，但由于不同行业或是同行业的不同细分市场的业务差别很大，导致幸幸苦苦搞的业务中台很难复用，也许这才是阿里不愿意做行业经验沉淀、投资源做业务中台的真正原因吧

这是我的思考，本身不是阿里的错，阿里做业务中台就是虎口拔牙做不好是正常的。

怎么破

其实上我也没什么太多建设性的想法，阿里上下比我有能力有深度的同学多得去了，相信要破局一定是组合拳，不是简简单单就可以说清楚的。

但从我们使用者或是产业公司的角度看，我觉得可以从以下几个方面探索：

1. 思想上：端正态度，放下架子，以学习者而不是布道者的心态对待各行业业务中台的建设，去虚心的倾听理解不同行业的业务特点，不是一上来就说你们那是不对的、应该这样那样做
2. 产品上：不做解决方案，专注小而美的产品，一方面解决方案不容易标准化，另一方面阿里的解决方案有很强的主导权意识，即用了你的解决方案就很难回去了，有很强的侵入性，对主流的研发体系形成冲击，这种“绑架式”的模式被众多产业公司唾弃，相反的阿里应该把行业经验沉淀到一个个产品中，做成标品，成为业务中台的一个个可选项，即可以用阿里的产品，也可以用其它厂商的，将中台视为生态而不是一个个项目
3. 商务上：良性竞合体系建设，不是嘴上说大家合作共赢，实际上以我阿里为大，业务中台这事可大可小，并不是非阿里不可，阿里给出有竞争力的产品及诚挚的合作方案

最后说一句

我与一些同行交流时会听到一些声音说“阿里、某某某也在做这块”，我想说的是狼并不可怕，你可以有枪。把你们企业的长处、其它厂商问题向你们的领导、团队、同事说清楚，不要妄自菲薄。

关注我的公众号：