随着网络信息化的发展，企业与企业之间的竞争越来越激烈。竞争的白热化迫切需要企业提高自身的服务质量，满足客户的个性化需求。因此就需要企业完整掌握客户信息，准确地把握客户的要求，快速地响应个性化需求，提供良好的服务，从而提高客户的满意度和忠诚度。在这样的前提下CRM系统应运而生。CRM在20世纪90年代兴起以来，迅速得到企业界和管理界的重视，成为企业寻求可持续发展的利器。无论是传统的国际化企业，还是新兴行业的公司，都纷纷在产品设计、生产流程、销售流程以及回馈环节中引人CRM计算机的管理和控制，使CRM成为企业的一项寻求创新和发展的商业策略。

CRM系统通过提取业务资料和成交资料，利用数据挖掘技术，分析客户要求，提供个性化的服务，而且为用户提供的所有资料都是实时且能更新的，以便给客户提供最贴心的服务。

CRM系统的构件从功能上分，主要包括：流程管理、接入管理、关系管理。其中CRM系统流程管理是其他两方面的基础。流程管理使销售、服务、支持和市场相关的流程自动化，也就是说，把分布在不同部门、不同区域已有的所有信息资源迅速整合，没有时间和空间的限制，最大限度地发挥企业内外部资源和技术。要实现CRM系统业务流程的自动化，对CRM系统的业务流程建模成为了关键。

目前对业务流程的建模主要有两种关键的技术：一种是基于Petril网的建模方法。它主要是运用图形化方式来描述工作流，同其它非形式化的框图技术相比，Petri网有规范而明确的语义和丰富的分析技术，从而避免了模糊性和矛盾性。但是，经典Petri网并不适合于直接描述业务过程，它在描述真实系统时往往过于复杂，工程较为庞大，不能很好地处理模糊信息，对特定环境约束下流程的描述能力也显得不够；另外一种常用方式是UML的建模方式：它是一种图形化建模语言。UML的语义用自然语言描述，表示法定义了UML的可视化标准表示符号。UML中的一些图可以用在企业建模、业务工程和过程分析上。UML提供标准的图形元素，具有较强的直观性，采用对象传递表示信息流可以通过消息机制来同步活动。但是总的来说，UML仍然是利用静态图的方式来表示工作流的动态过程，其对工作流过程中根据现有资源灵活决策、动态选择工作项无法表示并且缺乏逻辑的严密性。

因此，UML逻辑描述能力相对较弱，缺少精确语义，不支持模型的验证和优化。本文采用PI演算建模，是由PI演算的特点决定的。首先PI演算可以描述并发系统的结构演化，描述能力强，分析方法有较强的理论支持，可以用于描述复杂的系统；其次PI演算的推演可以用于模拟动态系统演化；再次，PI演算已有成熟的建模工具，便于对模型的验证；最后PI演算的推演是代数运算，易于编程处理。

本文源于Winograd和Flores的“语言行为模型”理论，首先采用形式化方法PI演算从客户方和服务方之间的语言行为交互上对工作流进行建模，突出了工作流模型中的客户与执行者之间语言行为交互和承诺，从而在一定程度上克服了传统的工作流模型的不足；另一方面，对系统进行动态建模并解决了数据实时更新问题及数据传输中发生的冲突等问题；最后对模型进行验证，确保模型的正确性。

1 PI演算

PI演算(π-Calculus)是图灵奖获得者RobinMilner，在CCS(Calculus of Communication System)后提出来的。用于描述具有动态结构的进程内和进程间通信的并发的计算模型，也可被用于描述动态变化的系统。在PI演算中，进程是并发运行的实体单位，并以名字来统一定义通道以及通道中传送的消息。

PI演算把通道、变量和数值都看成名字，这将会有两种基本实体：名字(用a,b,...,z等表示)和代理(由P,Q,...等表示可观察的动作)。

