如何对 SOP 进行版本控制
SOP 版本控制意味着给每一次程序修订编号，让安全关键变更走实操再培训加签字核对表，而不是阅读确认，并把被取代的副本撤回。
SOP 版本控制是把每一次程序修订与一个编号、一条审批记录和一项再培训要求绑在一起的做法，确保没有任何操作人员会照着一份已作废的副本执行安全关键步骤。
简而言之
- 给每一次 SOP 修订编号，并印在每一页上——这个编号是培训记录和审计轨迹共同指向的对象。
- 安全关键变更要走成文的安全影响评估和实操再培训，而不是阅读确认。
- 签字的能力核对表是再培训的证据；阅读回执只能证明有人打开过文件。
- 安全关键与标准这两条评审路径，最终仍会汇合到同一步：把前一修订版标记为已作废。
- QueryChart 的变更日志和比较版本视图（/features/version-control）显示谁改了哪个字段，不需要另一份登记册。
过时的 SOP 不是归档问题
SOP 记录的不是一般情况下应该怎么做——它是此刻正在当班的人正在遵照执行的确切步骤序列，这正是 SOP 的版本控制比政策文件或电子表格模板更要命的原因。一份过时的市场简报版本，代价是有人白干一下午。一份过时的锁定挂牌程序版本，或者一份过时的批放行检查表版本，代价却是有人伤了手，或者放出一批不合格品——因为一名严格照墙上那份说明做事的操作人员，就是在严格执行流程对他的要求，即便那张纸已经落后了两个版本。
通用的文件版本控制，见 /zh/guides/如何对文件进行版本控制，问的是哪份文件是当前版本、谁批准了它。SOP 的版本控制对每一次变更都多问一个问题：在按新方法操作之前，谁需要被再培训，而你又怎么证明他确实接受了培训。登记册里把编号加一并不能阻止操作人员继续用旧方法；能做到这一点的，只有一条完整、带日期、经过签字、绑定新修订编号的培训记录，这正是受控 SOP 的审批工作流——见 /zh/templates/受控标准作业程序模板——必须把流程交接到再培训这一步，而不是止步于“已批准”的原因。
下面的图表恰好在这个判断点上分叉——“是否涉及安全关键步骤？”——因为两种答案需要不同的证据。安全关键变更要走成文的安全影响评估、QA 关口把守的审批，以及带签字能力核对表的实操再培训；非安全关键变更走标准适宜性评审和阅读确认即可。把两者合并成一条路径，或者把一份阅读回执当成安全关键步骤上的能力证明，正是这套流程要防止出现的那类审计发现。QueryChart 自身的版本历史——见 /features/version-control——给质量团队一份变更日志和一个比较版本视图，用来核实每一次修订确实走了这条路，而不需要另一份会和图表实际记录脱节的平行电子表格登记册。
逐阶段看安全关键分叉
一次 SOP 变更从申请出发，经过一个判断，分流进安全评审加实操再培训，或标准评审加阅读回执。
申请要先登记到某一修订版上
“提出 SOP 变更”开启这条链，随后“提交变更申请并说明原因”和“将申请登记到当前 SOP 修订版上”把申请和一个具体版本绑定，然后才开始“评估拟议变更的运营影响”——到这里为止，谁都还没对这次变更下判断，只是记录了它是什么、取代的是什么。
决定难度的那个分叉
“是否涉及安全关键步骤？”让流程分叉：答案为“是”会进入“开展成文的安全影响评估”，再到“提交变更包以供 QA 关口审批”，由第二个“是否批准？”判断把关，驳回会直接回到安全评估这一步，而不是绕过它。
实操再培训 对 标准评审
获批的安全关键变更会进入“安排强制性实操再培训”和“完成实操培训并签署能力核对表”——一次有监督、有签字确认的实操演练，不是一份阅读回执——而“否”分支则走“完成标准适宜性评审”，进入自己的“提交变更包以供审批”和“是否批准？”关口。
两条路径最终汇合到同一次登记更新
标准路径最终仍会走到“分发更新后的 SOP 以供阅读确认”和“阅读并确认新版本”，两条路径都在“更新 SOP 登记册并将前一修订版标记为已作废”汇合，随后“将新修订版发布为当前受控版本”让它成为现行版本。
运作方式
在第一次修订之前定好 SOP 编号方案
给每份 SOP 一个标识符和一个整数修订号，印在每一页的页眉，连同生效日期和审批人。这件事只定一次，因为日后重新编号会打断每一条引用了旧编号的培训记录和审计轨迹。
把申请登记到它要变更的那个修订版上
在任何人碰草稿之前，先开立一份申请，写明具体要改的步骤和原因——一次事故、一次未遂事件、一次偏差。把它填进图表的方框文字列，用连线至指向把申请登记到当前修订版的那一行，让申请绑定到一个版本，而不是悬空存在。
把安全关键判断做成明确的一步
给工作流一行判断，问是否涉及安全关键步骤，在连线文字列里写上两条带标签的分支。把“是”导向成文的安全影响评估，把“否”导向标准适宜性评审——绝不能让申请人或审批人凭假设跳过这个问题。
把安全关键路径卡在实操再培训上，而不是确认签收
获批之后，安排强制性的实操培训，并要求签署能力核对表，变更才能上线。一行只写“阅读确认”的行应该放在标准路径上，而不是安全关键路径上——把两者做成独立的行，这样即使日后重新排序，这个区别也不会消失。
让两条路径汇合到同一次登记更新
无论走了哪条分支，都把变更导入一个统一的文件形状行，更新 SOP 登记册并标记前一修订版已作废，然后再把新版本发布为当前版本。一个汇合点意味着只需要在一处检查每条路径是否真的走到了旧副本退役这一步。
确认每一位受影响的操作人员，而不只是当班的那几位
在发布之前，对这个步骤涉及的每一个班次、每一位承包商人员逐一核对再培训或确认签收，而不只是变更获批当天在岗的那个团队。漏掉夜班，正是每一轮审计都会反复出现的那类发现。
应避免的错误
在安全关键步骤上用阅读确认
一份阅读回执只能证明有人打开过文件，不能证明他能安全地执行这个步骤。应该像“完成实操培训并签署能力核对表”那样，把任何涉及安全关键步骤的变更导向实操再培训和签字能力核对表。
被驳回的变更要重新进入评审，而不只是回到草稿
很容易把“是否批准？”直接循环回申请这一步，让被驳回的变更改改措辞就重新提交。在安全关键路径上，应该像这张图表一样，把驳回导回“开展成文的安全影响评估”，让修改后的草稿重新接受安全评估，而不只是重新打字、重新提交。
一条没有点名具体班次的登记条目
“更新 SOP 登记册并将前一修订版标记为已作废”只有在每一个受影响的班次和承包商都完成再培训或确认签收之后才算成立——不是白班完成了就算。要点名这一步能触达的具体人群，否则夜班团队就会继续用已撤回的版本。
创建你自己的 SOP 变更控制流程
把 SOP 变更控制示例打开成你自己的图表，设定你的编号方案，并保留安全关键分叉，让再培训始终是强制项而不是可选项。
相关指南
常见问题
SOP 的版本控制和通用文件版本控制有什么不同？
有一点不同：SOP 的版本控制必须回答的是新修订版生效前谁需要被再培训，而不只是哪份副本是当前版本。通用文件版本控制——见 /zh/guides/如何对文件进行版本控制——管的是任何受控文件的编号、审批和撤回。SOP 在此之上多了一个能力问题：修订号加一并不能阻止操作人员继续用旧方法，直到他被培训过新方法为止，所以 SOP 的版本控制记录除了通常的审批轨迹，还必须带上培训或确认状态。
安全关键的 SOP 变更应该怎样走和一般变更不同的路径？
安全关键变更——步骤做错会造成人身伤害、不合格品或违反法规的那种——在上线之前需要一份成文的安全影响评估、一次 QA 关口把守的审批，以及带签字能力核对表的实操再培训。非安全关键变更可以走标准适宜性评审、常规审批和阅读确认。把两者都塞进同一条轻量路径，结果就是一次措辞调整和一次锁定步骤的变更被要求提供同样的证据——对前者太多，对后者又太少。
培训记录和 SOP 的版本控制是一回事吗？
不是——它们回答的是不同的问题，一套 SOP 流程两者都需要。版本控制追踪的是哪个修订版是当前版本、谁批准了它、它取代了什么；培训记录追踪的是谁已经证明了对该修订版的操作能力。QueryChart 在 /features/version-control 的版本历史覆盖第一部分：带字段级差异的变更日志、比较版本视图和还原。上文提到的安全关键变更所需的签字能力核对表覆盖第二部分，两者需要引用同一个修订编号，否则审计员就无法判断接受过培训的人和现行程序是否对得上。
审计员对一次 SOP 修订最低期望看到什么证据？
文件上印着的修订号和生效日期，一条记录着谁在何时批准的记录，一个和触发这次申请绑定的成文变更原因，以及——对任何安全关键内容——一份注明谁在什么版本上接受了再培训、有日期、有签字的能力记录。关于 SOP 文件本身的流转与审批机制，见受控 SOP 模板 /zh/templates/受控标准作业程序模板；关于两次修订之间具体改了什么这个更窄的问题，见 /zh/guides/如何追踪SOP变更。
