阿里组织架构的”大中台+小前台“

刺骨的言语ヽ痛彻心扉 2022-04-24 10:34 338阅读 0赞

**[分享一个大神的人工智能教程。零基础！通俗易懂！风趣幽默！还带黄段子！希望你也加入到人工智能的队伍中来！点击浏览教程][Link 1]**

# **一、什么是“大中台、小前台”** #

**关键词：**精准打击、管理高效、资源整合、灵活敏捷

阿里巴巴 “大中台、小前台”机制的提出，**某种程度上是从传统的事业部制向准事业部制的转换。**就阿里巴巴而言，**“前台”**就是**贴近最终用户/商家的业务部门**，包括零售电商、广告业务、云计算、物流以及其它创新业务等；而**“中台”**则是**强调资源整合、能力沉淀的平台体系**，为“前台”的业务开展**提供底层的技术、数据等资源和能力的支持**，中台将集合整个集团的运营数据能力、产品技术能力，对各前台业务形成**强力支撑**。

前台和中台本质上是工作分工的问题。比如，某部门要开发一款App，**是部门内部（大前台）自己组织**一套技术、产品、设计、运营的团队，还是**集团为其提供资源（大中台）**，由专门的技术团队来帮助其开发、设计产品等等。

所以说，** “小前台+大中台”**的运营模式，就是美军的**“特种部队（小前台）+航母舰群（大中台）”**的组织结构方式，以**促进管理更加扁平化**。十几人甚至几人组成的特种部队在战场一线，可以根据实际情况迅速决策，并引导精准打击。而精准打击的导弹往往是从航母舰群上发射而出，后方会提供强大的侦查火力后勤支援。所以如果**中台**没有办法**承接前线的需求**，前线就会不认可它服务的价值。

# **二、****原因、解决的问题** #

**关键词：**组织膨胀、避免重复、加强集权、管理高效、资源整合、灵活敏捷、存在风险

当我们开展具体的业务时，**每个团队都需要**有技术、产品、市场等方面的**基础支持**，传统互联网公司的每个业务部门都会有自己专属的业务、市场、产品等人员。随着公司的发展壮大，许多业务部门内**提供基础支持的工作可能会有很大程度上的重复**（**例：**两个相互独立的业务部门同时开发APP，两个团队很可能在同时开发同样的功能，重复解决同样技术问题，同时写差不多的代码），**信息不能共享，导致许多资源被浪费。**

并且，每个业务团队的**水平参差不齐**，怎样使每个团队都能够在既保证质量、又保证效率的前提下完成任务。为此，我们急需一个有效的机制来将公司内部的技术、数据、产品等**资源进行整合，统一为业务线提供支持和帮助。**同时，各事业部就像一个个子公司，都是实行独立核算，导致各事业部往往**从自身利益出发**，影响事业部之间的协作，**难以形成企业合力**。

阿里巴巴近年来迅速扩张、员工众多，所以可能会存在管理不善、效率低下、各事业部各自为政等问题。为了解决以上问题，阿里提出了“大中台，小前台”机制。“小前台+大中台”的运营模式促使组织管理更加扁平化，使得**管理更加高效，组织运作效率提高，业务更加敏捷灵活：**

其“中台”的设置就是为了提炼各个业务条线的共性需求，并将这些打造成组件化的资源包，然后以接口的形式提供给前台各业务部门使用，可以使产品在更新迭代、创新拓展的过程中**研发更灵活、业务更敏捷**，**最大限度地减少“重复造轮子”的KPI项目**。前台要做什么业务，需要什么资源可以直接同公共服务部要。搜索、共享组件、数据技术等模块不需要每次去改动底层进行研发，而是**在底层不变动的情况下，在更丰富灵活的“大中台”基础上获取支持，让“小前台”更加灵活敏捷**，让每一个新的前台业务创新能够真正意义上“站在阿里巴巴这个巨人的肩膀上”，而不用每次开辟一个新业务都像新建一家创业公司那么艰难。

# **三、具体做法** #

**关键词：**组织架构调整、整合支持、网状结构、设立中台事业群、业务小前台

**（1）阿里巴巴的组织架构调整**

一直以“拥抱变化”著称的阿里巴巴，于2015年12月7日公布了新一轮组织调整。已经拥有3万员工的阿里巴巴将此前的**“树状”管理模式改为“网状”**，成立**整合**数据、搜索等技术平台的**“中台事业群”**，对**前台**各业务模块进行**整合支持**。

**【整合前（2013年）阿里巴巴组织架构】**

2013年的阿里巴巴把**具体业务划分为了9类**，并对每一块的业务进行了很明确的**细分**，共下设**25个事业部**，分别由9名事业部总裁负责。这时的组织架构是较为传统的**树状结构。**

**【调整后阿里巴巴的组织架构】**

2015年经过调整后阿里巴巴的组织架构不再是传统的树状结构，而变成了**网状结构**。同时，其不再采用具体的业务模块下分设事业部的方式，而是将之前细分的25个事业部打乱，根据具体业务将其中一些能够为业务线提供基础技术、数据等支持的部门**整合成为“大中台”**，统一为业务线提供支持和帮助。

### **四、问题与建议** ###

### **1、【问题】** ###

**① 中台无法为前台提供其想要的支持和帮助**

首先，是**因为资源有限**，中台无法为前台提供其想要的支持和帮助。在开展业务的过程中，各前台会向中台提出需求，因为中台的资源有限，所以当中台收到许多来自前线团队提出的需求后会**进行评估**。如果其认为某个前台项目的重要程度比较低，拒绝为前台提供支持。那么这个前台可能会为自己的业绩考虑去**自行组团队完成项目，**这就与传统的事业部制没有什么区别了。所以说，如果中台和前台**没有找好平衡点的话，这种机制很容易被破坏**。同时，也存在中台**能力受限**无法为前台提供有力支持的情况，最后项目做出来的效果可能与前台所想相差甚远。

同时，此制度**受限于中台的知识沉淀的能力，沟通协调能力和其对前台知识理解的能力等**，这些都是非常大的挑战。

**② 中台和前台分工不明确**

中台和前台之间存在许多**灰色地带**，这个时候就会出现**分工不明确**的问题：**哪些工作是属于前台的，哪些工作是属于中台的？**面对某一具体业务时，这一块任务是应该让中台来为业务线提供支持，还是让业务线自己做？如果中台和业务线都去完成这个任务，**工作上**会不会**有重复**？会不会有前台和中台之间**互相推诿“踢皮球”**的情况发生？

**③ 传统的绩效考核方式不再适用**

中台用**怎样的标准去衡量**前台的业务值不值得提供支持？**以什么为评估依据去分配资源**？如果中台为许多小前台提供了差不多的支持，而最后只有一个小前台完成了业务目标，**利润要怎么分配**？如果所有小前台都没有达成业务目标怎么办？

### **2、【建议】** ###

**关键词：**重建绩效考核体系 、划分清楚灰色地带、进行培训、评估过程标准化

针对以上三个问题，我提出了以下解决方法：

**① 最大程度上对资源进行整合**：以保证中台能够为各个小前台提供强有力的支持。

**② 建立评估部门，将评估过程标准化**：组建专业的评估部门去对小前台开展的业务进行考察和评价，并根据评估结果向中台提出建议，使中台能够将资源合理分配。

**③ 建立业务bp岗位（类似hrbp）：**深入前台了解前台的业务需求并反馈给中台，在前台和中台中起到沟通和协调作用，以免前台、中台有重复完成同一工作或“踢皮球”的情况发生。

[Link 1]: http://www.captainbed.net/haiyang