BPMN 与流程图：初学者何时以及为何使用 BPMN

流程图和 BPMN 图都展示了工作如何从一个步骤推进到另一个步骤。主要区别在于目的和精确性:

• 一个流程图是一种用于展示逻辑、步骤和决策的通用图表。

• BPMN，即业务流程模型与符号，是一种专门用于建模业务流程、职责、事件、消息、数据和自动化的标准化语言。

流程图通常是解释简单程序的最快方式。当流程涉及多人、多个部门、多个组织、异常处理、截止日期或软件系统时，BPMN 则更为有用。

BPMN 由对象管理组（Object Management Group）作为正式规范进行维护。其符号设计旨在让业务利益相关者易于理解，同时保持足够的精确性以支持技术实现。当前广泛使用的正式规范版本是 BPMN 2.0.2。

1. 什么是流程图？

流程图是对一系列步骤的可视化表示。它使用由箭头连接的简单形状，展示任务或决策如何推进。

典型的流程图包括：

• 椭圆形：开始或结束

• 矩形：过程或活动

• 菱形：决策

• 箭头：流向

• 平行四边形：输入或输出

• 文档形状：文档或报告

例如，一个基本的费用报销流程图可能如下所示：

开始
  ↓
员工提交费用报销单
  ↓
经理审核报销单
  ↓
是否批准？
 ├── 否 → 将报销单退回给员工
 └── 是 → 财务部门发放付款
  ↓
结束

流程图易于创建和理解，因为它们使用少量熟悉的符号。它们适用于：

• 解释简单程序

• 记录算法

• 描述故障排除步骤

• 绘制个人或部门工作流程

• 培训员工

• 展示基本决策序列

主要限制在于传统流程图并不总能清晰地表示谁执行每项任务, 不同组织之间如何沟通，或当事件中断正常流程时会发生什么.

2. 什么是 BPMN？

BPMN 代表业务流程模型与符号。它是一种用于以一致方式描述业务流程的标准符号。

BPMN 图表可以表示：

• 活动与任务

• 开始、中间和结束事件

• 决策与分支逻辑

• 并行工作

• 参与者与职责

• 部门或组织之间的沟通

• 消息

• 数据输入与输出

• 计时器、错误、取消和升级

• 可重用的子流程

• 人工与自动化活动

BPMN 基于流程图概念，但为业务操作提供了更丰富的词汇。其核心类别包括流对象、连接对象、泳道和工件。

简化的 BPMN 流程可描述为：

客户提交订单
        ↓
销售系统记录订单
        ↓
仓库检查库存
        ↓
商品是否有货？
 ├── 否 → 通知客户
 └── 是 → 拣货并打包订单
                 ↓
           物流服务商交付订单

在实际的 BPMN 图中，每个参与者可以出现在独立的池或泳道中，它们之间的通信可以通过消息流来表示。

3. BPMN 与流程图一览

特性	流程图	BPMN
主要用途	展示一般逻辑或顺序	建模业务流程
标准化	通常为非正式或特定于工具的	正式的国际建模符号
学习曲线	低	中等
符号数量	少量	更大、更专业的词汇
角色与职责	通常有限	通过池和泳道明确表示
跨组织通信	难以精确展示	通过消息流表示
异常与中断	通常简化	事件可表示计时器、错误、消息和升级
并行活动	可能但不清晰	通过并行网关支持
自动化支持	有限	可以详细到足以支持实施
最佳用途	简单的流程和逻辑	复杂、协作性、可重复的流程
典型受众	普通用户、学生、团队	分析师、流程所有者、开发人员、经理
详细程度	低至中等	中等至非常高

4. 核心区别：通用逻辑与业务流程语义

最重要的区别在于，流程图主要回答：

“接下来会发生什么？”

BPMN 可以回答几个额外的问题：

• 谁执行每项活动？

• 涉及哪个部门或组织？

• 交互是内部还是外部？

• 下一步是由消息、计时器、错误还是条件触发的？

• 活动是否可以并行发生？

• 需要哪些数据？

• 如果流程失败会发生什么？

• 哪些任务由人员、系统或规则执行？

• 该流程是否可以自动化或监控？

例如，流程图可能会说：

审查申请 → 批准申请 → 发送确认

BPMN 模型可以区分：

• 客户提交申请。

• 客户服务团队对其进行验证。

• 自动系统检查信用信息。

• 经理审批超过一定金额的申请。

• 计时器在三个工作日后触发提醒。

