设计业务流程图，先把流程的起点、终点、参与角色、业务对象和判定条件列清楚，再按“主干流程—分支与异常—输入输出与状态”的顺序画图，最后用角色、字段、异常路径三项做评审。本文按边界界定、五步画法、图形约定、角色分工、完整示例和交付检查展开，帮助你把一张图从草稿推进到可用于需求评审的定稿。
要点总览（TL;DR）
- 先写流程边界说明表：触发事件、结束状态、参与角色、外部系统、不在范围内五项填清楚，再开始画图。
- 按五步推进：梳理业务对象与状态、画主干路径、补分支与异常、标注输入输出与规则、自检与评审，每步都有完成标志。
- 图形要素在项目内统一约定：一条泳道对应一个角色或系统，判定条件写在出口连线上，任务命名统一为动词加宾语。
- 业务方提供事实与例外，需求分析人员负责绘制与版本维护，研发确认可实现性，测试从场景覆盖角度复核。
- 交付前按路径完整性、角色与权限一致性、异常与回退路径、与需求文档一致性四类清单逐项核对。
先定流程边界：从哪个触发事件画到哪个结束状态
流程边界决定了一张图要画多大。边界不清，图会越画越长，把上下游都卷进来；边界过窄，又会漏掉关键分支，评审时才发现流程走不通。画图前先用一张边界说明表把范围写下来，比直接打开绘图工具更省时间。
确定触发事件和结束状态，可以从三个问题入手：什么外部动作或时间点让这段流程开始？流程在什么业务结果出现时算结束？结束后还有没有必须交代的后续动作？触发事件要写成可观察的事实，例如“客户提交订单”“每月最后一个工作日生成对账单”，避免写成“有需求时”。结束状态要写成业务状态，例如“订单已发货并生成出库单”，而不是“流程完成”这类无法核对的表述。
角色与外部系统清单要和边界一起列。角色指在流程中执行动作或做判断的岗位，外部系统指流程需要调用或回写数据的系统。清单不必展开到每个按钮，但要覆盖所有会改变流程走向的参与方。以下是一张可直接填写的流程边界说明表：
| 项目 | 填写内容 | 示例（订单履约） |
|---|---|---|
| 触发事件 | 让流程开始的业务事实 | 客户在商城提交订单并支付成功 |
| 结束状态 | 可核对的业务结果 | 订单签收，售后窗口开启 |
| 参与角色 | 执行动作或做判断的岗位 | 客户、客服、仓库、物流承运商 |
| 外部系统 | 提供或接收数据的系统 | 商城、支付平台、仓储系统、物流系统 |
| 不在范围内 | 明确排除的内容 | 商品定价策略、售后维修流程 |
“不在范围内”这一行常被省略，却最能防止流程图失控。它把属于需求表示的内容和留给需求分析的内容分开：流程图负责表达业务如何流转、在哪些节点做判断、每个节点产出什么；至于某个判断规则是否合理、某个角色是否应该存在，属于需求分析与业务澄清的工作，不在画图阶段下结论。边界说明表完成后，让业务方确认一次触发事件和结束状态，后续返工会少很多。
核心答案与操作步骤：五步画出可评审的业务流程图
边界确定后，按固定顺序推进，每一步都有明确输入、动作、输出和完成标志。顺序的价值在于先保证主干走得通，再补细节，避免一开始就陷入异常分支而看不到全貌。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 第一步：梳理业务对象与状态 | 边界说明表、业务单据或表单 | 列出流程中流转的核心对象及其状态变化 | 对象—状态清单 | 每个状态都有产生它的动作，且能对应到后续节点 |
| 第二步：画主干路径 | 对象—状态清单 | 只画顺利情况下的动作序列，按角色分列 | 主干流程图 | 从触发事件到结束状态有一条连续路径，无断点 |
| 第三步：补分支与异常 | 主干流程图、业务方口述的例外情况 | 在每个判断点补充分支，标注异常处理与回退 | 带分支的流程图 | 每个判定节点至少有两个出口，异常路径有明确归宿 |
| 第四步：标注输入输出与规则 | 带分支的流程图、字段清单、规则说明 | 在节点上标注输入单据、输出结果和判断依据 | 带标注的流程图 | 关键节点都能说清“拿什么、做什么、交什么” |
| 第五步：自检与评审 | 带标注的流程图、检查清单 | 按清单自检后组织评审，记录问题并修订 | 评审记录与定稿图 | 评审问题全部关闭或有明确处理结论 |
第一步容易被跳过，但业务对象和状态是流程图的骨架。以订单为例，对象是订单，状态包括待支付、已支付、待发货、已发货、已签收；每个状态之间由一个动作连接，动作由某个角色执行。状态清单列全了，主干路径基本就出来了。第二步只画顺利路径，目的是先让业务方确认“正常情况是不是这样走”，这一步确认得越快，后面补分支越省力。
第三步补分支时，重点问三类问题：判断不通过怎么办？执行失败怎么办？需要人工介入时由谁处理？每个异常分支都要落到一个明确状态或结束点，不能画一条线指向空白。第四步标注输入输出，是把流程图从“动作示意”变成“可执行说明”的关键：节点上写清输入的单据或数据、输出的结果或状态变更、判断所依据的规则来源。第五步自检与评审的具体检查项在最后一节展开。
图形要素与命名规范：泳道、判定、事件怎么画才不歧义
同一张图被不同人读出不同意思，多数源于符号和命名不统一。团队不必绑定某一建模标准，但要在项目内约定一套画法并保持一致。若团队已采用 BPMN 等标准，按其符号体系执行即可；未采用标准时，下表可作为最小约定。
| 要素 | 画法约定 | 命名要求 |
|---|---|---|
| 泳道 | 一条泳道对应一个角色或一个系统，按执行顺序从左到右排列 | 用岗位名或系统名，不用人名 |
| 事件 | 用圆形表示，区分开始事件与结束事件 | 写成已发生的事实，如“订单支付成功” |
| 任务 | 用矩形表示，一个任务只描述一个动作 | 动词加宾语，如“校验库存”“生成出库单” |
| 判定节点 | 用菱形表示，每个出口标注条件 | 条件写成可判断的表达式，如“库存充足”“金额超过5000元” |
| 子流程 | 用带加号的矩形或折叠标记表示，另附子图 | 子流程名概括其业务目的，如“异常订单人工审核” |
| 编号 | 按泳道和顺序编号，如 P1-01、P1-02 | 编号在修订时保持不变，新增节点用后缀区分 |
泳道划分有两种常见做法：按角色分和按系统分。角色泳道适合人工操作密集的流程，系统泳道适合接口调用多的流程；两者混用时，先按角色分，再把系统作为独立泳道放在下方，避免一个动作同时挂在两个泳道之间。判定节点的分支条件要写在出口连线上，不要写在菱形内部，否则条件一多就看不清对应关系。分支命名避免“是/否”单独出现，改成“库存充足/库存不足”，读图人不需要回头找判定问题。
事件、任务、子流程的区分标准是粒度：事件描述状态变化，不消耗时间；任务描述有人或系统执行的动作；子流程是把一组任务打包，用于控制主图复杂度。命名上统一“动词+宾语”的任务格式，能让评审时快速发现重复动作和缺失动作。编号约定则服务于版本管理，修订时保留原编号、新增节点追加后缀，评审记录就能准确指向某个节点。
角色及交付物：谁提供输入、谁画图、谁评审
流程图不是需求分析人员一个人的产物。业务方提供事实，需求分析人员负责结构化表达，研发和测试从可实现、可验证的角度提出问题。角色分工写清楚，评审才不会变成逐句解释图意。
| 角色 | 主要职责 | 交付物 | 评审关注点 |
|---|---|---|---|
| 业务方 | 提供触发事件、业务规则、例外情况和实际单据 | 边界说明表确认、规则与例外清单 | 流程是否符合实际业务，异常处理是否可接受 |
| 需求分析人员 | 组织梳理、绘制流程图、维护版本 | 流程图各版本、评审记录、问题清单 | 路径完整性、标注准确性、与其他需求材料一致 |
| 研发 | 确认流程中的系统交互与状态变更可实现 | 系统交互确认意见、状态字段建议 | 判定条件是否有数据支撑，状态流转是否闭环 |
| 测试 | 依据流程图设计测试场景 | 场景清单、异常路径覆盖建议 | 每条分支是否可触发、可验证，回退路径是否明确 |
交付物管理上，流程图应和需求条目建立对应关系：一张图对应哪个需求、当前是第几版、这一版改了哪些节点。版本记录不必复杂，在图的标题区标注版本号和修订日期，在评审记录中写明每次修订涉及的节点编号即可。当流程图作为需求材料的一部分进入评审时，把图挂在对应需求条目下，评审意见直接关联到需求，后续变更时也能追溯是哪次评审推动了修改。ONES 的统一需求池与工单、任务看板可以把需求、任务和缺陷串联起来，业务团队跟踪处理进度，产品经理基于反馈调整路线图，流程图定稿后的挂接与评审记录可以放在这条链路上管理；具体挂接方式以团队实际配置为准。
示例：一段订单履约流程从草稿到定稿
以下为演示情景，用于说明草稿到定稿的修正过程，不代表真实客户案例。触发事件是“客户提交订单并支付成功”，结束状态是“订单签收，售后窗口开启”。参与角色为客服、仓库、物流承运商，外部系统包括支付平台、仓储系统和物流系统。
草稿阶段，需求分析人员按顺利路径画了五个节点：支付成功→仓库拣货→打包出库→物流运输→客户签收。主干连续，但评审时业务方提出三个问题：库存不足时订单怎么处理？支付成功但仓储系统未收到订单怎么办？客户拒收后货物退回哪个状态？草稿图在这三处都没有出口，属于典型的分支遗漏。
修正后补充两条异常分支。第一条是库存校验分支：支付成功后先校验库存，库存充足进入拣货，库存不足转入“缺货登记”并由客服联系客户改期或退款，该分支结束于“订单关闭”或“改期发货”。第二条是拒收退回分支：客户拒收后，物流系统回传拒收信息，仓库执行退货入库，订单状态变为“已退回”，由客服发起退款。修正记录同时标注了每个判定节点的条件来源：库存数据来自仓储系统，拒收信息来自物流系统回传。
定稿图在节点上补充了字段与状态标注：拣货节点标注输入为“订单明细与库存锁定记录”，输出为“拣货单”；出库节点标注输出为“出库单与物流单号”；每个状态变更都对应到订单状态字段的取值。评审中发现的遗漏和修正方式记入评审记录，与定稿图一同归档，后续需求变更时可以对照查看这段流程为何这样设计。
完成检查：流程图可以交付的判定标准
一张图能否进入评审和交付，用清单逐项核对比凭感觉判断可靠。以下检查项按四类组织，全部通过或有明确处理结论后，流程图即可作为需求材料的一部分交付。
- 路径完整性：从触发事件到每个结束状态都存在连续路径；没有只有入口没有出口的节点；每个判定节点至少有两个出口且条件互斥。
- 角色与权限一致性：每个任务都落在唯一泳道上；泳道角色与实际执行岗位一致；跨泳道的交接有明确的输入输出。
- 异常与回退路径：失败、超时、人工介入三类情况都有处理节点；回退路径指向明确状态；异常分支的结束状态已列出。
- 与需求文档一致性：图中出现的业务对象、状态名称与需求文档用词一致；判定条件能在需求规则中找到依据；节点编号与评审记录可对应。
检查时建议由需求分析人员先自检一遍，再交给测试从场景覆盖角度复核。测试人员按分支逐条设计场景，能快速暴露“画了但触发不了”的路径。全部检查项通过后，流程图连同边界说明表、图形约定和评审记录一起归档，作为该需求版本的正式材料；后续需求变更时，按同样的五步流程修订并更新版本号，保持图与需求条目同步。
常见问题
流程图画到什么程度可以拿去评审，而不是等评审时再补？
评审前至少满足三个条件：从触发事件到每个结束状态都有连续路径；每个判定节点都有至少两个出口且条件互斥；异常分支都落到明确状态或结束点。满足这三条，评审讨论的重点会集中在业务规则是否合理，而不是图本身走不走得通。若时间紧张，可以先保证主干路径和主要异常分支完整，把次要分支标注为待补充并列入评审议题，避免带着断点进评审。
团队没有统一建模标准，泳道和判定节点怎么约定才够用？
不必一开始就引入完整建模标准，先约定最小集合即可：泳道按角色或系统划分且不混用，事件用圆形、任务用矩形、判定用菱形，判定条件写在出口连线上，任务命名统一为动词加宾语。约定写成一张表放在团队文档里，新成员画图前先读一遍。若团队后续要对接采用 BPMN 的合作伙伴，再按标准符号体系迁移，前期的最小约定不会成为负担。
业务方口述的例外情况很多，怎么判断哪些要画进图里？
用两个标准筛选：该例外是否改变流程走向，是否产生新的业务状态。改变走向的例外要画成分支，例如库存不足转入缺货处理；只影响操作细节、不改变状态的，记在节点标注或规则说明里即可。筛选时请业务方确认发生频率和处理责任人，频率低但影响大的例外同样要画，因为评审和测试最需要覆盖这类路径。
流程图定稿后，需求变更时怎么保持图和需求条目同步？
把流程图挂在对应需求条目下，标题区标注版本号和修订日期，评审记录写明每次修订涉及的节点编号。需求变更时按原来的五步流程修订，保留原编号、新增节点追加后缀，这样评审记录和历史版本能准确对应到具体节点。ONES 的统一需求池与工单、任务看板可以把需求、任务和缺陷串联起来，业务团队跟踪处理进度，产品经理基于反馈调整路线图，流程图定稿后的挂接与评审记录可以放在这条链路上管理；具体挂接方式以团队实际配置为准。
流程图和需求文档里的状态字段对不上，通常是什么原因？
常见原因是画图时用了口语化状态名，写文档时又换了一套术语。解决办法是在第一步梳理业务对象与状态时就确定状态名称，后续画图、写规则、设计字段都沿用同一套词。交付检查时专门核对图中状态名与需求文档用词是否一致，发现不一致以业务方确认的状态定义为准统一修改，避免研发按图实现、测试按文档验证时出现偏差。
