zoukankan      html  css  js  c++  java
  • 大中台+小前台概念

    作者:东子
    链接:https://www.zhihu.com/question/38278138/answer/164057098
    来源:知乎
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

    1.什么是“大中台、小前台”

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

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

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

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

    2.原因、解决的问题

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

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

    并且,每个业务团队的水平参差不齐,怎样使每个团队都能够在既保证质量、又保证效率的前提下完成任务。为此,我们急需一个有效的机制来将公司内部的技术、数据、产品等资源进行整合,统一为业务线提供支持和帮助。

    同时,各事业部就像一个个子公司,都是实行独立核算,导致各事业部往往从自身利益出发,影响事业部之间的协作,难以形成企业合力。

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

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

    3.具体做法

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

    (1)阿里巴巴的组织架构调整

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

    【整合前(2013年)阿里巴巴组织架构】

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

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

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

    4.问题与建议

    【问题】

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

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

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

    ② 中台和前台分工不明确

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

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

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

    【建议】

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

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

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

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

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

  • 相关阅读:
    linux驱动开发学习一:创建一个字符设备
    如何高效的对有序数组去重
    找到缺失的第一个正整数
    .NET不可变集合已经正式发布
    中国人唯一不认可的成功——就是家庭的和睦,人生的平淡【转】
    自己动手搭建 MongoDB 环境,并建立一个 .NET HelloWorld 程序测试
    ASP.NET MVC 中如何用自定义 Handler 来处理来自 AJAX 请求的 HttpRequestValidationException 错误
    自己动手搭建 Redis 环境,并建立一个 .NET HelloWorld 程序测试
    ServiceStack 介绍
    一步一步实战扩展 ASP.NET Route,实现小写 URL、个性化 URL
  • 原文地址:https://www.cnblogs.com/UncleWang001/p/10979807.html
Copyright © 2011-2022 走看看