本书关注于IT里的流程产品。面对市场上品种繁多的流程产品，很多人的困惑是：这些流程产品究竟能够帮助企业做出哪方面的改进，这些产品背后的理论基础又是什么？同时，很多人对IT产品的宣传也存在着困惑，最多的就是：工作流技术和BPM（业务流程管理）技术究竟存在着什么区别？为什么很多原先的工作流产品现在都改称为BPM产品？本书将对这些问题都进行一定的讨论，一个事实是IT流程系统将在企业的改进方面发挥越来越重要的作用，但是不可否认的是，就目前而言，这些系统还存在着很多的局限，如果一个流程产品的思想是流程自动化，那么很大程度上这个产品是不符合企业发展需要的。

提到流程，第一个问题就是流程的历史。18世纪英国经济家学亚当·斯密在《国民财富的性质和原因的研究》中提出“劳动分工原理”，提出分工有利于提高效率、增加产量，其理由有三：第一，劳动者的技巧因业专而日进；第二，分工可以免除由一种工作转到另一种工作的时间损失；第三，简化劳动和机械的发明使一个人能做许多人的工作。亚当·斯密的分工论蕴涵了最朴素的流程理念。流程产生于一系列的分工。

维基百科里 对业务流程进行了如下定义：业务流程是为特定的对象（客户）创造价值的过程，这一过程由一系列相关联、有组织的活动或任务组成。企业和组织中，业务流程一 般被划分为三种基本类型：管理流程，对企业运行进行管理、协调的流程；运行流程，构成核心业务和创造基本价值的流程，如采购、制造、市场销售等；支持流 程，支撑管理流程和运行流程的流程，如会计、招聘、技术支持等。

接下来我们关注工作流技术的历史。工作流技术发端于1970年代中期办公自动化领域的研究工作，但工作流思想的出现还应该更早，1968年Fritz Nordsieck就已经清楚地表达了利用信息技术实现工作流程自动化的想法。1970年代与工作流有关的研究工作包括：宾夕法尼亚大学沃顿学院的Michael D. Zisman开发的原型系统SCOOP，施乐帕洛阿尔托研究中心的Clarence A. Ellis和Gary J. Nutt等人开发的OfficeTalk系列试验系统，还有Anatol Holt和Paul Cashman开发的ARPANET上的“监控软件故障报告”程序。SCOOP, Officetalk和Anatol Holt开发的系统都采用Petri网的某种变体进行流程建模。其中SCOOP和Officetalk系统，不但标志着工作流技术的开始，而且也是最早的办公自动化系统。

 可以看到，工作流最初出现的思想和要解决的问题即是实现工作流程的自动化。但是这带来了工作流技术应用的局限：第一是在企业里存在着很多关键的业务流程，这 些流程自动化的成本太高，无法自动化；第二是很多流程并不需要自动化，自动化反而会降低这些流程的执行效率，典型的在一个企业里，请假往往需要一定的审 批，在这种情况下，直接面对面的交流往往比通过工作流提交表单更有效率；第三是自动化流程往往意味着流程的柔性降低，比如制造企业都有设备维修业务过程，基本步骤如下：故障维修申请 －> 审批 －> 派工 －> 领料 －> 维修 －> 验收 －> 维修数据记录。这样的一个维修过程如果用工作流实现，工作流引擎会严格按照这样一个顺序执行，但是车间随手换了一个备件，可能只需要5分钟，而从提交申请到维修结束，走这样一个繁琐的过程，恐怕不是信息系统服务于人了，而是人服从信息系统了，再比如，紧急情况下进行的维修，可能直接进行维修、验收、记录维修数据三个步骤，可能连派工都来不及了。此时，自动化流程就会严重影响执行效率。

1970年 代人们对工作流技术充满着强烈乐观情绪，研究者普遍相信新技术可以带来办公效率的巨大改善，这种期望不可避免的落空了。人们观察到这样一种现象，一个成功 的组织往往会在适当的时候创造性的打破标准的办公流程；而工作流技术的引入使得人们只能死板的遵守固定的流程，最终导致办公效率低和人们对技术的反感。1970年代工作流技术失败的技术原因则包括：在办公室使用个人计算机尚未被社会接受，网络技术还不普遍，开发者还不了解群件技术的需求与缺陷。总结一下，工作流应用失败的原因有两点：第一点是自动化流程的柔性低；第二点则是限于当时的技术原因。

进入1990年代后，随着IT技术的发展、个人计算机的普及，工作流技术开始重新进入一个新的热潮，这个热潮完全是技术驱动的，这时候出现了大量的工作流技术应用。需要注意的是，工作流技术不仅仅是指专门的工作流管理系统，同时也指拥有工作流特征的各种应用系统，例如各类企业管理软件（ERP）和协作软件里有具有的相应流程组件。工作流技术的应用使得很多应用软件的开发得到一定程度的简化（同时，可以观察到工作流产品的采购客户往往会是系统集成商）。需要注意的是，此时工作流要解决的问题域依旧是实现工作流程的自动化，由此带来的应用局限并没有发生变化。

与此同时，新的管理革命正在发生。

