如何看待阿里巴巴最新的「大中台，小前台」组织架构？

前两天跟一位负责Lead某业务的同事聊天，说过这样一番话：我们大概花了4年多一点的时间，从无到有，让一个非腾讯名义的新业务，有起有伏，最终击败某个强大的行业对手。当中无论是项目组内个人还是公司都投入了极大的资源和支持。然而现在我负责另一个领域的开拓，我不会也再也不可能花4年了。资源必须更有效地配置，这样对身处项目的所有人都有更好的收益。

这4年里面差不多有2年半时间，团队都在积攒势能。说得比较美叫势能，说得直接一点就是：团队，技术和市场，以及推广都还没成熟，我们还得继续积累和等一个点燃的机会。

在业务变革极其迅速的当下，再也不会有4年了。成和败，基本半年，8个月就能看出来。那么这个“势能”又该如何积聚呢？

阿里非常狠，把所有与势能相关的公线资源全部收拢，使其变成真正意义上的“火力中枢”。

一、背景，大公司们都在尝试解决“KPI完成了，业务死了”的问题

现在大公司之间的部门墙，甚至业务墙都已经严重得不得了。只要你谈无收益的合作，一般都会被问：这跟我的KPI有什么关系。没关系啊，不做了。

这种玩法下怎么创新？之所以去年到今年年初，一堆人离职出去搞创业，资本是催化的作用，但根源还在于“很多人受不了”。

某个业务部门里面的研发小A，他想做个新业务，在传统组织下，他要搞定的流程，我们来脑补一下：

首先自下而上搞定他的Leader，再搞定总监，如果这个组织大到有研发GM，那么再搞定和说服一次。

然后开始自下而上配备资源，由上面下命令，产品设计配合，运营市场配合，最后落地到个人配合

就算我们假设当中任何一个环节都赞同了，他费尽千辛万苦搞定了9个关键人，开始落地。这沟通成本有多高？这时间耗费有多长？

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

二、为什么变成这样：阿里大中台，小前台模式的演变

有点想法的人，想要在体制内做些事情，结果拉不到人头也就算了，甚至乎自己都会背个差考核，不出走才怪。很多组织都意识到这一点，都在尝试作出改变，所以搞出了一系列的玩法：

1、极度扁平小团队玩法

在这套架构下面，会有一个决策中心来指导具体业务的方向。依然是小A，在新的扁平团队里面，他只需要搞定最上面的业务老大集群就行。业务老大们说：小A，我看好你的方向，你可以招人了。此时他可以创建业务D，然后自己招募对应的组织角色，至于是向A，B,C挖角，还是自己招募，那就看他的个人造化了。

是不是层级减少了很多？效率提升了很多？

好，神坑来了：

业务没人搞个毛？要招人！

招人要招多久才能让业务跑起来？很久很久

运营和渠道资源，从无到有自己干要多久？很久很久

新业务往往不能预见未来，老板直接拨人拨资源给你的可能性有多高？很低很低。

So，这种内部创业，除了人才质量相对有优势一些，几乎没用到大公司的资源支持。
小A内心想：靠，这跟我出去干没啥区别，我还是出去干吧。

2、大中台，小前台玩法，例如阿里

上面极度扁平的玩法上，最大的问题在于根本没有强有力的火力支持。举个例子，小A招了一票人准备把隔壁老王的山头打下来。他们每个人都有着最顶尖的武器和设备，然而他们就是一个小队，对面山头有一个集团军。再NB的武器也干不赢一个集团，于是小A和兄弟们扔下武器，先耕田种菜赚钱招人，等招到一个军团，再把隔壁老王的山头打下来。

于是小A就想，MD，占山头这种事情，十来个人就够了。我需要几千号人，为的是把对手干掉，但把对手干掉后，我不可能养着几千号人占一个山头啊。为啥不能有个火力中心帮我搞定干掉隔壁老王的事情，让我安心占山头？于是有了下面的组织架构。

