工作流资源模式之创建模式

在上一章里，我们谈到了工作流的控制模式，控制模式强调的是对业务流程进行建模，业务流程的目标是实现一个商业目标或者管理目标，业务流程的执行往往由一系列的任务所构成，控制模式建模的实质在于合理调配这些任务，以期以最少的成本达到最大的收益。

 

本章将介绍工作流的资源模式，如果说控制模 式更为宏观，强调的是业务流程里各个任务的合理调配的话，那么资源模式则深入细节，将要讨论单个具体任务的执行情况。提到任务的执行，那么谁能执行这些任 务呢。答案很直接，是人。不管是在公司企业还是政府里，人都是最重要的资源，除去人之外，还有其他的非人力资源，例如机器、设备、计算机等。探讨这些资源 如何执行业务流程中的具体任务，如何调配这些资源即构成了本章的内容，即资源模式。

 

本章介绍工作流的资源模式，共计43种。 提到模式，很多人会想到四人帮，想到他们的设计模式，但是需要与编程里的设计模式区别的是：程序里的设计模式关注的是代码，通过应用设计模式做到代码的职 责清晰、不重复、开发人员友好等等；而工作流里的模式关注的是业务价值，通过合理调配任务和资源为组织带来最大的业务价值，工作流模式是对实际业务的直接 描述，与具体的工作流产品实现没有直接的关系（后面我们可以看到，很多模式当前的工作流产品很难实现），两者的出发点完全不同。

 

本章先会讨论与资源模式相关的一些基本概念，例如资源、工作项、组织机构建模等。接下来会对具体的43种资源模式进行讨论，讨论的模式按照描述、应用和实现展开，分别对应着模式的介绍、模式对实际业务的映射和工作流产品对该模式的实现支持。最后是小结。

 

一、基本概念

 

1、资源

既然是资源模式，那么什么是资源。在本章的 前言里，我们已经提到人是业务流程执行里最为重要的资源，除去人之外，随着自动化水平的提高，还有其他的非人力资源，例如机器、设备、计算机等。资源指的 是能够进行工作的实体，通俗一点，就是能够执行业务流程里任务的实体。对于需要盈利的公司而言，就是找到一种可以盈利的模式，然后找寻能够执行这些盈利工 作的资源，通过资源的工作达到盈利的目的，通过合理调配这些资源达到利益最大化。

 

因为人是最为重要的资源，所以在后续对资源模式的讨论中，没有特殊说明，资源指的都是人力资源，大多数的模式也将以人来说明。

 

典型的，人是某个组织机构里的成员。组织机 构对人员进行分组，执行相关的工作以达到共同的目标。例如，企业的目标是盈利，政府的目标是为人民提供更好的公共服务。组织机构对人员的分组具有多种形 式，最常见的就是部门、角色和岗位（实际上与角色相比，岗位更多体现的是一种业务职能，而角色更多体现的是管理职能，与权限相关）。对于大的跨地域的组织 而言，还有分支机构的划分，此外，还有临时组（典型的如以交付为核心的软件开发公司里的项目组）。在很多情况下，人可能具有多个角色、属于多个部门，这 些，增加了管理的复杂性。

 

对工作流产品而言，要对资源模式进行支持，则必然涉及到对资源分组的支持，在大多情况下，资源分组即组织机构模型。只有支持目标客户的组织机构模型，才能在实施工作流产品时最大限度的契合客户业务。当然，如果产品是某个行业的标准，让客户模型向产品靠拢也是另外一种方式。

 

2、工作流产品里的组织机构建模

所有的工作流产品都有自己的组织机构模型，其是工作流产品里一个重要的模块。但是一套模型往往很难契合多种业务场景。在大多数的产品实现里，都会提供一套元模型，例如人（Person）和组（Group），然后建立多套与业务相关的模型向元模型适配，例如，角色、部门都是组的一种形式，它们只是拥有不同的业务语义而已。

 

在工作流产品实施时，很重要的一步就是进行组织机构建模，然后将建立完成的模型与工作流产品内置的模型进行适配，在适配的过程中，妥协是经常出现的。

 

