BPM建设不同于传统的基础信息化项目，它具有如下的 特点。

● 有着极强的导向性：面向价值增值（战略目标）而非仅仅实现当前业务。每个流 程和流程里的每个活动都可以用指标衡量其价值贡献（相对于战略目标）。因 此，BPM的建设成功与否，可以用企业最为熟悉的商业价值评估体系来评判并优 化调整。

● 以端到端的业务流程为中心：这意味着流程梳理是BPM建设的前提条件。基于片 断化的、局限于部门内部的流程建设，BPM难以获得BPM带来的价值。

● 由业务而非I T驱动：这意味着业务人员将从单一被动的需求提供者和业务执行者 的角色提升为更积极主动的业务设计者、业务优化者角色。业务人员和I T人员将 密切配合起来。

● 强调服务的编排和集成：利用并整合企业资产（包括I T和非I T），以快速、敏捷 地建设和变更业务流程。从开发到应用，周期短、见效快。因此，S O A是建设好 BPM必不可少的条件。

正是由于上述BPM项目区别于一般信息化项目的显著特点，BPM的实施方法论也与通常 的信息化项目有着巨大的区别。

一、BPM项目实施和其他项目实施的主要区别

那么，BPM项目实施和其他IT项目实施的主要区别在哪里呢？ 前面说过，BPM主要是由 业务来驱动的，这个特点决定了流程的开发是“粗粒度”的（或者说是“业务粒度”的）。 所谓“粗粒度”和“业务粒度”，是指BPM通过业务人员可以理解的业务步骤（即流程中的 活动“环节”）的概念来描述业务的主要活动，屏蔽掉了业务部门不必关心（或者看不懂） 的细节。

• 开发一个业务流程最先要定义的，是定义出流程中的“泳道”。泳道界定了这 个流程要管理的“业务粒度”的边界，规定了流程中不同角色的范围和相互作 用关系。
• 所谓“BPM”（业务流程管理），是要管理一个有序的业务过程的“流动”。流 程中的“泳道”里面有“环节”，每个“环节”都有“状态”，代表着业务活动 中的一个状态点。这个环节状态是业务部门所理解，同时也可以被业务部门监控 和度量的状态。这个状态又是有序的，流程中一个业务环节状态的“结束”，标 志着流程中另一个业务环节状态的“开始”（当然也不排除有“并行环节”的流 程）。这些环节状态的顺序变化表述了一个有明确业务含义的流动，是一个由 “粗粒度”颗粒组成的，具有明显业务意义的流动。
• 流程的每个环节都可以被“绩效”，可以通过流程的“业务绩效指标”来监控和 改进流程效率。也就是说，流程的监控是在业务粒度上的监控，以提供企业的业 务价值为目标。
• 如果是以人工任务为主的流程，每个环节的执行人需要依赖于公司人员的组织结 构和岗位角色的结构。由公司的组织结构和业务内容来决定“谁”可以做“什 么”业务。
• 对于人工环节的表单开发。表单是根据业务人员实际工作的前端页面设计的， 直接表示业务的应用页面。因此，BPM的产品套件一般都带有图形化表单设计工 具，以便和业务人员更方便地交流，甚至能让业务人员直接使用。BPM的产品套 件里面也有“页面流”的开发工具，让业务人员更方便地开发表单逻辑。

以上这几个特点都说明了流程的开发是围绕着业务的粗粒度的开发，需要在流程开发设 计的过程中更多地和业务人员交流，一起来完成流程的定义、开发和改进。

当然，根据BPM要管理的流程的不同，这个“粒度”的大小也不同。BPM梳理方法论里 面说的BPM的五级流程（流程分级在第3章内有详细阐述），对应的就是五种粒度。第一个 是企业高层要管理的粒度（战略级的业务粒度）；第二个是部门级要度量的粒度；第三个是 业务分析师在描述具体流程时需要有的业务粒度；第四个是执行层面的流程的粒度（执行环 节）； 第五个是执行层面的简单操作的粒度（如表单业务逻辑）。粒度不同，流程的开发和 处理方法也不同。例如，第四级或第五级流程的粒度最细，属于执行层面的流程，通常有IT 部门的介入。

