01—起源与发展

EPC（Event-driven Process Chain事件驱动的流程链）：是 20 世纪 80 年代末 90 年代初由德国的 Scheer 教授作为 ARIS 方法论的一部分提出的，在业务流程建模领域极具影响力，是西门子、大众汽车、可口可乐、汉莎航空、中石油等大量国内外企业采用的流程建模标准。从上世纪90 年代起，EPC成为 SAP 系统实施时业务流程建模事实上的标准。

BPMN（Business Process Model and Notation 业务流程模型和符号）：BPMN 源于可以由流程引擎执行的流程描述领域，最初由业务流程管理倡议组织（BPMI, Business Process Management Initiative）开发，目前由对象管理组织（OMG）维护管理，2011 年推出的 BPMN 2.0被很多企业和厂商接受。

当前，EPC 和 BPMN 是全世界两套最为主流的流程建模标准，大量流程建模工具软件 (BPA) 和流程执行系统软件 (BPMS) 都支持这两套标准。

EBPM 方法论建议企业直接采用这两套标准作为流程建模的规范，不要自己另起炉灶设计一套。否则，后续开展数字化流程建设时会面临很多问题，尤其是额外的接口开发。自定义流程建模的符号和标准，就好比建设高铁网络时既没有用 1435毫米的“准轨”标准，也没有用1067毫米的“窄轨”标准。虽然不能说采用自定义轨距标准建设的高铁网络一定跑不起来或跑起来一定有问题，但与其他高铁网络接轨时一定会很麻烦。

博阳精讯公司基于 EBPM 方法论研发的 EBPM 流程管理平台软件，既支持 EPC 标准，也支持 BPMN 标准。而且，在 EBPM 平台中这两套标准是可以自动切换的。

上图所示，是在 EBPM 流程管理平台软件中用 EPC 标准绘制的博阳家居《销售合同评审流程》的泳道图。

上图所示，是在 EBPM 流程管理平台软件中切换成 BPMN 标准的博阳家居《销售合同评审流程》的泳道图。

02—EPC 更适合业务人员，BPMN 更适合IT人员

企业内部通常有两类人员在构建业务流程模型。

第一类是业务管理人员，比如流程管理人员、销售管理人员、生产管理人员等。这类人员主要是站在业务运行和管理的角度来描述和构建流程模型，业内通常将这类模型称为“业务级流程模型”。

第二类是开发或配置流程执行系统的IT 工程师，这类人员主要是站在流程引擎可执行角度来描述和构建流程模型，业内通常将这类模型称为“技术级流程模型”。

可以这么说，EPC 流程图更适合 “业务管理人员” 画给 “业务执行人员” 看；BPMN 流程图更适合 “IT 工程师” 画给 “流程引擎” 看。事实上，这本来就是两套标准设计者的初衷。

EPC 标准的诉求是采用尽可能少的专业图符来构建流程图，更多的业务规则和逻辑通过功能分配图或者文本特性来补充说明。也可以这么说，EPC 标准追求的目标是在管理人员和执行人员能看懂的前提下，采用最少的专业图符。

BPMN 标准则倾尽全力通过大量不同的专业图符在图面上完整描述所有流程规则和逻辑。原因也很简单，BPMN希望流程执行引擎能看懂，从而能执行。相较于文本特性，流程引擎更易读取流程图模型中的要素图符。另外，还有一点也必须指出，BPMN 标准还会描述一些业务管理人员并不关注的流程执行时的IT技术规则。

说了这么多，相信读者们还是觉得有点 “抽象”。接下来，我们就来论证一下上述观点。

上图所示是 EPC 标准和BPMN 标准中最基本的要素图符类型，也可以称为核心图符。单独比较这六类基本要素图符，可以发现两者之间有以下三个主要区别：

1）BPMN 没有“角色”图符，而是采用“泳道”来描述不同的“角色”。（注：BPMN 中有“参与者”这一要素，但与大家通常理解的流程角色不太一样，一般也不会在流程图中直接用来描述角色。）

2）BPMN 中没有“流程接口”图符。

3）BPMN 标准对于图符的类型分得更为细致，也更复杂。

本文我们先着重说明一下第3点不同，即相较于 EPC标准，BPMN 标准的图符更为丰富，也更为复杂。

以“事件”为例，如上图所示，虽然 EPC 标准的名称中就有“事件 Event”这个词，但是 EPC 标准也就用一个图符来代表 “事件”。但是，BPMN 标准却细分为三个图符，分别代表开始、中间和结束事件。

在上图所示的流程图中，左侧是用 EPC 标准绘制的流程图。EPC 认为不管是绘图者还是读图者，一看图就知道<事件一>是开始事件；<事件四>、<事件五>是结束事件；<事件二>、<事件三>是中间事件，根本不需再特别用不同类型的事件图符来说明这一点。EPC 标准之所以这么认为，那是因为其假设的主要读者是“人”，是业务管理人员和业务执行人员。

