业务流程图示例的价值在于让读者看到一张“画完了”的图：谁在什么条件下做什么、判断走哪条路、出错怎么回退。本文用一个演示性的订单退款场景，交付一份包含角色、步骤、判断分支和异常路径的完整示例，再逐项解释画法依据，并提炼可迁移到其他需求场景的规律与适用边界。
要点总览（TL;DR）
- 业务流程图示例要交付一张“画完了”的图：起止明确、角色齐全、步骤完整、判断有条件、异常有出口，五项缺一不可。
- 演示示例采用订单退款场景，覆盖消费者、客服、仓库、财务四个角色，主干路径加三类异常出口，可直接对照还原成图形。
- 每个判断节点写成“是否+可验证状态”，所有出线必须有去向；回退环只保留必要的一处，回退点过多时拆子流程。
- 迁移到其他场景按“先定角色再定步骤、先主干后分支、判断补异常、节点表与图互校”的顺序操作。
- 业务流程图适合表达跨角色业务流转，系统架构设计、UI 绘制和需求内容判断分别由其他方式承担。
示例目标：这份业务流程图要回答什么
本文的示例情景设定为电商平台的“订单退款处理”：消费者提交退款申请后，客服、仓库、财务三个角色依次介入，根据订单状态和货物状态走不同的处理路径。选择这个场景，是因为它天然包含多角色交接、条件判断和异常回退，能较完整地展示业务流程图的表达要素。需要说明的是，这是一个用于讲解的演示情景，不对应任何真实企业或系统。
读者要完成的任务是：对照示例理解一张业务流程图应包含哪些要素，并能在自己的需求场景中画出同类图。因此示例要示范到“可直接对照”的程度，而不只是给出几个零散符号。
完成标准可以归纳为一份检查清单：
- 起止明确：有清晰的开始事件和若干结束状态，读者能判断流程在哪里终止。
- 角色齐全：每个步骤都归属到具体角色，跨角色交接点可辨认。
- 步骤完整：主干路径从发起到闭环没有断点，动作以“动词+对象”描述。
- 判断有条件：每个判断节点写明判断依据和分支去向，分支条件互斥且可验证。
- 异常有出口：失败、超时、驳回等情况有对应路径和回退处理，不出现“悬空”分支。
这份清单同时也是后文逐项解释的对照依据：示例中的每个节点和分支，都应能在清单中找到对应的检查项。
完整示例：一张订单退款业务流程图
下面用文字化流程加节点表的方式呈现这张图。文字化流程描述走向，节点表记录每个节点的角色、动作和输出，两者配合即可还原成图形。
参与角色与起止
流程涉及四个角色：消费者（发起方）、客服（受理与审核）、仓库（货物核验）、财务（退款执行）。开始事件为“消费者提交退款申请”，结束状态有三个：退款成功、申请驳回、申请关闭（超时未处理）。
主干流程（文字化）
- 开始：消费者在订单页提交退款申请，填写退款原因并选择退款类型（仅退款 / 退货退款）。
- 客服受理：客服在承诺时限内查看申请，核对订单状态。
- 判断一：订单是否已发货？未发货走“仅退款”审核；已发货走“退货退款”审核。
- 客服审核：判断申请是否符合退款规则（如是否在售后期限内、商品是否属于不支持退款类目）。
- 判断二：审核是否通过？不通过则通知消费者并结束于“申请驳回”；通过则进入下一步。
- 分支处理：仅退款路径直接转财务；退货退款路径通知消费者寄回商品，转仓库。
- 仓库核验：仓库收到退货后检查商品状态，登记核验结果。
- 判断三：商品核验是否合格？不合格则转客服与消费者协商，回到客服审核环节；合格则转财务。
- 财务执行：财务按原支付渠道发起退款，记录退款单号。
- 结束：退款成功，系统通知消费者。
节点表
| 节点编号 | 节点名称 | 角色 | 类型 | 输入 | 输出/去向 |
|---|---|---|---|---|---|
| N1 | 提交退款申请 | 消费者 | 开始事件 | 订单号、退款原因、退款类型 | 转 N2 |
| N2 | 受理并核对订单 | 客服 | 任务 | 退款申请单 | 转 N3 |
| N3 | 订单是否已发货 | 客服 | 判断 | 订单发货状态 | 未发货→N4；已发货→N5 |
| N4 | 仅退款审核 | 客服 | 任务 | 退款规则、订单信息 | 转 N6 |
| N5 | 退货退款审核 | 客服 | 任务 | 退款规则、订单信息 | 转 N6 |
| N6 | 审核是否通过 | 客服 | 判断 | 审核结论 | 通过→N7；不通过→N12 |
| N7 | 退款类型分流 | 系统/客服 | 判断 | 退款类型 | 仅退款→N10；退货退款→N8 |
| N8 | 通知寄回并等待收货 | 消费者/客服 | 任务 | 退货地址、寄回要求 | 转 N9 |
| N9 | 商品核验 | 仓库 | 任务 | 退回商品、核验标准 | 转 N11 |
| N10 | 发起退款 | 财务 | 任务 | 退款金额、支付渠道 | 转 N13 |
| N11 | 核验是否合格 | 仓库 | 判断 | 核验结果 | 合格→N10；不合格→N14 |
| N12 | 通知驳回 | 客服 | 结束事件 | 驳回原因 | 结束：申请驳回 |
| N13 | 退款完成通知 | 系统 | 结束事件 | 退款单号 | 结束：退款成功 |
| N14 | 协商处理 | 客服/消费者 | 任务 | 核验不合格说明 | 回退至 N6 重新审核 |
异常路径与结束状态
示例中设置了三类异常出口：审核不通过直接结束于“申请驳回”；商品核验不合格进入协商，协商后回到审核环节形成回退环；此外约定客服在承诺时限内未受理时，申请自动关闭。前两类在节点表中已体现，第三类作为超时规则补充说明，画图时可用边界事件或注释标注，避免主干图过于拥挤。
逐项解释：每个节点和分支为什么这样画
节点和分支的选择不是随意的，每一项都对应需求描述中的一句话或一个约束。下表逐项说明依据。
| 对象 | 画法 | 依据 |
|---|---|---|
| 角色泳道 | 按消费者、客服、仓库、财务划分四条泳道 | 每个动作都有明确执行者，跨泳道的连线即为交接点，便于识别等待和职责边界 |
| N3 订单是否已发货 | 判断节点，两条出线 | 发货状态直接决定是否需要退回货物，是退款流程的第一个分水岭 |
| N6 审核是否通过 | 判断节点，通过/不通过 | 审核结论是业务规则的核心判断，两个分支互斥且可核验 |
| N7 退款类型分流 | 判断节点，仅退款/退货退款 | 与 N3 呼应：未发货通常只能仅退款，已发货可走退货退款，分流保证路径不交叉 |
| N11 核验是否合格 | 判断节点，合格/不合格 | 货物状态影响退款能否执行，不合格需要人工协商，不能直接进入财务 |
| N14 协商处理 | 回退至 N6 | 协商结果可能改变审核结论，回到审核环节比新建分支更符合实际处理逻辑 |
| N12 通知驳回 | 结束事件 | 驳回是终态，需告知消费者原因，形成闭环 |
| 超时关闭 | 边界事件/注释 | 属于规则约束而非主干动作，单独标注可保持主干清晰 |
关于判断条件的表达，示例统一采用“是否+可验证状态”的写法，例如“订单是否已发货”“核验是否合格”，而不是“情况A/情况B”这类模糊描述。这样每个分支都能在需求文档中找到对应的数据字段或业务规则，评审时可以直接核对。
异常路径的处理遵循一个原则：每个判断节点的所有出线都必须有去向，不允许出现只画了“是”而“否”悬空的情况。回退环只设一处（N14→N6），避免多个回退交织导致图难以阅读；如果实际业务中回退点较多，可以拆成子流程单独表达。
流程与需求描述的对应关系体现在命名上：节点名称使用“动词+对象”，与需求条目中的用户故事或功能点一一对应。例如“商品核验”对应需求中的“仓库需在收货后完成商品状态检查”，读者可以从图反查需求，也可以从需求定位图中的节点。
可迁移规律：换一个业务场景怎么套用
把这张退款流程图换成请假审批、合同审批或工单处理，方法可以复用。以下规律按操作顺序排列。
- 先定角色，再定步骤。列出所有参与方，按参与方划分泳道，再把动作填进对应泳道。这样能自然暴露“谁在等谁”，减少遗漏交接环节。
- 从触发事件写起，先画主干。只写顺利走通的最短路径，确认起止和主要步骤后再补分支，避免一开始就陷入细节。
- 在每个需要做决定的位置放判断节点，条件写成可验证的状态。判断节点数量以业务规则为准，不为凑结构而增加。
- 为每个判断补齐异常出口。逐条检查“否”分支的去向，明确是结束、回退还是转人工，确保没有悬空线。
- 回退环控制在必要范围内。回退点过多时拆分子流程，主图只保留入口和出口。
- 用节点表与图互相校验。图中每个节点在表中有角色、输入和输出，表中每条去向在图中能找到连线，两者一致才算完成。
- 与需求文档双向挂钩。节点名称对应需求条目，判断条件对应业务规则字段，评审时按图逐条核对需求是否被覆盖。
在团队协作中，流程图往往与需求条目分开存放，修改后容易出现版本不一致。ONES 支持将需求工作项与流程说明文档关联管理，流程节点变更时可在同一处更新需求描述和评审记录，便于评审人对照图与需求逐项确认。这一衔接适用于需求与流程需要同步维护的团队，具体使用方式按团队现有流程配置。
适用边界：业务流程图适合与不适合的场景
业务流程图擅长表达跨角色的业务流转：谁发起、经过哪些角色、在什么条件下走哪条路、异常如何收口。当需求涉及多方交接、审批链或状态流转时，用流程图能把文字描述中容易遗漏的分支和回退显性化，这是它最合适的用途。
它也有明确的表达边界。系统架构设计关注服务划分、数据流向和技术选型，业务流程图的角色和步骤无法承载这些内容，两者应分开表达。UI 绘制关注界面布局、交互细节和视觉状态，流程图只说明“做什么”，不说明“界面长什么样”，用流程图替代原型会丢失关键信息。需求内容本身的判断，例如某个退款规则是否合理、售后期限定多长，属于需求分析与澄清的工作，流程图只负责把已确定的规则画清楚，不能代替需求讨论。
实际使用中，一张业务流程图通常与用户故事、用例描述配合：流程图给出全局走向，用户故事补充单个角色的操作细节，用例描述覆盖特定场景的前置条件和后置结果。三者各司其职，流程图不承担它不擅长的表达任务，才能保持清晰和可维护。
常见问题
业务流程图和用户故事、用例描述是什么关系，需要都画吗？
三者表达层次不同，可以配合使用。业务流程图给出跨角色的全局走向，说明谁在什么条件下做什么、异常如何收口；用户故事补充单个角色的操作细节和目的；用例描述覆盖特定场景的前置条件、主流程和后置结果。
需求涉及多方交接、审批链或状态流转时，流程图的价值最明显；单个角色内部的交互细节，用用户故事或验收条件表达更合适。不必为每个需求都画流程图，按交接复杂度选择即可。
流程图中判断节点很多、回退线交叉，怎么处理才清晰？
先确认这些判断是否都属于同一层级的业务规则。如果回退点集中在某个环节，可以把该环节拆成子流程单独表达，主图只保留子流程的入口和出口。如果判断数量多但彼此独立，考虑按角色或阶段拆成多张图，每张图聚焦一段流程。
另一个常见做法是把超时、自动关闭这类规则约束用边界事件或注释标注，不画进主干，避免主干图被规则细节淹没。
画业务流程图之前，需求要确定到什么程度才能动笔？
至少需要确定三件事：参与角色及其职责边界、主干路径的起止和主要步骤、关键判断所依据的业务规则。规则本身是否合理、期限定多长这类内容判断，属于需求分析与澄清的工作，应在画图前讨论清楚。
规则尚未定稿时也可以先画主干和已确认的判断，把待定分支标注出来，作为评审讨论的载体。这样流程图同时承担了暴露需求空缺的作用。
流程图改版后和需求文档对不上，团队里怎么避免？
常见原因是图与需求条目分开存放、各自更新。可行的做法是让节点名称与需求条目保持一一对应，判断条件对应业务规则字段，评审时按图逐条核对需求覆盖情况；流程变更时同步更新需求描述和评审记录。
ONES 支持将需求工作项与流程说明文档关联管理，流程节点变更时可在同一处更新需求描述和评审记录，便于评审人对照确认。具体配置方式按团队现有流程安排。
简单的一问一答式业务，也需要画业务流程图吗？
当流程只涉及单一角色、没有条件分支和交接点时，用文字步骤或验收条件表达通常更直接，画图带来的收益有限。判断标准可以看两点：是否存在跨角色交接，是否存在需要显性化的条件分支或异常回退。两者都不明显时，流程图可以省略。
