业务流程图里的职责边界不清，通常不是抽象的管理问题，而是能在图上指出来的具体症状：一个节点挂着多个部门、审批人和执行人写在同一格、异常分支没有承接角色。发现它需要逐节点核对角色、动作、输入、输出和异常出口，把疑似缺口先记为假设，再由流程参与者确认；修正则要拆节点、定唯一责任角色、补交接物和异常出口，最后用一次端到端演练验证边界是否闭合。本文按这条路径展开，适用于跨部门流程评审前的自查和评审后的改图。
要点总览（TL;DR）
- 职责边界不清在流程图上表现为多部门共担一个节点、审批与执行混写、泳道归属与动作不符、异常分支无承接角色、交接缺输入输出物，可先对照症状清单逐项标记。
- 发现缺口靠逐节点填五栏核对表（角色、动作、输入、输出、异常出口），每个节点只允许一个责任角色，疑似问题先记为假设，再由流程参与者确认作为证据。
- 修正动作包括拆分多部门共担节点、指定唯一责任角色、补齐节点间交接物、为退回超时驳回等异常补上处理角色与去向，改图前留存原版本。
- 修正后用一次端到端演练验证每个节点有人负责、每个异常有出口，交接物需交出方与接收方双向认可。
- 把五栏核对表纳入后续流程评审的固定检查项，并明确流程图的版本与变更记录责任人，可减少问题复发。
职责边界不清在流程图上是什么样子
“边界不清”之所以难讨论，是因为它常被描述成感受，而不是图形事实。评审前先把问题落到可观察的症状上，排查范围就会收窄到具体节点，讨论也更容易形成结论。以下症状可以对照现有流程图逐项标记。
| 症状 | 图上表现 | 常见后果 |
|---|---|---|
| 多部门共担一个节点 | 一个框内写“由业务部、财务部共同审核” | 出问题时互相等待，无人拍板 |
| 审批与执行混写 | 同一节点既写“提交申请”又写“审批通过” | 无法判断谁对结果负责 |
| 泳道归属与动作不符 | 动作画在A部门泳道，文字却写B部门执行 | 读图人按泳道理解，实际执行走样 |
| 异常分支无承接角色 | 驳回、退回、超时箭头指向空白或直接回到起点 | 异常发生时流程停摆 |
| 交接缺输入输出物 | 两个节点之间只有箭头，没有表单、单据或系统状态 | 责任在节点之间悬空，交接靠口头 |
标记症状时还要区分两类问题。一类是图形表达问题：流程实际运行顺畅，只是图上画得含糊，修正方式是改画法。另一类是需求内容本身未定：某个环节到底由谁审批，业务上还没有结论，这时改图只是把未决问题画得更整齐，需要先回到需求澄清。评审中把两类问题分开记录，可以避免用改图掩盖尚未决策的事项。
逐节点核对：用五栏表找出边界缺口
症状清单告诉你哪里可疑，五栏核对表则把可疑变成可记录的缺口。做法是对流程图中每个节点填一行，五栏分别是角色、动作、输入、输出、异常出口。填写时坚持一条规则：每个节点只允许一个责任角色，协作角色单独标注在说明里，不与责任角色并列。
| 节点 | 责任角色（唯一） | 动作 | 输入 | 输出 | 异常出口 |
|---|---|---|---|---|---|
| 示例：费用报销初审 | 部门主管 | 核对发票与事由 | 报销单、发票 | 初审意见 | 驳回至申请人，超时提醒主管上级 |
| 示例：付款执行 | 财务出纳 | 按审批单付款 | 已审批报销单 | 付款凭证 | 账户信息有误退回申请人补正 |
表格中“示例”为演示情景，用于说明填写口径。实际核对时，异常出口一栏最容易空着，而它恰恰是边界问题的高发区：驳回之后谁处理、超时由谁升级、部分通过如何继续，这些都要落到具体角色和去向。
填表过程中会遇到大量“看起来知道、其实没确认”的判断。处理方式是分层记录：把疑似缺口先写成假设，例如“假设超时升级由部门主管发起，待确认”；再通过跨部门走查提问获取证据。有效的提问围绕三个点展开：这件事谁发起、谁审批、失败后谁处理。提问对象应覆盖每个节点的实际执行人，而不只是部门负责人，因为执行人对交接物的实际形态更清楚。参与者明确确认的内容记为证据，无人能确认的继续保留为待决项。
排查顺序建议先主干、后分支。主干流程节点少、参与人多，先把主干的角色和交接物对齐，再进入异常与退回分支。反过来先查异常分支，容易在主干尚未对齐时陷入细节争论。全部节点核对完成后，输出一份缺口清单，每条包含节点位置、缺口类型、当前假设、待确认对象和确认结果，作为后续修正的输入。
修正动作：拆节点、定角色、补交接与异常出口
缺口清单确认后进入改图。修正的核心动作有四类，按顺序处理可以减少返工。
第一，拆分多部门共担节点。拆分的依据是动作，而不是部门数量：把“共同审核”拆成“业务合规审核”和“费用标准审核”两个独立节点，各自有明确的判断标准和输出。拆分后节点数量会增加，但每个节点的责任变得可追溯。
第二，为每个节点指定唯一责任角色。原协作方写入节点说明或作为咨询角色标注，不再与责任角色并列。审批与执行混写的节点同样拆开，提交动作归申请人，审批动作归审批人，两者之间用交接物连接。
第三，补齐节点间交接物。交接物可以是表单、单据、系统状态或确认记录，要求是相邻两个节点都认可它的存在和形态。例如“初审意见”需要明确是纸质签字还是系统状态变更，接收方按什么标准判断可以进入下一节点。
第四，为退回、超时、驳回等异常补上处理角色与去向。每条异常箭头都应指向一个有责任角色的节点，或者指向一个明确的终止状态并说明通知谁。异常出口补齐后，流程图的箭头不再有悬空终点。
改图有两条风险边界需要交代。修改前留存原图版本，保留修改说明，便于评审时对照差异、必要时回退。涉及审批权限调整的修改，例如把某节点的审批人从部门负责人改为分管领导，应先与相关部门确认再落图，避免流程图先行、实际权限未变造成执行偏差。当某个缺口在评审中仍无法达成一致时，停止在该节点继续细化，把它列为待决事项带回业务侧澄清，其余已确认部分照常修正。
跨部门评审产生的缺口记录、修改说明和验证结论需要让参与方都能看到并持续跟进。在 ONES 中，这类记录可以保存为工作项或 Wiki 页面，评审结论与后续修改在同一处留痕；ONES Assistant 能结合项目与 Wiki 上下文回答相关问题，并把结果保存为工作项或 Wiki 页面，减少在多个页面间切换和重复录入。是否采用这类方式承载流程评审记录，取决于团队已有的协作工具和权限配置。
验证修正结果与防止再次模糊
改完图不等于边界已经闭合，需要用一次端到端流程演练来验证。演练从流程起点走到终点，逐节点确认两件事：每个节点有人负责，每个异常有出口。演练时可以让每个节点的责任角色说明自己收到什么、做什么、交给谁，出现说不清的地方即为未闭合点，回到修正环节处理。
交接物的验证要双向进行。相邻两个节点中，交出方确认自己产出的东西，接收方确认自己认可并能据此开展工作，双方对交接物的形态描述一致才算通过。只由一方确认的交接物，往往在实际执行中变形。
为防止问题复发，把五栏核对表纳入后续流程评审的固定检查项，新流程或流程变更在评审时都按同一口径逐节点核对。同时明确流程图的版本与变更记录责任人：谁负责发布新版本、谁记录变更原因、旧版本保存在哪里。验证完成后输出验证记录，包含演练发现的问题、处理结果和遗留待决项，与修正后的流程图版本一并归档。
这套方法适用于跨部门、节点较多、异常分支常见的业务流程。对于参与方单一、异常路径很少的简单流程，可以只做症状清单核对和关键节点的五栏填写，不必完整走一遍演练。无论采用哪种范围，判断边界是否清晰的标准是一致的：每个节点有唯一责任角色，每条路径有明确去向，每个交接物被双方认可。
常见问题
流程图上某个节点业务上还没定由谁审批，应该先改图还是先澄清？
先澄清。这类情况属于需求内容本身未定，改图只能把未决问题画得更整齐，无法形成真正的责任归属。建议在缺口清单中把它标记为待决事项，带回业务侧确认审批人，其余已确认的节点照常修正，避免整张图因一个未决点停滞。
跨部门评审时各方对某个节点的责任归属争执不下，怎么推进？
把讨论拉回到动作和交接物上：先确认这个节点具体做什么动作、接收什么输入、产出什么输出，再讨论由谁承担。若仍无法达成一致，停止在该节点继续细化，列为待决事项并指定确认对象和时限，其余节点按已确认结论推进。评审记录中保留争议点和各方意见，便于后续决策时有据可查。
只做主干流程核对、不查异常分支，会有什么风险？
异常出口是边界问题的高发区。主干看起来顺畅，但驳回之后谁处理、超时由谁升级、部分通过如何继续这些问题没有落到角色，流程在实际运行中容易在异常处停摆。建议先对齐主干，再进入异常与退回分支，至少为每条异常箭头确认一个有责任角色的去向或明确的终止状态。
修正流程图时涉及审批权限调整，需要注意什么？
先与相关部门确认再落图。例如把某节点的审批人从部门负责人改为分管领导，如果流程图先行、实际权限未变，执行时会出现图与实际不一致的偏差。同时留存原图版本和修改说明，便于评审时对照差异、必要时回退。
流程评审的缺口记录和修改版本如何留痕，方便后续跟进？
缺口记录、修改说明和验证结论需要让参与方都能看到并持续跟进。在 ONES 中，这类记录可以保存为工作项或 Wiki 页面，评审结论与后续修改在同一处留痕；ONES Assistant 能结合项目与 Wiki 上下文回答相关问题，并把结果保存为工作项或 Wiki 页面，减少在多个页面间切换和重复录入。是否采用这类方式承载流程评审记录，取决于团队已有的协作工具和权限配置。