但是，右侧用 BPMN 标准绘制的流程图，则明确要求采用不同类型的图符来表示开始、中间和结束事件。对一看就明白的事，BPMN 标准为什么非要用不同的图符再描述一下呢？那是因为其假设的主要读者是“IT 系统”，是“流程引擎”。

还是那句话，EPC 流程图是“流程管理者”画给“流程执行者”看的， 是“人”画给“人”看的。对于人来说，一看就知道这些事件是开始、结束还是中间事件，无需赘述。而 BPMN 是“IT 工程师” 画给 “流程执行引擎” 看的，是“人”画给 “IT 系统”看的。对于“流程执行引擎”来说，事先定义好逻辑的图符相较于文本描述，解析起来要容易得多了。在实现业务流程信息化的过程中，系统可以将不同类型的图符自动转化为可执行的软件代码或者完成流程引擎的配置。例如，通过识别流程中的任务、事件和流程逻辑图符，使用相应的技术框架和工具可以实现自动化的流程调度、任务分配和数据处理等功能。

在上图所示的流程中，如果错将“中间事件”图符用成“结束事件”图符，流程引擎驱动流程运行到“事件三”时，就会自动终止本次流程实例，不会再运行到下一个流程环节了。

事实上，为了更为精准地描述流程运行逻辑，仅针对“事件”这个要素，BPMN 标准还提供了如下扩展图符。

没错，这些图符全都是用来描述“事件”这一个要素的。是不是一看头都大了？试想，要业务管理人员全面学习和掌握这些图符的含义，并且准确地使用，这门槛有点高啊。更为重要的是，业务管理人员有必要学习和掌握这么专业的知识吗？

举个例子。上图所示的“开始事件”是时间触发型的，EPC 标准只要求在事件中用文字注明时间规则，比如“每周一”。做到这个细度，不管是绘图者和读图者，都能完整明白其含义，不会有偏差；而 BPMN 不但要求注明事件规则“每周一”，还要求采用正确的内部带有时钟样式的扩展事件图符。BPMN 为什么要这么复杂呢？因为，在流程信息化落地时，这个图符表明需要调用时间规则触发的IT应用服务或者解析并完成时间规则的系统配置。总之，那是为IT系统的开发或配置服务的。让IT系统来读文字是比较困难的，而识别和解析定义好逻辑的图符就容易多了。

以上仅是以“事件”这个图符为例，说明BPMN标准有非常多扩展要素图符，也有很多更为复杂和细致的建模规范。事实上，不仅是“事件”，针对其他要素BPMN标准也有类似情况。

上图所示是一个较为复杂的BPMN流程图的示例，来自于 2011 年1月OMG 组织发布的 BPMN 2.0 标准。这样的流程图，在实践中确实更适合专业的IT工程师来绘制，而不是让类似人事经理、采购经理或者销售总监这样来自于业务管理领域的流程主人们来绘制。

03—企业中两套流程模型导致的“两张皮”问题

如果企业内的业务管理人员用EPC 标准构建流程模型；IT工程师用BPMN 标准构建流程模型。那么，企业内部岂不是会有“两套”流程模型吗？

还真就是这样的！针对同一条流程，很多企业内部还真有两套模型。一套是业务管理人员构建的；一套是流程信息化过程中由 IT 工程师构建的。

上图所示，是本人担任IDS Scheer 中国区副总裁期间，我的德国同事们经常给企业客户们展示的一张 PPT。

在很多企业中，流程信息化的过程是首先由业务管理人员构建“业务级流程模型”，然后将此模型交给 IT 工程师进行信息化落地，业务管理人员通常会采用 EPC 标准。

IT 工程师由于需要构建“信息化流程引擎”能读懂的模型，会采BPMN模型将这套模型再绘制一次，同时补充描述更多技术细节，从而完成“技术级流程模型”的构建。

最后，“信息化流程引擎”通过读取IT工程师构建的“技术级流程模型”来驱动流程执行系统的运行，从而完成业务流程的信息化落地。

上述过程中，由于“技术级流程模型”是由 IT 工程师们照着“业务级流程模型”人工构建的，这就存在由于人为错误导致两者不一致的可能。

可以这么认为，“业务级流程模型”是流程的蓝图设计；“技术级流程模型”是流程在信息化系统中的技术实现。蓝图与实际系统不一致，这是过去几十年来所有信息化系统建设过程中普遍存在的问题，可以认为是一个“顽疾”，我的德国同事们称之为“BPM GAP”，业内俗称为“两张皮”的问题。

其实，造成“两张皮”现象的主要原因，倒还不是“人为错误”。更为主要的原因是蓝图设计也就是“业务级流程模型”本身就有问题，在系统落地时发现需要修改。而修改流程设计时，往往就直接修改“技术级流程模型”了，不再同步修改“业务级流程模型”，最后这两者就不一致了。这是造成“BPM GAP”或者说“两张皮”现象更为主要原因。

那么，如何解决这一问题呢？下一篇文章将同大家深入探讨一下“BPM GAP”或者说“两张皮”的解决之道。

04—EPC 标准和 BPMN 标准的对比表

最后，附上一张 EPC 和 BPMN 标准的对比表，供各位读者参考。