LOVE模型是流程建模最常见的方法之一，但其表达业务逻辑尚不够严谨，结合资深多年从事流程管理、设计流程的感受，认为EPC是业务流程表达的最好方式之一，主要在于其业务逻辑表达清晰，当然，在不做简化的情况下也可能存在流程图篇幅过长的问题。

一、EPC建模和传统LOVEM建模的区别

EPC全程是event driven process chart的简称，含义为事件驱动的流程图。

顾名思义，流程图中强调事件，在建模过程中，EPC流程以事件开始、事件结尾，同时在流程中的每个活动节点均已事件开始、事件结束--这就是EPC和传统LOVEM流程建模最大的差别，通过对每个活动节点触发事件和结束事件的描述，使业务逻辑更清晰的展现。

当然，每个活动节点都表现出事件，显然会拉长流程模型，这就需要企业在选用EPC模型的时候，决定如何对事件进行简化。笔者此前在迈瑞医疗工作时，公司采用的EPC画法，简化策略是普通流程活动略去事件，在关键节点保留事件，如判断类活动后面可能对应不同分支的时候，需要保留事件、首位事件保留。

另外，EPC区与LOVEM建模方法的另一显著区别是引入逻辑符号：逻辑与、逻辑异或、逻辑或，这些符号的引入，为有效的提升模型的表达能力带来了便利，当然对初学者而言，也显然引进了复杂度，需要假以时日才能准确掌握。笔者在初学时也非常困惑，但习惯之后，不用逻辑符号就觉得逻辑不清。

二、EPC支持泳道图和瀑布图

泳道图大家都清楚，横纵向用到均可。

瀑布图，简而言之就是不要泳道直接展现流程活动、角色、输入输出的模式。

如何选择，没有好坏之分，主要在于企业适应哪种表达方式。

三、EPC模型建模规范：

四、建模总体原则：

1、如瀑布式，则遵循自上而下布局方式，鉴于图形可能较长，一般在系统工具中展现时采用，如ARIS

2、如泳道式，仍然遵循自上而下、自左向右的指导原则：

五、建模过程中遵循的一些规范要求：

EPC的特点为对事件的描述来更为清晰的展现业务，因此在EPC流程模型中，一定以事件开始、事件结束，过程中的非关键事件额可以省去，这是采用EPC建模必须遵循的原则。以下几种模式是正确的示例：

六、EPC逻辑符号用法补充：

1、逻辑与的常见使用方法：

1）一个事件同时触发多个活动：

2）多个事件完成后，才能触发下一步活动：

2、逻辑或的常见使用方法：

1）一个活动可能产生不同的事件（结果），当然，这本来就代表不确定性，在追求严谨的业务设计中，不是一种好的方式：

2）一种或多种事件触发相应的活动，如客户投诉，不管是收到邮件、还是接到电话，还是电话邮件均收到，都会触发后续的客诉流程。

3）错误展示：一个事件后不能使用逻辑或符号：

3、其他：

1）逻辑与在有分支的情况下，一般成对使用（并不绝对，如另一分支END的情况下）：

2）逻辑异或在有分支的情况下，一般成对使用（并不绝对，如另一分支END的情况下）：

3）逻辑符号不能多进多出：

错误的范例：

正确的范例：

备注：

1、上述概要介绍仅是流程建模中的最基本知识，但一条高质量的流程，不可能是脱离业务的，因此首先需要想清楚业务如何多快好省的开展，其次才是通过流程图固化好的业务开展方式；

2、流程建模，是为了承载业务设计方式，因此好的流程图不但要承载好的业务运作方式，还要简单易读，这就包括图面的整洁合理、连线不纵横交错、图标摆放合理等，因此在掌握流程图绘制基本知识的基础上，更需要流程设计人员要用心去思考如何设计出更高质量的流程图，这是考验功底的，初学者和资深人员的差别，往往也能在这种细微处体现出来。