业务流程建模要把“谁在什么条件下做什么、产出什么、交给谁”用一套可读、可评审、可追溯的方式固定下来，再转成需求条目。本文按定边界、识活动、画流程、补规则、处理异常、映射需求的顺序展开，给出每一步的输入、动作与产出，并附字段约定、角色分工、完整示例和完成检查清单。
要点总览（TL;DR）
- 业务流程建模从划定流程边界与触发条件开始，再按角色识别活动与交接，避免边画边改、范围失控。
- 六个步骤依次是定边界、识角色与活动、画主流程与分支、补输入输出与规则、处理异常路径、映射为需求条目，每步都有输入、动作、输出和完成标志。
- 建模前先约定图种、泳道划分依据和活动字段，活动编号、名称、执行角色、输入输出、业务规则、异常处理与关联需求要统一口径。
- 模型是否可交付，用完整性、角色权限一致性、输入输出与规则、异常覆盖、需求双向追溯五类检查项逐条确认。
- 流程节点与需求条目需要统一维护状态和追溯关系时，可借助 ONES 的需求池与工单机制承载，是否采用取决于团队协作方式与流程规模。
业务流程建模的核心答案与操作步骤
建模的起点是流程边界与触发条件。直接打开画图工具从第一个活动开始画，往往会在中途发现范围失控：有的分支牵扯到另一个部门，有的例外情况没人能说清，最后模型变成一张谁也评审不了的图。先把“这个流程从哪开始、到哪结束、什么事件触发它”写清楚，后面的活动识别才有稳定的范围。
一次完整的业务流程建模可以拆成六个步骤。每一步都有明确的输入、动作、输出和完成标志，做完一步再进入下一步，避免边画边改、反复返工。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 定边界 | 业务背景说明、流程发起人访谈 | 明确流程名称、触发条件、起点与终点、上游与下游流程 | 流程范围说明（一页以内） | 业务负责人确认范围，上下游接口无争议 |
| 2. 识角色与活动 | 流程范围说明、岗位职责、现有表单与制度 | 列出参与角色，按角色梳理各自执行的活动与交接点 | 角色清单与活动清单（含初步编号） | 每个活动都能对应到一个执行角色，无“大家共同负责”的活动 |
| 3. 画主流程与分支 | 活动清单 | 按发生顺序连接主流程，标出判断节点与各分支走向 | 主流程图与分支说明 | 从起点到终点存在完整路径，每个判断节点有明确条件 |
| 4. 补输入输出与规则 | 主流程图、业务规则文档 | 为每个活动填写输入、输出、业务规则与执行角色 | 带字段的活动说明 | 每个活动的输出能成为下游活动的输入，规则可被验证 |
| 5. 处理异常路径 | 活动说明、一线人员反馈 | 识别退回、超时、驳回、数据缺失等异常，补充处理路径 | 异常路径清单与对应流程分支 | 每个异常都有处理动作和结束状态 |
| 6. 映射为需求条目 | 完整流程模型 | 把需要系统支撑的节点转为需求条目，建立关联 | 需求条目清单与追溯关系 | 每个流程节点都能找到对应需求或明确标注为人工处理 |
建模深度按当前阶段控制。如果当前目标是支撑一次迭代的需求设计，画到“活动—分支—输入输出—异常”这一层就够用；如果目标是梳理跨部门流程体系，才需要继续展开到岗位级操作细节。一次画全企业所有流程，通常会导致模型长期停留在草稿状态，反而失去评审价值。
建模前要确定的表示方式与字段约定
同一张流程，不同人画出来符号含义不同，评审时就要花大量时间对齐“这个菱形代表什么”。建模前先约定图种、泳道依据和活动字段，团队产出的模型才能互相对照、复用和交接。
常用表示方式及其表达重点
流程图适合表达活动的先后顺序和判断分支，结构简单、业务人员容易读懂，适合范围较小的单角色或单部门流程。泳道图在流程图基础上按角色、系统或部门分区，能直观呈现“谁做什么、在哪里交接”，适合跨岗位协作流程。事件驱动的流程表示（如 BPMN）用事件、网关和消息流描述触发条件与系统间交互，适合需要精确表达条件分支、并行和异常事件的场景，但符号较多，需要评审方具备相应阅读基础。
选择时看两个条件：流程是否跨多个角色交接，以及是否需要精确表达事件触发和系统交互。跨角色流程优先用泳道图；涉及多系统消息往来、需要作为开发依据时，再考虑事件驱动的表示方式。
泳道划分依据
泳道可以按角色、系统或部门划分。按角色划分最能体现职责交接，适合岗位分工清晰的流程；按系统划分适合梳理系统间数据流转；按部门划分适合跨部门审批类流程。同一条流程内保持一种划分口径，混用会让交接点变得模糊。划分依据确定后写入建模约定，后续同类流程沿用。
活动字段约定
每个活动至少记录以下字段，字段名和填写口径在建模前统一：
| 字段 | 填写要求 |
|---|---|
| 活动编号 | 按“流程缩写-序号”规则编制，如 AP-01，全流程唯一 |
| 活动名称 | 动宾结构，如“提交采购申请”，同一流程内不重名 |
| 执行角色 | 具体到岗位或系统，不写“相关人员” |
| 触发条件 | 该活动开始的前置事件或状态 |
| 输入 | 执行该活动所需的数据、单据或信息 |
| 输出 | 活动完成后产生的数据、单据或状态变化 |
| 业务规则 | 约束该活动的判断标准，如金额阈值、审批层级 |
| 异常处理 | 退回、超时、数据缺失时的处理动作与去向 |
| 关联需求 | 对应需求条目的编号，用于追溯 |
命名与编号规则要提前定好：活动名称用动宾结构，避免“审批”“处理”这类无法区分对象的词；编号在流程内唯一，活动拆分或合并时保留原编号并标注版本，不直接复用旧编号。模型与需求条目的关联字段建议双向记录——活动上填需求编号，需求条目上回填来源流程与活动编号，评审时可以从任一侧查到另一侧。
角色分工与各环节交付物
模型停留在个人文档里，通常是因为没有明确谁提供事实、谁维护字段、谁评审、谁承接。把角色和交付物定下来，建模才是一项团队工作而不是个人作业。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 业务负责人 | 提供流程事实，判断业务规则是否成立，确认流程范围与关键分支 | 流程范围说明、规则确认意见 |
| 需求分析或业务分析人员 | 组织建模，维护活动字段与编号，保证模型与需求条目关联完整 | 流程模型、字段说明、需求条目清单 |
| 流程涉及岗位 | 确认本岗位活动、输入输出与交接细节，指出实际执行中的例外 | 活动确认意见、异常情况说明 |
| 评审人（业务负责人、设计或开发代表） | 检查流程完整性、规则可验证性与需求可落地性 | 评审记录与修改意见 |
| 设计与开发人员 | 承接需求条目，反馈模型在实现层面的疑问 | 需求澄清问题、实现约束说明 |
评审关注点按角色区分：业务负责人重点看流程是否符合实际业务规则、分支条件是否遗漏；岗位代表重点看活动描述与交接是否准确；设计开发代表重点看需求条目是否足以支撑设计与验收。向设计开发交接时，交付内容应包括流程模型、活动字段说明、需求条目清单以及异常路径说明，并注明哪些节点由系统支撑、哪些仍为人工处理。
当流程节点和需求条目需要在同一处维护状态与追溯关系时，可以借助 ONES 的需求池与工单机制：业务需求池承接流程中提出的业务诉求，产品需求池承接转化后的需求条目，工单与任务看板同步处理状态，使流程节点到需求、任务、测试、缺陷的链路可以连续追踪。是否采用平台承载，取决于团队已有的协作方式和流程规模。
示例：一条审批流程如何建模并转成需求
以下为演示情景，用于说明方法，流程和字段经过简化，不代表任何真实企业案例。
边界与触发条件
流程名称：采购申请审批。触发条件：员工在系统中提交采购申请。起点：提交申请；终点：审批通过并生成采购订单，或申请被驳回并通知申请人。上游为预算编制流程，下游为采购执行流程，本流程不展开供应商选择与合同签订。
泳道划分与活动清单
按角色划分三条泳道：申请人、部门负责人、采购专员。活动清单如下：
- AP-01 提交采购申请（申请人）
- AP-02 审核申请内容（部门负责人）
- AP-03 复核预算与采购合规性（采购专员）
- AP-04 生成采购订单（采购专员）
- AP-05 通知申请人审批结果（系统）
主流程、分支与异常路径
主流程为 AP-01 → AP-02 → AP-03 → AP-04 → AP-05。分支出现在 AP-02：申请金额不超过部门预算额度时直接进入 AP-03，超过额度时需部门负责人上级加签后再进入 AP-03。异常路径包括：AP-02 审核不通过退回 AP-01 修改；AP-03 发现预算不足时终止流程并通知申请人；AP-01 提交后 3 个工作日未处理时系统提醒当前处理人。
活动字段填写示例
| 字段 | AP-02 审核申请内容 |
|---|---|
| 活动编号 | AP-02 |
| 执行角色 | 部门负责人 |
| 触发条件 | 申请人提交申请且格式校验通过 |
| 输入 | 采购申请单（物品、数量、金额、用途） |
| 输出 | 审核意见与审核状态（通过/退回/加签） |
| 业务规则 | 金额不超过部门预算额度时直接通过；超过额度时转上级加签 |
| 异常处理 | 审核不通过退回 AP-01，附退回原因；3 个工作日未处理触发提醒 |
| 关联需求 | REQ-012、REQ-013 |
由流程节点导出的需求条目
- REQ-012：系统支持采购申请单提交与格式校验，校验不通过时提示具体字段。
- REQ-013：系统按申请金额与部门预算额度自动判断审批路径，超过额度时增加上级加签节点。
- REQ-014：审批退回时记录退回原因并通知申请人，申请人修改后重新进入审核。
- REQ-015：审批节点超过 3 个工作日未处理时，向当前处理人发送提醒。
- REQ-016：审批结束后向申请人通知结果，通过时生成采购订单并记录订单编号。
这个示例的适用边界是单类采购申请、审批层级固定为两级的情形。如果企业存在多级审批、按品类设置不同规则或需要与外部采购平台对接，模型需要补充更多分支和系统交互，需求条目也会相应增加。
模型评审与完成检查
模型是否达到可交付状态，可以用一组可逐项核对的检查项判断。评审时按清单逐条确认，未通过项记录为遗留问题并明确处理人和时间。
| 检查类别 | 检查项 | 通过标准 |
|---|---|---|
| 完整性与连通性 | 是否存在断头路径、无出口分支、无入口活动 | 从起点到每个终点都有完整路径，每个判断节点所有分支都有去向 |
| 角色与权限一致性 | 活动执行角色是否与岗位职责、系统权限一致 | 每个活动有唯一执行角色，跨角色交接点明确 |
| 输入输出与规则 | 输入输出是否衔接，业务规则是否可验证 | 上游输出能作为下游输入，规则有明确判断标准 |
| 异常与边界条件 | 退回、超时、驳回、数据缺失是否覆盖 | 每类异常有处理动作和结束状态 |
| 需求追溯 | 流程节点与需求条目是否双向可追溯 | 每个需系统支撑的节点有对应需求，每条需求能回指来源活动 |
评审通过的标准是：上述检查项全部通过，或未通过项已记录为遗留问题并明确责任人与处理时间。遗留问题不影响当前阶段需求设计时，可以先放行并在模型中标注；影响关键分支或规则判断的，应在进入设计前解决。评审记录与模型版本一并归档，后续流程变更时从同一份模型上修订，保持追溯关系连续。
常见问题
流程边界一时定不下来，能不能先画主流程再补范围？
可以先画一版草图帮助讨论，但不要把它当作评审版本。边界不清时，活动识别会不断牵扯出新部门和例外情况，模型反复扩张。更稳妥的做法是先和业务负责人确认三件事：流程名称、触发事件、起点与终点，并写明上游和下游流程各是什么。范围说明控制在一页以内，上下游接口没有争议后再进入活动识别。若边界确实存在争议，把争议点记录为待定项，先按已确认部分建模，待定部分单独标注。
泳道按角色分还是按系统分，同一条流程能混用吗？
按角色划分最能体现职责交接，适合岗位分工清晰的流程；按系统划分适合梳理系统间数据流转；按部门划分适合跨部门审批类流程。同一条流程内建议保持一种划分口径，混用会让交接点变得模糊，评审时难以判断某个活动到底由谁执行。如果一条流程既要表达岗位职责又要表达系统交互，可以主模型按角色划分，另附一张系统交互说明，两张图通过活动编号对应。
异常路径要补到什么程度才算覆盖完整？
至少覆盖退回、超时、驳回、数据缺失这几类常见情况，每类异常都要有处理动作和结束状态，不能停在“异常时另行处理”。判断标准是：沿异常路径能走到一个明确的终点，比如退回修改后重新进入审核、超时后提醒当前处理人、预算不足时终止并通知申请人。一线人员反馈的实际例外是重要来源，建模时逐条确认是否纳入当前范围，暂不纳入的记录下来，避免评审时才发现遗漏。
流程节点转成需求条目后，怎么保证后续变更还能对上？
关键是双向记录：活动上填关联需求编号，需求条目上回填来源流程与活动编号，评审时从任一侧都能查到另一侧。流程变更时从同一份模型上修订，保留原编号并标注版本，不直接复用旧编号，需求条目同步更新关联关系。当流程节点和需求条目需要在同一处维护状态与追溯关系时，可以借助 ONES 的需求池与工单机制，让业务需求、产品需求、任务与测试的链路连续追踪；具体承载方式取决于团队已有的协作习惯和流程规模。
模型评审没全部通过，能不能先进入设计？
取决于未通过项影响的范围。不影响当前阶段需求设计的遗留问题，可以先放行并在模型中标注，明确责任人与处理时间；影响关键分支、规则判断或角色权限的问题，应在进入设计前解决，否则设计和开发会基于不完整的模型做判断，返工成本更高。评审记录与模型版本一并归档，后续流程变更时从同一份模型上修订，保持追溯关系连续。