PI演算的语法具体定义为：

设N为无限名字集，用u,v,w,x,y,z等小写字母表示名字集上的名字；进程标识符用A,B,C等大写字母表示；进程表达式用P,Q,R等大写字母表示，进程表达式为以下七种：

 

2 CRM系统的实例

图1为CRM订单系统的主要的业务流程图。该图主要有四部分组成：客户代理、客服系统、产品供应部门和银行。其中客户代理是在质量部门和技术部门的支持下进行交易的；客服系统是从产品供应部门获取信息，为客户提供个性化服务；产品供应部门主要负责生产的调度以及产品的运输管理；银行作为交易的第三方保证交易的顺利完成。以下本文将以该系统为例，来讨论如何应用PI演算对CRM系统业务流程进行建模。

 

图1 CRM订单系统的主要的业务流程图

2.1 主要业务流程的描述

订单系统首先接收到客户代理的请求，根据客户代理提供的产品信息及客户代理的个人信息，客服系统来确定是否接受客户订单；当客服系统确定接受客户的订单以后，再向银行发出付款请求；若银行确认客户代理已付款，则向客服系统发送客户付款信息；确认客户付款后，客服系统再向产品供应部门发出生产请求；最后产品供应部门向客户代理发送货物运输信息，客户代理接收信息并确认产品已到货。在各个代理通信的过程中，客服接受订单后，客户代理需要实时了解订单的状态。因此在客服系统和客户代理，以及产品供应部门问至少需要两个通道。

其中业务流程之间交互消息表示如下：

Request客户向订单系统提出企业订单的申请。

Asklnfo客服系统根据企业要求，向客户提出提交客户的相关信息。

Moreinfo客户根据企业要求提交订单的详细信息及相关信息。如公司名称、经营信息、法人代表、公司地址、订货的详细信息等。

Refusal/Accept客服系统通过查询并分析业务数据和成交资料，进行客户需求分析，对于诚信度高、信誉好的客户及潜在的客户提供个性化服务；反之，则拒绝订单。

Comfirmation客服系统向客户发出确认信息，生成正式订单。

RequirePay客服系统向银行提出要求客户付款。(假定银行作为支付第三方，在企业产生正式订单后，向客户提出付款请求，待客户验收货物后，银行再将货款打入企业帐号)。

PaySucc银行通知客服系统，客户已付款。

InformPay银行向客户发出付款请求。

PaymentFee客户代理付款并确认。

RequirePro客服系统向产品供应部门发出生产请求，即发出满足客户个性化要求的生产请求。如有关商品信息的名称、生产规格等，及时满足客户的个性化需求。

AceeptPro产品供应部门接受请求，并向客服系统提供有关商品生产的状况。

Replylnfor产品供应部门发送产品货物运输信息。如：货物的运输工具、到货日期等等。

ComSucc客户收到信息，并确认产品已收到，即货物通过质量部门和技术部门的检测，交易成功。

PI演算既是一种基于名字概念的并发计算模型，又是一种相互通信时内部链接改变过程的数学模型。因此，可以用于描述CRM系统的业务流程。本文把CRM系统业务流程之间的逻辑关系映射在了PI演算上。我们需要解决的问题有：

(1)如何划分系统中的代理；

(2)如何保证部门间消息或数据的实时更新，即如何保证数据传送的实时性并与其它类型的消息或数据传递不发生冲突；

(3)如何保证多任务共用一个通道时不能发生数据冲突而产生错误的数据。

为了解决以上问题，本文对以下的概念进行定义：

定义1 CRM系统中的agent CRM系统中逻辑上单独存在的部门作为一个代理或进程．也就是说可以把企业的每个主干部门作为一个代理或进程。当需要对一个复杂的单一的部门进行流程分析，也可将其分割为几个相对独立的代理或进程。

如图1我们可以把客服系统和银行看作一个代理或进程。在下一小节，我们再将复杂的产品供应部门分割为几个相对独立的进程或代理。

