如何管理 SOP 修订

运作方式

1. 在第一条条目之前定好编号方案

   一次性决定已发布的修订版是用整数（1、2、3）还是用把草稿和已发布副本分开的大.小版本方案，并把这条规则写下来。永远不要为了修补一个旧的不一致，去给一个正在使用的登记册重新编号——重新排列过的序号，会让每一条引用了旧编号的交叉引用、培训记录和历史审计轨迹都失效。

2. 按风险设定审查周期，而不是套用一条一刀切的规则

   安全关键的 SOP 应该比低风险的 SOP 有更短的审查周期；图表自身的“变更影响安全关键步骤？”分支，用的正是这套逻辑，只是应用在单次变更上，审查节奏也应该沿用同样的逻辑。把这个周期以到期日的形式写进 SOP 的页眉，不要指望有人记得某条政策。

3. 为整个登记册指定一位负责人

   一份 SOP 的作者起草它的条目，它的审批人在上面签字，但两者都不对整个登记册负责——不对那条逾期三周的条目负责，也不对那份没人设定审查日期的 SOP 负责。把这份职责交给一个具名角色，通常是文件管理员或质量经理，让他去追那些逾期的事项。

4. 把一次“无需变更”的审查也记成它自己的条目

   当一次计划审查确认某份 SOP 依然正确时，把这个结论连同日期和评审人姓名写进登记册，就像记录一次真正的修订一样。一份只在内容变化时才增长的日志，在审计员看来就是一份自成文以来没人看过的文件。

5. 在两条重复条目相撞之前先发现它们

   在起草一条新条目之前，先检查这份 SOP 是否已经有一条待处理条目——登记册里“修订历史登记册中是否已有该 SOP 的待处理条目？”这个问题之所以存在，是因为两位作者从同一份母本各自开工，是件足够常见的事，值得专门绕过。把这些变更合并，或者给条目排定先后顺序，这样日志就永远不用去调和同一份文件的两个候选版本号。

常见问题

一份 SOP 的修订和它的版本有什么区别？

修订是那条带日期的条目——对 SOP 内容的一次改动，附带作者和原因被记录下来。版本是这条条目产生的那个编号，盖在当前发布副本上的那个号。实际使用中两个词经常混用，但登记册本身是围绕修订组织的：每一行都是一条修订，版本是最近一条修订获批之后 SOP 所处的那个状态。QueryChart 自身在 /features/version-control 的版本历史，用“版本”的方式也一样——每次保存产生一个带编号、可比较的快照。

SOP 应该多久审查一次？

没有哪一个间隔适用于所有程序——正确答案取决于这一步一旦出错代价有多大。安全关键或面向监管机构的 SOP 通常每年或更短周期就要审查一次；低风险的行政类 SOP 两到三年审查一次也是安全的。比具体数字更重要的是每份 SOP 都要有一个审查周期，写进页眉作为到期日，而不是等着某个碰巧注意到它逾期的人。

谁应该负责 SOP 修订登记册？

应该是独立于任何单一 SOP 的作者或审批人的人——通常是文件管理员或质量经理，也就是上面图表里那个泳道，负责给每一条获批条目定稿的角色。作者和审批人各自对一次修订负责；登记册需要一个人对整个集合负责：追逾期的审查、抓重复的条目、维持编号方案的稳定。

一次没发现需要变更的审查还算数吗？

算，而且它需要自己的记录来证明这一点。审计员抽查修订登记册时找的是审查按计划发生过的证据，不是 SOP 变过的证据——一份写得正确的程序理应多年保持不变。把审查日期和“无需变更”这个结论记为一条带日期的条目，否则两次修订之间的空档，读起来就像是被忽视，而不是稳定。

这和追踪 SOP 里的单次变更有什么不同？

追踪单次变更是条目层面的事：改了什么、谁改的、取代了什么，这是 /zh/guides/如何追踪SOP变更 讨论的主题。管理 SOP 修订是登记册层面的事：每条条目都要遵循的编号方案、每份 SOP 到期该走的审查周期，以及一旦其中任何一环松动时那位具名负责人。一份登记册可以把每一次单独的变更都记得完美无缺，却因为没人负责这套时间表而管理得很差。本文之外更完整的一套治理实践，见 /zh/guides/SOP版本控制最佳实践。