阿里前台业务

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

去年底阿里巴巴集团宣布组织结构全面升级，建设整合阿里产品技术和数据能力的强大中台，进而形成“小前台，大中台”的组织和业务体制，使前线业务更加灵动、敏捷，迎接未来新商业环境带来的机遇和挑战，笔者近期学习了下，简要谈谈个人理解。...

点击上方
蓝字关注公众号，让我们与数据同行！

阅读本文前，请您先点击本文标题下面的蓝色字体“与数据同行”再点击“关注”，这样您就可以分享一个大数据从业者的真实数据生活，独家数据观点！

去年底阿里巴巴集团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

历史文章

如何访问？请关注"与数据同行" 微信公众号，点击历史文章菜单或者右上的按钮-查看历史消息