阿里都拆中台了,为什么我们还死磕到底?

51CTO 2021-08-03
2531 字丨阅读本文需 7 分钟

中台的概念最早是由 2015 年阿里提出的“大中台,小前台”战略中衍生出来。作为解决企业多业务线发展到一定阶段后出现瓶颈的有效解决方案,一经提出各大互联网公司迅速跟进,如火如荼的进行中台建设。

巨头的背书效应,使得不仅互联网行业,连传统行业的数字化转型都纷纷向中台靠拢。

一时无两的风头使得中台的概念迅速火了起来,几乎成为行业标配,2019 年也被称为“中台元年”。

我们也是从那年开始规划采购中台,作为中台的坚定践行者目前相关项目仍在迭代优化。

但是到了 2020 年底,随着阿里掌门逍遥子要拆掉亲自搭建的大中台。业界对中台的质疑声逐渐多了起来“阻碍企业产品颠覆式创新变革”,“成本远超预算,加重企业负担”,“建设缓慢,效果未达预期”等等,再坚持做中台似乎有 “另类”之嫌。

对于逐渐走下神坛的中台,我们为什么还选择坚持呢?简言之:中台没有对错,合适既可所用。

阿里拆中台源自于逍遥子在内网发表的文章,里面表达了自己对目前阿里中台的不满“现在阿里的业务发展太慢,要把中台变薄,变得敏捷和快速”。

网传的阿里“拆中台”就此揭开序幕,整合了阿里雄厚的产品,技术及数据能力的大中台,成为革新的目标。

但不可否认的是中台化战略对阿里近五年业务的高速发展是功不可没的,其解决了随着阿里业务线拓展和组织不断膨胀带来的重复建设和树状结构,而导致的效率低下和资源浪费问题。

无论是屡创新高的双十一交易额,还是孵化的多个现象级产品都提供了有力证明。

那为什么又要拆中台呢?个人觉得主要两个原因:

①对手变了

近年来无论拼多多异军突起,还是抖音快手也开始从内容跨界电商行业,以及互联网巨头火拼社区团购都给阿里带来了巨大的挑战。

大中台因其自身庞大的架构和自身特性所限,无法为创新式业务提供敏捷快速的资源支撑,协助其尽快落地。

在以快著称的互联网行业,风口稍纵即逝,失去的先机可能需要花费对手几倍的代价才能挽回。

②场景变了

近几年伴随着移动通信设备的普及和相关通信技术的升级带来的移动互联网红利基本被瓜分殆尽,特别是起步较早的消费互联网也开始从增量期慢慢转为存量期。

如何解决第二曲线是各大企业都面临的问题,以大数据,人工智能,云计算为主的产业互联网是个趋势,但重新开辟新的赛道,目前的大中台也已经不足以支撑其快速落地。

基于以上两点大中台到了非拆不可的地步,正所谓破而后立。

“此拆非彼拆”阿里这里的拆不是彻底放弃中台,只是将庞大的共享中台事业部重新打散,下沉到业务端。

也可以理解为中台碎片化,将大中台拆解为一个个的独立的业务域中台,大中台不再负责具体业务,由专业的人做专业的事。

各个业务中台通过自身对业务的熟悉度,更容易发挥其灵活的特性,提供更多更细维度的服务以及组合。服务基数的增加也给组合创新带来更多的可能!

这就好比积木和磁力珠,大中台是将通用能力抽象后在企业内复用,这里的通用能力就像积木,其现成的形状可以快速搭建起来一个房子,但积木本身提供的形状毕竟是有限的,这也大大限制了发挥的空间。

而拆解后业务中台则可以更加灵活,依据自身对业务的熟悉还可以将服务能力进一步细化按需重组。

细化后的原子服务就像磁力珠,虽然单个看似微不足道,但是依靠自身磁力可以根据需要快速组合成各种形态,打破了积木形状的桎梏又不失其灵活性和复用性,为新业务特别是颠覆式创新的业务的快速试错提供快速有力的支撑。

