艰难的抉择,阿里“小前台、大中台”的解读

审核去年底阿里巴巴集团CEO发出内部信,宣布组织结构全面升级,建设整合阿里产品技术和数据能力的强大中台,进而形成“小前台,大中台”的组织和业务体制,使前线业务更加灵动、敏捷,迎接未来新商业环境带来的机遇和挑战。同时,让集团更多优秀的年轻人承担起更大的责任。

当前网上对于这个战略也有了不少看法,大家众说纷纭,笔者参考了知乎上的部分言论, 结合自己的学习和想法,我就当一回知识的搬运工,谈谈阿里的这个战略。

阿里所以要搞“小前台、大中台”,大致应该有以下三个原因:
Part 1

为什么要搞“小前台、大中台”
部门众多抑制了创新环境

以前我们曾经非常羡慕互联网公司的组织结构,比如较传统公司更加扁平化,员工的声音能直达上级,创新成本较低,但实际上,随着像阿里这类公司的逐步壮大,其部门也越来越多,分工越来越细,某个员工为了创新,需要协调研发,产品及运营等多个部门,沟通过多,创新成本已经非常高,这应该是阿里下决心进行组织变革的一个主要原因,下图示例出自知呼。
“某个业务部门里面的研发小A,他想做个新业务,在传统组织下,他要搞定的流程,我们来脑补一下,首先自下而上搞定他的Leader,再搞定总监,如果这个组织大到有研发GM,那么再搞定和说服一次。然后开始自下而上配备资源,由上面下命令,产品设计配合,运营市场配合,最后落地到个人配合。就算我们假设当中任何一个环节都赞同了,他费尽千辛万苦搞定了9个关键人,开始落地。这沟通成本有多高?这时间耗费有多长?”

在这种玩法下,玩个毛线创新。

山头林立资源无法整合

我们先用贝恩咨询的一段IT的评价开始:

“企业的不同各部门提出了独立且迥异的方案,每个方案都是为相互独立的目的服务,IT部门为满足不同的(有时是相互冲突的)业务部门搭建了一组拜占庭风格的复杂系统,功能相互重合的系统可能短时间内满足了一些个别部门的需求,但却没能在整体上推进公司业务的发展。

他们为独特的业务需求构建了定制化的最佳解决方案、然而,他们忽略了标准化以及对现有系统的升级。他们在旧的复杂性上面创造了新的复杂性的迷宫,从而使系统的升级和架构的改善变得更加困难,同时丧失了规模经济的机会。效率很差的IT部门即使朝着正确的业务目标努力,也不会达到目标”。

这是一个非常精辟的解释。如果你还有疑惑,我就打个比分:“C语言的函数之所有存在是为了将一些可复用的公共功能封装起来,从而让C语言的代码编写更加快速而高效,否则每个开发者用C语言画一条线都需要自己去写代码打点,这个效率是很低的”。

UBDC全域大数据峰会·2016上,阿里巴巴公共数据平台负责人罗金鹏提到,在没有建设统一的数据公共层时,阿里内部服务器需求量会在5年之后达到现在的100倍之多。而经过数据公共层的统一建设,5年后的服务器需求量相对会节约90%。姑且不说是否能真正实现,也算是一个宏大目标吧。

员工缺乏发展机会

做IT的都知道,如果我们自己不创新,或者环境不给你创新的机会,可能90%以上的时间是在跟需求的扯皮和重复性的开发中度过的,满足需求和创造需求是两个层面的事情,前者是被动的,能力增长有限,而后者如果企业缺乏高效的创新环境,则会驱逐优秀员工,或者抑制年轻人的发展。

搞技术是门很深的学问,有个说法我是不太认可的,说IT人员嘛,有一条发展路径就是写代码-搞设计-做架构-转管理-换部门,实际往往造成一个企业动嘴皮子的越来越多,动手的越来越少,管理层级越来越多的现象,而IT的真正核心能力却无法积累,最终导致IT的竞争力下滑,面对业务问题往往只能采取竖井式开发模式,从头做到底,从而疲于奔命。

