业务流程 EPC 模型如何转换成工作流 BPMN 模型

EPC 转 BPMN 不能只做图形符号替换。EPC 更偏向业务分析和过程沟通，用“事件—功能—事件”表达业务状态变化；BPMN 同时面向业务沟通、技术设计和流程执行，必须明确令牌怎样流动、谁在等待什么事件、网关怎样分支与汇聚、任务由谁执行。因此，可靠的转换应分为“解析 EPC、构建中间图、识别语义、规整控制流、生成 BPMN、引擎校验、人工复核”七个步骤。

截至 2026 年 8 月，OMG 公布的 BPMN 最新正式规范仍是 BPMN 2.0.2。SAP Signavio 2026 年用户指南仍提供 EPC 到 BPMN 2.0 的自动迁移功能，但官方同时强调 EPC 与 BPMN 并不完全同构，Letter、Email、Fax、Phone、Entity、Form、Resource 等 EPC 元素不能明确映射，转换后应检查并修改。这个提醒非常重要：自动转换适合生成 BPMN 初稿，不应直接把结果发布到 Flowable 生产环境。

本文先解释 EPC 和 BPMN 的概念、定位与差异，再以“采购申请审批”为例展示完整转换过程，最后给出可落地的转换器架构、映射算法、Flowable 校验和批量迁移方案。

一、核心结论与问题边界

一句话回答：先恢复业务语义，再生成可执行 BPMN

EPC 到 BPMN 的转换对象不是图标，而是业务语义。转换器至少要回答五个问题：

1. EPC 事件表示流程启动、流程结束、普通业务状态，还是一个真正需要等待的外部事件？
2. EPC 功能应该转换为用户任务、服务任务、业务规则任务、子流程，还是只是一段业务说明？
3. AND、XOR、OR 连接符是分支还是汇聚，能否在 BPMN 中找到结构匹配的网关？
4. 组织、岗位和角色应该成为泳道，还是成为用户任务的办理人规则？
5. EPC 中的表单、数据、系统和文档是流程变量、数据对象、服务调用，还是仅保留为扩展属性？

只有这些问题得到明确答案，才能生成可执行 BPMN。否则生成的 XML 即使能被设计器打开，也可能在运行时产生错误分支、重复令牌、永久等待或无人办理任务。

EPC 是什么：以事件和功能交替描述业务过程

EPC 全称 Event-driven Process Chain，通常译为事件驱动过程链。它源于 ARIS 方法体系，主要用于描述业务过程中的时间顺序和逻辑依赖，在 SAP 参考模型和企业流程分析中应用广泛。

EPC 的核心元素包括：

• 事件：描述已经发生或已经成立的业务状态，例如“采购需求已提出”“申请已提交”“订单已创建”。事件本身不消耗资源，通常触发后续功能或表示功能执行后的结果。
• 功能：描述需要执行的业务活动，例如“填写采购申请”“财务审核”“创建采购订单”。
• 连接符：AND、XOR 和 OR，用于表达并行、互斥选择和一个或多个分支选择，可以充当 split 或 join。
• 组织对象：部门、岗位、角色或人员，用于表达谁负责某项功能。
• 信息对象：文档、表单、数据、系统和资源，用于说明功能使用或产生什么信息。
• 流程接口和层级功能：用于链接另一个 EPC 或展开为子过程。

经典 EPC 强调事件与功能交替出现。函数执行后产生一个结果状态，该状态再触发下一个函数。它非常适合业务人员描述“发生了什么—做什么—形成什么状态”，但传统 EPC 一般用于建模、分析和沟通，并不天然等同于可部署的工作流定义。

EPML 是一种面向 EPC 的 XML 交换格式，可以表达事件、功能、AND/OR/XOR 连接符、控制流、层级和图形信息。实际项目还可能从 ARIS AML、SAP Signavio 导出、数据库或厂商 JSON 中获取 EPC，因此转换器不能只绑定一种输入格式。

二、关键概念与能力差异

BPMN 是什么：面向沟通、设计和执行的标准流程语言

BPMN 全称 Business Process Model and Notation。OMG BPMN 2.0.2 不仅定义图形表示，也定义可交换的 XML 元模型，使不同建模工具和流程引擎可以围绕同一套流程语义协作。

BPMN 的主要元素包括：

