Business Process Diagrams

导言

业务讨论中最常见的误区，不是图画得不够漂亮，而是用一张图回答了错误的问题。想确认执行步骤，却画满参与者和消息；想追踪订单状态，却用时序图枚举所有异常；想划分责任，却把普通泳道当作 BPMN 执行语义。

本文用同一个“电商订单履约”案例做受控比较：业务事实不变，只改变观察轴。流程图看步骤，BPMN 看参与者、事件和规则，泳道图看责任与系统，状态机看订单生命周期，时序图看系统调用。读完后，应该先能选择合适的图，再决定用什么工具绘制。

先说结论

这五类图并不是从“简单”到“高级”的升级关系。它们更像五个镜头：对准同一段业务，
但每个镜头只让一种变化成为主角。

业务问题	首选图	图中主要变化	最容易遗漏的内容
事情按什么步骤执行	流程图	步骤与分支	责任人、正式事件语义
业务由哪些参与者、事件和规则驱动	BPMN	流程令牌、事件、消息、网关	实现级 API 与数据结构
每一步由谁负责、在哪个系统执行	泳道图	责任交接	严格事件与执行语义
一个对象如何在状态间变化	状态机	对象状态	跨系统调用细节
多个系统如何按顺序调用	时序图	消息与响应	对象的完整生命周期

{ width=100% }

自绘小黑示意图：小黑转动观察筒，订单没有改变，改变的是提问方式和模型中的主角。

选择图的第一问不是“我会画哪种图”，而是“读者现在缺少哪一种确定性”。 如果读者
不知道下一步，画流程图；不知道谁负责，画泳道图；不知道超时和异常怎样改变业务，画
BPMN；不知道订单能否从当前状态执行某操作，画状态机；不知道一次请求经过哪些服务，
画时序图。

允许同时画两张

复杂系统通常需要一张业务视图和一张实现视图。例如先用 BPMN 约定“支付成功消息触发履约”，再用时序图说明支付回调如何经过网关、订单服务和仓储服务。两张图共享术语和事件即可，不必把所有信息挤进一张“万能图”。

先看图中什么在变化

比较方法图时，最有效的判断标准是图中被追踪的对象。如果这个对象没有选清，节点
很快会混入动作、状态、角色、系统和数据，箭头也会同时表示“下一步”“调用”“负责”
和“状态变化”。图看起来信息丰富，实际无法验证。

以“用户下单”为例：

• “检查库存之后发起支付”描述的是工作步骤；
• “支付超时事件使流程走向取消”描述的是业务过程语义；
• “库存锁定由订单中心发起、仓储系统执行”描述的是责任交接；
• “待支付在支付成功后变为已支付”描述的是对象状态；
• “订单服务调用库存服务并等待响应”描述的是消息交互。

这五句话都正确，却不能随意使用同一种箭头。本文后面的五张示意图固定使用相同案例，
让差异只来自建模视角。所有技术图都是依据 ISO/OMG 规范绘制的教学简化图，不是某个
生产系统的完整实现。

流程图

流程图回答“接下来做什么”。 ISO 5807 为数据、程序和系统流程图定义了符号与使用
约定；实践中最常见的最小词汇是起止、处理步骤、输入输出、判断和连接箭头。[^iso5807]

它适合操作说明、审批步骤、故障排查、用户旅程的主路径，以及尚未稳定到需要正式过程
语义的早期讨论。直觉上，流程图是在一条路上放路标：读者沿箭头前进，在菱形处回答
问题，再进入下一条路径。

输入：业务起点、完成条件、关键步骤、分支条件
1. 把每个动作写成“动词 + 对象”
2. 按先后关系连接主路径
3. 只在会改变后续路径时增加判断
4. 为每个判断写出互斥且完整的出口条件
5. 让每条路径到达明确终点或回到一个已命名步骤
输出：可从起点逐箭头走到终点的步骤模型

{ width=100% }

自绘示意图：流程图突出步骤与判断。注意“库存是否充足”改变后续路径，但图中没有表达哪个团队或系统负责。