小A想要搞个新业务，此时他搞定业务线的老大：给我三个人，我们一起搞业务D。

业务线老大想想看，嗯~历史上小A还是蛮靠谱的，做吧。你这几个人负责业务的方向和差异化资源的落地。至于其他的公共资源，直接找公线要吧。

于是小A从公线要到了一大堆被公线打磨过很多的公共模块，拼装一下，然后把差异化的部分合进去，开搞！

三、阿里这种玩法的风险在哪里？

不画图了，用几个问题来说明下风险就行：

1、前台和中台的冲突：当创新业务需求无法从公线中满足时，是公线支持还是业务线自己搞。如果是前者，公线如何平衡资源投入与其他业务线。如果是后者，跑个半年八个月，业务线又变得巨大了。

2、不靠谱的前台怎么办：百花齐放不是百家争鸣，越小的单个试错成本越容易让人放松警惕，百花放完就枯萎了。

3、饼怎么分：一个中台的某个模块支持了6个业务，5个死了，1个成了。成了的加分，死了的扣分，这业务模块的成就和存在感怎么办。如果是6个都死了呢?

我个人还是很赞同阿里的这种玩法，至少这种玩法下，如果我再做一个新业务，给我足够的重火力支援就行。打什么山头我来决定，呼叫火炮即可，那么再让我做一件事情，不需要4年。

国内的，百人往上的互联网公司，有一家算一家，

尤其是已经上市的公司。

谁现在不头疼这几个问题？

进BAT的人谁不知道这么一句话：刚进公司最关键是什么？进对项目，跟对老大！

谁敢说没有内部消耗？尤其是项目之间争夺资源的情况？为什么不少人离职创业，大半都是受不了资源掣肘。

不说行政人力财务商务这些“跑部钱进”的部门，

就算是部门内部，那也是个个小组难以驾驭。

多少人说过怀念当年一起打天下，搞创业的日子。

问题是回的来吗？哎，一声长叹，该干啥干啥去。

别的不说，tg还有山头和利益集团呢！你能NB过tg？

但是一家北欧小公司却说我能啊！

而且人家说到做到了，15B一年摆在台面上。

我玩了3年来，前天刚给它的red活动充了值！

你是马云你不惊？

Supercell的大中台架构，避免了大公司常见的部门与部门争夺资源，不同的小组做同样的事情。能够快速出原型，快速试错，失败后全公司开香槟庆祝，对了资源堆上。天下武功，唯快不破。

当然这是最理想的情况。就算是学不全，只要能解决内耗的问题，也是大功一件。

还有一个好处，技术人员可以安心下来做技术，不用想什么劳什子30之后转管理，40之后当经理。技术是手艺，是跌跌撞撞拿钱喂出来的，就这么放弃了？还不是被公司制度逼的。

这事两年前就有人在说，在盼了，不过由马大仙亲自拍板开始干，还是很有魄力的。

未来的游戏公司，不应该是软件公司，而应该更像影视公司。创意为先，制片牵头，流程标准化，技术中台化。

解放生产力，打破制度禁锢，任重而道远。

互联网公司在发展初期受益于灵活多变的组织形态，但随着业务和组织的膨胀，就会因为组织架构与管理机制的不协调而催生很多乱象---从这个意义上讲，看上去很高大上的互联网公司其实本质上和草莽期的一般民营企业并无二致。

对很多民营企业而言，经过十几年的高速发展，组织已经庞大而复杂，业务也不像当初那么单一而独立。同时，整个行业的成熟也倒逼企业与企业之间的竞争提升到“向管理要效率”的高度，再像过去那样靠着奇谋伎俩、混沌不羁轻易取胜已经几乎不可能了。

