各位亲爱的读者，今天要讨论的话题是如何做与时俱进的行政组织架构。在讨论这个问题之前，让我们设想一个情境：你是一家公司的老人，随着公司的发展而不断成长，自己的专业能力也不断地在提升，同时你一直有个苦恼，虽然说自己团队不断在发展，也不断地通过和外部的交流优化内部的架构，但总感觉在目标落地上总有点不得劲，不知道是自己的问题，还是组织的问题或者是人员的问题。

那亲爱的读者，如果你是这位老人，你要如何解决呢?如果你是这个团队内的人，你如何看待你leader的苦恼呢？如果你是HR，你会如何给这位leader建议呢？如果你是行政人你会如何出主意呢？

这是件真事，在一次聚会上笔者的一位朋友提了出来，随机引发了大家的共鸣，不过都是做行政的。组织架构这类涉及到战略和HR的内容，显然在聚会上只能是以吐槽开始，玩笑结束。

但在聚会后，笔者查了一些资料，感觉很值得说说其中的一些方法论，为此请教了一些在组织规划和设计方面的HR大咖。试着整理了一下相关资料，希望能对大家有所帮助。

笔者将试着从以下几个方面来进行梳理，说的不好不专业不够直白的地方，还请见谅哦。

1、组织架构设计的基本原理是什么

2、古典的组织架构设计与现代的组织架构设计的区别

3、为什么企业要调整组织架构

4、行政如何主动适应及调整自己的架构适应企业的调整

01

那让我们先进入第一部分，组织架构设计的基本原理是什么？（网上一大把，为了让上下文通顺，笔者仅仅摘抄了一些，但不展开了，感兴趣的读者可以自行百度哦。对了，如侵删）

组织架构设计的基本原理是基于如下三点：（源自对 陈春花 老师大作的摘抄）

1. 体现组织四大类职能的内在协同

四大职能分别是：决策职能（红色），价值创造职能（橙色），支撑服务职能（绿色）与管控职能（蓝色）

不同的职能在一家公司的组织架构中定位不同，如下图所示。

2. 实现不同级公司之间的权属关系：

集团与分子公司在权属关系上分为：

强控制：操作管控（分子公司业务受集团管控）

中控制：战略管控（分子公司经营方向与主要策略受集团管控）

弱控制：财务管控（分子公司财务数据及资金流受集团管控）

3.确定岗位

完整的组织架构图是要从部门划分具体到具体岗位。

02

让我们迅速进入第二部分，古典的组织架构设计与现代的组织架构设计的区别。

首先要说的是，所谓的古典和现代并没有本质的区别，仅仅是一众对架构设计的理解不同而已。让抛开古典和现代的区别，我们先来看一下实操中，往往会存在什么情况？

无论哪个理论都会告诉你组织结构设计与战略、环境、规模、技术这四个要素有关，但是现实的情况是，在大部分公司，老板的意愿决定了组织的架构，今天老板说需要一个新事业部，HR就需要根据老板的想法调整架构，多一个结构出来。过一段时间，老板说这个事业部做的不好，或者这个VP不好，要调整。HR还是要跟着调整架构，让组织结构稳定下来。从理论上看，无论哪种情况的调整，都和上面的四个要素有关，但实际上架构的调整其实和真实的业务没半毛钱关系。

正如上面说的那样，在大部分情况下，大部分组织做的变革，其实还是在将人员从一个框架内移动到另外一个框架内，看上去是组织变革了，最后其实组织是以leader们的权利边界进行再划分，事实上并没有起到战略调整，架构先行的辅助作用。（当然老板意识到这点的除外）

言归正传，笔者用以下表格来对比以下古典与现代架构体系的区别，仅供参考。

从上图的对比，各位亲爱的读者就能明显的看出，同样是基于四个基本要素的组织架构设计上，古典的关注的是公司本身的稳定性，而现代更关注业务的发展性。或者可以这么说，目前很多中国企业都更适用于现代的模式，这样的组织架构可能更加适合用来快速扩大，直至进入瓶颈期后，开始转古典的模式，进行管理。

03

接着我们进入第三部分：为什么企业要调整组织架构

归根到底是为了解决业务发展与权责分配的问题。

让我们对比一下2种情况。

