在架构实践中如何围绕“流程”和“角色”发现组织冗余

        TOGAF元模型中把任何形式的组织分解为35个元模型实体（Metamodel Entity，以下简称元素），通过研究元素之间的关系及其演变规律，反映组织的整体逻辑蓝图和演变规律。

在35个元素中，业务架构的元素有18个，占据了50%以上的内容。可能有人会有疑问，组织情况这么复杂，用18个元素就能把组织分析清楚吗？

不要小看这18个元素，更不要小看架构元模型的作用。TOGAF之所以能够成为当前国际上最为流行和被采用最多的架构框架，TOG组织在2009年颁布TOGAF 9时提出的架构内容框架（包含了架构元模型和架构制品）起到了至关重要作用。虽然以前Zachman架构框架也提出了类似的元模型，但TOGAF第一次详细给出了元素以及元素的关系，并且把架构内容框架和架构开发方法（ADM）有机整合在一起，实现了工作路径和工作内容的统一。十几年的时间，TOGAF架构元模型从2009年的9.0版本已经升级至2018年的9.2版本，元模型的理论基础越来越充实完善，在架构实践项目中依据架构元模型的实践也取得了更多更有价值的成果。

今天我们来讨论一下业务架构中的两个元素——“角色”和“流程”，并结合实际项目，了解如何通过角色和流程的分析，定量的发现组织中的人员冗余，并针对性的提出解决方案。

一、TOGAF中对角色的定义

我们首先来看一下TOGAF中对于角色的定义：

角色：施动者具有的通常或预期功能，或某个人或事物在特定行动或事件中扮演的角色。一个施动者可以具有多种角色。（原文Role：The usual or expected function of an Actor,or the part somebody or something plays in a particular action or event. AnActor may have a number of roles. ）

从上面的定义可以看出，角色这个定义和施动者有密切的联系。那么TOGAF又是如何定义施动者的呢：

施动者：以某种角色发起活动或与活动进行交互的个人、组织或系统，（原文Actor：A person, organization, or system thathas a role that initiates or interacts with activities. ）

从TOGAF的元模型我们也能够看出，角色“执行或者参与”流程的运行；流程“被角色执行，或包含相关的角色”。

注意，TOGAF9.2此处有一个比较重要的修订，就是把角色和流程直接关联，而在TOGAF9.1中角色是和功能相连的。个人认为这是一个更加精确的描述，因为我们的业务功能是通过流程实现的，角色是流程中一个关键要素。若干流程和角色的集合形成了组织的功能。所以角色和流程的颗粒度更接近，角色和流程相连也能更加精确的通过模型描述组织的业务架构。（这一点在下面的架构项目案例中可以看得非常明确）

二、架构实践项目中的角色定义

我国大多数企业的业务架构工作开展的比较晚，基于流程的各种元素定义和梳理还很不全面。如果完全采用TOGAF的角色定义，特别是再加上施动者这样的元素，容易让企业的人无法理解，更加无法顺利开展架构项目。

一般来讲，我们在架构项目落地中对“角色”的定义是：具有相同权力和义务（职责）的一类人员，是某种类型的人或事物在从事特定行动或事件的分工类别。

基于这样的理解，我们首先需要根据做什么事来识别角色，然后根据该角色所做的事情，明确角色所需的权利及能力要求。相同的“角色”从事相同的“业务活动”，拥有相同的“业务权利”。“角色”如果仅有一个名称，没有与“业务活动”关联，那么这个“角色”没有实际意义。

流程角色作为流程标准化的关键部分，其设计可以从业务对象和业务操作类别（RACI）两个方面考虑（当然也可以从RASCI的角度考虑，具体方法可以参考其他文章《用架构方法让组织机构变革“有理有据”》。

业务对象与组织职责、流程颗粒度有关，表达了一个人、地点、事务或概念，需要根据业务中的名词进行提取，如客户、订单或物品等。以库存管理流程角色设计为例，企业根据物资类别设立多个仓库，如原料库、辅料库、备件库和成品库等，每个仓库会设有库存管理员。如果各类仓库的管理流程均一致，对应的物资入库流程、物资出库流程和物资盘点流程，其业务对象分别是“物资入库业务”、“物资出库业务”和“物资盘点业务”；如果备件的库存管理流程与其他存在差异，业务对象也会出现“备件入库业务”、“备件出库业务”和“备件盘点业务”。

我们在架构项目实践中，可以按照RACI责任矩阵的方法，对角色分类：

负责类角色（Responsible）

负责执行任务、活动的角色，即执行人、实际去完成的人，如编制人、经办人等。

命名规则为：“业务对象+操作类型（负责类）+者/员”的格式。其中业务对象指某个对象或某项事务，是一个名词，如战略、计划、单据、物资或产品等，操作类型（负责类）为完成该项业务的负责（执行）类动作，如申请、编制、提出、拟定、办理、录入、修改等动词。整体命名规则如报销单申请者、合同编制员、投诉意见提出人等。

批准类角色（Accountable）

对流程（业务）负全责的角色，只有经该角色批准同意或签署后业务才能进行。

命名规则为：“业务对象+操作类型（批准类）+者/员”的格式。其中业务对象指某个对象或某项事务，是一个名词，如战略、计划、单据、物资或产品等，操作类型（批准类）为批准类动作，是一个动词，如批准、审批、评审、签署、确认等动词。整体命名规则如报销单审批者、合同审批者、订单确认人等。

审核类角色（Consulted）

