承接以下前续文章，继续我们的角色揭秘之旅。

《揭秘角色 01 | “戏剧角色” 与 “流程角色”》

《揭秘角色 02 | 分清角色类别、角色、人员》

《揭秘角色 03 | 用RASCI进行流程优化（上）》

《揭秘角色 04 | 用RASCI进行流程优化（中）》

《揭秘角色 05 | 用RASCI进行流程优化（下）》

《揭秘角色 06 | 端到端流程中的流程角色》

《揭秘角色 07 | 角色-岗位-人员的关系（上）》

由于在 “角色-岗位-人员” 三者关系中，“岗位” 只是框定了一个选人的范围，所以在流程实际运行中未必能直接确定唯一的一位人员来扮演某一具体流程步骤的 “流程角色”。

在一个流程实例中，针对某个具体的流程步骤，只要不能基于选人规则直接选定一个唯一的执行人员，这个选人规则就不够明确，EBPM 方法论称之为存在流程的 “组织断点”。

如果一个“流程角色” 仅关联一个岗位，而这个岗位上只有一位员工，那么这个选人规则就是明确的，将这个角色作为执行角色分配给一个流程步骤时，这个流程步骤就不存在 “组织断点”。所以，也可以这样认为， “角色-岗位-人员” 中的 “岗位” 是最常用的一项选人规则。

存在 “组织断点” 的流程步骤，只能由上一步骤完成人或者流程发起人来选择和决定最终扮演 “流程角色” 的 “人员” 并打通这个 “组织断点” 了 。

上图所示是某企业的《发票开具流程》，这条职能流程由 3 个流程步骤构成：

步骤 01：<提交开票申请> 对应R 类角色 <开票申请人>。

步骤 02：<审批开票申请> 对应A 类角色 <开票审批人>。

步骤 03：<开具发票> 对应R 类角色 <开票人员>。

运行本流程时，需要有 3 位员工来 “扮演”上述 3个角色。可以看到，上图示例中已构建了 “角色-岗位-人员” 的关系。

步骤 01的 R 类角色 <开票申请人>对应了岗位<客户经理>，而这个岗位该组织当前定编三人且已有 3 位员工，分别是张三、李四、王五。在流程实际运行中，即每一个具体的流程实例中，究竟是这 3 位员中的哪一位来完成<提交开票申请>这个任务事项呢？由于<提交开票申请>是本流程的第一个步骤即流程发起环节。作为按需发起的环节，已隐含了一个规则即谁需要谁发起。也就是说，因为张三、李四、王五这 3 位销售经理有各自负责的客户，谁的合同需要收款了谁就负责发起开票申请。因此，在一个流程实例中，从岗位对应的 3 位员工中明确1个负责员工的规则是明确的，不存在 “组织断点”。

步骤 02 的 A 类角色 <开票审批人>对应的岗位是<销售总监>，而这个岗位只有一位员工即赵六。因此，每一个具体的流程实例中由谁来负责完成 <审批开票申请> 这个任务事项的任务派发规则也是明确的，即总是由赵六完成。所以，也不存在“组织断点”。

步骤 03 的 R 类角色 <开票人员>对应的岗位是<财务出纳>，而这个岗位上有 2人，分别是钱一和孙二。每一个具体的流程实例中究竟由谁来负责完成 <开具发票> 这个任务事项呢？比如，当客户经理张三发起给 A 客户开具首付款收款发票的申请后，财务总监赵六审批通过了，此时第三步即<开具发票>这个任务事项该派发给谁呢？没有一个预设的规则可以自动定位到钱一或者孙二。此时，EBPM方法论认为 <开具发票> 这个流程步骤存在 “组织断点”。

可以看到，“角色-岗位-人员” 是框定了一个选人的范围，比如在本示例中<开具发票>这个任务应该且只能派发给钱一、孙二这两位员工，而不是别人。因为，这个工作是 <财务出纳> 这个岗位的职责，而钱一、孙二都隶属于 <财务出纳> 这个岗位。