言归正传，说到所谓的“前台-中台-后台”的概念，其实在金融、制造、零售等领域已经实行了多年，愈是大型的组织愈是依赖这种三层架构。其中，“前台”最贴近用户服务，强调创新灵活多变；“中台”和“后台”更贴近组织管理，突出规划控制协调。具体到阿里巴巴的例子，其“前台”就是贴近最终用户/商家的业务部门，包括零售电商、广告业务、云计算、物流以及其它创新业务等；而“中台”则是强调资源整合、能力沉淀的平台体系，为“前台”的业务开展提供底层的技术、数据等资源和能力的支持，用张勇的话来说就是“中台将集合整个集团的运营数据能力、产品技术能力，对各前台业务形成强力支撑”。

之前有知友提到阿里巴巴内部存在的各自为政、重复造轮、缺乏沉淀的问题，其实这是所有互联网公司的共同问题，而在目前业务瓶颈日益显现的背景下这些问题就显得更加不容回避了。而这些问题背后的根源其实就在于没有形成一个规划协同、共建共享的中后台，而是任由前台条线各行其是、南辕北辙。此次阿里组织架构中“中台”的设置就是为了提炼各个业务条线的共性需求，并将这些打造成组件化的资源/能力包（对组件化感兴趣的可以自行了解“Component Business Model”的知识），然后以接口的形式提供给前台个业务部门使用，这样就可以最大限度地避免“重复造轮子”的问题，也让每一个新的前台业务创新能够真正意义上“站在阿里巴巴这个巨人的肩膀上”，而不用每次开辟一个新业务都像新建一家创业公司那么艰难，甚或更为艰难。

总而言之，阿里巴巴这次以及之前的数次组织架构调整，其实背后反映了小公司长成大公司的过程中所必须经历的规范化与正规化历程。而这，也是其它的互联网公司迟早都需要经历的---这似乎也意味着中国互联网的发展将进入到“新常态”了。

最后啰嗦一句，不要因为主角是BAT就刻意增加故事的复杂性，要看清背后的逻辑只需回归常识即可。

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

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

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

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

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

2.原因、解决的问题

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

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

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

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

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

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

3.具体做法

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

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

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

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

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

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

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

4.问题与建议

【问题】

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

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

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

② 中台和前台分工不明确

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

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

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

【建议】

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

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

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

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

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

做中台的这帮人或团队, 他们的 KPI 和升职评估方法从何而来? 如果不解决这个问题, 那中台以后也还是会乱战, 会为了虚构的 KPI 去瞎折腾

比如阿里云这样的后台团队 (以后应该会算在大中台里), 就有各种为了并没有什么用的 KPI 而天天折腾, 正事因为有风险反倒没什么人做

其实就是特种部队化，这思想简单地说就是大后台小前端，如《野蛮生长》里阐述：

现在所有的国家都在增加特种部队，减少常规的海陆空军。特种部队中又着重增加信息战部队和心理战部队。增加之后，它的成本和收益会发生什么变化呢？简单地说就是大后台小前端：70%的钱用来找目标，30%的钱花在直接摧毁目标上。前端的组织变成全能的，后台变成系统的支持力量。以前前线的连长指挥不了炮兵，要报告师部请求支援，师部下命令炮兵才开炮；现在系统的支持力量超强，前端功能全面，特种战士一封e-mail炮兵就开打。部队在哪儿，每个队员的位置，在总司令的指挥屏幕上显示得十分精确。很难想象解决阿富汗塔利班的是仅仅123人的特种部队，三人一组，每组支持系统是5000万美元。三人小组包括一名信息情报专家、一名火力炸弹专家、一名战斗专家，他们相互了解一点儿对方的领域，在紧急救援、包扎等方面都经过训练。我们来看它的成本收益的变化。过去战争成本主要用在军火、死人身上，轰炸目标的成功系数低，70%的成本浪费掉，30%的钱正中目标。现在使用巡航导弹，70%的成本在找目标，卫星定位之类的，30%是炸药成本。现在的战争条件下，用于找目标的成本加大，直接针对敌人的费用少了。