• 向客户发送一条消息。

• 错误路径处理缺失的文档。

流程图传达概要，BPMN 传达操作结构。

5. 初学者需要掌握的主要 BPMN 元素

BPMN 包含许多符号，但初学者最初只需掌握一小部分核心符号。

事件

事件代表发生的事，而非某人执行的动作。

它们以圆形绘制。

常见类型包括：

• 开始事件：启动一个流程

• 中间事件：在流程过程中发生

• 结束事件：完成一个流程

• 消息事件：接收或发送一条消息

• 计时器事件：涉及截止日期或预定时间

• 错误事件：发生错误

• 升级事件：某事项需要更高层级的关注

示例：

• 客户下订单。

• 付款截止日期到期。

• 收到一封电子邮件。

• 发生系统错误。

活动

活动表示正在执行的工作。它们以圆角矩形绘制。

它们可以是：

• 任务： 独立的工作单元

• 子流程： 相关活动的集合

• 用户任务： 由人员通过系统完成的工作

• 服务任务： 由软件自动执行的工作

• 手动任务： 在无系统辅助下执行的工作

• 业务规则任务： 由业务规则或决策服务确定的工作

对于初学者来说，最重要的概念很简单：

事件发生；活动被执行。

网关

网关控制流程的分支或合并方式。它们以菱形绘制。

常见的网关类型包括：

• 排他网关： 仅选择一条路径

• 并行网关： 多条路径同时发生

• 包容网关： 可选择一条或多条路径

• 基于事件的网关： 下一条路径取决于哪个事件首先发生

排他决策示例：

是否已收到付款？
 ├── 是 → 发货
 └── 否 → 发送付款提醒

并行工作示例：

订单已批准
      ↓
 ┌───────────────┬────────────────┐
 │               │                │
打包订单      准备发票      通知客户
 │               │                │
 └───────────────┴────────────────┘
      ↓
订单已准备好发货

顺序流

实线箭头表示同一流程中活动、事件和网关的发生顺序。

任务 A → 任务 B → 任务 C

消息流

虚线箭头表示不同参与者或池之间的通信。

例如：

客户 ──消息──> 公司
公司 ──确认──> 客户

消息流与顺序流不同：

• 顺序流：显示流程内的工作顺序

• 消息流：显示参与者之间的通信

池与泳道

泳道按参与者或职责组织工作。

• 一个池通常代表一个参与者、组织、业务实体或独立流程。

• 一个泳道将池划分为角色、团队、部门或系统。

示例：

客户泳道：提交订单 ─────────────── 接收确认
                         │                              ↑
销售泳道：审核订单 ─────── 发送确认

池与泳道回答了流程中最关键的问题之一：

谁负责此步骤？

数据对象与注释

数据对象显示活动所使用的或产生的信息。

示例：

• 申请表

• 发票

• 合同

• 客户记录

• 运单标签

注释添加解释性文本，但不改变流程逻辑。

6. 何时流程图是更好的选择

当流程简单、线性或主要涉及决策时，请使用流程图。

在以下情况下，流程图通常已足够：

• 只有一个主要参与者

• 流程仅包含少数步骤

• 无需强调职责

• 不存在与外部方的复杂交互

• 该图表用于快速说明

• 流程正在被非正式地探讨

• 您正在记录算法或故障排除流程

• 您的受众不熟悉 BPMN

例如，“如何重置密码”可能更适合用简单的流程图表示：

开始
  ↓
输入用户名
  ↓
找到账户？
 ├── 否 → 显示错误
 └── 是 → 发送重置邮件
                ↓
          用户创建密码
                ↓
               结束

除非目的是对完整的服务操作进行建模（包括身份验证、通知、系统任务、升级和审计记录），否则为此流程使用 BPMN 可能会增加不必要的复杂性。

7. 何时 BPMN 是更好的选择

当您需要对真实业务流程进行建模，而不仅仅是描述一个序列时，请使用 BPMN。

当流程具有以下特征时，BPMN 尤为有用：

• 涉及多个部门

• 涉及多个角色或参与者

• 涉及客户、供应商、监管机构或合作伙伴

• 团队之间的交接

• 并行活动

• 外部消息

• 计时器或截止日期

• 错误或异常处理

• 审批层级

• 自动化系统任务

• 合规要求

• 重复的流程改进工作

• 工作流自动化的未来目标

典型的BPMN用例包括：

• 采购订单审批

• 贷款申请处理

• 保险理赔