• 事件：分为开始、中间和结束事件，还区分捕获与抛出，并可携带消息、定时器、信号、错误、升级和补偿等事件定义。
• 活动：包括任务、子流程和调用活动；任务还可细分为用户任务、服务任务、脚本任务、业务规则任务、接收任务等。
• 网关：包括排他、并行、包容、事件网关和复杂网关，用于控制令牌的产生、选择、等待和汇聚。
• 顺序流和消息流：顺序流表示同一参与者内部的执行顺序，消息流表示不同参与者之间的通信。
• Pool 和 Lane：表示参与者和职责分区。
• 数据对象、数据存储和消息：用于表达流程执行所依赖的数据与交互。

Flowable 8 能解析 BPMN 2.0 XML，并把模型转换为引擎内部的 BpmnModel。流程部署后，引擎按 BPMN 令牌语义创建任务、等待事件、执行定时器、判断条件并维护历史。因此，准备部署到 Flowable 的 BPMN 必须比业务分析图更加严格。

EPC 与 BPMN 的定位有什么不同

EPC 的首要价值是帮助业务人员理解过程结构、业务状态和职责关系；BPMN 的目标更宽，既可以绘制业务协作图，也可以形成工作流引擎可解释的执行模型。

比较维度	EPC	BPMN 2.0
核心视角	事件驱动的业务状态变化	活动、事件、参与者和令牌执行
主要用户	业务分析、流程管理、企业架构人员	业务、架构、开发、自动化和运维人员
典型用途	过程梳理、流程地图、职责和信息分析	过程沟通、协作建模、工作流执行和交换
事件含义	多数是业务状态或功能结果	有明确开始、中间、结束、捕获和抛出语义
控制流	AND、XOR、OR 连接符	多种网关、条件流、默认流和事件竞争
参与者	组织对象附着在功能上	Pool、Lane、办理人和消息流
可执行性	传统 EPC 通常不直接执行	BPMN XML 可以部署到支持的流程引擎
交换格式	EPML、AML 或厂商格式，生态并不统一	OMG 定义的 BPMN 2.0 XML

二者不是“旧格式与新格式”的简单关系。企业可以继续使用 EPC 做业务架构和现状分析，再把需要自动化的部分转换为 BPMN；也可以逐步统一到 BPMN，但仍保留价值链、组织、数据和能力地图等企业架构视图。

三、模型架构与运行机制

EPC 与 BPMN 在语义上有哪些关键差异

第一，EPC 的事件经常只是状态说明，而 BPMN 事件可能是运行时等待点。“申请已提交”通常不需要转换成一个中间事件；它更适合作为“提交申请”任务的输出状态、后续顺序流说明或审计状态。如果把它机械转换为消息捕获事件，流程会无故等待一条消息。

第二，BPMN 活动可以直接拥有多个出口。如果没有网关，Flowable 会沿所有满足条件的顺序流继续，多个出口可能产生并行执行。EPC 中隐含的分支意图必须显式转换为合适的网关，不能只删除连接符。

第三，EPC OR 连接符的同步语义长期存在讨论，特别是非局部 OR-Join 需要知道上游哪些分支仍可能到达。BPMN 包容网关也有激活分支和汇聚等待语义，但复杂、非结构化 EPC 不能保证一对一映射。此类模型应进入人工复核，必要时重构为结构化的 XOR、AND 或显式条件子流程。

第四，EPC 常把角色、组织、系统、表单和数据附着在功能周围；BPMN 需要区分参与者、泳道、办理人、数据对象和扩展属性。角色并不必然等于 Lane，不同公司或独立系统也不应只画成同一 Pool 内的 Lane。

第五，BPMN 对异常、超时、取消和补偿有专门元素，而 EPC 经常把这些内容画成普通事件和分支。转换时应识别“超时”“错误”“收到消息”等词义和属性，将其转换为边界事件、事件网关或中间捕获事件，而不是普通顺序流。

EPC 元素应如何映射到 BPMN 元素

推荐使用“规则 + 上下文 + 置信度”的映射，而不是固定字典。

EPC 元素	默认 BPMN 候选	转换条件与注意事项
首事件	Start Event	识别消息、定时器或信号触发；否则使用 None Start Event
末事件	End Event	按业务结果区分正常、错误、终止等结束语义
中间状态事件	删除或转为条件/文档	只有真正等待或抛出的事件才生成 Intermediate Event
人工功能	User Task	绑定候选人、表单、按钮和数据权限
系统功能	Service Task	配置调用方式、重试、超时和错误边界事件
规则判断功能	Business Rule Task 或 Service Task	规则可独立治理时优先 DMN；简单条件也可放在网关出口
层级功能	Sub-Process 或 Call Activity	内嵌范围用子流程，可复用外部流程用调用活动
Process Interface	Call Activity、Link Event 或引用	取决于它表示真实调用、跨图导航还是文档链接
XOR	Exclusive Gateway	每个出口有互斥条件，并设置默认流
AND	Parallel Gateway	split 产生所有分支，join 等待所有已创建分支
OR	Inclusive Gateway	仅在激活与汇聚语义清晰时自动映射
角色/岗位	Lane 或办理人规则	职责展示用 Lane，运行分配用 candidate/assignee 扩展
组织	Pool 或 Lane	独立参与者用 Pool，并以 Message Flow 通信
数据/文档	Data Object、Data Store 或扩展属性	表单、附件和业务实体通常保留业务引用