国内的企业管理者技术出生的比例不大,对于中台的理解有限,传统企业有几个CEO是真正懂的,一定程度上造成业务人员高人一等的现象,毕竟KPI为王,企业大多数时候,还是屁股决定脑袋的,但从长远角度讲,只关注当下是个大问题,因为做百年老店拼的不是起跑线,而是谁的耐力更久,在移动互联网时代更是如此了。
Part 2

什么是“小前台、大中台”
阿里的“小前台、大中台”模式就是为了解决这个问题提出的,下图是个组织重构后的一个示例,一目了然,终极目标就是“鼓励创新,资源整合”:
“小A想要搞个新业务,此时他搞定业务线的老大:给我三个人,我们一起搞业务D。业务线老大想想看,嗯~历史上小A还是蛮靠谱的,做吧。你这几个人负责业务的方向和差异化资源的落地。至于其他的公共资源,直接找公线要吧。于是小A从公线要到了一大堆被公线打磨过很多的公共模块,拼装一下,然后把差异化的部分合进去,开搞!”
Part 3

面临的挑战和思考
但这种模式面临的挑战还是比较大的,个人认为重点有以下四大方面:

大中台和小前台的权利博弈

一个企业内,业务部门由于背负着KPI指标,因此话语权相对会大一点,一旦有了强有力的中台,就会涉及谁做主的问题,涉及2个方面的问题:

中台人员没有接触市场,不了解需求,在资源有限的前提下,中台能客观理解需求并评估多个项目的价值并做取舍吗?笔者认为解决之道就是大中台触角需要向前衍生,比业务更懂业务的本质,需要有一批既懂业务也懂技术的中坚力量,阿里让行癫做这个事情,应该是希望大中台的人对于业务和技术都有足够的话语权。

商机稍纵即逝,加了中台,时间耽误了谁负责,是否允许前台自己做,等成熟了中台再来整合好了,这个问题的解决依赖于大中台的管理能力,可以做些变通和妥协,不能太硬,也不要太软,长短结合,做好平衡。

总之,大中台立足于长远和全局,前台立足于当下和局部,这个问题其实没有标准答案,全赖于企业根据自身的实际做成合适的调整。

大中台的能力中心定位

我们在进行产品设计时,一方面要考虑产品对业务支持的程度,另一方面要考虑产品对其他及潜在业务支持的通用性。如果产品对某一具体业务的支持力度过大,无疑问可以更有效地推进业务的发展,然而带来的问题是,当出现其他业务甚至相关业务时,原有产品并不能支持。

比如拿笔者以前做的报表体系举例,也存在同样的问题,业务人员提报表需求,中台人员评估提出更好的指标解决方案,可以适配未来更多的报表场景,但业务人员并不认可,认为虽然方案很好,但需要花更多的时间,当前报表做得简单点能快速满足客户需求,下一个客户的满足跟他有什么关系。

阿里提出“大中台”的概念,是希望能够将底层技术与产品“中台化”,从而让产品在更新迭代、创新拓展的过程中研发更灵活、业务更敏捷。搜索、共享组件、数据技术等模块不需要每次去改动底层进行研发,而是在底层不变动的情况在更丰富灵活的“大中台”基础上获取支持,让“小前台”更加灵活敏捷。

大中台的纵向划分体系

对于阿里这样的大集团来讲,大中台也不是铁板一块,个人认为需要特别关注以下三个方面:

首先,大中台需要划分纵向模块,大中台涉及到各条业务技术线资源的重新规划、整合和重新划分,这是非常有挑战的事情,如果划得过粗,资源整合有利,但对于业务的响应就会变慢,反之亦然。

其次,针对大中台每大类业务应该适配特定的技术平台、人力资源和管理流程等,因此这涉及对于业务,技术和管理的较高挑战。

