如何创建文件审批工作流
如何搭建一条先分流、再签字的文件审批工作流：先给变更定性，让文件类型决定评审人，并给编辑性改版一条绕开评审的路。
文件审批工作流首先是一次分流决定，其次才是一条签字链——文件的类型和这次变更的实质性程度，共同决定哪些评审和哪些审批适用。
简而言之
- 先给文件定类型。必须参与的评审人由类型决定，而不是由设计流程的人决定。
- 一次不改变任何含义的编辑性改版，要的是一条登记记录，而不是一轮评审。
- 评审意见汇总到作者身上；会签性质的审批必须排在它所会签的那次审批之后。
- 写明触发第二位审批人的条件，而不是写死第二位审批人是谁。
- 发布不是单一的一种状态：一次登记在案的编辑性更新，与一次附带培训的发布并不相同。
多数文件用不上多数评审人
每一条文件审批工作流里都有一个分类步骤，而多数流程从来不把它画出来。总还是有人在决定：这一次改版要三位评审人，那一次一位都不要——凭习惯，凭谁有空，凭上一版惹了多大麻烦。画出来，这个决定就是一条有记录可查的规则；不画，它就是一连串无法证明被同样应用过两次的个人判断，而一致性恰恰是一条分流规则唯一可以被检验的性质。
一个好的分流问题，是提交人不必读文件正文、一分钟之内就能回答的问题：这是什么类型的文件、它是否受监管、这次变更有没有改变某个人必须做的事。一个非要先做它本来想省掉的那次通读才能回答的问题，早就把它被加进来时想省下的那点成本花光了。这就是分类必须通过的检验，也正是这些问题只问文件、从不问哪位评审人恰好有空的原因。
下面的示例是一棵决策树而不是一条链条，分流在任何人开始读文件之前就已经定了。“是编辑性修改还是实质性修改？”把一次改版整个引出评审之外，而“作者能否当下解决？”会把没处理完的意见送回“收集评审意见”再走一轮——这样一次返回是链条图根本画不出来的，这也是链条在纸面上总显得比它所描述的流程更快的原因。
八个判断，一个回环
一棵文件审批决策树，它的前三个问题就决定了后面还有多少内容真正适用。
先定性，再分流
编辑性改版在任何人读它之前就离开了工作流。“是新文件还是改版？”把一次改版交给“是编辑性修改还是实质性修改？”，它的“编辑性”分支通向“登记这次编辑性更正”——问到第二个问题就出口，工作流由此决定它欠这份文件多少工。
把评审回环如实画出来
分类是评审的闸门：“是否属于受监管的文件类型？”会在涉及管理体系或许可证时加入质量与法规评审人。意见汇总到同一个步骤，而“所有评审意见是否都已处理？”把未决的那些交给“作者能否当下解决？”，它的“是”再走一轮。
先审批，再要第二个名字
审批进入时是两行，一行在读、一行在定——“审批人审阅最终稿”排在“是否批准发布？”之前；截到这里，只有它的“批准”出口还有去处，通向“是否需要第二位审批人？”，那里的“取得第二位审批”添上一次会签。
发布不止一个结局
最后一个判断决定这次发布是否附带培训义务，而完成的这棵树给出三种已发布状态，再加上“退回作者返工”和“已否决并关闭”——五种这条工作流真能产生的结果。
运作方式
先做分流表，再画图
一种文件类型一行，两列会引起争论：这个类型强制要求哪些评审人，以及什么层级的授权可以放行它。在表上把它们定下来，那里的一场争论只花掉一个下午，而不是一次改版。随后的图不过是把这张表画出来，所以一个没人认可的类型，最后就是一条没人走的路径。
把编辑性与实质性写成文字
编辑性意味着读者不会因此做出任何不同的动作：字体排版、版式、部门改名、交叉引用更正。其余一律算实质性。指定谁来裁定有争议的定性，因为边界情形——改动了一个公差数值、调整了步骤顺序——正是这条定义值得存在的地方。
把分流问题放在最前面几行
把分类问题录进表格最上面的几行，并把每一行的“形状”设为决策。因为“连线至”填的是行号，一条跳过整个评审区块的路径就只是一个越过它的数字——编辑性出口是一个数字，而不是一张重画的图。
评审收成一行，再给签名排序
同时工作的评审人是一行：他们的意见并行到达，并汇总到作者身上。只有当后一个签名是在会签前一个签名时才需要串行，就像“取得第二位审批”那样；其余的串行只是把习惯画成了图。分支名称按行号的顺序填进“连线文字”。
给每一种结果各自的终止符
文件发布的那几行把“形状”设为成功，被否决的设为拒绝，退回作者的设为结束。三种已发布状态并不是冗余：“经完整审批后发布”“发布并已指派培训”和“作为小幅编辑性更新发布”，留在身后的义务确实互不相同。
拿三次已登记的改版跑一遍
从文件控制记录里取最近三条，只用前三个问题给每一条定性。如果三条都落到同一条路径上，说明分类目前还没起作用——要么定义划得太宽，要么这三次改版确实相似。扩大样本，直到其中有一条走出不同的路。
应避免的错误
分流规则只存在于某个人脑子里
固定链条至少还是在所有人都看得见的地方运行。一条只在私下里握着的分流规则，会被逐份文件地各自解读，而这些解读只朝一个方向漂移：利害最大的那些变更走了最短的路。
在批准之后又编辑
审批人签的是一份草稿；随后在发布之前又来了一次排版、一处临时更正，或者合并了一条意见。如果发布出去的文件不是被批准的那一份，这个签名就属于一个谁手里都没有的版本。
第二个名字问得太晚
“是否需要第二位审批人？”排在“是否批准发布？”之后，于是要不要会签，是在第一位审批人已经表态之后才定的。哪些类型需要两个名字，在分类时就已经知道——就在那里问。
确认要么人人都要，要么谁都不要
两种默认都会失败。每一次排版微调都要求确认，会训练大家一路点过去；而从不要求确认，就没有任何证据表明有人在按变更后的现行版本作业。
搭建你们的文件审批流
把这棵决策树打开成您自己的图表，设定那些真正决定您的文件需要哪些评审与审批的问题。
相关指南
常见问题
谁应该批准文件，谁只应该评审？
审批人是这份文件的流程负责人，或者持有该类型授权的那个人——一位指名的自然人，绝不是一个角色邮箱。评审人同样不是逐份文件挑出来的：这份名单属于文件类型，而这正是示例里“是否属于受监管的文件类型？”所决定的事——它给一条本来两者都没有的路径加上了质量与法规的名字。类型只需要争论一次，而你就此决定了它今后的每一次改版。
每一次文件改版都需要走完整的审批轮次吗？
不需要，而正是这样对待它，才让评审周期一拖数周。一次不改变任何含义的改版——排版、部门改名、引用更正——需要的是一条登记在案的编辑性更新，而不是重新走一轮签字。凡是改变了某人必须做的事，就走完整路径，包括它的文件类型强制要求的那些评审人。关键在于这条判定标准在改版到来之前就已经存在，而且不是只有作者一个人在用它。
一份文件应该评审几轮？
一轮；只有在第一轮发现了实质性问题时才需要第二轮。工作流真正要写明的，是第二轮同样没有收口时会怎样，而这正是“作者能否当下解决？”的职责：它的“是”把意见再送一轮，它的“否”终止于“退回作者返工”——那是一个决定，决定不再继续评审一份本来就没准备好的草稿，而不是让它一直转下去。轮次没有上限，只会换来四位评审人份量的意见，以及没有一个负责人。
“已阅读并理解”记录是用来做什么的？
它是做这项工作的人确实知道这次变更的证据——这与文件是否获批是两个不同的问题。当改版改变了某人在受监管、安全关键或面向客户的步骤里实际必须做的事时，要求它才有意义；对每一处措辞改动都要求它，它就只是一次点击。审计人员会去看文件生效日期与这些确认之间的间隔，因为那段时间里，人们还在按旧版本作业。
