踩过三个坑之后，我理解的业务中台规划

前年帮华东一家年营收百亿的零售集团做业务中台梳理，项目尾款差点黄了。原因说出来可笑，我们第一版规划把能抽的公共能力全抽了，画出来的架构图完美无缺，给业务线负责人评审的时候，人家一句话给我顶回来：我要搞直播带货，你的商品中心要改三个需求，排期要两个月？那我这个季度的活动早就黄了。

那时候才明白，很多人讲的业务中台规划，都是纸上谈兵。

别上来就堆能力，先拆“真共享”和“伪复用”

现在随便搜一下中台相关的资料，十篇有八篇会告诉你，中台就是把重复的能力抽出来复用，降本提效。这话没错，但错在大部分人分不清，什么是真的要复用，什么是你以为能复用。

很多公司做规划，上来就是先建用户中心、商品中心、订单中心，把所有业务的数据都塞进去，要求所有新业务必须调用中台接口。你猜怎么着？最后每条业务线都在中台外面又搭了一层自己的逻辑，绕开中台走，中台变成了一个存数据的死库，钱花了，啥用没有。

说实话，我现在看业务中台规划，第一先看，抽出来的每个能力，是不是已经有至少两条业务线实打实遇到了同样的痛点，真的需要共享。要是只有一条业务线在用，剩下的都是“未来可能用”，那坚决不抽。

真共享的核心，是业务主动需要，不是规划师硬塞。之前碰过一个做To B的客户，非要把客户管理能力抽出来做共享中心，原来的销售业务用得好好的，新的政企业务说我客户层级、跟进逻辑全不一样，你的中台我用不了，最后还是政企自己搭了一套，中台那个中心变成了摆设，浪费了小半年的研发资源。

很多人说复用就是代码复用，其实错了。中台的复用，核心是数据和核心规则的复用，不是非要所有业务都用同一套代码逻辑。你要是为了复用，把所有东西都绑死，那反而不如不做。

中台规划必须留够“不标准”的弹性空间

我见过最离谱的一份中台规划，是某上市公司做的，整整三百页，把未来五年所有业务要用到的能力都定义好了，大到交易流程，小到字段格式，全定死了。现在过去三年，那个公司的核心业务都换了两轮了，中台还在按原来的规划改，改到研发团队都不想碰。

业务哪有什么一成不变的？现在市场变化这么快，上个月你还在做To C，这个月可能就要蹭热点做To B，中台规划要是追求百分之百标准化，那就是自寻死路。

我现在做规划，都会给业务线留15%到30%的自定义空间，核心数据统一进中台，非核心的业务逻辑，你爱怎么玩怎么玩，只要不碰核心数据的规则，中台不卡你排期。之前那个零售集团的项目，就是原来把所有逻辑都定死了，后来我们改了规划，核心的会员数据、支付结算能力放到中台共享，直播、社群团购这些新业务，商品展示、活动规则这些都自己做，只调用中台的会员和支付接口，上线只用了两周，皆大欢喜。

不过话说回来，留弹性不是说乱搞，核心边界要划清楚。什么边界？就是核心数据的主权必须在中台，所有业务产生的核心数据必须回传给中台，不能各存各的，不然最后又变成数据孤岛，中台白做了。

你看现在头部互联网公司讲中台，早就不说大一统了，都讲灵活迭代，核心就是给业务留空间，规划不做死，一步一步往前滚，不会上来就把所有路都堵死。

算清投入产出的时间账，别搞一步到位

很多企业做中台，上来就喊着要投几千万，花一两年做一个完美的中台，然后再支撑所有业务。这种十有八九都死了。

为什么？因为业务的变化速度，比你中台建设的速度快多了。等你中台建好，业务方向早就变了，你的投入全打了水漂。现在降本增效的大环境下，更不能这么干。

我做规划的原则是，先找最痛的那个点切入。比如你公司现在有三条业务线，都在用户运营上重复花钱，那你就先做用户中心，把这个痛点解决了，看到效果了，再往下做下一个能力。这样每一步都有产出，老板也愿意持续投钱，团队也有信心，不会做一半就砍项目。

我之前有个客户，原来规划一年做完所有中台模块，后来听了我的建议，先做用户和商品两个核心模块，半年就上线，给业务省了三分之一的重复开发成本，老板一看真有用，后续的钱马上就批了，现在慢慢做，两年才全部做完，反而比一步到位省了不少钱，也更贴合现在的业务。

别不信。很多中台项目烂尾，不是技术不行，是规划的时候太贪，想要一口吃成胖子，结果把自己撑死了。

业务中台规划本质是什么？本质是服务业务，不是做出来给老板看的架构图。你架构图画得再好看，不能帮业务降本，不能让新业务更快上线，那就是垃圾。对吧？

现在很多人把中台神化了，说中台是企业数字化转型的核心，其实说白了，中台就是一个工具，规划这个工具的时候，就得跟着业务的脚步走，不能让业务迁就你的工具。坑踩多了才明白，好的业务中台规划，从来不是完美的，是能跟着业务一起慢慢长大的。