业务流程图
Business process flowchart
用明确起止、处理步骤、判断分支和交接，画出一项业务实际或拟议的处理路径。
当不同角色对工作怎样流转、异常返回哪里或何时算处理结束理解不同时使用。先界定起点与终点，再画动作和判断；跨角色交接写明输入、输出和等待状态。现状与改善草案分开，不用理想路径冒充真实操作。
业务边界、参与角色、记录支持的步骤、判断条件、异常与返回路径、输入输出和待确认交接。
带判断和返回条件的流程图、交接与等待清单，以及走查和核对任务。
先理解，再动手
使用步骤
先界定业务起止和状态，再用动作框、判断与标明答案的箭头连接。等待和返回需明确触发；现状与改进草案分开，不能凭图证明效率或授权。
- 01
写清从哪一事件开始，到什么记录或状态结束，确定现状还是拟议流程。
- 02
按参与角色列动作、输入和输出，给交接写清接收条件。
- 03
把判断写成可回答的问题，为每一答案连到明确路径。
- 04
画出补充、等待、取消等异常及返回条件，避免无条件循环。
- 05
让实际执行角色走查正常与异常案例，再修订图示并记录尚未确认的规则。
流程图说明处理路径，不证明效率、控制有效或服务完成。每条分支需有明确条件，等待不是已完成；复杂路径可拆成有边界的子流程。图示演示一个判断节点，其他决策需按实际业务另行展开，不能凭图补造步骤或权限。
看清框架结构
从一份空白提纲开始
复制到你的文档，填入真实的业务事实与判断。
查看空白提纲
业务流程图 · 空白提纲 什么时候用：当不同角色对工作怎样流转、异常返回哪里或何时算处理结束理解不同时使用。先界定起点与终点，再画动作和判断；跨角色交接写明输入、输出和等待状态。现状与改善草案分开，不用理想路径冒充真实操作。 需要准备：业务边界、参与角色、记录支持的步骤、判断条件、异常与返回路径、输入输出和待确认交接。 预期产出：带判断和返回条件的流程图、交接与等待清单，以及走查和核对任务。 使用边界：流程图说明处理路径，不证明效率、控制有效或服务完成。每条分支需有明确条件，等待不是已完成；复杂路径可拆成有边界的子流程。图示演示一个判断节点，其他决策需按实际业务另行展开，不能凭图补造步骤或权限。 工作问题： 期望结果： 已有证据与假设： 未知项与下一项核查： 填写说明：说明起点、终点、参与角色和现状或拟议性质。 1. 业务起止与状态： 填写说明：说明触发、接收角色、输入与记录。 2. 开始与受理： 填写说明：写可核对的问题与是/否成立条件，避免含糊判断。 3. 判断条件： 填写说明：写是分支动作、角色和终点，不将处理结束等同业务效果。 4. 是分支与终点： 填写说明：写待补或异常状态、跟进者和返回条件，不让等待消失。 5. 否分支与返回： 填写说明：保留取消、时限、未知规则和走查安排，区别计划与真实验证。 6. 交接异常与走查： 检查清单 □ 起止、图形和箭头含义清楚，判断条件可核对。 □ 正常与异常路径都有去向，等待与完成分开。 □ 现状、拟议路径与未确认规则未混写，走查尚未发生时不记作通过。 考虑下一个框架 RACI: 处理路径和交接已明确，但谁执行、谁最终负责仍有缺口时，用RACI逐项确认责任；流程箭头不能代替角色同意。 https://bizthinkframe.com/zh/frameworks/raci-matrix BizThinkFrame · https://bizthinkframe.com/zh/frameworks/business-process-flowchart
跟着案例走一遍
虚构教学案例把预约待补资料的返回路径画清楚
组织、人物、数据和结果均为虚构，仅用于说明框架用法。
背景与问题
虚构教学案例：松桥预约服务准备一项试点。共同底稿 F0 中，W0 同一队列有100个符合纳入条件的请求、60个确认预约、其中48个完成服务，观察均已结束。未来试点、人员投入与本页安排均未获批准或执行。
操作草案只有“受理—确认”，没有说明资料缺失时谁跟进，也把预约确认当成服务完成。
手头有哪些材料
- F0准备阶段拟订处理规则：运营受理请求并保留编号；须同时核实资料齐全与时段可用，才可确认预约。
- 缺资料或时段未确认时保留待补状态，运营跟进，申请人补齐或重新选择时段后再次核查；回复时限尚待约定。
- 此子流程从受理到确认或待补状态记录，不覆盖实际服务完成；取消需单列明确关闭记录。
如何使用这个框架
- 把终点限定为本次预约处理状态，指出服务完成在本图范围之外。
- 将受理和确认写为运营动作，把资料与时段的联合条件写入判断。
- 为是分支记录确认，为否分支记录待补、缺项与运营跟进。
- 只在申请人补齐或重选时段后返回判断；无回复不当作确认，取消另有关闭记录。
- 提出四种情形的走查，并保留尚未约定的回复时限和接收条件。
得到一张有是/否和返回条件的拟议流程图，以及待确认交接清单；没有认定流程更快或已实际执行。
这是一个判断节点的拟议子流程；预约确认与KPI中的服务完成是不同事件。等待、取消及未执行走查没有被当成处理成功。
连接方框前先排除三种流程问题
同一请求因为步骤或交接理解不同而流向不同结果时，可以画业务流程图。先定触发点和终点，再说明是在记录现状还是提出未来方案，不能不加说明就把两者揉在一起。
三种情况先停：判断没有可检查条件；回箭头只写“再试”，却没有新输入或触发；为了让路径整齐结束，把等待画成完成。规则不明确就写在旁边，不为补全图形而编期限或权限。
先切出有限子流程，再考虑其他组织活动。动作写明角色与产出；需要第二个判断，就单列问题和分支。现有图形只演示一个组合判断，下面用文字解释异常，不声称渲染器已画出更大的多判断系统。
画流程、改流程和量结果分别准备
流程图让大家检查工作如何流动，不能证明为什么延迟，也不能证明新方案更好。这些问题要观察记录或另做试验。
| 方法 | 输入材料 | 能得到什么 |
|---|---|---|
| 业务流程图 | 触发、角色、判断、交接及异常 | 有限路径与未决规则 |
| ECRS | 当前路径及必须保留的产出或控制 | 待评估的重设计候选 |
| 用户旅程图 | 人物任务及可归属的体验记录 | 触点与体验问题 |
| KPI树 | 同口径数量与定义 | 指标拆解，不是流程因果 |
完整案例：先定义四条走查，再实际执行
继续使用松桥F0虚构案例。完整W0批次有100次合格请求、60次确认预约，其中48次完成服务。这是背景，不是拟流程产生的效果；试点与人员仍未批准。子流程从申请人提交、运营记录请求ID和原始输入开始，到确认、待补资料或明确取消记录结束，不到服务完成。
组合判断为：资料完整，并且可用时段已核实？两项都真才走“是”。“否”由运营记录缺失或未核实内容并跟进；只有申请人补资料或给出新时段，才回到判断。收到回复不等于跳过检查，时段仍须核实；无回复就继续等待。
下面四张卡是虚构的拟走查输入，不是四次真实请求，更不是通过的测试报告。每张给出草案预期路径和待参与者确认的规则。取消是与预约不同的明确关闭。回复期限与交接接受条件尚不清楚，不能从图上推一个时限。
| 输入卡 | 草案预期路径 | 仍需核对 |
|---|---|---|
| 资料齐全，时段可用已核实 | 运营确认并记预约，受理结束 | 什么记录证明交接被接收？ |
| 缺少资料 | 记缺项、跟进、等重新提交 | 必填项是什么，回复怎样关联？ |
| 资料齐全，时段未核实 | 记时段问题，等新时段再检查 | 谁核实可用性并留下答案？ |
| 申请人取消 | 记录明确取消关闭 | 怎样通知并保留取消记录？ |
先核实交接，再讨论流程是否改善
结论是拟受理路径暴露了等待与交接缺口，没有证明处理更快或控制有效。负责人拟邀请运营和申请人代表逐卡走查，确认判断含义并约定什么叫接收。出席、同意和执行测试分开登记。
每次保留输入卡、参与者、版本、走过的箭头、终点应有记录及分歧。无人能解释谁核实时段，就保持未决，找适当责任人确认。拟跟进不变成无条件循环；提醒或到期规则要明确同意后再加，沉默本身不能授权确认或取消。
真实试点若获授权，按约定定义记录每条请求状态和时间，保留等待与取消项。确认预约计入预约数，服务完成要同批次的另一份证据。比较处理时间或错误，需要合适基线和完整观察条件。复查在原草案后追加发现与获准变更。即使四次走查做完，也只证明执行了走查，不证明异常已穷尽或服务已改善。
检查你的思考
再问自己几个问题
- 这个终点是一次处理结束，还是服务或收款完成？
- 否分支去哪里，什么时候能返回？
- 等待由谁跟进，哪些条件仍需确认？
完成前的检查清单
- 起止、图形和箭头含义清楚，判断条件可核对。
- 正常与异常路径都有去向，等待与完成分开。
- 现状、拟议路径与未确认规则未混写，走查尚未发生时不记作通过。
框架参考
参考资料说明框架定义与适用范围，不验证虚构案例的结果。