中台战略实施：避开绝大多数企业踩过的坑，才谈得上落地
别把中台当万能政绩筐，先搞懂你为什么要做
前几年中台概念火的时候，大大小小的峰会全在讲中台，好像不上中台就是落后企业。很多老板脑子一热就拍板立项，根本没想清楚自己要解决什么问题。
很多人对中台的初始印象，就是解决业务重复建设、数据不通的问题。原来各个业务线各干各的，用户数据在电商部，会员数据在线下零售部，库存数据在物流部，要做一次全渠道用户分析，得跨三个部门走一周审批，最后拿到的数据还对不上。
传统企业业务部门数据孤岛示意图
这种情况做中台，方向没错。可做着做着就歪了。为了凑中台的“完整性”，什么模块都往里塞，从用户数据到供应链到办公OA，恨不得把整个公司的系统都重构一遍。说实话，大部分企业根本不需要这么大而全的东西。
我见过创业公司，才三条业务线，一共不到三百人，找咨询公司做方案，上来就要做“全域智能中台”，招了三十个人的技术团队，做了一年半还没上线，钱烧完了，项目直接烂尾。
中台从诞生那天起，核心就是降本增效，不是拿来给企业贴标签的。你要是连前端业务都没跑通，模式都没确定，谈什么中台？
中台战略实施，最大的坎从来不是技术，是利益
百分之八十的中台项目做砸，根本不是技术不行，是组织和利益没捋顺。
很多人觉得中台就是技术项目，扔给技术部就不管了。做出来推不动，才发现各个业务部门都在阳奉阴违。
原来每个业务部门都有自己的技术团队，自己的数据权限，自己的预算盘子。你搞中台，要把公共能力收上来，要把重复的人员裁掉，要把数据权限统一收归中台管，这不就是动了人家的奶酪？
我之前旁听一个中台项目启动会，各个部门经理表面都叫好，散会就跟自己人说“拖就完了，反正他中台也拿我们没办法”。结果呢，中台团队要数据，各个部门说系统正在升级，给不了，推了大半年，一点进展都没有。最后老板出面把两个不配合的部门经理换了，项目才往下走。
企业中台实施组织架构调整对比图
中台实施第一步，从来不是写代码搭框架，是拿到上层足够的授权，先把利益分配说清楚。
哪部分权力收上来，哪部分利益还给业务部门，原来的人员怎么安排，这些问题不解决，技术再牛也白搭。毕竟系统是死的，人是活的，人家不肯配合，你技术做的再完美也没人用。
适配自己的规模，别迷信大厂的完美中台
适配自己的规模，别迷信大厂的完美中台
现在市面上大部分中台方法论，都是大厂出来的。阿里当年做中台，打出名声之后，一堆人跟着学，不管自己公司规模多大，都要照着大厂的模板套。
大厂为什么要做全功能中台？人家几十上百条业务线，光用户登录、支付、风控这些基础能力，每个业务线做一遍，就是巨大的浪费，收上来做成中台，一年能省好几个亿的成本，当然划算。
你一个几百人的公司，总共才三五条业务线，你凑什么热闹？非要搞个几十人的中台团队，做个大而全的系统，最后算下来，省的钱还不够给中台团队发工资，这不是亏本买卖吗？
不过话说回来，也不是说小公司完全不能碰中台。而是要做轻中台，够用来就行。比如你做两个ToB产品，都需要用户登录、开票、支付，你把这几个公共能力抽出来，统一维护，那就是你的中台，没必要搞那么多花里胡哨的概念。
最近这两年行业里对中台的反思也多了，前几年那种疯话，已经没人说了。大家都务实了，能解决问题的就是好中台，解决不了问题，吹的再天花乱坠也没用。
我那个吐槽的CIO朋友，去年痛定思痛，把原来大而全的中台拆了，只保留了用户数据统一和全渠道支付两个核心模块，砍掉了三分之二的中台团队，反而业务提效了三成，每年还能省几百万维护费。
你看，很多时候不是中台不行，是做中台的人，一开始就想错了方向。把简单的事情复杂化，把工具做成了面子工程，那不踩坑才怪。