SAP Signavio 的自动迁移允许把 Position/Role 和 Organization 转为 Pool/Lane，并依据 Responsibility 关系分配功能；如果没有责任关系，可能产生空 Pool/Lane。这说明组织映射必须依赖责任属性，而不能仅依据图形邻近关系。

四、核心场景与处理策略

哪些 EPC 内容不能自动一对一转换

以下情况应标记为“需要人工决策”，而不是悄悄丢弃：

• 一个 EPC 事件既像业务状态，又带有“收到、等待、到期”等触发含义。
• 功能没有类型信息，无法判断它是人工任务还是系统任务。
• 一个组织对象同时承担执行、审批、咨询和知会职责。
• OR-Join 位于非结构化循环或跨层级分支中，无法确定应等待哪些分支。
• 一个功能有多个入口或出口，但模型没有显式连接符。
• 流程接口只表示文档导航，却被误判为可执行子流程调用。
• 表单、邮件、电话、资源等对象缺少目标系统、数据类型或动作语义。
• 多个起点只是不同前置状态，还是不同消息/定时器触发，模型没有说明。

转换器应为每个映射结果保存置信度和原因。例如“功能名称包含审批且责任角色存在”可高置信映射为 User Task；“事件名称为申请已提交且位于两个功能之间”可高置信删除为状态说明；“事件名称为收到供应商报价”可能是消息事件，需要人工确认是模型外部消息还是内部任务结果。

示例：一个采购申请 EPC 模型

示例 EPC 表达以下业务：

1. “采购需求已提出”后，申请人执行“填写采购申请”。
2. 形成“申请已提交”状态后，系统执行“判断采购级别”。
3. XOR 根据金额选择普通采购或重大采购。
4. 普通采购由部门负责人审批。
5. 重大采购同时进行财务复核和法务复核，两个分支完成后继续。
6. 两条路径汇合后创建采购订单，最终形成“采购订单已创建”状态。

这个 EPC 适合业务沟通：事件清楚说明每个功能前后的状态，组织对象可以附着到审批功能，AND 和 XOR 连接符也能表达主要逻辑。但它还没有说明 BPMN 开始事件类型、任务技术类型、网关条件表达式、办理人规则、异常边界和服务调用方式。

五、数据、规则与状态设计

转换后的 BPMN 模型应该是什么样

转换后的 BPMN 可以简化为：

Start Event → 提交采购申请 User Task → 判断采购级别 Business Rule Task → Exclusive Gateway。

普通采购路径进入“部门负责人审批”User Task；重大采购路径进入 Parallel Gateway，同时创建“财务复核”和“法务复核”两个 User Task，待两个分支在 Parallel Gateway 汇聚后继续。两条金额路径通过 Exclusive Gateway 汇聚，再执行“创建采购订单”Service Task，最后到达 End Event。

EPC 中“申请已提交”“普通采购”“重大采购”“审批已通过”等状态事件没有全部保留为 BPMN 中间事件。普通/重大采购被转换为排他网关出口条件，例如 ${amount <= 50000} 与 ${amount > 50000}；审批结果由用户任务完成、变量和审计记录表达。只有真正会让流程等待外部触发的状态，才应该生成消息、定时器或信号捕获事件。

组织对象也被拆成两层：Pool/Lane 用于图形上展示采购、财务和法务职责；Flowable 扩展属性用于运行时解析办理人。泳道解决“谁负责哪一段”的阅读问题，candidateGroups、assignee 或自定义办理人规则解决“实际给谁创建待办”的执行问题。

这个示例的逐步转换逻辑

第一步，识别首事件和末事件。“采购需求已提出”没有外部触发类型，因此转换为 None Start Event；“采购订单已创建”转换为普通 End Event。

第二步，给功能分类。“填写采购申请”和三类审批是人工工作，转换为 User Task；“判断采购级别”调用决策规则，转换为 Business Rule Task 或调用 DMN 的 Service Task；“创建采购订单”调用采购系统，转换为 Service Task。

