业务流程的计算机建模优化

在理解了业务流程的概念以及CRM的流程应用需求的基础上，需要进一步来研究流程的应用设计，第一步即业务流程的计算机模型的建立。一个概念只有被“结构化”和“模型化”才可能被计算机管理，这是计算机应用的首要前提。

1）事务（Activity）

在工作流管理中，活动（Activity）是指逻辑步骤中的一项工作任务，与业务流程中的事务是同一个词。但这里用事务更多的是指一个计算机语言，活动不太适用于建立需要准确概念的模型，它主要指流程的构成组件，为作区别，把它称为事务。

（1）事务的定义

事务是一个流程中执行某个特定功能的组件。比如，激发另一个流程的启动，向其他应用发送消息，呼叫一个电子邮件程序等都是活动。一个活动可以很简单，也可以很复杂。一个流程中如果嵌套了另一个子流程，那么这个子流程本身也是一个事务，换句话说，一个子流程对父流程来说是一个事务，但就这个子流程来说，它是一个流程。

（2）事务的种类

按照事务所执行功能的复杂程度，可以分为原子事务和复杂事务两种类型。

原子事务是指这个事务无法继续细分，在执行时具备“有或无”（All or Nothing）这两种状态。比如，呼叫另一个程序这个事务，要么无呼叫，要么有呼叫，中间不存在别的状态。

复杂事务通常用来协调多个原子事务和复杂事务的执行，包含一个或多个事务集。它必须决定内部需要执行的事务个数及执行顺序。复杂事务还以继续细分为更小的事务，在执行过程中存在多个中间状态，如果要实现“或无”的执行特性，必须采用类似于数据库管理系统中的交易“回滚”特性。

（3）事务与流程的关系

在计算机模型上，可以简单地理解为一个流程是由一系列事务组成的，以达成一个特定结果，如图8.6所示。

图8.6　事务与流程的关系

从图8.6 上看，每个事务之间好像没有联系，不像一个“流程的样子”。理解这个问题的根本在于流程模型中对事务这个实体的定义。事务之间之所以没有“连线”，是因为一个流程之中的事务的方向性和关联性是可以在事务的属性中定义的，如果现在就把它们都连起来，好像一个流程事务之间的顺序已经安排好了，这就会失去流程执行时的灵活性。而且，在流程过程中，各个事务的发生顺序并不总是“单线的”，其他如并行的、反复的，甚至中途放弃也都可能发生。

（4）有关事务的几个概念

·事务执行容器（Context）：容器是事务运行环境。一个事务总是在一个容器中得以执行，在同一个容器下执行的多个事务之间往往会共享一些属性值。另外，基于同一个事务可以激发出多个事件（Instance），这些基于同一个事务的事件只能在同一个运行环境里进行，容器的使用可以有效管理和控制事务的执行。

·事务集（Activity Set）：所有放在同一个容器里执行的事务集合称为事务集，事务集有两个属性（Attribute），即事务集名称以及事务集所含各个事务的名称。

·事务事件（Activity Instance）：事务被激活后成为处于运行状态的事件，事件的生命周期如图8.7所示，其正常结束经历工作中、结束中和正常结束3 个状态，在出错时则有放弃状态。一个事务可以同时激发多个事件，都在同一个容器下运行。

图8.7　事务事件的生命周期

（5）事务的种类

根据流程中各个事务的功能特性，BPML（Business Process Modeling Language）标准定义了16 种事务，下面简略说明一下这些事务（见表8.2）。

表8.2　事务类型

续表

2）业务流程种类和属性

一个流程实质上是一种特殊类别的复杂型事务，在执行过程中有属于自己的运行环境（Context），每个流程包含一系列事务，可以顺序执行，也可以并行执行，流程完成后实现特定流程结果。

（1）流程被激活的过程（Instantiation）

一个流程主要由另一个流程发来的消息（Message）激活。这种由消息激活方式发生在具有“松耦合”特征的两个流程之间，每个流程相互独立，因此，流程的交互可以在异构平台下进行。一个流程也可以由其他方式激活，比如，它可以由另一个流程直接调用“Call”，或者连接（Join）的方式激活，这种激活方式发生在两个“紧耦合”流程之间，无法跨越异构平台。两种不同的激活方式如图8.8所示。