因此，流程开发是一个“粗粒度”的组合式开发过程，也是一个不断迭代、不断改进的 过程。和一般IT项目相比，流程开发是使用符合业界标准的流程工具进行开发。纯代码的开 发量相对较少，开发人员更多的是使用图形化工具定义流程，对参数进行定制，通过服务的 调用去编排已有的服务。因此，BPM项目的开发强调了如下内容。

• 交流。不断地和业务部门交流，共同开发流程。业务部门应该能够使用流程开发 工具对流程进行定义和修改，用标准和工具来减少开发过程中I T部门和业务部门 的交流障碍。
• 简单。流程开发是一个“粗粒度”的开发，需要业务人员的参与驱动流程的开发 和完善。正因为如此，流程开发需要一个“粗粒度”的开发模式。在这个“粗粒 度”下，要尽量屏蔽掉业务人员弄不懂的I T语言和实现，尽量使用业务人员能够 看懂并使用的流程开发工具。
• 流程生命周期管理。基于业务流程经常需要变化的背景，流程开发必须把流程的 生命周期管理作为流程开发不可忽略的部分。这里需要考虑的不仅是流程模板的 版本控制机制，还有流程实例对版本的升级机制（分水岭，一刀切），以及流程 部署上线的运维管理流程等。

二、BPM“粗粒度”开发的基本原则

“粗粒度”（或者“业务粒度”）开发模式的基本原则如下。

• 用标准的、图形化的、可定制化的流程产品开发工具开发流程和表单，尽量避免 使用代码。
• 把需要用代码开发的部分尽量包装成可重用的组件，一般分为两类组件。 一类是可以重复调用的服务，这个服务要包装成为“粗粒度”的有业务含义的 服务（即S O A）。S O A的出现是流程管理技术从工作流转向业务流的分水岭，是 指SOA的服务使BPM的开发可以简化成为一个个“人工任务环节”和“SOA服务环 节”，把业务人员不懂的IT细节屏蔽在SOA的服务环节之内。 一类是公用的基本模块库，可以在搭建流程平台时作为平台模块库提供。例如， 将常用的表单模板、常用的子流程、常用的开发环节表单所需要的组件（菜单、 按钮、人员选择框等）封装成组件的目的，是要尽量保证在这个“粗粒度”以下 的这些业务组件（S O A服务）的相对稳定性。这样在未来不断的流程改进中，业 务人员可以简单明了地掌握流程的各个环节，需要时直接组装和重用（而不是重 新开发）流程中的各个组件。
• 先搭建流程平台，再做具体业务流程的开发。在流程项目实施时，首先搭建业务 流程平台，也就是把常用的公共组件建到流程平台上，把企业常用的典型流程模 板库放在平台上。在流程平台搭建完毕后，再开发具体流程。这样，具体的流程 功能开发就可以重用平台的通用功能模块和流程库，做到真正由业务驱动的“粗 粒度”开发。
• 把业务人员可以定制的业务规则（包括人员任务分配规则）外挂，成为通过业务 人员制订（而不是开发）就可以改变的业务组件。

三、BPM项目开发的范围和步骤

明确BPM项目的范围

正如前面所说，BPM的一个管理方法是对企业各个层级的业务流程的管理，应该覆盖企 业战略管理、战略流程定义、业务构建、业务流程定义、业务服务定义和编排、业务执行和 监控、业务流程优化和改进以及战略调整等几乎企业管理的方方面面。但是，这样的说法显 得比较空洞。人们马上就要问，BPM是要取代目前所有的业务应用系统吗？是要取代企业的 运营架构吗？是要取代企业核心的ERP套件吗？ 答案显然是否定的。BPM是一种管理理念。 BPM并不是要取代现有的系统，而是利用（或者重用）现有的系统，达到管理企业各个层级 的业务流程的目的。那么接下来的问题就是，BPM项目的实施是怎样利用现有的系统的？ BPM的实施范围在哪里？BPM应该从哪个应用系统首先开始实施？等等。本节将和大家探讨 的问题如下。

● BPM的范围在哪里？BPM的管理边界在哪里？哪些流程是最适合BPM管理的？

● 从项目实施的角度来看，如果企业要分步实施BPM项目，应该先实施哪种类型的 流程、后实施哪种类型的流程？最佳实践是什么？