这张图应该从左到右阅读：用户提交订单后检查库存；库存不足直接结束，库存充足则进入
支付；支付成功后创建出库单并完成履约。它保留了顺序和分支，主动省略参与者、系统
边界、消息类型和订单状态。

• 优势：学习成本低，主路径清晰，适合快速对齐“先做什么、后做什么”。
• 劣势：复杂异常、并行、等待和跨组织消息一多，箭头会迅速膨胀；责任边界往往靠
  文字猜测。
• 适用边界：当讨论重点转向事件、补偿、参与者或可执行语义时，应升级为 BPMN；
  当争议集中在“谁做”，应改用泳道。
• 效果边界：它减少的是步骤顺序歧义，代价是压低组织、状态和实现细节；没有对照
  评审，不能声称它会定量降低缺陷。
• 实现归属：由流程负责人维护即可，不依赖特定绘图工具；迁移工具时主要成本是符号
  和链接重建，不是业务语义重写。

BPMN

BPMN（Business Process Model and Notation，业务流程模型与标记）回答“业务过程为何在
此刻沿这条路继续”。 OMG 将它定义为业务过程的标准图形标记：既要让业务人员理解，
又要为技术人员提供更精确的过程语义。BPMN 2.0.2 也是 ISO/IEC 19510。[^bpmn-home]

流程图的中心是“步骤”，BPMN 的中心则是由活动、事件、网关、顺序流、消息流和参与者
共同约束的过程。一个圆形事件可以表示消息到达、定时器到期或错误；一个网关可以基于
数据或事件选择路径；Pool 表示参与者，跨 Pool 的虚线消息流表示参与者之间的通信。

输入：参与者、业务起止事件、任务、等待事件、分支规则、跨参与者消息
1. 为独立参与者建立 Pool；在需要时用 Lane 细分内部角色
2. 在每个 Pool 内放置开始事件、任务、网关和结束事件
3. 用顺序流连接同一 Pool 内的执行路径
4. 用消息流连接不同 Pool 之间的发送与接收
5. 把超时、错误、补偿或取消绑定到真正受影响的任务
6. 检查每个网关出口和每个异常路径是否有明确终点
输出：参与者、事件与规则共同驱动的业务过程模型

{ width=100% }

自绘 BPMN 教学简化图：实线是 Pool 内的顺序流，虚线是参与者间消息流；支付等待附着定时事件，超时会走向取消。

图中客户、商家和支付平台是三个参与者。商家创建订单后向支付平台发出支付请求；支付
结果通过消息返回。等待支付的任务上附着定时边界事件，因此“15 分钟未支付”不是普通
判断框，而是一个在等待期间可能发生的事件。支付成功进入履约，超时则取消订单。

OMG 的入门说明明确区分了 Pool 与 Lane：Pool 代表参与者，Lane 是 Pool 内的子分区；
顺序流不能跨 Pool，而消息流用于参与者之间的通信。[^bpmn-intro] 这也是 BPMN 与普通
泳道图最关键的边界：BPMN 的线条不仅帮助排版，还携带规定的过程语义。

• 优势：适合跨组织、等待、异常、补偿、并行和消息驱动过程；符号语义比普通流程图
  更可检验。
• 劣势：学习与评审成本最高；如果团队只需要五步操作说明，完整 BPMN 会制造不必要
  的精度。
• 适用边界：用于业务分析、流程治理、合规、工作流自动化设计。API 参数、事务边界
  和数据库字段仍应交给时序图、接口契约或数据模型。
• 效果边界：它降低的是参与者、事件和异常处理的语义歧义；新增成本是符号培训、模型
  治理和版本维护。
• 实现归属：业务分析师或流程架构师维护过程语义，领域负责人确认规则，自动化团队
  再映射到具体引擎。换引擎不应改变业务模型，但可执行子集往往需要重新适配。

泳道图

泳道图回答“谁在什么边界内做这一步”。 它把画布切成角色、部门、组织或系统的平行
区域，动作必须落在一个明确的 Lane 中，跨 Lane 的箭头就是一次责任或信息交接。