3、工作项

一个业务流程由一系列相关的任务组成。在工作流产品里，使用图形化的节点代表这些任务，而实际的任务被映射为工作项（work item），任务的调用被映射为工作项的执行。一般情况下，一个任务对应着一个工作项，但是存在一个任务需要多人完成的情况，这个时候一个任务就会对应着多个工作项。工作项可以看作是工作流中最小的工作单元，其代表着一个单一资源对某一任务的执行。

 

既然在工作流系统里任务的执行被映射为工作项的执行，那么就一定存在着人与工作项这个计算机概念的交互，在工作流系统里，这一交互通过工作项管理器来进行管理。即我们通常所见的工作项列表（任务列表），我们通过这一列表拾取任务、处理任务以及管理任务的状态。

 

4、工作项的生命周期

工作项有其自己的生命周期。

 

图 5-1

如图5-1所示，当工作流系统执行某一任务节点时就会创建工作项，工作项可以是一个也可以是多个，正如上面已经提到的，工作项代表着一个单一资源对某一任务的执行即一个工作项只能由一个资源来执行，现在我们讨论的是一个工作项的生命周期。

 

工作项被系统创建完毕后即处于创建状态，接 下来系统会选取资源来执行该工作项。有两种状态：一种是提供状态，一种是指派状态，这两者的区别在于一个是可选的一个是必须的。如果系统提供一个工作项给 你执行，这意味着你符合执行该工作的条件，但你不必为该工作负责，即你可以选择执行该工作也可以选择拒绝，你只是该工作的合适候选者；而如果系统指派一个 工作项给你执行，则意味着你必须为该工作负责，该工作必须由你来执行。因为一个工作项只能由一个资源来执行，所以如果是指派的话，那么只能指定一个资源； 而提供，则可以提供给一个资源也可以提供给多个资源来候选。通常工作项管理器会提供两种列表来区分这两种状态，分别是可拾取列表和待办列表，一旦资源对可 拾取列表里的工作项进行拾取，工作项即进入到资源的待办列表，状态成为指派状态。

 

工作项进入指派状态即意味着执行该工作的资源已确定，那么接下来就可以由资源来开始执行该工作，执行的过程中可以将工作暂时挂起中断处理，后续可以再恢复对该工作的执行。如果工作成功完成，则工作项成为完成状态；如果工作因为各种原因没有成功完成，则工作项置为失败状态。

 

二、创建模式

创建模式在系统创建工作项时生效，如下图所示，其位于工作项生命周期的创建阶段。

 

图 5-2

正如上面提到的，工作流系统在执行任务节点时会为其创建相应的工作项，根据情况工作项可以是一个也可以是多个。

创建模式作为流程模型的构成部分在流程设计期指定，通常在任务节点的定义里进行定义，与一个任务关联，其用来限定可执行该任务的资源范围。系统根据创建模式限定的资源范围生成工作项，工作项可以直接分配给人，也可以分配给角色、部门、岗位等。

 

1、直接分配（WRP_01: Direct Distribution）

描述

在设计期直接为任务指定特定的资源，该任务的工作项能够在运行期分配给它。注意，指定的资源可以为多个，如果是多个的话就会生成多个工作项，为每个资源生成一个单独的工作项。该模式实际限制执行该任务的资源范围。

 

图 5-3

如图5-3所示，任务A在定义时直接指定给员工甲，任务B在定义时直接指定给员工乙，当实际执行任务A和任务B时，将由员工甲和员工乙分别执行。

 

应用

该模式一般应用于流程里的关键路径。同时， 在中小企业里，该模式是应用最多的分配模式，因为人员少，管理扁平，所以每个人的职责都非常清晰。该模式也是执行效率较高的资源模式，因为人和任务直接绑 定，所以不会产生推诿等情况，便于管理也便于追究责任，因为运行情况完全在设计期确定。而随着企业规模的扩大，管理层次的复杂，一个任务往往需要交由特定 的部门、岗位或角色来执行，这样无形中会影响任务执行的效率。

