如何创建工作流程图
如何创建工作流程图：把申请、审批关卡、实际工作以及那个让流程闭环的复核画出来，并让每个状态都有一个角色负责。附一个实时的权限申请示例。
工作流程图展示一个工作事项如何在角色之间流转：什么触发它、它必须通过哪些审批、由谁执行，以及最终停在什么状态。
简而言之
- 单元是事项——一份申请、一张工单、一份文档——以及它经过的那些状态。
- 每个关卡都要点名一位审批人，并写清两种结果。
- 一个事项绝不能停在没人盯着的状态里。
- 拒绝要有明确去向：打回修改，或进入一个已关闭的状态。
- 如果存在周期性复核，就把它画出来——很多工作流会按时间重新开启。
工作流程图能显示、而流程图显示不了的东西
工作流（workflow）和流程（process）这两个词常被混用，多数时候也无伤大雅。这个区分真正派上用场的时刻，是你要决定画什么：流程图描述工作是怎么做的，而工作流程图描述某一个具体事项——一份申请、一张工单、一份文档——如何在必须对它采取行动的人之间流转。分析单元是这个事项以及它经过的状态，而不是活动本身。
这会改变页面上应该出现什么。工作流程图靠它的关卡活着：谁必须审批、按什么顺序、以及其中有人说“不”时会发生什么。任何一刻，一个事项可以停在哪里、由谁持有，都必须毫不含糊——因为最常见的工作流故障不是一个错误的决定，而是一个事项停在了没人盯着的状态里。
下面的示例是一份权限申请。它有四个不同的审批人、一个可能把事项打回上一步的冲突检查，以及一个在流程看似完结数月之后又把它重新打开的重新认证循环——这很好地提醒我们：一个工作流的最后一个状态，往往不是它的最后一个事件。
一个带四道关卡的工作流
一份权限申请如何从表单走到已开通的权限——并在重新认证时再走出去。
触发与第一道关卡
一份写明理由的申请，随后是直属经理的决定。注意，理由是在任何审批之前就收集好的：一道关卡的质量，不会高于审批人所看到的材料。
串行而非并行的审批
系统负责人复核权限范围，职责分离检查可以把事项退回去修改并重新检查，而特权访问还会额外叠加一道安全审批。每一道关卡都有唯一的负责人，并为拒绝标注了明确的去向。
工作本身
按最小权限开通、向申请人确认、取得使用规范的知悉确认，并把该权限登记进权限台账。在多数工作流程图里，真正“做事”的那一段是最短的——而这通常正是那个发现。
把它重新打开的那个循环
重新认证按固定节奏让工作流从头再走一遍，而“是否仍然需要？”的答案要么再次确认这项权限，要么触发回收。一个只向前走的工作流，会让权限日积月累地堆上好几年。
运作方式
为事项及其状态命名
写下流转的到底是什么——一份申请、一张发票、一份文档——以及它可能处于的状态：已提交、已批准、已开通、已回收。当读者问“这件事现在到哪了”，他们要找的就是状态，所以先把状态谈定，能避免图表变成一份任务清单。
按生效顺序列出各道关卡
对每一次审批，记下由谁负责、他们在决定什么。然后检查这个顺序是不是真实的：本可以并行的关卡，常常被画成串行，只因为工单系统当初就是那样配置的——这一点值得摆到台面上，而不是就此固化下来。
把状态写成行并连起来
把每个状态或动作放进一行，把关卡的“Shape”设为 Decision，再用“Line to”列把它们连接起来。每道关卡的两个出口都要在“Line text”里标注文字。做到这一步，图表就已经能替你指出任何一个出不去的状态。
为每个状态指定一条泳道
把每一行放进那个在该状态下持有事项的角色的泳道里。正是这一步，让这张图成为“我的申请现在压在谁手里”的答案——而那是工作流程图被问得最多的一个问题。
为拒绝规划去向
一个被拒绝的事项总要去某个地方：退回给申请人修改、进入一个已关闭的状态，或转给例外处理的负责人。把它画出来。让拒绝停留在言下之意的工作流，恰恰会制造出那种典型故障：事项既不在办、也没关闭，而且没人去催。
加上周期性复核
如果这个事项会按计划被重新审视——权限重新认证、文档定期复核、合同续签——就把它画成一条回到工作流中的路径，并带上自己的决策点。否则这张图就暗示工作到此为止，而台账会悄悄堆满没人再看一眼的条目。
应避免的错误
没有负责人的状态
不属于任何泳道的“待审核”，意味着没有人对推动它负责。每个状态都属于某个人，哪怕那是一个有指定负责人的队列。
画的是工具而不是工作
照抄工单系统的状态列表，得到的是一张关于配置的图。先问真正必须发生什么，再拿来对照——差异之处才是有意思的部分。
为求安心而层层叠加的审批
每多一道关卡都会拉长周期时间并稀释问责，因为五分之一的审批人签得很快。两道有意义的关卡胜过五道礼节性的。
拒绝没有出口
如果图表没有说明审批人说“不”之后会发生什么，那么这个工作流最常见的非理想结局就是未定义的。
创建您自己的工作流程图
把权限申请示例作为您自己的图表打开，把关卡、审批人和状态替换成你们自己的。
相关指南
常见问题
工作流程图和业务流程图有什么区别？
业务流程图描述工作是怎么执行的；工作流程图描述某一个具体事项如何在对它采取行动的人之间流转，重点在状态、归属与审批关卡。在实践中两者大量重叠，同一套图形符号也能同时服务两者。这个区分更有用的地方是当成一道自检：如果你说不出流转的是什么事项、它可能处于哪些状态，那你画的是流程图，而不是工作流。
一个工作流应该有多少个审批环节？
只保留承载真实决策的那些。每道关卡都会增加排队时间，超过两三道之后还会稀释问责——五分之一的审批人往往看都不看就签了，这比没有关卡更糟，因为它制造出一份“复核发生过”的证据，而复核并未发生。如果一道关卡从来没有拒绝过任何东西，它就是一条通知，也应该按通知来画。
工作流程图需要用泳道吗？
几乎总是需要。工作流程图被问得最多的问题，是这个事项现在由谁持有，而泳道不需要任何人去读方框里的文字就能回答它。例外是那种从不离开一个团队的工作流——在那里泳道只会多出一个不承载信息的维度。
按计划重复发生的工作流怎么表示？
把触发点画成一个步骤，并用一个关于结果的决策把它接回流程中。在权限示例里，重新认证是一个计划内的步骤，接入“权限是否仍然需要？”的决策，结果要么再次确认、要么回收。把这一点显式建模出来，正是让工作流程图不再暗示“事项一旦办完就永远完结”的关键。