OMG 的 BPMN 入门材料把 Lane 与传统泳道建模联系起来，并指出 Lane 常用于按公司职能
或角色分隔活动。[^bpmn-intro] 但本文所说的“普通泳道图”是一种责任导向的布局方法：
除非明确采用 BPMN 元素和规则，否则它不自动拥有 BPMN 的消息、事件和执行语义。

输入：业务步骤、责任主体、执行系统、交接点
1. 选择一个稳定的分区维度：角色、部门或系统
2. 为每个步骤指定唯一主责 Lane
3. 在步骤名称中写明动作，在 Lane 名称中写明责任边界
4. 按时间连接步骤，并标记跨 Lane 的交接物
5. 检查每个交接是否有发送方、接收方和完成条件
输出：能追责、能定位系统边界的交接模型

{ width=100% }

自绘示意图：每条泳道同时标明责任主体与执行系统，箭头突出订单、支付结果和出库单在边界间的交接。

示例把客户/小程序、订单中心/OMS、支付平台和仓库/WMS 分成四条 Lane。读者可以立刻
看到“库存校验”和“创建出库单”不在同一系统，也能定位支付成功后由谁把结果交回订单
中心。图中没有引入定时器或补偿语义，因为它的首要任务是让责任和系统归属可见。

• 优势：交接点、职责空洞和重复负责非常醒目；适合 SOP、RACI 讨论、跨部门协作和
  系统边界梳理。
• 劣势：Lane 太多时横向或纵向跨度很大；如果一张图同时按“部门”和“系统”分区，
  会产生二维责任混淆。
• 适用边界：当责任是核心问题时使用。若问题是“超时后发生什么”，补 BPMN；若问题
  是“服务怎样调用”，补时序图。
• 效果边界：它减少的是主责和交接歧义，新增成本是持续维护组织与系统变化；组织架构
  频繁变动时，图会比业务规则更快过期。
• 实现归属：流程 Owner 维护步骤，组织负责人和系统 Owner 共同确认 Lane；迁移成本
  主要来自责任调整，不来自绘图语法。

状态机

状态机回答“这个对象现在允许发生什么，以及事件后会变成什么”。 UML 2.5.1 将行为
状态机描述为由 Region、Vertex 和 Transition 组成的图，匹配的事件触发状态迁移；一个
稳定 State 会保持到某个事件启用迁移或状态机终止。[^uml]

这里的主角不是工作步骤，而是一个有身份的领域对象，例如订单、工单、合同、设备或
账户。迁移标签通常写成 事件 [守卫条件] / 动作：事件解释为什么尝试迁移，守卫条件
决定是否允许，动作描述迁移时产生的效果。

输入：对象、稳定状态、外部事件、守卫条件、迁移动作、终止状态
1. 只保留会改变允许行为的稳定状态
2. 为每个状态列出可接受事件
3. 为每个事件写出目标状态与必要守卫条件
4. 把副作用写在迁移动作上，不把短暂步骤伪装成状态
5. 检查非法迁移、重复事件、超时和失败后的去向
6. 确认每个终止状态是否真的不可继续
输出：给定当前状态和事件即可判断下一状态的生命周期模型

{ width=100% }

自绘 UML 状态机教学简化图：订单是唯一主角，箭头标签使用“事件 [条件] / 动作”，终态表示正常完成、取消或退款结束。

订单创建后进入待支付；支付成功进入已支付，超时或主动取消进入已取消；履约路径依次经过
拣货中、已发货和已完成；已支付或已完成的订单在满足售后条件时可以进入退款中，最终
成为已退款。图中没有表达订单服务如何调用仓储服务，因为一次状态迁移可能由多种实现
完成。

动作不是状态

“调用支付接口”“发送短信”“写数据库”通常是动作，不是稳定状态。判断方法是：如果没有新事件到来，对象会在这里持续停留吗？若不会，它更可能属于迁移动作、流程步骤或时序消息。