在前面的章节里分析了流程开发的“粗粒度”和“有序”的特点。就是说，最适合BPM 管理范围的业务流程，是可以梳理出让业务人员管控的适当的“粒度”， 而且具有“有序” 的状态变化的流程，对这个流程的管控可以给企业带来商业价值。从这个角度看，人工工作 流自然就成为BPM最常见的应用对象，也是目前大多数BPM项目的实施范围。因为用“人 员”（或者岗位、角色）来界定工作流的粒度是非常清晰的，环节状态的变化显而易见，环 节的路由路线和跳转也非常清楚，业务人员看得见、摸得着。同时，对工作流程的管理和监 控能大大提高工作管理和人员管理的效益，带来商业价值。

从技术的角度来讲，人工工作流 的实施有三个挑战，即流程建模和流程环节之间的状态跳转、人工任务的人员分配、环节 内的表单和表单业务逻辑。在这三个方面，用Java或者其他语言直接开发会遇到一定的难度 （例如，如何处理状态机，如何处理多并发下的死锁问题，如何进行流程的生命周期管理， 等等），而目前商业化的流程产品都有很完善的模块，这也是BPM产品在人工工作流方面被 普遍应用的原因。当然，在用BPM进行人工工作流的开发时，用到的方法论是前面说过的以 业务驱动的BPM的方法论，和以前用纯工作流的方法论相比，在理念上是更新的。这个更新 很重要，在本书后面的章节中会看到，正是这个理念上的更新，可以把企业BPM项目的范围 从人工工作流扩展到其他种类的业务流上去， 最终实现企业对业务流程的全面管理。

沿着“人工工作流”和“粗粒度”这两条思路，还可以类比出适合BPM管理的其他业 务流程。这些流程都有“粗粒度”和“有序”的特点，都是业务人员能懂而且需要介入的流程，都会给企业带来商业价值。 下面就是适合BPM管理的流程类型。

● 人工工作流：用“人员”界定被管理的边界。

● 状态机：用业务事件触发的“状态”界定被管理的边界。

● 跨流程的业务活动：由几个流程的相互耦合形成的控制流程，流程之间通过一个 统一的业务编号（如订单号）耦合。

● 跨部门的业务活动：用业务部门的某个关键行为界定被管理的状态的边界。

● 跨系统的业务活动：用子系统的某些关键行为界定被管理的状态的边界。

● 跨应用套件的活动：如CRM套件和SAP套件之间互动的业务内容。

● SOA服务编排：用“粗粒度”的服务界定被管理的边界。

● 上述流程的组合。

例如，企业中的项目管理流程属于“协调流程”，有许多部门参与，项目进程中的各个 里程碑也表示着项目进行中的“状态”，这样的流程就适合用BPM来管理。可以用项目进行 中的“状态”作为活动环节，用和项目相关的部门作为“泳道”，当“项目”状态发生变化 时，流程就发生流转。

又如，一个跨系统的工单管理，从CRM套件的客服系统给出订单，到SAP套件里的采 购、生产、入库、物流，再回到客服系统，这个描述订单状态的流程也可以用BPM来管理。 这样的流程可以被认为是“三级流程”，就是说，这个流程的环节不再是完成某个具体的任 务，而是监控工单的流动状态

BPM项目实施的顺序

在后面会讲到BPM的“成熟度”的概念，就是说，BPM的实施是一个分阶段的循序渐 进的过程。根据企业BPM的成熟度，逐步落实不同层次的业务流程管理。2.3.1节里面的调查报告 反映了这一点。许多企业目前需要进一步做的，是在人工工作流的基础上，对BPM的实施范围进 行拓展，将其拓展到管控级别上来，从而走向下一个成熟度的里程碑。根据在1.6节中从战略层面 讨论的BPM项目实施的层次和方法，企业应该按照下面的次序逐步开发企业内的流程项目。

● 人工工作流：应该按照“粗粒度”的原则开发。

● 协同流程：跨“边界”（即跨系统、跨应用、跨部门）的业务协同流程。

● 三级流程的监控流程：开发针对粒度为三级流程的监控流程，所监控的流程环节 为主要业务活动的里程碑，或者某个执行流程中的一个状态，而不是具体的执行 环节。

● 基于SOA的自动流程。

● 二级流程以上的监控流程：根据业务的需要，在三级流程的监控流程实施以后可以开发二级甚至一级流程的监控流程。

