未完待续。。。

第二章 业务流程范例

2.1 引言

2.2 表征过程的维数

第一章提到的结构化、半结构化、非结构化流程的概念，这种分类可以更正式地称为过程范例，用更简单的术语来表述典型的类型（即结构）。

下图所示为表征过程的维度。图片来源于Springer《Process Analytics》。

在上面这张图中，纵轴标识流程的三个主要维度，分别是：过程实现技术、过程模型/语言、过程案例。横轴显示了每个维度的选择，这也代表了一般的概念和技术发展。

  2.2.1 过程范例

过程范例是指过程或过程系统能够处理的典型控制结构类型。

通常有三种典型的结构选择：结构化、半结构化、非结构化。

结构化过程：

通常意味着要执行的功能、它们发生的顺序以及相关的过程控制可以预先准确描述。

因此这类别通常包括可以重复的操作过程。在许多情况下，结构化过程系统可能依赖于预定义的模式方法，该方法在执行过程中经常无法更新。

非结构化过程：

通常很难提前描述，这类类型的流程通常可能涉及很大程度的创造性，通常没有固定的事务描述或流程结构，由于这个原因，基于预先定义的方案显然行不通。

半结构化（基于案例的）过程：

展示了两种类型的活动。虽然他们可能采用某种结构，但与非结构化过程相比，它们仍需要一定程度的灵活性。半结构化过程的一部分可能被很好的定义，而其他部分不能被完全指定。

  2.2.2 过程表示模型/语言

这个维度表示过程设计者为了指定他们想要的过程而可能提供的语言、模型或接口。有三类主要的类别：以活动为中心、以规则为中心、以工件为中心。

但是还可以考虑第四类：视觉界面。如思维导图界面以推动业务互动的方法，或者是基于表单的界面。

以活动为中心：

代表了基于特定顺序的从一个活动到另一个活动的控制流。流程任务根据他们之间的依赖关系进行排序。这种方法适合结构化流程。

以规则为中心：

本质上更少结构化，更不易于在流程中强加顺序。他们非常适合于捕获在活动之间几乎没有约束的过程，并且其中一些规则可以指定该过程。尽管提供了这种额外的灵活性，但纯基于规则的方法只适用于规则数量相对较少的小规模流程（理解和维护起来是可行的）。

以工件为中心：

在过程相关工件的上下文中定义的活动，这些活动基于工件上的数据事件变得可用。

  2.2.3 过程实施技术

用于实现过程支持的底层技术可以被认为是表征过程系统的另一个方面。共有以下三种实现技术：

工作流引擎：

依赖于业务流程（或工作流程）的概念，它通常由定义流程中节点执行顺序的有向图来指定。还引入了流程实例的概念，表示工作流的执行。一个工作流实例可能被实例化多次，而且相同或不同工作流的多个实例可能同时运行。此外，*工作流引擎是执行工作流实例的工具。

规则引擎：

一般是从管理和处理大数据流的需要中产生的，这也导致了复杂的事件处理器和随后的反应式规则引擎。规则引擎确保规则在事件发生时解释事件并**相关的流程分支。

程序化控制流程：

这种方法更传统。可以将正在执行的过程视为硬编码编程语句的规范。

 

2.3 过程实施技术

  2.3.1 工作流引擎

下图表示工作流引擎执行过程（通常是：调度和资源分配）。图片来源于Springer《Process Analytics》。

  2.3.2 规则流引擎

    2.3.2.1 事件-条件-执行规则

    2.3.2.2 生产规则

  2.3.3 程序编码

2.4 过程范式：框架和工具的调查

  2.4.1 结构化过程 

    2.4.1.1 活动中心

    2.4.1.2 数据/工件中心

    2.4.1.3 规则中心

  2.4.2 非结构化（特设）过程

  2.4.3 案例案例（非结构化）过程

    2.4.3.1 案例管理的共同特征

    2.4.3.2 回顾现有方法

2.5 结论和未来方向