业务流程建模要回答的是“业务实际怎么运转、系统要支持哪些动作和例外”。做法是先写清建模目标与范围，再从触发事件出发梳理角色、活动、分支和例外，用统一字段把每个活动写实，最后通过走查和检查清单确认模型能支撑需求评审。本文按这一顺序给出步骤、角色分工、交付物和完整示例。
要点总览（TL;DR）
- 建模前先写一页任务说明，明确目标（需求澄清、流程优化或系统建设）、起止事件、涉及部门与不纳入环节，以及只画主干还是展开例外分支。
- 按“识别触发事件与结束状态→划分泳道与角色→列活动、分支与例外→标注输入输出与规则→绘制当前与目标流程→走查修订”六步推进，每步都有完成标志。
- 活动说明表至少写清编号、名称、负责人、输入、输出、业务规则和异常处理；分支要有条件表达式和默认出口，例外路径要有处理去向。
- 业务负责人提供流程事实与规则确认，需求分析人员主持建模并维护一致性，开发与测试从模型提取验收条件与测试场景，评审意见逐条闭环。
- 交付前用检查清单核对路径完整性、活动字段、分支可判断、需求可追溯和版本一致，全部通过再进入需求评审。
先定建模目标与范围：这次要回答哪个业务问题
建模开始前先写一页任务说明，把“为什么画、画到哪里、画多细”定下来。没有这页说明，流程图容易变成部门全景图，评审时无法判断哪些内容与本次需求有关。
建模目标通常来自三类场景，目标不同，模型的重点也不同：
- 需求澄清：业务方和需求分析人员对流程理解不一致，需要把现状讲清楚，重点是把角色、活动和规则对齐。
- 流程优化：现有流程存在等待、返工或审批过多，需要对比当前流程与目标流程，重点是差异点和改进依据。
- 系统建设：要开发或改造系统，需要明确系统承接哪些活动、哪些仍由人工完成，重点是活动输入输出和数据对象。
范围界定要写清三件事：起止事件（从什么触发开始，到什么状态结束）、涉及部门与岗位、明确不纳入本次建模的环节。例如“本次只覆盖订单提交到发货完成，售后与财务结算不在范围内”。范围写出来，评审时才有边界可守。
建模深度按用途确定。只用于需求澄清时，画主干活动和关键分支即可；用于系统建设时，需要展开例外路径、退回路径和人工干预点。深度一旦确定，后续所有泳道和活动说明表按同一深度展开，避免有的分支画到操作级、有的只到部门级。
本节产出是一页建模任务说明，包含：建模目标、起止事件、涉及部门、不纳入环节、建模深度、参与角色和计划评审时间。这页说明随模型一起归档，后续修订时先看它是否仍然成立。
业务流程建模的操作步骤：从事件到可评审的流程
下面六步按顺序执行，每步都有明确的输入、动作、输出和完成标志。实际项目中可以并行收集材料，但模型定稿前应按此顺序回查一遍。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 识别触发事件与结束状态 | 建模任务说明、业务方口述 | 列出什么事件启动流程、流程在什么状态结束，区分正常结束与异常结束 | 事件与结束状态清单 | 每个事件都能对应一个明确的结束状态 |
| 2. 划分泳道与角色 | 组织与岗位信息 | 按实际承担动作的岗位划分泳道，明确每个角色的职责边界 | 角色清单与泳道划分 | 每个活动都能落到一条泳道，无“无人负责”的活动 |
| 3. 列活动、判断分支与例外 | 事件清单、访谈记录 | 按时间顺序列活动，标出判断点和每条分支条件，单独列出例外路径 | 活动清单与分支说明 | 每条分支都有判断条件，例外路径有处理去向 |
| 4. 标注输入输出、规则与数据对象 | 表单、制度文件、系统截图 | 为每个活动填写输入、输出、业务规则和涉及的数据对象 | 活动说明表初稿 | 每个活动至少有一项输入和一项输出 |
| 5. 绘制当前流程与目标流程并标注差异 | 活动说明表、现状材料 | 先画当前流程，再画目标流程，用标记区分新增、删除、调整的活动 | 两张流程图与差异说明 | 差异点可逐条对应到需求或改进项 |
| 6. 组织走查并修订 | 流程图、活动说明表、差异说明 | 邀请业务负责人、开发、测试逐条走查路径，记录意见并修订 | 评审记录与修订版模型 | 评审意见全部有处理结论 |
第1步容易被跳过，但触发事件决定了流程的入口数量。一个流程如果有多个触发事件（如客户下单、销售代下单、系统补单），应分别标注入口，而不是合并成一个模糊的“开始”。
第3步列活动时，按“谁在什么条件下做什么”描述，先不追求图形美观。分支条件写成可判断的表达式，例如“库存充足”“信用额度超限”，避免写成“情况特殊时”这类无法评审的表述。
第5步画两张图的目的，是让评审者看到改了什么。当前流程用于确认事实，目标流程用于确认需求，差异说明则是后续需求条目和验收条件的来源。
流程模型里必须写清的字段与表达规则
流程图负责让人看懂路径，活动说明表负责让模型可评审、可复用。两者字段口径一致，才能支撑需求条目追溯。
活动说明表建议包含以下字段：
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 编号 | 按流程缩写加序号，全局唯一 | ORD-03 |
| 名称 | 动宾结构，描述动作而非部门 | 校验客户信用额度 |
| 负责人 | 承担该活动的岗位或系统 | 信用审核岗 |
| 输入 | 启动该活动所需的信息或单据 | 订单信息、客户信用记录 |
| 输出 | 活动完成后产生的结果或状态 | 审核结论、额度占用记录 |
| 业务规则 | 判断依据和计算口径 | 可用额度低于订单金额时转人工审批 |
| 异常处理 | 规则不满足或数据缺失时的去向 | 信用记录缺失时转人工核验 |
分支条件与合并规则要成对写清。每个判断点注明条件表达式和默认分支，合并点注明哪些路径汇入、汇入后继续执行哪个活动。缺少默认分支是常见遗漏，评审时应重点检查。
流程与需求条目的关联方式，建议在活动说明表中增加“关联需求编号”字段，或在需求条目中反向引用活动编号。无论采用哪种方向，保证一个活动能追溯到对应需求、一个需求能定位到受影响的活动。
命名与编号约定提前统一：活动名称用动宾结构，判断点用疑问式或条件式命名，泳道用岗位名称。常见表达错误包括：把部门名当活动名（如“财务部”）、分支只有一条出口没有条件、例外路径被省略、活动没有输入输出。这些问题在走查时逐条对照活动说明表即可发现。
角色分工与各阶段交付物
建模不是需求分析人员一个人的工作。业务方提供事实，分析人员保证模型一致，开发和测试验证模型能否支撑后续工作，评审角色在固定时点给出结论。
| 角色 | 主要职责 | 交付物 | 参与时点 |
|---|---|---|---|
| 业务负责人 | 提供流程事实、确认业务规则和例外处理方式 | 流程事实说明、规则确认意见 | 建模启动、走查评审 |
| 需求分析人员 | 主持建模、维护模型一致性、关联需求条目 | 建模任务说明、流程图、活动说明表 | 全过程 |
| 开发人员 | 判断活动能否由系统承接、识别数据对象缺口 | 系统承接意见、数据对象清单 | 目标流程绘制、走查 |
| 测试人员 | 从分支和例外路径提取测试场景 | 测试场景清单、验收条件建议 | 走查评审 |
| 评审负责人 | 组织评审、汇总意见、确认闭环 | 评审记录、修订确认 | 评审时点 |
评审时点建议设在目标流程和活动说明表初稿完成后，此时模型已有足够信息供开发和测试判断。评审前把材料提前发出，评审会上逐条走路径，而不是逐页看文档。
交付物归属要明确：流程图和活动说明表由需求分析人员维护，业务规则确认意见由业务负责人签署，测试场景由测试人员维护。版本管理上，每次修订记录变更原因、变更活动和影响的需求条目，避免多版本并存导致开发与测试依据不一致。
当流程模型需要与需求池、任务和测试环节联动时，可以把活动说明表关联到需求条目，让需求、任务、测试用例共享同一套活动编号。ONES 的需求池与任务看板支持需求—任务—测试—缺陷的闭环管理，业务、产品与研发可以在统一视图中追溯需求与问题状态；具体如何把流程模型字段映射到工作项，需要按团队实际流程配置确认。
示例：一条订单异常处理流程如何建模
以下为演示情景，用于说明建模方法，不代表真实项目案例。
触发事件与结束状态：客户订单提交后系统校验失败，触发异常处理流程；结束状态分为“订单恢复处理”和“订单关闭并通知客户”两种。
泳道与角色划分：订单系统、客服岗、信用审核岗、仓储岗四条泳道。
主干活动与异常分支：订单系统校验订单信息→判断失败原因→信息缺失转客服补录→信用超限转信用审核→库存不足转仓储确认→各分支处理完成后回到订单系统重新校验。任一分支无法处理时进入订单关闭路径。
活动说明表片段：
| 编号 | 名称 | 负责人 | 输入 | 输出 | 业务规则 | 异常处理 |
|---|---|---|---|---|---|---|
| ORD-03 | 校验客户信用额度 | 信用审核岗 | 订单金额、客户信用记录 | 审核结论、额度占用记录 | 可用额度低于订单金额时转人工审批 | 信用记录缺失时转人工核验，核验不通过进入订单关闭 |
| ORD-04 | 确认库存可用量 | 仓储岗 | 订单明细、库存台账 | 库存确认结果 | 可用库存低于订单数量时标记缺货 | 缺货且无补货计划时进入订单关闭 |
由模型导出的验收条件：信用额度不足的订单必须进入人工审批且记录审批人；信用记录缺失时必须转人工核验并保留核验结果；库存不足的订单在关闭前必须通知客户并记录通知时间；每条异常分支处理后订单状态可回到重新校验环节。
这个示例的关键在于：例外路径不是附注，而是与主干活动一样有负责人、输入输出和处理去向。评审时按验收条件逐条核对，就能判断模型是否覆盖了实际处理方式。
完成检查：模型可以交付的判断标准
模型定稿前，用下面这份清单逐项核对。全部通过再提交评审或进入需求分解，未通过的项目记录责任人和修订期限。
- 路径完整性：每条路径都有明确起点和终点，没有悬空的活动或分支。
- 活动完整性：每个活动都有负责人、输入和输出，活动名称是动宾结构。
- 分支可判断：每个判断点有条件表达式和默认分支，例外路径有处理去向，没有“其他情况”式的模糊出口。
- 规则可确认：业务规则有明确判断依据，业务负责人已确认。
- 可追溯：每个活动能关联到需求条目，需求变更时能定位受影响的活动。
- 评审闭环：评审意见逐条有处理结论，修订记录包含变更原因和影响范围。
- 版本一致：当前使用的流程图、活动说明表和需求条目为同一版本。
这份清单同时可以作为评审会的议程：按路径走查、按活动核对字段、按分支确认例外，最后确认意见闭环。模型达到这些标准，就可以作为需求评审和后续开发的输入交付。
常见问题
流程建模时业务方只能口述、拿不到制度文件，活动说明表怎么填？
先按口述把活动、负责人和输入输出填出来，业务规则一栏标注“待确认”，并在走查会上逐条向业务负责人确认。制度文件缺失时，可以用现有表单、系统截图和实际处理记录作为规则依据，把确认结果记录在评审记录里。规则未确认的活动不进入需求分解，避免把推测写成确定规则。
当前流程和目标流程差别很大，是画两张图还是合成一张？
建议分开画。当前流程用于确认业务事实，目标流程用于确认系统要承接的动作，两张图各自保持完整路径，再用差异说明逐条列出新增、删除和调整的活动。合成一张图容易让评审者分不清哪些是现状、哪些是设想，差异点也难以对应到需求条目。差异说明应写明每个变更的原因和影响的活动编号。
流程模型和需求条目怎么关联，变更时怎么保证不脱节？
常见做法是在活动说明表中增加“关联需求编号”字段，或在需求条目中反向引用活动编号，保证双向可查。需求变更时，先按活动编号定位受影响的活动，再更新流程图和活动说明表，并在修订记录中写明变更原因和影响范围。工具层面，ONES 的需求池与任务看板支持需求—任务—测试—缺陷的闭环管理，业务、产品与研发可以在统一视图中追溯需求与问题状态；具体字段映射需要按团队实际流程配置确认。
建模深度怎么把握，什么时候需要展开到操作级？
深度由用途决定。用于需求澄清时，画主干活动和关键分支即可；用于系统建设时，需要展开例外路径、退回路径和人工干预点，因为这些路径直接决定系统要处理哪些状态。判断标准是：评审者能否依据模型判断系统承接范围。如果某个分支的处理方式会影响开发工作量或验收条件，就应展开到操作级；如果只是部门内部的事务性动作，可以保留在活动说明中而不画进图里。
评审会上开发和测试应该重点看什么？
开发重点看每个活动能否由系统承接、输入输出对应的数据对象是否齐全、分支条件是否可实现；测试重点看每条分支和例外路径能否导出测试场景和验收条件。评审时按路径逐条走查，比逐页看文档更容易发现遗漏。评审意见要逐条记录处理结论，未闭环的意见在检查清单中标记为未通过。
