SOP 修订历史模板
SOP 修订历史模板：拟议变更如何变成一条带日期的登记条目，与待处理变更核对，经评审、审批，最终连同被取代的版本一起定稿。
什么是SOP 修订历史流程
修订历史登记册，是为一份 SOP 回答一个问题的台账：改了什么、什么时候改的、谁改的、谁批准的，以及现行版本取代的是哪一个版本。它是独立于 SOP 本身的一份制品——程序描述的是工作今天该怎么做，修订历史则是此前每一个版本的只增不改的记录。审计员和新任流程负责人往往先读这份登记册，因为这是判断眼前这份程序究竟是受控的现行版本，还是评审人忘了更新的旧版本，最快的办法。
这张图把登记本身画成一套独立的工作流，而不是 SOP 审批的一个附注。拟议变更先按安全关键程度判断，决定走加急评审还是标准评审，然后再对照登记册本身核对：如果同一份 SOP 已经有另一条未结条目，两处变更就会被协调，登记册也就不必事后去调和两条都声称取代同一版本号的条目。只有到这一步之后，起草才会真正产生登记条目——日期、变更摘要、起草人，以及它所取代的版本号——这也是为什么起草与定稿这两步用的是“文件”形状而不是“流程”形状：它们是内容真正被写入登记册的时刻，而不只是流转到下一步。
这不是 SOP 文件本身的审批流程——那是 /zh/templates/受控标准作业程序模板 上的受控 SOP 模板，那个页面把程序的内容本身送经起草、评审与签署。这张图是那套流程每产生一个新版本时都要写入一条条目的登记册。它也比通用的文件控制更窄——后者在 /zh/templates/文件控制流程 上管理各类受控文件的起草、发布、分发与定期审查；这张图只覆盖登记本身，也就是记录改了什么、取代了哪个版本的那份制品。
本流程图涵盖的内容
本模板包含
- 顶部五个阶段——识别变更、起草登记条目、评审、审批与登记定稿——对应五条泳道，代表会接触修订历史条目的角色：流程负责人、SOP 起草人、评审人、审批人与文件管理员。
- 受理与分流：变更被识别并描述，随后“变更是否涉及安全关键步骤？”这道判断在起草开始之前，把它导向加急评审或标准评审。
- 起草之前的重复条目核查：“修订历史登记册中是否已有该 SOP 的待处理条目？”把流程导向与未结条目负责人协调，这样对同一份 SOP 的两处变更就永远不会被登记成两条相互竞争的修订。
- 条目本身用“文件”形状而不是“流程”形状来起草并最终定稿：日期、变更摘要、起草人，以及它所取代的版本号，先提交评审，再提交审批。
- 评审循环：“审批前是否有待处理的意见？”把条目退回给 SOP 起草人更新并重新评审，而不是逼审批人直接驳回。
- 审批与结案：“是否批准？”这道判断在“驳回”时把条目退回返工，在批准后则让文件管理员将其记录为定稿、更新 SOP 的版本号与生效日期，并归档它所取代的版本。
何时使用本模板
- 你们正在为 SOP 建立修订历史登记册，希望结构上把受理、起草、评审、审批与定稿分开，而不是用一个不设边界的“追加一行”步骤了事。
- 两个人可能同时对同一份 SOP 提出变更，你们需要一个检查点，在重复条目作为两条相互竞争的修订走到审批之前就把它拦下来。
- 你们需要向审计员说明修订历史登记册中某一行具体是怎么来的：谁提出了变更、谁评审的、谁批准的，以及它取代了哪个版本。
- 你们正在把修订历史登记册从 SOP 审批流程本身中分离出来，因为同一份登记册需要在其生命周期内，记录不止一位负责人对同一份 SOP 提出的变更。
运作方式
把泳道改成你们真实的角色
把流程负责人、SOP 起草人、评审人、审批人与文件管理员，换成你们实际使用的头衔。小团队里 SOP 起草人和流程负责人往往是同一个人——把这两条泳道合并，而不是留一条空着的；如果质量负责人既做评审又做签核，就改为合并评审人和审批人这两条泳道。
定下安全关键性的判定标准
写明什么样的变更该走加急评审，而不是把“变更是否涉及安全关键步骤？”留给个人临场判断：涉及锁定步骤、关键控制点或法规强制检查的变更，应当始终符合条件，其余的默认走标准流程。
定下每条登记条目必须携带的字段
在起草这一步，明确你们的登记册需要哪些确切字段：登记日期、SOP 编号、用平实语言写的变更摘要、起草人，以及被取代的版本号。让加急条目和标准条目使用完全相同的字段，这样无论走的是哪条路径，登记册都保持一致。
决定重复条目如何解决
定下“修订历史登记册中是否已有该 SOP 的待处理条目？”背后的规则：第二处变更是等第一条结案，还是并入同一条条目，还是单独登记并注明与另一条互相参照？三种做法都可行，只要登记册最终不会出现两条都声称取代同一版本号的条目。
定下你们的版本编号与生效日期规则
明确版本号如何递增——常见做法是已发布修订用整数、草稿用小数——并规定生效日期需要留出多长的提前量，好让文件管理员能在生效之前更新总登记册并撤下被取代的副本。
常见问题
什么是 SOP 修订历史登记册？
它是一份带日期的台账，列出一份 SOP 的每一个版本以及版本之间改动了什么：登记日期、谁提出了变更、变更内容摘要、谁评审并批准了它，以及它取代了哪个版本号。它独立于 SOP 自身的审批签核——SOP 记录的是谁批准了现行版本，修订历史登记册记录的则是走到这一步经历的版本序列。
这和 SOP 自身的审批流程有什么区别？
/zh/templates/受控标准作业程序模板 上的受控 SOP 模板，把程序内容本身送经起草、评审与审批，产出一个签核过的现行版本。这张图是那套流程每产生一个新版本时都要写入的登记册——一份只增不改的历史记录，包含日期、起草人、摘要与被取代的版本号，作为独立制品保存，使这份序列不依附于文件本身也能留存。
为什么在起草新条目之前要先核查是否有待处理条目？
因为两个人可能在同一个评审周期内各自对同一份 SOP 提出变更，彼此并不知情，如果两条条目各自独立走到审批，登记册最终就会出现两行都声称取代同一版本的记录。在起草之前、流程一开始就核查，意味着第二处变更会被协调并入第一条条目，而不是等到审批阶段才发现冲突。
是不是每一次 SOP 变更都要走加急路径？
不是。加急路径是为安全关键步骤的变更而设的，因为从识别到变更生效之间的时间间隔必须很短。其余情形——澄清措辞、排版调整、非关键的程序性改动——都应该走标准评审流程，因为把所有变更都当加急处理，就违背了设立两条路径的初衷。
