跳出伪架构陷阱：业务中台规划的破局路径

去年秋分那天在南京珠江路的茶馆见一个做连锁餐饮的创始人，茶没泡开他就掏出手机翻聊天记录，满屏都是技术团队和外包的扯皮。前年想整，砸了小一千万，现在别说提效，开个新的外卖产品线都比原来慢了两个星期。 这不是个例。太多企业把这个事当成了数字化转型的标配，图纸画得整整齐齐，复用、共享喊得震天响，最后用起来全是问题。

绝大多数死在「为了架构而架构」

上来先定调子，我们要建一套覆盖全业务的共享能力中心，把所有能抽的模块全抽出来。美其名曰超前规划，实际上就是脱离业务的自嗨。 那个餐饮创始人的项目就是这么回事。外包团队把会员、商品、门店、供应链全拆进了中台，哪怕是刚试水产品线的新品推荐逻辑，都硬抽出来做了通用服务。结果呢？每个门店的区域性活动规则不一样，改一行代码要中台、前端、运营三个团队排期，原来一周能上线的活动，现在最快也要一个月。 营收没涨，人力成本先涨了三成。 说白了，很多人一开始就搞错了目标。我们做这个事，目的是解决业务重复造轮子的痛点，不是为了凑出一张好看的架构图给老板看，更不是为了赶风口吹牛逼。 错误业务中台架构分层示例图 很多大厂出来的架构师容易犯这个错，把大厂那套全栈中台直接搬过来，根本不管中小企业的业务规模还在快速变化，今天的通用能力，可能三个月后就全推翻了。

先搞清楚，什么样的能力才适合进中台

我见过最扯的一个项目，创业公司，业务线才两个，就开始抽中台了，美其名曰提前布局。结果烧了大半年钱，业务没跑起来，中台先把现金流耗干了。 这里有个很简单的判断标准，别扯虚的，就看三条：第一，这个能力是不是至少在三条不同业务线重复开发过？第二，核心规则是不是半年以上没有大变动？第三，是不是不绑定单个业务线的创新试错？三条都满足，再考虑抽进中台，缺一条都别急。 举个例子，支付清分，不管你做堂食、外卖还是预制菜电商，底层的对账、分账、合规逻辑都是稳定的，而且每个业务线都要做，这个抽进去，绝对降本。反过来，你新做了一个直播带货的业务，现在要做直播间专属的用户标签体系，还在每周迭代规则，你硬抽进中台，那就是给自己套枷锁。 说实话，哪怕同一个能力重复三次，如果你只是复制粘贴就能解决，成本都比你改造中台低。很多人把复用等同于抽中台，这个误区不知道坑了多少人。 复用有很多种，代码拷贝是复用，技术组件是复用，中台只是其中一种，而且是成本最高的那种。没搞清楚这个前提，上来就要做，不输才怪。 合理业务中台能力边界划分图 还有一个很容易被忽略的点，就是中台的能力一定是无业务感知的。你不能把某个业务线的特定规则绑进去，不然就不叫共享，叫甩包袱。比如会员中台，只放最核心的用户注册、身份管理、积分计算通用规则，不同业务线的会员等级权益，一定放在业务端的适配层，别往中台塞。

从痛点倒推的落地路径，才走得通

从痛点倒推的落地路径，才走得通 别上来就做整体规划，别上来就要搭完整个框架。正确的做法是，先拉着所有业务线数痛点：近半年来，哪些能力重复做了？哪些地方卡了业务的脖子？哪个需求改了七八次全因为重复造轮子？ 列个清单，按收益从高到低排，先做第一个，跑通了，验证了确实能帮业务提效，再往下扩。比如先从支付清分入手，做完了，每个业务线不用再花一个月搭支付体系，两周就能上线新业务，所有人看到好处了，后面再推别的能力，阻力小得多。 很多人上来就要一年建完整个中台，等你建完，业务方向都变了，做出来的东西全没用，只能堆在服务器里落灰。 还有更关键的，组织得跟着变。如果中台放在技术部，业务线肯定不愿意用。为什么？技术部不懂业务的实际需求，做出来的能力不好用，出了问题互相甩锅。最好的方式，是把中台团队做成共享服务中心，直接对业务线的使用体验负责，成本分摊给各个业务线，收益也和业务线的增长绑定，你服务做得好，所有业务线都愿意用，你做的不好，业务线可以不用，自然就有压力把活做好。 不过话说回来，不是所有企业都需要这个东西。你就一条业务线，谈什么共享复用？安安稳稳把业务做好，比什么都强。别听到什么概念就往自己身上套，适合自己的才对。 上次那个餐饮创始人，后来把中台砍了三分之二，只留了支付、会员、商品三个核心能力，剩下的全还给业务线，这下好了，上新的速度直接提了四倍，成本也降下来了。 说白了，哪有什么正确的标准答案。能解决自己问题的，就是对的。