1 BPM方法理论
流程管理的思想，经历了从workflow、BPM和BAM(Business Activity Monitoring)几个阶段。上个世纪90年代WfMC工作流参考模型的发布，标志着工作流思想的成熟。后来逐渐形成了BPM的思想，BPM从workflow阶段只关注流程的执行，到具有企业高度的流程管理，乃至流程治理，涵盖设计、建模、执行和优化周期。BPM出现了多个相关的规范，涉及流程的符号表示、数据表示、业务编排、流程执行等，这些规范有互相补充、也有互相重叠。
BAM是BPM之后由甘特公司提出的，强调对BPM要有持续有效的监控，即时发现流程中的问题，并对其优化，提高效率、提高企业效益，形成一个良性循环。因此BAM思想是对原有BPM思想的一种补充。BAM涉及到对大量数据的分析，因此跟BI（商业智能）有一些关系。有不少BPM工具或平台都或多或少的体现了BAM，更有很多BPM工具或平台把BAM作为目标。
因为BPM着眼于整个企业，因此BPM的建设应该成为企业一项战略性的任务。为了能够支持企业不同的业务，BPM最好独立于业务系统，跟业务系统通过Web Service等标准技术来交互。BPM跟SOA的结合，可以大大提高BPM的效用，因此企业最好有自己的SOA设施。建议企业建设一套ESB系统。
有了企业的BPM相关设施的支持，可以按BPM相关的思想来分析、优化业务流程。分析、优化均从业务、企业的角度出发，技术是为业务服务的，如果选用的BPM工具不能满足要求，就要考虑改造或定制BPM工具本身。
BPM的建模语言有多个，包括XPDL、BPEL、BPMN。其中XPDL是较早的工作流定义语言；BPMN（目前版本是2.0）目前使用得最为广泛，它有标准化的符号、较强的表达能力。BPEL是流程执行语言，适用于Web Service的服务编排。
2 分析和建模
以下主要基于BPMN的概念和思想，介绍具体设计一个业务流程时的分析过程，包括要考虑的一些问题。
2.1 资源
资源主要指的是流程中的人员、角色。当然人员、角色可以不同的叫法，角色用来定义一组人员，也可以同时使用多种对人员分组的方式。在定义一个业务流程时，首先要清楚的就是任务由哪些人/角色来完成。参与的人/角色要预先在系统中定义。
人员和角色都可以是分层次的，分层次可以便于流程的定义，例如人员可以按组织机构来定义层次。
清楚了流程中所参与人员、角色的范围，便有以下问题：
l 流程任务指派到个人还是角色，还是两者？如果指派到多人,或者两者都指定，那么最终由谁来办理？
l 如果任务指派到个人，则办理任务的人员何时指定？在流程定义时还是流程执行时？流程执行时指定，比如办理一个任务时由办理人指定下一任务的办理人，或者由业务系统程序来设定下一任务的办理人。
l 任务指派采用“推模式”还是“拉模式”，还是两者。由上一任务的办理人指定下一任务的办理人，就是推模式。拉模式每个人在办理自己的任务时不用考虑下一步由谁来办理，当流程走到下一任务时，由任务潜在拥有者自己领取任务。任务潜在拥有者是指属于办理人列表或角色列表。
l 任务的拥有者是否可以重新指派任务（让其他人办理），或撤销任务（流程回退），或跳过任务（不执行操作直接完成任务）等等。
l 当流程有企业外部的人员参与时，如何处理？可以给企业外部的人员建立账号，与内部人员同样使用系统。或者任务办理人设定为内部用户，当外部用户实际办理完成时，内部用户在系统中触发完成流程中的任务。或者流程中定义为自动任务，由BPM外部的事件触发，当接收到信号或事件时任务自动完成。
以上问题，有些是需要权衡的。例如在流程定义时把任务指派到个人，可以让职责更清晰，不需要在流程运行时指定办理人，或在有多个潜在拥有者时不存在推诿任务（均不领取任务）的问题。但当要重新指定办理人时，就需要修改流程定义，再发布一个流程。
以上问题都考虑了之后，对流程中资源的需求就比较清楚了。考虑以上问题时，往往需要结合流程中的任务来考虑。
在流程图中，通过使用池、泳道，可以很清晰的体现流程中涉及的不同角色，和不同角色直接的协作。
2.2 任务
任务的划分和定义是流程设计的关键工作。一个任务就是流程中的一个步骤。任务可分为自动任务（或叫非人工任务）和人工任务，自动任务由流程引擎自动执行，不需要人的参与，人工任务需要人来完成。自动任务可以包括：脚本任务（执行本地一段脚本，shell/bat）、服务任务（调用Web Service等）、业务规则任务（执行指定的业务规则）等。例如跟其他系统的交互可以定义为一个服务任务。
除了人工/非人工任务，还有考虑任务的其他性质。是单纯的表单录入任务、还是审批类的任务；是业务系统内的任务，还是涉及企业其他业务系统的任务；是企业内的任务，还是涉及其他企业、客户的任务（例如调用其他企业的接口，给客户发送邮件）；是正常流程的任务，还是异常处理的任务，或流程前面任务的补偿任务（undo）。
对于自动任务，可以考虑以下问题：
l 采用什么类型的自动任务？本地脚本需要在流程引擎所在的服务器上运行。服务任务可以调用Web Service （SOAP或REST），也可以定制自己的服务（一般引擎都支持）。对于易变的业务规则，使用规则引擎是比较合适的，如果流程本身不支持业务规则，可以定义自己的服务任务，在其中调用规则引擎。
l 自动任务的执行时机，一般流程到达自动任务后，任务会立即开始运行。比如任务A跟任务C之间是一个自动任务B，则任务A完成之后任务B会立即启动，可能迅速完成，流程到达任务B。如果不希望立即运行，可以考虑加入定时器，或者自动任务由消息、事件来触发。
l 自动任务要求是同步还是异步的？如果其他任务依赖于此自动任务的输出，就要采用同步模式，否则可以考虑异步模式，通过使用并行网关，自动任务和其他人工任务可以同时开始。
l 服务任务的定制，企业应该有统一规划，统一管理，定义流程时只需要从中选取一个服务。例如想要获取近几天的天气，如果已定制了这个服务，流程定义时只需要拖动一个图标或从列表中选择即可；获取天气的服务执行时会把获取到的天气信息放在某个约定的流程变量里，后续的任务从中读取即可。
对于人工任务，跟人员有关的考虑已在前面“资源”部分讲到。定义人工任务时需要指定任务具体办理的业务功能，可以通过给任务关联一个业务表单或业务功能标识来实现。
人工任务可以处于不同的状态，不同状态之间的迁移就形成了状态迁移图。不同状态所允许的操作以及操作之后的状态迁移都有定义。不同引擎支持的状态数和状态迁移图可能不一样。任务的典型状态有，就绪、已接收（已领取）、处理中、暂停、失败、完成等。流程引擎或业务系统可以考虑简化用户的操作，例如对于任务唯一的办理者，不需要明确地领取任务。
正确划分和定义任务之后，还要分析任务间的关系，包括任务的依赖关系，先执行哪个才能执行哪个，哪些任务是可以并行开始的，等等。这就要考虑流程的控制结构。
2.3 控制
在流程中使用网关来体现控制结构。网关分为分支（或叫互斥）、同步（或叫并行）、条件同步（相容并行）等。对网关的使用，有以下建议。
l 明确使用网关来建模流程流向，不采用隐含的表示。具体来说，一个任务不应该有多条的进入路径，如果要有，先经过网关汇聚成一个路径，再进入任务。
l 分支不应使用太复杂的条件表达式，如果过于复杂，则可能是没有把业务梳理清晰。
l 给网关起一个名字，便于人理解，而且在流程有错误时引擎可以给出有提示性的信息。
l 给分支网关后的分支设置一个有意义的名字。例如一条路径叫“通过”，另一条叫“不通过”。
l 多个网关的组合使用，形成了一个个工作流的模式，可以参考已有的模式，但不要刻意套用。
2.4 事件
很多流程引擎，尤其是体现BAM的引擎，都支持事件机制。采用事件机制，可以定义复杂的流程，实现复杂的流程控制、信息交换。
有时候，流程中多个任务都可能触发某个状态的改变，而这个状态的改变需要引起其他多个任务的执行。如果不采用事件，流程几乎是没法定义的。采用事件，则定义某些节点触发事件，某些节点捕获事件。这相当于注册一个事件监听器。
在BPMN2中，事件有多种类型，例如可分为开始事件、中间事件和结束事件，又可分为中断事件和非中断事件。中断事件在触发事件后会中断当前子流程的执行，非中断事件触发事件后继续执行当前子流程。根据事件的语义，又可划分为多种，包括常规事件、消息事件、时间事件、取消事件、补偿事件等等。具体根据情况来选择。
2.5 其他问题
2.5.1 流程开始
如何开始一个流程实例，有多种方式。
l BPM开放接口，其他直接调用接口启动流程。
l BPM在ESB注册接口，其他系统通过ESB调用BPM接口启动流程。
l BPM在ESB监听消息，接收到消息后启动流程。其他系统向ESB发送消息启动流程。
从业务用户的角度，启动方式有：
l 用户在业务系统明确触发启动一个流程（直接调用或通过ESB）
l 用户在业务系统执行操作，业务系统透明的启动一个流程（直接调用或通过ESB）
2.5.2 子流程
如果一个复杂流程包含一部分通用的流程，可以将其单独定义为一个流程，然后在复杂流程中引用它。在复杂流程中它就是一个子流程，叫可重用子流程。可重用子流程使得公共流程可以单独维护，简化了复杂流程的定义。
在BPMN中，子流程有多种类型，除了可重用子流程，还有嵌入子流程、多实例子流程等。嵌入子流程在父流程中直接定义，虽然不可重用，但可以起到隔离变量、事件的作用。多实例子流程也是父流程中直接定义，但可以根据某个集合创建子流程的多个实例。
2.5.3 异常
对流程中的一些异常情况，包括业务处理中的程序错误、流程中跑出的异常事件、任务执行失败等，需要采取一些策略来处理。根据业务情况，可以考虑以下一些策略。
l 结束当前执行路径
l 结束流程
l 结束流程并启动新流程
l 采取重做策略。例如重设失败的任务状态，重新办理任务。对于自动任务，可以实现重做策略，可设置重试次数
l 执行补偿任务，即执行一个任务抵消失败任务的影响
l 对于子流程，可以通过事件通知父流程异常的发生。
3 业务流程优化
业务流程的优化，应该贯穿于整个业务流程管理的过程之中，从流程设计、建模、执行中以及执行后，都要考虑流程优化的问题。
3.1 引擎的支持
流程引擎有一些功能，可以对流程优化有帮助。
l 日志记录。几乎所有的引擎都可以记录日志，日志内容包括，流程的开始和结束信息，节点的进入和离开信息，任务办理信息等。有些引擎还允许支持自定义的事件接口回调，当启动或结束一个流程、进入或离开一个节点时可以得到调用，在其中开发人员可以决定记录哪些信息。事后可以根据这些流程日志分析，可以知道每个任务平均花了多少时间办理、哪些流程路径走的比较多，哪些人员的任务比较繁重，等等，根据这些分析结果来决定如何进一步优化流程。
l 流程执行时的监控。体现BAM思想的引擎都支持流程执行时的监控，采用的往往是跟流程事件同样的机制来实现。这个事件机制可能是一个CEP（Complex event processing）实现。在流程执行中一定的条件符合时，引擎会执行预定义的动作，记录一些信息、或触发某些事件。例如一个任务在一段时间都没有完成时可以给某些人员发送邮件。又例如流程触发某类事件时，可以额外执行一些动作，这些动作是没有预先定义在流程中的。
l 流程执行模拟。设置一定的环境，可以模拟一个流程的执行，在运行期和运行后可以做一些统计分析。例如，所有分支都同概率的情况下，哪些任务会被执行的比较多；在任务办理的时间呈某个概率分布的情况下，整个流程走完的时间的概率分布是怎样的。这些分析有助于流程的优化。
3.2 技术上的支持
l BPM跟SOA结合。除了其他系统使用BPM会更加方便以外，BPM调用其他系统也有了一致的接口，便于流程定义和监控。BPM也可以从ESB中接收消息，触发相应的流程。
l 引入规则引擎。如果流程引擎本身不支持，可以定制一个规则任务，在任务中调用规则引擎。对复杂易变的任务，或者触发条件复杂的业务规则，又或者有大量的数据需要匹配规则，可以考虑采用规则引擎来处理。
l 引入数据分析支持。BPM的流程日志、监控会积累越来越多的数据，如果没有有效的数据分析技术，这些数据就没有多大用处。这需要一些BI有关的技术（因此说BAM跟BI有一些关系），包括报表、多维分析、数理统计，甚至数据挖掘等技术。
3.3 一般化的优化考虑
以下一些一般化的流程优化考虑，可供参考。
l 增加自动化任务，通过标准接口或ESB接入其他系统，获取业务数据、决策支持，执行业务操作等，减少手工操作
l 减少流程在不同人员/角色间流转。流程在不同人员/角色之间流转，可能会带来沟通成本，最好是某个人/某个角色在把能办理的任务都办理完了再一次转换人员/角色
l 同理，减少流程在不同部门、不同企业间流转的次数
l 采用事件/消息建模复杂流程
l 对于长时间未领取、领取后长时间未完成的任务有通知机制，可给指定的业务人员、系统管理员发送通知
l 基于对流程数据的分析结果，发现流程瓶颈，例如某些人员的任务较多，某些任务办理耗时较长等
l 基于对流程数据的分析结果，发现流程可能存在问题的地方，例如有些路径从来没有走到，有些任务常常执行失败，等等
3.4 业务分析
一般化的优化考虑，可以提供参考，是否采用，还要看具体业务的情况。
l 首先是这个任务有没有必要，例如某些审批步骤
l 一个任务能不能快速结束。例如某些会签任务，不需要所有参与人员都审批完就可以完成
l 一个任务能不能用自动任务代替。例如获取某些信息、日志、存档等任务，不需要人工来触发
l 任务是否可以同步。这要确定任务间的依赖关系，没有依赖关系的任务可以考虑并行处理
l 合理把任务指派到个人，避免某个人任务过多，延迟流程进度。例如尽量把并行的任务指派给不同的人员