1. 一个具体问题

员工说报销很简单，只要提交材料就行。新同事实际办理时发现，缺少发票要退回、金额超限要加签、部门代码错误又要重新提交。口头上一个动作，现实里却有多条循环。没有共同流程图，大家很难确认问题到底发生在哪一步。

2. 一句话解释

流程图用节点、箭头和判断分支展示工作的实际路径，帮助人们理解顺序、责任交接、例外和返工，而不只是描述理想操作。

3. 出处与原意

流程图长期用于工业工程、计算机程序和质量管理，ASQ 提供了通用的绘制与分析方法。常见约定包括开始结束、活动、判断和输入输出等符号。符号有助交流，但图的首要标准是准确反映现实；不必为了形式规范把读者不理解的复杂符号塞满页面。

4. 原理与机制

先确定起点、终点和分析粒度，再让真正执行工作的人按一次实际案例描述步骤。判断节点的问题应能明确回答，分支写清条件；每条返工路径都要有去向。跨部门流程可用泳道标示责任，等待和系统自动处理也要显示。现状图和未来图应区分，不能在描绘现状时偷偷把不喜欢的步骤省略。

为判断节点命名时，最好使用可核对的问题，例如“材料是否齐全”，而不是“是否合适”。还应标出流程由谁发起、结束后留下什么证据，以及取消申请如何退出。没有这些出口，系统可能积累大量实际上已无人需要的待办。

5. 一个完整案例

以下是假设案例。团队绘制软件采购流程：提出申请、主管审批、预算核验、采购下单、账号开通。追踪一张真实申请后发现，预算不足会退回申请人，但申请人只收到“审批失败”，并不知道需要调整项目代码。图中因此出现申请、核验、退回的循环。团队把失败分支拆为预算不足与代码错误，对代码错误提供明确提示，并允许预算人员直接发起更正请求。试行后记录退回次数与总等待时间，确认是否减少循环。没有简单删掉预算核验，因为这一环节有实际控制目的。

6. 适用条件与反例

适合梳理多步骤、跨岗位以及例外较多的工作。不适合单凭一张流程图证明流程有效，仍需时间和质量数据。反例是所有判断分支都只画“通过”，不画拒绝、超时与补充材料；这张图容易展示，却恰好漏掉最常导致延迟的路径。

7. 今天可以尝试的行动

拿一张最近完成的工单，从进入到交付逐步画出来。每到一个判断点，补上没有发生的另一条路径；每次交接，问清接收者通过什么信号知道有工作。最后挑一个无明确出口的等待点，指定超时后的处理方式。

8. 参考资料与关联条目

关联条目：SIPOC 流程分析；价值流图。