踩过三个大坑之后，我眼里靠谱的业务中台规划是什么样的
前几天跟老东家的技术负责人喝茶，聊到今年他们刚砍了折腾两年的中台项目，三十多个人的团队拆去了各个业务线，老板拍桌子骂浪费资源，一群人灰头土脸。
坑踩够了。钱烧没了。才回过神来，原来大部分人从做业务中台规划第一天起，方向就错了。
零售行业业务中台痛点拆解路线图
去年帮一家做全域零售的朋友看他们的业务中台规划，原来他们上来就要做支持二十种业态的全通用商品能力模型，光需求评审就开了八次会，架构图画了三四版，还没动工就已经耗了三个月。我直接给打回去了。
他们公司最大的痛点是什么？是线下门店库存和线上直播库存不同步，每次大促都超卖，光赔优惠券一个季度就要十几万，客服团队一半人都在处理库存投诉。那规划为什么不从这个痛点切？先抽库存同步这一个最小可用能力，三个月上线，直接把超卖率降到5%以下，业务线拿到真真切切的结果，自然会支持你后续扩能力，这不比上来就搭大框架画饼强？
靠谱的业务中台规划从来不是先画完美的饼，是先找最痛的那个钉。对吧？
企业业务中台组织权责划分表
说实话，业务中台规划，七分是业务治理，三分才是技术落地。你做规划的时候，不能只写技术架构图，得把各个角色的权责理得清清楚楚：中台输出什么标准能力，业务线可以改什么自定义内容，出了问题谁背锅，收益怎么分，这些才是决定中台能不能活下来的核心。
我碰过一个做得特别好的中台项目，是一家连锁餐饮的，他们做规划的时候，每个要抽出来的中台能力，都拉了三个核心门店线的产品负责人一起签字，承诺未来一年一定会用这个能力，项目的钱也是各个业务线一起出的，不是中台团队拿总部的预算瞎折腾。这样搞出来的东西，怎么会不好用？毕竟自己掏了钱，肯定盯着要结果。
很多人上来就喊“复用降本”，结果总部掏钱，业务线白嫖，出来不好用也没人关心，反正钱花完了项目就烂尾，这不就是纯浪费吗？
留够冗余，别追求百分百通用
这个坑是最多人踩的。做业务中台规划的时候，总想着要兼容所有业务，要做到百分百通用，结果把能力做得特别重，逻辑绕得像迷宫，开发了一年半才上线，最后各个业务线都嫌麻烦，还是自己偷偷写了一套。
我见过一个商品中台，为了兼容生鲜的按斤称重和数码的按序列号管理，光商品属性模型就做了八个版本，光文档就写了两百多页，上线的时候，生鲜业务线说太复杂，我们原来几百行代码的小系统够用，数码业务线说太灵活，很多规则定不下来，不安全，最后两边都不用，项目直接砍了。你说图啥？
业务中台规划，要接受“部分复用”，要给业务线留足二次开发的空间。说白了，中台只做所有业务线都必须要用的那百分之六七十，剩下的百分之三四十，让业务线自己去折腾，别什么都揽到自己身上。
不过话说回来，留冗余不是留烂摊子，中台要把接口规范、数据标准定死，业务线在此之上做自定义开发，不会乱掉就行。现在行业里喊的“轻量化中台”，本质就是这个思路，别搞大而全，搞小而美，先能用，再慢慢迭代，别上来就要一口吃成胖子。
现在很多人一提到中台就说，前几年的中台热都死了，中台本来就是伪需求。不对。中台本身没有错，错的是大部分人做业务中台规划的时候，从根上就错了——为了中台而中台，为了给老板交差而做规划，不是为了解决业务问题而做规划。
你摸着胸口想想，你做规划的时候，是先想我要解决业务的哪个具体问题，还是先想怎么画一张漂亮的架构图给老板展示我的技术能力？大部分人都是后者。
还有很多中小企业，老板听了几场峰会就要做中台，上来就招几十个人的中台团队，搞什么全栈能力抽象，纯属跟风瞎折腾。你就三四个业务线，抽一两个公共能力就行了，搞那么大干嘛？烧钱玩吗？
现在行业里其实越来越务实了，前几年那种“所有能力必须中台化”的喊叫声没了，更多人都是按需建设，小步快跑，这才对嘛。业务中台本来就是支撑业务的工具，不是拿出去吹牛逼的名片。你规划做得再漂亮，解决不了实际问题，那就是一叠废纸。
活过三年以上的中台，我见过的，没有一个是一开始就把未来五年的所有细节都规划好的，都是踩一个坑，补一块能力，慢慢磨出来的。那些一开始就把五年架构画得完美无缺的，基本都死透了。
别从能力抽象开始，从业务痛点切
很多人做规划上来就是拆能力，把用户、商品、订单全抽出来，搞个大统一，喊着“所有能力复用”，结果呢？业务线要用的时候，改一点东西要走三个审批，等完流程，业务窗口期都过了，比原来自己写代码还慢。 说实话，我见过不下十个中台团队，刚上线就被业务线骂做“信息阻塞墙”，钱花了几百万，反倒拖慢了业务进度。零售行业业务中台痛点拆解路线图
去年帮一家做全域零售的朋友看他们的业务中台规划，原来他们上来就要做支持二十种业态的全通用商品能力模型，光需求评审就开了八次会，架构图画了三四版，还没动工就已经耗了三个月。我直接给打回去了。
他们公司最大的痛点是什么？是线下门店库存和线上直播库存不同步，每次大促都超卖，光赔优惠券一个季度就要十几万，客服团队一半人都在处理库存投诉。那规划为什么不从这个痛点切？先抽库存同步这一个最小可用能力，三个月上线，直接把超卖率降到5%以下，业务线拿到真真切切的结果，自然会支持你后续扩能力，这不比上来就搭大框架画饼强？
靠谱的业务中台规划从来不是先画完美的饼，是先找最痛的那个钉。对吧？
中台不是技术项目，是业务治理项目
百分之八十的中台项目死，都是死在把中台当成纯技术项目了。老板扔给技术部，说你给我做个中台，技术部埋头抽能力写代码，从来没拉过业务线的负责人坐下来理清楚规则和利益，结果做出来的东西没人用。 我之前参与过某头部互联网公司的中台复盘，他们当年号称投入百亿做中台，最后拆分的时候，发现核心问题根本不是技术不行，是各个业务线原来的用户规则、销售分成体系都不一样，抽中台的时候，没人牵头做业务规则的统一，技术抽了个四不像的空架子，这边要改规则，那边说动了我的KPI不让改，直接僵住，最后只能拆伙。企业业务中台组织权责划分表
说实话，业务中台规划，七分是业务治理，三分才是技术落地。你做规划的时候，不能只写技术架构图，得把各个角色的权责理得清清楚楚：中台输出什么标准能力，业务线可以改什么自定义内容，出了问题谁背锅，收益怎么分，这些才是决定中台能不能活下来的核心。
我碰过一个做得特别好的中台项目，是一家连锁餐饮的，他们做规划的时候，每个要抽出来的中台能力，都拉了三个核心门店线的产品负责人一起签字，承诺未来一年一定会用这个能力，项目的钱也是各个业务线一起出的，不是中台团队拿总部的预算瞎折腾。这样搞出来的东西，怎么会不好用？毕竟自己掏了钱，肯定盯着要结果。
很多人上来就喊“复用降本”，结果总部掏钱，业务线白嫖，出来不好用也没人关心，反正钱花完了项目就烂尾，这不就是纯浪费吗？
留够冗余，别追求百分百通用
留够冗余，别追求百分百通用
这个坑是最多人踩的。做业务中台规划的时候，总想着要兼容所有业务，要做到百分百通用，结果把能力做得特别重，逻辑绕得像迷宫，开发了一年半才上线，最后各个业务线都嫌麻烦，还是自己偷偷写了一套。
我见过一个商品中台，为了兼容生鲜的按斤称重和数码的按序列号管理，光商品属性模型就做了八个版本，光文档就写了两百多页，上线的时候，生鲜业务线说太复杂，我们原来几百行代码的小系统够用，数码业务线说太灵活，很多规则定不下来，不安全，最后两边都不用，项目直接砍了。你说图啥？
业务中台规划，要接受“部分复用”，要给业务线留足二次开发的空间。说白了，中台只做所有业务线都必须要用的那百分之六七十，剩下的百分之三四十，让业务线自己去折腾，别什么都揽到自己身上。
不过话说回来，留冗余不是留烂摊子，中台要把接口规范、数据标准定死，业务线在此之上做自定义开发，不会乱掉就行。现在行业里喊的“轻量化中台”，本质就是这个思路，别搞大而全，搞小而美，先能用，再慢慢迭代，别上来就要一口吃成胖子。
现在很多人一提到中台就说，前几年的中台热都死了，中台本来就是伪需求。不对。中台本身没有错，错的是大部分人做业务中台规划的时候，从根上就错了——为了中台而中台，为了给老板交差而做规划，不是为了解决业务问题而做规划。
你摸着胸口想想，你做规划的时候，是先想我要解决业务的哪个具体问题，还是先想怎么画一张漂亮的架构图给老板展示我的技术能力？大部分人都是后者。
还有很多中小企业，老板听了几场峰会就要做中台，上来就招几十个人的中台团队，搞什么全栈能力抽象，纯属跟风瞎折腾。你就三四个业务线，抽一两个公共能力就行了，搞那么大干嘛？烧钱玩吗？
现在行业里其实越来越务实了，前几年那种“所有能力必须中台化”的喊叫声没了，更多人都是按需建设，小步快跑，这才对嘛。业务中台本来就是支撑业务的工具，不是拿出去吹牛逼的名片。你规划做得再漂亮，解决不了实际问题，那就是一叠废纸。
活过三年以上的中台，我见过的，没有一个是一开始就把未来五年的所有细节都规划好的，都是踩一个坑，补一块能力，慢慢磨出来的。那些一开始就把五年架构画得完美无缺的，基本都死透了。