定义2 消息在两个代理间传递时，存在着“承前启后”的关系。也就是说，在系统接收该消息前，不能完成系统业务流程的其他操作。可以用PI演算的前缀操作表示，形式化描述为：

P₁=a.P₂

定义3 消息在代理间传递时，业务流程也存在着“与”的关系。也就是说，代理(进程)问的业务流程可以并发执行。可以用PI演算的并行合成操作“｜”表示，形式化描述为：

P₁=P₂｜P₃

定义4 消息在代理间传递时，业务流程也存在着“或”的关系。它可以用PI演算的选择操作“+”表示，形式化描述为：

P_l=P₂+P₃

定义5 消息在两个代理问传递时，存在着“匹配”的关系。代理(进程)P1通过端口号x对接收消息msg进行判断，来决定下一步的操作。使用PI演算的选择操作“+”和匹配操作“[]”表示，形式化描述为：

P₁=x(msg)([msg=a]P₂+[msg=b]P₂)

定义6 通信的两个代理间至少存在一条通道，然而当传递不同类型的数据或消息时。需要开辟多个通道，来保证数据传输的正确性。如本文中应用多个通道来解决数据的实时更新问题。因为本文重点讨论如何建模和模型的验证，所以我们对CRM订单系统适当作了一些简化，省略了部分细节问题。其逻辑结构如图2所示。

 

2 CRM系统的业务流程示意图

每个步骤都可用一个或多个PI演算进程进行形式化描述，为此我们需要首先确定消息传输通道。其中，X为客户与客服系统之间的通道，Y为客服系统与银行之间的通道，Z为客户代理与银行之间的通道，W为客服系统与产品供应部门之间的通道，L为客户代理与产品供应部门之间的通道。CRM系统要求客户代理能够实时了解客户订单的状态，也就是客户所需产品的生产状况．所以我们在客户代理与客服系统之间增加一个通道M以及在客服系统与产品供应部门之间增加一个通道W，来传送产品的生产信息。我们使用S表示需要实时的数据信息。(为了清楚地表示沿通道发出的消息，发出的消息均增加了尖括号<>)

 

图3 CRM系统简化的业务流程

首先，与客户代理相关的通道及交互参数表示为：

整个订单系统的业务流程就是由客服系统，产品供应部门，银行和客户代理之间交互完成的。对于订单系统来说，{w,y,n}是其内部私有通道，所以为约束名字。即整个业务流程定义为：(w,n)(Client(c)｜CRM(a)｜Produee(d)｜Bank(b))。

2.2 复杂部门内部的业务流程描述

在定义1中提到当需要对一个复杂的单一的部门进行流程分析时，也可将其分割为几个相对独立的代理，以供应部门为例，可以将其分割为生产部门、销售部门、仓库部门和财务部门。图4中销售系统负责与客服系统交互制定生产计划；仓库部门负责与客户代理交互来管理产品的运输情况；财务部门与银行部门的交互以便确认客户代理的产品的支付情况。其中r,s,z,d,t是产品加工部门内部的私有通道。四个部门中有三个部门的通道与外部链接，分别为X,Y,L。

 

与整个订单系统的业务流程相类似，可以建立产品加工部门内部的业务流程。

通过本例可以看出，应用PI演算可以描述CRM系统中比较复杂的业务流程，从而实现对系统的业务建模。

3 CRM系统的模型检测

利用形式化工具的目标就是为了系统业务流程的建模和保证模型的正确性。在抽象设计阶段，利用PI演算可以清晰地描述CRM系统业务流程的交互行为；而在模型建立以后．则可利用PI演算来推演系统的行为，同时验证模型的正确性。