• 员工入职

• 客户支持升级

• 发票处理

• 产品退货

• 医疗转诊

• 合同审查

• 发货履行

• 监管报告

• 软件部署工作流

一条有用的规则是：

如果流程跨越了边界——在人员、团队、系统或组织之间——通常值得考虑使用BPMN。

8. 为什么要使用BPMN？

共享语言

不同群体往往以不同方式描述同一流程。业务经理可能谈论审批，开发人员谈论服务，而员工谈论日常任务。

BPMN提供了一种通用的可视化语言，可帮助这些群体讨论同一流程。其设计目标是既可供业务利益相关者使用，又足够精确，能够转化为软件流程组件。

明确的责任归属

泳道使责任可见。

不显示：

审查申请 → 批准申请 → 创建账户

BPMN可以显示：

• 客户提交申请

• 客户服务验证信息

• 信贷团队进行评估

• 经理批准例外情况

• IT 系统创建账户

这可以揭示重复工作、职责不清以及不必要的交接。

更优的异常分析

许多实际流程并不遵循理想路径。BPMN 使得建模更加容易：

• 信息缺失

• 被拒绝的申请

• 截止日期已过

• 支付失败

• 系统错误

• 取消操作

• 客户升级投诉

• 补偿或纠正措施

流程图可以显示异常，但 BPMN 提供了专门的事件类型和约定，以便更清晰地表示它们。

支持自动化

BPMN 模型可以包含足够的细节以指导工作流实施。并非每个 BPMN 图表都可执行，但当模型后续可能用于配置或设计自动化流程时，BPMN 比基本流程图更合适。

例如，流程设计师可能会区分：

• 由员工执行的任务

• 由自动化服务执行的任务

• 由业务规则评估的决策

• 从其他系统接收的消息

• 触发操作的计时器

改进流程优化

BPMN 图表可以帮助识别：

• 瓶颈

• 冗长的审批链

• 重复的数据录入

• 不必要的审查

• 适合自动化的手动任务

• 缺失异常路径

• 过多的交接环节

• 职责不清

• 由外部方导致的延误

这使得 BPMN 不仅对记录流程有价值，还对分析和重新设计流程有价值。

9. BPMN 的缺点

BPMN 功能强大，但并非总是最佳选择。

学习曲线更陡峭

流程图通常可以立即理解。BPMN 则要求用户学习诸如以下的区别：

• 顺序流与消息流

• 事件与活动

• 池与泳道

• 排他网关与并行网关

• 中断事件与非中断事件

• 捕获事件与抛出事件

图表可能变得杂乱

大型 BPMN 图表可能包含数十个符号和交叉线条。设计不良的模型可能比简单的流程图更难理解。

精确性可能产生虚假信心

使用 BPMN 符号并不能自动使流程模型准确。模型仍依赖于流程所有者和领域专家提供的正确信息。

并非所有受众都需要完整细节

高层管理者可能希望获得高层级的流程概览，而工作流开发人员可能需要详细的任务和异常信息。一张图表很少能完美地同时满足这两种目的。

可能被过度使用

一个五步的内部流程不一定需要消息事件、多个池和嵌套子流程。符号表示应与问题相匹配。

10. 实用决策指南

使用以下问题在流程图和 BPMN 之间做出选择：

1. 涉及多少参与者？

   • 一人或一个团队：流程图可能就足够了。

   • 多个团队或组织：BPMN 更为合适。

2. 职责是否重要？

   • 如果否，请使用流程图。

   • 如果是，请在BPMN中使用泳道或池。

3. 是否存在外部通信？

   • 如果否，两种表示法均可使用。

   • 如果是，BPMN可以区分消息与内部流程。

4. 是否存在定时器、错误或升级机制？

   • 如果否，流程图可能已足够。

   • 如果是，BPMN提供更清晰的建模工具。

5. 该流程是否会被自动化？

   • 如果否，对于简单流程，流程图可能已足够。

   • 如果是，BPMN通常是更好的基础。

6. 该流程是否需要作为正式标准被复用？

   • 如果否，请使用您的受众能理解的最简单表示法。

   • 如果是，BPMN可提供图表与工具之间更高的一致性。

7. 您的受众的技能水平如何？

   • 普通受众：从简单的流程图或高层级BPMN开始。

   • 分析师和技术团队：使用具有适当详细程度的BPMN。

11. 一种面向初学者的BPMN建模方法

步骤1：定义流程边界

