流程图是用标准化形状和箭头按顺序表示流程或工作流的图表。每种形状有特定含义：椭圆标注流程的开始和结束，矩形表示需要执行的操作，菱形表示路径分叉的决策点，箭头表示流向。
流程图是历史最悠久、使用最广泛的图表形式之一——出现在业务流程文档、软件工程、制造业、医疗和教育领域。原因很简单：它把存在于人脑或冗长书面程序中的流程变得一目了然。
为什么流程图有效
流程图的力量不仅仅是视觉化。当你试图画出一个你以为已经理解的流程时，很快就会发现其中的漏洞：没有人负责的步骤、从未真正定义过的决策、通向死路的路径。
流程图强迫你精确表达。你无法从一个步骤画出箭头，除非你知道它指向哪里。你不能让一个菱形只有一个出口。格式本身的约束，暴露了自然语言描述中隐藏的模糊性。
这就是为什么组织在构建事物之前会使用流程图——无论是软件系统、客服流程还是生产线。在白板上发现的错误几乎没有成本。在生产环境发现的错误成本极高。
流程图符号及含义
| 符号 | 形状 | 含义 |
|---|---|---|
| 终止符 | 椭圆 | 流程的开始或结束 |
| 处理步骤 | 矩形 | 一个动作、任务或步骤 |
| 判断 | 菱形 | 是/否或真/假分支 |
| 数据 | 平行四边形 | 接收的输入或产生的输出 |
| 流向线 | 箭头 | 步骤之间的方向 |
| 文档 | 波浪底矩形 | 产生或使用的文件 |
| 数据库 | 圆柱体 | 存储在数据库或文件中的数据 |
| 连接符 | 圆圈 | 在同一图表的另一部分继续 |
| 跨页引用 | 五边形 | 在不同页面继续 |
| 手动输入 | 斜顶矩形 | 由人工手动录入的数据 |
前五种形状——终止符、处理步骤、判断、数据和流向线——覆盖了你会遇到的大约 95% 的流程图。其余的是专业符号，主要出现在技术文档中。
流程图的类型
不同场景适合不同结构的流程图：
流程图（基本型）。 步骤从上到下或从左到右流动，带有决策分支。用于记录任何线性或分支流程。
泳道图。 同样的流程，但划分为横向或纵向的泳道——每条泳道对应一个人、团队或系统。展示每个步骤的责任归属，让各方之间的交接清晰可见。适合多人或多部门参与的情况。
数据流图（DFD）。 聚焦于数据在系统中的流动：数据从哪里来、哪些处理过程对它进行转换、存储在哪里。用于软件和系统分析。
工作流图。 比标准流程图更宽松、不那么严格标准化，常用于业务流程建模，强调步骤和责任归属而非技术精确性。
跨职能流程图。 类似于泳道图，专门用于展示工作如何在组织的不同职能部门之间流转。
对于大多数用途，标准流程图或泳道图就够了。更专业的类型（DFD、BPMN）是特定专业场景下的工具。
真实世界的流程图示例
客服工单处理流程
支持团队用流程图记录工单处理方式：
- 开始： 客户提交工单
- 判断： 是否为账单问题？→ 是：转至账单部门。否：继续
- 判断： 是否为技术问题？→ 是：转至技术支持。否：继续
- 步骤： 分配给第一位空闲的普通客服
- 步骤： 客服在 SLA 时限内响应
- 判断： 首次接触解决？→ 是：关闭工单。否：升级处理
- 结束： 工单关闭，通知客户
没有流程图，同样的流程需要在客服很少会一致阅读的多页程序文档中描述。图表把它压缩成一页可以随时参考的内容。
软件部署流程
开发团队梳理发布流程：
- 开发者将代码合并到主分支
- CI 系统运行自动化测试
- 判断：测试通过？→ 否：通知开发者，拒绝合并。是：继续
- 构建产物并推送到预发环境
- QA 团队在预发环境验收
- 判断：QA 通过？→ 否：返回开发阶段。是：继续
- 开启监控后部署至生产环境
- 结束：发布完成
流程图让每道关卡都变得明确——没有通过自动化测试和 QA 验收，代码不会进入生产环境。
新员工入职流程
HR 记录入职顺序：
- 员工接受 offer
- IT 开通账号（邮箱、工具、权限）
- 判断：远程还是现场办公？→ 不同的欢迎流程
- 主管分配入职导师
- 第 1 周：岗前介绍和工具培训
- 第 2-4 周：岗位专项培训
- 30 天 HR 回访
- 结束：入职完成
通过把流程图化，团队发现远程/现场的判断发生在账号开通之前——这意味着 IT 需要在开始工作前就知道员工的工作地点。
电商订单处理
网店梳理从下单到交货的全流程：
- 客户下单
- 判断：支付成功？→ 否：通知客户，订单取消。是：继续
- 判断：商品有库存？→ 否：通知客户，提供替代方案。是：继续
- 订单发至仓库拣货和打包
- 判断：特快配送？→ 不同的运输路线
- 发货，向客户发送快递单号
- 结束：确认送达
这张流程图揭示了库存是在支付成功之后才检查的——这是常见的设计选择，但值得有意识地去决定。
如何创建流程图
第一步：定义范围。 起始事件是什么，结束状态是什么？要具体。「客服流程」太宽泛。「一级支持工单从提交到关闭的流程」才是可以实际画出来的范围。
第二步：列出所有步骤。 在动手画之前，把所有操作和决策写成编号列表。这能防止你在画图过程中才发现遗漏了某个步骤。
第三步：识别决策点。 检查列表，标出所有有多个可能结果的步骤。这些步骤在图中变成菱形。
第四步：画出流程。 从起点开始，放置形状，用箭头连接。每个菱形需要带标注的出路箭头（是/否，或描述性标注）。
第五步：检查完整性。 每条路径都应该有终点。一个决策分支在没有到达终止符的情况下就结束，说明你的流程有漏洞。
第六步：与实际执行者确认。 流程设计者和流程执行者往往有不同的认知。把流程图展示给真正做这项工作的人，问他们是否准确。
常见错误
用错形状。 菱形代表决策。如果因为视觉上好看就把菱形用于普通操作步骤，读者会以为有分支。
决策出路没有标注。 菱形的每条出路都需要标注。没有标注，读者只能猜测哪条是「是」哪条是「否」。
箭头交叉太多。 箭头频繁交叉时图表很难跟读。重新整理布局，让主流程沿一个方向流动。
没有开始和结束。 没有明确标注开始和结束的流程图没有定义清晰的范围。
步骤承载过多。 一个步骤需要五行说明，说明它做了不止一件事。把它拆开。
流程图 vs. 其他图表类型
| 场景 | 更合适的工具 |
|---|---|
| 需要展示多团队流程中谁负责什么 | 泳道图 |
| 探索想法，还没有固定顺序 | 思维导图 |
| 展示软件组件之间的连接关系 | 系统架构图 |
| 展示数据库的结构 | ER 图 |
| 展示系统之间随时间的消息交互 | 时序图 |
| 规划有任务和截止日期的项目 | 甘特图 |
当需要记录有明确顺序和一个或多个决策点的流程时，用流程图。当问题涉及结构、时序、责任归属或探索时，换用其他工具。
常见问题
用什么软件画流程图？ draw.io 完全免费，功能无限制。Lucidchart 有支持实时协作的免费版。CodePic 免费且无数量限制，通过 AI 可以用自然语言描述生成流程图。
流程图应该有多少个形状？ 没有硬性规定，但如果一张流程图有超过 20-30 个形状，且在可读的尺寸下无法放在一屏内，考虑用连接符把它拆分成子流程。
流程图和流程地图有什么区别？ 大多数情况下这两个词可以互换使用。严格来说，「流程地图」有时暗示更宽松、不那么严格标准化的图表，更强调利益相关方和指标，但在日常使用中含义相同。
流程图应该从上到下还是从左到右？ 从上到下更常见，对大多数读者来说也更自然。从左到右有时用于强调「时间推移」感的流程。两者都可以——重要的是在同一张图内保持一致。