我们的采购中台就是这样一个业务域的中台。最初的采购业务仅限于电器类,随着业务线的不断拓展,母婴,百货,极物等先后加入,特别是近两年小店,迪亚和家乐福带来的大快消融合为我们采购执行端带来巨大挑战。

快消业务的灵活性,多变性,将各种操作模式,业务模式,经营模式,以及特性业务需求穿插编织,导致创单业务类型层出不穷。

如果每个业务类型都对应一套独立的业务处理逻辑,就如下图所示,我们的系统结构和规模将惨不忍睹,给后期的优化和运维也挖了一个巨坑。

所幸从最初规划借鉴了中台的思想,当然没有完全照搬阿里的中台模式介入组织架构调整,更多的是从系统架构和定位上切入,这样也保障了采购中台的快速落地。

通过采购中台“集火”的采购执行端的服务能力,然后进行方便快捷的对外输出。

另外对底层的核心功能逐一进行梳理细化,通过迭代优化将服务打散抽离出业务特性,形成一个个独立的原子服务。

这样就可以根据业务需要迅速的组合成各种口径的“子弹”进行火力输出。

“此中非彼中”前面提到的中台无论是对阿里还是 Supercell 来说更像一个后台,一个提供通用能力的大后台。

而我们的采购中台除了作为采购执行端通用能力抽象层,还有一层含义就是位置上的中间层,处于业务链路的前台和后台之间,作为缓冲调和层而存在。

为什么需要调和缓冲层?这是我们的业务特性和所处环境所决定的。

首先采购前台作为和用户直接接触的产品部分,其主要职责是通过及时提供丰富的产品线,便捷灵活的功能操作来提升用户对产品的感知度和体验的满意度。

这也直接决定了前台业务逻辑不能太厚重,复杂的业务逻辑需要后移,通过降低业务复杂性提升前台的灵活性。

而采购执行的后端关联的系统呢,则包括了物流,库存,财务,结算等等这些巨无霸型的系统。

由于历史悠久,而且很多系统都是脱胎于 R3,除了本身业务逻辑复杂,再加上业务上合规性要求,流程上的限制以及业务的量级都导致系统复杂度很高。

所以出于安全,可靠,性能等方面的考虑,也不可能提供灵活快速的服务对接。

前台求快和后台求稳如同两个口径不兼容的齿轮很难协同工作,需要一个中间传导的齿轮进行协调,我们的采购中台就是这样一个传导齿轮。

作为位置意义上的中台又承担了哪些职责呢?对前台来说,中台需要承接那些影响前台灵活性的复杂业务逻辑,让前台尽可能的轻量级化。

另外还需要封装后台系统的一些因合规性或流程限制等等对前台提出的一些业务需求,而这些需求往往非常影响前台用户体验。这些都需要通过中台的合理屏蔽做到对前台业务无感。

对后台系统来说,作为巨无霸系统的中间层,通过中台的中转和适配,可以更好的加快对接效率。

通过一年多项目的迭代也证明了中台对我们业务是合适的,这也是我们坚持走中台之路的信心来源。

但是这里还要强调的是任何解决方案的提出都是有其业务背景的,如同世界上不存在两片完全相同的叶子,也不存在完全相同业务背景的两家企业。

脱离业务背景的解决方案都是盲目的,生搬硬套最终带来的永远是一地鸡毛,所以“中台没有对错”!

作者:胥磊

简介:苏宁易购供应链 BU 采购管理研发中心采购中台技术负责人,对供应链采购业务域有丰富业务经验和系统建设经验。主导了苏宁采购平台的搭建,以及向采购中台的演进的技术架构设计。对系统架构,代码架构以及数据架构设计和优化有较丰富的经验和心得,目前在主导推进采购中台的 DDD 改造。

【51CTO原创稿件,合作站点转载请注明原文作者和出处】

免责声明:凡注明来源本网的所有作品,均为本网合法拥有版权或有权使用的作品,欢迎转载,注明出处本网。非本网作品均来自其他媒体,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责。如您发现有任何侵权内容,请依照下方联系方式进行沟通,我们将第一时间进行处理。

0赞 好资讯,需要你的鼓励
来自:51CTO
0

参与评论

登录后参与讨论 0/1000

为你推荐

加载中...