这三个人怎么作战呢？北方联盟一开始很怀疑。特种部队的人说你们很快就能看到我们的力量，计划第二天就装备一个团。北方联盟的人都傻了，心说这怎么弄啊！特种战士拿出笔记本电脑，开始输入人员的身高、体重，配备的军装、皮鞋、军帽、枪支……一封e-mail发出，全球的供应链就开始调动。第二天下午，各种物资通过飞机直投下来。装备好之后，北方联盟的人还是走在后面，前面是塔利班军队栖身的山谷。特种部队拿出红外线扫描仪，用“死亡射线”寻觅，锁定目标。假如有400人，他会计算出相应匹配炸弹的数量。炸弹太少杀伤力不够，太多又浪费成本，而且血肉横飞国际影响不好。最后选择一种炸弹，基本能把他们闷死，而且保持尸体完好。这些炸弹所需费用也同时明确计算出来，美国总部根据这些信息核算战争经费。飞机上的哥们儿听着音乐早已等得不耐烦了，收到e-mail，输入参数坐标后开战，几秒钟之后山谷里悄无人声。这几个特种兵在北方联盟军队眼中犹如天兵天将，立即被奉若神明。所以，现代战争成本是精确计算的，前台是全能的，主要靠强大的支持系统，保证有效使用战争资源，战争更加伦理化。

~

应该说这是资源利用非常高效的方式，专家型的小团队，配合全功能技术顶尖不差钱的大后方，指哪打哪。其实对内部竞争的消除未见得有多大用处，毕竟竞争的不只是业务部门，技术部门也同样。关键在于机动性、效率，为长远考虑，培养出适应这种打法的后方力量，会进入一个良性循环，优化出高品质的后方功能，比能够适应各种场景的多功能全球分布式系统，简单易用、算法模型丰富的推荐、搜索、广告投放、数据分析系统，更别提基本的运维监控平台等，这些技术系统之外，还有公关、法务、市场等全方位支持。这样的平台化东西越多，也就越充实后方力量，前方的精英团队就可以专注于达到目的。

• 前台无力推动技术
• 中台不对结果负责
• 到后面前台觉得没技术成长
• 到后面中台觉得没有跟着业务成长
• 中台怎么分配资源，都会有前台觉得阻碍发展
• 沟通成本增高
• 本质上KPI不一致，就无法高效地做事
• 在这个事儿上，我只看到节约成本来着，不考虑招聘难带来的效率损失，本质上是在降低效率的
• 然而事实上，阿里想推动的，可能只是节约部分公共资源的成本，真做到大中台，是非常难的

每个公司，无论大、小都有一身的问题，每个人都能随手扔出一堆来，但想出方案的少。每个高层都不傻，我们都没在那个位置，体会不了问题的复杂程度。

能看到的，只是各公司都意识到了后台服务标准化、前台组织灵活化这个趋势。从任正非的“将军连长”，对财务体系的指责，到阿里的大中台，再到韩都衣舍的标准后勤模块、产品小组独立决策。

再往深处追究一下，本质上讲，还是马克思告诉我们的：生产力决定生产关系。随着沟通方式的改变，公司面对的消费者群体的行为发生了巨变，像社交影响力增大、服务个性化、高品质 商品需求增加等。比如最近的网红现象。公司的最终目标是为消费者服务，那自身组织结构必然要调整姿势适应客户，要不就被淘汰吧。

这也是为什么很多传统行业的公司发现这几年越来越琢磨不透消费者的原因。信息流动速度加快，导致消费者习惯行为易变。一个产品或服务如果按照原来的市场调研、设计、生产品、投放等流程，一个圈子走下来，消费者的爱好都变了几轮了。

1.马云的管理哲学一直天马行空，这次对标了美国大兵的组织模式:前线靠班一级的小兵突击，后方提供强大的侦查火力后勤支援。通常认为，大公司的特点是资源足灵活性差，小公司特点是资源不足但足够灵活，这种组织模式从愿景上希望同时具备两者优点，如能贯彻到底，则能实现置霸102年。