1990年迈克尔·哈默在《哈佛商业评论》上发表了题为《再造：不是自动化改造而是推倒重来》(Renglneenllg work：don"t automate，obliterate)的文章，文中提出的再造思想开创了一场新的管理革命。1993年迈克尔·哈默和詹姆斯·钱皮在其著作《企业再 造：企业革命的宣言)(Reengineering the Corporation；a Manifesto for Business Revoiution) 一书中，首次提出了业务流程再造(BPR：Business Process Reengineering)概念，并将其定义为：对企业业务流程进行根本性的再思考和彻底性的再设计，以取得企业在成本、质量、服务和速度等衡量企业绩 效的关键指标上取得显著性的进展。该定义包含了四个关键词，即：“流程”、“根本性”、“彻底性”和“显著性”。

以此为标 志，形成了新的业务流程理念，并伴随着对传统企业金字塔式组织理念和管理模式的反思，新的理念强调企业以业务流程为中心进行运作、打破传统的部门隔阂、增 加客户价值和企业效益（降低成本）。以业务流程为中心取代职能分工，成为管理的首要原则，围绕流程建立起来的组织具有更高的敏捷性、效率和效益，呈现出扁 平化、网络化的特征。

新的管理理念催生新的IT产品，BPM产品孕育而生。可以说一个好的IT产 品总是对应有相应的理论基础，那种简单的对现有工作方式的复制化是没有生命力的（一个小的而典型例子是电子印章软件，从布局到排版都很逼真。可是现实中印 章的设计是为进行文件的状态确认，非常直接，但是在电脑上摹仿这种印章，不但用着别扭，看着也十分难过，更重要的是，明明通过工作流的控制已经能够确认文 件的状态，却一定要通过电子印章来生硬模拟。）。很多技术人员以XPDL和BPEL来区分流程产品是工作流还是BPM，认为BPM更为强调软件的系统集成能力。实际上，工作流软件与BPM软件最大的区别不在于技术实现，而是它们解决的问题域发生了变化。

工作流软件解决的问题域是流程的自动化，而BPM软件解决的问题则是业务流程的优化。

因为解决的问题域发生变化，那么BPM软件相比工作流软件在技术上的变化就很清晰了：强调对流程运行的监控、强调对流程运行数据的分析、强调对各种企业应用软件的集成能力、强调快速的开发能力。实际上很多BPM软件的前身即是工作流产品，从技术角度上理解，工作流软件和BPM软件是没有区别的，BPM软件是工作流软件发展的结果，只是开发商出于市场的考虑换上一个不同的标签而已（非常类似于当前的药品市场，同一种成分换个名称就变成新药）。然而从处理问题的角度考虑，区别两者则又是必要的。

但是BPM软件面临的问题依旧存在，因为很多BPM软件解决问题的思路并不正确，很多BPM软件依旧是通过自动化流程来实现业务流程的优化，这再次回到工作流软件所面临的问题：企业很多业务流程很难自动化、自动化流程的柔性很低。对于这些问题，BPM软件试图通过简化编程（快速开发、SOA思想）和系统集成来尽可能自动化多的流程，通过增强流程定量分析能力来尽可能的增加流程柔性。这实际上是在用正确的方式做错误的事，因为解决问题的思路从一开始就决定了这并不是一条正确的路。

相比而言，Nimbus的Control-ES软件则选择了另外一条道路，它并不强调流程的自动化，它是从咨询软件发展而来的，这决定了其解决问题的另外一种方式：强调对现有流程的评估和重构而非自动化。在Control-ES里，流程是作为企业财产保存的，仅仅文档化。这几乎立刻扩大了其对业务流程的描述能力，但是其的咨询背景也决定了它的局限性：无法实时获取业务流程执行的数据（完全依靠咨询人员的工作），于是Control-ES更多是作为咨询人员的工具而存在的。从某种意义上说，流程改进本来就是一项咨询工作，很多IT厂商甚至没有任何业务领域经验，拿出其BPM软件就宣传能够实现客户流程的优化是一件很搞的事情，很多所谓的流程梳理实际仅仅是对现有流程的复制再现，没有任何改进可言。

          一种更好的方式是文档化所有业务流程，然后通过系统集成能力实时获得关键的数据信息，实现以流程为中心的数据撮合，关键的流程执行和改进则交由人去灵活执行。对这种实现思路我们将在本书的最后部分进行讨论。可以看见的是，流程优化从来也不应该是IT系统能够完成的事情，IT系统所要做的是为流程优化撮合必需的数据，做为支撑系统而存在。

          说完BPM软件，最后我们需要关注的一个方向是云计算。越来越多的企业将其工作放置到了网上，典型的如Google提供的各种在线服务，文档、邮件、Excel等，这种趋势触发了新的业务模式，云中的工作流即是其中一种，通过提供在线的工作流程自动化，将各种在线服务通过流程粘合起来。在这方面，Cordys走在了最前面。

我们知道，一个商业目标的实现必定由一系列 的活动组成，这些活动的编排即构成了以目标为导向的业务流程。管理的目标即通过合理有效的编排这些活动以期以最少的成本达到最大的收益。这个编排的过程亦 即进行业务流程建模的过程。在进行业务流程建模时反复出现的活动结构构造即产生了模式。在本章中，我们将讨论工作流的控制模式。控制模式关注业务流程中活 动的编排，一方面强调与实际业务的契合，另一更为重要的方面则是如何合理调配这些活动。

 

本章讨论的控制模式共计43种。需要注意的是，这些模式的出发点是基于对实际业务进行描述的，与具体的工作流系统没有太大的关联。而一个工作流系统对工作流模式的支持程度则直接决定了该系统对业务的建模能力。所以在某种程度上，衡量一个合适的工作流系统时，往往会考虑其对工作流模式的支持程度。

 

本章讨论的控制模式按照描述、应用和实现展开，分别对应着模式的介绍、模式对实际业务的映射和工作流产品对该模式的实现支持。最后是小结。作为约定，我们将业务流程里的活动映射为任务，将对活动的建模描述映射为任务节点。

 

一、       基本控制模式

基本控制模式包括5个模式，是其他控制模式的基础。

 

1、顺序（WCP_01: Sequence）

描述

在同一个流程实例里，任务会在前续任务完成后顺序触发。

图 4-1

如图4-1所示，任务A执行完毕后会顺序触发任务B的执行，任务B执行完毕后会顺序触发任务C的执行。

 

同义词

顺序执行、串行路由。

 

应用

顺序模式是工作流建模的基础，是流程定义里最基本的构建块，用以描述连续串行的一系列任务，这些任务之间的触发是无条件的。

顺序模式也是实际的业务中应用最多的模式， 当实现一个业务价值需要执行多个任务时，最自然的方式就是排序并顺序完成这些任务，典型的如流水线作业。当企业人数不多，业务模式简单（不需要过多的任务 或任务之间存在很强的线性依赖关系），管理成本很低时，顺序模式是最自然的选择。

 

2、并发分裂（WCP_02: Parallel Split）

描述

分支分裂为两个或多个后续分支，当分支执行完毕后触发后续并发分支的同时执行。并发的分支有可能在后续合并为一个分支，也可能不合并。

图 4-2

如图4-2所示，任务A完成后将同时触发任务B和任务C的执行，任务B和任务C的执行不存在前后关系。

 

同义词

AND-split、Fork、并行路由、并行分裂。

 

应用

在传统的软件开发里，开发过程被典型的分为了5个阶段，如下图所示：

图 4-3

这5个 阶段是顺序执行关系，典型的当需求分析完毕后会有一个需求冻结状态，在这种状态下才开始正式的软件设计和实现。该模式最大的弊端在于在需求分析阶段不可能 捕获用户所有可能的需求，而且客户的需求是变化的，开发阶段由于需求冻结对于客户完全黑盒，导致最后的交付无法实现客户期望的业务价值。

在敏捷开发里，开发过程由多个迭代组成，在每个迭代里，需求分析、架构设计、编码开发、测试和交付都是同时进行的，客户参与到这个过程中，客户能够从不断的交付中提出新的需求，这样软件才能够更好的响应变化，不至于在最终交付时出现业务价值的偏差。

图 4-4

其实从某种角度上看，不同企业的组织管理结构也决定了它所采用的业务流程模式。在图4-3所 示的开发流程里，每个阶段都对应于不同的部门，需求分析有专门的业务部门，开发部门内部分为了架构部门、开发部门和测试部门，交付则又有专门的实施团队， 在这种情况下，从管理的成本考虑，顺序执行无疑是最自然和最便宜的选择（这也是为什么在传统企业里实施敏捷困难的原因之一）。

而在敏捷开发团队里，整个团队则是围绕开发流程建立，减少了内部不必要的协调沟通成本，能够达到相对较高的执行效率。

 

实现

由于后续分支的触发是无条件的，所以在很多工作流产品的实现里省去了AND-split节点，直接由任务节点进行分支分裂，如下图4-5所示：

图 4-5

jBPM使用token记录当前流程实例执行的位置并触发流转，建立起token的父子关系。如下图所示，在AND-split节点每个并发的分支都会产生一个新的子token，当子token到达AND-join节点后即可通过其访问到它的父token，再通过父token遍历其子token即可获得当前并发分支的执行情况并实现合并。

图 4-6

作为约定，我们在后续的说明中，将会采用token来指代当前流程实例所执行的位置。

 

3、同步（WCP_03: Synchronization）

描述

两个或多个分支合并为一个后续分支，当被合并的分支都执行完毕后，后续分支才被触发。

图4-7

如上图所示，当任务A和任务B都完成后，才会触发任务C的执行。

 

同义词

AND-join、汇聚、同步。

 

应用

在实际的应用中，AND-split节点与AND-join节点一般成对出现。

在任何时候，总结总是有必要的，每次迭代开发结束后，我们都会进行迭代小结，写出应该改进的部分、应该保持的部分，以保持整个团队的迭代前进。

实际上，很多情况下AND-split节点和AND-join节点往往隐含着管理意义，上一级的管理者在AND-split节点进行任务的管理和下发，在AND-join节点对任务执行结果进行负责。

 

实现

和AND-split节点一样，在部分工作流产品里，直接采用任务节点进行分支合并，如下图所示：

图 4-7

jBPM里，分支的合并实际是token的合并，子token生命周期终止，父token重新激活。

 

4、排他选择（WCP_04: Exclusive Choice）

描述

分支分裂为两个或多个后续分支，当分支执行完毕后只能选择触发一个后续分支执行，即多选一。

图 4-9

如上图所示，任务A完成后将会选择触发任务B或任务C的执行，任务B和任务C之间只能选择一个执行。

 

同义词

XOR-split、排他OR-split、条件路由。

 

应用

流程里的决策任务。会存在两种决策方式：人为决策和系统决策。由人或一组系统设定条件根据流程执行情况作出后续执行路径的选择。

 

实现

两种实现方式，一种是在XOR-split节点定义路由选择条件（图4-10）、一种是在后续转移线上定义触发条件（图4-11）。

图 4-10

图 4-11

条件的计算有多种方式：工作流变量与相应条件定义值简单匹配、提供接口由具体实现类返回计算结果、规则引擎进行规则匹配计算。同时，当存在多个后续分支和条件判断时，一般会定义一个默认执行分支。

 

5、简单合并（WCP_05: Simple Merge）

描述

两个或多个分支合并为一个后续分支，任何一个分支执行完毕后就会触发后续分支的执行，不需要同步，遵循先进先出的原则。需要注意的是：该模式有个前提条件，即前续分支有且只有一个会执行。

图 4-12

如上图所示，任务A或任务B只要有一个完成都会触发任务C的执行，但是任务A和任务B有且只有一个可以执行。如果任务A和任务B都有可能执行，则变为另外一个模式：多合并模式（WCP_08）。

 

同义词

XOR-join、排他OR-join、merge。

 

应用

在实际的应用中，为保证该模式的前提条件，一般XOR-join节点与XOR-split节点成对使用。

 

实现

和AND-join节点一样，因为不需要任何条件判断，所以在部分工作流产品里，直接采用任务节点进行分支简单合并，但是需要和AND-join做出区别，如下图所示：

图 4-13

6、基本控制模式小结

基本控制模式非常简单，实现起来也没有太大的难度。需要注意的是，对于一种模式往往会存在多种实现方式，笔者的建议是：将条件判断的节点独立出来，由其负责条件计算和路径选择，而任务节点则只关注于实际业务的执行，做到职责分离。例如，AND-split、AND-join、XOR-split和XOR-join节点都会单独存在。

可以看到：除去AND-split和AND-join节 点，顺序、排他选择、简单合并模式组合的流程和我们编写程序的逻辑流程图非常的相似，也就是这三种模式能够对程序的逻辑流程图进行建模。于是一件有意思的 事情出现了：有快速开发平台产品使用流程引擎来编排程序逻辑。他们的做法是将细粒度的代码逻辑封装为运算构件，然后再通过流程的可视化编辑器将这些运算构 件粘合起来。这样，传统方式下采用代码实现业务逻辑的过程变成了画流程图的过程。笔者认为这样的实现存在相当大的弊端，相当不合理。首先，编写代码变得复 杂了，明明几十行代码能够实现的逻辑却需要经过编写构件、绘制程序流程图、部署、运行好多步才能实现，编程效率可以想象；其次是代码的执行效率低，程序的 运行需要经过一次流程定义的解释才能执行；然后是这种实现完全牺牲了语言自身的特性，面向过程，很难提供代码级别的单元测试环境，只能提供有限的调试。该 实现实际上是定义了一种简单的流程语言，通过该流程语言来进行功能函数（运算构件）调用的编排。任务编排没有问题，服务编排也没有问题，但是如果编排细粒 度到功能函数，那么就超出了流程引擎的作用域。提升编程效率的最好途径总是语言而不是工具。

六、自动开始模式

在前面的资源模式里，我们讨论了创建模式、推模式和拉模式，它们实际对应着工作项的一个正常生命周期：创建、提供/指派、资源选取开始执行。在前面的讨论里，工作项的执行都是由资源驱动的（从工作项待办列表里选取执行），而自动开始模式则提供了一种系统驱动工作项执行的方式，系统直接驱动工作项执行往往表明了该工作项的最高优先级，需要马上开始执行。

图 5-42

如图5-42所示，自动开始模式对应着红线标识着的工作项的状态变迁，共有4种模式：创建即执行、指派即执行、成堆执行和链式执行。

 

1、创建即开始执行（WRP_36: Commencement on Creation）

描述

资源能够在工作项一创建完毕就开始执行。

图 5-43

如图5-43所示，任务A工作项一创建就插入员工甲的办理列表，需要员工甲马上开始执行。

 

应用

该模式应用在关键的优先级高的任务里，通过系统推送，强制资源优先执行该任务，省去任务的等待时间。

 

实现

该模式的实现实际是系统同时完成了工作项的创建和推送，系统需要确定具体的执行人，工作项不会分配给角色、岗位等资源组以提供给相应资源进行选择。

 

2、指派即开始执行（WRP_37: Commencement on Allocation）

描述

资源能够在工作项一指派完毕就开始执行。

图 5-44

如图5-44所示，任务A工作项一旦被员工甲从可拾取列表拾取就马上插入员工甲的办理列表，需要员工甲马上开始执行。

 

应用

该模式跳过了工作项的指派状态，实际是对创 建即开始执行模式的扩展，在创建即开始执行模式里，工作项必须预先确定明确的执行人，不能分配给角色、岗位等资源组，而在该模式里除了支持创建即开始执行 模式里的情况，同时也提供了对这种情况的支持，工作项可以提供给多个资源拾取，一旦一个资源拾取则必须马上开始执行（从这个角度看，该模式与资源驱动执行-提供工作项模式是相同的）。

 

 

3、成堆执行（WRP_38: Piled Execution）

描述

资源能够成堆执行相同任务的不同工作项。

图 5-45

如图5-45所示，员工甲有多个任务A的工作项需要执行，这些注意的是，这些工作项并不是由一个任务实例所产生的，它们属于不同的流程实例，是由多个流程实例里的任务A生成的。一旦员工甲开始任务A工作项的执行，那么他将执行所有任务A的工作项，即将任务A相关的工作项全部打包执行。这一功能由系统驱动，系统将与任务A相关的工作项依次推送至资源的办理列表。

 

应用

开发人员甲熟悉持续集成工具，此时同时有多个软件开发项目需要搭建持续集成环境。一旦他为某个项目组搭建了持续集成环境，那么处于执行效率的考虑，最好的方式无疑是他一鼓作气将所有的持续集成环境都搭建完毕。

相同/相似的工作交由同一资源一并执行，这些工作具有完全或大部分相似的执行上下文（相同的知识、能力要求），从这个角度能够达到最高的工作效率。

 

实现

系统需要在进行工作项状态变迁操作时提供相应的钩子，以进行相应的回调操作。

 

4、链式执行（WRP_39: Chained Execution）

描述

在一个流程实例里，当前一个任务的工作项执行完毕后，能够自动开始执行下一个任务的工作项。

图 5-46

如图5-46所示，任务A和任务B是两个连贯的任务，它们都分配给员工甲执行，当员工甲执行完毕任务A的工作项后，任务B生成的工作项将马上被系统发送至员工甲的办理列表，员工甲需要马上办理。

 

应用

该模式实际是将资源胶黏在一个流程实例上，同样是出于执行效率的考虑（两个任务位于同一流程实例里，具有相同的执行上下文）。该模式的应用具有前提条件：流程定义时，连续的任务由相同的资源进行处理。

 

七、可见性模式

可见性模式讨论各种不同资源对工作项的可见 性，不同的资源由于角色、权限的不同，对工作项拥有不同的可见范围。由于涉及到权限，那么根据不同的组织机构设置，必然会出现不同的工作项权限分配，这里 不讨论具体的工作项权限分配，仅从工作项的状态来讨论这些工作项区分可见性的必要性。

可见性模式包括2种：未指派状态工作项的可见性和指派状态工作项的可见性。实际上，工作项处于执行状态或完成状态也存在不同的可见性。

 

1、可配置的未指派工作项的可见性（WRP_40: Configurable Unallocated Work Item Visibility）

描述

能够配置未指派工作项的可见性。

图 5-47

如图5-47所示，可拾取列表里存在3个工作项：任务A工作项、任务B工作项和任务C工作项。员工甲可拾取的工作项包括：任务A和任务B工作项；员工乙可拾取的工作项包括：任务B和任务C工作项，那么由此产生的可见性是：员工甲只能看到任务A和任务B工作项，而员工乙则只能看到任务B和任务C工作项。而作为员工甲和员工乙的部门经理，他需要了解每个属下的工作情况，所以他可以看见所有甲乙可见的工作项。

 

应用

随着企业规模的发展，几乎所有企业的组织模 型都会形成金字塔型的结构，一方面是出于分工的需要，另一方面则是出于管理的需要，每一层级的人员都需要对上一级负责，同时管理下一层级的人员。处于管理 的需要，管理者必然需要了解下属的工作情况，这样权限就自然产生了，具体到工作流的任务里，管理者需要对其所管理下属的工作具有可见性。

其实不仅仅是对于工作项，对于流程实例本身 也具有可见性的分配。对流程负责的人必然具备最大的可见性和权限，流程根据任务分解，如果仅仅只对某一任务负责，那么则只对该任务具有可见性，而如果需要 对多个任务负责，那么就需要对多个任务具有可见性，最直接的负责人就是具体执行该任务的人员，但是引入管理的层级后，职责的承担也会形成层级的关系，从上 至下层层承担，此时担负最大职责的人员往往不再是具体的工作执行人员，而是相应的管理人员。

 

实现

在前面所描述的情况里，支持员工甲乙的可见性是比较简单的，因为每条工作项记录都携带有参与者信息，但是部门经理显然不在这些参与者信息里，所以需要引入与组织权限模型相匹配的工作项查询机制，即不同于工作项列表的查询列表。

 

2、可配置的指派工作项的可见性（WRP_41: Configurable Allocated Work Item Visibility）

描述

能够配置已指派工作项的可见性。

图 5-48

如图5-48所示，待办列表里存在3个工作项：任务A工作项、任务B工作项和任务C工作项。指派给员工甲的工作项包括：任务A和任务B工作项；指派给员工乙的工作项包括：任务C工作项，那么由此产生的可见性是：员工甲只能看到任务A和任务B工作项，而员工乙则只能看到任务C工作项。而作为员工甲和员工乙的部门经理，他需要了解每个属下的工作情况，所以他可以看见所有甲乙可见的工作项。

 

八、多资源模式

到目前为止，我们讨论的工作项都是与某一特定资源一一对应的，即一个工作项只能由一个单一资源执行，或者严格来说，一个工作项在任何时间段都只能由一个单一资源执行（考虑到工作移交的情况）；同时，一个资源在任何一个时间段都只能处理一个工作项。

多资源模式将会讨论两种不同的情况：一个资源同时执行多个工作项、多个资源执行同一个工作项。

 

1、同时执行（WRP_42: Simultaneous Execution）

描述

资源能够同时执行多个工作项。

图 5-49

如图5-49所示，员工甲的办理列表里有三个工作项，他能够同时执行这三个工作项。

 

应用

和计算机一样，虽然在任何时刻都只能处理一项工作，但是通过将多项工作切分成多个线程交替执行，从某个时间段看，人能够同时处理多项工作。

人能够选取相关联的多个工作，同时开始执行，在执行的过程中，合理安排这些工作的执行时机和顺序。

 

实现

几乎所有的工作流系统都不会约束人员往自己的办理列表里增加多个工作项。

 

2、增加资源执行（WRP_43: Additional Resources）

描述

资源能够要求增加资源来处理他正在执行的工作项。

图 5-50

如图5-50所示，员工甲和员工乙同时处理一个工作项。

 

应用

在一些复杂的场景里，一项工作往往需要多个资源共同协作完成。

典型的在一个会签任务里，一个发文需要多人签字通过，同时在会签过程中，经常出现动态加签的情况：需要新的人员加入进行签字。

在敏捷开发里，所有的开发工作都是由两个开发人员共同结对完成。

 

实现

工作项作为工作流系统里最小的工作单元，如果将其分配给多个资源，无疑会增加编程模型的复杂度。最常见的实现方式是增加工作项，一个任务节点对应多个工作项，对于需要增加资源的情况，增加工作项。

 

九、小结

在本章里，我们讨论了工作流的43种资源模式，这些模式分为7类，分别是创建模式、推模式、拉模式、折回模式、自动开始模式、可见性模式和多资源模式。

创建模式在系统创建工作项时生效，其位于工作项生命周期的创建阶段，创建模式作为流程模型的构成部分在流程设计期指定，通常在任务节点的定义里进行定义，与一个任务关联，其用来限定可执行该任务的资源范围。系统根据创建模式限定的资源范围生成工作项。

接下来，系统需要将工作项推送给相关的资源进行执行，这个推送的过程即是推模式所包含的内容。工作流系统通过工作项管理器即不同类型的工作项列表与用户进行交互，这里的推送可以理解为系统将生成的工作项推送至相应资源的工作项列表里。

推模式的主语是系统，由系统将工作项推送至资源的工作项列表，那么，接下来的主动权交由单个资源本身，由其拉动工作项的执行，这是拉模式所包含的内容。

实际工作中，工作的执行状态不可能总是与预想相符的，总会出现各种各样的情况，例如重新分配、重做、挂起等等。折回模式对应着这些情况，折回代表着工作项状态的反复、回退。

自动开始模式提供了一种系统驱动工作项执行的方式，系统直接驱动工作项执行往往表明了该工作项的高优先级，需要马上开始执行。

可见性模式讨论各种不同资源对工作项的可见性，工作项自身作为资源与权限相关。

多资源模式讨论一个资源执行多个工作项和多个资源执行同一个工作项的情况。

从这些模式的讨论可以看出，这些模式更多关 注的是对实际业务执行的场景描述，关注通过合理分配任务和调配工作的执行为组织带来最大的执行效率。从另一个角度看，由于这些模式都以业务作为出发点，这 给工作流系统的实现带来了复杂性，很多模式当前的工作流系统都无法完全支持或直接支持。在很多情况下，模式的支持需要很多的约束，而这种约束往往需要在工 作流实施阶段结合客户具体情况进行限定，这实际强调了工作流实施的重要性，工作流系统的应用是由工作流产品加实施两部分组成，很多时候，实施占据了更大的 比重，这就对工作流产品的可扩展性提出了要求。应用工作流不仅仅是选择工作流产品，更重要的还包括选择合适的实施团队。

在下一章里，我们将讨论另外一种工作流模式-数据模式。

五、折回模式

实际工作中，工作的执行状态不可能总是与预想相符的，总会出现各种各样的情况，例如原本分配给员工甲的任务由于甲要请假不得不重新分配，由于新的紧急任务员工乙当前的工作需要挂起一段时间等等。折回模式则刚好对应着这些情况，折回代表着工作项状态的反复、回退。

图 5-33

如图5-33所示，折回模式对应着红线标识着的工作项的状态变迁。这些状态变迁对应着以下情况：

委派：资源将先前指派给他的工作项委派给他人执行。

系统重新分配：系统将没有完成的工作项重新提供或指派给其他资源执行。

退回指派：资源撤销指派给他的工作项，工作项可以重新指派给其他资源。

工作移交：资源将其已经开始执行的工作项移交给他人执行。

挂起/恢复执行：资源临时挂起当前执行的工作项，并在某一个时候重新恢复执行该工作项。

跳过：资源选择跳过指派给他的工作项的执行，不执行该工作项。

重做：资源重新执行先前已经完成的工作项。

提前执行：资源在流程实际触发该工作前已经开始执行该工作。

折回模式共有9种。

 

1、委派（WRP_27: Delegation）

描述

资源能够将先前指派给他的工作项指派给另外的资源执行。

图 5-34

如图5-34所示，委派对应于红线标识着的工作项状态变迁。

 

应用

委派在平常工作中非常常见，例如员工甲将要请假，他将他要完成的工作委派给同事乙执行；在协同办公里，领导将相关工作委派给下属执行等等。

 

实现

实际应用中，委派按照粒度分为了两种：一种 是工作项的委派，这是一种细粒度的委派，指单一任务实例的委派，与某一特定的任务实例关联；另一种是业务的委派，这是一种粗粒度的委派，例如，员工甲将其 负责的某类业务的工作全部委派给员工乙，这意味着属于这类业务的所有工作都将由员工乙执行。业务的委派通常与权限紧密关联，实际实现时为避免用户权限的混 淆，一般采取分开登录系统的方式进行实现，即员工乙如果想处理员工甲委派给其的工作，则需要用员工甲的账号和其给定的密码重新登录系统，并注销掉自己账号 的使用。

需要注意的一点是：委派意味着原先指派的资源还必须对该工作负责，例如员工甲将某项工作委派给员工乙执行，尽管员工乙实际执行了该工作，但该工作仍然必须由员工甲负责。所以在实现中，员工甲必须能够保持对委派工作项的追踪和控制。

 

2、系统重新分配（WRP_28: Escalation）

描述

系统能够重新分配已经分配的工作项，以加快工作项的执行。

图 5-35

如图5-35所示，工作项原先提供或指派给了一个或多个资源执行，现在由于各种原因，需要优化该工作项的执行，所以将该工作项收回重新分配，提供或指派给其他的资源。

 

应用

工作分配的优化。很多时候，计划跟不上变 化，工作也是这样，分配工作前有许多的考虑因素，例如个人能力、工作经验、技能要求等等，但在实际工作中往往会发现原先的人力分配并不合理，或者有些人承 担了太多的职责，或者有人能力超出其目前担承的职责等等（在敏捷软件开发里，我们通过频繁的交换结对编程以达到部分的平衡），在这种时候就需要对工作进行 灵活的重新分配以到达最高的执行效率。

 

实现

实际实现中非常受限，对流程的优化始终是一 个对人的命题，而不是对机器对工具的命题，工具所能做到的只是尽可能多的提供可供参考的数据模型，例如各种报表、数据分析等等，最后做出决策的还是人。所 以该模式的实现也以提供给流程管理员重新分配工作项的能力为主，同时提供工作项超时的提示为辅。

 

3、退回指派（WRP_29: Deallocation）

描述

资源撤销指派给他的工作项，工作项可以重新分配给其他资源。

图 5-36

如图5-36所示，资源能够退回原先指派给他的工作项，该工作项可以交由系统重新分配给其他资源。

 

应用

同样是工作分配的优化，只不过该模式由资源驱动。

实际工作中，由于各种原因，例如经验不足、当前承担职责过多等等，发现自己并不能很好完成当前的任务时，可以提出不执行该任务。

 

实现

实现的难点在于资源退回工作项后的重新分配，即如何重新分配该工作项。

与提供给多个资源模式对应，该模式的最简单支持是退回重新提供给多个资源。例如工作项分配给开发人员这一角色执行，开发人员甲拾取了该工作项（故事卡），经过一番痛苦和彷徨，最终将该工作项退回，这样所有开发人员又都能拾取该工作项。

 

4、有状态工作移交（WRP_30: Stateful Reallocation）

描述

资源将正在执行的工作项移交给其他资源执行，该工作的状态将得到保存。

图 5-37

如图5-37所示，资源将已开始执行的工作移交给其他资源执行。该模式与委派模式很相似，差别就在于委派模式是将未开始执行的工作进行重新指派执行，而该模式则是将已开始执行的工作进行重新指派执行。委派模式中的委派者仍需要为委派出去的工作负责，而移交则同时意味着责任的移交。

 

应用

工作移交非常常见，最常见的原因包括位置调动、离职、休假等等。

 

实现

在大多数的工作流系统实现里，业务数据与流程数据是相互隔离的，仅仅通过某一字段进行关联（例如业务主键），流程的目标是携带业务数据进行流转。在这种情况下，该模式的实现变成了默认实现，系统不需要做任何回退或清理操作，直接做工作项的转发即可。

 

5、无状态工作移交（WRP_31: Stateless Reallocation）

描述

资源将正在执行的工作项移交给其他资源执行，该工作的状态不会得到保存。

与有状态工作移交对应。

 

应用

工作的无状态移交通常意味着工作的重新执行，并且原有的工作对重启的工作而言没有太大的价值。

 

实现

与有状态工作移交相比，该模式需要处理相应业务数据的回退或清理。直接支持该模式比较困难，需要在实施时根据情况对该任务节点操作业务数据的权限进行限定，并在限定的基础上进行记录和回退。

 

6、挂起/恢复执行（WRP_32: Suspension/Resumption）

描述

资源能够挂起当前执行的工作项，并在某一个时候重新恢复执行该工作项。

图 5-38

应用

资源对分配给其的工作进行优化执行，能够根据自己和当前的实际情况合理的安排工作执行，挂起正在执行的工作，执行当前最重要或效率最高的工作，然后再返回执行该工作。

 

实现

基本的状态变迁。

 

7、跳过（WRP_33: Skip）

描述

资源能够选择跳过指派给他的工作项的执行，不执行该工作项，并将该工作项标识为完成。

图 5-39

 

应用

实际工作中，对于非关键工作，可以选择跳过，以便进行后续更为紧急或重要的工作。

 

实现

对于实现工作项本身的状态变迁来说，支持该模式非常简单，问题在于业务数据的依赖关系，如果后续工作的处理依赖于该节点处理后的业务数据，那么简单的选择跳过该工作项的执行就会产生问题。所以一个好的做法是给一些关键任务节点加上约束，不允许执行跳过操作。

 

8、重做（WRP_34: Redo）

描述

资源能够对先前完成的工作项重新处理，同时，该工作的后续工作项（后续任务所对应的工作项）也将被重新处理。

图 5-40

 

应用

对已完成的工作进行重新处理并不少见，但该 模式最为重要的部分还是在于要求所有后续工作的重新处理。所以该模式一般应用在极其重要的关键任务节点，例如非常重要的决策节点，因为后续的任务严重依赖 于该节点所作出的决策（所产生的数据），一旦决策发生变化，那么相应的后续工作必须都要做出变化。这也是业务敏捷性的一种反映。同时需要注意，该模式也是 一种代价高昂的应用，因为这往往意味着该业务流程实例中的很多工作都需要重新处理，所以如何在业务处理中尽早发现可能的环境变化并及时作出决策的调整并避 免成本高昂的返工才是最为重要的一点。

现在的软件开发越来越强调于拥抱变化，强调 代码的重构和演进，尽管如此，如果软件的基础架构需要根据当前业务变化发生重大变更，那么这依旧是一件成本高昂的事情，因为一旦基础架构发生变化，那么很 多模块实现将不得不重新编写代码。所以尽管越来越多的开发团队开始引入敏捷的开发方法，但是经验丰富的开发人员才是整个敏捷团队的基石（敏捷开发非常重视 人）。

 

实现

从该模式里能够看到资源模式与控制模式的结合，工作项的重做需要后续任务的重新执行，这需要取消当前的执行任务，并将流程实例的控制点重新返回至该工作项所对应的任务。这涉及到两种控制模式，分别是：取消任务模式和任意循环模式（具体可以参考第四章的说明）。

 

9、提前执行（WRP_35: Pre-Do）

描述

在工作项实际提供或指派给资源执行之前，资源已经可以执行该工作项。

图 5-41

如图5-41所示，任务A还在执行，任务B还未激活，但此时员工甲已经可以开始执行任务B的工作项。该模式的实现需要一个前提条件：任务B不能依赖于任务A的执行结果，即不能依赖于前续任务的处理输出。

可以看出，该模式与前面推模式里的提前分配模式非常相似，所不同的是：提前分配强调一种通知机制，强调预先准备；而提前执行则已经可以开始实际的执行工作。

 

应用

和提前分配模式不同，该模式实际提供了一种 流程任务执行的灵活机制，在预先定义的业务流程里，任务的执行是具有一定顺序的，可能在大多数情况下，这种顺序是合理的，但是在某些具体的流程实例里，某 些串行执行的任务节点可以并行的执行以达到最好的执行效率和负载均衡，在这种情况下，就可以应用该模式并行执行部分任务。

需要注意的是，该模式仅仅引入了一种实际执行任务的灵活性，是对业务流程定义固化的补偿，如果在一个业务流程中频繁应用到该模式，则往往意味着流程定义本身需要作出调整。

本书全文连载地址
四、拉模式

与推模式相比，拉模式的区别在于动作的主语发生了变化：推模式的主语是系统，由系统将工作项推送至资源的工作项列表，那么，接下来的主动权交由单个资源本身，由其拉动工作项的执行。

图 5-28

如图5-17所示，拉模式对应着工作项的五种状态变迁：

由提供给一个资源拾取到指派给一个资源负责执行，这意味着该资源拾取了该工作项，其将负责该工作项的执行，并将在未来的某个时候执行该工作项；

由提供给多个资源拾取到指派给一个资源负责执行，这意味着多个资源中的一个资源拾取了该工作项，其将负责该工作项的执行，并将在未来的某个时候执行该工作项，余下的资源将不再有机会执行该工作项；

由提供给一个资源拾取到开始执行，这意味着该资源拾取了该工作项，其将负责该工作项的执行，并立即开始执行该工作项；

由指派给一个资源负责执行到开始执行，这意味着该资源开始执行该工作项；

由提供给多个资源拾取到开始执行，这意味着多个资源中的一个资源拾取了该工作项，其将负责该工作项的执行，并立即开始执行该工作项，余下的资源将不再有机会执行该工作项；

拉模式共有6种，分为两组：前三种模式关注工作项的状态变迁；后三种模式关注工作项显示在资源工作项列表里的顺序以及选择执行的方式。

 

1、资源驱动指派（WRP_21: Resource-Initiated Allocation）

描述

资源能够将工作项指派给自己，负责该工作项的执行，但是不必马上开始执行该工作项。

图 5-29

如图5-29所示，员工甲拾取了可拾取列表里的任务A工作项，该工作项由可拾取列表移至待办列表。可拾取列表通常是一个共享的列表，而待办列表则是某一资源的专属列表。资源拾取工作项，意味着工作项从共享状态进入到专属状态。

该模式实际对应着工作项的两种状态变迁：由提供给一个资源拾取到指派给一个资源负责执行；由提供给多个资源拾取到指派给一个资源负责执行。

 

应用

该模式符合大多数的工作场景，我选择负责执行该工作，但我并不马上开始，我可能还有其他的工作需要处理，等到处理完毕后才处理该工作。

 

实现

分配给角色、部门等资源组的工作项通常都以共享的形式分配给所有的组内成员，一旦有人拾取即进入他的专属待办列表，其他人不再可见。

 

2、资源驱动执行-指派工作项（WRP_22: Resource-Initiated Execution – Allocated Work Item）

描述

资源能够开始执行指派给其的工作项。

图 5-30

如图5-30所示，员工甲开始执行任务A工作项，该工作项由待办列表移至办理列表。

该模式对应着工作项的一种状态变迁：由指派给一个资源负责执行到开始执行。

 

实现

最基本的工作项状态变迁，所有的工作流系统都提供支持。

 

3、资源驱动执行-提供工作项（WRP_23: Resource-Initiated Execution – Offered Work Item）

描述

资源能够选取提供给其的一个工作项，并马上开始执行该工作项。

图 5-31

如图5-29所示，员工甲拾取了可拾取列表里的任务A工作项并立刻开始执行，该工作项由可拾取列表移至办理列表。

该模式对应着工作项的两种状态变迁：由提供给一个资源拾取到开始执行；由提供给多个资源拾取到开始执行。

 

应用

与描述略有不同，实际应用该模式是强制要求资源一旦拾取了共享的工作项就必须马上开始执行，基于两点的考虑：一是工作项能够尽快执行；二是工作项能够指派给当前最为空闲的资源，不会出现该工作项被一繁忙资源卡住，造成等待和阻塞。

在敏捷开发里，我们使用故事卡管理项目的开 发，故事卡足够小（如果大的故事卡则分解为多个任务），每天早上由开发人员挑选移动该卡，一旦该卡由可开发状态移动至开发状态，则必须进行该卡的开发工 作，这样项目的真实进展随时得到显示，同时不允许一个开发人员同时进行多张卡的开发。

 

实现

通过这三个模式我们可以发现，工作流系统实现这些模式只是在不同的工作项列表里移动这些工作项，以反映工作项不同的状态和变迁策略，这对于IT系 统而言这不是很困难，困难在于如何能保证人确实是这么做的，例如说一旦拾取就必须开始执行，工作项的跳转很简单，但无法保证的是拾取该工作项的人一定会按 照要求马上开始执行该工作项，也就是说业务流程项目的实施不仅仅包含技术实施，也包含了一套与之相应的管理实施。那种期望上一套流程系统就能马上提高生产 效率和管理水平显然是不现实的，其中一定包含管理方式的变化和组织机构的变化。

敏捷开发中，早上的站立会议是重要的部分，每个团队成员都会汇报昨天的进展和今天将要进行的工作，这样就保证了工作执行的有效性。

 

4、系统决定工作队列内容（WRP_24: System-Determined Work Queue Content）

描述

工作流系统能够排定资源工作项列表里的工作项顺序和内容。

图 5-32

如图5-32所示，员工甲共享的可拾取列表默认按时间排序工作项。

 

应用

实际应用中工作项的排序条件非常多，其目的就是将最重要或优先级最高的工作项排在最前面，引起资源的注意或优先执行。

 

实现

实际实现时有多种排序策略，通常会有时间排序，例如先进先出、先进后出等，同时也有很多其他的排序元素，例如工作项的预定完成时间、执行该工作项的成本预算、工作项的优先级或重要程度等，系统查询工作项时根据这些影响因素进行默认排序。

 

5、资源决定工作队列内容（WRP_24: Resource-Determined Work Queue Content）

描述

资源能够排定其工作项列表里的工作项顺序和内容。

 

应用

为资源提供一定程度上排定工作项的灵活性。每个人关注的视角和侧重点不同，就会产生不同的排序和内容过滤。

例如，作为老板，我可能更为关注各个工作的成本预算，我需要按成本排定各项工作；而作为秘书，我更为关注老板下发各项工作的重要程度，我需要按老板指定的重要程度排定工作。

 

实现

提供工作项列表的客户端排序，一般情况下列表显示系统给定的顺序，用户可以在客户端进行二次排序，典型的Web系统中，工作流系统提供JavaScript的表格控件，利用Ajax异步请求重新排序或进行工作项的过滤。

 

6、自主选择（WRP_26: Selection Autonomy）

描述

资源能够根据自己个人的情况选择执行工作项。

图 5-32

如图5-32所示，员工甲能够根据自己的情况选择执行任务A、B、C中任意一个工作项。

 

应用

尽管老板要求先实现功能最后再重构，但是我认为当前代码如果不进行一定重构会严重影响后续的开发效率，所以我决定先进行部分重构。

 

实现

几乎所有工作流系统都不会对用户实际选择执行工作项的方式进行限制，也没有办法限制。但是系统一般会把重要的工作项加以高亮显示，让用户优先选择。