上一篇文章《EBPM 方法论对 EPC 和 BPMN 流程建模标准的理解 》中提到，针对同一条流程，很多企业内部有两套模型：一套是业务管理人员构建的，业内称之为“业务级流程模型”（后续简称为“业务级模型”）；一套是在流程信息化过程中由 IT 工程师构建的，业内称之为“技术级流程模型”（后续简称为“技术级模型”）。

01—业务与技术脱节的 “两张皮” 现象

如上图所示，很多企业的流程信息化过程是这样的：

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

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

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

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

由于“技术级模型”是IT 工程师基于“业务级模型”的二次建模，当“业务级模型”的设计存在问题或者需要优化时，IT工程师往往就直接在“技术级模型”中进行修改了，不会再同步修改“业务级模型”，最后这两者就不一致了。这是造成“两张皮”问题的主要原因所在。

02—消除 “两张皮” 的解决方案

如何解决业务与技术脱节的“两张皮”问题呢？经过业界多年的努力，随着数字化技术的进步，目前逐步形成了如上图所示的由“业务级流程模型”自动生成“技术级流程模型”的解决方案，业内称之为“模型至执行M2E”解决方案。

如上图所示，在 BPA 软件平台中完成蓝图设计的“业务级模型”将通过一个技术接口直接推送给 BPM 系统，也就是通常所说流程执行系统 (BPMS)，并在 BPM系统中自动生成“技术级模型”。严格意义上来说，是自动生成“技术级模型”的基础模型。

这一环节的关键点是，流程执行平台 BPMS 系统中的“技术级模型”的基础模型是通过接口自动生成的，与“业务级模型”是完全一致的。更为重要的是，这个基础模型中的流程整体框架（流程活动、事件、逻辑连接符、角色和连线）是锁住的，在 BPMS 系统中是不可以增、删的。

在BPMS 系统中自动生成的“技术级模型”通常会采用 BPMN 标准。为什么用 BPMN 标准呢？因为IT 工程师可以采用BPMN 标准中丰富和细腻的图符对基础模型的技术细节进行更为详细地描述和补充，以便让数字化流程引擎能读懂。

比如，IT 工程师会将上图所示的“技术级模型”中由时间触发的“事件”这个要素图符替换成 BPMN 中表示时间触发类事件的特定图符（中间有时钟样式的圆圈），同时配置相关的时间触发应用服务。这样，当基于“技术级模型”运行流程时，数字化流程引擎识别到这个图符时就会去调用配置好的应用服务，从而发起流程实例。

此时，上图所示的 BPMN 标准中大量丰富的图符和规范就有了用武之地，可以帮助IT 工程师将很多技术细节描述得更为精准，更易让数字化流程引擎识别和读懂。强调一下，上图所示的图符仅是 BPMN 标准中比较常用的部分而已，完整的 BPMN 标准有更多的图符和绘图规范。

另外，如上图所示，BPMN 模型通常以 XML 格式存储和交换。XML 具有良好的可读性、可扩展性和跨平台性，能够方便地在不同的系统和工具之间传递 BPMN 模型信息。而 XML Schema 则为 BPMN 的 XML 文件提供了结构定义和验证规则。通过 XML Schema，可以精确地规定 BPMN 模型中各种元素（如流程、活动、事件等）的名称、属性、嵌套关系和数据类型等，确保 BPMN 模型以一种标准化、规范化的方式进行表达。通俗地说，BPMN 标准中的各种图符可以通过XML的标准存储格式被各类IT系统解读。

所以，BPMN 标准更适合IT 工程师用来构建可以让流程引擎读懂的流程模型；而业务管理人员更适合采用 EPC 标准来绘制流程图模型。

有一点需要特别指出，市场上有众多提供 BPMS 流程执行系统软件的厂商，其流程引擎对于 BPMN 标准支持的全面程度各有不同。有的支持所有图符和规范；有的支持主要图符和规范，更多技术细节通过参数配置来描述，不采用图符进行表达。但不管怎样，这些厂商及其软件产品支持的通常都是 BPMN 标准。所以，EBPM 方法论强烈建议企业采用 EPC 或者 BPMN 标准来构建“业务级流程模型”，不要自行设计一套。而 EPC 和 BPMN 由于是被广泛应用的标准，两者间已经有现成的转换规则和逻辑，可以自动转换。

