如何绘制一条业务流程
如何端到端绘制一条业务流程：先约定边界，访谈真正执行工作的人，把包含异常在内的现状画出来，然后逐一验证。附一个可直接操作的采购到付款示例。
运作方式
把范围写成两个事件
“从开出请购单开始；到供应商收到货款结束。”一句话，在任何访谈之前，与提出绘图需求的人达成一致。如果大家对边界有分歧，这个分歧就是第一个发现，而且现在解决比画完三版之后再解决便宜得多。
确定泳道以及泳道里的人
列出工作会经过的角色，包括外部相关方，并为每条泳道找到一位真正在执行这些步骤的人，而不是一位在管这些步骤的人。四到五条泳道；如果您需要八条，说明范围太宽，应当在一次交接处拆开。
访谈要冲着异常去，而不是冲着常规
顺利路径人人都能讲，而问题很少出在那里。要问的是：预算科目缺失时你们怎么办？审批人休假时怎么办？发票先于货物到达时怎么办？这些答案就是那些分支，而且它们几乎从不写在别的任何地方。
用行搭出现状，泳道留到最后
把步骤录入 QueryChart 成为一行行内容，用“连线至”列把它们连起来，然后给每一行指派一条负责人泳道和一个阶段。在操心排版之前先把顺序理对，能让讨论一直停在流程上；图表会自行从行里组装出来。
量度交接
对每一次跨泳道的流转，记下下一条泳道是怎么知道自己有活的，以及它通常要等多久。写进这个步骤的备注里。大多数业务流程的周期时间是排队时间而不是作业时间，而队列恰好就排在这些边界上。
验证、批准，并只保留一个版本
与每一位泳道负责人逐步走一遍完成的图，把他们不认可的地方改掉。然后在 QueryChart 里让它走完审批，这样就有一个带签署和日期的现行版本，而不是一份在工作坊结束第二天就开始与现实脱节的 PDF。
常见问题
流程绘制与流程建模有什么区别？
流程绘制产出的是一张人们真会拿来用的图：谁做什么、按什么顺序、有哪些判断和交接。流程建模产出的是一份形式化、受符号规范约束的表示——通常是 BPMN——工具可以对它做校验或直接执行，它对事件类型、网关和消息流都有规则。大多数组织需要的是那张图。只有当下游确实有东西要消费它时，比如一个工作流引擎或一个自动化项目，才去动模型。
我应该画现在的流程还是改进后的流程？
画现在的，而且永远先画现在的。现状图是一份可以与执行工作的人一起验证的事实记录，这让它成为一项共识而不是一种看法。有了它之后，未来流程图不过是一次简短又便宜的对话，谈的是几处具体改动。跳过现状，就意味着改进是针对一条假想的流程设计的，而这个假想通常就是顺利路径。
绘制一条业务流程应该花多长时间？
对一条有四到五条泳道的单一运营流程来说：几个小时的访谈、一个下午起草，再加一场验证会。折合两到三天的投入，分散在日历上。凡是要花上几周的，通常是范围问题而不是复杂度问题——边界没有钉死，于是图不断向旁边的邻接流程蔓延。
业务流程图应该由谁来负责？
一位可以修改它的指名人员，通常是流程负责人，而不是主持这次绘制的那个人。泳道负责人负责复核；流程负责人负责维护。没有唯一负责人，图会以一种可预见的方式失效：它在技术上一直可用，却悄无声息地不再对得上现实，这比根本没有图更糟，因为大家仍然相信它。