图8.8　消息激活与调用激活方式

在流程被激活时，各种参数由源流程事务（Output）写入被激活流程的第一个事务的输入属性（Input），流程执行完毕，根据流程的输出定义决定返回值。

（2）顶级流程和嵌套流程

顶级流程独立于任何其他流程，它有完全属于自己的运行容器，可以随时被别的事件激活；嵌套流程是在另一个环境下所定义的流程，嵌套事件的发生必须依赖于所指定的容器内，只能被属于同一个容器的事件或“子容器”内的事务所调用。

（3）流程事件（Instance）

像事务事件一样，流程事件也有它的生命周期。自被外部消息调用开始，一个流程事件的状态变化如图8.9所示。此图相对于事务事件的状态，其流程事件多了一个可以恢复到工作状态的暂停状态，可以暂时将流程挂起直到恢复。

图8.9　流程事件的生命周期

3）CRM的业务流程应用

CRM应用中，集成以工作流技术为主的流程功能是目前大多数CRM 产品提供商所采取的通常做法。从严格意义上说，真正的业务流程管理是建立在底层应用之上，任何同底层“紧耦合集成”的流程应用都是一个局限，只能作为一个过渡性的权宜之计；企业级的流程应用必须跨越底层的任何具体应用，而且还需要跨越企业的组织界线，同企业的业务伙伴、银行等真正实现端到端的全程性业务流程的自动化。(www.xing528.com)

尽管如此，在理想的业务流程管理系统出现之前，一些技术实力雄厚的CRM 应用提供商在自己的产品中加入符合未来开放标准接口的流程应用，为CRM升级的应用预留空间。当然，开发任何产品都要有前瞻性，符合技术发展的基本趋势，以免浪费宝贵的开发资源。

下面从流程的计算机模型出发，提供CRM流程应用的基本构架，并对构架中各个“原材料”分别加以说明。

（1）业务流程的基本功能框架

首先，以一个典型的重要客户通知流程为例，分析从设计到触发内外部事件一直到成功执行所经历的各个基本环节，从而对流程应用建立一个基本的概念。

功能框架应用举例：

①企业政策

为了加强同重要客户的关系，销售部规定从2018 年10 月起，如果客户的订单额达到5 000 元，系统必须自动向负责该客户的销售人员的手机发出一个短信息（SMS），这个消息包含了该客户的名单、客户联系人和订购产品编号等有关信息。

②政策的计算机规则

条件：订单额＞=5 000 元AND订购时间＞=2018 年10 月1 日。

行动：发送SMS信息（客户名单，联系人姓名，所订产品编号，产品名称）给销售人员。

对这样一个规则，如果没有流程应用，就必须编写一个计算机程序来具体实现这个企业规定。而且，多数情况下，这种程序灵活性很低，只要企业政策有所变化，比如政策有效期、订单额大小调整、发送信息内容变化和发送信息对象变化等，肯定又要对源程序加以修改。如果企业某一天取消了这条政策，那么原来的程序可能就会浪费。

③如果有一个CRM流程应用，其一般步骤如下：

·销售经理将这项政策转换化为计算机规则，即定义条件和行动。

·在图形化流程设计工具中新建一个流程，称为重要客户SMS 订购通知，由于在流程库中已经有订购额比较事务，日期比较事务，订单信息查询事务以及发送SMS事务，因此，用户只要简单地采用鼠标拖放就可以完成这个流程的设计，并且，对每个部分的属性进行必要的赋值，如果某个需要的事务在数据库中没有，则必须先行建立该事务。

·当用户将这个流程存贮后，这个设计应用在流程数据库中添加XML 格式的流程定义，并填写流程中每个事务的属性值，过程如图8.10所示。

图8.10　流程设计与流程模型

·用户在流程设计界面中单击“激活”按钮，此流程设计应用向事件触发器发出“新事件监控”监控请求，并附带流程识别号。当事件触发器处理这个请求时，发现是内部应用事件触发（本地数据库订单额≥5 000 和日期≥20181201），于是在数据库中提交数据触发命令（SQL Create Triggers），并随时监控数据库触发事件的产生。

