过程建模EPC,我拿什么拯救你
2007-08-23 15:46
        EPC是一种过程建模方法,全称是Event-driven Process Chain。在九十年代初期才由Keller等人提出。对于EPC,国内开发人员是陌生的,可能很多人听说EPC【01】,也仅仅是在ARIS(Architecture of Integrated Information System)系统框架中接触过一些。EPC可能很多人是陌生的,但SAP R3可能很多人或多或少听过,SAP R3就是基于EPC过程建模的。
       我也仅仅只是在2004年中的时候才接触过EPC这个概念的,那时候还在思维加速公司(现在叫起步公司了)研发Biz5.0系统,为了在Process Model这一层寻找一套方法论的支持,查阅了大量的建模方法资料,其中就包括EPC。
       但那时候接触的业务场景和业务范围很局限,虽然对EPC很认同,却不敢轻易的深入和采用,加上当时受Alast的YAWL的影响,所以更加痴迷于PetriNet。——很遗憾的是,那个时候没有看出EPC与PN之间是有很大关联性的,这是后话。
        2004年底进入USE(用友软件工程),接手了工作流引擎的开发。虽然那时候很想按照自己的思路采用PN或EPC的模型来开发,但当时在我之前的开发人员已经花费了大量时间在XPDL模型语言上,并做出了一款可运行的Deme和设计器,对我来说,当时的首要任务是重构出一款实际可用的引擎,而不是重新开发一个工作流系统。
       不得已,我只能采用XPDL流程模型,也只能选择重构,这在我去年写的《工作流引擎核心调度算法与PetriNet》【03】已经稍稍提及了。虽然模型这个层面让我很被动,但是由于至少还可以把握引擎结构和调度算法这一层,或多或少弥补了很多。
       其实,那个时候即使允许采用PN或EPC,心里其实也是没有多少底的。毕竟早先我很多的研究基础也是基于WfMC的参考模型和XPDL描述语言的。两年之后再回过头来看看,心中已经很清晰了,至少那几个过程模型的思想已经很有把握了。
       说道这儿,顺带说两个方面的个人观点,这两个方面与主题没有直接关系,但是有间接关系。以后我会写专门的文档来阐述我的这两个观点,此处我就不多加解释了,“仁者见仁,智者见智”,有心者自己把握吧。
       第一:我不是很喜欢XPDL流程描述模型,但目前国内绝大多数的厂商采用的是XPDL描述模型及扩展,这没有任何不妥。目前国内的流程应用范围主要还集中在类似OA审批流之类的应用上,这一层面的应用XPDL的模型所描述的语义基本可以满足大家的理解和应用了。再加之绝大多数的客户更偏重于“离散型活动关系”,这就让建模的约束又浅了一层。
       第二:在引擎构建上,需要把握关键的三点:过程模型建模、引擎调度算法和状态变迁、实例之间的对象关系。把握了这三点,则基本能够奠定一个引擎的主线结构。这好比是写文章的“主线”。当然,一篇好的文章,光有一个好的主线逻辑和构思是不够的,但主线是核心,写工作流引擎,也类似。
       
       自从2005年初写出那款引擎之后,就很长时间没有想去写一个引擎的冲动了。这似乎是开发人员的一种诟病,如果感觉现在所做的研发或者开发,不能让自己超越现在的自己,则会丧失很大兴趣,甚至放弃。我当时就是那种状态。
       我没有再去做工作流研发,但是却没有放弃对工作流的研究。从2005年中开始,我自己利用业余时间在默默地研究,也利用给别人培训和讲课的机会,对相关知识进行巩固和升华。这一年多来,收获是不小的,但是却没有再公开什么文章,是比较沉寂的一年。
  
       前面废话说了一堆,现在正式转入正题。
       前段时间,公司接了一个物流的项目,其中有一个子系统是要做WMS(仓储管理系统),主要是处理物品入库、出库、库存的流程管理。我看这个WMS子系统的需求之后,对其内部所需要处理的流程、单据状态等业务场景,脑海中第一个念头就是应该采用EPC用于建模抽象。可惜这只是脑海中的一个念头而以,现实中,是不可能这么去实施这个项目的。(这是令人痛心的,不过国内很多项目的实施,是很应付性的,也很难听取开发人员的意见)。
