5步实现基于流程的组织架构设计，避免经验主义、拍脑袋

胡建国博士在他的理论中说，企业的战略、组织、运营是一个铁三角，这是企业管理最顶层的基本结构。组织是企业运营的载体，是企业资源最基本的组织方式，也代表着企业的运营模式和权责关系结构。组织架构设计是组织管理的核心内容，今天我们就来讨论组织架构设计的方法。

组织和流程的关系

首先我们需要清楚组织和流程之间的关系，这是所有问题的开端。流程（包括业务框架）相对组织是具有独立性的，不应该依附于组织而存在。流程是战略实现的方式，是最佳实践的结果。组织应该是与流程相适应和匹配的，而不是反过来流程要适应组织，那是本末倒置。换句话说，一件事怎么做最好就该怎么做，与谁去做没有关系，谁去做都应该是一样的。当然组织也会对流程造成影响，这种影响主要源自于组织所具有的资源和权责分配的功能，它可以促进或者阻碍业务的运行和发展。

我通常用这张图来解释组织和流程之间的关系。

流程就是河道，组织是行政区划。决定河道走向的不应该是行政区划，而是最佳实践，即河道应该按照最有利于灌溉的方式设计，这就是流程相对于组织的独立性。

比如一家企业，工艺系统和质量系统的人总是吵，主要针对质量问题的判定和归属。于是企业高层做了一个决策，将工艺部门和质量部门合并，这样一来再也没有了争吵。耳根子清静了，问题解决了吗？实际问题的根源在于质量问题处理的流程和标准不清楚，而机构合并没有解决这个问题，只是解决了争吵的人，相反问题被掩盖起来。时间久了发现问题越来越严重，因为质量系统很强势并总是试图在生产系统解决问题，压制了工艺的话语权，公司的工艺技术能力下降，最终导致了整体质量水平的下降。

有很多类似的例子告诉我们，业务的问题需要通过业务模式、策略和流程来解决，而试图通过改变组织机构就能够解决这些业务问题是不现实的。

传统组织架构设计的典型问题

传统的组织架构设计是经验主义的。企业战略提出了新的要求，或者目前的组织机构在运行中发生一些问题，需要调整组织架构。如何去调整？企业通常会沿着这样的一个思路。

从战略到组织架构的设计，虽然企业一般也会通过对业务进行分析来提取组织架构设计的需求，但是这种分析通常是问题导向的，是片面的、不完整的。组织机构设计之后，再考虑岗位和编制。流程是在岗位之下的，按照岗位各自去梳理与自己工作相关的流程。在这个逻辑当中，部门职责和岗位职责都是业务部门自己去编写的，流程也是被岗位和部门分割的，这是典型职能型组织的做法。

这样的组织架构设计过程存在几个问题：

1.组织架构的设计方案缺少业务支撑的依据，表现为经验主义拍脑袋的结果，经常为解决一个问题而制造另外的问题，有些企业为此会不停的调试；

2.没有从业务结构和流程出发，会导致部门分工的边界不清楚，然后通过讨价还价的方式达成一致，有可能造成实际分工的扭曲；

3.从部门职责到岗位职责，再到岗位和编制的配置，缺少流程的支撑，难以形成一套完整的、相互匹配的标准，结果是组织和人力资源管理的不精细。

基于流程的组织架构设计

现在我们要做的是基于流程的组织架构设计，这种方法和传统方法最显著的区别，就是首先构建企业的业务框架和流程，然后再从流程出发去思考组织架构、岗位编制和人员。

这样做的好处是：

1.可以从整体视角去考虑组织架构和流程的匹配关系，确保组织架构的设计是适应并且有利于企业整体价值链流程的；

2.组织架构的设计和调整是为了解决企业运营当中的问题，而这些问题并不能单纯从组织层面去解决，最终需要通过业务模式、业务策略和流程的设计和调整来实现；

3.流程为组织架构设计提供充分的依据，并且组织调整的结果（部门职责、岗位职责和工作接口关系等）需要通过流程实现落地。

下面我们就来讨论这个过程是如何实现的。

1.构建业务框架

首先要构建企业的业务框架，包括顶层、业务域层和逻辑关系层（这部分内容我们已经非常熟悉了）。

需要说明的是，在这个构建业务框架的过程中，通常我们会去勾画企业价值链的基本轮廓。还要针对企业现有的问题，进行业务模式和业务策略分析，因为我们需要在调整组织结构的同时解决这些问题。

上面这家企业，工艺、仓储和信息化是运营中问题比较集中的业务，我们在业务框架中表示出来，并且分析它们的现实问题和成因。比如，我们上面提到的工艺被弱化的问题。