确定流程的起点和终点。

例如：

• 起点：客户提交支持请求

• 终点：客户收到解决方案

避免试图一次性建模整个组织。

步骤2：识别参与者

列出涉及的人员、团队、组织和系统。

示例：

• 客户

• 支持专员

• 技术支持团队

• 计费系统

• 服务经理

这些可能成为池或泳道。

步骤 3：首先编写正常流程

记录无例外的正常流程。

接收请求
  ↓
分类请求
  ↓
调查问题
  ↓
解决问题
  ↓
通知客户
  ↓
关闭请求

这为在增加复杂性之前提供了清晰的基础。

步骤 4：添加开始和结束事件

每个完整的 BPMN 流程都应有明确的开始和结束。

示例：

• 开始：收到消息

• 开始：计时器到达

• 开始：客户提交表单

• 结束：案件已关闭

• 结束：请求被拒绝

• 结束：支付已完成

步骤 5：将工作分配给参与者

将每个活动放置在相应的泳道中。

例如：

客户：       提交请求 ───────────── 接收解决方案
支持：                    分类 ─ 调查 ─ 解决
系统：                                      发送通知

步骤 6：添加决策网关

当只应遵循一条路径时，请使用排他网关。

问题已解决？
 ├── 否 → 升级
 └── 是 → 通知客户

不要仅仅因为任务名称中包含问题就使用网关。当流程实际分支时才使用。

步骤 7：谨慎添加并行工作

当活动确实可以同时发生时，请使用并行网关。

例如，在订单批准后：

• 预留库存

• 生成发票

• 通知仓库

如果某项活动必须在另一项活动之前发生，则不要将它们建模为并行活动。

步骤 8：添加消息和数据

在参与者进行沟通时显示消息。

示例：

• 客户提交申请

• 供应商发送发货通知

• 系统发送审批邮件

当信息对活动至关重要时，添加数据对象。

步骤 9：添加异常

询问：

• 如果缺少所需信息怎么办？

• 如果客户不回复怎么办？

• 如果支付失败怎么办？

• 如果截止日期到期怎么办？

• 如果系统不可用怎么办？

• 如果员工拒绝请求怎么办？

仅建模对理解或改进流程有意义的异常。

步骤 10：与流程负责人一起审查图表

图表应由执行工作的人员进行审查。他们可以识别：

• 缺失的步骤

• 不正确的职责

• 非正式的变通方法

• 未在程序中记录的异常

• 延误和不必要的审批

12. 示例：流程图版本与 BPMN 版本

简单流程图

假设客户退回产品：

开始
  ↓
客户申请退货
  ↓
退货是否符合条件？
 ├── 否 → 拒绝申请
 └── 是 → 发送退货标签
                ↓
          收到退回商品
                ↓
          发放退款
                ↓
               结束

这易于理解，可能足以用于培训或快速概览。

面向 BPMN 的版本

更详细的 BPMN 模型将区分参与者：

客户

• 申请退货

• 包装产品

• 发送产品

客户服务

• 验证退货申请

• 批准或拒绝退货

• 发送退货说明

仓库

• 接收产品

• 检查状况

财务

• 发放退款

系统

• 发送确认

• 更新库存

• 记录退款

该模型还可以表示：

• 来自客户的信息

• 退货截止时间的计时器

• 基于产品状况的网关

• 如果未收到物品则报错

• 库存和退款活动的并行处理

• 确认退款的讯息

流程图解释总体逻辑，BPMN 解释操作协作。

13. 初学者常见错误

错误 1：使用所有 BPMN 符号

初学者有时会试图使用尽可能多的符号，这会使图表更难阅读。

从以下内容开始：

• 开始和结束事件

• 任务

• 排他网关

• 顺序流

• 池和泳道

• 在需要时使用消息流

仅在高级元素能解决实际建模问题时才添加它们。

错误 2：混淆顺序流与消息流

顺序流展示流程内部的进展；消息流展示不同参与者之间的通信。

不要仅仅为了改变线条外观而使用消息流。

错误 3：错误地混合池和泳道

使用泳道来划分参与者内部的责任。当参与者是独立实体或流程时，请使用单独的池。

例如：

• 销售、财务和运营可以是同一家公司内的泳道。

• 客户和供应商可以是单独的池。

错误 4：将每个决策都视为排他性

排他网关意味着仅选择一条路径。如果多条路径可能同时发生，请使用并行网关。如果一条或多条可选路径可能出现，请考虑使用包容网关。