该模式的缺点在于一旦关键人物因为各种原因不能及时处理任务，那么将造成整个流程的挂起等待。

 

实现

最简单的资源模式，设计期确定资源，运行期工作流引擎不需要做额外的工作。

 

2、基于角色的分配（WRP_02: Role-Based Distribution）

描述

在设计期为任务指定一个或多个角色，该任务的工作项能够在运行期分配给这些角色。实际执行该任务时，资源将从属于这些角色的资源中产生。该模式实际限制执行该任务的资源范围。

 

图 5-4

如图5-4所示，任务A在定义时指定给“开发人员”这一角色，该角色包括了两名员工甲和乙。实际执行任务A时，将由员工甲或乙来执行。

 

应用

企业达到一定规模，就会产生人员的分组，角色是典型的分组方式，将具有相似属性的人员定义为一个特定的角色，这些属性通常与工作的内容相关，例如开发人员、项目经理、总经理等，而角色通常又会与权限产生关联。

将任务分配给角色意味着将会有多个员工可以执行该任务，执行效率相比直接分配会有下降，这也是企业扩大后管理成本增大的一种表现形式。

 

实现

工作流系统内置的组织机构模型需要对角色进行支持。引擎运行期通过角色访问属于该角色的人员。

 

3、延迟分配（WRP_03: Deferred Distribution）

描述

在设计期为任务指定资源的标识，典型的，在工作流系统里，该标识对应于一个数据字段变量，例如userid。即在设计期并不确定资源，资源的确定被延迟至运行期，系统运行期从该数据字段里获取该任务分配的资源。

 

图 5-5

如图5-5所示，任务B在定义时资源的标识指定为userid，实际执行时，任务A由员工甲执行，其指定了下一任务的执行者为员工乙即设置了userid这一变量为员工乙的id，在任务B实例创建时，它访问userid，发现该变量里是员工乙的id，于是将该任务分配给员工乙。

需要注意的是，根据具体的分配策略，运行期该数据字段不仅可以指定人员，也可以指定角色、部门等。

 

应用

该模式给资源的分配引入了灵活性。资源的确定延迟至运行期，即任务可以根据具体的实际情况再确定执行人。具体实施时，这个指定的数据字段可以通过一系列的规则运算得出。

在国内应用中，该模式被大量应用在人工干预流程中，例如下一任务的执行由上一任务的办理者指定。

 

实现

一般通过工作流变量来包含资源的id。为了区别该id是人员id还是角色id，一般内置特殊变量，例如userid、roleid、groupid等。

 

4、按权限分配（WRP_04: Authorization）

描述

能够指定资源的范围，只有该范围内的资源才具有执行该任务的权限。

图 5-6

如图5-6所示，只有项目经理才有权限对开发人员申请软件的要求进行批准。

 

应用

随着分工的细化，每个人工作内容的不同，必然会产生权限的概念。权限实际代表着对同一件事情，每个人执行工作内容的差别。权限越大能执行的操作越多意味着需要负责的方面越多。

该模式强调通过权限对执行任务的资源加以限定。

 

实现

在大多数的软件系统中，角色不仅仅代表具有相似属性的一组人员，同时其也是最重要的权限概念，人员往往不与权限直接关联，角色将人员与权限两者进行关联。所以，对任务设定权限可以通过指定角色来完成。

 

5、职责分离（WRP_05: Separation of Duties）

描述

在一个流程实例里，能够指定两个任务必须由不同的资源执行。

 

图 5-7

如图5-7所示，任务A和任务B在设计期被指定不能由相同的资源执行，同时它们都指定分配给经理这个角色。那么在运行期，在一个流程实例里，任务A被分配给了员工甲执行，那么在进行任务B的分配时，尽管员工甲也属于经理，但是将不能由其执行。

 

应用

职责分离，不能既当运动员又当裁判员，不能又当跳水队领队又当全运会裁判长。

典型的报销流程里，一般员工的差旅报销由财务人员核实，但如果某名财务人员需要报销差旅费显然不能由自己审批，需要另外一名具有同样权限的财务人员审核。此时就可以对申请任务和审核任务两个任务节点应用该模式。如下图所示：

 

