如何绘制业务流程图
业务流程图这一个名字下面其实有三种图。如何按这张图将被用来做什么定下详细程度，把这个程度贯彻到每一个方框，以及该把一个子流程拆出去、而不是把它撑大。
业务流程图在一个选定的详细程度上，把一条流程的步骤、决策和交接摆出来——可以是一份具体作业，可以是一条跨越多个团队的流程，也可以是一整个端到端的循环。
简而言之
- “业务流程图”指的是三种东西：一份作业、一条跨团队的流程、一整条链路。
- 详细程度由这张图将被用来做什么决定，永远不由流程本身决定。
- 颗粒度用交接来衡量，不用分钟来衡量——一个方框完全可以装下六周。
- 决策不会抬高详细程度：菱形承载的是路由，不是工作。
- 一个大到装不进这张图的方框，应该变成第二张图，而不是就地摊成六个方框。
同一个名字下面的三种图
三种不同的图都叫这个名字，而下面这张采购到付款的图，可以是其中任何一种。作业级的图会取它的其中一行——“按采购订单登记收货或服务确认”——然后用十五个方框去讲界面、容差和催办。流程级的图只画匹配和它的异常：四条泳道，从“应付账款”一直到“采购”。真正画出来的这一张是整条链路，从一项提出来的需求走到已经报告的支出。生手的做法，是一次把三种都画出来。
一个方框是某个人可以接下来、并且能够做完的一项承诺，而且它内部发生什么都不会改变流程接下来往哪走。这条规则必须在写下第一行之前就落到纸面上，因为详细程度来自用途，而不是来自流程本身：同样一条采购到付款的循环，对一位追查某项控制的审计人员来说，十五个方框才是对的；对一位刚学着提请购单的新采购员来说，九十个才是对的。两者都没错，而一张想同时满足两者的图，两边都不是。
下面这条采购到付款循环，在六个阶段、26 行里保持同一个颗粒度。“开展寻源并授标”是一个方框，覆盖好几周的工作，这是有意为之，因为它里面发生的任何事都不会改变流程接下来往哪走。当“是否已登记收货或服务确认？”发现什么都没登记时，它把发票送回“按采购订单登记收货或服务确认”——同一个程度，重复一次，而所谓循环从来就只是这么回事。
从提出需求到报告支出
采购到付款，从提出需求到报告支出：26 行、六个阶段，全程一个颗粒度——而一整轮招标就装在一个方框里。
第一行之前先定颗粒度
请购这部分工作六行就结束了：一个事件，“提交带规格与科目的请购单”，然后是“成本中心是否有预算？”，它的“否”已经停在“请购单被驳回或暂缓”。两道关卡都没有额外加屏幕或催办——菱形承载路由，不承载工作。
一个方框，六周时间
“是否已有合同或框架协议？”打开了走向市场的岔路：“有，按合同下单”直接到达“向供应商发出采购订单”，而“没有，转入寻源”要穿过“开展寻源并授标”——一个方框装下一整轮招标，因为它内部不改变路由。
异常保持同一颗粒度
交付、收货和发票依次到位，然后是连着三道关卡。“是否已登记收货或服务确认？”把“缺失，催办”送回“按采购订单登记收货或服务确认”，而匹配这一步此时只画出“超出容差”这条出口，干净的那条稍后才汇入。
循环在这里合上
剩下的两个循环都在这里合上，而且都没有降低程度。“异常是否已解决？”让“已解决，重新匹配”指回“三方匹配是否在容差内？”，“事后补开采购订单并登记”则回到收货检查。“仍有争议”停在“争议依合同条款处理”。
一直保持到最后一行
发票入账、付款批次放行，然后是“更新供应商与支出记录”。这张图里有四行是终点——被驳回的请购单、交给合同处理的争议、无订单而未付的发票，以及“周期关闭，支出已报告”——每一个都是一个方框，而不是一段被概括掉的路线。
运作方式
先点名读者和用途
写一句话：谁会打开这张图，他打开它是为了回答什么问题。培训某个人上手一项工作、修好两个团队之间的交接、找出一条循环在哪里丢掉了几周——这是三个不同的问题，它们会对同一份工作产出三张大小完全不同的图。
把颗粒度写成一条明文规则
动手打字之前先定下来：一个方框是一个单元的工作，有一个责任人、一个结果，而且它内部发生什么都不会改变流程接下来往哪走。同时定一个方框预算——一份作业十到二十个，一条跨团队的流程二十到四十个——并且把超出预算当成一次分层失误，而不是当成做得细致。
按这个颗粒度把步骤填进各行
每一行的“方框文字”列就是一个方框，图随着行一起长出来。按流程发生的顺序一路做下去，忍住不要去展开你恰好最熟悉的那一段；一个你想拆开的步骤到底是不是两个，由那条颗粒度规则来回答。布局是自动生成的，事后没有什么需要重新摆放。
给路线编号，给岔路加标签
“连线至”列填这个步骤通向的行号，通向多处时用逗号分隔，“连线文字”按同样的顺序填上分支标签。一个比它所在行更小的数字，画出来就是一条向后的循环——一张图就是这样说明某段工作要重做，而不必因此降到更细的一层。
填好泳道列，再把鼓包拆出去
“水平泳道”放阶段，“垂直泳道”放责任人。然后去找那个鼓包：方框数量是邻居三倍的那个阶段。把它的内容搬进第二张图，在更细的一层展开，在原图里只留下一个以结果命名的方框，并在那一行的备注里引用子图。
拿点名的那位读者验证详细程度
带着第一步里那位读者把画完的图走一遍，对每一个方框只问一件事：对他来说，这个方框是不是大小不对？预料会得到两种答案——有一个方框他希望被打开，有三个他根本不需要。然后把读者和详细程度写进图表标题，这样下一个想加方框的人，面对的是一个已经写明的范围。
应避免的错误
没有点名读者，也就没有什么在范围之外
没有点名的读者和点名的问题，任何一条新增提议听上去都很合理，图就这样一直堆积，直到没人再打开它。那场争论从来就不是在争流程；争的是这张图到底是给谁看的。
靠删掉菱形来做简化
被要求把一张图弄简单一点时，大多数人删的是决策，而不是合并方框。删掉“发票上是否引用采购订单？”，整条无订单的支路也跟着走了：图是短了，程度没变，只是它现在把两条路线说成了一条。
就地把一个方框摊开
一个后来发现很复杂的步骤，在原地收拢了六个方框，于是它周围的每一个方框读起来都成了摘要。把它挪进属于它自己的图，原处留下那一个方框，这样父图保持一个程度，细节保持另一个程度。
拿时间长短当作拆分的理由
耗时不是颗粒度。一轮招标在它内部不改变路由时就是一个方框；而一次两分钟、却决定工作接下来往哪走的检查，已经挣到了属于自己的一个菱形。
画一张你自己的业务流程图
把采购到付款循环变成你自己的图表，然后按你心里那位读者定下颗粒度，把每一个方框都收到这个程度以下。
相关指南
常见问题
什么是业务流程图？
在一个选定的详细程度上，把一条流程里的步骤和决策画出来的图。这个说法涵盖三种不同的东西：作业级的图，画一项具体工作；流程级的图，画跨越几个团队的工作，通常用泳道；以及链路级的图，画一整条端到端的循环，例如采购到付款。它们共用一套画法，回答的却是不同的问题——这正是详细程度必须先说清楚、而不能默认的原因。
业务流程图和流程图是一回事吗？
在业务场景里两者可以互换：业务流程图就是一条流程的流程图。在化工与过程工程里则不然。在那里，Process Flow Diagram 是一份特定的工程交付物，画的是设备、物流、流量和主要控制回路，由 ISO 10628 规范；而大多数人真正想要的那种活动图，会被叫做流程图或流程地图。动笔之前先弄清楚对方要的是哪一种。
怎样把一张业务流程图拆成子流程？
在父图里留下一个方框，让子图去承担它下面那一层。示例里的接缝是“开展寻源并授标”：父图把它保留成一个方框，标签结尾就是下一支箭头所依赖的那个结果——授标；子图从这个方框收到的事件开始，并且正好停在那个结果上。这样边界就是可检验的：读子图的最后一行，它必须说出父图那个方框承诺过的东西。没有任何内容被画两遍，每张图各自保持一个程度。
应该先画哪一层的业务流程图？
先画与你眼前问题相匹配的那一层，通常是跨越团队的流程层。工作卡住的地方就在职能之间的交接上，而只有这一层能把它们显示出来。当问题是一整条循环在哪里丢掉了几周时，画链路层；只有在需要培训某个人上手一项具体工作时，才画作业层。一上来就把三层都做出来，得到的是三张图，而它们会在一个季度之内彼此矛盾。