错误 5：省略触发条件

流程应说明其启动原因。除非模型明确显示触发条件是什么，否则“处理订单”这一表述是模糊的：

• 客户订单

• 计划批次

• 付款确认

• 来自其他系统的消息

错误 6：仅建模理想流程

实际流程包括返工、拒绝、延迟和升级。仅展示理想路径的模型可能具有吸引力，但在操作上是不完整的。

错误 7：在活动中放入过多文本

任务标签通常应采用简洁的动词 – 宾语格式：

• 审查申请

• 验证地址

• 批准退款

• 发送确认

避免在任务框内使用长段落。将支持性说明放在注释或文档中。

错误 8：创建一个巨大的图表

大型流程应划分为子流程。高层级图表可能显示：

接收订单 → 处理付款 → 履行订单 → 关闭订单

每个阶段都可以链接到更详细的图表。

14. 用于可读图表的 BPMN 最佳实践

• 以一个清晰的开始事件开始。

• 以一个或多个有意义的结束状态结束。

• 将主流程从左到右或从上到下排列。

• 尽量使序列流线条保持笔直。

• 避免线条交叉。

• 使用一致的任务名称。

• 保持主图表在可读的详细程度。

• 仅在责任重要时使用泳道。

• 用有意义的疑问句或条件标记网关。

• 当含义不明显时，标记网关的出口路径。

• 使用子流程隐藏不必要的细节。

• 区分正常路径和异常路径。

• 在适当的池之间保持消息流。

• 谨慎使用注释。

• 与执行该流程的人员一起验证模型。

• 在重新设计流程时，创建单独的“当前状态”和“未来状态”图表。

15. 初学者应学习多少 BPMN？

创建有用的图表并不需要学习整个 BPMN 规范。

初学者级别

学习：

• 开始事件

• 结束事件

• 任务

• 顺序流

• 排他网关

• 并行网关

• 池

• 泳道

• 消息流

• 基本数据对象

这对于许多业务流程图来说已经足够了。

中级

添加：

• 定时事件

• 消息事件

• 错误事件

• 子流程

• 调用活动

• 用户任务

• 服务任务

• 边界事件

• 基于事件的网关

• 补偿路径

高级

学习：

• 编排图

• 对话图

• 非中断事件

• 事件子流程

• 事务

• 补偿

• 多实例活动

• 相关性

• 执行语义

• 特定于工具的实现规则

BPMN 支持多种模型类型，包括流程、协作、编排和对话图。初学者通常应从普通的流程和协作图开始，然后再学习更专业的类型。

16. BPMN、流程图及相关符号

BPMN 并非唯一的建模符号。

• 流程图：最适合简单的逻辑和过程

• BPMN：最适合业务流程和工作流协作

• UML 活动图：适用于软件和系统行为

• DMN：适用于正式的业务决策和规则

• CMMN：适用于灵活、基于案例的工作，其中路径未完全预定义

• 价值流图：适用于分析端到端的价值和浪费

• SIPOC 图：适用于高层级的供应商 – 输入 – 过程 – 输出 – 客户分析

BPMN 可能显示发生了决策，而专注于决策的符号（如 DMN）则可以描述用于做出该决策的规则。这些符号可以相互补充，而非相互竞争。

17. 一个简单的经验法则

选择流程图时：

你需要尽可能快速且简单地解释一系列步骤或决策。

选择BPMN时：

你需要理解、沟通、分析、改进或自动化涉及职责、事件、系统或组织的业务流程。

您也可以同时使用两者：

1. 先从简单的流程图开始，以理解整体流程。

2. 当角色、消息、异常、时间或自动化变得重要时，将其转换为BPMN。

3. 为高管创建高层级BPMN图，为分析师或开发人员创建详细版本。

结论

流程图和BPMN并非在所有情况下都是相互竞争的工具。流程图是一种轻量级的可视化说明。BPMN是一种结构化建模语言，适用于需要更高清晰度、责任明确性和操作细节的流程。

对于初学者，最佳方法是从简单开始：

• 定义流程边界。

• 识别参与者。

• 绘制正常路径。

• 添加决策点。

• 分配职责。

• 仅在必要时添加消息、计时器、数据和异常。

• 使用子流程来控制复杂性。

如果您的流程简短且由一人或一个团队处理，流程图可能已足够。如果流程涉及多个角色、部门、系统、外部方、截止日期或自动化，BPMN通常能提供更清晰且更持久的模型。