《Process Analytics 过程分析》读书笔记第二章业务过程范例

本文链接：https://blog.csdn.net/fu_jian_ping/article/details/110009879

第二章业务过程范例

毫无疑问，在过程管理中的研究和开发为技术革命铺平了道路。更重要的是，过程管理技术在今天也同样重要，就像它在两三年前成立时一样。然而，主要转移的是主要重点。例如，在1990年代，重点是过程自动化，以便通过加强系统集成和业务逻辑的自动化执行来减少人员的参与。这是因为过程的全部或部分自动化创造了前所未有的机会，在企业中提高过程执行的能见度，而在随后的十年里，重点转向了过程改进，这就需要理解和分析业务流程，使用各种信息系统和服务及其集成来实施。在本章中，我们概述了围绕业务过程管理的技术景观，并为理解分析业务过程的不同方面设置了舞台，目的是改进它们。

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 规则引擎

“规则引擎”通常是指以任何形式使用规则的任何系统，这些规则可以应用于数据以产生结果。

由于需求的增长，导致系统不断地被开发，这些系统被设计成根据一组预先部署的处理规则来处理信息流。

这些系统由很多不同的方面，如架构、数据模型、规则语言和处理机制。

近年来主要出现了两种主要的模型：数据流处理DSP模型（主要处理数据）和复杂事件处理CEP模型（主要处理事件）。

这两种模型都影响了现代事件流处理器和基于规则的引擎。

2.3.2.1 事件-条件-执行规则

事件-条件-动作（event-condition-action， ECA）规则赋予更新在本地或远程资源中找到的数据的能力，交换关于事件的信息（例如执行的更新），以及不仅对简单事件，而且对由事件的时间组合表示的情况进行检测和反应的能力。

在网络上传递事件的两种可能的策略：a.推策略：这意味着一个网络结点向其他感兴趣的网络结点通知事件，通常要求感兴趣的各方订阅更改；b.拉策略：这意味着感兴趣的网络结点必须专门和定期地查询在其他网络结点发现的数据，以确定变化。

虽然这两种策略都很有用，但推送策略通常比定期轮询更有优势，因为它允许更快的反应，避免不必要的网络流量，并节省本地资源。

ECA规则由三部分组成，其应用形式为：如果条件为“是”，则指定我们希望在事件发生时自动执行该操作。

事件：事件部分驱动ECA规则规范的执行。事件的一般概念可以被认为是系统的状态变化。

条件：条件部分通常表示对事件模式捕获的数据进一步查询。条件查询也用于确定规则是否将触发（即动作被执行）。

行动：规则的动作部分通常服务于修改当前系统状态的目的，这可能包括更新持久数据以及过程调用，并且还可能导致引发新的事件。

2.3.2.2 生产规则

2.3.3 程序编码

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

2.4.1 结构化过程

2.4.1.1 以活动中心

以活动为中心的结构化流程系统通常指工作流管理系统或是最近的业务过程管理系统。这是因为本质上，“业务或工作流过程模型”的概念恰好符合“以活动为中心”模型的定义，因为它代表了过程中结点之间的执行顺序。同样，“业务或工作流过程实例”的概念精确地满足了这些过程类型的结构化特征——因为过程实例通常是指过程模型的不变的实例化，只有当过程结构良好并且不需要持续的灵活性时，这才是合适的。

2.4.1.2 数据/工件中