第三步，压缩状态事件。位于功能之间、只描述上一功能结果的事件不生成运行节点，而是保留在源映射报告、任务完成结果或顺序流说明中。

第四步，映射连接符。XOR split 转为 Exclusive Gateway，并给出口设置互斥条件和默认流；AND split/join 成对转为 Parallel Gateway；路径重新汇合时增加 Exclusive Gateway merge，使图形和令牌语义清晰。

第五步，补充可执行属性。为用户任务配置办理人规则和表单，为服务任务配置实现方式、超时、重试和错误处理，为流程设置 process id、业务键、变量模式和版本说明。

第六步，重新布局并人工确认。转换器生成的 BPMN DI 坐标只是初稿，需检查泳道、分支方向、交叉线和标签位置，确保图形可读。

六、工程实现与系统集成

技术方案：建立“解析—中间图—转换—校验”流水线

推荐将转换器拆成六个模块。

输入适配器读取 EPML、AML、厂商 JSON 或建模平台 API，统一提取节点、边、坐标、责任关系和属性。不同来源的字段映射保存在独立适配器中，不让厂商格式污染核心算法。

中间表示层把 EPC 转为带类型和属性的有向图。图节点保留 sourceId、sourceType、name、attributes、responsibilities、incoming 和 outgoing；图边保留控制流类型、条件、源坐标和原始关系。

规范化模块修复或报告重复 ID、悬空边、多个无连接组件、非法多入口多出口、缺失连接符、事件—功能交替异常和无法配对的 split/join。

语义映射模块根据节点类型、位置、名称、责任对象和上下文生成 BPMN 候选，并给出 confidence、ruleId 和 reviewRequired。低置信结果进入人工决策清单。

BPMN 生成模块创建 BPMN 2.0 元模型和 BPMN DI。前端可使用 bpmn-moddle 生成 XML、bpmn-js 预览和编辑；Java 服务也可直接构建 Flowable BpmnModel，再通过 BpmnXMLConverter 输出 XML。

验证模块执行 OMG XSD/元模型检查、Flowable 可执行性校验、结构规则、路径测试和人工复核。只有全部通过的版本才能进入模型发布流程。

中间图模型应该保存哪些信息

不要从 EPC DOM 直接边遍历边生成 BPMN XML。中间图可以隔离输入格式差异，也便于运行结构算法和生成转换报告。

{
  "id": "epc-f-17",
  "kind": "FUNCTION",
  "name": "财务复核",
  "responsibilities": ["finance-reviewer"],
  "attributes": { "automation": "human" },
  "incoming": ["arc-31"],
  "outgoing": ["arc-32"],
  "source": { "format": "EPML", "modelId": "purchase-v1" }
}

中间图还应保存转换后的 targetId 和映射证据。这样发生问题时，可以从 BPMN 节点追溯到原 EPC 元素，也可以生成“已映射、已压缩、已忽略、待人工确认”四类清单。

对于层级 EPC，中间图需要显式表示模型引用关系。层级功能可以映射为嵌入式 Sub-Process，也可以映射为引用独立流程的 Call Activity；选择依据是子过程是否复用、是否需要独立版本、是否与主流程共享生命周期。

七、安全、性能与治理要求

转换算法需要解决哪些关键问题

首先识别 split 和 join。节点出度大于 1 表示分支候选，入度大于 1 表示汇聚候选。连接符类型提供 AND/XOR/OR 语义，但复杂模型还需要用支配关系和后支配关系寻找结构块，判断哪个 join 对应哪个 split。

其次识别 EPC 事件类别。可以组合位置、关键字、属性和相邻节点判断：无前驱事件是开始候选，无后继事件是结束候选；位于两个功能之间且名称为完成状态的事件通常可压缩；名称包含“收到、等待、到期”且来自外部参与者的事件可能映射为捕获事件；名称包含“发送、发布、通知”的事件可能映射为抛出事件或发送任务。

第三处理隐式网关。EPC 功能或事件如果有多个出口但没有连接符，转换器不能让 BPMN 活动直接多出口，因为那可能产生并行执行。应根据条件和语义插入 XOR、AND 或 OR 网关；无法判断时阻止自动发布。

第四处理循环。先识别回边和强连通分量，再确认循环出口条件。循环中的 XOR/OR 汇聚要特别检查令牌是否可能重复进入；无限循环、无出口循环和跨子流程回边应作为错误或高风险警告。

第五处理 OR。结构化、条件明确的 OR split/join 可以转换为 Inclusive Gateway；非局部 OR、分支重叠或跨循环 OR 必须降级为人工重构，不能以“看起来最像”为理由自动生成。

