如何绘制一条业务流程
如何端到端绘制一条业务流程：先约定边界，访谈真正执行工作的人，把包含异常在内的现状画出来，然后逐一验证。附一个可直接操作的采购到付款示例。
绘制业务流程，就是就它从哪里开始、到哪里结束达成一致，弄清这两点之间实际发生了什么，并把它记录成一张执行工作的人愿意认可的图。
简而言之
- 把范围表述成两个事件——一个触发条件和一个终止状态——而不是一个主题领域。
- 访谈真正执行工作的人，并专门追问异常情况。
- 先画现状。在没有人对“今天是怎样”达成一致之前画出的未来流程，只是一份提案。
- 把外部相关方放进各自的泳道：等待供应商的时间也算在您的周期时间里。
- 验证的方式是与每一位泳道负责人逐步走一遍，然后只保留一个已批准的版本。
在您动笔之前就已经出错的事
流程绘制在任何人动笔之前就已经出错了。当范围被表述成一个题目——“梳理采购”——而不是两个事件时，它就错了：每一次访谈都会带出另一条流程，图不断长大，直到它描述的是整家公司。先把边界钉死：这条流程从开出请购单开始，到供应商收到货款结束。这两个事件之外的一切，都是别人的图。
第二类失败出在取材上。依据书面政策画出来的图，记录的是应该发生什么；依据系统画出来的图，记录的是系统允许什么。两者都不是流程本身。流程要从真正在跑它的人那里得到，尤其是要问他们：正常路径走不通时，你们会怎么做。变通做法不是杂音，它就是流程，而风险通常正落在那里。
下面的示例是一条跨五条泳道（含供应商）的采购到付款流程。逐步走一遍，看看一张完整的图在顺利路径之外还包含什么：阻止资金被提前占用的关卡、工作离开公司的那个节点，以及采购订单、收货记录与发票三者对不上时形成的异常队列。
一条端到端绘制出来的业务流程
跨五条泳道的采购到付款流程，分五个阶段搭建——先是边界，然后是控制关卡，最后是异常。
钉死边界
图从“识别采购需求”开始，并将在付款处结束。两个事件，先于其他一切写下来——因为“供应商选择算不算这条流程的一部分”这场争论，现在吵要便宜得多。
找出控制关卡
主管批准、预算可用性，随后是一道按金额把事项转给财务总监的阈值。控制关卡正是业务流程图最常被用来暴露的东西，而那道金额阈值的判断，能看出授权矩阵与实际做法是否一致。
标出工作离开公司的位置
寻源转入采购部门，再转入供应商自己的泳道。交付步骤分成两条各自独立推进的支线——货物进来、发票进来——这是这条流程真实存在的特征，在一份线性清单里根本看不见。
画出异常，而不只是顺利路径
三单匹配是发票去送命的地方。不匹配的分支退回采购部门，改正之后重新进入匹配：一张诚实的图会把这个回路画出来，因为周期时间实际上就花在这个回路里。
在您承诺过的那个事件上结束
“付款已放行给供应商”——正是第一阶段命名的那个终止状态。一张停在自己声明的边界以外的图，是一张在绘制过程中范围发生了漂移的图。
运作方式
把范围写成两个事件
“从开出请购单开始；到供应商收到货款结束。”一句话，在任何访谈之前，与提出绘图需求的人达成一致。如果大家对边界有分歧，这个分歧就是第一个发现，而且现在解决比画完三版之后再解决便宜得多。
确定泳道以及泳道里的人
列出工作会经过的角色，包括外部相关方，并为每条泳道找到一位真正在执行这些步骤的人，而不是一位在管这些步骤的人。四到五条泳道；如果您需要八条，说明范围太宽，应当在一次交接处拆开。
访谈要冲着异常去，而不是冲着常规
顺利路径人人都能讲，而问题很少出在那里。要问的是：预算科目缺失时你们怎么办？审批人休假时怎么办？发票先于货物到达时怎么办？这些答案就是那些分支，而且它们几乎从不写在别的任何地方。
用行搭出现状，泳道留到最后
把步骤录入 QueryChart 成为一行行内容，用“连线至”列把它们连起来，然后给每一行指派一条负责人泳道和一个阶段。在操心排版之前先把顺序理对，能让讨论一直停在流程上；图表会自行从行里组装出来。
量度交接
对每一次跨泳道的流转，记下下一条泳道是怎么知道自己有活的，以及它通常要等多久。写进这个步骤的备注里。大多数业务流程的周期时间是排队时间而不是作业时间，而队列恰好就排在这些边界上。
验证、批准，并只保留一个版本
与每一位泳道负责人逐步走一遍完成的图，把他们不认可的地方改掉。然后在 QueryChart 里让它走完审批，这样就有一个带签署和日期的现行版本，而不是一份在工作坊结束第二天就开始与现实脱节的 PDF。
应避免的错误
把范围表述成一个题目
“梳理采购”没有边界，于是每一次访谈都会在两端各加一个步骤。两个事件，写下来，达成一致。别的都可以商量，这一条不行。
照着政策文件画
政策是某个人的意图。图要记录的是实际发生了什么。两者不一致的地方，那道差距正是整个练习最有用的产出——所以不要靠把政策画出来，悄无声息地把它抹平。
把外部相关方留在图外
如果流程要等供应商或客户，他们就该占一条泳道。否则这张图会暗示延迟发生在内部，改进的力气也就用错了地方。
一张图，用到永远
流程会变。没有负责人、没有复审日期的图，是一家已经不存在的公司的快照。给它一位负责人、一个固定的复审节奏和版本控制，让现行版本可以被辨认出来。
绘制您自己的业务流程
从采购到付款示例开始，或者打开一张空白图表，把您的步骤录进行里。
相关指南
常见问题
流程绘制与流程建模有什么区别？
流程绘制产出的是一张人们真会拿来用的图：谁做什么、按什么顺序、有哪些判断和交接。流程建模产出的是一份形式化、受符号规范约束的表示——通常是 BPMN——工具可以对它做校验或直接执行，它对事件类型、网关和消息流都有规则。大多数组织需要的是那张图。只有当下游确实有东西要消费它时，比如一个工作流引擎或一个自动化项目，才去动模型。
我应该画现在的流程还是改进后的流程？
画现在的，而且永远先画现在的。现状图是一份可以与执行工作的人一起验证的事实记录，这让它成为一项共识而不是一种看法。有了它之后，未来流程图不过是一次简短又便宜的对话，谈的是几处具体改动。跳过现状，就意味着改进是针对一条假想的流程设计的，而这个假想通常就是顺利路径。
绘制一条业务流程应该花多长时间？
对一条有四到五条泳道的单一运营流程来说：几个小时的访谈、一个下午起草，再加一场验证会。折合两到三天的投入，分散在日历上。凡是要花上几周的，通常是范围问题而不是复杂度问题——边界没有钉死，于是图不断向旁边的邻接流程蔓延。
业务流程图应该由谁来负责？
一位可以修改它的指名人员，通常是流程负责人，而不是主持这次绘制的那个人。泳道负责人负责复核；流程负责人负责维护。没有唯一负责人，图会以一种可预见的方式失效：它在技术上一直可用，却悄无声息地不再对得上现实，这比根本没有图更糟，因为大家仍然相信它。
