甜腻的嘴角|头部电商的中台实践血泪总结

在企业业务发展中 , 中台是个很重要的存在 。 本文作者以自己的亲身经历 , 从三个方面围绕中台进行讲述 , 希望对你有帮助 。
甜腻的嘴角|头部电商的中台实践血泪总结从19年中开始 , 中台概念的热度突然间蹭的一下就上去了 , 而我所在的企业(某头部电商企业)则在去年年底提出了全面建设中台的战略 , 于是我便吭哧吭哧的在中台这个大坑里倒腾了大半年 , 期间起起伏伏的血泪总结 , 将在后文中与君分享 , 并借此分享真心希望帮助即将走上中台建设与正在进行中台建设的朋友们少走弯路 。
一、中台的缘起明确中台建设的目的十分重要!十分重要!十分重要!
关于中台的缘起 , 想必阿里的例子 , 大家已经听得耳朵起茧了:为了快速支持业务扩展 , 同时降低开发成本 , 阿里把能够通用的服务抽离出来并以中台的形式来提供共享服务 。
那么 , 在这一句大家都耳熟能详的关于中台的定义中 , 中台它最核心的目标又是什么呢?
避免重复开发?
抽离通用服务?
不 , 这些都只是手段 。
中台最核心的目标 , 没有之一 , 就是快速响应业务诉求 。
以终为始 , 方得善终 。
以我们中台项目团队的亲身经历来回顾的话 , 在整个项目的一开始 , 领导给项目团队制定的目标就是 , 减少系统之间的重复开发 , 最短时间内 , 先把能够抽象的公共服务完成打造 。
整个项目团队 , 二三十号人 , 吭哧吭哧的搞了好几个月之后 , 总算是把第一阶段的公共服务完成交付了 。
但是极其残酷的现实摆在面前:业务团队根本不买单 , 而且毫不避讳地说这个东西的作用不大 。
而在这一堆的公共服务打造的这几个月里 , 所有的业务需求几乎全部停滞 。
换句话来说 , 在这几个月的中台的打造工程中 , 我们只是把原来已有的系统进行重新整合或者重构 , 又或者说是把原来一些业务同学认为并不是十分重要的功能模块实现了通用化打造 , 但对于业务同学来说 , 最急最痛的一些东西 , 并没有得到很好的满足 。
总结起来就是 , 你给的我不要 , 我要的你不给 。
为什么会得到这一荒诞的结果呢?
很重要的一个原因就是 , 把目的和手段搞反了:为了做中台而做中台 , 为了通用化而通用化 。
但我们不妨再细想一层 , 我们为什么要做中台?我们为什么要做通用化?这不都是为了更快速的响应业务的诉求吗?
所以说 , 建设中台的目的 , 从来都是为了快速有效的响应业务诉求 , 通用化这些都只是手段而已 。
二、中台的定义关于中台的定义 , 我十分认同王健老师的观点:中台就是企业级能力的复用 。
拿大家熟悉的阿里巴巴的例子来说 , 他们把电商业务核心的模块都抽里出来 , 并以共享的形式对前台提供服务 , 这些核心的业务模块包含:用户中心 , 商品中心 , 交易中心 , 支付中心 , 库存中心 , 物流中心 。
而这些中心本质上就是阿里这个电商帝国核心的企业级能力 , 阿里通过把这些核心能力的中台化 , 让阿里的电商版图在业务扩张的过程中 , 能够快速的复用这些核心能力 , 最终达到快速响应业务的目的 。
下面我们来一一细数这中台定义的关键词 。
企业级:
企业级 , 就是说 , 中台这个东西 , 在设计的时候 , 就应该站在全盘来考虑 , 做出来的东西定位是企业层的某项能力 , 而不单单是某个业务线或者某个项目组内部使用 。 站在全盘的角度来进行业务的抽象与复用 , 站在全盘的角度来考虑数据服务的融合与通用 , 并借此支持业务的快速与低成本的扩展 。
基于上面的阐述:中台做出来的东西定位是企业层级的某项通用能力 , 中台的打造大概率涉及业务线和组织的调整 , 如原先独立的两条业务线的交易模块 , 在打造中台的交易中心的时候 , 必定涉及原先这两个团队中该系统模块的整合与人员的调整;这样的调整下 , 必定需要由公司高层出面推进 , 即自上而下的推动 , 推动业务线的整合 , 推动利益的重新分配 。