在一条知乎高赞答案里有这样一个场景：
“某个业务部门里面的研发小A，他想做个新业务，在传统组织下，他要搞定的流程，我们来脑补一下，首先自下而上搞定他的Leader，再搞定总监，如果这个组织大到有研发GM，那么再搞定一次。然后开始自下而上配备资源，由上面下命令，产品设计配合，运营市场配合，最后落地到个人配合。就算我们假设当中任何一个环节都赞同了，他费尽千辛万苦搞定了9个关键人，开始落地。这沟通成本有多高？这时间耗费有多长？”
互联网公司在发展初期受益于灵活多变的组织形态，创新成本低，更扁平，员工的声音直达上级。但随着像阿里这样的头部企业日渐膨胀，就会因为组织架构与管理机制的不协调而催生很多乱象：部门也越来越多，分工越来越细。某个员工为了创新，需要协调研发，产品及运营等多个部门，成本其实非常高。现在国内百人往上的互联网公司，尤其是已经上市的公司，谁不是“部门墙”“业务墙”高立，谁不头疼这几个问题？
为什么一堆人从大厂离职创业，除了资本原因，大半都是受不了资源的掣肘。除了行政人力财务商务，还有部门内部的各个小组都难以驾驭。好不容易谈上了，跟我的KPI没有关系？不做了。
从这个意义上讲，看上去很高大上的互联网公司其实本质上和草莽期的一般民营企业并无二致。对很多民营企业而言，经过十几年的高速发展，组织已经庞大而复杂，业务也不像当初那么单一而独立。同时，整个行业的成熟也倒逼企业与企业之间的竞争提升到“向管理要效率”的高度。
阿里“中台战略”的来历
阿里巴巴“大中台小前台”这个提法最早是在2015年，CEO张勇在一封内部信里宣布启动“中台战略”，构建更创新灵活的“大中台、小前台”机制。
2015年之前，阿里巴巴把具体业务划分为9类，下设25个事业部，分别由9名事业部总裁负责。这是较为传统的树状结构。
调整之后，阿里巴巴变成了网状结构。将25个事业部打乱，根据具体业务将其中一些能够为业务线提供基础技术、数据等支持的部门整合成为“大中台”，统一为业务线提供支持和帮助。
网上对这个战略也有不少看法，众说纷纭。我们参考了知乎上的一些发言，和大家聊聊阿里的这个新动作。
这个思路的来历有两种江湖传说：
一说是来自美军的“特种部队+航母舰群”， 70%的钱用来找目标，30%的钱花在直接摧毁目标上。十几人甚至几人组成的特种部队在战场一线，而精准打击的导弹从航母舰群上发射而出，后方会提供强大的侦查火力后勤支援。专家型的小团队，配合全功能技术顶尖不差钱的大后方，指哪打哪。既做到了扁平、迅速，又能集中火力，不浪费弹药物资。
第二种说法：管理哲学一向天马行空的马老师，有一次参观北欧游戏公司Supercell看到大中台架构，于是深受启发。Supercell的大中台避免了大公司常见的部门与部门争夺资源，不同的小组做同样的事情。能够快速出原型，快速试错，失败后全公司开香槟庆祝，对了资源堆上。天下武功，唯快不破。当然这是最理想的情况。就算是学不全，只要能解决内耗的问题，也是大功一件。
还有一个好处，技术人员可以安心下来做技术，不用想什么劳什子30之后转管理，40之后当经理。技术是手艺，是跌跌撞撞拿钱喂出来的，就这么放弃了？还不是被公司制度逼的。这事两年前就有人在说在盼了，但由马老师亲自拍板开始干，还是很有魄力的。
“小前台，大中台”是什么？
其实所谓的“前台-中台-后台”的概念并不是什么新鲜事，在金融、制造、零售等领域已经实行多年，愈是大型的组织愈是依赖这种三层架构。
“中台”的设置就是为了提炼各个业务条线的共性需求，并将这些打造成组件化的资源包，然后以接口的形式提供给前台各业务部门使用，可以使产品在更新迭代、创新拓展的过程中研发更灵活、业务更敏捷，最大限度地减少“重复造轮子”的KPI项目。
如果培养出了适应这种打法的后方力量，就会进入一个良性循环，能够适应各种场景的多功能全球分布式系统，简单易用、算法模型丰富的推荐、搜索、广告投放、数据分析系统，更别提基本的运维监控平台等，这些技术系统之外，还有公关、法务、市场等全方位支持。
“前台”要做什么业务，需要什么资源可以直接同公共服务部要。搜索、共享组件、数据技术等模块不需要每次去改动底层进行研发，而是在底层不变动的情况下。这样的平台化东西越多，也就越充实后方力量，前方的精英团队就可以专注于达到目的。
还是举之前小A的例子。
小A又要搞个新业务，这次他去搞定业务线的老大：给我三个人，我们一起搞业务D。业务线老大想想看，嗯~历史上小A还是蛮靠谱的，做吧。你这几个人负责业务的方向和差异化资源的落地。至于其他的公共资源，直接找公线要吧。于是小A从公线要到了一大堆被公线打磨过很多的公共模块，拼装一下，然后把差异化的部分合进去，开搞！
核心原因
所以阿里为什么要搞“小前台、大中台”模式？
核心原因有两个：
组织庞大，沟通低效，阻碍试错。
随着像阿里部门也越来越多，分工越来越细，某个员工为了创新，需要协调研发，产品及运营等多个部门，创新成本已经非常高。IT服务需要不断有新的业务接入，才能从最初仅提供单薄功能逐渐成长为宝贵的IT资产。产品开发在当下市场上也是唯快不破，试错和创新有时甚至可以划等号，共享服务平台的快速编排、组合服务可以极大降低前端试错成本。这在传统模式中是几乎不可能的。
重复造轮，资源浪费，无法成长。
做IT的都知道，如果IT自己不创新，或者环境不给你创新的机会，可能90%以上的时间是在跟需求扯皮和重复开发中度过的。比如两个相互独立的业务部门同时开发APP，两个团队很可能在同时开发同样的功能，重复解决同样技术问题，同时写差不多的代码，信息不能共享，导致许多资源被浪费，例如淘宝和天猫就不必各自开都开发一个评价服务。
这带来的另一个问题就是这些满足被动需求的工作对能力增长有限，长此以往会驱逐优秀员工，或者抑制年轻人的发展。
简而言之，阿里搞“小前台+大中台”的组织模式，核心目的是希望能够促使组织管理更加扁平化，使得管理更加高效，组织运作效率提高，业务更加敏捷灵活。
“大中台”面临的问题
大中台和小前台的博弈
中台人员没有接触市场，不了解需求，在资源有限的前提下，中台能客观理解需求并评估多个项目的价值并做取舍吗？如何让大中台触角需要向前衍生，比业务更懂业务的本质？这里需要有一批既懂业务也懂技术的中坚力量，阿里让行癫做这个事情，应该是希望大中台的人对于业务和技术都有足够的话语权。这个问题的解决依赖于大中台的管理能力，不能太硬，也不要太软，长短结合，做好平衡。
大中台的能力中心定位
我们在进行产品设计时，一方面要考虑产品对业务支持的程度，另一方面要考虑产品对其他及潜在业务支持的通用性。如果产品对某一具体业务的支持力度过大，无疑问可以更有效地推进业务的发展，然而带来的问题是，当出现其他业务甚至相关业务时，原有产品并不能支持。
大中台的纵向划分体系
对于阿里这样的大集团来讲，大中台也不是铁板一块，个人认为需要特别关注以下三个方面：
首先，大中台需要划分纵向模块，大中台涉及到各条业务技术线资源的重新规划、整合和重新划分，这是非常有挑战的事情，如果划得过粗，资源整合有利，但对于业务的响应就会变慢，反之亦然。
其次，针对大中台每大类业务应该适配特定的技术平台、人力资源和管理流程等，因此这涉及对于业务，技术和管理的较高挑战。
最后，大中台是个非常讲究战略方向、标准化、规范化的特定组织和系统，其能力和资源的整合的直接驱动力来自于自身对于业务的主动分析，而不是被动承接的特定业务，因此特别强调工作的主动性和创造性，也特别容易流于形式。
商机稍纵即逝，如果中台速度过慢，时间耽误了谁负责？是否允许前台自己做，等成熟了中台再来整合好了？大中台的起步实施难度很大，短时间内往往由于中台不够强大，或者贯彻不彻底，会造成大量的妥协，使得中台被业务牵着鼻子走，最后反倒变得散沙一盘。
大中台的KPI考核问题
大中台是个上不顶天，下不立地的组织，一方面不能简单的按照业务和收入KPI进行考核，因为能做多少收入不是它能掌控的，毕竟它是个能力和成本中心，不是个利润中心，又不能按照IT系统的方式去考核它，否则离业务太远，资源整合的业务价值没法体现，同时你还不能简单的以一年为单位来考核它，因为能力中心的建立不是一朝一夕之事，你按年考核它，它就会急功近利。
也许只能以平台化产品数量，平台产品对于业务的覆盖程度及响应能力、资源的节省程度来进行适当的考核，甚至起步阶段它耗费的资源可能远超以往，毕竟老的业务不能下，新的平台还未建立，总要有个过渡过程，当然也是一家之言了。
另外，国内的企业管理者技术出身的比例不大，对于中台的理解有限，传统企业有几个CEO是真正懂的，一定程度上造成业务人员高人一等的现象。毕竟KPI为王，企业大多数时候，还是屁股决定脑袋的，但做百年老店拼的不是起跑线，而是谁的耐力更久，在移动互联网时代更是如此了。
建议
针对这些问题，也有一些建议的声音：
1、 最大程度上对资源进行整合：以保证中台能够为各个小前台提供强有力的支持。
2、 建立评估部门，将评估过程标准化：组建专业的评估部门去对小前台开展的业务进行考察和评价，并根据评估结果向中台提出建议，使中台能够将资源合理分配。
3、 建立业务bp岗位（类似hrbp）：深入前台了解前台的业务需求并反馈给中台，在前台和中台中起到沟通和协调作用，以免前台、中台有重复完成同一工作或“踢皮球”的情况发生。
考虑到阿里这么大的体量，大中台的初期可能第一要务更多应是资源的集中管理，其次才是做能力的抽象，最后，至少应留出足够的灵活性和绿色通道去支撑业务蓝海的开拓，从这个角度讲，大中台也并不是纯粹的大中台，是兼具稳定性和灵活性的混合台。
阿里巴巴这次以及之前的数次组织架构调整，其实背后反映了小公司长成大公司的过程中所必须经历的规范化与正规化历程。
而这，也是其它的互联网公司迟早都需要经历的——这是否也意味着中国互联网的发展将进入到“新常态”了呢？
也许你还想看…
点击标题直接阅读
联系客服