·一旦事件触发器发现该事件触发记录，会立即将该事件消息以及流程标识发往流程引擎。

·流程引擎根据流程标识号码，利用BPQL语言向流程数据库查询该流程的所有执行信息，并根据流程定义运行该流程。

·流程被执行过程中，需要调用本地应用所提供的数据库操作服务（订单信息查询）以及SMS发送API，每一个事务的执行都携带各个参数值，直至流程执行完毕。如果执行过程中有错误，流程引擎利用内部的出错处理事务进行处理。

以上通过一个例子来说明流程应用中各个模块的功能，下面将对各部分的功能设计进一步分析，如图8.11所示。

图8.11　流程应用功能框架

（2）流程设计图形化用户界面

图形化流程设计应用的底层是一个流程数据库，这个数据库主要是一个流程描述的元流程（Meta Process），可以用XML来记录，也可以用其他数据库记录。不过，为了标准化目的，最好采用基于XML的标准流程模型化语言（如BPML），为今后B 2 B流程整合提供前提条件。应用程序可以采用客户/服务器（C/S）方式，也可以采用浏览器/服务器（B/S）方式编写，由CRM设计人员自己选择。

流程应用的主要设计要求是简单易用，适用于非IT 人士。因此，可以集成一定的企业政策及规定的定义功能，提供企业的规定与具体流程的对应关系，当然这要求在数据库中添加政策的存储记录。另一个功能是流程仿真功能，这部分可以通过流程引擎实现，即将仿真命令当成流程引擎的一个特别的事件触发输入来处理。

（3）流程发动机：流程引擎

流程引擎（服务器）是流程执行程序，这个程序首先要监听由事件触发器传来的各种事件。一旦截获特定事件，必须按照事件流程对应表执行流程。引擎解读流程库中流程事务等定义，将各种输入输出参数按定义准确传递（改变属性），并相应调用系统所提供的各种服务和程序接口，产生各种规定的输出。

流程引擎应用是以事件为驱动的，在设计中同时要考虑负载平衡、内存垃圾处理和安全等一般系统设计要求。

（4）事件统一入口：事件触发和监控程序

大多数企业业务流程的执行都是条件触发的，即有“如果：行动”这样一个逻辑，也是从日常运作中的各种业务规定演化而来。数据库管理系统都有触发器的功能，当数据表中某项操作的发生，如插入、更新和删除等，系统会自动触发某个规定的动作，这些触发信号都可以作为流程引擎的触发信号。本地数据库触发器所发生的触发可以称为本地应用事件触发，另外一类触发信号是由外部应用发出的，如网络服务的SOAP（简单对象访问协议，Simple Object Access Protocol）信号，或其他应用请求信息。事件触发和监控程序的目的就是随时监听各方事件，并按照事先规定好的事件流程相关参数和流程标识等信息向流程引擎传达。这样，流程引擎便可以根据事件和流程的对照表将事件分流至相应的流程初始化程序，完成相应的流程事件。

（5）流程API

除了流程设计界面、流程引擎以及事件触发与监控程序以外，还有很多内部、外部的应用接口供流程引擎使用。这些程序有些是本地的，如CRM 软件所提供的各种服务程序（数据库操作和整合适配器等），有些是根据第三方API设计的，如通过MAPI设计的电子邮件发送程序、传真程序和无线应用接口等，另外一类是通过互联网的网络服务或传统的EDI处理程序等。程序库越丰富，流程应用所能做的实际操作也就越多，CRM 客户功能的选择余地就越大。

另外需要说明的是，由于流程引擎没有同CRM的多层应用架构直接发生关系，CRM应用的商业逻辑和具体数据库操作的实现是通过这些API调用实现的，因此，将整个流程应用看成一个同一般CRM应用相互分离的应用也未尝不可。这种独立性为今后企业更大范围的流程整合提供了一个基本前提。反过来说，如果流程应用同CRM应用紧密相关，即发生“紧耦合”现象，那么，这种流程应用将有很大的局限性，只有在企业应用中分离出独立的流程逻辑层才可以实现全方位的独立于平台和应用的流程整合目的。