如何管理 SOP 修订
如何管理 SOP 修订：在需要之前先定好编号方案，按风险而不是一刀切的日期设定审查周期，给整个登记册指定负责人，并把“无需变更”的审查结果也记录为证据。
管理 SOP 修订，指的是治理这些修订所在的那个登记册——它的编号方案、审查节奏和负责人——而不只是描述某一条条目里改了什么。
简而言之
- 在登记册的第一条条目出现之前就定好编号方案——日后给一个正在使用的库重新编号，会打断每一条引用了旧编号的交叉引用和培训记录。
- 按风险设定审查周期，而不是给所有 SOP 一刀切地套用同一个年度日期。
- 为整个修订登记册指定一位负责人，独立于任何单一 SOP 的作者或审批人。
- 把一次“没发现需要变更”的审查也记录成它自己带日期的条目——审计员抽查的是审查发生过的证据，不是变更发生过的证据。
- 在两条开放中的条目互相冲突之前先发现它们，否则同一份 SOP 会得到两个候选版本号。
- QueryChart 自身的变更日志和比较版本视图（/features/version-control），让登记册本身也拥有它要求每份 SOP 保留的那种历史。
登记册比任何单一条目都大
一份修订历史日志可以有十一条完美无缺的条目，却依然是一次审计发现被写下来的原因——因为第十二条条目在两位 SOP 作者同时开立时没能拿到编号，或者因为没人说得清去年三月那次计划审查到底有没有真的发生过。会写 SOP 的组织，通常也擅长描述某一条条目里改了什么。真正容易出问题的，是这些条目周围的那个登记册：编号方案、每份 SOP 到期该审查的周期，以及任何一环松动时该由谁负责。
这些术语常常被随意混用，值得先在这里把它们分开。一次修订是一条带日期的条目——对 SOP 内容的一次改动，附带作者和原因被记录下来。它的版本，是这条条目产生的那个编号，盖在当前发布副本上的那个号。修订控制，是随着时间管理这一连串条目；它属于更宽泛的文件控制这个大类之下，文件控制同时也管着分发和撤回。本文讲的是把整个登记册当作一个整体来运营；关于如何记录单独一次变更的机制，见 /zh/guides/如何追踪SOP变更。
下面的图表是一次修订走过这个登记册的过程，从变更被识别的那一刻，到 SOP 被重新发布的那一刻，横跨五条泳道：流程负责人、SOP 起草人、评审人、审批人、文件管理员。QueryChart 自己的图表也受到同一种治理：每一次保存都会写入变更日志，带上谁改了什么的逐字段差异；比较版本视图把任意两个版本并排展示；一份过时的图表一点击就能还原——这一切都在 /features/version-control 有完整介绍。
一条条目，从识别到重新发布
一次修订申请走过五条泳道——从流程负责人到文件管理员——成为登记册下一条编号条目。
变更被识别，并按风险分诊
起点是一个事件，“识别到 SOP 变更”，随后是“描述拟议变更及其原因”，这一切都发生在任何人起草条目之前。“变更是否涉及安全关键步骤？”是登记册自身的风险分诊，决定这条条目走加急评审还是标准周期。
分流、重复检查，然后才是起草
“将该条目标记为加急评审”或“将该条目送入标准评审流程”定下节奏，然后“修订历史登记册中是否已有该 SOP 的待处理条目？”在第二条开放条目和第一条相撞之前先把它抓出来。只有到这一步，“起草修订历史条目：日期、变更摘要、起草人、被取代的版本”才会被写下并提交。
评审人和审批人都要核对这个编号
“评审人对照现行 SOP 内容核对条目”可能会在“审批前是否有待处理的意见？”上把草稿送回去；“审批人对照 SOP 母本及其所取代的版本核对条目”是第二次、独立的检查，针对的是同一个被取代的编号，驳回会像评审人的意见一样，循环回到同一个更新行。
登记册负责人定稿并重新发布
“在修订历史登记册中将已批准的条目记录为最终版”锁定这一行，然后“更新 SOP 的版本号与生效日期”和“撤回或归档被标记为已取代的版本”依次运行，最终到达“SOP 以新版本重新发布”——这四步全部由文件管理员负责。
运作方式
在第一条条目之前定好编号方案
一次性决定已发布的修订版是用整数（1、2、3）还是用把草稿和已发布副本分开的大.小版本方案，并把这条规则写下来。永远不要为了修补一个旧的不一致，去给一个正在使用的登记册重新编号——重新排列过的序号，会让每一条引用了旧编号的交叉引用、培训记录和历史审计轨迹都失效。
按风险设定审查周期，而不是套用一条一刀切的规则
安全关键的 SOP 应该比低风险的 SOP 有更短的审查周期；图表自身的“变更影响安全关键步骤？”分支，用的正是这套逻辑，只是应用在单次变更上，审查节奏也应该沿用同样的逻辑。把这个周期以到期日的形式写进 SOP 的页眉，不要指望有人记得某条政策。
为整个登记册指定一位负责人
一份 SOP 的作者起草它的条目，它的审批人在上面签字，但两者都不对整个登记册负责——不对那条逾期三周的条目负责，也不对那份没人设定审查日期的 SOP 负责。把这份职责交给一个具名角色，通常是文件管理员或质量经理，让他去追那些逾期的事项。
把一次“无需变更”的审查也记成它自己的条目
当一次计划审查确认某份 SOP 依然正确时，把这个结论连同日期和评审人姓名写进登记册，就像记录一次真正的修订一样。一份只在内容变化时才增长的日志，在审计员看来就是一份自成文以来没人看过的文件。
在两条重复条目相撞之前先发现它们
在起草一条新条目之前，先检查这份 SOP 是否已经有一条待处理条目——登记册里“修订历史登记册中是否已有该 SOP 的待处理条目？”这个问题之所以存在，是因为两位作者从同一份母本各自开工，是件足够常见的事，值得专门绕过。把这些变更合并，或者给条目排定先后顺序，这样日志就永远不用去调和同一份文件的两个候选版本号。
应避免的错误
为了修补一个旧的不一致而重新编号
一旦第 4 版已经被写进一条培训记录或供应商资料包，现在为了套用一套更整洁的方案把它改成 4.1，就意味着同一段日期范围要对两个不同的编号负责。方案只定一次，然后去治理例外情况，而不是重新调整整个序列来迁就它们。
给每份 SOP 都套用同一个十二个月的审查日期
在同一个周年日审查每一份程序，会堆出一摞没人有时间仔细读的文件，审查就变成了走过场。像图表的安全关键分支对单次变更所做的那样，按风险错开审查周期，让评审人真的有时间处理每一份。
没有变更的审查没有条目
一份只在内容有变化时才有条目的登记册，在审计员眼里就像一份自发布以来没人打开过的文件。把审查日期和“无需变更”这个结论记为它自己的一行，与真正的修订区分开，但同样真实有效。
登记册没有唯一的负责人
当任何一位 SOP 作者都能开立一条新条目、却没有人在盯着整个登记册时，重复的草稿和错过的审查日期都会一直被忽视，直到审计发现它们。围绕这个问题的完整文件生命周期——包括谁拥有这份母登记册——见 /zh/templates/文件控制流程。
搭建你自己的 SOP 修订登记册
从这张图表开始，QueryChart 会把每一次保存记入一份你可以比较和还原的变更日志。
相关指南
常见问题
一份 SOP 的修订和它的版本有什么区别？
修订是那条带日期的条目——对 SOP 内容的一次改动，附带作者和原因被记录下来。版本是这条条目产生的那个编号，盖在当前发布副本上的那个号。实际使用中两个词经常混用，但登记册本身是围绕修订组织的：每一行都是一条修订，版本是最近一条修订获批之后 SOP 所处的那个状态。QueryChart 自身在 /features/version-control 的版本历史，用“版本”的方式也一样——每次保存产生一个带编号、可比较的快照。
SOP 应该多久审查一次？
没有哪一个间隔适用于所有程序——正确答案取决于这一步一旦出错代价有多大。安全关键或面向监管机构的 SOP 通常每年或更短周期就要审查一次；低风险的行政类 SOP 两到三年审查一次也是安全的。比具体数字更重要的是每份 SOP 都要有一个审查周期，写进页眉作为到期日，而不是等着某个碰巧注意到它逾期的人。
谁应该负责 SOP 修订登记册？
应该是独立于任何单一 SOP 的作者或审批人的人——通常是文件管理员或质量经理，也就是上面图表里那个泳道，负责给每一条获批条目定稿的角色。作者和审批人各自对一次修订负责；登记册需要一个人对整个集合负责：追逾期的审查、抓重复的条目、维持编号方案的稳定。
一次没发现需要变更的审查还算数吗？
算，而且它需要自己的记录来证明这一点。审计员抽查修订登记册时找的是审查按计划发生过的证据，不是 SOP 变过的证据——一份写得正确的程序理应多年保持不变。把审查日期和“无需变更”这个结论记为一条带日期的条目，否则两次修订之间的空档，读起来就像是被忽视，而不是稳定。
这和追踪 SOP 里的单次变更有什么不同？
追踪单次变更是条目层面的事：改了什么、谁改的、取代了什么，这是 /zh/guides/如何追踪SOP变更 讨论的主题。管理 SOP 修订是登记册层面的事：每条条目都要遵循的编号方案、每份 SOP 到期该走的审查周期，以及一旦其中任何一环松动时那位具名负责人。一份登记册可以把每一次单独的变更都记得完美无缺，却因为没人负责这套时间表而管理得很差。本文之外更完整的一套治理实践，见 /zh/guides/SOP版本控制最佳实践。
