上一篇，我们聊了如何从无到有搭建一套制度流程，并能持续运转下去。有了制度流程还得有配套的组织架构做支撑才可以，今天，我们来聊一些组织架构的话题。
聊到组织架构的话题，不禁让人想起了很多年前很火的一组组织架构图。
如上图所示，这些图非常形象的描述了几家顶尖科技公司的组织架构。其实组织架构并没有好与坏之分，几家公司也都非常成功。但是不同的组织架构的确为这些公司未来的发展产生了深远的影响。
回到我们自己，我们应该怎么设计自己的组织架构呢？在设计的过程中，又应该考虑哪些因素呢？
决策流
观察这几家公司的组织架构，我觉得有一个主干的脉络可以帮助我们理清思路，虽然组织架构千差万别，但其实都在围绕一个脉络来进行设计。这个脉络就是组织的决策流。
什么是决策流呢？就是组织从收集信息到落地实现的整个流程。如下图所示，他包括四个过程点，分别是信息收集者、决策者、执行者和结果反馈，信息收集者采集客户信息，决策者根据这些信息进行决策，执行者按照决策进行组织生产，最后产生结果又得到客户反馈。这四个节点组成了决策的闭环，体现了组织对外界变化的响应能力。设计组织架构就是一个让决策闭环流逐渐高效的过程。
同时，组织架构还面临着一个基本的矛盾。我们看决策流图，其中信息收集者、决策者、执行者是团队中的三种角色，当团队人数很少的时候，很可能一人身兼数职，这时候信息传递是很快的。但是当团队规模越来越大，每个角色的人数也会激增，即便是管理者，每个人的精力也都是有限的，能管理的人数也就是有限的，这就导致组织架构必然会出现层级关系。
层级如果过多，那信息传导的效率就会降低，层级如果过少，团队就没有办法充分管理。这就是组织架构面临的基本矛盾。那么，我们如何在这个基本矛盾下完成组织架构设计，让决策流程更加高效呢？下面，我们沿着决策流的各个节点分别来看一下。
信息收集
首先是信息收集节点，所有的决策都得在掌握一定信息的情况下才能做出。所以，信息收集非常重要。对企业组织来说，最核心的信息就是客户或者用户的一线反馈。简单说就是你的产品到底怎么样，口碑如何。只有知道了这些一线的信息，我们才能及时的改变策略，优化产品，做出正确的决策。
组织架构的目标就是要让这个流程更加高效。对信息收集节点来说，就要求及时全面的收集信息，并且尽可能快和不丢失信息的传递给决策者。怎么才能做到这一点呢？那就要求信息收集者和决策者之间的信息传递链条足够短才行。怎么才能足够短呢？让信息收集者直接参与或者主导决策，或许是一种选择。
比如，如果你是一家传统的软件服务企业，如果对你的业务来说，资源和关系是最重要的。那谁在资源和关系的一线呢？那就是市场和销售同学。怎么能让这个决策链条足够短呢？那就是让市场和销售人员成为决策者之一，以他为中心，调集后续的一切资源。只有这样，决策链条才是最短的。让一线的信息来调度炮火，才能保障最终的结果达成。
再比如，如果你是一家面向大众的互联网产品公司，如果对你的业务来说，产品是组织的核心，那对你的业务来说，用户的反馈就是第一位的。那谁能第一时间获取这些信息呢？那就是产品和运营同学。很自然的，让他们进入决策层，就会让决策效率足够高。以他们为中心设计组织架构，就是最高效的。
所以说，一定程度上，你做的业务以及你的业务定位，就会决定了不同的决策传导流程，这个不同的流程就会决定你的组织架构。当然，在业务的不同阶段也会有不同的目标，根据目标还需要变换对应的组织驱动方式。
决策者
再来看看决策者环节，一方面，决策的层级越少越好，刚才我们提到，可以让信息收集者进入决策圈，这样就减少了信息传导的路径。
另一方面，还可以给下层组织一定的授权也可以减少传导层级。也就是说让底层的组织也有一定的决策权，而不是事事汇报。这其实就是很多人在讨论的扁平化组织架构。
但是，我们得明白，追求组织的扁平并不是目的，追求决策流的高效才是目的。扁平化管理貌似很完美，但是，在这种架构下，因为决策权的下放，作为最高的管理者，有一些决策信息你可能就接收不到了，那么又怎么来保障这一部分的决策质量呢？
这就得需要制度和文化的帮助。制度就是把过往的经验固化下来，固化成流程，固化成系统，让大家在决策的时候也有保障。但是，日常工作中我们面临的情况是千奇百怪的，制度无法覆盖所有可能的情况，那就需要文化来提供支撑，文化就是团队共同的认知，他来指导我们决策的方向。
除了制度和文化，我们还要明白，即使有了这些保障，也不是所有人都可以授权的。授权的人得能做决策，敢做决策，并且敢于承担结果。能做决策就要求员工有一定专业能力和经验，敢做决策和承担结果就要求员工具有一定组织和解决问题的能力。不是所有人都适合扁平管理的，这对员工是有一定要求的。
所以，我们不能盲目的学习扁平化，没有制度和文化的保障，没有相对应的人才梯队，就会东施效颦，适得其反。
执行者
聊完了决策者这个环节，我们再来看一下执行者环节。执行者依然会有层级的关系，依然要考虑刚才说到扁平化的问题。
除此之外，执行者团队要完成具体的项目实现，就需要团队成员具备一定的专业技能。另外，因为涉及大规模项目的协作，还需要成员有一定组织协调的能力。但是两种能力兼备的人才是稀缺的，怎么让两种能力的员工合理搭配呢？这就需要我们在设计组织架构的时候仔细考虑，一般来说，执行者团队会有以下几种组织方式。
第一种方式，按职能划分。当业务线比较单一的时候，往往我们的团队就是按职能去划分的。比如技术研发团队，就会有前后端、客户端、测试、运维、数据等等职能团队，大家一起来协作完成一个项目。
第二种方式，矩阵型划分。当业务线变得越来越复杂，可能同时需要我们进行的项目就有几十个，原来按照职能进行的组织划分，就很难兼顾到各个项目的具体情况。这时候，我们怎么来进行组织架构来适应这种情况呢？
我们有两种选择可以参考，一种选择就是每个业务线配套单独的团队来支撑，还是以技术团队为例，也就是说每个业务线会有完整的前后端、客户端、测试甚至运维等团队。这种选择的好处是每个业务线自给自足，效率足够的高。但是缺点是人员无法复用，业务和技术上也比较难以协同，因为每次协同都需要跨团队的沟通和协作。比如，技术上的一些可复用的公共组件或服务，就很难在每个独立团队中推广。
那怎么能综合一下优缺点呢？我们还有第二种选择，就是矩阵式的管理。什么是矩阵式管理呢？就是我们把团队按照职能和项目两个维度进行划分。还是以技术团队为例，首先，按职能来划分，还是有独立的前后端、客户端、测试、运维等团队，每个团队有独立的负责人，这些团队负责人负责团队成员的招聘引进，以及培养和管理。
另一方面，我们又根据业务线进行项目的划分，项目负责人来统一管理和协调项目的整体进展。团队中的人员在组织上归职能负责人管理和调配，但是所做的具体工作由项目负责人管理。
这么做的好处是，把职能和项目分离的方式，可以充分发挥各自的优势。职能团队可以进行技术层面统一的优化和设计，对于各个项目碰到的共性问题，可以组织人力集中攻关。另外，根据各个项目的进展情况，还可以灵活的调配人力，使整个团队的效率最高。通过这种分离，项目团队就可以专注到各条业务线的具体业务需求，保障每个项目的顺利完成。
第三种方式，分拆、分层的方式划分。当业务线越来越多，甚至开始出现完全不同的业务群组后，这种超大规模的业务形式，对团队来说又是一个巨大的挑战。还是从决策链条来考虑，如果不同的业务群组所需的决策信息都不一样，比如说客户群都不一样，那就比较适宜完全隔离的事业部甚至子公司的方式来运作，这就是分拆的方式。
但是，这种分拆的方式，因为团队的隔离，使得业务的协同成本变得非常高，那如何能充分协同的情况下，还保持灵活的创新呢？这就可以考虑进行分层的设计，比如阿里在17年提出了“小前台、大中台”的概念。
什么是“小前台、大中台”呢？就是我们刚才说的矩阵式管理的基础上，把技术、产品、运营市场等各个职能抽取出公共部分，这个公共部分就是大中台，他为各个业务线服务，他们主要完成一些大家都需要的基础服务。而各个具体的业务线呢，仍然有自己的团队，但是业务都在基础服务之上进行搭建。大的中台保障了各个业务线的高效协同，小的前台保障了各个业务的灵活度，提升了整个团队的创新性。
举个例子的话，这有点像我们用到的各种云服务，云服务为我们提供了大量拿来就用的基础设施，我们自己的业务就可以组合这些基础服务来实现，业务就变得非常轻快和灵活。
当然，这种方式也不是没有缺点，他其实是一种理想化的支撑模式，他需要主动地对现有业务进行自上而下的分拆和重组，找到可以复用的共性服务。这个重组的设计，要求前台业务要足够灵活，中台配套支撑要足够快捷，资源还能够高效复用，这对业务架构能力的要求是非常高的。另外，他本身适用范围还是有限的，比如企业要有一定规模，业务要比较丰富，只有这样才值得去提炼共性元素。最后，前台和中台的协作也是一大问题，大家的KPI不一样，如何能步调一致也是一个挑战。
结果反馈
最后，再看一下决策流程的结果反馈环节。任何组织架构的设计都是为了业务目标服务的，也就是为了最终结果服务的。产生的结果会在客户中产生反馈，信息收集者就会得到这些信息，从而影响决策，最终的决策流程闭环就完成了。
大家可以看到，从信息收集到最终结果，信息传导过程中会逐渐丢失信息，如何让流程更加高效，这就是一个不断优化和调整的过程。沿着决策链条走，因为大家有各自不同的分工，大家的目标也会不一致。如何让各个角色能协同起来，我们后续还会继续探讨这个问题。
总结一下，组织架构的目标就是为了让决策流程更加高效，从信息收集者，到决策者，到执行者，到最终的结果反馈，每一个环节都需要我们慎重考虑。