2.阿里已是一个庞大的帝国，内部系统复杂，如淘宝产品十年事所言，仅就淘宝都很难出一个产品架构能把握淘宝这个产品说清楚(话语权通常在运营和业务也是主因)，更何况支付宝，国际，村淘等大系统。如果每个做前台应用的都要理解底层逻辑，不是努力就够了，是根本做不到。

3.用户在前端感受到是十步流程，则中台就得有百步流程支持。比如订单支付，对用户来说就是输入密码确认，背后则走了非常非常多的流程步骤来确保支付环节走通，是否有盗刷嫌疑，账户余额是否足够，是否有优惠等等，这样算下来近百步流程和分支。把中台能力包装给前台用，让前台的产品专心于用户需求，也算是有效分工。

阿里巴巴集团组织架构里:前台、中台、后台，摘录两张图片，更多点链接进入 

http://www.moyouhui.cc

阿里巴巴战略;

从战略升级、组织升级、流程升级、技术升级等

阿里巴巴发生员工间性侵害，怎么样在职场保护自己？

阿里的牛逼之处不在于又出现了啥大动作，而在于每年都有作死的大动作都不会挂掉。

哎，前阿里人，颠总D的D（小弟的小弟）

在阿里呆过几年：

13年的时候，语嫣执掌淘宝，最后成交没做上来，走了，现在在负责阿里的投后。

14年的时候，乔峰执掌天猫，成交没达到预期增长，走了，现在在创业吧大概，不过他那么有钱了去哪里还不一样。

14年的时候，恰好淘宝做成交还不错，颠总从负责淘宝+手淘，到负责整个大淘宝，虽然手也伸不进天猫（你懂得）。

15年的时候，我不在淘宝了，我不知道淘宝数据怎么样，但是我看到的是一堆漂亮话，其实只有一句：行癫（颠总）不再负责前台业务，还披了个“中台战略”的漂亮外衣。在阿里呆过超过3年的看到这句话都只会“呵呵”吧。中台有发言权么？能驱动业务的增长么？能给公司带来成交和股价上涨么？所以说白了就是颠总下台。原因我也不懂，但是下台就是下台，一个掌管淘宝最核心前台业务的老大，现在去做中台了，你解释再多也是白搭。

另外你知道这个通告里最可怕的是什么吗？

那就是所谓大淘宝的班委里面，居然没有出现淘宝PC端（又称行业市场）的掌门人杨过的名字，西斯疾控啊，杨过可是m6呀（阿里巴巴CEO逍遥子才m8）。

所以说高处不胜寒。当然虽然斗争凶狠，但是马总对人还是很够意思的，这些人都有的是钱，就算下台了也不是我们普通人能比的。

免责声明：以上提到的各位老大我本人都见过（电视里），都非常敬佩。

高赞李丹华的答案很清晰，我从一个实践者的角度对比一下几种组织架构的好与坏。

同方一直以来就在主攻各大政府部门，套路跟其他厂商一般无二，先不计成本攻克部级单位，然后自顶向下逐层渗透瓦解。

在向下渗透的时候，传统的职能型组织架构和项目型组织架构都无法满足多点、密集的火力需求。

以作战为例：

部队较小时，只能单线作战，举全军之力攻克难关。公司虽小，职能俱全，这时候组织架构就是最原始的职能型组织架构。

当公司逐渐发展，可以多线操作了，每一个业务线都可以直接攻占山头，这样要求每支部队必须要编制齐全，销售、产品、研发、运营一一俱全，这就是项目型的组织架构，即集团军作战。

当公司再发展，需要攻克的山头越来越多，如果还是按照项目型的组织架构进行编制的话，就会出现资源浪费、新业务无法获取资源等诸多问题，会哭的孩子就能在这种公司里混的非常好。 北冥乘海生-怎样在大公司混成中层干部？ 这篇文章描述的就是在这种情况下如何成为一个牛逼的中层。