第一种是很多企业容易出现的情况，就是所谓的“面对上级，屁股对着顾客”的组织结构。这种结构钛普遍了，大部分的金字塔架构都会产生这样的情况。这种情况下，员工更关心上级脸色和看法，一切以上级意志马首是瞻。也可能出现都非常敬业，但是只对部门的业绩负责，公司的业绩与他们不管。最后导致市场中真真要重视的“客户导向”在这个结构中成了一句口号。当然这样的结构在中小型公司非常有用，可以有效的增加灵活性，领导高瞻远瞩，下属做好自己的事情，很多企业因此活了下来。第二种情况就是从互联网企业开始流行的“大中台，小前台”的模式了。这种模式就是为了解决大企业病—“赢了KPI，输了业务”而产生的。大企业病的主要原因很多，笔者的感觉就是部门的孤岛效应或者叫业务墙、部门墙。其核心理念就是让懂业务的人指挥资源。将原本分散在各条线的公线资源全部回收成为一个“航空母舰类型的火力中枢”，前台负责创新和业务的人员成为“独当一面的特种部队”，当“特种部门”做业务需要资源的时候，由中台这个“航母”提前火力资源。这样的好处是能减少大量在传统架构中要解决的层层审批与沟通带来的效能降低的成本。但也需要解决中台支援了10个项目，最终成了1个死了9个的OKR评价问题。

笔者是特别喜欢“大中台，小前台”模式的，因为这个类似做风投，有很多成熟的评价工具与方法论来参考。当然一个模式有优势就一定有劣势，对于“大中台，小前台”这个模式来说，也有其需要探索解决的问题，比如说：

• 前台和中台的冲突：当前台需求无法从中台中满足时，是中台设法支持还是前台自己搞？如果是前者，中台如何做好资源的平衡工作？如果是后者，前台的架构膨胀只是时间问题。当然，可以参考风投模式，确认好投资总额后，前台对预算负责，中台则根据前台的业务进度，分批投放资源。

• 如何判断前台的创新是否靠谱：现在就说快速迭代，小步试错，那小步试错就不容易发现前台业务的风险，因为你看到数据是优化过的。当然也可以参考风投做投前评估与阶段测试来解决。

那，我们行政架构如何与时俱进呢？

据笔者所知，一些互联网的公司已经将行政部的架构变成了“大中台，小前台”了。我之前听说，阿里铁军的人事行政已经在启动一场深刻的组织变革，方向是上面的“支撑平台+战斗小分队”的模式类似。例如，阿里铁军的人事行政打散了原来的架构，合并在了一起，然后按照不同的客户来划分团队，相当于是小前台的角色，后面也有支撑平台。这样的变革，是先合并，再拆分，将团队做小。因为小才灵活，才有活力，才能快速应对客户需求。除了平时支持业务线，根据不同业务线的不同项目需求，临时自由组合成不同样式的支持体系，保证能力匹配，这个可能才是未来行政应该有的组织架构。

现在，请再审视一下你的组织架构，是不是还停留在上个世纪？

04

最后，我们来抛个小彩蛋，对行政而言是架构先行还是流程先行呢？

这是一个源自IT的概念，套用在行政身上也很适用。主要的矛盾点在哪里呢？因为技术和方法发展的太快，当我们行政拥抱着新技术和新方法的时候，让组织架构相对封闭的传统行政部门连思考的时间都没有，就跟着变革了。我们知道做变革管理的核心是小步快速的试错然后迭代，但在技术和方法大量及快速的涌来的时候，很多行政一下子就懵了，看这个不错，看那个在某企业用的很成功。

那，如果我们想要与时俱进的做组织架构升级，架构与流程哪个先行呢？通常，初做管理者的时候，你和所有人交流都会和你说，组织一定先要有架构，才有流程。一方面，先把团队骨干搭好，才能好根据架构梳理流程。另一方面，不管什么样的团队，对外沟通的时候，多数也是按架构内分工来进行。所以，通常的印象中架构先于流程。

但如果做了一段时间，看了一段时间后，有些行政人会重新怀疑架构先行是否真的完全正确了。笔者觉得组织的架构与流程并不是前后的关系。架构是指你为了能保障提供服务而搭建的框架，而流程是则是业务具象化的过程或者说提供用户体验的界面。

对于用户体验这个维度来说，流程是目标。让用户舒服顺畅的按预设跑完整个流程。对行政体系的保障来说，架构是目标，你所有的产品开发、产品设计、产品测试、迭代优化都是在这个架构的基础上完成相应的工作的。

所以笔者的观念是，架构和流程是一个互补关系。架构打造流程，流程验证架构。架构是用来让用户顺畅跑完流程的产物，但归根到底，流程才是核心，对流程有分析，能验证架构是否满足用户的需求。

从实操的角度看，用户的需求越多样，那相应的流程就越多。这个时候架构会显得非常的复杂，但有种情况是当你按端到端流程架构体系梳理了流程后，你的架构反而可以趋向扁平化。

本节小结：架构先行还是流程先行，其实是个伪命题，作为相辅相成的一对CP，流程与架构能互相促进其成长，但其关键点还是在于与公司业务的匹配。

看到这里，亲爱的读者，分享几个问题，架构与流程的区别是什么？从用户交互的角度看，如果发生了流程交叉的情况，在架构上意味着什么？如果你是加大型集团的行政leader，在你服务的复杂组织内，采用的是同一套架构，如何解决不同用户的相同需求？

好了，说了这么多，今天就先到这里吧。如果觉得好，还请期待下一次的分享哈。