在传统的流程梳理、设计和优化工作中，“组织断点” 通常是被直接忽略且从不谈起的一点。但是，企业管理者又强烈希望通过流程来解决职责不清、工作扯皮和窝工的问题，这是非常有意思的一个现象。要消除 “组织断点”，明确流程任务的派发规则是唯一的途径，没有第二条路可以走。

至此，可能又有人要问了，既然传统的流程管理往往直接忽略这个逻辑，那么企业内的这些流程又是如何实际运转起来的呢？事实上，在实际运行中是由上一步骤完成人或者流程发起人通过 “脑补”、“打听” 和 “试试” 这三个法宝来消除 “组织断点” 的。在本示例中，最可能出现的情况是 <客户经理> 或者<销售总监> 将审批通过的《开票申请单》送到钱一或孙二手上。至于是钱一还是孙二，那取决于到财务部时碰见谁，碰见谁就给谁。如果钱一、孙二都不接收申请，谁都说不是自己负责的活，那么就找他们的主管比如财务总监，让他指定人员。所以，如果没有一个明确的任务派发规则，这个环节就可能出现职责不清、工作扯皮和窝工的情况。当然，也不排除钱一、孙二 2 位员工责任心很强，积极主动抢活干的情况。总之，人工线下运行本流程时，“组织断点” 往往是通过人员间的反复沟通、协调和折冲来最终打通的。

如果我们将这条流程放到数字化的平台上运行，那么运行到第三步时，数字化的流程引擎就无法处理了，构建明确到人的任务派发规则是流程数字化的一个基本要求。

比如：《随机派发给<财务出纳>岗上的任何一位员工》就是一条数字化的流程引擎可以读懂的规则。这条规则其实就是对应线下运行时，到财务部碰到谁给谁的场景。

较随机派发而言，更为常见的情况是管理者会制定如上图所示的基于管理分工的任务派发规则：<北方区的合同由钱一负责；南方区的合同由孙二负责>。此时，流程运行至第三步时，基于申请开票的合同类别，数字化的流程引擎就可以基于此规则，通过 “角色-岗位-人员” 模型自动选定唯一的执行人员，并将 <开具发票> 这个任务派发给他。

还有一种情况，就是索性增加派工环节。如上图所示，增加 <派发开票任务> 这个流程步骤，对应 R 类角色 <开票任务派发人>由 <财务总监>这个岗位来扮演这个 “流程角色”，而 <财务总监> 这个岗位上只有一位员工周七，所以这个步骤本身没有 “组织断点”。

综上所述，可以将 “角色-岗位-人员” 的关系概括为以下两个要点：

1）岗位的作用之一是框定可以扮演 “流程角色” 的人员范围，是一条最常用的流程任务派发规则；岗位的作用之二是可以进行岗位管理，包括基于岗位的管理要求推送及岗位的优化分析。

2）一个流程角色中如果有多个岗位，或者虽然只有一个岗位但此岗位上的员工不止一人时，通常还需增加任务派发规则才能确保流程实际运转时不出现“组织断点”。任务派发规则也可以理解为授权某位员工负责执行的授权规则。

最后强调一下，在数字化时代，识别所有需要任务派发规则的流程环节，构建基于规则的模型并驱动数字化流程引擎自动完成任务派发，是流程数字化的一个热点。

很多任务派发规则的管理逻辑较为简单，很快就可以实现数字化的自动任务派发。但也有很复杂的任务派发规则，比如某家大型软件企业就在研发将系统开发工单派给 IT 开发工程师的算法模型。他们给每位 IT 开发工程师进行标签化处理，标明其技术等级、擅长领域、过往开发经验等等，有十几个标签；同时，给每一个系统开发工单标识难度等级、需要的技术能力等等，也有十几个标签；然后再构建一套基于规则的算法模型驱动数字化流程引擎完成自动派工。这套算法模型上线后，现有的研发团队主管进行任务派发的流程节点也就自然取消了。更为重要的是，这套算法模型还有学习能力，可以基于历次派工及完成情况，不断调整 IT 开发工程师的标签特性及算法逻辑，从而不断迭代优化这套任务派发规则模型。