最后,大中台是个非常讲究战略方向、标准化、规范化的特定组织和系统,其能力和资源的整合的直接驱动力来自于自身对于业务的主动分析,而不是被动承接的特定业务,因此特别强调工作的主动性和创造性,也特别容易流于形式。

笔者认为大中台的起步实施难度很大,因为短时间内往往由于中台不够强大,或者贯彻不彻底,会造成大量的妥协,使得中台被业务牵着鼻子走,最后反倒变得散沙一盘。

大中台的KPI考核问题

大中台是个上不顶天,下不立地的组织,一方面不能简单的按照业务和收入KPI进行考核,因为能做多少收入不是它能掌控的,毕竟它是个能力和成本中心,不是个利润中心,又不能按照IT系统的方式去考核它,否则离业务太远,资源整合的业务价值没法体现,同时你还不能简单的以一年为单位来考核它,因为能力中心的建立不是一朝一夕之事,你按年考核它,它就会急功近利。

也许只能以平台化产品数量,平台产品对于业务的覆盖程度及响应能力、资源的节省程度来进行适当的考核,甚至起步阶段它耗费的资源可能远超以往,毕竟,老的业务不能下,新的平台还未建立,总要有个过渡过程,当然也是一家之言了。
Part 4

笔者的探索和实践

“小前台、大中台”要有生命力,不是搞个突击或完成一个重大项目、封装一些能力就可以了,实际上更关键的是机制、流程上的自我革命。

笔者以前搞过公司的统一指标体系,设想是通过一个项目把所有的指标标准化,我们花了很大经历去调研一线指标,好不容易打造了一个基本统一的指标体系,虽然初期运行的还可以,但随着时间流逝,各种不规范,各种临时性的开发要求不断冒出,指标的管理最终还是失控,指标的中台也逐步塌陷,因此,没有组织、机制和流程上的同步改造,实际上这个战略很难成功。

很多时候我们建设一个类似中台的项目很热情(其实任何架构层面的改造多多少少有中台的痕迹),但维持却很困难,只管杀不管埋是经常的现象,在IT建设中几年就推倒重来的事情其实也很多。但即使是推倒重来,你也会发现以前的积淀太少,可复用的东西太少,代价是何其之大。

当前,笔者的团队在大数据建模上也在采用类似中台的概念,我们在组织上成立了公司独立的建模团队,跟开发团队完全分离,建模团队的目标是建立标准、控制流程、持续迭代,我们会评估每个开发需求的合规性,比如模型是否已经能够支撑开发,不断从开发需求中提炼共性的元素,作为模型团队建模的输入,从而完善大数据的DW层,从当前运行的效果看,当有专职团队来管理建模规范和强调复用性的时候,的确规范性好很多很多,而且它是能迭代的,开发团队再也不能想怎么来就怎么来了。至于是否降低了一定的效率,其实很难说,成果有待时间的检验。但做这个事情,肯定对“我们要做102年的企业,横跨三个世纪”这句话有一定认同度。

笔者也只是谈了一点小的实践,跟阿里这么复杂的业务和系统无法比,但道理是相通的。
Part 5

结语


“小前台,大中台”这种组织形式,并不是什么新鲜事物,实际上其是一种理想化的支撑模式,前台业务足够灵活,配套支撑足够快捷,资源还能够高效复用,但适用范围还是有限的,比如企业要有一定规模,业务要比较丰富,值得去提炼共性元素,不能一概而论。

考虑到阿里这么大的体量,因此大中台的初期可能第一要务更多应是资源的集中管理,其次才是做能力的抽象,最后,至少应留出足够的灵活性和绿色通道去支撑业务蓝海的开拓,从这个角度讲,大中台也并不是纯粹的大中台,是兼具稳定性和灵活性的混合台。

本文部分图例参考知乎

作者:李恺

https://www.zhihu.com/question/38278138/answer/75771138

作者:李丹华

https://www.zhihu.com/question/38278138/answer/77748126
展开阅读全文

没有更多推荐了,返回首页