回到家后,又把之前所搜刮到的有关EPC的资料翻了翻。其中有两篇文档在这里提一提:
       第一篇就是《SAP R/3 Business Blueprint:Understanding Enterprise Supply Chain Management》【02】,这本书有一章节专门讲了EPC建模的要素,并且在后续章节中,用了大量的图例诠释了如何用EPC流程构建业务流程。
       书中主要点了EPC的四个主要要素:事件(Event)、功能(Function)、组织单元(Orgnization Unit)、信息(Data)(事实上,OU和Data这两个要素是ARIS系统框架中的)。由于本书的宗旨主要在于业务诠释,所以对于这几个要素讲解的不够概念化、形式化。但读完后,用EPC的图例绘制业务流程图,估计没有多大难度了。
  
元素
图例
描述
Event
描述了状态的发生,同时又充当了一个触发器
Function
功能描述了一个任务的执行,代表了一个start event和end event转换过程
Orgnization Unit
Data
Process Path
流程之间的连接关系
Logical Connectors
逻辑连符号:AND,OR,XOR

  
让我们来看一个例子,可以加深对EPC所构建的流程模型的理解:下图显示的是一个货物接收处理的流程。

  
       第二篇就是Alast大师写的《Formalization and Verification of Event-driven Process Chains》【04】。Alast是位Petri Net领域的专家,这篇文档也依然没有脱离PN角度。
       这篇文档从“过程”角度给出了EPC的几个元素解释:
元素
描述
Functions
A function corresponds to an activity (task, process step) which needs to be executed.
Events
Events describe the situation before and/or after a function is executed. Functions are linked by events. An event may correspond to the postcondition of one function and act as a precondition of another function.
Logical connectors
Connectors can be used to connect activities and events. This way the flow of control is specified. There are three types of connectors: AND, XOR (exclusive or) and OR
       
        Alast这篇文章另外一个重要内容,就是做了EPC到PetriNet的映射,但不涉及到对OR逻辑连接符的映射,因为OR的语义有多种诠释,不是非常清晰明确,这在Alast的这篇文档中也已经说明。
        EPC的Event可以映射为PN中的库所(Place),而Function可以映射为PN中的变迁(Transition)。而至于逻辑连接符AND和XOR的映射在采用Place的控制,很容易表示:
           

           

   
国内EPC应用的匮乏
       看到这儿,估计大家对EPC过程模型能够有个基本的认识。因为本篇不是讲解EPC的,而只是想说明:EPC在业务建模方面为我们提供了很好的参考,但是国内当前基于EPC模型的流程产品或业务产品几乎没有。在网络上搜索中文EPC的资料,仅有寥寥几篇,而且主要还都是因为讲解ARIS框架而顺带提及的。
       到不是说EPC是一剂万能的良药,事实上EPC也仅是过程建模的一种。几个过程建模诸如PetriNet、EPC、Activity Diagram、FSM等,如果可能的话,XPDL的定义元模型也算一种。
       但是国内这几年的工作流相关的产品和应用发展,受WfMC的XPDL影响很深。
一方面是因为国内自身的理论研究过于薄弱和苍白,可能有些研究人员会注意到上述的那些过程建模方法,但是由于这些过程建模方法并没有形成完整的形式化描述语言支持(事实上,是有一些的,比如基于PN的PNML,基于EPC的EPML等,但是这些xml的描述语言过于理论化,不像XPDL那样偏应用),所以很难直接被一些开发厂商了解。
而另一方面,这几年国内工作流应用的主要领域依然是OA及相关审批流程。在这样一个“偏重用户自主行为控制”的流程应用领域,XPDL所阐述的流程元模型对象:Process、Activity、Transition、Participant已经基本可以描述一个完整的流程。在可以完整描述完一个流程之后,大部分厂商都把重点放在了:(1)通过扩展属性来丰富流程定义;(2)通过完善引擎的功能支持一些用户行为化的操作,诸如退回、自由流等。
       但很少有厂商真正的反思一下,XPDL的过程建模就一定完善吗?合适吗?。对于XPDL来说,有个最大的缺陷就是缺少对State和Event的描述(在XPDL2.0中已经部分的纳入Event概念了)。
       而对于其他过程建模PetriNet、EPC、Activity Diagram、FSM这几个来说,State是一个核心的元素:
过程建模方法
基本模型元素
表示State的对象
PetriNet
Place,Transition
Place
EPC
Event,Function,Connectors
Event
Activity Diagram
State,Decision
State
FSM
State,Action
State
XPDL Metedata
Activity,Transition
       
       在这几个过程建模方法中,EPC是最偏重于商业业务化流程的。但是却是国内应用却是空白的。
       据我所知道的,目前国内已经有两三家厂商已经采用PetriNet作为流程描述模型;OSWorkflow和jBpm这两款开源引擎的应用,也已经让部分厂商在不知不觉中采用了FSM和Activity Diagram模型。唯独EPC没有应用(当然那些采用SAP R3的除外)。
       我记得在2001年,我还在有生博大公司研发RiseOffice5.0公文流程系统,那时候采用的是Task和Action对象,有些类似FSM的State和Action。不过现在有生博大新版的RiseOffice工作流系统,已经采用XPDL模型了。—— 其实这也是国内很多厂商的一个开发趋势:虽然不了解“过程建模”,但是知道XPDL可以描述流程。
事实上,EPC所抽象的模型,很适合诸如B2B、供应链流程管理、仓储物流管理等商业化业务流程。这样的业务流程有个很共同的特点,对于“活动处理的前后状态”很在意。一旦把握了状态,则可以依据状态来丰富业务对象的生命周期控制和业务规则控制,这两点在业务系统中是比较重视的。
相比较而言,XPDL的元模型则仅仅只描述了“活动与活动之间的连接关系”,则很难在模型角度就看清楚活动之间所影响的状态及变更关系。
但很少有开发商或者开发人员去反思这个问题:活动与状态。XPDL虽然屏蔽了“状态”这个理念,但是由于其是目前最为“完善的XML描述化流程语言”(当然,这里我们不去谈论BPEL、BPML之类的规范),对于开发商来说,只需要考虑遵循规范和扩展,则可以基本清晰的描述一个“流程”,虽然不能够表达流程各个区段的状态问题,但是却可以清楚地展现“活动之间的关系”。
更况,国内的流程发展,这几年主要依赖于办公自动化和审批流,加上国内应用偏重于“离散活动点的组合关系”,也就是说,在很多客户眼力:流程就是一个个离散的任务,这些任务在不同情况下可以很随意的组合。而这样的需求,是XPDL所依赖于的Activity和Transition所基本可以描述的。
加之WfMC毕竟是一个有着十多年的国际化标准组织,对客户,对开发商来说,这样的组织和标准,都是比较容易接受的。
而EPC,PetriNet,FSM,Activity Diagram则显得很脆弱,没有国际化的组织支撑,没有完善的描述语言支撑。最令人叹息的就是,在XPDL的描述模型中,几乎找不到任何这四个模型的影子,似乎WfMC在有意回避这几个建模思想。
国内的业务化建模流程,应该吸纳EPC这样建模方法,特别是在业务化系统中,比如B2B、供应链流程管理、仓储物流管理等商业化流程系统中。当然这样的代价是比较高的,需要基于这些模型元素和思想,自主摸索出一套完整描述语言。事实上,SAP R3的成功是很值得大家借鉴的

  
下面把仓储管理系统中的一个入库流程中的“入库订单处理”用EPC模型表示,如下:
       
  
01】G. Keller, M. Nüttgens, A.-W. Scheer. Semantische Prozessmodellierung auf
der Grundlage „Ereignisgesteuerte Prozessketten (EPK)“. Veröffentlichung
des Institut für Wirtschaftsinformatik, Paper 089, Saarbrücken, 1992
02】Thomas A. Curran, Andrew Ladd. SAP R/3 Business Blueprint:Understanding Enterprise Supply Chain Management,2003
03】胡长城,《工作流引擎核心调度算法与PetriNet》,2005年
04】W.M.P. van der Aalst, Formalization and Verification of Event-driven Process Chains