图 5-8

 

实现

后续节点进行任务分配时，需要获取与之关联前续节点的分配执行信息。流程定义期，在定义任务节点属性时建立两者的关系。

 

6、流程实例整个处理（WRP_06: Case Handing）

描述

在一个流程实例里，所有的任务都能够分配给同一个资源执行。

 

图 5-9

如图5-9所示，流程实例中的所有任务都由同一个人执行：任务A、B、C都由员工甲执行。

 

应用

在应用该模式的流程里，通常流程里的任务都 是紧密关联的。流程里的任务往往执行在一个紧密相关的上下文里，如果所有的工作都由一个人执行，那么在其了解该上下文的情况下连贯执行这些任务会具有更高 的效率；而如果执行任务的过程中换人，那么新换的人无疑还需要时间对该流程实例相关的上下文进行熟悉，这样无疑会多付出执行成本。

同一个软件的开发最好由同一拨开发人员完成，如果中途更换开发人员，那么新来的开发人员需要一段时间熟悉该软件，会对开发进度产生影响。同样的道理，在软件上线前增加开发人员不一定会提高开发效率，很多时候甚至作用相反。

 

实现

可以在实现延迟分配模式的情况下实现该模式，即在第一个任务节点初始化设置参与者变量，后续任务全部使用该变量。如下图所示：

 

图 5-10

 

7、经验获取（WRP_07: Retain Familiar）

描述

在同一个流程实例里，当存在多个资源都能执行某一工作项时，能够将该工作项分配给执行了前某一工作项的同一资源。

 

图 5-11

如图5-11所示，任务A和任务B在设计期被指定由相同的资源执行，同时它们都指定分配给经理这个角色。那么在运行期，在一个流程实例里，任务A被分配给了员工甲执行，那么在进行任务B的分配时，任务B依旧由员工甲执行。

 

应用

该模式刚好与职责分离模式相反，正如它的名字所暗示的，这些任务之间存在着紧密关联，如果执行了其中一个，那么就会熟悉这些相关联任务的背景上下文，积累一定经验，那么后续任务的执行相对其他人来说会变得容易。提高任务执行的效率。

 

图 5-12

如图5-12所示，在软件销售的过程中，售前和编写标书是重要的两步，这两个任务最好由同一个人进行处理，因为参与软件售前的人更熟悉客户的实际情况和需求，如果分开由不同的人员执行，那么必然会存在前者与后者的交流成本。

 

实现

后续节点进行任务分配时，需要获取与之关联前续节点的分配执行信息。流程定义期，在定义任务节点属性时建立两者的关系。运行期可以通过参与者变量（工作流变量）建立起运行期关系。

 

8、基于能力的分配（WRP_08: Capability-Based Distribution）

描述

能够基于资源的能力进行工作项的分配，能力作为组织模型的一部分建模为资源的属性。

 

图 5-13

如图5-13所示，任务A需要交与开发人员执行，同时其对办理该任务的人员能力提出了要求，要求只有熟悉JAVA且工作经验大于2年的开发人员才能执行该任务。这样就缩小了选取资源的范围。

 

应用

人力资源管理中很重要的一点就是要做到人尽 其用，每个人的能力都能得到最大的发挥，其实也就是根据能力将人放置到最合适的工作中去。从这一点看，该模式是对人尽其能的实现。但是如何定义各个人员的 能力，这本身就比较的主观，执行各项工作需要具备的能力也具有主观因素，更何况很多时候能力并不能与表现划上等号，模型是固定的但人是变化的受环境影响 的，所以工具本身就是工具，工具的应用最后还是依赖于人。

 

实现

实现需要两部分：一部分是组织机构对人进行建模时需要包括能力模型；另一部分是流程建模时需要给任务定义执行该任务所需的能力约束，这些约束是一系列的领域特定条件，需要有特定的解析器进行条件的解析。

很多工作流引擎提供有参与者接口，接口返回人员ID列表供给任务分配，从而将这部分工作委派到工作流实施时实现。

 

