业务流程模型与符号，或BPMN，是一种标准化的视觉语言，用于描述工作是如何完成的。它帮助业务分析师、管理人员、开发人员和流程参与者在不依赖冗长书面流程的情况下，理解同一流程。
BPMN图由四个主要类别构成：
-
流程对象：事件、活动和网关
-
连接对象：顺序流、消息流和关联
-
泳道：池和泳道
-
辅助元素：数据对象、分组和文本注释
本指南重点介绍最重要的一类：BPMN流程对象。流程对象描述了流程中发生的事情、执行的工作以及流程如何从一个路径转移到另一个路径。
1. 什么是BPMN流程对象？
流程对象是BPMN流程图的核心元素。它们通过顺序流连接，表示流程的行为。
共有三种类型：
| 流程对象 | 基本形状 | 主要目的 |
|---|---|---|
| 事件 | 圆形 | 发生的事情 |
| 活动 | 圆角矩形 | 执行的工作 |
| 网关 | 菱形 | 一个决策、分支、合并或同步点 |
一个简单的流程在概念上可能看起来像这样：
开始事件 → 活动 → 网关 → 活动 → 结束事件
例如：
收到订单 → 检查库存 → 该物品有货吗？
├── 是 → 发货
└── 否 → 通知客户
这些形状很简单，但它们内部的符号提供了额外的含义。
2. 事件：发生的事情
一个事件表示在流程过程中发生的事情。与活动不同，事件不是由人或系统执行的工作。它可以触发一个流程、中断一个活动、表示一个条件，或表明流程如何结束。
事件以圆圈表示。边框表示事件在流程中发生的地点：
| 事件类型 | 边框外观 | 含义 |
|---|---|---|
| 开始事件 | 细单线 | 表示流程如何开始 |
| 中间事件 | 双线 | 发生在开始和结束之间 |
| 结束事件 | 粗单线 | 表示流程路径如何结束 |
开始事件可以捕获触发器，例如传入的消息或预定的时间。中间事件可能等待或发送某些内容。结束事件产生流程路径的最终结果。
2.1 开始事件
一个开始事件表示启动流程或子流程的触发器。
它以带有细边框的圆圈绘制。
常见示例包括：
-
客户提交订单
-
员工提交请假申请
-
定时器到达预定日期
-
消息到达
-
系统检测到一个条件
-
创建了一个新案件
无开始事件
一个普通的开始圆圈表示流程在没有特定建模触发器的情况下开始。
○
示例：
○ → 审核申请
当确切的触发条件未知、无关或有意保持泛化时，使用无开始事件。
消息开始事件
开始事件内部的消息符号表示流程在收到消息时开始。
示例：
◉ 信封符号 → 处理客户请求
典型用例：
-
接收电子邮件
-
接收API请求
-
接收采购订单
-
接收来自另一参与者的请求
定时器开始事件
开始事件内的时钟表示该流程将根据计划或日期启动。
示例：
-
每月启动发票生成
-
在到期前30天启动续期流程
-
运行每日对账流程
条件开始事件
当业务条件变为真时，条件开始事件即启动。
示例：
库存水平低于补货点
信号开始事件
当接收到广播信号时，信号开始事件即启动。与消息不同，信号通常不会指向某个特定接收者。
示例：
接收“紧急关闭”信号 → 关闭所有分支机构
多重开始事件
多重开始事件表示多个不同的触发条件可以启动同一流程。
例如，支持案例可能在以下情况开始：
-
客户提交网页表单
-
代理手动输入案例
-
一个自动监控系统检测到一个问题
2.2 中间事件
一个中间事件在流程开始后、结束前发生。它可以暂停流程、等待某些事情、发送消息、创建异常路径，或响应某个条件。
它用双线边框绘制。
中间事件可以是：
-
捕获：等待或接收某些内容
-
抛出：发送或生成某些内容
捕获事件通常使用空心或轮廓标记，而抛出事件通常使用实心标记。
定时器中间事件
定时器事件表示延迟、截止日期、持续时间或重复计划。
示例：
-
等待三个工作日
-
等待到特定日期
-
如果24小时内没有收到回复，则升级处理
-
在流程运行期间执行重复操作
示例：
发送报价 → 等待3天 → 检查回复
消息中间事件
消息中间事件要么等待消息，要么发送消息。
示例：
发送审批请求 → 等待审批回复
当流程与另一个参与者、部门、组织或系统交互时，消息事件尤其有用。
错误中间事件
错误事件表示影响正常流程的错误条件。
它通常用作附加到活动或子流程的边界事件。
示例：
处理付款
│
└── 错误 → 处理付款失败
升级中间事件
升级事件表示某个问题需要在更高层级引起关注，但不一定代表技术故障。
示例：
处理客户投诉
│
└── 升级 → 主管审核
条件中间事件
条件事件会等待指定条件变为真。
示例：
等待客户账户验证通过
信号中间事件
信号事件会广播或接收一个可能与多个流程参与者相关的信号。
示例：
广播产品召回信号
链接中间事件
链接事件可以在同一流程图中的两个远距离点之间建立连接，而无需在页面上绘制一条长长的顺序流线。
应谨慎使用链接事件。它们可以提高流程图的可读性，但过度使用可能会使流程更难理解。
补偿中间事件
补偿事件会触发纠正工作，以撤销或补偿之前的一项活动。
示例：
取消酒店预订
补偿不同于普通的错误路径。它专门用于撤销或补偿已完成的工作。
2.3 边界事件
一个边界事件直接附着在活动或子流程的边缘上。它表示在该活动进行过程中可能发生的事情。
示例：
┌────────────────────┐
│ 流程应用 │
└────────────────────┘
○
│
└── 超时 → 升级案例
边界事件适用于建模：
-
超时
-
取消
-
错误
-
升级
-
传入消息
-
补偿
-
外部信号
中断边界事件
当发生中断边界事件时，会停止关联的活动。
示例：
处理付款
│
└── 付款错误 → 处理失败
错误发生时，付款活动结束。
非中断边界事件
非中断边界事件在原始活动继续进行的同时，启动一条额外的路径。
通常用虚线边框表示。
示例：
处理申请
│
└── 定时提醒 → 发送提醒
提醒路径运行时，申请流程继续进行。
这种区别很重要：
| 边界事件类型 | 对关联活动的影响 |
|---|---|
| 中断 | 停止活动 |
| 非中断 | 保持活动运行 |
2.4 结束事件
一个结束事件表示流程路径的结束。它被绘制为一个带有粗边框的圆圈。
一个流程可能有多个结束事件，因为不同的结果可能导致流程终止。
示例：
-
订单完成
-
请求被拒绝
-
支付失败
-
案件取消
-
客户已通知
-
流程以补偿方式完成
无结束事件
一个普通的结束事件表示该路径已结束，但未指定具体结果。
●
消息结束事件
当流程结束时，消息结束事件会发送一条消息。
示例：
订单已批准 → 发送确认 → 消息结束
错误结束事件
错误结束事件通过向更高级别的流程或处理程序抛出错误来结束流程。
用于必须在其他地方处理的流程级故障条件。
升级结束事件
升级结束事件结束当前流程路径，并表明已发生升级。
终止结束事件
终止结束事件立即结束整个流程实例，包括其他活动路径。
这比普通结束事件更强。当所有剩余工作都必须停止时，应使用它。
补偿结束事件
补偿结束事件在流程路径结束前触发补偿活动。
3. 活动：执行的工作
一个活动表示由个人、团队、系统或自动化服务执行的工作。活动以圆角矩形绘制。
示例包括：
-
审核申请
-
批准发票
-
发送确认
-
验证客户信息
-
计算运费
-
更新账户
-
生成报告
活动构成了BPMN图的操作核心，因为它们显示了时间、精力、成本和责任集中的地方。
3.1 活动命名
一个好的活动名称通常遵循以下模式：
动词 + 宾语
示例：
-
审核申请
-
批准发票
-
创建客户记录
-
验证付款
-
发送确认邮件
避免使用模糊的名称，例如：
-
处理
-
处理请求
-
步骤1
-
其他工作
-
管理
清晰的活动名称应描述一个动作及其对象。
| 名称较弱 | 更好的名称 |
|---|---|
| 处理中 | 处理付款 |
| 审核 | 审核申请 |
| 客户步骤 | 验证客户身份 |
| 电子邮件 | 发送批准邮件 |
| 更新 | 更新订单状态 |
任务通常表示一个不可再细分或不应再细分的工作单元。子流程表示一组相关的活动。
3.2 任务
一个任务是最简单的活动类型。它代表一个单一的工作单元。
一个基本任务以圆角矩形表示：
╭────────────────────╮
│ 审核申请 │
╰────────────────────╯
任务可能包含标识正在执行的工作类型的标记。
用户任务
用户任务由人类使用系统或应用程序完成。
示例：
-
审批费用报告
-
输入客户信息
-
审核合同
-
分配支持案例
手动任务
手动任务由人员在没有业务流程引擎或应用程序协助的情况下完成。
示例：
-
检查设备
-
签署纸质文件
-
包装实物产品
-
手动递送文件
服务任务
服务任务由系统、应用程序、Web服务或API自动执行。
示例：
-
获取信用评分
-
发送自动邮件
-
计算税款
-
创建数据库记录
-
调用支付服务
脚本任务
脚本任务在流程环境中执行脚本或代码片段。
示例：
-
转换数据
-
计算一个值
-
格式化消息
-
应用一个简单的数据规则
业务规则任务
业务规则任务通过规则引擎评估业务规则。
示例：
-
确定信用额度
-
计算保险费
-
决定订单是否符合免费配送条件
-
确定审批级别
发送任务
发送任务将消息发送给另一个参与者或系统。
示例：
-
发送发票
-
发送订单确认
-
发送通知到仓库
接收任务
接收任务等待来自其他参与者或系统的消息。
示例：
-
接收已签署的合同
-
接收付款确认
-
接收发货状态
3.3 子流程
一个子流程是一个包含更详细流程的活动。
它可以用两种方式表示：
-
折叠的子流程： 带有加号标记的圆角矩形
-
展开的子流程： 一个更大的圆角矩形，显示内部流程
当多个任务彼此关联，且如果在高层图中全部显示会使图表过于复杂时，应使用子流程。
示例：
╭──────────────────────────────╮
│ + 完成客户入职流程 │
╰──────────────────────────────╯
子流程可能包含：
收集信息
↓
验证身份
↓
创建账户
↓
发送欢迎消息
何时使用子流程
在以下情况使用：
-
一组步骤具有明确的业务目的
-
该组步骤在概念上可能被重复使用
-
主图正在变得拥挤
-
利益相关者需要同时具备概览和详细视图
-
内部流程具有自己的开始、结束、异常或决策逻辑
嵌入式子流程
嵌入式子流程在其父流程内部定义，是该流程流程的一部分。
调用活动
调用活动调用一个单独定义的可重用流程或全局任务。
当同一流程逻辑从多个位置被调用时使用，例如：
验证客户身份
如果客户验证出现在多个业务流程中，使用可重用的调用活动可能比复制其所有内部步骤更为合适。
事件子流程
事件子流程在包含它的流程或子流程处于活动状态时，由一个开始事件触发。它适用于处理异常或并行情况，例如取消请求、紧急升级或传入的更新。事件子流程可以是中断型或非中断型。
示例：
主流程：履行订单
事件子流程：
取消请求 → 取消履行 → 为客户退款
3.4 活动标记
活动可能包含一些小标记，用于添加有关其行为方式的信息。
循环标记
循环标记表示该活动会重复执行，直到满足某个条件为止。
示例：
审核文件
↻
用于以下类型的活动：
-
审核直至批准
-
尝试配送直至成功
-
联系客户直至联系上
并行多实例标记
这表示同一活动的多个实例同时运行。
示例：
获取三个批准
该活动可由多位审核人同时执行。
顺序多实例标记
这表示多个实例依次运行。
示例：
逐项审核项目
补偿标记
此标记标识用于补偿先前已完成工作的活动。
示例：
退款给客户
临时标记
临时子流程由类似波浪线的标记表示。它表明子流程内的活动可以以灵活或松散的顺序执行，而不是遵循单一固定顺序。
4. 网关：决策、分支与合并
一个网关用于控制流程的分支或汇聚方式。网关以菱形表示。
网关通常不是一个任务。它本身并不执行决策工作，而是表示在决策、条件或事件被评估后，流程如何被控制。
例如：
审核申请 → 申请是否完整？
审核活动用于收集或评估信息。然后，网关根据结果引导流程。
网关可以：
-
将一条路径拆分为多条路径
-
将多条路径合并为一条
-
同步并行工作
-
等待一个或多个事件
-
根据条件或规则引导工作
4.1 排他网关：异或
一个排他网关会选择恰好一条传出路径。
通常显示为一个包含“X”的菱形，尽管在某些图示中该标记可能被省略。
示例：
┌── 已批准 → 创建账户
检查申请 ─◇
└── 已拒绝 → 发送拒绝通知
只有一条路径会被执行。
典型用途：
-
如果支付获批，则继续；否则拒绝
-
如果客户符合条件，提供折扣
-
如果请求完整，则处理；否则退回
传出路径通常应具有明确的条件或标签：
-
已批准
-
已拒绝
-
完整
-
不完整
-
金额 > 10,000美元
-
金额 ≤ 10,000美元
排他合并
独占网关还可以将多个备选路径合并回一条路径。它不会等待所有路径，因为只有其中一个备选路径应该被采用。
默认流程
当所有指定条件都不成立时，可以使用默认路径。
例如：
批准
拒绝
默认 → 手动审核
默认路径适用于意外或未分类的情况。
4.2 并行网关：AND
一个并行网关将流程拆分为多个并行运行的路径。
它由一个包含加号的菱形表示。
示例：
┌── 准备发票 ──┐
订单批准 ─◇ ◇── 发货
└── 预留库存 ┘
两个活动同时开始，之后流程可能需要等待两者都完成。
并行拆分
并行拆分会启动所有输出路径。
当所有活动都必须发生，而不管条件如何时，使用它。
示例：
-
发送确认信息并更新库存
-
通知财务部门并通知运营部门
-
执行安全检查和欺诈检查
并行汇合
并行汇合会等待所有传入路径完成后再继续。
这有时被称为同步。
准备发票 ──┐
◇── 履行订单
预留库存 ┘
如果其中一个传入分支延迟，汇合将等待它。
4.3 包含网关：或
一个包含网关根据哪些条件为真，选择一个或多个传出路径。
它用一个包含圆的菱形表示。
示例：
客户符合以下条件：
- 标准折扣
- 忠诚度折扣
- 促销折扣
如果满足多个条件，可以选择多个与折扣相关的操作。
当满足以下情况时使用包含网关：
-
一个或多个条件可能为真
-
多个路径可以同时运行
-
所有选定路径完成后，流程应继续
与互斥网关不同，包含网关不一定只选择一条路径。与并行网关不同，它也不一定选择所有路径。
4.4 基于事件的网关
一个基于事件的网关根据首先发生的事件来引导流程。
它通常后接捕获的中间事件或接收任务。
示例：
发送报价 → 基于事件的网关
├── 消息收到 → 处理接受
└── 定时器超时 → 发送提醒
只有最先发生的事件决定流程路径。
当流程等待外部行为而非评估已知业务条件时，应使用基于事件的网关。例如，流程可能等待客户响应或超时。
基于事件的网关与排他网关
| 问题 | 排他网关 | 基于事件的网关 |
|---|---|---|
| 什么决定流程路径？ | 一个条件或业务规则 | 最先发生的事件 |
| 典型问题 | “请求是否已批准？” | “什么最先发生？” |
| 常见的后续元素 | 活动或序列流 | 捕获事件或接收任务 |
| 决策源 | 数据或逻辑 | 外部事件 |
4.5 复杂网关
一个复杂网关处理无法通过标准网关类型清晰表达的高级路由逻辑。
例如：
-
在收到至少两个审批后继续
-
根据复杂的条件组合选择路径
-
根据自定义规则同步选定的路径
应谨慎使用复杂网关。在许多情况下，使用多个更简单的网关或一个命名清晰的业务规则任务会更容易理解与维护。
4.6 基于事件的网关变体
BPMN 还支持基于事件的网关变体，包括：
-
互斥基于事件的网关
-
并行基于事件的网关
-
实例化基于事件的网关
并行基于事件的网关可能需要等待多个事件条件，而互斥基于事件的网关则根据第一个发生的事件继续执行。正确的变体取决于流程是等待单一事件还是多个事件的组合。
5. 流程对象如何协同工作
BPMN图的含义来自于事件、活动、网关和序列流之间的关系。
考虑一个订单流程：
开始
↓
接收订单
↓
检查库存
↓
商品可用吗？
├── 是 → 打包订单 → 发货订单 → 结束
└── 否 → 通知客户 → 结束
此示例包含：
-
一个开始事件用于启动流程
-
用于接收、检查、打包、发货和通知的活动
-
一个排他网关用于选择一条路径
-
两个结束事件或表示不同结果的结束路径
一个更高级的版本可能是：
开始
↓
接收订单
↓
检查库存
↓
商品可用吗？
├── 否 → 通知客户 → 结束
└── 是 → 并行网关
├── 预留库存
├── 准备发票
└── 检查欺诈
↓
并行汇聚
↓
发货订单
↓
结束
此处：
-
排他网关决定履行是否可以继续。
-
并行网关启动三项活动。
-
并行汇聚等待所有三项活动完成。
-
只有在同步完成后才开始发货。
6. 事件、活动和网关：快速比较
| 元素 | 关键问题 | 示例 |
|---|---|---|
| 事件 | 发生了什么或将会发生什么？ | 收到付款 |
| 活动 | 执行了什么工作？ | 验证付款 |
| 网关 | 流程应走哪条路径？ | 付款是否有效？ |
一个有用的规则是：
-
事件发生
-
活动被执行
-
网关控制路径
如果你不确定使用哪个符号，请问：
-
这是不需要作为工作处理而发生的吗？使用一个事件.
-
是否有人或某物正在执行一个动作？使用一个活动.
-
流程是否正在分叉、合并，或等待路由条件？使用一个网关.
7. 正确连接流程对象
流程对象通过不同类型的线条连接。使用错误的连接器可能会使图表产生误导。
7.1 顺序流
一个顺序流是一条带箭头的实线。它表示同一流程中流程对象的执行顺序。
活动 A → 活动 B
使用顺序流连接：
-
事件到活动
-
活动到网关
-
网关到活动
-
活动到结束事件
序列流通常不应跨越不同泳道之间的边界。
7.2 消息流
一个消息流是一条带空心箭头的虚线，表示不同参与者或泳道之间的通信。
示例：
-
客户向卖家发送订单
-
卖家向客户发送确认信息
-
银行向商户发送支付结果
使用消息流表示通信，而不是显示内部流程顺序。
7.3 关联
一个关联是用点线连接图元、注释或数据表示与流程对象的连接。
示例：
-
将文档附加到任务
-
将文本注释链接到活动
-
显示任务使用了数据对象
连接对象的三种主要类型是序列流、消息流和关联。
8. 泳道和泳道
尽管泳池和车道不是流程对象，但它们为理解每个活动由谁执行提供了重要背景。
泳池
泳池表示流程中的一个参与者。
示例：
-
客户
-
供应商
-
银行
-
公司
-
政府机构
-
外部系统
泳池可以包含整个流程，也可以以不显示内部细节的黑箱参与者形式呈现。
车道
车道根据责任、角色、部门、系统或位置对泳池进行划分。
示例：
-
客户服务
-
财务
-
仓库
-
经理
-
支付系统
车道有助于回答以下问题：
谁负责这项活动？
它们还可以揭示交接、延迟、重复工作和权责不清的问题。
9. 数据对象和其他支持元素
数据对象不是流程对象，但它们能提供关于活动中使用、创建或更改的信息的有用背景。
示例：
-
申请表
-
发票
-
采购订单
-
客户记录
-
审批文件
-
发货标签
数据对象可能以如下方式与活动连接：
申请表 → 审核申请
数据对象标识相关的信息，但并不一定代表流程处理的每一条数据。
其他支持元素包括：
-
数据存储：数据存储的持久位置
-
文本注释：解释性说明
-
分组：相关元素的视觉组织
-
关联：支持性元素与流程对象之间的链接
10. 建模流程的逐步方法
步骤1：定义流程范围
确定流程的起点和终点。
例如：
从：客户提交订单
到：订单已发货或被拒绝
避免在一个图中建模整个组织。
步骤2：识别参与者
列出涉及的人员、部门、系统或组织。
示例：
-
客户
-
销售团队
-
财务部门
-
仓库
-
支付网关
这些可能成为池或泳道。
步骤3：识别启动触发器
询问：
是什么导致这个过程开始的？
使用适当的开始事件：
-
消息
-
定时器
-
条件触发
-
信号
-
无
步骤4：列出主要活动
使用动词+宾语的格式写出每一项活动：
-
接收订单
-
验证订单
-
计算总额
-
批准付款
-
发货订单
在此阶段，不必担心每一个例外情况。
步骤5：添加决策
寻找如下问题：
-
订单是否完整？
-
付款是否已批准？
-
库存是否可用？
-
客户是否符合资格？
-
截止日期是否已过？
使用网关来表示答案如何影响流程。
步骤6：添加并行工作
识别可以同时发生的活动。
例如：
-
更新库存
-
发送确认
-
创建发票
当所有分支都必须完成或同步时，使用并行网关。
步骤7：添加中间事件和边界事件
询问在工作进行过程中可能发生什么：
-
该活动是否有截止日期？
-
它可以被取消吗？
-
可能会发生错误吗？
-
外部消息可能到达吗？
-
如果过程耗时过长，是否应升级？
步骤8：添加结束事件
识别所有有意义的结果：
-
已完成
-
已拒绝
-
已取消
-
失败
-
已升级
-
已补偿
步骤 9：添加数据和注释
仅在有助于理解的情况下才包含文档、系统、笔记和业务规则。
步骤 10：审查流程图
检查以下内容：
-
每个流程路径都有明确的起点
-
每个路径最终都会结束
-
网关条件是可理解的
-
活动有明确的负责人
-
顺序流显示实际顺序
-
消息流仅在参与者之间使用
-
没有网关被用作任务
-
流程图没有包含不必要的细节
11. 常见的BPMN建模错误
错误 1：将网关用作决策活动
网关应负责流程的路由，而不是执行分析。
弱模型：
◇ 检查信用评分
更好的模型：
检查信用评分 → 信用是否批准？
该活动执行检查。网关根据结果进行路由。
错误2：在独立的泳道之间使用顺序流
顺序流表示内部流程顺序。独立参与者之间的通信应使用消息流。
错误的概念：
客户泳道 ── 实线顺序流 ── 卖方泳道
更好的概念：
客户泳道 ── 虚线消息流 ── 卖方泳道
错误3：网关路径未标注
未标注的网关会造成歧义。
而不是：
◇ → 路径A
→ 路径B
使用：
◇
├── 批准
└── 拒绝
错误4：使用互斥网关处理并行工作
如果所有活动都必须发生，请不要使用互斥网关。
错误：
◇ ├── 发送确认
└── 更新库存
这意味着仅选择了一条路径。
如果两个活动都必须发生，请使用并行网关：
+ ├── 发送确认
└── 更新库存
错误5：对条件性工作使用并行网关
并行网关会激活所有出站路径。如果只有部分路径需要运行，请使用互斥网关或包含网关。
错误6：对每个微小操作都进行建模
如果包含每一次点击、字段输入和内部系统操作，图表可能会变得难以阅读。
根据受众的需求，选择合适的建模层级：
-
高管需要关注主要阶段
-
流程负责人需要了解职责和决策点
-
开发人员可能需要实现级别的细节
-
审计人员可能需要控制措施和证据
错误7：创建无法继续的路径
每个顺序流路径最终都应到达一个合适的结束事件，或一个明确界定的子流程边界。
错误8：不必要地混合业务逻辑和技术实现
业务流程图应首先解释流程。只有当技术细节有助于目标受众理解时，才应包含。
12. 实用的命名规范
一致的命名使图表更易于阅读。
事件
用结果、发生或条件来命名事件：
-
订单已收到
-
付款已确认
-
截止日期已到达
-
客户已取消
-
发生错误
活动
使用：
动词 + 宾语
示例：
-
审核合同
-
批准请求
-
更新账户
-
发送通知
网关
网关通常与一个问题关联时最为清晰：
-
申请是否已完成？
-
付款是否已批准？
-
库存是否可用？
-
截止日期是否已过？
出站路径应包含答案：
-
是 / 否
-
批准 / 拒绝
-
可用 / 不可用
结束事件
根据结果命名结束事件：
-
订单完成
-
请求被拒绝
-
支付失败
-
案件已取消
13. 选择正确的网关
使用此决策指南：
| 建模需求 | 应使用的网关 |
|---|---|
| 根据条件选择唯一一条路径 | 排他网关 |
| 启动每一条出站路径 | 并行网关 |
| 根据条件选择一条或多条路径 | 包含网关 |
| 遵循第一个发生的事件的路径 | 基于事件的网关 |
| 应用高度专业化的路由规则 | 复杂网关 |
一个快速的思维测试：
-
一条路径？ 排他性
-
所有路径？ 并行
-
某些路径？ 包含性
-
第一个事件？ 基于事件
-
不寻常的自定义逻辑？ 复杂
14. 完整示例：客户退款流程
考虑一个客户退款流程。
开始：收到退款申请
↓
审核退款申请
↓
申请是否符合资格？
├── 否
│ ↓
│ 发送拒绝通知
│ ↓
│ 结束：退款被拒绝
│
└── 是
↓
批准退款
↓
并行网关
├── 发放退款
└── 更新客户账户
↓
并行汇合
↓
发送退款确认
↓
结束：退款完成
此模型展示了：
-
一个消息开始事件
-
用户或手动活动
-
排他网关
-
拒绝路径
-
并行分支
-
并行汇聚
-
确认活动
-
不同的结束结果
如果退款服务可能失败，请添加一个边界错误事件到发出退款:
发出退款
│
└── 错误 → 创建手动审核案例
如果退款必须在五个工作日内完成，请添加一个边界定时器事件：
发出退款
│
└── 5天超时 → 升级退款
15. 精简版BPMN符号速查表
| 符号类别 | 含义 | 典型用途 |
|---|---|---|
| 细圆圈 | 开始事件 | 开始一个流程 |
| 双圈 | 中间事件 | 等待、发送、接收或响应 |
| 粗圈 | 结束事件 | 完成一个流程路径 |
| 圆角矩形 | 任务或活动 | 执行工作 |
| 带加号的圆角矩形 | 折叠的子流程 | 分组详细工作 |
| 带X的菱形 | 排他网关 | 选择一条路径 |
| 带加号的菱形 | 并行网关 | 运行所有路径 |
| 带圆圈的菱形 | 包含网关 | 运行一个或多个路径 |
| 带有事件标记的菱形 | 基于事件的网关 | 遵循第一个事件 |
| 实线箭头 | 序列流 | 显示内部顺序 |
| 虚线箭头 | 消息流 | 显示通信 |
| 点线连接器 | 关联 | 链接注释或数据 |
| 池 | 参与者 | 表示一个组织或流程 |
| 泳道 | 角色或职责 | 分配所有权 |
| 文档/数据形状 | 数据对象 | 显示使用或生成的信息 |
16. 最终建模原则
最有效的BPMN图遵循一些基本原则：
-
使用事件表示发生的事情。
-
使用活动表示人员或系统执行的工作。
-
使用网关来控制或同步路径。
-
使用顺序流表示内部流程顺序。
-
使用消息流表示参与者之间的通信。
-
清晰地标明决策和外出条件。
-
使用子流程来控制复杂性。
-
使用池和泳道表示责任。
-
使用边界事件表示超时、错误和中断。
-
根据受众水平进行建模。
-
为每个有意义的路径设定明确的结果。
-
优先选择简单易懂的图表，而非过于复杂的图表。
一旦这三大核心概念变得熟悉——事件发生，活动被执行，网关控制流程——大多数BPMN图将变得更容易阅读和创建。