别再把中台当万能补丁：业务中台规划的落地边界与避坑逻辑

上周在苏州跟一个做精密零部件的制造企业CIO吃夜宵，他灌了半瓶黄酒才吐槽，去年咬着牙批了1200万预算拉团队做业务中台，折腾了14个月上线，现在三个核心业务部门的日常系统登录入口还是原来的老ERP，中台后台的日活还不如公司内部的打卡系统，运维团队天天追着业务部门问要不要用，被怼回来的次数比内部培训还多。

这不是个例。我见过太多团队谈中台的时候，张口就是架构图、技术栈、复用率，压根没搞清楚自己为什么要做这件事。

被误解的起点：不是技术项目，是业务权责的切分实验

很多人启动业务相关的中台建设时，第一反应是拉上技术团队，把现有所有系统的功能列个清单，把重复的模块抽出来搭个新系统。错得离谱！

中台的核心不是“复用代码”，是把跨部门重复的业务规则、权责边界、数据口径先统一成可协商的共识，再落地成系统能力。说白了，你得先谈明白“订单超时自动取消这个规则，到底是电商部定，还是供应链部定，还是客服部定”，再谈怎么把这个规则做成系统能力。

说真的，我见过80%的中台死在第一步——技术团队自嗨式抽能力，根本没跟业务线坐下来谈权责。说个离谱的事，我之前参与过一个项目，中台团队把“退货退款”流程抽成了通用能力，结果电商部门说我们的退货是7天无理由，线下门店是15天质量问题，你通用流程根本覆盖不了，最后还是得给两个部门开独立的流程分支——那你当初费那么大劲抽这个能力干嘛？

这不是技术问题。

是利益问题。

能力沉淀的反常识：先做“减法”，再谈“复用”

很多团队对中台的想象是“一个平台支撑所有业务场景”，恨不得一开始就把所有系统的能力都塞进去，结果就是中台变成了大杂烩。

我见过最夸张的中台项目，需求清单里列了400多个能力点，从用户头像上传到财务自动记账全包含，做了两年还没上线，CTO都换了两任，最后项目直接砍了，钱花了不少，啥也没落下。

不要追求一开始就覆盖100%的业务场景，先把跨部门重复度超过70%的共性能力跑通，再给个性化需求留够扩展插槽。比如“用户手机号脱敏校验”“订单状态跨系统同步”“支付通道统一对接”，这些能力不管是做电商、做线下门店、做经销商管理都要用，而且规则几乎没有部门差异，先把这些最小的能力单元做扎实，让业务线能直接调用，比你花半年做个复杂的用户标签体系有用得多。

我之前碰到一个团队，上来就想做全渠道的营销中台，光用户标签体系就做了2000多个标签，结果业务部门用的时候，连“最近30天复购用户”这个标签都找不到，因为标签分类是技术团队按数据维度分的，根本不是按业务使用场景分的——这不是做中台，是建数字迷宫。

绕不开的落地风险：别把中台做成新的“部门墙”

很多企业做完中台之后，反而出现了更荒诞的问题：原来业务线自己改个规则，找两个开发三天就能搞定，现在要提需求给中台团队，走排期、等评审，两周才能上线，效率还不如之前。

比如某连锁餐饮企业的中台团队，把门店的优惠规则全收归中台统一管理，结果有个门店想在高考期间给持准考证的学生打8折，提了需求之后中台团队排期排了两周，等规则上线，高考都结束了。

问题出在哪？很多团队把中台的定位搞反了。中台的定位是“能力超市”，不是“全能管家”——业务线能自己配置解决的问题，绝对不要堆到中台团队的需求池里。

你得把能力划成两类：一类是刚性的，比如用户身份核验、支付通道对接、跨系统的数据同步，这些必须中台统一管，避免各个业务线重复造轮子；另一类是柔性的，比如门店级的促销规则、单渠道的活动配置，这些要给业务线留可视化的配置后台，让他们自己拖拖拽拽就能完成，不需要找中台开发。

还有KPI的坑。很多企业给中台团队定的考核指标是“能力复用率”，为了凑这个数字，不管什么需求都要往中台塞，最后把中台做成了一个什么都有但什么都不好用的杂货铺。正确的考核逻辑应该盯着“业务线使用中台能力之后，需求交付周期缩短了多少”“跨部门的协作成本降了多少”，而不是你到底抽了多少个能力点。

这点想不明白。

中台早晚被拆。

上次跟那个苏州的CIO通电话，他说后来把原来的中台团队拆了一半，把跟生产、销售直接相关的能力还给业务线，只留了跨工厂的库存调度、经销商的统一对账两个核心能力，现在上线才3个月，业务部门的使用率从原来的12%涨到了68%。

哪有什么一劳永逸的完美架构啊。

都是跟着业务的步子，慢慢磨出来的。