为了解决诸上的问题，管理者给出的解决方案就是由原来的集团军作战的粗放管理方式优化为前后端（小前台，大中台），小前台即销售、业务线人员，团队多且自治、小而精悍，主要任务是寻找并确定有价值的目标；大中台即产品、研发、运营等，任务就是根据小前台反馈回来的信息，提供火力支援。

同方软件在发现资源不够使的时候，从2015年开始调整结构，以类似的方式支撑公司的战略部署。我就是大中台的执行者，还是挺有感触的。

首先来说，这种组织架构非常适合于多点打击，业务覆盖面非常广，前端不需要考虑资源的问题了，他们需要做的就是找到并确认高价值的目标，收集尽可能多的信息给后方。前端人数不多，因此比较容易组建团队，机动性也强；后端资源统一管控协调，规避职能架构中跨部门协作的陷阱，还有项目型架构中占山为王的资源垄断弊病。

在大中台执行过程中，我们也出现了各种问题，我们做一些应对，不一定是最好的，但是是最适合我们现状的选择。

问题1：前端在攻克各地区政府单位的客户时，受限于地区（贫富、信息化程度、领导者理念等）、合作伙伴（政府关系、重视程度、办事效率等）、销售（人脉、能力等）等各种原因，获取来的销售线索质量不一，后端该如何甄选？

我们的解决方案是交由决策中心负责决策，类似于“指挥所”，由各GM加一个负责的VP组成。前方收集的信息汇聚到决策中心，商定之后确定优先级别、火力大小等，最后将决策交给后方处理。

问题2：在推进时，情况是不断变化的，后方如何应对此类变化？

与前方约定火力支援的节奏，初次拜访需要怎么支持，多久给什么样的成果；深入沟通时需要那些输入，标准输出是那些成果物，大约多久。申请流程是怎样的，加强火力、出差支持需要怎么走流程等，做好前后端事务处理的准标准化。

同时，后方在制定计划时，改变原有项目管理时的长期计划，调整为敏捷管理的机动计划，把变化当做常态，每周更新一次计划即可。随时跟进前方战况进行支持力度的强弱，甚至是暂定。

问题3：不出成果怎么办？

我们曾有过支持了半年，一个成功的都没有的尴尬局面。就像是挖水井，前方去定了一堆点，谁也不知道那个坑里有水，多深有水。后端就去挖坑，挖那个，挖多深？谁也不知道。

我们的解决办法比较笨，就是先挖着，多挖一些，大家的感觉就出来了。不用后端抱怨，前端就知道出问题了，决策中心就会有一个结果，是后端暂停，走商务关系（销售再去探消息）还是彻底放弃。

恩，现写这么多吧

集成、集成、集成。

一、理论依据与技术支撑

回忆一下99年前后的微电子行业和专业，那个时候的SoC、知识产权核、EDA工具、FPGA等等，从理论到技术到工具，对硬件行业及其从业人员的冲击。在95年之前，大陆的硬件设计是怎么样子的。然而，5年的时间，就开始改变了一切。

软件也逃不出这个规律。

自从软件危机以来，学术界和工业界在理论研究和技术开发进行了大量的努力，已经进行了大量的积累。分布式计算、云计算、容器等，已经使得“简单”变得可能。

自己也想了一下，所谓“大中台、小前台”其实对前后台的要求都挺高的。

小前台是什么？特种部队啊！那是对敌情判断、武器了解、战术应用具备一流能力的团队，不是推倒消息树喊一句“鬼子来了”就行了，你让炮火怎么打？

大中台是什么？高度信息化、机动化火力支援啊！你能在10分钟内把导弹打过来、半小时内飞机开过来、一天之内航母到位吗？否则前台呼叫响应不了，战狼也会挂了的……