实施这几类项目的时候要把握业务驱动这个核心。正是因为BPM对业务的粗粒度的界 定，使得业务人员可以介入，可以用粗粒度的业务语言去描述企业的业务现象。当开发人工 工作流的时候，企业需要通过项目的实施，逐步建立起IT部门和业务部门的合作机制，建立 起企业流程管控的组织架构，搭建起企业级的流程平台，然后以这个流程平台和管控架构为 基点，以“粗粒度”开发为原则，就可以开始实施协同流程和监控流程，打通执行层面的流 程和管理层面的流程的互通机制，达到让业务流程管理与业务战略相融合的目的（详细的方法见BPM和企业业务框架(EA）的关系）。与此同时，还需要不断地对人工工作流加以改造，尽量把人工环节进行业务的 优化分解，逐步用粗粒度的服务（SOA）代替人工环节，变人工工作流为自动工作流，提高 企业的工作效率和灵活性。

四、搭建流程平台的步骤和开发原则

流程“粗粒度”开发的原则之一是，先搭建流程平台，再做具体业务流程的开发。所谓 “流程平台”，就是要搭建一个企业共享的功能模块平台，把流程开发中可以重用的模块和 服务放在共享平台之上，让一个具体流程的开发变得简单。由于目前大多数企业实施的都是 人工工作流，这里就用人工工作流作为项目目标， 谈一谈搭建针对工作流的流程平台的内容 和开发原则。

有一点需要指出的是，这里所说的平台搭建，并不是要开发人员完全自己搭建一个流程 平台。IBM的BPM产品套件，本身就具有强大的平台功能。基本能够满足企业对于流程平台 的管控需要。在下面的内容里讨论了平台的搭建内容和原则，更多的是基于产品已有的平台 功能进行定制。根据企业的需求，给出平台定制的规范。

1、人工工作流平台开发的内容

人工工作流平台开发的内容如下。

● 定义并建立流程平台和企业门户系统、业务系统之间的逻辑关系。企业门户系统、 业务系统和流程平台（包括服务总线平台）通常是三个系统互相独立、属于松耦合 的体系架构。它们之间如何相互整合，是建立流程平台要解决的第一个问题。

● 定义并建立流程平台对外提供的标准AP I接口，让业务系统可以进行流程的启 动、挂起、结束以及人工工作项的查询、认领、提交等动作，以及获取业务监控 绩效指标的接口。

● 建立流程平台常用的功能模块。

流程常用的功能模块：流程的触发、挂起、恢复、终止。

人工任务常用的功能模块：任务的抄送、回退、取回、跳转。

企业常用的“流程模板库”：把企业常用的经过优化合并的流程模块写入“流程 模板库”。

人工任务分配策略模块：建立常用的任务分配规则。

路径选择和人员选择模块。

人工任务重新分配和任务代理模块。 统一的工作任务列表。

统一的业务日历。

统一的工作流异常处理机制。

● 建立流程监控的基本机制和监控页面。

● 建立和服务总线的整合调用机制。

● 建立流程生命周期的管理：管理所有流程的注册、发布、更新、归档、流程版本 控制。

● 满足流程平台的非功能指标。

● 建立流程部署的环境：开发环境、测试环境、生产环境。

● 建立流程平台的运维规范。

平台软件的安装、部署、升级、迁移规范。

流程版本更新操作规范。

平台流程引擎调优指南。

出错处理机制和出错管理界面。

消息管理机制：发送邮件和短信通知。

数据备份机制、归档机制。

高可用和灾备的操作规范。

2、人工工作流程的开发原则

针对人工工作流的三个挑战（流程建模和流程环节之间的状态跳转、人工任务的人员分 配、环节内的表单和表单业务逻辑），流程的开发原则有如下四个松耦合原则。

● 流程的路由环节和环节内的表单逻辑松耦合：工作流的“粗粒度”特点表现在流 程模板层面，工作流只关心泳道的定义、环节的状态和路由、和谁来执行该环 节。至于环节内的业务实现，是由表单逻辑控制的。这两部分应该是松耦合的。 当流程路由发生变化时，环节的实现不受影响；同样，当环节的实现（表单逻 辑）发生变化时，流程的路由逻辑不受影响。

● 流程路由和环节的执行人的任务分配规则松耦合：为了使各地区、各部门都可以共享同一个流程模板，把环节执行人的分配规则外挂，由基于业务应用、地区、 法规和部门等参数的业务规则决定环节的任务分配。

● 流程和后台服务松耦合：流程本身不做具体功能的实现，而是重用已有的服务。 通过服务总线，与适配器和后台系统（或者应用）进行整合，调用已有的服务。

● 流程数据和业务数据松耦合：即轻流程的原则。

这四个松耦合使得流程变“轻”，这就是所谓“轻流程原则”，其本质的目的还是让业 务人员能容易地操控流程的建模和监控，把许多业务人员不关心或者不容易明白的东西剥离 出去，更容易应变业务需求的不断变化，更容易进行流程的业务梳理和归并，更容易重用已 有的服务。

实现轻流程理念的一个重要内容是流程数据和业务数据松耦合，即在具体开发流程的时 候需要分离三种数据结构，如下。

● 业务数据：和该流程业务有关的数据（即表单的业务数据），一般存放在后台的 业务系统数据库内。

● 流程业务数据：和流程直接相关的业务数据，直接与流程流转、任务分配、流程 追踪有关的业务数据，与流程监控有关的业务数据（KPI）。

● 任务列表数据：人工任务列表用到的数据结构

定义和处理流程这三种数据的原则如下。

● 尽量采用轻流程原则，只把少量的和数据流程直接相关的数据定义为流程数据， 参与流程的流转，大部分的业务数据均在环节的表单实现中从业务数据库中直接 调入。如果业务数据调用的逻辑关系复杂，可以考虑采用页面流的逻辑。

● 将这三种数据分离之后，还必须有一个机制将这三种数据耦合在一起。为了流程 平台的扩展性，比较常见的做法是用三个I D标识符把三者耦合起来，即流程实例 I D、任务实例I D和业务数据I D。有了这三个标识I D，就能够实现流程数据和业务 数据的分离，并能在需要相应数据的时候方便地进行关联处理，形成处理流程业 务耦合问题的三把钥匙。其中，根据不同的应用，业务数据I D会有所不同，如订 单号、合同号、客户号等。

● 需要注意的是，当采用了轻流程的开发方式以后，实际上就是把流程的流转逻辑 和每个环节上表单开发的业务应用进行了松耦合。由此带来的一个问题是流程流 转和环节业务应用的同步问题。当出现异常情况时，要注意流程如果回退到前一 个环节，那么相应环节的业务应用也应该一起回滚。

● 人工任务列表的数据尽量不用或者少用业务数据，除非查询人工任务时需要用到 业务字段。可以考虑把业务数据I D放入人工任务列表，这样可以通过业务数据I D 查找其他相关业务信息。

3、建立流程平台的“流程模板库”

流程平台的一个重要内容是建立企业内常用的流程模板库，这样做的目的是梳理出企业 常用的流程模板和常用的业务环节，从而可以在实施新的流程时提供参考和指导。具体的流 程梳理和流程模板库的开发原则请参考第3章的“流程梳理方法”相关内容。

4、流程平台的对外接口

流程平台对于流程实例和任务实例的管理，通过流程引擎对外暴露出来的接口API调用进 行。流程设计人员可以根据需要调用流程平台的API。常用的接口需求如表2-1所示。

5、建立统一的人工任务分配策略模块

搭建流程平台时，把常用的任务分配规则写成服务。建立一个“人员组织架构和任务分 配系统”。该系统是一个人力资源分配系统，是由流程平台开发组和业务部门负责制订和维 护，里面包括人员的权限控制和基于业务规则的人工任务分配机制。该系统对外提供一个可 供流程调用的服务接口。

该服务接口的输入参数如下。

● 流程模板名：由流程给出。

● 该流程模板的人工任务环节名。

● 流程里的BO：由流程给出，其中包括流程实例标识（PIID或者业务数据ID）。

● 如果需要更多的业务数据，“人员组织架构和任务分配系统”会根据业务系统的 业务数据（BOUUID）由系统到相应业务系统中获取。

● 分配类型：表示人员分配为单人userID类型还是组GroupID类型。 该服务接口的输出参数如下。

● 为该流程节点分配的一个人员userID（或角色ID）或者组GroupID。

● 为该流程节点分配的一个人员列表数组（userID1，userID2，userID3…）。

任务的分配规则基于业务变量，即地点、法规、部门、业务板块、岗位、金融类别、客 户类别、后台，还可以基于人员的当前工作量、技能以及是否在工作岗位。流程在定义环节 执行人的时候，可以通过一个团队（Team）的属性绑定这个服务接口。流程引擎在执行时就 会自动调用该团队的服务接口，以获得执行人信息。

6、建立统一的人工任务列表

人工工作流的一个重要工作就是管理人工任务。对任务的管理，集中体现在人工任务列 表。流程平台建立了统一的工作任务列表，具体开发人员要做的是了解如何使用和定制工作 任务列表。 工作任务列表分为下面几类。

● 我的待办任务：列出属于某个用户的所有任务（包括可以申领但还没有申领的 任务）。

● 我的团队的待办任务：列出属于某个角色（部门或者岗位）的所有任务（包括可 以申领但还没有申领的任务）。团队任务又可以细分为属于团队的所有任务（包 括可以申领但还没有申领的任务），属于团队的还没有申领的任务。

●属于一个业务板块的待办任务：列出属于某个业务板块的所有待办任务。

● 属于一个业务板块的任务：列出属于某个业务板块的所有任务（包括已办结 的任务）。

● 自制订的任务列表：由于业务的特殊需要而定制的任务列表。 根据任务的流程实例标识（ProcessID）、人工任务标识（TaskID）、业务数据标识 （BOUUID），开发人员可以对该任务进行处理。常见的任务处理行为如下。

● 任务认领：声明拥有这个任务，其他人不能再处理这个任务。

● 任务认领释放：释放认领，让其他人有机会认领这个任务。

● 任务完成：通知流程引擎该任务已经完成，可以流转到下一步。这一动作是整个 环节业务处理完成以后的最后一步。

● 任务的再分配：把该任务分配给另一个人。

● 任务的挂起：暂停执行该任务（这时绩效指标计时也同时停止）。

● 任务的恢复：恢复被挂起的任务。

● 任务的跳过：在特殊情况下，跳过该任务，直接把该任务标记成完成。

● 任务督办：给任务执行人或执行人的经理发出通知，督促加快办理任务。

● 任务出错管理：当任务的状态是“异常”时，处理异常并重新启动该任务。 常见任务列表的数据结构如表2-2所示。

五、具体流程的开发步骤和开发原则

建立了流程平台之后，具体流程功能的开发就相对简单了。对于一个人工工作流，流程 主要由若干个“人工环节”的节点组成，辅助一些系统自动环节。对于一个流程的开发，开 发流程是任务，主要分为如下六个步骤。

● 定义流程的业务数据结构。

● 定义泳道并画流程图（指定各个环节之间的路由规则和跳转规则）。

● 指定环节的属性并指定环节的执行角色以及任务分配规则（包括权限规则、任务 列表）。

● 开发环节中涉及到的表单和表单背后的逻辑（包括和后台系统的整合）。

● 给出流程监控的绩效指标。

● 和业务人员一起对流程进行“回放”，改进流程设计。

对于人工工作流，流程的开发是明确定义流程的输入、输出、活动步骤以及相关人员 等，回答为什么做、做什么、怎么做、谁来做等问题。

1、定义流程的业务数据结构

根据开发流程的三种数据结构的处理原则和实际业务需要，定义流程数据主要考虑流程 的流转逻辑、流程绩效指标需要的业务数据和表单的业务数据。人工待办列表的数据已经由 流程平台给出标准和实现。开发人员一般不需要再做开发。

2、定义泳道并定义路由逻辑（画流程图）

为了更直观、更有效地描述流程，通常采用流程图来展示。在开始画流程图之前，要首 先定义出“泳道”。泳道用来区分不同部门或者不同参与者的功能和职责，定义了流程所要 管理的粒度边界。对于人工工作流，泳道的定义非常容易，就是任务节点执行角色（一个岗 位或者部门）。对于自动节点，泳道是该业务功能属于的子系统、部门或者板块。定义了泳 道，就可以清晰地定义出这个流程所管理的业务活动的范围。

流程图是流程路由的定义，流程路由的模式应该尽量符合基本流程模式标准。

3、流程的路由逻辑

在流程设计时经常遇到分支。当路由出现分支，而且路由分支的逻辑仅仅是因为执行角 色的不同，就应该简化流程。例如，在地区A，路由到环节A，在地区B，路由到环节B，而 且环节A和环节B的不同仅仅是执行角色的不同（环节A由角色A执行，环节B由角色B执行， 但环节A和环节B的执行内容相同）。建议把这两个执行环节合并，用业务规则去确定执行人 的角色，这样就会减少因为业务场景不同而增加流程模板的复杂度。如果流程中遇到下面的 这些变量，可以尝试通过运用业务规则的方法简化流程模板，增加流程模板的重用性。

● 地区的不同。

● 部门的不同。

● 岗位的不同。

● 板块的不同。

路由分支的逻辑可能因为执行角色的不同而不同，这时可以通过运用业务规则的办法解 决问题，但在有些情况下会更为复杂。

在这里特别提一下所谓的“动态流程”。动态流程是指流程中的路由跳转逻辑是动态变化的， 甚至可以动态地增加或减少流程中的环节，而且造成流程跳转逻辑变化的因素不可预料，没有办法通过模板把流程固定。

例如，流程模板定 义了一个审批环节，但对于某个子公司或者地区，审批环节需要变成两个审批环节。这种情 况给流程开发带来了困惑，也是到目前为止一个比较有争议的流程开发方法。用动态流程开 发的好处是，可以提高流程模板应对业务变化的灵活性；但缺点是，不利于该流程环节的监 控，也增加了开发的难度。一般情况下，不建议采用动态流程搭建一个具体的业务流程。

相反，动态流程一般是用于搭建一个描述某类特定业务的“业务流程模板”，即在给定的业务 规则下（如给定表单数据结构、给定环节类型等），由用户自己选择路由逻辑和人员分配， 是属于搭建“流程平台”的范畴，其目的是要降低前端业务人员开发流程的难度和技术门 槛。动态流程一般是由IT部门的流程平台开发部门搭建，并配备有图形化的流程配置页面， 以便于开放给终端客户使用。因此，动态流程也被称为“基于业务规则的业务流程引擎”。

当业务需要实现一个动态流程时， 开发人员可以通过下列步骤实现动态流程。

● 首先查看流程平台是否已经提供了预定义的“动态环节”。如果流程平台已经提 供了可以重用的环节，就不需要再开发。如果流程平台没有预定义此类的动态环 节，则进行下面的步骤。

● 在定义环节类型时，定义流程中需要动态改变的环节类型为“业务自定义环 节”，并定义一个实现这个环节的子流程。

● 开发一个子流程去实现这个动态环节。一般来讲，这个子流程是由一个由规则导 向的循环实现。

● 开发相应的业务规则，控制动态子流程。业务规则需要包括：

规则定义下一个执行路径。

规则定义下一个执行人。

规则定义相关业务属性。

制订动态节点的数据结构和表单，这里要求所有在同一个循环里面的节点都采用同一个 表单和同一个数据结构。如图2-1所示

4、指定环节的属性并指定环节的执行角色以及任务分配规则

环节的定制

环节可以是一个简单的人工任务，也可以是一个已经在流程模板库（Toolkit）里面的子 流程。开发者要首先定义环节类型，常见的环节类型如表2-3所示。

流程的权限和环节角色的制订及任务分配

人工工作流的一个非常重要的任务就是管理什么人可以做什么事。因此，权限的指定和 任务的分配是人工工作流中不可缺少的一步。在第4章的第3节中会专门讲解如何实现人工任 务的分配，这里是给出几个基本原则。在BPM的项目实施中，需要指定流程的管理权限（并 指定相应的角色）。这些权限包括如下内容。

● 流程开发时，指定流程模板的读权限（可审阅）和流程模板的写权限（可编辑）。

● 流程运行时，指定流程实例的权限，即启动、挂起、恢复、终止权限。

● 流程运行时，指定任务实例的权限，即查询、认领、提交、任务重新分配等。

几种任务的分配模式如下。

● 直接分配。在上一个环节页面中直接指定用户名，运行时把任务分给此用户。

● 基于角色的分配，按泳道的角色分配。按泳道分配还可以细分为：

属于所在泳道角色的任意一个参与者。

执行人必须是同一泳道中的上一个节点的同一个执行人（职业完整性原则）。

执行人必须是同一泳道中的上一个节点的非同一个执行人（职责分开原则）。

委派给一个泳道角色的一个指定人员。

基于一个业务规则的分配。

确定人员之后，流程设计人员还需要指定如何把任务推送给他们。

● 竞争模式：符合条件的人员都会被通知有新任务，当其中一个人开始处理此任务 之后，其他人就看不到该任务了。

● 推送模式：系统通过业务规则把任务指派给一个人，这个人必须完成该任务。 其他需要设计人员考虑的几种特殊的任务分配情景如下。

● 跳过（绿色通道）：是否允许这个环节的任务可以被流程管理人员（或者经理） 在某种情况下指定为跳过（无人执行），并直接把它标记成完成。

● 任务重新分配：允许指定的流程管理人员（或经理）重新分配当前的任务给其 他人。

● 任务代理机制：当某个员工请假或调动工作，他以前的任务和将来的任务被指定 的代理承担。

5、表单和表单逻辑

表单

人工工作流的表单开发和一般表单开发一样，只是多了表示任务完成并控制流程流转的 任务提交按钮。设计人员需要考虑的按钮类型如下。

● 任务正常完成（如审批同意）并由系统自动流转到下一个环节。

● 把任务退回到前一个环节（如审批不同意）。

● 如果需要，先指定下一个流程路径或者指定下一个环节的执行人，然后提交 任务。

● 页面流之间的流转按钮 （如下一步、上一步）。

对于一些动态性的流程，表单逻辑中还包括了指定下一个流程环节的支持。即，在流程 运行时，下一个路由路径由上一个环节在人工页面中指定。当业务需要进行路由选择时，开 发人员需要通过下列步骤实现动态路由的选择。

● 在流程数据结构中增加一个描述环节名的属性和一个描述任务执行人的属性。

● 在表单开发时，用流程平台提供的“路径选择和人员选择模块”，定制上一个环 节选择路径的操作页面。分别让用户选择下一步环节名，或者选择环节执行人。

● 利用流程平台提供的“路径选择和人员选择模块”中的动作按钮，选择“指定 下一个流程路径或者指定下一个环节的执行人”按钮，调用流程平台接口实现 环节跳转。

● 定义谁可以进行路由指定（任务执行人、经理或系统管理员）。

表单逻辑开发

对于一个人工环节，可能有几个表单，或者虽然是一个表单，但在填写表单的同时，需要 根据表单内容调用后台的应用，然后再回到该表单。这时，需要开发人员定义表单之间、表单 和后台之间的流转及调用逻辑（通常被称为“页面流”逻辑）。页面流逻辑常常可以由流程引 擎自带的图形化流程开发工具提供，这为设计人员提供了设计页面流逻辑的易用的开发环境。

在用图形化流程开发工具定义页面流逻辑的同时，还涉及到了表单及后台数据的交换和整 合的问题。开发规范应该规定如果需要调用后台服务，则必须在页面流里面增加服务调用节点 以实现服务调用。如果要获取业务数据，BOUUID就是耦合流程数据和业务数据的标识。

这里值得一提的是，IBM BPM表单开发工具（Coach）提供了强大的页面开发功能和页 面流功能，其设计理念是让用户可以用简单拖曳的方法设计表单，并用图形化工具设计页面 流。

6、给出流程监控的绩效指标

开发流程的同时，要指定流程应该达到的绩效指标。根据这个绩效指标所涉及的数据设 计该流程的业务数据架构，并设计绩效指标的计算方法。流程引擎自带的流程开发工具会给 出系统默认的KPI列表，开发人员根据需要选定KPI。在特殊情况下，设计人员也可以自定义 特殊的KPI指标。

7、流程回放

流程开发的“粗粒度”特性，要求流程开发人员和业务人员定期地进行流程回放。所谓 “流程回放”，是和业务人员一起，用流程工具提供的流程回放功能对建立的业务流程（包 括表单）进行场景回放。其间，讨论流程人员开发的流程模板和业务人员的流程功能开发说 明书是否一致，有没有需要改进的地方，同时也要检验流程模板描述的业务活动环节，这都 是具有业务意义的，已经屏蔽掉了业务人员弄不懂的IT内容，保证流程的“粗粒度”性，以 便和上级流程（二、三级流程）进行衔接。

流程回放是保证流程健康性的一个必要步骤，是流程开发过程中必须要定期执行的。流 程回放的内容如下。

● 流程开发的“粒度”是否为业务人员明白的业务内容，尽量屏蔽业务人员不懂的 IT部分。

● 流程的业务数据结构是否和业务需求一致。

● 流程图的各个环节之间的路由规则和跳转规则。

● 各个环节的执行角色以及任务分配规则（包括权限规则、任务列表）。

● 各个环节的表单展现和表单逻辑（页面流）是否和业务需求一致。

● 流程监控的绩效指标是否和业务需求一致