业务流程图设计从确定流程边界开始：写清目标、触发事件与结束状态，列出参与角色和外部系统，再沿主干路径拆出活动、判断与交接，补齐异常和回退分支，最后用统一符号和泳道绘制并组织评审。本文按这条主线给出每一步的输入、做法和产出，适合需要把一段业务表达成流程图并通过评审的产品、需求或业务人员参考。
要点总览（TL;DR）
- 先写一页流程边界说明：目标、触发事件、结束状态、参与角色与外部系统、范围外事项，避免把流程图扩成无边界的全景图。
- 沿主干路径按时间顺序拆活动，在角色变化处记录交接、在需要选择处设判断节点，活动粒度以“一个角色一次处理能完成的一个业务动作”为准。
- 主干完成后系统补齐输入不合格、判断否定、超时、主动中止四类异常，回退箭头指向明确节点并标注触发条件。
- 绘制前确定符号、泳道和命名三项约定并写入图例，跨泳道箭头即交接点，评审时重点核对。
- 交付前按边界闭合、分支有去向、活动要素完整、异常覆盖、符号一致、评审闭环六项清单逐条核对。
先定边界：流程目标、起止点与参与角色
流程图画成无边界的全景图，是设计阶段最常见的问题：图上什么都有，评审时却没人能说清这段流程解决什么问题、从哪里开始、到哪里结束。边界说明的作用，是把这次要画的流程从相邻业务中切出来，让后续活动识别有明确的搜索范围。
边界说明可以写成一页纸，包含以下五项内容，每项都用一句话或一个清单写实：
- 流程目标：这段流程要解决什么业务问题，完成后业务对象处于什么状态。例如“采购申请从提交到获得审批结论”，目标是让申请在约定时限内得到明确的通过或驳回结果。
- 触发事件：什么动作或时点让流程启动。触发要具体到业务事件，如“申请人提交采购申请单”，避免写成“有采购需求时”。
- 结束状态：流程在哪些状态下算结束。一个流程可以有多个结束状态，如“审批通过”“审批驳回”“申请人撤回”，每个都要写明。
- 参与角色与外部系统：列出所有在流程中执行动作、做判断或接收结果的角色，以及参与交互的外部系统，如财务系统、邮件通知服务。角色按岗位或职责命名，不写具体人名。
- 范围外事项：明确本次不展开的相邻流程，如“采购订单执行”“供应商准入”不在本图范围内，只作为上下游接口标注。
完成标志是：一位没参与讨论的同事读完这页说明，能准确说出流程从哪开始、到哪结束、涉及哪些角色，并且不会把范围外业务混进来。边界一旦确定，后续拆活动时遇到范围外的内容，直接标注为接口而不是继续展开。
按主干路径拆活动、判断与交接
主干路径是流程在一切顺利时的走法，从触发事件出发，经过各角色的活动，到达主要结束状态。拆解时按时间顺序逐段推进，每遇到一次角色变化或一次判断，就停下来记录，这样拆出的活动清单天然带有交接点和分支。
具体做法分四步：
- 从触发事件写出第一个活动：谁在什么条件下做了什么。活动用“动词+业务对象”命名，如“提交采购申请”“审核预算科目”。
- 在角色变化处记录交接：上一个角色的活动结束后，把什么输入交给下一个角色。交接要写清传递的业务对象和状态，如“申请单状态变为待审批，流转至部门负责人”。
- 在需要选择处设判断节点：判断节点只写一个问题，分支条件写成可判定的表达式，如“金额是否超过5万元”“预算科目是否存在”。避免“情况是否复杂”这类无法客观判定的条件。
- 逐段推进到结束状态：每段活动都追问“然后呢、由谁做、依据什么”，直到抵达边界说明中定义的结束状态。
活动粒度以“一个角色在一次处理中能完成的一个业务动作”为宜。粒度过细会把流程图变成操作手册，粒度过粗则掩盖交接和判断。判断标准是：如果两个活动总是由同一角色连续完成、中间没有判断和交接，可以合并为一个活动；如果一个活动内部包含多个角色或多次决策，应拆开。
建议把主干路径整理成两张表：活动清单按顺序列出活动编号、活动名称、执行角色、输入、输出；分支条件表列出判断节点编号、判断问题、各分支条件及去向。这两张表是后续绘图的底稿，也方便评审时逐条核对。
补齐异常、回退与例外路径
只画顺利路径的流程图，在评审时往往被业务人员一句“实际不会这样走”推翻。异常路径不是补充说明，而是流程设计的一部分，需要在主干完成后系统性地识别和表达。
识别异常可以从四个来源入手：
- 输入缺失或不合格：申请材料不全、数据校验不通过、附件缺失。处理方式通常是退回补充或终止流程。
- 判断结果为否定：审批驳回、预算不足、资格不符。要写明驳回后回到哪个节点、由谁修改、是否需要重新走完整审批。
- 时间与外部条件：超时未处理、外部系统调用失败、供应商无响应。要写明超时后的升级或自动处理规则。
- 主动中止：申请人撤回、业务取消。要写明中止时已产生的业务对象如何处理。
回退与重做的表达要点是“回到哪里、带什么状态回去”。回退箭头应指向明确的节点，而不是笼统地指回流程起点；如果驳回后只需修改局部内容再提交，就指回被驳回的活动；如果需要重新审批全部环节，才指回审批链起点。回退路径上要标注触发条件，如“材料不全”“金额超预算”。
异常路径需要标注优先级，避免图上分支过多导致主干不可读。常用做法是：主干路径用主线条完整呈现，高频异常（如材料退回补充）画在主图上，低频异常（如系统故障、流程取消）用标注或附页说明。每条异常路径都要写明触发条件、处理角色和结束状态，与主干路径采用同一套命名和编号规则。
用统一符号和泳道把流程画出来
绘制阶段的目标是让图能被不同角色独立读懂。符号、泳道和命名三项约定要在动笔前确定，并在图例中说明，避免同一张图里出现多种画法。
基本符号的使用约定如下：
| 元素 | 图形 | 使用约定 |
|---|---|---|
| 开始/结束 | 圆角矩形或椭圆 | 每个流程至少一个开始，可有多个结束，结束状态需命名 |
| 活动 | 矩形 | 用“动词+业务对象”命名，一个活动对应一个角色的一次处理 |
| 判断 | 菱形 | 只写一个问题，出口分支标注条件，每个分支必须有去向 |
| 交接/流转 | 箭头 | 箭头方向表示业务推进方向，跨泳道箭头即角色交接 |
| 输入输出 | 文档形或旁注 | 关键业务对象可在活动旁标注，避免图上堆满附件图标 |
泳道按角色或系统划分，一条泳道对应一个执行主体。角色泳道按流程中出现的顺序从左到右或从上到下排列，外部系统单独设泳道并标注为系统。跨泳道的箭头就是交接点，评审时可以重点检查每个跨道箭头是否写清了传递的业务对象和状态。
命名与编号规范建议统一为：活动编号采用“阶段缩写-序号”，如“PR-01”；判断节点单独编号，如“D-01”；结束状态命名为“业务对象+结果”，如“申请单-已通过”。图与文字说明要一一对应：活动清单中的编号与图上编号一致，分支条件表中的每个条件都能在图上找到对应标注。图例放在图的一角，说明符号含义、泳道划分依据和编号规则。
流程设计通常由业务负责人提出目标并确认业务规则，流程设计者负责拆解活动、绘制和整理说明，参与角色在评审中核对本岗位环节，评审者对完整性做最终确认。版本与变更记录由流程设计者维护，每次评审后的修改都要记录变更点、原因和确认人，避免多版本并存时无法判断哪版有效。评审意见、修改任务和版本记录如果分散在邮件和聊天里，容易丢失上下文；可以在 ONES 中把流程图文档、评审意见和修改工作项关联到同一处，让每条意见有处理状态和确认人，定稿版本与变更记录保持对应。
角色分工与各阶段交付物
流程设计涉及多类角色，职责不清时容易出现业务规则没人拍板、图改完没人确认的情况。下表按阶段列出输入、输出和责任人，可作为项目启动时的分工依据。
| 阶段 | 主要输入 | 主要输出 | 责任人 |
|---|---|---|---|
| 边界确定 | 业务问题描述、上下游流程信息 | 一页流程边界说明 | 业务负责人提出并确认，流程设计者整理 |
| 主干拆解 | 边界说明、现有制度或操作规范 | 活动清单、分支条件表 | 流程设计者主笔，参与角色提供本岗位细节 |
| 异常补齐 | 主干清单、历史异常记录、一线反馈 | 异常与例外路径清单 | 流程设计者整理，业务负责人确认处理规则 |
| 绘制 | 活动清单、分支条件表、异常清单 | 流程图及图例说明 | 流程设计者 |
| 评审 | 流程图、图例、说明文档 | 评审意见及处理结论 | 评审者组织，参与角色逐岗核对 |
| 定稿与变更 | 评审意见处理结果 | 定稿版本、变更记录 | 流程设计者维护，业务负责人确认 |
评审与确认的责任人要明确到岗位：业务负责人对业务规则和结束状态负责，评审者对完整性和一致性负责，参与角色对本岗位环节的准确性负责。版本记录至少包含版本号、修改内容、修改原因、确认人和日期，变更后同步通知受影响的角色。
示例：一条审批流程从草稿到定稿
以下示例为演示情景，用一条采购申请审批流程说明前述步骤如何串联。
边界：目标是采购申请从提交到获得审批结论；触发事件为申请人提交采购申请单；结束状态包括“审批通过”“审批驳回”“申请人撤回”；参与角色为申请人、部门负责人、财务审核员、分管领导，外部系统为预算系统；范围外事项为采购订单执行与供应商管理。
主干：申请人提交申请（PR-01）→ 部门负责人审批（PR-02，判断D-01：金额是否超过5万元）→ 未超过则由财务审核员审核预算（PR-03）→ 超过则增加分管领导审批（PR-04）→ 审批通过，结束。分支条件表记录D-01的两个条件及去向，每个跨泳道箭头标注传递的申请单状态。
异常：材料不全时由部门负责人退回申请人补充（回到PR-01，标注触发条件“附件缺失”）；预算科目不存在时由财务审核员驳回（结束状态“审批驳回”）；部门负责人超过2个工作日未处理时升级提醒；申请人在任一审批前可撤回（结束状态“申请人撤回”）。
评审修正：走查中发现两处问题。一是原图将“财务审核”画在部门负责人审批之前，与制度规定的顺序不符，调整为审批后再审核预算；二是驳回路径原图直接指回流程起点，实际只需申请人修改附件后重新提交，改为指回PR-01并标注“仅补充材料，无需重新审批已通过环节”。修正后更新版本记录，由业务负责人确认定稿。
完成检查：流程图可以交付的判定标准
交付前按以下清单逐项核对，全部通过再提交评审或归档：
- 边界闭合：流程目标、触发事件、结束状态齐全；每个结束状态都有明确命名；范围外事项已标注为接口。
- 分支有去向：每个判断节点的每个出口都指向明确的活动或结束状态；不存在只有入口没有出口的节点。
- 活动要素完整：每个活动都有执行角色、输入和输出；跨泳道箭头标注了传递的业务对象和状态。
- 异常覆盖：输入不合格、判断否定、超时、主动中止四类异常均有对应路径；回退箭头指向明确节点并标注触发条件。
- 符号与命名一致：图例齐全；活动、判断、结束状态编号与文字说明一一对应；同一元素在全图中使用同一画法。
- 评审意见闭环：每条评审意见都有处理结论和确认人；修改后的版本号与变更记录一致；定稿版本由业务负责人确认。
这份清单同时可以作为评审会的核对议程：按清单顺序逐项过图，发现的问题记录为待办并指定处理人，处理完成后更新版本再确认。流程图达到可交付状态，意味着任何一位参与角色都能在图上找到自己的环节、输入输出和异常处理方式，并且对定稿版本没有异议。
常见问题
流程边界说明需要写到多细，才够支撑后续拆活动？
边界说明的完成标准是：一位没参与讨论的同事读完，能准确说出流程从哪开始、到哪结束、涉及哪些角色，并且不会把范围外业务混进来。达到这个标准即可，不必在边界阶段就写清每条业务规则。业务规则和判断条件留到主干拆解阶段，在分支条件表中逐条落实。
如果边界说明写完仍有人对“结束状态有几个”有分歧，说明业务目标本身还没对齐，应先由业务负责人确认，再进入活动拆解。
主干路径拆完后，怎么判断活动粒度是否合适？
用两条规则检验：如果两个活动总是由同一角色连续完成、中间没有判断和交接，可以合并为一个活动；如果一个活动内部包含多个角色或多次决策，应拆开。粒度合适的活动，在图上能对应一个矩形，在活动清单里能写清一个执行角色、一组输入和一组输出。
粒度过细会把流程图变成操作手册，评审时难以聚焦业务规则；粒度过粗则掩盖交接和判断，异常路径也无处挂接。
驳回后应该指回流程起点，还是指回被驳回的活动？
取决于驳回后需要重做多少内容。如果只需修改局部内容再提交，回退箭头指回被驳回的活动；如果需要重新审批全部环节，才指回审批链起点。回退路径上要标注触发条件，例如“材料不全”“金额超预算”，并写明由谁修改、修改后是否需要重新走完整审批。
示例中的做法是：材料不全退回申请人补充，指回提交活动并标注“仅补充材料，无需重新审批已通过环节”。这条标注本身就是业务规则的一部分，应在评审中由业务负责人确认。
异常分支很多时，全部画在主图上还是另附说明？
常用做法是按频率分层：主干路径用主线条完整呈现，高频异常（如材料退回补充）画在主图上，低频异常（如系统故障、流程取消）用标注或附页说明。无论画在哪里，每条异常路径都要写明触发条件、处理角色和结束状态，并与主干路径采用同一套命名和编号规则，保证评审时能逐条追溯。
如果低频异常也全部画进主图，主干会被分支淹没，评审者反而难以判断流程是否走得通。
流程图定稿后业务规则发生变化，版本怎么管理？
版本记录至少包含版本号、修改内容、修改原因、确认人和日期，由流程设计者维护，业务负责人确认。变更后同步通知受影响的角色，避免多版本并存时无法判断哪版有效。
评审意见、修改任务和版本记录如果分散在邮件和聊天里，容易丢失上下文。可以在 ONES 中把流程图文档、评审意见和修改工作项关联到同一处，让每条意见有处理状态和确认人，定稿版本与变更记录保持对应。
