如何创建流程图
如何创建流程图：确定触发事件与结束状态，每个方框只写一个动作，把每一个“如果”变成带标签的决策，并让每条分支都有归宿。附一个可逐步查看的完整示例。
流程图呈现工作实际发生的顺序：一个触发事件、每个方框一个动作、每处分叉都有一个带标签的决策，以及每条分支上明确的结束状态。
简而言之
- 先确定触发事件和终点线；其余都是中间部分。
- 每个方框一个动作，用动词开头：“在应付账款系统中登记发票”，而不是“发票处理”。
- 每个决策都是一个问题，从它引出的每条出口都带标签。
- 每条分支要么汇回流程，要么以自己的终止符结束——不允许有悬在半空的线。
- 异常路径才是让这张图值回工夫的部分。
是什么让流程图成为流程图
多数人第一次画出来的流程图，其实算不上流程图。那只是一排用箭头连起来的矩形，描述的是一切都没出错的那个版本。这样的图不过是一份多加了几个步骤的检查表，这也正是为什么那么多流程图画完一次、打印出来，就再也没人看——顺利路径本来大家就都知道。价值在于这张图对其他所有路径说了些什么。
一张能用的流程图，语法很小但很严格。只有一个开始。每个方框一个动作，用动词开头来写，好让谁做什么一目了然。决策画成一个问题，每条出口都带标签，读的人才能看出自己该走哪一条。而每条分支要么汇回主流程，要么以自己的终止符结束——因为一条悬在半空的线，意味着没有人知道接下来会发生什么，而这恰恰是这张图本该解决的情形。
下面的示例是一个真实的发票审批流程，分五个阶段逐步搭建。留意每个阶段发生了什么：这张图正是在异常出现时才真正变得有用——重复的发票、与采购订单对不上的价格、退回供应商查询后又从上游重新汇入流程的那条路。这三条分支，就是这张图比检查表更有价值的全部理由。
看一张流程图是怎样搭起来的
一个真实发票审批流程的五个阶段。逐步查看——每一步都会补上流程图语法的下一块。
一个触发事件，一个起始步骤
任何流程图都只以一个开始图形起步，而且它命名的是一个事件而不是一项活动：发票送达，而不是“发票处理”。如果你的图有两个开始，那你画的其实是两个流程。
提出第一个问题
菱形是一个问题——“重复发票？”——两条出口都带标签。注意“是”这条分支并没有半途消失：它以自己的终止符结束，因为拦下一张重复发票是这个流程的一种正当结束，而不是图没画完。
只拆分真正不同的路径
有采购订单的发票要与采购订单和收货单做三方匹配；没有采购订单的发票则改为按成本中心记账。分成两条分支，是因为工作确实不同——而不是因为有人希望这张图看起来更周全。
把异常送回流程里
价格不一致会向供应商发起一次查询，问题解决之后，流程从采购订单核对处重新汇入，而不是从头开始。回到流程中段的环路很正常；不正常的是一条悄悄消失的异常分支。
以状态收尾，而不是以活动收尾
审批按金额分流，超过限额需要会签，图最终停在“已向供应商付款并已发出付款通知”——一个可以核实的状态。“处理付款”是一项活动，而活动永远不是终点线。
运作方式
先写下触发事件和终点线
在画任何方框之前：什么事件启动这个流程，什么状态代表它已经结束？这两句话确定了范围，而关于流程图的多数争论，最后都会发现争的是边界而不是步骤。终点线要写成一个状态——“供应商已收到付款”——而不是一项活动。
先把步骤列成行，而不是画成图
在 QueryChart 中新建一张图表，把步骤逐行填进 Box text 列，一行一个。忍住不要去排版。列表比图更容易拿来讨论，而布局是自动生成的——连线交由应用完成，所以你在这里手工摆的东西反正也留不下来。
用行号把各行连起来
Line to 列填的是下一个步骤的行号，所以第 2 行指向 3，箭头就画出来了。某个步骤通向不止一个去处时，用逗号分隔填写多个行号。在 QueryChart 中连接流程图就只有这些内容，这也是为什么从没用过绘图工具的人也能修改这张图。
把笔记里的每一个“如果”变成决策
凡是笔记里出现“如果”“除非”或“视情况而定”的地方，就把那一行的 Shape 设为 Decision，并把标签改写成一个问题。然后把答案填进 Line text 列——“是”“否”“超过 10 万元”——让每条出口都说明自己对应哪种情况。没有标签的分叉，是流程图读不下去的最常见原因。
画出异常路径
取每个决策的不顺利分支，把它一路跟到一个真实的结论：它是回到前面的某一步、移交给别人，还是就此终止？终止时给它一个终止符图形。这是大家会跳过的部分，也正是读者真正需要的部分——没有人会去翻流程图，只为搞清楚一切顺利时会发生什么。
和实际做这项工作的人一起走一遍
把图念给实际执行这个流程的人听，问他们哪里不对。要预料到会发现：某一个步骤其实是三个，以及某一条从来没有人写下来的分支。在行里改好，把图表分享出去，并给它加上审批，让大家看到的版本是达成一致的那一版，而不是别人幻灯片里的一张截图。
应避免的错误
把决策写成陈述句
“主管审批”是一个步骤；“主管是否批准？”才是一个决策。菱形如果读起来不像一个问题，从它引出的两条线就没法写出像样的标签，读的人只能猜哪一条适用于自己。
悬在半空的分支
每条线都必须落到某处：另一个步骤，或者一个终止符。一条就这样断掉的分支，是这张图在承认没有人知道那种情况下会发生什么——这值得知道，但应当去解决，而不是照原样画出来。
一个方框做三件事
“审阅并批准并归档”是三个方框，中间藏着两个可能出错的点。如果一个步骤的标签需要用“并”，它通常就不止一个步骤，而你看不见的那次交接，正是等待时间藏身的地方。
画出自己希望拥有的那个流程
先把现状流程画出来，连异常和变通做法一起，哪怕难堪。在还没有人对今天究竟发生什么达成一致之前就画出来的目标流程图，是一份提案，也应当标明它是提案。
创建你自己的流程图
从上面的发票审批示例开始，或者把它清空，把你自己的步骤填进各行。
相关指南
常见问题
画流程图需要哪些图形？
四种几乎就承载了一切：终止符用于开始和每一种结束状态，矩形表示一个动作，菱形表示一个决策，文档图形表示会产生记录的步骤——一张签署的表单、一份报告、一条写入日志的记录。QueryChart 另外提供 Reject 与 Success 两种终止符，这很实用，因为一张图通常不止一种结束方式，用不同颜色区分能让不顺利的结局一眼可见。
流程图应该画到多细？
细到让一个不做这份工作的人也能照着走下来，不必更细。一个实用的判断：如果某个步骤可以交给另一个团队而无需额外解释，那它就是一个方框。如果解释它要用上一整段话，那它多半是一个子流程，值得有自己的图并从这张图链接过去。十五到二十五个方框，是多数业务流程还能在一屏内读完的区间。
流程图和流程地图有什么区别？
流程图呈现顺序和逻辑：发生什么、按什么次序、经过哪些决策。流程地图在这个顺序之外补上背景——每个步骤归谁负责、在哪个系统里完成、输入什么、输出什么。实际上两者的差别主要体现在泳道上：当你按责任人把流程拆开的那一刻，你手上的就是一张流程地图，而对于任何跨越团队边界的事情，通常正是这个版本才值得拥有。
决策一定要是“是”或“否”吗？
不一定，但它们必须穷尽且互斥。按变更类型分成三条——标准、常规、紧急——完全可以，只要每一个申请都恰好落进其中一类。真正会毁掉一张图的，是某个决策带标签的出口没有覆盖所有情况，因为那位情况被漏掉的读者无处可去，只会自己发明一条路。