今天只谈下工作流引擎中的流程参与人设计。

对于工作流引擎，在在前面谈BPM业务流程管理的文章里面书顺带谈到过，并且说明了常说的BPM流程引擎实际是业务自动化引擎+人工工作流引擎的一个融合。

常说的工作流引擎一般都是特制HWF人工工作流引擎。

对于工作流引擎设计，里面一个关键点就是流程参与人。因此今天只谈下对于流程引擎中的模板配置，角色和参与人，用户组，岗位等之间的核心关系。

分清角色和用户组

对于国内的流程引擎设置都比较灵活，一般既可以配置角色，也可以配置部门和岗位，但是对于标准的工作流配置一般都是设置角色，并在角色中配置参与人。

那么首先就要搞清楚角色和用户组之间的关系。对于角色往往是一个泛指的概念，而对于用户组则是一个关联到具体组织或工作组后的特指概念，即：

• 角色*产品分类树=》形成用户组

• 角色*组织分类树=》形成用户组

如上图可以看到，对于产品经理，项目经理都是角色的概念。对于角色并不直接配置人员到角色里面。而产品分类*角色后才形成用户组的概念，比如平台产品线SOA项目项目经理，即是一个特定的用户组概念。

平台产品线+SOA项目这是一个层级结构，我们有时候会用到工作组这个概念，工作组可以是一个分级的多层结构，但是往往最多一般分三层，即产品大类，产品线，项目。某个产品线下具体哪个项目的项目经理，就是一个用户组。

为何要这样设置？

即我们在进行流程模板设置的时候，参与人只会配置到具体的角色，而实际流程启动后才会动态去计算出具体对应到哪个用户组计算出具体的人。

举例来说：

当前一个文档申请提交流程，里面涉及到项目经理审批，QA审批，产品经理审批等。但是对于不同的文档可能涉及到不同的流程，这个时候有两种方法，一个是仍然沿用工作组的设置，即将产品分类(工作组)和流程模板进行映射，在选择了工作组信息后来确定具体调用两个流程模板。即我们常说的，即使是同一个类型的表单或申请单，由于类型或工作组不同，在启动的时候也可以调用不同的流程模板。

在表单申请的时候，申请单必须选择工作组信息，比如上面我们选择产品2-项目1这个产品分类下的具体项目。

选择完成后提交项目，启动流程实例后流转到项目经理审批。我们在设置流程模板的时候，参与人设置的是项目经理，这个时候就需要基于产品分类选择来交叉计算对应的用户组，这个时候计算过程为：

产品2项目1 * 项目经理角色 =》项目1项目经理（用户组）

当计算到具体的用户组后，这个用户组里面往往就只有特定的人，而不是一堆的符合项目经理角色的都能够收到待办和处理。

这个是流程引擎在启动和计算人的时候最常见的方式，可以看到，在这种方式下必须要实现定义清楚角色，同时对用户组进行动态计算和生成，并将收集到的用户组成员信息导入到系统中。

从角色到组织结构

在流程审批的时候，最常见的业务场景就是，当前部门的领导审批，当前部门的管理经理审批，当前部门的主管副总审批，上一级部门的领导审批，同级部门的领导会签等。

这个场景是什么意思？

即在流程审批的时候，我们往往会涉及到部门和组织的层级机构去找人，而不是单纯地通过角色和用户组去找人。

比如我们有一个角色叫部门经理，按传统的做法可能是每一个部门的部门经理都需要单独建立一个用户组，并把参与人放进去。但是如果当前有完整的组织结构树，这个工作则不需要，即张三这个人，基于组织结构树一定是能够找到对应的部门经理，对应的测试经理，对应的部门主管副总的，只要组织结构和岗位设置正确，这个信息就能够完全查找和精确定位到。

这就回到了我们前面的问题，在流程模板设置的时候，我们可以设置岗位作为流程活动节点的参与人，比如岗位就是部门经理。然后在参与人计算规则那个地方来设置，具体是找同级部门经理，还是找上级部门经理。对于找同级容易理解，对于找上级本身又有规则，比如我们前面说的有上级部门经理的概念，也有主管副总的概念。

那么如果一个企业有二级，三级多级部门的情况下，如何去找上级主管副总。你从三级查找到二级的时候可能找不到主管副总，但是从二级查找到一级的时候就能够查到主管副总的。因此找上级的过程往往是一个逐层朝上面查找的过程，直到找到为止。

在这种时候你就有两种做法，在流程参与人那设置部门经理，但是里面不放人，根据组织结构和岗位树去找部门经理。还有一种做法就是将所有的部门经理都配置进来，但是根据当前部门的部门经理，上一级部门的部门经理等规则去精确计算出对应的人。这两种方法本身都没有问题。但是第2种折中方法更好些，不用完全依赖于组织机构和岗位设置。即只会用到组织结构和层级关系，而不会用到岗位人员信息。

注：对于流程引擎设计中，参与人可以设置组织岗位一般是国内流程引擎在标准流程引擎基础上适合国内应用场景做的个性化能力扩展，但是这个扩展本身是有意义的。

动态规则计算参与人

如果上面的方式都无法处理自动计算出对应的参与人，那么就需要自己写规则和程序来动态计算参与人，即流程引擎简化为仅仅是一个状态流转机，但是状态流转后具体对应的处理人流程引擎不计算，而是需要调用你写好的计算规则或接口去动态计算。

在流程模板设置中经常会遇到这种复杂情况，比如需要由某个单据分类对应的项目经理进行审批，需要有申请人对应的系统主管项目经理审批等，这些我们都可以自己写规则去计算对应的参与人。

而要实现这种计算，重要的就是需要在业务系统里面自己去维护大量的这种对应关系和映射表，这些对应表往往是在组织机构，岗位角色中无法拿到的映射信息。

动态计算参与人，虽然灵活，但是由于进行了硬编码，会导致后续本身参与人的维护更加麻烦，也会导致由于审批规则出现变化的时候都不能简单的通过配置修改，而需要修改代码，那么这种代码仍然是很大的。

参与人的配置逻辑

基于上面说的，可以看到当前国内的各种工作流引擎往往就具备了满足上面各种场景的需求。即流程活动节点，既可以选择角色，也可以选择岗位，还可以选择具体的人。同时参与人节点配置还可以配置同级关系，还是上级关系等，这些都极大的方便了流程模板的配置。

注意在当前系统实现过程中，往往将系统功能角色和流程角色这两个概念分开，即专门配置流程角色供流程引擎使用。在流程角色中直接配置人，也可以是在流程角色中不配置人，而是在用户组中配置具体的人。这两种方式都可以。但是对于第一种方式，一定存在一种动态精确计算规则，否则就会导致待办信息分发到多个人的情况。