业务中台规划：为什么你折腾三年，还在原地打转？

上周有个CTO朋友找我喝茶，刚坐下就叹气：“中台项目又双叒延期了，老板说要砍预算……”我听着，手里的杯子转了两圈——这种场景，我过去五年见了不下三十次。说实话，每次听到都像看同一部烂片重映，连BUG都一模一样。

中台这玩意儿，起初被吹成万能药，现在成了背锅侠。但问题真在中台本身？不如说，大部分公司做的压根儿不是中台，是给各个业务线又压了一座山。

中台的幻觉：你以为的复用，其实是在攒垃圾

很多老板觉得，中台就是把相似功能抽出来，统一做，这样就能省成本。逻辑没毛病——但业务逻辑要是能随便抽，那就不是业务了，是乐高。可惜现实里的业务系统，早被无数补丁糊成了意大利面。强行抽，抽出来的是怪胎：A部门要的订单服务，B部门用不了，因为字段都不一张，于是中台团队开始加字段、加逻辑、加if-else，最后变成一座谁都不敢碰的屎山。

更讽刺的是，中台团队为了证明自己“有产出”，拼命造轮子，生怕别人说他们复用度低。结果呢？真正该复用的没做好，不该统一的反倒被卡死了脖子。去年一个零售企业，把促销逻辑硬拉进中台，结果双十一时，不同事业部的促销规则互相掣肘，订单系统直接雪崩——几千万流水就打了水漂。

说到这里我得补一句：中台不是技术架构问题，是权力分配问题。谁来决定什么该复用、什么该各自为政？这比写代码难十倍。

业务中台规划的核心：不是画格子，是切蛋糕

见过太多规划文档，一打开就是密密麻麻的能力域矩阵，什么用户中心、订单中心、商品中心……整整齐齐，像毕设答辩的PPT。但一落地就废。为什么？因为那些格子是按教科书画的，不是按利益关系切的。

真正的业务中台规划，你得先搞明白三件事：谁买单？谁疼？谁有权拍板？ 有一回我帮一个B2B平台做梳理，他们原本按“采购、销售、库存”分了三个中台。听起来很合理对吧？但采购部门说销售中台的查询接口太慢，销售部门骂采购中台的数据不准——两个团队差点在会议上打起来。后来我们发现，真正的断层线不在功能域，在决策链。 于是我们把中台重新切成“供应商侧”和“客户侧”，中间用一套异步事件打通。世界清净了。

你看，规划时少盯着技术图谱，多盯着会议室里的较量。中台切得好，是润滑剂；切不好，就是开战导火索。

落地时最贱的骨头：不是架构，是人

我特别烦一种论调：“只要中台系统构建好，推广自然水到渠成。” 天真！你给业务方塞一个平台，跟给她换牙刷一样——她只会觉得你嫌她脏。

中台落地的最大阻力，从来不是API调不通，而是业务方根本不认你的账。人家前线背KPI背得要死，你还让她迁移到新系统、学新流程，她心里能没火？而且没有考核绑定的中台，就是一纸空文。 有个公司推了个超级漂亮的数据中台，报表秒出。但一线销售还是找IT私下跑SQL，因为中台不认他们的“私下客户关系”。你得把中台的使用纳进业务部门的OKR，甚至先从小恩小惠开始——比如帮市场部自动生成周报，他们尝到甜头才会慢慢靠过来。

还有件事很反常识：中台团队要学会“装傻”。 别急着追求大一统，允许局部冗余，允许灰度期。有个物流中台，硬啃了两年才被业务接受，秘诀就是前期只做了车辆调度这一个环节，而且允许车队自己保留Excel。老板差点拍桌子骂他们效率低。但正是这种容忍，让中台活到了证明自己的那一天。

说到底，业务中台规划是一道没有标准答案的题。它像装修房子——你请了设计师，画了图纸，但住进去之后，插座位置不对、收纳空间不够，你还得砸墙。所以别指望一步到位。先跑通一个最小闭环，哪怕只是个“猪圈”，也比毛坯豪华要强。

最后说句扎心的话：如果你们公司连两个业务线的利益都摆不平，先别急着搞中台。 你可能更需要一个能拍桌子的老板，而不是一堆华丽的架构图。