• 优势：适合权限校验、幂等、乱序事件、重试和非法操作分析；能够直接支持领域对象
  的状态约束与测试用例设计。
• 劣势：对象一多就需要多张状态机；跨对象协作和具体调用路径并不直观。
• 适用边界：用于订单、工单、合同、审批、设备和会话等长生命周期对象。纯线性操作
  清单不必强行建状态机。
• 效果边界：它降低的是合法状态与迁移规则的歧义；新增成本是处理状态爆炸、并发事件
  和历史数据迁移。
• 实现归属：领域 Owner 定义状态语义，服务 Owner 将其映射到代码、数据库和事件；
  更换框架通常不改变状态模型，改变业务政策则必须迁移模型与存量对象。

时序图

时序图回答“谁先给谁发了什么消息，之后发生了什么”。 UML 把 Interaction 定义为
围绕 Lifeline 间消息传递建立的行为模型；Sequence Diagram 是最常见的交互图变体，重点
是多个 Lifeline 之间的消息交换。[^uml]

时间从上向下推进，每条 Lifeline 表示一个参与者在该交互中的生命线，横向箭头表示请求、
响应或异步消息。UML 规范特别说明：纵向距离只表示事件先后和非零时间经过，不是可按
比例读取的真实耗时。[^uml]

输入：参与者、触发请求、同步调用、异步消息、返回值、条件分支
1. 从左到右排列参与者，并明确系统边界
2. 从触发消息开始，按实际发生顺序向下添加消息
3. 区分同步请求、返回和异步通知
4. 用 alt、opt 或 loop 框表示条件、可选和重复交互
5. 在消息上写业务意图或接口名，在必要处标明关键数据
6. 以可观察响应、事件发布或失败结束本次交互
输出：可逐消息核对实现路径的交互轨迹

{ width=100% }

自绘 UML 时序图教学简化图：从用户端到订单、库存、支付和仓储服务，消息按时间自上而下排列；alt 框隔离库存不足分支。

示例从用户端调用订单服务开始。订单服务先让库存服务预占库存，再向支付服务创建支付单；
支付成功回调订单服务，订单服务更新状态并异步通知仓储服务。库存不足路径在 alt 框内
直接返回失败，因此不会继续创建支付单。

• 优势：能把跨服务调用、同步/异步边界、返回、回调和条件路径放到同一时间轴上；
  适合接口评审、故障定位和集成测试设计。
• 劣势：参与者和分支增加后会很宽、很长；它展示的是一个或若干场景轨迹，不天然
  覆盖对象的全部合法生命周期。
• 适用边界：用于 API、RPC、消息队列、回调、缓存和数据库交互。组织责任和长期状态
  应分别由泳道图和状态机补充。
• 效果边界：它减少的是调用顺序和交互契约歧义；新增成本是与实现版本同步，接口重构
  后图容易失真。
• 实现归属：系统架构师或服务 Owner 维护，接口提供方和调用方共同评审；迁移到新架构
  时通常需要重画参与者与消息路径。

不能互相替代

最常见的错误是把图的外形当作语义。例如，BPMN 也有 Lane，所以看起来像泳道图；状态机
也有方框和箭头，所以看起来像流程图；时序图也按时间排列，所以看起来像竖向流程图。
真正的差异不在外形，而在哪些元素拥有规定含义，以及模型允许验证什么问题。

比较维度	流程图	BPMN	泳道图	状态机	时序图
核心对象	步骤	业务过程	责任交接	单个对象	交互消息
时间表达	先后	先后、等待、事件	先后与交接	事件驱动迁移	自上而下的偏序
参与者	可选文字	Pool/Lane 有语义	Lane 是中心	通常不是中心	Lifeline 是中心
异常表达	分支	边界事件、错误、补偿	交给谁处理	失败事件与状态	alt/opt、错误响应
适合验证	路径是否完整	过程语义是否闭合	是否有人负责	迁移是否合法	调用顺序是否一致
主要风险	箭头爆炸	过度建模	Lane 维度混乱	状态爆炸	场景过长、版本漂移

