中台概念诞生几年了，相关文章不计其数，但是真的读下来，读者大概率会产生至少两个疑问：

（1）概念是讲了一堆，架构图是很酷炫，但是中台到底长什么样的？具体咋工作的？

（2）有道理的好话说了一堆，怎么没怎么听见有分量的坏话？落地这么久了，具体遇到了什么问题？为什么会遇到这些问题？这病能治么？怎么治？

其中，问题（1）在关于中台，讲一些别人没讲清楚的(上)已经讲过，本文用人话+案例的老猿风格，把问题（2）讲清楚。

1、中台落地之痛

我们看到中台的价值通常是这样的：

（1）我们这个中台体系里有什么样的能力，可以让各业务很清楚的知道，也可以让前台业务方更快的理解、选择和使用中台能力。

（2）我们提供了基础解决方案，业务方根据需要做定制开发满足自己的业务特性，对前台的业务来说会更快。

总之就是：通过将共性功能高复用，大幅提升多项业务效率，关键词，共性，复用。

但实际中，中台往往是这样的：

（1）中台并不总是能够提炼共性需求，因为缺乏共性的判断标准

（2）没有谁能完整的掌握中台的所有能力，因为中台的庞大与业务改动的幽深天然矛盾。

这两点挫伤了中台的共性提取能力。

（3）中台抱大业务的大腿，小业务抱中台的大腿，因为发展的短期性与投入的长期性难以调和。

（4）中台的“轮子”会不断变化，业务被动升级，因为中台的扩展需要超前于某项业务的发展。

（5）30%的定制代码量耗费的人力可能超过100%，原本追求的边际效益递增反而成了边际效益递减。

（6）中台是某类业务的中台，不是所有业务的中台，部分公司业务线不多，或者业务线很多但差异化太大，搞中台得不偿失。

这四点挫伤了中台的多业务复用能力。

具体来说：

（1）中台并不总是能够提炼共性需求，因为缺乏标准：

1、中台和业务方天然存在对共性需求的不同诉求，业务方希望把80%的非核心功能都定义成共性的，扔给中台做，中台希望弱水三千，只取一瓢，只做最具有共性的。

2、单个业务方提出的需求，没有什么标准判断是共性需求，因而，大业务的需求更可能是“共性需求"，需求的判断沦落为话语权的比较，例如淘宝特加版的需求就是共性的，飞猪的需求就不共性。（手动狗头）

（2）没有谁能完整的掌握中台的所有能力，因为中台的庞大与业务改动的幽深天然矛盾。

1、对于中台的能力，业务方不能，中台自己也不能完整掌握。在本文上篇关于中台，讲一些别人没讲清楚的(上)中提到，一个电商业务中台下的交易中心系统，往往由20多个子系统组成，每个子系统都是一个P7级别的团队负责，整个电商业务中台的功能体系之庞大，可想而知。业务提了一个细小的改动，中台的对接人员，很难快速定位到哪个环节需要改进，因而更难给出充分的理由，说明这个到底算不算共性问题，到底是你们业务自己做，还是我们中台来做。

2、所以，哪怕是阿里，在建设中台时，其实也是玩人月神话，人海战术那一套。划分中台的子域/子系统，给足子系统架构师、程序员、产品人手，用数量换时间。

（3）中台抱大业务的大腿，小业务抱中台的大腿，因为发展的短期性与投入的长期性难以调和：

业务会分优先级，优先满足大业务

因为在实际中，中台的KPI最终只能通过大业务体现。中台是支撑性业务，他们的从业人员的劳动结果，是帮助其他业务做的更好。那么，一项没什么增长的业务A，一项飞速增长的业务B，都来跟你提需求，你怎么办？由于中台都是边做边用，不可能等你1，2年做好了 再用，那必然涉及到资源有限的条件下，优先满足谁？你给业务B做了，搞不好一年到头业务B数据还下滑了，到时候甩锅给你中台，怕是百口莫辩。绝大部分公司的考核机制下，即便是中台这种立足于长期效益的部门，其员工也不可能真的牺牲个人眼前得失，来为公司的未来努力。

（4）中台的“轮子”会不断变化，业务被动升级，因为中台的扩展需要超前于某项业务的发展:

为了提升中台的可扩展性，满足未来可能诞生的新业务需求，中台系统的架构和接口会不断演进，理想中，中台人员应该有能力预估到集团未来的业务，并且提前做好功能和接口升级，做好埋伏，因此基于中台功能的老业务已有功能被迫进行切换，老业务的功能升级频率比自己独立发展要高，但这些升级本来很可能“大可不必”。

（5）30%的定制代码量耗费的人力可能超过100%，原本追求的边际效益递增反而成了边际效益递减

因为中台虽然目标是高复用性，但目前中台还无法设计成那种可拖拽的傻瓜模式，中台的复用还是进行代码复用，而不是模块拖拽复用，这看起来问题也不大，但实际中，大量时间花费在了判断哪些是那30%的代码，为什么不可以是20%？为什么不可以是另外的30%？这种判断，在实际中就是大量的会议、大量的人数暴多的临时工作群、大量的扯皮甩锅，最后确实讨论出了个3，7开，但算下来也许还没有自己做70%效率高。

（6）中台是某类业务的中台，而不是万能解药：

1、中台重投入，慢见效，业务相似才有共性需求，业务差异越大中台价值越小，ROI算下来可能很不划算。

2、很多“技术中台”只不过是把“平台”二字替换为“中台”。

2、中台该往何处去

梳理了中台落地的问题，我们可以提炼几点，中台发展的建议，也可以作为我们判断一些中台能否发展好的标准，以供参考。

（1）勿在浮沙筑高台

先做好技术平台，再做中台，技术平台都没有搭完善，基于不同技术业务互通都存在困难，怎么搭中台？

（2）勿做追风的猪

至少有超过3个相似的平行业务线才考虑做中台。业务线不多又差异大，建中台就像大炮打蚊子，浪费资源。

（3）步子太大小心扯到蛋

基本上来就要做大而全的中台，都是吹牛批。先找一个子系统开始试水，由点到面扩张边界。

（4）世上没有万能药

不要相信一个中台可以满足所有业务。中台能力边界的划分，别人可以糊弄，自己心里要门清。

（5）火车要靠车头带

承认理想与现实的差距，拥抱共性标准的不确定性，最好的方式，就是给中台安排一个和业线的层次相仿的leader。相反，如果一个公司的中台领导矮了好几个业务线半级一级，可以合理怀疑中台的落地效果。