BPMN 图表详解：实用业务流程指南（2026）
学习 BPMN 2.0 符号、核心元素，以及如何创建清晰的业务流程图表。涵盖事件、网关、泳池、泳道和真实案例。
业务流程失败，往往不是因为人员能力不足，而是流程文档不完整，不同团队对流程的理解各有差异。BPMN 的存在正是为了解决这个问题——一种统一的标准化符号，让业务分析师、开发人员和高管都能读懂。
如果你见过带有圆圈、粗边框和 X 标记网关的流程图，那你已经接触过 BPMN 了。本指南将解释这些符号的含义、何时值得使用 BPMN 的复杂性，以及如何创建真正能够传达信息的业务流程图表。
什么是 BPMN？
BPMN 代表业务流程模型和符号（Business Process Model and Notation）。它是由对象管理组（OMG）维护的国际标准（ISO/IEC 19510），用于业务流程建模。当前版本 BPMN 2.0 于 2011 年发布，至今仍是主流标准。
关键词是符号——BPMN 定义的是一种具有精确规则的特定视觉语言，而不仅仅是绘制流程图的通用方法。德国顾问创建的 BPMN 图表，对韩国的开发人员来说应该具有相同的含义。
BPMN 2.0 还定义了一种 XML 交换格式，这意味着在一个工具中创建的 BPMN 图表可以导入另一个工具——某些工具甚至可以直接将 BPMN 图表作为运行中的工作流执行。
BPMN 与普通流程图的对比
大多数流程都用基本流程图来记录。BPMN 更加结构化，也更具表达力。正确的选择取决于你的受众和目的。
| 方面 | 普通流程图 | BPMN 图表 |
|---|---|---|
| 标准 | 无正式标准 | ISO/IEC 19510 (BPMN 2.0) |
| 学习曲线 | 极低——广泛易懂 | 中等——需要学习符号体系 |
| 事件类型 | 仅开始/结束 | 30 多种事件类型（计时器、消息、错误） |
| 并行处理 | 难以表示 | 内置并行网关支持 |
| 多方参与 | 泳道方式略显笨拙 | 原生泳池和泳道支持 |
| 工具可执行 | 否 | 是（通过 BPMS 工具） |
| 最适合 | 简单流程、快速文档记录 | 复杂的跨组织流程、自动化 |
| 受众 | 任何人 | 业务分析师、流程工程师 |
使用普通流程图的场景：
- 你需要向非技术受众快速解释一个流程
- 该流程仅限于一个人或一个团队内部
- 准确性要求较为宽松
- 你在草图阶段，而非为实施而记录文档
使用 BPMN 的场景：
- 流程跨越多个部门或组织
- 你正在工作流引擎中自动化或实施该流程
- 合规性要求可审计的流程文档
- 你需要与开发人员或 BPM 工具进行精确沟通
BPMN 2.0 核心元素
BPMN 有四大主要元素类别：流对象、连接对象、泳道和人工信息。
事件
事件表示发生了某事。它们以圆圈表示，出现在流程的开始、中间或结束位置。
( ) ( ● ) ( × )
开始 消息 终止
事件 开始 结束
开始事件（细边框圆圈）触发流程：
- 普通开始：流程手动启动或按需启动
- 消息开始：流程由传入消息触发
- 计时器开始：流程按计划触发
中间事件（双边框圆圈）在流程中出现：
- 消息中间事件：在流程中途发送或接收消息
- 计时器中间事件：在继续之前等待特定时间
- 错误中间事件：从子流程捕获错误
结束事件（粗边框圆圈）完成流程：
- 普通结束：流程正常结束
- 消息结束：流程通过发送消息结束
- 终止结束：立即停止流程中的所有活动
活动
活动表示正在完成的工作。它们以圆角矩形表示。
任务是原子工作单元——无法进一步分解的单个步骤：
┌─────────────────────┐
│ 审核发票 │
└─────────────────────┘
任务类型通过左上角的图标表示：
- 用户任务：由人执行的工作
- 服务任务：由系统自动执行的工作
- 脚本任务：脚本或规则引擎执行
- 手动任务：无需软件辅助即可执行
子流程内部包含嵌套流程：
┌─────────────────────┐
│ 处理付款 │
│ [+] │
└─────────────────────┘
[+] 标记表示已折叠的子流程，内部细节被隐藏。展开即可查看内部步骤。
网关
网关控制序列流的分叉或合并。它们以菱形表示。
排他网关 (XOR)——根据条件只选择一条路径：
┌─────────────────┐
│ 检查余额 │
└────────┬────────┘
↓
◇ XOR ◇
╱ ╲
[充足] [不足]
↓ ↓
┌──────────┐ ┌──────────────┐
│ 批准 │ │ 拒绝贷款 │
└──────────┘ └──────────────┘
并行网关 (AND)——所有路径同时执行：
◇ AND ◇
╱ | ╲
↓ ↓ ↓
发送 更新 通知
邮件 数据库 团队
当步骤可以并发运行时使用此网关。匹配的关闭网关会等待所有路径完成后再继续。
包含网关 (OR)——一条或多条路径根据条件执行：
◇ OR ◇
╱ ╲
[高优先级] [任意订单]
↓ ↓
上报管理层 记录工单
包含网关评估所有条件。任何评估为真的条件都会创建活动路径。
序列流
序列流是连接泳池内元素的箭头。它们显示活动的顺序。
- 普通流： 实线箭头
- 默认流： 箭头源端有斜线的箭头（当没有其他条件适用时执行）
- 条件流： 箭头源端有菱形的箭头（仅当条件为真时执行）
泳池和泳道
泳池代表参与者——执行流程的组织、系统或角色。泳道将泳池细分为内部角色或部门。
┌─────────────────────────────────────────────────────────┐
│ 泳池：订单履行流程 │
│ ┌──────────────────────────────────────────────────┐ │
│ │ 泳道：销售 │ │
│ │ (开始) → 接收订单 → 确认库存可用性 │ │
│ └──────────────────────────────────────────────────┘ │
│ ┌──────────────────────────────────────────────────┐ │
│ │ 泳道：仓库 │ │
│ │ 拣货 → 包装 → 发货 │ │
│ └──────────────────────────────────────────────────┘ │
│ ┌──────────────────────────────────────────────────┐ │
│ │ 泳道：财务 │ │
│ │ 生成发票 → 收款 │ │
│ └──────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────┘
关键规则：
- 一个泳池 = 一个流程参与者
- 泳道将参与者细分为角色（而非单独的参与者）
- 序列流连接同一泳池内的元素
- 消息流连接不同泳池中的元素（虚线箭头）
何时 BPMN 过于复杂
BPMN 功能强大，但也比较繁重。默认使用它会增加摩擦而无实际收益。
跳过 BPMN 的情况：
- 你在为快速的团队讨论记录流程
- 流程不超过 10 个步骤且只有一个参与者
- 你的受众不熟悉 BPMN 符号（它会带来更多困惑而非清晰）
- 流程处于探索阶段，很可能会有重大变化
必须使用 BPMN 的情况：
- 流程将在工作流引擎中实施（Camunda、Activiti、jBPM）
- 多个组织需要正式确认流程责任
- 合规性要求符合 ISO 标准的文档
- 流程涉及复杂的并行执行路径
- 你在集成系统，需要精确记录消息交换
逐步创建 BPMN 图表
第一步：定义流程范围
命名流程并设定边界：
- 什么事件触发流程？
- 什么事件结束流程？（不同结果可能有多个结束事件）
- 哪个参与者拥有该流程？
第二步：识别参与者
列出所有相关方：
- 哪些角色或部门执行活动？
- 哪些外部系统发送或接收信息？
- 哪些方是外部的（单独的组织）？
为每个参与者创建一个泳池。如果外部方只接收通知，则以没有内部细节的黑盒泳池显示。
第三步：先绘制主路径
在添加例外情况之前，先绘制正常的成功流程：
- 放置开始事件
- 按顺序添加活动
- 用序列流连接
- 添加结束事件
这为你提供了一个可以继续构建的工作框架。
第四步：添加决策点
识别流程分支的每个位置：
- 什么条件决定走哪条路径？
- 路径是互斥的（XOR）还是可以多条触发（OR）？
- 步骤可以并行运行吗（AND）？
放置适当的网关类型，并为每条出路标注条件。
第五步：处理例外和错误
添加中间错误事件和例外路径：
- 如果任务失败会怎样？
- 存在哪些超时？
- 哪些外部事件可能中断流程？
第六步：添加泳池间的消息流
如果存在多个泳池，绘制虚线消息流箭头，显示参与者之间传递的信息。
第七步：与利益相关方审查
与实际流程参与者一起演练图表。询问：
- 这是否反映了实际发生的情况，而不仅仅是理想状态？
- 活动是否放在了正确的泳道中？
- 网关是否正确表示了决策逻辑？
真实案例：订单处理
┌─────────────────────────────────────────────────────────────────────────┐
│ 泳池：电商订单流程 │
│ ┌───────────────────────────────────────────────────────────────────┐ │
│ │ 泳道：客服 │ │
│ │ (开始) → 接收订单 → 发送确认 │ │
│ └───────────────────────────────────────────────────────────────────┘ │
│ ┌───────────────────────────────────────────────────────────────────┐ │
│ │ 泳道：库存 │ │
│ │ 检查库存 → ◇XOR◇ → [有货] → 预留商品 │ │
│ │ → [缺货] → 缺货通知 → (结束) │ │
│ └───────────────────────────────────────────────────────────────────┘ │
│ ┌───────────────────────────────────────────────────────────────────┐ │
│ │ 泳道：支付 │ │
│ │ 处理支付 → ◇XOR◇ → [成功] → 确认 │ │
│ │ → [失败] → 通知客户 → (结束) │ │
│ └───────────────────────────────────────────────────────────────────┘ │
│ ┌───────────────────────────────────────────────────────────────────┐ │
│ │ 泳道：履行 │ │
│ │ 拣货 → 包装订单 → 发货 → [计时器：3天] → (结束) │ │
│ └───────────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────────┘
注意此图表展示了：
- 多条例外路径（缺货、支付失败）
- 用于发货追踪的计时器事件
- 清晰的泳道职责与可见的交接
常见的 BPMN 错误
错误使用网关。 当步骤实际上并行运行时使用 XOR 网关，反之亦然。网关类型必须与实际执行逻辑相匹配。
忘记关闭并行网关。 AND 分叉必须有对应的 AND 合并。如果并行路径开放但从未合并，图表意味着流程永远无法完成。
把所有内容放在一个泳池中。 单独的组织或外部系统应该是单独的泳池，而非泳道。泳道用于一个参与者内部的角色。
过度使用 BPMN 符号。 并非每个图表都需要中间事件、补偿标记和事件子流程。从简单开始，只有在反映真实流程行为时才增加复杂性。
混合抽象级别。 一个泳道显示高级别的"处理申请"，而另一个泳道显示 12 个详细的子步骤。保持粒度一致——要么所有泳道在相同细节级别展示，要么使用子流程来折叠细节。
网关流上没有标签。 离开网关的每条序列流（默认流除外）必须有条件标签。未标记的分支会造成每条路径何时执行的歧义。
使用 Flowova 创建 BPMN 图表
BPMN 图表手动创建出了名的费时——即使在专用工具中，正确使用符号、对齐元素和连接复杂的网关逻辑也需要大量时间。
Flowova 的 BPMN 图表生成器 让你用纯文本描述业务流程，并生成可以精修的结构化图表。这对于从流程描述草拟初始图表或将现有文档转换为可视化形式特别有用。生成后，你可以直接在编辑器中调整网关类型、添加泳道和连接例外路径。
结论
当精确性至关重要时，BPMN 是正确的工具：多方流程、工作流自动化和合规性文档。对于内部沟通和简单流程，普通流程图更快速，也更易于理解。
当你使用 BPMN 时，从主路径开始，正确使用网关类型，并根据实际组织边界匹配泳道结构——而非理想化的组织架构图。
相关资源
- 流程图符号及含义 — 标准符号参考
- 泳道图指南 — 跨职能流程可视化
- BPMN 图表生成器 — 使用 AI 创建 BPMN 图表
- 业务流程图模板 — 即用型流程模板