选择时可以使用一个最小决策表：

当前争议句式	应建模的对象	推荐图
“然后做什么？”	步骤	流程图
“谁的事件让流程继续？”	过程令牌与事件	BPMN
“到底谁负责？”	责任交接	泳道图
“现在能不能退款？”	订单状态	状态机
“回调先于库存确认会怎样？”	消息顺序	时序图

从一次访谈产出五张图

五种图可以共享事实，但不应该共享全部元素。一个实用做法是先建立业务事实表，再按
问题投影出不同视图：

1. 固定范围：确定起点、终点、主对象和外部参与者。本文的范围是“提交订单到履约
   完成或终止”。
2. 收集事实：记录动作、责任人、执行系统、触发事件、规则、对象状态、输入输出和
   交互消息，不急着画图。
3. 先画主路径：用流程图确认最小可读路径，避免一开始陷入符号争论。
4. 按风险加视图：跨组织和异常风险高时补 BPMN；责任争议高时补泳道；对象一致性
   风险高时补状态机；集成风险高时补时序图。
5. 做交叉校验：状态机中的“支付成功”应能在 BPMN 中找到事件，在时序图中找到消息；
   泳道图中的每个交接应能回到一个明确任务或调用。

最后用下面的检查清单防止多图互相矛盾：

• 同一业务对象使用同一名称，不在不同图中混用“订单”“交易单”“履约单”；
• 同一事件使用同一时态，例如统一写“支付成功”，不混用“已支付”和“支付完成通知”；
• 每个异常在至少一张图中有明确终点或恢复路径；
• 每个跨 Lane 交接至少对应一个交付物、消息或完成条件；
• 每个状态迁移都能追溯到业务事件，关键系统消息也能映射到业务含义；
• 图上省略的内容写在图注或边界说明中，不让读者误以为“不存在”。

常见误区

• 把节点名称写成名词：流程步骤应写“校验库存”，不是“库存”；状态才适合用“待支付”
  这类稳定名词。
• 一根箭头表达四种关系：下一步、调用、消息、责任交接应使用各自视图的语义，不要
  靠颜色让读者猜。
• 泳道同时混合部门和系统：如果确实要同时表达，像本文一样在 Lane 名称中明确写成
  “责任主体 / 执行系统”，并保持整个图一致。
• 把 BPMN 当作漂亮流程图：用了圆圈和菱形不等于 BPMN；Pool、Lane、顺序流、消息流
  和事件的边界必须一致。
• 追求一张图覆盖一切：信息越多不等于模型越强。图不能让读者回答一个明确问题，
  就应该拆分。

万能图通常不可验证

如果同一个方框有时表示步骤、有时表示系统、有时表示状态，那么任何箭头都可以被事后解释，模型也就无法用于评审。宁可维护两张共享术语的小图，也不要维护一张语义漂移的大图。

总结

流程图、BPMN、泳道图、状态机和时序图的差别，本质上是五种建模承诺：分别承诺把
步骤、业务过程、责任交接、对象状态和消息顺序说清楚。它们可以共享同一组业务事实，
却不能共享一套含混箭头。

最终选择规则很简单：先写下读者必须回答的问题，再识别图中持续变化的对象。 只要
这两步明确，图的类型通常会自然浮现；绘图工具、颜色和版式都只是后续实现。

参考资料

[^iso5807]: ISO, ISO 5807:1985 — Information processing — Documentation symbols and conventions for flowcharts. ISO 目录显示该版本于 1985 年发布，并在 2019 年复审确认。
[^bpmn-home]: Object Management Group, Business Process Model and Notation 2.0.2 与 BPMN overview.
[^bpmn-intro]: Object Management Group, Introduction to BPMN, pp. 3–4。该材料用于说明 Pool、Lane、Sequence Flow 与 Message Flow 的边界。
[^uml]: Object Management Group, Unified Modeling Language 2.5.1, Clause 14（StateMachines）与 Clause 17（Interactions）。