PI演算作为一种强大而成熟的形式化方法，有许多支持自动模型检查和验证的工具。例如：JACK工具集，基于PI演算的语言PICT，可执行的PI演算EPI以及传值进程代数工具VPAM等。本文采用的验证工具是移动工作台MWB(Mobility Work-bench)。它是针对PI演算开发的一个自动验证工具，可对用PI演算、通信系统演算CCS描述的移动并发系统进行分析与验证。MWB是在瑞典的Uppsala大学计算机系开发出来的MWB使用标准ML语言设计，可在Windows、Linux等系统下的New Jersey SML编译环境里运行。

在对CRM系统业务模型验证时，我们首先要把PI演算公式转化为MWB编码，然后利用MWB进行具体的验证。在利用MWB验证时，我们首先可以对模型进行语法检查，以排除不正确的PI演算表达式，然后可以利用deadlocks检测模型是否存在死锁，最后用step命令模拟跟踪服务的交互行为。

3.1 PI-演算公式的MWB编码

为将PI-演算公式输入MWB，需将通常的PI-演算公式做一些转换；

A称为P的名，注意P的名可用任意的符号串(例如My-ID)，但第一个字母需大写且(...)里一定要将P的非受限名字完全列举。然后将几个MWB公式放到一块，以ag为扩展名用ASCII文件存盘。

根据以上的规范将部分PI演算描述转化为MWB语法形式。如：对CRM系统中的客户代理和客服系统之间的交互行为进行转化。其中，我们设agent A(x,m,a,b,c,d,e,f,g)为客户代理；agent B (x,m,a,b,c,d,e,f,g)为客服系统；x和m为客户与客服系统之间的通道。其中a为Req,b为Ask,c为Minfo,d为Ref,e为Acc,f为Comf,

3.2 利用MWB的验证

(1)载入文件 使用input“P.ag”将上述agent P载入进行分析检验是否存在语法错误；

(2)死锁检验 用命令deadlocks检验各agent是否有死锁。结果如下：

MWB>deadlocks P

No deadlocks found．

可见，结果在P中没有发现死锁；

(3)交互模拟跟踪检验使用step命令模拟跟踪服务的交互行为，分别键入0,l,2观察系统的演变，结果如图5所示。

图5 CRM系统的部分验证结果

由图5可知在应用PI演算对CRM系统业务流程建模的模型中，MWB首先检测出流程可能出现0、l、2三个转移，并且系统为了更好地描述转移的消息的状态，在参数后随机产生脚码。0转移：转移的产生是在完成tao动作的情况下，也就是说在代理A和B发送完除消息a以外的所有的消息后开始转移的；1转移：代理A和B发送完所有的消息产生的转移；2转移：代理A和B也是在发送完所有的消息后产生的，并且代理B发送参数v代替参数a。最后在step命令后分别键入0、l、2，观察系统系统的模拟检测结果可知：如图5所示在键人step0后，存在三种转移；同理键入1后，存在2种转移；最后键入2后可step2重复着stepl的转移。由此，我们可以得到在CRM系统模型中共存在6转移，也就是说模型中存在六种分支流程。从而我们可以更进一步地模拟、分析、检测每一步交互，对流程中可能存在的错误进行修改，保证模型的正确性。

4 结论

业务流程建模问题一直是学术界关注的热点问题。本文提出采用形式化方法PI演算对CRM系统业务流程建模，突出了工作流模型中的客户与执行者之间语言行为交互和承诺；并且通过一个实例，应用PI演算精密而抽象地描述业务流程的全过程，解决了CRM系统中数据冲突问题，定义相应的规则；最后对所建模型进行了完整的验证、分析、检测、跟踪系统流程交互的每一步，保证了模型的正确性。这样，大大地降低了企业实际开发软件的风险，节约了成本。在下一步的工作中，一方面我们将考虑建模过程中资源、角色以及时间的问题，对系统的流程进行全面的仿真模拟；另一方面将进一步运用PI演算的互模拟等价、弱互模拟、强互模拟及观察等价等定理进行业务流程的优化。