如何生成 Flowable 可以执行的 BPMN XML

生成阶段先创建 definitions、process、collaboration、participant 和 laneSet，再按拓扑顺序创建事件、活动、网关和顺序流。所有 ID 必须稳定且在流程内唯一，建议由源模型 ID 加命名空间生成，而不是每次随机生成。

用户任务需要补充办理人和表单引用，服务任务需要补充实现类型或调用配置，网关出口需要条件表达式和默认流。Flowable 自定义属性应放在 flowable: 命名空间中，同时把原 EPC ID、转换规则和转换版本写入 extensionElements，便于追溯。

前端方案可以用 bpmn-moddle 把对象树序列化为 BPMN 2.0 XML，再用 bpmn-js 的 importXML 加载预览；服务端方案可以用 Flowable 的 BpmnModel 和 BpmnXMLConverter。无论采用哪种方式，BPMN DI 都要包含 shape bounds、edge waypoints 和 label 位置，否则 XML 虽然可部署，设计器打开后却可能没有可用布局。

生成结果不要直接部署。先调用 Flowable RepositoryService.validateProcess(BpmnModel) 或 ProcessValidator.validate(BpmnModel) 获取可执行性错误，再在隔离环境部署，通过 RepositoryService 读取回模型，确认序列化和反序列化一致。

八、平台落地、测试与选型

转换后应该进行哪些验证和测试

第一层是格式验证：XML 能通过 BPMN 2.0 Schema 或元模型解析，命名空间、ID 引用和 BPMN DI 完整。

第二层是结构验证：每个非开始节点有入口，每个非结束节点有出口；网关类型明确；条件流有表达式；默认流存在；子流程边界合法；顺序流不跨 Pool 和 Sub-Process 边界。

第三层是令牌语义验证：枚举代表性路径，检查 XOR 只选一个分支、AND 创建并等待全部分支、OR 只等待实际激活分支、循环能够退出、结束事件不会意外终止其他分支。

第四层是 Flowable 校验：使用 Flowable 8 的模型转换器和 ProcessValidator，检查用户任务、服务任务、事件和网关是否符合引擎支持范围。之后运行最小化自动测试，启动实例、完成用户任务、设置条件变量并验证最终状态。

第五层是业务复核：由 EPC 模型负责人确认活动、状态、角色、数据和路径没有丢失；由流程开发人员确认办理人、表单、变量、异常和服务调用已补齐；由运维人员确认定时器、重试和外部依赖可观测。

转换质量不应只用“节点转换成功率”衡量，还应统计自动映射率、人工确认率、被压缩事件数、被忽略对象数、结构错误数、引擎校验错误数和路径测试覆盖率。

批量迁移 EPC 资产时怎样控制风险

先按模型价值和复杂度分组。简单、结构化、无 OR、无循环的 EPC 可以批量自动转换；包含层级、跨组织、复杂 OR、循环和大量附着对象的模型应进入专家迁移队列；只用于制度归档、没有自动化价值的 EPC 可以继续保留，不必强制转换。

每个模型保存源文件、源版本、转换器版本、规则集版本、转换报告和目标 BPMN。源 EPC 与目标 BPMN 建立不可变映射，后续修改以 BPMN 为主，避免两边同时编辑造成双主数据。

推荐采用“转换草稿—自动校验—人工复核—沙箱演练—发布审批”的工作流。云程低代码开发平台一类产品可以把转换结果接入 BPMN.js 设计器、表单、办理人规则和发布中心，让业务模型逐步补齐为可执行应用，但仍要保留源 EPC 的追溯关系和转换报告。

批量迁移时不要追求百分之百自动化。转换器最有价值的能力，是自动完成确定性工作，并把不确定点准确交给人，而不是生成一批表面完整、运行语义错误的 BPMN。

九、如果只记住四个结论

第一，EPC 是面向业务状态和过程分析的模型，BPMN 是兼顾沟通、交换和执行的标准流程语言，二者定位不同。

第二，EPC 事件不能全部转换为 BPMN 事件。多数中间状态事件应压缩为任务结果、条件或文档，只有真实的运行时触发和等待才使用 BPMN Event。

第三，AND、XOR、OR 不只是图标映射。必须识别 split/join、激活分支、汇聚等待、循环和非结构化控制流，尤其不能盲目转换复杂 OR。

第四，可用的技术方案应包含输入适配器、中间图、规则与置信度、BPMN 生成、Flowable 校验、路径测试和人工复核。自动转换的正确目标是“生成可信初稿并暴露不确定性”，不是“一键直接上线”。