什么是EPC
EPC是一种过程建模方法，全称是Event-driven Process Chain。在九十年代初期才由Keller等人提出。对于EPC，国内开发人员是陌生的，可能很多人听说EPC【01】，也仅仅是在ARIS（Architecture of Integrated Information System）系统框架中接触过一些。EPC可能很多人是陌生的，但SAP r3可能很多人或多或少听过，SAP R3就是基于EPC过程建模的。
前段时间，公司接了一个物流的项目，其中有一个子系统是要做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的图例绘制业务流程图，估计没有多大难度了。
让我们来看一个例子，可以加深对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是一个核心的元素：
在这几个过程建模方法中，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模型表示，如下：