业务流程建模可以按“定范围—收事实—画现状—标问题—设目标流程—补规则与异常—评审定稿”推进。关键是把流程画成能支撑需求表达和验收的文档：先明确要回答的业务问题与流程边界，再用访谈、观察和单据还原实际执行方式，最后补齐规则、异常路径和需求追踪关系。下文给出每一步的输入、做法与产出，并附一个采购申请审批的演示示例和完成检查清单。
要点总览（TL;DR）
- 业务流程建模按“定范围—收事实—画现状—标问题—设目标流程—补规则与异常—评审定稿”推进，每一步都有明确产出。
- 建模前先写清要回答的业务问题、流程起止边界、涉及角色与系统，并确定端到端还是子流程粒度。
- 现状流程靠访谈、现场观察和单据、系统记录还原，区分规定流程与实际执行流程。
- 目标流程要逐节点对照现状，补齐判断规则、异常路径和表单字段，并建立节点与需求的追踪关系。
- 交付前用检查清单核对边界、规则、异常、需求追踪和共同确认，定稿后登记变更。
先定建模目标与流程边界
建模启动前先写清“这次建模要回答什么问题”。常见目标有三类：审批慢，需要找出等待和空转环节；交接丢单，需要查清跨角色传递中的信息断点；规则不清，需要把判断条件和例外情况说明白。目标不同，图的画法和收集信息的重点也不同。把目标写成一句话，例如“查清采购申请从提交到下单平均耗时偏长的原因”，后续每个节点都能对照这句话判断是否相关。
边界要同时确定三件事：流程起点和终点、涉及的角色与系统、建模粒度。起点终点用可观察的事件描述，例如“员工提交采购申请”到“采购订单下达供应商”。角色按实际承担动作的岗位列，不按部门列；系统列出流程中需要操作的业务系统。粒度上，端到端流程用于看清跨部门交接，单个子流程用于细化某个环节的操作规则。一次建模通常先画端到端，再对问题集中的子流程单独展开。
本步产出是一页流程范围说明，包含：目标问题、起止边界、涉及角色与系统、建模粒度。范围说明需要业务负责人确认，避免建模过程中不断扩张。
收集事实：访谈、观察与单据证据
流程信息不能只靠管理者口述。访谈对象至少覆盖三类人：一线执行者，清楚实际操作中的变通做法；审批人，清楚判断标准和退回原因；下游接收方，清楚交接时最常缺什么信息。访谈时让对方按最近一次真实业务从头讲一遍，记录每个环节的输入、动作、输出和等待时间，比笼统问“流程是怎样的”更容易得到细节。
现场观察和系统记录用于校验访谈内容。观察一次完整业务的实际流转，注意纸质单据、聊天消息、口头确认这些系统外的传递方式。系统操作记录可以看状态停留时长、退回次数和字段填写情况，帮助发现访谈中被忽略的等待。表单、审批单、邮件和系统状态截图作为证据留存，后续标注问题时可以直接引用。
收集过程中要区分规定流程与实际执行流程。制度文件写的是应然路径，访谈和观察得到的是实际路径，两者不一致的地方往往正是问题所在。事实清单按环节组织，每个环节记录：输入、执行人、动作、输出、耗时、常见例外。清单完成后请被访谈者复核一遍，确认没有遗漏。
画现状流程：符号、泳道与判断分支
现状图的作用是让业务、产品、开发看到同一张图时理解一致，因此符号要统一。常用元素包括：开始与结束事件、活动（矩形）、判断（菱形）、并行分支、文档节点和系统节点。团队可以沿用既有规范，但同一份文档内符号含义必须一致，并在图旁附符号说明。
泳道按角色或系统划分，一条泳道对应一个承担动作的主体。活动画在真正执行它的泳道里，跨泳道的连线表示交接。判断分支从菱形引出，每条分支标注条件，例如“金额≤5000”“金额>5000”；回流路径用箭头明确指回哪个节点，避免出现无来源的循环。等待、返工和人工传递点用注释或颜色标出，这些位置通常是后续问题分析的入口。
画完后配一张节点说明表，逐节点写明执行人、输入、动作、输出和使用的系统。图负责展示结构，表负责承载细节，两者一起构成现状流程交付物。图不宜塞入过多文字，规则和字段放到说明表里。
标注问题并设计目标流程
在现状图上逐节点标注问题，常见类型包括：等待时间长的审批空转、同一信息在多处重复录入、跨角色交接缺少必要字段、判断规则依赖个人经验。每个问题标注位置、表现和影响对象，例如“财务复核节点平均等待两天，原因是发票信息需回到申请单手工核对”。
针对每个问题提出改法，改法要具体到动作层面：合并相邻审批、把校验前置到提交环节、用系统自动带出已有数据、把模糊判断改成明确规则、取消无实际决策价值的节点。改法与原问题一一对应，形成问题—改法对照表，写清改动内容、涉及角色和涉及系统。
| 现状问题 | 改法 | 影响角色/系统 |
|---|---|---|
| 申请单与发票信息重复录入 | 提交时上传发票，系统自动带出金额与供应商 | 申请人、财务、采购系统 |
| 金额判断依赖审批人经验 | 按金额区间设定审批路径，规则写入系统 | 审批人、流程配置 |
| 跨部门交接缺预算科目 | 申请单增加必填预算科目字段 | 申请人、财务 |
目标流程画完后与现状逐节点对照，说明哪些节点保留、哪些合并、哪些新增、哪些取消，以及改动后角色工作量与系统操作的变化。对照结果需要让受影响的角色确认可执行。
补齐业务规则、异常路径与数据字段
流程结构确定后，补充让流程可执行的细节。关键判断节点逐条写业务规则：判断依据的字段、取值条件、命中后的走向，以及规则由谁维护。规则写成可核验的条件句，例如“申请金额大于5000元且预算科目为设备类时，增加部门负责人审批”。
异常与退回路径要单独列出：材料不全退回哪一步、审批超时如何处理、供应商无法供货时流程如何终止或改道、重复提交如何识别。每条异常写明触发条件、处理动作和责任人。流程中流转的表单字段、状态值和数据归属同样要写清，包括字段由谁填写、在哪一步变为必填、状态如何流转。
最后建立节点与需求的对应关系。每个流程节点关联到对应的用户故事、用例或验收条件，形成节点—需求追踪表。这样开发实现和测试验收都能回到具体节点，流程改动时也能快速判断影响哪些需求。
角色分工与评审定稿
建模过程需要明确四类职责。业务负责人确认目标问题和范围，并对目标流程的业务合理性负责；流程执行者提供事实、复核现状图、确认改法可执行；产品/需求人员组织建模、维护流程图与规则说明、建立需求追踪；开发与测试评估系统改动可行性，并从实现和验收角度提出问题。
评审前提交的材料包括：范围说明、现状泳道图与节点说明表、问题—改法对照表、目标流程图、规则与异常说明、节点—需求追踪表。评审关注点按材料对应：边界是否清楚、现状是否与实际一致、每个问题是否有对应改法、判断节点规则是否完整、异常是否覆盖、节点能否追踪到需求。
评审意见逐条记录，标明提出人、处理结论和修改位置；流程图与说明表同步更新版本号。定稿后进入变更管理：流程或规则发生调整时，登记变更原因、影响节点和受影响需求，重新确认后再发布新版本。流程文档、评审记录和需求条目如果分散在多个工具中，容易造成版本不一致；ONES 提供统一的需求池与工单、任务看板，可将需求、任务与测试关联起来追溯，流程文档和评审结论也可在知识库中留存，便于业务与研发按同一版本协作。
一个审批流程的建模示例
以下为演示情景，用于说明产出形态，不对应真实客户案例。背景：某公司采购申请审批流程，目标是查清从提交到下单耗时偏长的原因。
范围说明示例：目标问题为“审批周期长、退回率高”；起点为员工提交采购申请，终点为采购订单下达供应商；涉及角色为申请人、部门负责人、财务复核、采购执行；涉及系统为申请表单、审批系统、采购系统；粒度为端到端流程，财务复核子流程单独展开。
现状问题标注示例：财务复核节点等待时间长，原因是发票信息需回到申请单手工核对；金额判断依赖审批人经验，不同审批人要求补充的材料不一致；跨部门交接时预算科目经常缺失，导致退回。目标流程改动示例：提交环节增加发票上传并自动带出金额与供应商；按金额区间配置审批路径；预算科目设为必填字段。
规则与异常示例：金额大于5000元且预算科目为设备类时增加部门负责人审批；材料不全退回申请人补充，保留已填内容；审批超过两个工作日未处理时提醒审批人并通知申请人。需求追踪示例：节点“财务复核”关联用户故事“财务可在一个页面核对申请单与发票信息”，验收条件为金额、供应商、预算科目三项一致时可直接通过。
完成检查：流程模型是否可用
交付前按清单逐项核对，每项都要有明确结论，不能以“基本清楚”代替。
| 检查项 | 通过标准 |
|---|---|
| 边界完整 | 起点终点为可观察事件，范围说明经业务负责人确认 |
| 角色与输入输出完整 | 每条泳道有对应角色，每个节点写明输入、动作、输出 |
| 判断规则明确 | 每个判断节点有取值条件和走向，无“视情况而定”的模糊分支 |
| 异常路径覆盖 | 退回、超时、终止等异常均有触发条件与处理动作 |
| 需求可追踪 | 每个节点能对应到用户故事、用例或验收条件 |
| 共同确认 | 业务负责人、执行者、产品、开发与测试均完成评审并记录意见 |
| 版本可管理 | 定稿版本有编号，变更登记表记录原因与影响范围 |
清单全部通过，流程模型即可作为需求表达和后续验收的依据交付使用。
常见问题
业务流程建模应该先画端到端流程，还是直接细化某个子流程？
通常先画端到端流程，再对问题集中的子流程单独展开。端到端流程能看清跨部门交接和整体耗时分布，帮助判断问题出在哪个环节；如果一开始就钻进子流程，容易把局部操作画得很细，却看不出上下游的等待和返工。若建模目标已经非常明确，例如只查清财务复核环节的退回原因，也可以直接以该子流程为起点，但范围说明里要写清它与上下游的衔接关系。
访谈得到的流程和制度文件写的不一致，建模时以哪个为准？
现状图以实际执行流程为准，制度文件作为对照参考。两者不一致的地方往往正是问题所在，例如制度要求两级审批，实际执行中常因金额小被口头跳过。建模时把差异记录下来，在问题标注环节说明差异的表现和影响，再在目标流程设计中决定是让执行回归制度，还是把实际做法固化为新规则。这个判断需要业务负责人参与，不能由建模人员单方面决定。
流程中的判断节点规则写不完整，会带来什么影响？
判断规则不完整，开发和测试只能按理解实现，验收时容易出现“按规则通过、按实际不通过”的争议。每个判断节点至少要写清判断依据的字段、取值条件、命中后的走向，以及规则由谁维护。遇到确实无法一次定清的规则，可以标注待确认并指定确认人和时间，避免用“视情况而定”留在定稿版本里。
流程模型定稿后，业务规则发生变化怎么处理？
定稿后进入变更管理：登记变更原因、影响节点和受影响需求，重新确认后再发布新版本。流程图、节点说明表和节点—需求追踪表要同步更新版本号，避免不同角色手里拿着不同版本。变更影响范围较大时，建议重新组织一次小范围评审，让受影响的执行角色确认改动可执行。
流程文档、评审记录和需求条目分散在不同工具里，怎么保持版本一致？
分散存放时，常见问题是流程图更新了而需求条目没改，评审结论也找不到对应版本。可以指定一个承载流程文档与评审记录的位置，并让需求条目与流程节点建立对应关系。ONES 提供统一的需求池与工单、任务看板，可将需求、任务与测试关联起来追溯，流程文档和评审结论也可在知识库中留存，便于业务与研发按同一版本协作；具体配置方式需结合实际版本确认。