2.组织和业务框架匹配分析

然后我们要做的，就是在业务框架上勾画组织机构的分工和边界，分析现有组织机构与业务框架的关系。

上面这张图是我们按照部门分工，在业务框架上把组织机构标示出来，看到的结果是有些部分看起来功能是完整的，而有些部分业务功能被不同的部门分割，形成了“马赛克”。

3.制定优化方案

接下来我们就需要通过讨论，来设计组织机构的优化方案。设计这样的方案需要有几个思考的前提：

1.面向企业未来发展的需要，至少要考虑2至3年，因为组织机构的调整不能是经常性的，需要具有前瞻性；

2.能够解决现实问题，这通常是组织机构调整的初衷；

3.基于企业的现实。每个企业都有自己发展的历程和阶段特征，组织架构设计有规律而没有标准，适合自己的才是好的。

4.保持业务经营的稳定性。如果不是在一个需要剧烈变革的窗口期，就要避免在业务层面的伤筋动骨。

这张图是我们给出的组织架构优化方案，与上面那张图比较，看起来明显将马赛克消除了，这符合业务相关性和专业性的需要，避免职能部门之间功能的交错。

同时针对现实问题给出优化方案。比如，将工艺从质量系统分离，回归技术系统，这样能够确保“设计——工艺——生产”这个链条的完整性。再比如，将信息化从技术系统分离调整到规划发展部，一方面避免信息化在技术系统中被弱化，另一方面可以与企业管理更好的承接。

有一点我们需要强调说明：组织架构的调整有助于解决业务问题，避免因为组织架构造成的功能扭曲，但不表示组织架构调整之后业务问题就会迎刃而解。就像前面我们说的例子，工艺从质量分离出来，只是避免了被人为的弱化，而要强化它的功能则需要通过构建它自身的完整能力来实现，这部分是组织架构优化之外的工作。

4.编制部门职责说明书

组织架构优化之后的结果，需要编制部门职责说明书。通常在很多企业中，总是倾向于要把职责说明书写得很详细。其实这完全没有必要，因为不管我们写得多详细，都没有办法把具体活动的职责说清楚。作为部门职责说明书，只需要分清楚在业务框架中基本的业务分工。至于具体流程活动中的职责，那是需要通过定义流程角色来解决的问题。

如果我们以业务框架作为基础，那么问题就简单得多。看下面的例子，这是企业的流程清单（战略管控的部分）。流程清单实际就是业务框架的表格化的表现形式，在流程清单里我们能够看到业务框架的三层结构。

我们可以直接从业务框架，得到了部门职责的结构。

如果想要适当细化，也可以在每一条展开到下一层级，也可以加以必要的解释。

5.岗位名称定义

我们将岗位定义（包括名称和编码）、岗位职责、岗位说明书这样的工作统称为岗位标准化。在此我们只讨论岗位名称定义的问题，因为它和业务框架高度相关。

下面是给岗位名称定义的示例，在这个示例中，我们很容易看出来岗位名称和岗位角色与前面业务框架的对应关系。

这里需要注意的是，我们通常会才采用大岗位小角色的方式来定义岗位。在上面表格中，有一个岗位是发展规划岗，角色分战略规划、经营计划、全面预算、技改规划。岗位是统称，角色是细分，它们在本质上是没有差别的。也就是说我们理论上可以定义为4个岗位，但是定4个岗位就比较麻烦，任职资格、能力模型、岗级、专业要求等很多要素都是一样的，却要编写4份岗位说明书，这会使得管理成本很高。所以我们就认为他们是一个岗位，角色是这个岗位里的具体分工。如果这个岗位有3个人，那么人力资源部门只管到这3个人都是发展规划岗，他们是一个Team，至于这3个人怎么分工就是他们部门内部的事情了。

如此，我们已经确定了组织机构，定义了部门职责和岗位，接下来需要做的是确定岗位编制，调配人员，制定实施方案。这部分内容对于技术性的要求不高，而更多是出于企业自身的组织能力和经验，在此不做赘述。

我们可以回顾一下，在上一篇文章中讲到的流程和组织关系的图。

我们还应该可以看到，业务框架实在是一个法宝。不仅在组织架构设计中我们要用到它，在流程、绩效、制度、IT等各种管理维度和体系中都要用到它。那是因为，所有的事情都脱离不了业务，所有的事情最终的结果也都是为了业务的发展，而业务框架就是对业务逻辑关系的抽象描述。

最后想说的一句话：好的企业是设计出来的。