总结一下，上述解决方案的两个关键技术点是：

1）“技术级流程模型” 由 “业务级流程模型” 通过接口推送后自动生成，不再由 IT 工程师手工创建。

2）自动创建的 “技术级流程模型”，其流程基础框架（流程活动、事件、逻辑连接符、角色、连线）是不可以修改的，IT 工程师只能在此基础上进一步描述技术细节，配置或开发数据、界面和应用服务。

基于上述方案，如果流程的基础框架（活动、事件、逻辑符、角色、连线）需要修改和优化，必须先调整 “业务级模型” 然后再次推送给 BPMS 流程执行平台，生成新的 “技术级模型”，因为 IT 工程师不被允许直接修改 “技术级模型” 的基础框架。在 BPMS 流程执行平台中，这个基础框架是锁住的，是不可修改的。这样，从技术层面就确保了 “业务级模型” 和 “技术级模型” 的一致性，不再会出现两者不一致的 “两张皮” 现象。

而且，上述方案还消除了 IT 工程师照着 “业务级模型” 再手工创建一次 “技术级模型” 的冗余工作。

03—业务级模型可采用EPC或极简版BPMN

通过本文及上一篇文章《EBPM 方法论对 EPC 和 BPMN 流程建模标准的理解》的阐述，相信对于 “技术级流程模型” 应采用 BPMN 标准这一点应没有什么疑问了。而且，由于是 “技术级模型”，所以这套标准只要 IT 工程师们学习、掌握及运用即可，广大作为流程主人的业务管理人员可以不用过多关注这套标准。

然而，在实践中经常还会有这样的困惑：既然 “业务级模型” 推到技术平台后会自动生成符合 BPMN 标准的基础模型，那为什么 “业务级模型” 不直接采用 BPMN 标准来绘制呢？即业务管理人员也直接用BPMN标准绘制流程蓝图不行吗？是似乎又回到了问题的原点。

针对上述问题，EBPM 方法论的观点是：“业务级流程模型”既可以采用 EPC标准，也可以采用 BPMN标准，但是建议仅采用 BPMN 标准中的一些核心要素图符和规范。

上图右侧所示就是一些企业采用 BPMN 标准绘制“业务级模型”时采纳的 BPMN 标准图符，即业务管理人员只学习、掌握和运用右侧这些图符和相应的规范即可。对技术细节的详细描述，由 IT 工程师在技术平台上基于自动创建的“技术级模型”去进一步完成。可以发现，此时EPC标准和BPMN 标准的区别就不大了。

总之，EBPM 方法论认为“业务级流程模型”可以采用 EPC标准或者极简版的 BPMN 标准来构建。而不管采用哪套标准，推送给流程执行平台时，都可以自动创建符合 BPMN 标准的 “技术级模型” 的基础框架。

最后，还要指出一点。由于 BPMN 标准中没有 “角色” 这个要素图符，而是必须启用 “角色泳道”，所以 BPMN 标准必须是角色泳道图。而 EPC 标准即可以启用 “角色泳道”，也可以不启用。所以EPC 标准更为灵活一点。另外，由于没有 “流程接口” 这个要素图符，BPMN 标准在描述前后置流程时会遇到一些困难。总之，相较于极简版 BPMN 标准，EPC 标准还是更为灵活和简洁一点。所以，EBPM 方法论认为 EPC 标准是业务管理人员描述 “业务级流程模型” 的最佳选择。

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

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

另外，希望今后不再听到这样的问题：请您比较一下 EPC 流程图和流程泳道图之间的优劣？

EPC 是流程建模标准，既可以是泳道图，也可以是瀑布图。

EPC 和泳道图不是两个可以比较的对象。EPC 标准可以比较的对象是同样作为流程建模标准的 BPMN。BPMN 由于没有 “角色” 这个要素图符，所以必须是角色泳道图。