9、基于历史的分配（WRP_09: History-Based Distribution）

描述

能够基于先前的工作历史决定当前任务的分配。

 

图 5-14

如图5-14所示，当需要在员工甲和员工乙之间做出选择时，会选择此前执行类似任务时完成最好的员工。需要注意的是，这里的历史不再是限定在同一流程实例的任务执行里，可能是同一流程模型的执行历史，也可能是不同流程模型的执行历史。

考虑历史时，有很多的考虑因素，例如完成类似任务最好的员工、完成类似任务最快的员工、完成类似任务出差错最少的员工等等。这些考虑因素依赖于具体的任务内容和背景。

 

应用

国家篮球队比赛前，主教练会考察各个位置里各个球员的联赛比赛历史情况，其中不仅会考虑出场时间也会考虑各项数据，从而做出选择。

 

实现

同基于能力的分配模式一样，该模式的实现依赖于工作流具体应用的场景，也就是需要到实施阶段结合实际实现。从某一种角度也说明，应用工作流产品时，产品实施阶段也是最重要的步骤，选择工作流产品不仅仅是选择产品也需要考察其背后的实施团队。同时也可见，这些模式在诸如政府OA这些应用中是根本应用不上的。

实现需要两部分：一部分是对用户任务执行历史进行统计分析找出关键的评定因素；另一部分是流程建模时需要给任务定义执行该任务所需的历史因素约束，这些约束同样是一系列的领域特定条件，需要特定的解析器进行解析。

 

10、按组织分配（WRP_10: Organizational Distribution）

描述

能够基于人员在组织机构中的位置以及与其他人员的关系分配工作项。

 

图 5-15

如图5-15所示，审批任务需要由申请人的部门经理执行，即需要员工甲的部门经理执行。这种情况即基于人员之间的关系分配工作。

基于人员在组织机构中的位置分配即需要在工作流模型里建立起与用户相匹配的组织机构模型，可以将任务分配给部门、角色、临时组、岗位等。

 

应用

应用最为广泛的模式，实际工作中几乎所有的工作都必然和组织机构具有联系。其他模式，如基于历史的分配、基于能力的分配等都是基于该模式之上的扩展，直接分配、基于角色的分配则直接是该模式的简单情况。

 

实现

对该模式的支持实际上是对用户组织机构模型的支持。正如前面所提到的，很难存在一种工作流产品能够支持所有的组织机构模型，但是大部分的产品都会提供一套元模型或扩展机制，需要在实施过程中最大限度的契合客户业务。

 

11、自动执行（WRP_11: Automatic Execution）

描述

任务的执行能够自动完成，不需要人员参与。

 

图 5-16

如图5-16所示，请假审批后需要将情况通知给申请人，该任务由计算机完成，不需要人的参与，也不会产生工作项。

 

应用

随着自动化水平的提高，越来越多的工作可以交由计算机或相应的机器设备完成。流程中的自动执行节点也会逐渐增加。

 

实现

实际上工作流产品对该模式的支持即是支持各种的企业集成方式，不管是通过Web服务还是消息，工作流需要驱动相应的设备机器或应用系统进行工作并传递给必须的数据。所以也可以看出，随着信息化程度的提高，目前工作流应用越来越趋向于企业集成领域。这也是为什么基于Web服务编排的BPEL会逐渐取代XPDL成为工作流流行标准的原因之一。

评论

4 楼 comsci 2010-09-09  

楼主的文章描述了很多理论上面的东西，做流程不仅仅要实践，更要理论的东西。。

3 楼 wait10000y 2010-08-27  

面试时的翻译题 就是翻译workflow的工作原理.当时只翻译了一段.

就是流程控制.不是有许多这么方面的设计吗?只是没有脱离代码,整理成文档.

楼下的,我理解的偏了没有?

2 楼 ronghao 2009-11-08  

ecoll 写道

理论有点多，能否多点实例的讲解？

我们会在后续增加这方面的内容，谢谢关注

1 楼 ecoll 2009-11-07  

理论有点多，能否多点实例的讲解？