如何创建工作流程图
如何创建工作流程图：把申请、审批关卡、实际工作以及那个让流程闭环的复核画出来，并让每个状态都有一个角色负责。附一个实时的权限申请示例。
运作方式
为事项及其状态命名
写下流转的到底是什么——一份申请、一张发票、一份文档——以及它可能处于的状态：已提交、已批准、已开通、已回收。当读者问“这件事现在到哪了”，他们要找的就是状态，所以先把状态谈定，能避免图表变成一份任务清单。
按生效顺序列出各道关卡
对每一次审批，记下由谁负责、他们在决定什么。然后检查这个顺序是不是真实的：本可以并行的关卡，常常被画成串行，只因为工单系统当初就是那样配置的——这一点值得摆到台面上，而不是就此固化下来。
把状态写成行并连起来
把每个状态或动作放进一行，把关卡的“Shape”设为 Decision，再用“Line to”列把它们连接起来。每道关卡的两个出口都要在“Line text”里标注文字。做到这一步，图表就已经能替你指出任何一个出不去的状态。
为每个状态指定一条泳道
把每一行放进那个在该状态下持有事项的角色的泳道里。正是这一步，让这张图成为“我的申请现在压在谁手里”的答案——而那是工作流程图被问得最多的一个问题。
为拒绝规划去向
一个被拒绝的事项总要去某个地方：退回给申请人修改、进入一个已关闭的状态，或转给例外处理的负责人。把它画出来。让拒绝停留在言下之意的工作流，恰恰会制造出那种典型故障：事项既不在办、也没关闭，而且没人去催。
加上周期性复核
如果这个事项会按计划被重新审视——权限重新认证、文档定期复核、合同续签——就把它画成一条回到工作流中的路径，并带上自己的决策点。否则这张图就暗示工作到此为止，而台账会悄悄堆满没人再看一眼的条目。
常见问题
工作流程图和业务流程图有什么区别？
业务流程图描述工作是怎么执行的；工作流程图描述某一个具体事项如何在对它采取行动的人之间流转，重点在状态、归属与审批关卡。在实践中两者大量重叠，同一套图形符号也能同时服务两者。这个区分更有用的地方是当成一道自检：如果你说不出流转的是什么事项、它可能处于哪些状态，那你画的是流程图，而不是工作流。
一个工作流应该有多少个审批环节？
只保留承载真实决策的那些。每道关卡都会增加排队时间，超过两三道之后还会稀释问责——五分之一的审批人往往看都不看就签了，这比没有关卡更糟，因为它制造出一份“复核发生过”的证据，而复核并未发生。如果一道关卡从来没有拒绝过任何东西，它就是一条通知，也应该按通知来画。
工作流程图需要用泳道吗？
几乎总是需要。工作流程图被问得最多的问题，是这个事项现在由谁持有，而泳道不需要任何人去读方框里的文字就能回答它。例外是那种从不离开一个团队的工作流——在那里泳道只会多出一个不承载信息的维度。
按计划重复发生的工作流怎么表示？
把触发点画成一个步骤，并用一个关于结果的决策把它接回流程中。在权限示例里，重新认证是一个计划内的步骤，接入“权限是否仍然需要？”的决策，结果要么再次确认、要么回收。把这一点显式建模出来，正是让工作流程图不再暗示“事项一旦办完就永远完结”的关键。