别瞎搭架子：业务中台规划的三个避坑方向
我最近三个月见了五个筹备业务中台的团队，四个都卡在了规划阶段。
不是没人懂技术，是思路从根上就错了。
上来先搬咨询公司的模板，抄大厂的架构，最后出来的规划，好看是好看，落不了地。
零售企业业务中台重复开发成本统计表示例
业务中台从诞生那天起，核心就是降本提效，不是用来给财报贴金的概念。
做规划的第一步，根本不是画架构图。你要做的，是拉出去过去三个月所有业务线的开发记录，数清楚：
有多少功能，不同项目重复做了三次以上？
每次重复开发，花了多少人天，折合成成本是多少？
如果把这些能力抽出来中台化，一年能省多少钱，能多支撑几个新业务？
算不清楚这笔账，千万别动工。
你花大几百万搭出来一个花架子，最后钱花了，业务没受益，中台反而成了团队的包袱，接下来想砍都砍不动。
业务中台上下结合规划路径示意图
正确的思路其实一点都不复杂。
先自上而下定好边界：你的中台未来两年要服务哪几条业务？要支撑什么方向的新业务？哪些是绝对不能动的核心规则？先把框框画好，别越界。
定完边界，再自下而上收痛点：让每个业务线把自己天天吐槽、重复做了一遍又一遍的工作列出来，排序，把痛得最狠的那几个挑出来。比如每个业务线都要做支付对账，每个都要维护商品基础信息，每个都要算用户积分，这些才是你真正该抽进中台的能力。
那些半年才用一次，只有单个业务线需要的偏门需求，别往中台上塞。中台不是万能垃圾桶，什么需求都能往里装。
很多人迷信“足够通用”，为了未来可能有的需求，提前做一堆扩展能力，最后把中台搞成了几十吨重的生锈机器，用起来比原来还麻烦，这不纯纯浪费钱吗？
别做一步到位的规划，给变化留足空间
我见过最离谱的一个规划，中台团队上来就做了三年一步到位的方案，一共六千多人天，说三年之后就能建成“完美赋能全业务”的中台。结果做了一年半，公司业务方向转了，原来要做传统电商，现在改做AI原生应用，原来规划的九成能力全用不上，预算花完了，团队直接解散。
现在这个世道，变化太快了。今年你做社区团购，明年可能就转做AI大模型应用，后年谁知道又出什么新风口？你现在做的一步到位的规划，能跟上一年后的变化吗？对吧？
所以做业务中台规划，一定要抱着“先做最小可行中台，再慢慢长”的思路。先把最痛的两三个需求解决了，上线跑起来，拿到真实的使用反馈，验证了确实能降本提效，再一点点往里面加能力。
好的业务中台从来不是规划出来的，是跟着业务慢慢长出来的。
不过话说回来，留空间不是让你瞎做。核心的东西不能松，比如主数据的标准，能力调用的规则，这些顶层的东西一定要一开始就定好，不然你滚着滚着，又变成了新的信息孤岛，又要重复建设，等于白做。
前段时间看一个制造企业的案例，他们做业务中台，一开始就只规划了三个核心能力：物料主数据管理、供应商信息管理、生产工单协同，就这三个，花了三个月就上线了，跑了半年，验证了确实能帮业务省三分之一的重复工作量，然后业务团队自己一点点往上加能力，现在两年过去了，已经支撑了六条新的产品线，总投入还不到那些一步到位方案的三分之一，效果好太多。
很多咨询公司卖规划，就爱给你做几十上百页的PPT，全是高大上的名词，就是不说你今天下班前该先做哪件事，收你大几十万几百万，最后落地全靠你自己摸，这种规划，扔了也不可惜。
业务中台本来就是帮业务跑更快的工具，别把工具做成了绑住业务的绳子。规划的时候多想想自己的真痛点，少抄别人的漂亮PPT，你就已经赢过八成的中台团队了。
别为了概念做规划，先算清你的投入产出账
很多公司老板听完行业分享，回来拍板就要上中台，说竞争对手都有我们不能缺。 说实话，大部分人做业务中台规划，第一步就踩坑。 上来先画组织架构，拆能力模块，定KPI，连自己公司一年到底在重复开发上浪费了多少钱都没数过。 去年我帮朋友看一个连锁零售公司的中台规划，他们光规划就做了八个月，列了一百二十多个可复用能力点，预算砍了两次还剩九百多万。结果上线跑了三个月，发现他们三条业务线，只有用户积分这一块是真的重复开发，剩下的全是各业务线独有的需求，抽成中台能力之后，反而每次改需求要多走三个审批环节，效率比原来还低。零售企业业务中台重复开发成本统计表示例
业务中台从诞生那天起，核心就是降本提效，不是用来给财报贴金的概念。
做规划的第一步，根本不是画架构图。你要做的，是拉出去过去三个月所有业务线的开发记录，数清楚：
有多少功能，不同项目重复做了三次以上？
每次重复开发，花了多少人天，折合成成本是多少？
如果把这些能力抽出来中台化，一年能省多少钱，能多支撑几个新业务？
算不清楚这笔账，千万别动工。
你花大几百万搭出来一个花架子，最后钱花了，业务没受益，中台反而成了团队的包袱，接下来想砍都砍不动。
别光靠顶层拍板，要上下结合找真需求
我见过太多两种极端。 一种是全靠高层定规划，老板说我们要做统一订单中台，那全公司所有业务线的订单都得塞进来，不管你逻辑对不对得上。另一种是全扔给一线业务自己报需求，最后报上来一堆零散的小点，拼出来的中台碎得渣都不剩，根本撑不起新业务。 之前有个做企业服务的朋友跟我吐槽，他们公司规划中台的时候，高层拍板要把To C和To B的订单统进一个中台，为了适配两边完全不同的流程，开发团队改了八个月，最后上线之后，两边的业务都嫌难用，又拆回两个系统，浪费了一年多时间。业务中台上下结合规划路径示意图
正确的思路其实一点都不复杂。
先自上而下定好边界：你的中台未来两年要服务哪几条业务？要支撑什么方向的新业务？哪些是绝对不能动的核心规则？先把框框画好，别越界。
定完边界，再自下而上收痛点：让每个业务线把自己天天吐槽、重复做了一遍又一遍的工作列出来，排序，把痛得最狠的那几个挑出来。比如每个业务线都要做支付对账，每个都要维护商品基础信息，每个都要算用户积分，这些才是你真正该抽进中台的能力。
那些半年才用一次，只有单个业务线需要的偏门需求，别往中台上塞。中台不是万能垃圾桶，什么需求都能往里装。
很多人迷信“足够通用”，为了未来可能有的需求，提前做一堆扩展能力，最后把中台搞成了几十吨重的生锈机器，用起来比原来还麻烦，这不纯纯浪费钱吗？
别做一步到位的规划，给变化留足空间
别做一步到位的规划，给变化留足空间
我见过最离谱的一个规划，中台团队上来就做了三年一步到位的方案，一共六千多人天，说三年之后就能建成“完美赋能全业务”的中台。结果做了一年半，公司业务方向转了，原来要做传统电商，现在改做AI原生应用，原来规划的九成能力全用不上，预算花完了，团队直接解散。
现在这个世道，变化太快了。今年你做社区团购，明年可能就转做AI大模型应用，后年谁知道又出什么新风口？你现在做的一步到位的规划，能跟上一年后的变化吗？对吧？
所以做业务中台规划，一定要抱着“先做最小可行中台，再慢慢长”的思路。先把最痛的两三个需求解决了，上线跑起来，拿到真实的使用反馈，验证了确实能降本提效，再一点点往里面加能力。
好的业务中台从来不是规划出来的，是跟着业务慢慢长出来的。
不过话说回来，留空间不是让你瞎做。核心的东西不能松，比如主数据的标准，能力调用的规则，这些顶层的东西一定要一开始就定好，不然你滚着滚着，又变成了新的信息孤岛，又要重复建设，等于白做。
前段时间看一个制造企业的案例，他们做业务中台，一开始就只规划了三个核心能力：物料主数据管理、供应商信息管理、生产工单协同，就这三个，花了三个月就上线了，跑了半年，验证了确实能帮业务省三分之一的重复工作量，然后业务团队自己一点点往上加能力，现在两年过去了，已经支撑了六条新的产品线，总投入还不到那些一步到位方案的三分之一，效果好太多。
很多咨询公司卖规划，就爱给你做几十上百页的PPT，全是高大上的名词，就是不说你今天下班前该先做哪件事，收你大几十万几百万，最后落地全靠你自己摸，这种规划，扔了也不可惜。
业务中台本来就是帮业务跑更快的工具，别把工具做成了绑住业务的绳子。规划的时候多想想自己的真痛点，少抄别人的漂亮PPT，你就已经赢过八成的中台团队了。