BPMN（业务流程模型与符号）是一种用于描述业务流程如何运作的标准可视化语言。它帮助业务用户、分析师、开发人员和管理人员使用一致的符号理解同一流程。
该图总结了 BPMN 的五个主要领域：
-
泳道——谁负责
-
流程元素——流程中发生什么
-
连接对象——元素之间如何关联
-
数据——使用或产生的信息
-
工件——额外的解释性信息
1. BPMN 的用途
BPMN 可以描述以下类型的流程：
-
处理客户订单
-
审批员工休假申请
-
处理保险理赔
-
新员工入职
-
从仓库发货产品
-
解决客户投诉
-
审批发票
BPMN 图可以回答以下问题：
-
谁执行每项活动？
-
首先发生什么？
-
做出哪些决策？
-
哪些活动是并行发生的？
-
需要哪些信息？
-
发生错误时会怎样？
-
流程何时结束？
一个简单的流程可能如下所示：
客户下单
↓
销售部门审核订单
↓
仓库准备发货
↓
订单已发出
↓
客户收到确认
BPMN 使用事件、任务、网关、流程、池和泳道以可视化方式表示此流程。
2. BPMN 图表结构
BPMN 流程通常包含四个基本部分：
开始事件 → 活动 → 决策 → 活动 → 结束事件
例如：
收到订单
↓
检查库存
↓
产品是否有货？
↙ ↘
是 否
↓ ↓
打包订单 通知客户
↓ ↓
发货订单 取消订单
↘ ↙
结束
主要元素描述如下。
3. 泳道：池与泳道
泳道用于组织职责。它们显示每个活动由哪个参与者、部门、角色或系统执行。
池
一个池代表流程中的一个主要参与者。
参与者可能是：
-
一家公司
-
一位客户
-
一个供应商
-
一家银行
-
一个政府机构
-
一个外部软件系统
示例：
池：在线零售公司
一个池可以包含一个或多个泳道。
当不建模内部流程时，池也可以显示为折叠的方框。
泳道
一个泳道是池内部的一个子部分。它通常表示：
-
一个部门
-
一个职位角色
-
一个团队
-
一个系统
-
一个业务职能
示例：
池：在线零售公司
├── 销售部
├── 仓库
└── 财务部
一个流程可能这样组织：
| 泳道 | 职责 |
|---|---|
| 客户 | 下订单并接收通知 |
| 销售部 | 审核并确认订单 |
| 仓库 | 拣货、打包并发货 |
| 财务部 | 处理付款 |
| 配送合作伙伴 | 配送包裹 |
带泳道的示例
客户 | 下订单 ─────────────── 接收确认
|
销售部 | 接收订单 → 检查订单 → 确认订单
|
仓库 | 拣货 → 打包 → 发货
|
财务部 | 接收付款请求 → 批准付款
活动在一个泳道中的位置表明了谁对其负责。
池与泳道的区别
| 元素 | 含义 | 典型示例 |
|---|---|---|
| 池 | 主要参与者或组织 | 客户、供应商、银行 |
| 泳道 | 参与者内部的角色、部门或系统 | 销售、仓库、财务 |
初学者规则
使用池当参与者在组织上或操作上相互独立时使用。使用泳道当参与者是池内的角色或组时使用。
4. 流程元素
流程元素描述过程中发生的内容。主要有三种类型：
-
事件
-
活动
-
网关
4.1 事件
事件表示过程中发生的某件事。事件通常不描述正在执行的工作，而是指示某事开始、中断或结束流程。
事件用圆圈表示。
开始事件
开始事件显示流程的起始位置。
符号：细线圆圈
示例：
-
客户提交订单
-
收到一条消息
-
计时器到达预定日期
-
员工提交请求
示例：
○ 收到订单
开始事件通常应有流出流，但不应有流入顺序流。
中间事件
中间事件发生在流程的开始和结束之间。
符号：双线圆圈
它可以表示：
-
等待消息
-
等待计时器
-
捕获错误
-
发送通知
-
升级问题
示例：
开始 → 审核订单 → ◉ 等待付款 → 发货
中间事件可以是：
-
捕获某事，例如等待传入的消息
-
抛出某事，例如发送消息或引发错误
结束事件
结束事件表示流程路径的结束位置。
符号：粗线圆圈
示例：
-
订单已完成
-
请求被拒绝
-
支付失败
-
案件已关闭
示例：
发货 → ● 订单已完成
结束事件通常具有传入的顺序流，但没有传出的顺序流。
4.2 活动
活动表示在流程中执行的工作。活动以圆角矩形表示。
示例：
-
审核申请
-
批准付款
-
拣选产品
-
发送发票
-
更新客户记录
活动通常应使用动词和宾语命名：
-
审查申请
-
验证地址
-
批准请求
-
发送确认
避免使用模糊的名称，例如：
-
处理
-
工作
-
处理问题
-
步骤 1
任务
一个任务是当前图中不再进一步分解的单一工作单元。
示例：
[审查客户订单]
任务可以手动执行、自动执行，或由用户与系统协作完成。
常见的 BPMN 任务类型包括：
| 任务类型 | 含义 | 示例 |
|---|---|---|
| 用户任务 | 人员使用系统执行工作 | 批准贷款申请 |
| 手动任务 | 人员在没有系统的情况下执行工作 | 检查包裹 |
| 服务任务 | 系统或自动化服务执行工作 | 计算运费 |
| 发送任务 | 发送消息 | 发送订单确认 |
| 接收任务 | 等待消息 | 接收供应商响应 |
| 脚本任务 | 执行脚本或程序 | 计算总计 |
| 业务规则任务 | 应用业务规则 | 确定折扣 |
对于初学者而言，除非具体实现至关重要，否则普通的通用任务通常已足够。
子流程
一个子流程是一组被视为一个更大活动的活动集合。
示例：
[处理客户退货]
子流程内部可能包含：
接收退货请求
↓
检查退货资格
↓
检查退回商品
↓
发放退款
在以下情况下使用子流程：
-
活动组在逻辑上相互关联
-
图表变得过大
-
您希望暂时隐藏细节
-
同一组步骤被重复使用
-
不同人员需要不同详细程度的信息
子流程在折叠时显示为带有一个小加号的圆角矩形。
4.3 网关
网关控制流程的分支、合并或决策方式。网关用菱形表示。
菱形内部的符号表示网关类型。
排他网关：XOR
排他网关仅选择一条路径。
示例：
┌── 是 → 批准请求
检查请求 ─◇─┤
└── 否 → 拒绝请求
当仅有一个条件可能为真时，请使用排他网关。
示例问题：
订单金额是否超过 1,000 美元？
可能的路径：
-
是：需要经理审批
-
否：自动继续
典型表示法：
◇ 付款是否已批准？
应仅遵循一条 outgoing 路径。
并行网关：AND
并行网关同时激活多条路径。
示例：
┌── 发送发票
订单已确认 ─◇
└── 准备发货
两项活动均会执行。
并行网关也可用于同步并行路径：
发送发票 ────┐
◇── 发货
准备发货 ┘
流程仅在两个分支都完成后继续。
当活动相互独立且可并发执行时，请使用并行网关。
包容网关：OR
包容网关根据条件激活一条或多条路径。
示例：
客户类型？
├── 企业客户 → 创建企业账户
├── 国际客户 → 计算关税
└── 高级客户 → 应用高级折扣
可能选择其中一条、两条或全部三条路径。
当多个条件可能同时为真时，请使用包容式网关。
基于事件的网关
基于事件的网关根据最先发生的事件选择路径。
示例：
发送报价
↓
◇ 等待事件
├── 客户接受 → 创建订单
├── 客户拒绝 → 关闭请求
└── 计时器超时 → 发送提醒
当流程等待相互竞争的事件时，这种方法非常有用，例如：
-
客户的响应
-
超时
-
来自其他系统的消息
网关比较
| 网关 | 选择的路径数量 | 主要用途 |
|---|---|---|
| 排他式 | 恰好一条 | 在备选方案中选择 |
| 并行式 | 所有适用的路径 | 同时执行工作 |
| 包容式 | 一条或多条 | 遵循所有适用的条件 |
| 基于事件的 | 最先发生的事件 | 对最先发生的事件做出响应 |
网关命名
网关可以写成一个问题：
-
付款是否已批准？
-
客户是否符合资格？
-
所有文档是否完整？
-
截止日期是否已过？
随后，流出流应使用匹配的条件：
-
是 / 否
-
已批准 / 已拒绝
-
完整 / 不完整
5. 连接对象
连接对象展示 BPMN 元素之间如何相互关联。
5.1 顺序流
一个顺序流显示活动、事件和网关发生的顺序。
它由带实心箭头的实线表示。
开始 → 审查请求 → 批准请求 → 结束
顺序流通常用于同一泳道内。
示例：
○ 开始 → [验证订单] → ◇ 付款是否已批准？
顺序流规则
-
使用箭头表示方向。
-
保持方向一致，通常从左到右或从上到下。
-
必要时标注条件流。
-
避免线条交叉。
-
不要使用顺序流连接不同的泳道。
5.2 消息流
一个消息流显示不同参与者或泳道之间的通信。
它由带空心箭头的虚线表示。
示例：
客户泳道 - - - 订单消息 - - -> 公司泳道
公司泳道 - - - 确认 - - -> 客户泳道
消息流可以表示：
-
发送订单
-
接收发票
-
发送付款请求
-
接收交付更新
-
与外部系统交换信息
顺序流与消息流
| 连接 | 用于…之间 | 含义 |
|---|---|---|
| 顺序流 | 同一池中的元素 | 工作顺序 |
| 消息流 | 独立的池或参与者 | 参与者之间的通信 |
初学者常见的错误是在两个池之间使用顺序流。应改用消息流。
5.3 关联
一个关联将附加信息链接到 BPMN 元素。
它以虚线形式显示。
使用它来连接：
-
文本注释到活动
-
数据对象到任务
-
组到相关元素
示例：
[批准发票] ······· “需要经理批准”
关联不控制流程的顺序。它仅添加上下文。
5.4 数据关联
一个数据关联显示数据如何进入或离开某项活动。
它可以显示：
-
正在使用的输入文档
-
正在生成的输出文档
-
正在更新的信息
-
正在存储的数据
示例：
[创建发票] ─ ─ ─ → 发票文档
该线通常为虚线，并带有开放式箭头。
6. 数据元素
BPMN 数据元素显示流程中使用或创建的信息。
6.1 数据对象
一个数据对象表示在流程中使用或生成的信息。
示例：
-
客户订单
-
发票
-
申请表
-
运单标签
-
审批文档
-
付款收据
示例：
[审核订单] ─ ─ ─ → 订单文档
数据对象不一定指纸质物理文档，它也可能代表数字文件或业务记录。
6.2 数据输入
一个数据输入表示进入流程的信息。
示例：
-
客户申请
-
供应商报价
-
新订单
-
上传的文档
示例：
客户申请 → 处理申请
6.3 数据输出
一个数据输出表示由流程产生的信息。
示例：
-
已批准的申请
-
发货确认
-
发票
-
完成报告
6.4 数据存储
一个数据存储表示在单个流程实例之外仍持续存在并可用的信息。
示例：
-
客户数据库
-
库存系统
-
员工记录
-
文档存储库
-
会计系统
示例：
[更新库存] ─ ─ ─ ↔ 库存数据库
当流程从长期信息存储库读取或向其写入时，数据存储非常有用。
数据元素比较
| 元素 | 含义 | 示例 |
|---|---|---|
| 数据对象 | 在过程中使用或产生的信息 | 订单表 |
| 数据输入 | 进入过程的信息 | 客户申请 |
| 数据输出 | 离开过程的信息 | 批准通知 |
| 数据存储 | 持久化信息存储库 | 客户数据库 |
7. 工件
工件在不改变流程的情况下添加信息。
该图像显示了两种常见的工件：分组和文本注释。
7.1 分组
分组在视觉上包围相关元素。
分组使用虚线圆角矩形表示。
使用分组来：
-
突出显示过程的某个阶段
-
组织相关活动
-
标记与合规相关的步骤
-
标识可选工作
-
解释过程边界
示例：
┌ - - - - - 客户验证 - - - - - ┐
[检查身份] → [验证地址]
└ - - - - - - - - - - - - - - - - - - - - -┘
组不控制执行。它仅是一种视觉辅助。
7.2 文本注释
文本注释用于添加评论或说明。
示例：
[批准退款] ····· “超过 500 美元的退款需要经理批准。”
注释有助于：
-
业务规则
-
例外情况
-
政策
-
假设
-
异常行为的解释
-
给读者的备注
请勿将文本注释作为实际 BPMN 逻辑的替代品。如果规则改变了流程路径，请使用网关或事件对其进行建模。
8. 完整示例：在线订单流程
以下示例结合了池、泳道、活动、网关、数据和消息。
场景
客户下在线订单。公司检查库存和付款。如果产品有货且付款已批准，仓库将发货。否则，通知客户。
客户
○ 下订单
|
| 订单消息
v
在线商店
销售部
○ 接收订单
↓
[检查库存]
↓
◇ 产品有货？
↙ ↘
否 是
↓ ↓
[通知客户] [请求付款]
↓ ↓
● 订单关闭 ◇ 付款已批准？
↙ ↘
否 是
↓ ↓
[通知客户] 仓库
↓ [拣货]
● 订单关闭 ↓
[打包订单]
↓
[发货]
↓
[发送确认]
↓
● 已完成
流程中使用的数据
客户订单 → 接收订单
库存数据库 ↔ 检查库存
付款请求 → 请求付款
运单 → 发货
订单确认 → 发送确认
参与者之间的通信
-
客户向公司发送订单。
-
公司向支付提供商发送付款请求。
-
支付提供商发送批准或拒绝消息。
-
公司向客户发送确认信息。
-
仓库接收发货请求。
9. 示例：员工休假申请
业务规则
员工提交休假申请。经理批准或拒绝该申请。如果批准，人力资源系统将更新员工的休假余额。
员工
○ 提交休假申请
↓
经理
[审查申请]
↓
◇ 已批准？
↙ ↘
否 是
↓ ↓
[发送拒绝] [通知员工]
↓ 人力资源部
● 结束 [更新休假余额]
↓
[记录批准]
↓
● 结束
可能的数据元素
-
休假申请
-
员工休假余额
-
审批通知
-
人事记录
可能的注释
“超过10个工作日的申请需要部门负责人审批。”
如果该规则创建了另一个决策路径，应使用网关进行建模，而不仅仅是作为注释书写。
10. 示例：并行活动
假设已批准的贷款申请需要同时进行信用检查和身份验证。这两项工作可以并行进行。
[接收贷款申请]
↓
◇ 并行网关
↙ ↘
[信用检查] [身份验证]
↘ ↙
◇ 并行网关
↓
[做出贷款决策]
↓
● 结束
第一个并行网关将流程拆分，第二个网关则等待两项活动均完成后继续。
在以下情况下使用此模式：
-
活动相互独立
-
两项活动均为必需
-
同时执行可节省时间
11. 示例：等待事件
供应商会发送报价，但如果响应时间过长，公司也可能取消该请求。
[发送报价请求]
↓
◇ 基于事件的网关
↙ ↘
[接收报价] [计时器到期]
↓ ↓
[评估报价] [发送提醒]
↓ ↓
● 结束 ● 结束
路径取决于哪个事件先发生。
12. 如何创建BPMN流程图
在建模新业务流程时，请遵循此过程。
步骤1：定义流程范围
确定流程的起点和终点。
示例：
-
开始：客户提交订单
-
结束：订单已发货或已取消
避免在一个流程图中建模整个组织。
步骤2：识别参与者
列出涉及的人员、部门、组织和系统。
示例：
-
客户
-
销售部门
-
仓库
-
支付提供商
确定哪些应作为池，哪些应作为泳道。
步骤 3：识别开始事件
问：
什么触发了此流程？
可能的答案：
-
提交了请求
-
收到消息
-
预定时间到达
-
条件变为真
步骤 4：列出主要活动
先用通俗语言描述工作内容。
示例：
-
接收订单
-
检查库存
-
请求付款
-
拣选产品
-
打包订单
-
发货订单
-
发送确认
步骤 5：添加决策点
寻找会改变后续流程的问题。
示例：
-
产品是否有货？
-
付款是否已批准？
-
请求是否完整？
-
截止日期已过吗？
使用网关来表示这些决策。
步骤 6：添加结束事件
一个流程可能有多个结束点。
示例：
-
订单已完成
-
订单已取消
-
请求被拒绝
-
支付失败
步骤 7：添加顺序流
将流程从头到尾连接起来，保持方向清晰易懂。
步骤 8：添加消息
使用消息流显示不同池之间的通信。
步骤 9：添加数据和注释
仅在有助于阐明流程的地方添加文档、数据库、规则和注释。
步骤 10：审查图表
检查以下内容：
-
每条流程路径都正确开始
-
每条路径都能到达结束点
-
网关逻辑配对正确
-
职责清晰明确
-
消息连接不同的参与者
-
活动命名一致
-
图表可读性强
13. 命名规范
良好的命名使 BPMN 图表更易于理解。
事件
使用名词或事件短语：
-
订单已接收
-
支付已批准
-
已到达截止日期
-
客户取消请求
任务
使用动词后接宾语：
-
验证申请
-
检查库存
-
批准付款
-
发送通知
网关
使用疑问句：
-
申请是否完整？
-
付款是否已批准？
-
产品是否可用？
结束事件
使用结果：
-
订单已完成
-
请求被拒绝
-
付款失败
-
案件已结案
避免使用模糊的标签，例如：
-
处理订单
-
处理请求
-
进行检查
-
需要采取行动
优先使用更精确的名称：
-
验证订单详情
-
审查客户请求
-
检查付款状态
-
发送批准通知
14. 初学者常见错误
使用了错误的流程类型
错误示例：
两个独立池之间的顺序流
正确示例：
独立池之间的消息流
在参与者内部的活动顺序中使用顺序流。在参与者之间的通信中使用消息流。
将每个部门都视为独立的池
同一组织内的部门通常更适合表示为单个池中的泳道。独立的池更适用于独立的参与者。
对简单的顺序工作使用网关
如果没有分支或合并，请勿添加网关。
不必要的：
开始 → ◇ → 审核表单 → ◇ → 结束
更好的做法：
开始 → 审核表单 → 结束
忘记合并分支
如果网关将流程拆分，其分支可能需要在后续步骤中合并。
例如，在批准或拒绝请求后，流程可能会继续到一个通用的通知步骤。
使用文本代替流程逻辑
将“如果支付失败，通知客户”作为注释书写并不能对行为进行建模。请使用排他网关：
◇ 支付是否已批准？
├── 是 → 继续订单
└── 否 → 通知客户
使图表过载
包含过多细节的图表会变得难以阅读。请使用：
-
子流程
-
单独的图表
-
分组
-
为不同受众提供更具体的视图
混合不同详细程度的内容
除非关系明确，否则避免将高级活动（如“处理订单”）与详细步骤（如“打印标签”和“密封包裹”）并列放置。
为图表选择一种详细程度，或使用子流程。
缺少结束事件
流程通常应明确其可能的结果。在适当的情况下，应为成功、被拒绝、已取消或失败的路径包含结束事件。
15. BPMN 建模最佳实践
-
从流程目标和范围开始。
-
使用清晰的从左到右或从上到下的方向。
-
除非确实需要多个触发器，否则只使用一个开始事件。
-
为每条重要路径明确其结果。
-
保持任务处于相似的详细程度。
-
使用泳道来明确责任。
-
标注网关的流出流。
-
仅在参与者之间通信时使用消息流。
-
尽可能避免连接线交叉。
-
优先使用有意义的名称，而非技术名称。
-
仅在信息重要时使用数据对象。
-
使用注释进行解释，而非替代流程逻辑。
-
将大型图表分解为子流程。
-
与执行实际工作的人员一起验证模型。
16. BPMN 快速速查表
| 符号或概念 | 含义 |
|---|---|
| 细圆圈 | 开始事件 |
| 双圆圈 | 中间事件 |
| 粗圆圈 | 结束事件 |
| 圆角矩形 | 活动或任务 |
| 带加号的圆角矩形 | 折叠子流程 |
| 带叉的菱形 | 排他网关 |
| 带加号的菱形 | 并行网关 |
| 带圆圈的菱形 | 包容网关 |
| 带事件标记的菱形 | 基于事件的网关 |
| 实线箭头 | 顺序流 |
| 虚线箭头 | 消息流 |
| 点线 | 关联 |
| 文档形状 | 数据对象 |
| 数据库圆柱体 | 数据存储 |
| 虚线分组框 | 组 |
| 文本框 | 文本注释 |
| 大型外部容器 | 池 |
| 池内的细分 | 泳道 |
17. 简单的 BPMN 建模检查清单
在最终确定图表之前，请询问：
流程流
-
是否有明确的开始？
-
正常流程是否易于理解？
-
每条路径最终都会结束吗？
-
决策是否由网关表示？
职责
-
每项活动是否都分配给了参与者或泳道？
-
池是否用于表示不同的参与者？
-
泳道是否用于表示内部角色或部门？
连接
-
顺序流是否在池内使用？
-
消息流是否在池之间使用？
-
网关分支是否已标注？
信息
-
是否显示了重要文档？
-
持久系统是否表示为数据存储？
-
注释是否仅用于澄清说明？
可读性
-
图表是否过大？
-
活动名称是否一致？
-
连接线是否易于追踪？
-
子流程是否可以简化该图表？
核心理念很简单：事件描述发生的情况，活动描述工作内容，网关控制决策或并行路径，泳道显示职责，连接显示关系，数据元素显示信息。这些元素共同提供了业务流程如何开始、推进、分支、通信和结束的清晰图景。
参考文献
- BPMN、Visual Paradigm 工具、人工智能及生态系统的综合指南: 官方博客文章，概述 VP AI 生态系统的四大支柱，并包含员工入职和订单履行等实用的 BPMN 示例。
- 掌握业务流程建模：BPMN 与 AI 驱动图表生成的完整指南: 官方指南，详细介绍如何使用 AI 业务流程图表生成器，包含分步说明和功能对比。
- 从文本到流程：我对 Visual Paradigm AI 驱动 BPMN 生成器的实操评测: 从业务分析师角度对生成器在现实场景（电子商务、IT 支持、银行）中的独立评测。
- AI BPMN 图表生成器：专业业务流程图工具: 官方产品页面，介绍文本转图表功能、在 VP Desktop 中的访问方式以及关键优势（如标准合规性）。
- BPMN、Visual Paradigm 工具、人工智能与生态系统全面指南: 该综合指南的中文版，涵盖 BPMN 基础知识和人工智能驱动生成的案例研究。
- 从文本到流程：Visual Paradigm 人工智能驱动 BPMN 生成器的实战评测: 关于硬件零售商发货流程的详细案例研究，展示人工智能如何处理网关、并行执行和泳道逻辑。
- AI BPMN 图生成器：专业业务流程设计工具: 中文版产品指南，详细介绍 AI 生成器的功能，包括自动包含池和泳道以实现跨职能清晰性。
- 我的亲身体验：利用 Visual Paradigm 的 AI 驱动 BPMN 改变工作流程文档: 关于 AI 生成器在员工入职、客户支持和贷款审批场景下表现的第一手评测。
- BPMN 2.0 商业流程建模新手实战指南：运用 Visual Paradigm 与 AI 轻松打造专业流程图: 实用教程，包含提示词编写策略及利用 AI 聊天机器人进行对话优化的高级技巧。
- BPMN 完整实战教程：Visual Paradigm 体验、AI 功能与生态系统深度指南: 一系列文章，涵盖人工智能驱动 BPMN 生成器的发布，深入探讨生态系统集成与实际案例。