文件审批工作流决策树
文件审批工作流的决策树：编辑性修改还是实质性修改、按文件类型确定的必审评审人、第二审批人，以及发布时的已读并理解要求。
什么是文件审批工作流决策树流程
文件审批工作流，就是介于一份写好的草稿和一份正式发布的文件之间的那段评审与审批路径。它回答的问题数量不多：这是一份新文件还是一次修订，这次修改是否真的改变了别人必须做的事，谁必须评审，是否还有未了结的意见，是否需要第二审批人或法规审批人，以及发布之后是否要求有人阅读并签认。它刻意比文件控制更窄：文件控制还要涵盖版本编号、发放、分发、收回已作废的副本以及定期审查。如果你们要的是带文件管理员泳道的完整生命周期，请使用文件控制流程图；本页是嵌在那个流程内部的那棵决策树。
这两张图回答的是不同的问题，值得把你们到底需要哪一张说清楚。跨职能流程图回答的是接下来会发生什么、由谁来做：一串任务自左向右穿过各条部门泳道，最后汇合到同一条终点线。本图回答的是这份文件走哪条路、由谁作决定：一串八道问题，它们的分支通向五个各不相同的具名结果。一次编辑性更正、一次完整审批、一次退回返工、一次否决，以及一次附带培训任务的发布，在这里是彼此独立的终点——由它们上方那些问题的答案决定去向，而不是同一条顺利路径上的几个阶段。
审批工作流失败的原因，通常是判定标准没有写下来，而不是缺了步骤。人人都同意编辑性修改有一条快速通道，但没有人写明什么才算编辑性，于是一次实质性修改就当作改错别字混了过去。关键判断上的注释承载着这些标准：什么使一次修改成为编辑性的，什么使一类文件成为受监管的，什么会触发第二审批人，以及什么时候确实必须做到已读并理解。泳道命名的是谁来回答每一道问题，而不是谁来打字，于是这张图同时也是一份决策权清单：起草人、文件负责人、评审人与审批人，横跨受理、分类、评审、审批与发布五个阶段。
本流程图涵盖的内容
本模板包含
- 八道判断构成主干：新文件还是修订、编辑性修改还是实质性修改、是否属于受监管的文件类型、评审意见是否全部了结、起草人能否当场解决、是否批准发布、是否需要第二审批人，以及是否要求已读并理解。
- 分支标签是答案而不是下一项任务：修订或新建、编辑性或实质性、受监管或业务、已了结或未了结、已批准、返工或否决、需要或不需要。
- 五个具名终点，而不是一条共同的终点线：作为轻微编辑性更新发布、经完整审批后发布、发布并同时指派培训、退回起草人返工，以及否决并结案。
- 编辑性捷径：只有修订才可以被归类为编辑性，编辑性更正经记录后即可发布，无须强制评审或审批；而任何新文件都要走完整路径。
- 按文件类型选定评审人：受监管的文件在收集意见之前先加入质量与法规评审人，业务文件则只送交指定的流程评审人。
- 未了结的评审有两个出口：起草人当场可以关闭的意见回到重新评审，无法关闭的意见则以退回返工结束本轮；此外，审批人也可以把一份本已完备的草稿退回返工，而不是直接否决。
何时使用本模板
- 你们的文件控制程序列出了步骤，却从来没有说明哪些修改可以跳过完整评审，于是改一个电话号码和发布一条新的安全关键作业指导书一样要走六个星期
- 审批停滞，因为没有人说得出是否需要第二审批人或法规审批人，答案由当时在场的人逐份文件临时决定
- 你们正在文件管理系统中配置审批路由，需要先把分支条件作为成文标准达成共识，再由人把它们做成规则
- 审计人员问过你们如何判定一次修改属于编辑性，或者如何判定一次发布需要已读并理解，而目前的答案是凭个人判断，而不是一条成文标准
- 你们在带新的文件负责人或审批人上手，希望他们看到这些问题、每一道问题背后的标准，以及每一个答案确切通向哪里
运作方式
把泳道改成你们真实的决策权
这四条泳道命名的是谁来回答每一道问题：起草人、文件负责人、评审人与审批人。把它们换成你们自己的角色，按角色而不是按人名命名，这样图才经得住人员离职和组织调整。如果你们的质量经理既是文件负责人又是审批人，就把这两条泳道合并，而不是假装这个决定是分开作的。如果技术评审和法规评审由不同的人回答，就把评审人这条泳道一分为二。
用一句话写清编辑性的判定标准
“编辑性修改还是实质性修改？”是最容易被滥用的一道判断，因为它是唯一一条跳过评审与审批的路径。写一条谁都能套用的标准：如果读者会因为这次修改而做出任何不同的动作，它就是实质性的。然后把可以接受的编辑性情形逐一列明，例如改正错别字、调整排版、部门更名以及修正交叉引用，并写明由文件负责人而不是起草人来作这个判定。
按文件类型固定必审的评审人
把“是否属于受监管的文件类型？”做成一张短表，让你们的文件登记册可以凭一个字段而不是凭记忆来回答。对每一种类型，写明哪些评审人必须签署、哪些是可选的。受监管通常意味着该文件落在某个管理体系、某项许可或某份安全论证的范围之内；如果你们没办法从登记册的条目里判断一份文件属于哪一类，这道判断就一定会被不一致地作出。
设定第二审批人的触发条件
第二次审批应当由文件本身的某项属性触发，而不是由不安感触发。常见的触发条件是受监管的文件类型、涉及法律或安全的承诺，以及超出第一审批人授权范围的文件。把触发条件记在判断旁边，并写明由哪个角色提供这第二次审批，这样图告诉大家的就不只是“还需要再找一个人”，而是应该送给谁。
确定返工在什么情况下结束本轮
“起草人能否当场解决？”这道判断的作用，是不让草稿落进一个没有尽头的评审循环。约定本轮之内可以关闭的是什么，通常是措辞、澄清与排版；不能关闭的是什么，通常是任何需要新内容、新数据，或者需要起草人无权作出的决定的事项。凡属第二类，一律作为返工退回起草人，从受理重新进入流程，而不是原地打转。
定下已读并理解的规则，并把证据存好
当修改改变了某人在安全关键、受监管或面向客户的步骤中实际必须做的事时，要求已读并理解；仅涉及排版或措辞时则不要求。在发布之前就决定签认记录存放在哪里、保存多久，因为证明大家是按现行版本工作的，正是这条记录，而不是审批本身。
常见问题
什么是文件审批工作流？
它是一份草稿从写完到发布之间所走的路径：给这次修改归类、选定必须过目的评审人、了结他们的意见、取得审批，并决定这次发布要求别人做什么。它是一个决策结构，而不是一张任务清单，因为真正值得关心的不是“有没有评审”，而是“进行的是哪一种评审、谁有权作决定”。一个对每份文件都套用同一条路径的工作流，不是工作流，那是排队。
它与文件控制流程图有什么区别？
区别在范围和形态。文件控制流程图是一张跨职能流程图，涵盖完整生命周期，包括版本编号、向受控位置发放、收回已作废的副本以及按计划开展的定期审查，它回答的是接下来会发生什么、由谁来做。本页只是评审与审批这一段的决策树，它回答的是一份文件走哪条路、由谁作决定。如果你们正在编写一份程序文件，多半两者都需要：用流程图描述生命周期，用本图作为其审批阶段内部的路由规则。
一次修改在什么情况下可以按编辑性批准并跳过完整评审？
只有在含义没有改变时。改正错别字、调整排版、部门更名以及修正交叉引用是合格的；任何改变了一个人必须做什么、按什么顺序做、受什么限值约束或对照什么验收准则的修改都不合格，无论那处改动看上去多小。有两道防线让这条路径保持诚实：只有对现有文件的修订才可以被归类为编辑性，而且由文件负责人而不是起草人来作这个判定。要把归类结果记录下来，因为那是审计人员最先要查的东西。
一份文件需要两位审批人吗？
没有哪项标准把两位审批人定为通行规则。ISO 9001:2015 第 7.5.2 条要求成文信息在发放之前经过评审和批准，以确认其适宜性和充分性，但并没有规定由几个人来做。行业规则在特定情形下更严格，例如药品生产要求由质量部门批准生产与工艺控制的相关程序。实务上的做法是按文件属性触发第二审批人或法规审批人，例如受监管的文件类型、涉及法律或安全的承诺，或者超出第一审批人授权范围的文件。
电子审批算不算签名？
在多数商业场景中，一条可审计的审批记录只要写明审批人、版本和日期就够了。在受 FDA 监管的场景中，21 CFR Part 11 提出了具体条件：一份经签署的电子记录必须显示签署人的姓名全称、签署的日期与时间，以及签名的含义，例如评审或批准；并且签名必须与其记录相关联，使其无法被删除、复制或转移。在假定点一下按钮就够之前，先确认适用的是哪一套规则。
QueryChart 怎样追踪两轮审批之间到底改了什么？
每张图都自带变更日志与比较版本视图，免费且默认开启，所以你不用做任何配置，就能确切看到这一轮意见与上一轮之间动了什么——具体原理见 /features/version-control。/guides/how-to-track-process-changes 用这同一张图走过好几轮评审，展示它在实践中的样子。但这只是版本历史，不是合规审计轨迹：谁批准了什么、经签署并留存的记录，是另一项付费功能，免费的变更日志与比较版本视图并不包含它。