执行业务活动必须向其咨询、征求意见的角色，即对业务进行审核的人。

命名规则为：“业务对象+操作类型（审核类）+者/员”的格式。其中业务对象指某个对象或某项事务，是一个名词，如战略、计划、单据、物资或产品等，操作类型（审核类）为审核类动作，是一个动词，如检查、审核、校对、复核、核对等动词。整体命名规则如年度工作计划审核者、合同内容校对员等。

被告之类角色（Informed）

执行活动后需要被告知的角色，一般应用较少，如被告知人、被知会人等。

命名规则为：“业务对象+操作类型（被告知类）+人/者”的格式。其中业务对象一般指某项事务，如合同签订、投诉处理、计划发布等，操作类型（被告知类）较少，一般用被告知、被通知、知会等词，整体命名规则如质量归零被告知人、通知发布知会人等。

三、架构项目中基于角色-岗位-流程的补充

我国的大部分企业中都包含“岗位”这一元素。“岗位”是组织架构中一个确定的节点，是因企业的组织机构设置情况而产生的。所以，“岗位”一般都有定编。而“角色”是因“业务活动”而产生的，对应的是一组“业务活动”，当“业务活动”没有实际发生时，“角色”不一定要对应到具体的人，也可能根本对应不到具体的人。岗位或人员在组织中的职责和权力可以分配给某些角色，某些角色的权力也可授权给某些岗位，岗位和角色的关系是多对多关系，一个岗位可以指派多个角色，而一个角色也可以授权给多个岗位。

因此，在TOGAF给出的角色和流程连接关系的基础上，我们增加了一个符合国内企业特色的元素实体“岗位”。其中角色和岗位的链接关系是“授权”，角色授权是指将“角色”执行某项业务的权力通过授权条件授予给特定的“岗位”。引入角色授权后，流程与组织架构实现了“松耦合”，即以角色为桥梁，通过“流程步骤”关联到“角色”，再由“角色”授权给“岗位”的方式，将流程/流程步骤与组织岗位实现关联。只要业务没有发生变化，就不需要调整相关流程；组织架构有调整时，只要重新调整角色与岗位的授权关系即可。因此，在对角色进行设计时，需要避免出现部门、科室、人员等名称，避免组织架构或岗位调整时需要对角色重命名，影响到业务执行。

在架构实际项目案例中，我们通过对业务架构的分析，逐级细分至流程，这种细分过程参考当前的组织形式，但并不完全等同当前的组织形式。在另外一方面，通过流程中角色与岗位的对应，实现了流程-角色-岗位之间的衔接。因为我们对业务架构和流程的分析是依据战略、面向未来的形式，自然而然的流程中的角色和对应的岗位也是面向未来的形式。在此基础上，依据相同业务领域的流程对角色和岗位进行整合，赋予同类型的岗位以组织机构和相应的组织职责，从而形成了“流程分解——岗位匹配——组织履职”的业务和组织匹配的设计结果。见下图。

当然，在这过程中一定会发现一些组织与流程之间的能力差距，那么是应该降低业务需求，还是应该内部挖掘潜力，亦或是外部招聘或者购买能力，就是属于具体的解决方案方面的内容了。

我们还可以在此基础上，进一步引入职责等元素，从而构建一个完整的从流程到组织的关系模型。见下图。

在上面的模型中，我们把角色进一步细分成通用角色和专业角色，通用角色是基于岗位类型及职责对同类岗位的归纳，例如“中层干部”、“各部门行政助理”等，虽然这样的角色对应的岗位人员有很多，但大部分的岗位所从事的流程都是一样的，我们在梳理具体的流程和组织的对应关系时，没有必要细化到具体岗位，这时候通用角色的设置就显现出巨大的作用了。

专用角色是基于业务活动信息而建立的与业务服务有关的角色。这类角色是组织在流程工作中的责任主体，也是要具体分析的对象。通过角色实现了流程和岗位的相连以后，我们可以进一步管理“职责”、“部门”等元素，这样就形成了一个完整的从流程到组织的关系模型。

上述岗位关联角色、角色关联流程步骤的方式，不仅实现了对业务与组织架构的共同管理，还消除了组织岗位变动对流程环节的影响，可有效支撑组织的快速变革。如果组织在梳理架构的时候采用了架构建模工具，组织架构调整时，只需调整角色岗位的匹配关系模型，便可通过导出《岗位手册》将业务职责落实到新的岗位。当管理要求或标准发生变化时，只需更新流程步骤描述或匹配的相关要求，便可将新的管理要求、标准落实到更新后的《岗位手册》中，业务执行中满足相关管理要求和标准。

四、流程和组织关系模型的应用

一是从流程到岗位之间的断点，企业中各业务领域共有百余项流程没有具体的人员负责和落实。

二是从岗位到流程之间的断点，企业中有数十个岗位人员不承担或者参与任何流程。

注意，上面发现的问题和断点，都是定量分析的结果。可以根据需要定位到任何一个岗位、流程或角色，把问题具体化，从而从根本上解决了组织和岗位职责调整时的各种扯皮现象，帮助企业定量的明确了组织或岗位人员“冗余”，企业也能够更有针对性的开展基于流程的业务改进和绩效激励措施。

在这种分析的基础上，本项目还进一步设计形成了组织从订单到汇款的L2C高阶端到端流程场景。

并且还按照“华为铁三角”模式构建了面向一线的市场销售团队。

如果想进一步了解本项目详细技术路径、实施过程、架构制品等内容，请关注企业架构实践案例系列课程。