文件变更控制流程图
文件变更控制流程图：涵盖小改/大改分类、评审人影响评估、审批、版本标注、分发名单更新，以及对前一版本的正式作废。
什么是文件变更控制流程
文件变更控制比文件控制更窄，也和 IT 变更管理性质不同，这三者值得分清楚。一份治理性文件从申请、起草、审批、发布到定期审查的完整生命周期，是 /zh/templates/文件控制流程 上的文件控制流程。一项拟议的系统或服务变更所要经过的关口——影响评估、CAB 审批、回滚方案与部署窗口——是 /zh/templates/变更控制流程 上的变更控制流程。这张图两者都不是。它是一份已经生效的文件需要变更时启动的那个具体子程序：修订如何被分类、评审、审批、编号并推送出去，以及它所取代的那份副本如何被正式撤回。这里没有 CAB，没有回滚窗口，也没有部署方面的用语，因为文件修订不是系统变更。
大多数成文程序会跳过的那道判断，恰恰在最前面：“变更被归类为小改还是大改？”措辞修正、排版更正或错别字改动，不需要和改变文件实际要求的变更接受同等程度的审查，而把每一次变更都一视同仁，要么让琐碎的修改拖着走完整个评审周期，要么让实质性的变更从原本为错别字准备的快速通道里悄悄溜过去。这张图把这个分岔明确画了出来：小改被快速准备并快速审批，大改则先送交变更评审人做一次留有记录的影响评估，再抵达同一个审批关口。
让这套流程最区别于一般修订流程的两个步骤，都发生在审批之后。“更新版本号与分发名单”把版本标注和现行副本持有人名单当成一个动作，而不是两个，因为文件版本改了、分发名单却没跟着改，正是有人最终拿着落后一个版本的副本在工作的原因。而“撤回并将前一版本标记为已作废”，给旧副本一个明确、有记录的退场，而不是任由它自行淡出使用，同时由分发名单持有人确认撤回，留下谁被告知过的记录。
若修订源于工程变更，先取得已批准的 ECN／ECO，列明受影响图纸、BOM 与作业指导书的旧／新版本及生效点，再走本图的审核、批准、编版与分发。ECR-014 的示例把 D-014、BOM-100 与 WI-014 同步至 P-014 rev B、L-015；发布及旧副本撤回记录交回变更负责人。文字小改的快速通道不能取代工程对产品定义与库存处置的授权。
工程决策与文件发布的交接
本流程图涵盖的内容
本模板包含
- 五条泳道——申请人、文件负责人、变更评审人、文件管理员与分发名单持有人——横跨五个阶段：申请、评估、审批、版本与分发，以及作废。
- 受理：“识别到受控文件的变更”引出“提交文件变更申请”，其中记录文件编号、当前版本与变更原因，然后是“将申请登记到该文件的记录上”。
- 分类分岔：“变更被归类为小改还是大改？”把小改直接导向“准备快速通道修改”，而大改先要经过“变更评审人评估全面影响”和“记录对相关文件与表单的影响”。
- 两条路径都汇合到“是否批准？”这道判断，其“驳回”分支回到“修改草稿并重新提交评审”，循环回评审阶段，而不是终止申请。
- 由文件管理员负责的版本与分发阶段：“更新版本号与分发名单”“将新版本发布到受控位置”，然后是“通知分发名单持有人新版本已发布”。
- 正式作废：“撤回并将前一版本标记为已作废”与“分发名单持有人确认撤回”，最终止于“文件按正式变更控制重新发布”。
何时使用本模板
- 你们正在为单份受控文件如何变更编写具体的子程序，并希望把它与更宽泛的文件控制生命周期分开，以免在审计中把两者混为一谈。
- 已作废的副本总是和现行版本一起出现，你们需要一个明确的版本标注与撤回步骤，而不是指望大家自己注意到旧版本已经不在了。
- 目前每一次变更都走同一套重量级评审，导致无关紧要的措辞或排版修正，堵在真正改变要求的变更后面排队。
- 你们的分发名单是一张没人记得更新的电子表格，你们希望版本标注和名单更新合并成一步，而不是两个可能各自脱节的步骤。
- 审计员或认证机构问过你们，怎么知道受控文件的每一位持有人都被告知了这次修订，你们需要把通知与确认画成一个明确步骤，而不是想当然地默认它发生了。
运作方式
把泳道改成你们真实的角色
把申请人、文件负责人、变更评审人、文件管理员与分发名单持有人，换成你们实际拥有的角色。小团队里，除了大改之外，文件负责人和变更评审人往往是同一个人——把这两条泳道合并，而不是画一道从不会独立发生的评审。
写明什么算小改、什么算大改
分类判断的好坏，取决于它背后的规则。列出例子：错别字与排版修正、更新联系方式、修复失效链接属于小改；改变要求、职责、审批权限或引用管控措施的，属于大改。把这条规则放在判断旁边，让申请人在提交给文件负责人之前就能自行分类。
定下你们的版本编号方案
在“更新版本号与分发名单”这一步，定下惯例：比如大改、已批准的修订用整数，小改、快速通道的修订用小数。写明每一页必须出现什么：文件编号、版本、生效日期与审批人，这样光凭编号，读者就能判断自己看到的是不是现行版本。
定义分发名单以及由谁维护它
明确这套流程更新的是哪份名单：名单上的人按角色而不是姓名列出，某人加入使用该文件的团队时如何被加入，离开时又如何被移除。决定通知是一次群发，还是需要经过这张图在“分发名单持有人确认撤回”这一步所画出的确认。
列出已作废副本可能残留的每一处
“撤回并将前一版本标记为已作废”只有在背后有一份清单时才真正可执行：共享盘、使用现场的打印件、内网页面、入职资料包、供应商或客户手中的副本。在保存期内保留一份标注为已作废的归档副本，而不要直接删除。
决定什么会触发全面影响评估
在“记录对相关文件与表单的影响”这一步，列出变更评审人必须核查的类别：被引用的程序、关联表单、培训材料，以及任何引用了本次改动章节的其他受控文件。凡是受影响的，都需要单独提交变更申请，而不是悄悄夹带在这一次里改掉。
常见问题
什么是文件变更控制？
它是专门在一份已获批准、正在使用的文件需要变更时启动的程序：变更如何被申请、如何被归类为小改或大改、以与该分类相匹配的深度接受评审、如何获批、如何标注新版本号、如何推送给持有副本的人，以及它所取代的版本如何被正式撤回。它是更宽泛的文件控制生命周期的一个子程序，而不是取代它；文件控制还涵盖文件在发生任何变更之前的首次起草与审批。
文件变更控制和 IT 变更管理有什么区别？
两者形态相似——申请、评估、审批、实施——但对象不同。IT 或 ITIL 式的变更管理管的是系统与服务的变更：需要变更咨询委员会（CAB）、风险与停机评估、排定的变更窗口和回滚方案，因为在变的是正在运行、可能在变更过程中出故障的基础设施。文件变更控制管的是一份书面制品的变更：政策、程序、作业指导书或表单。这里没有停机窗口，也没有回滚方案，因为文件修订不像部署那样“上线”，它只是取代一份已作废的副本。两者被分开成文的道理，和一家工厂把设备变更日志与程序变更日志分开保存是一样的：风险不同、评审人不同、需要的证据也不同。
怎么判断一次文件变更是小改还是大改？
看这次变更对文件要求本身造成了什么影响，而不是看改动痕迹有多大。错别字修正、排版更正、更新职位名称或修复失效链接属于小改，无论它改动了多少行。改变文件要求某人做什么、某个步骤由谁负责、审批权限、引用标准或安全说明的，即使只改了一个字，也算大改。把这条规则写在判断旁边，而不是留给当天临场判断，这样同类变更无论由谁提出，都会得到相同的分类。
为什么要在更新版本号的同时更新分发名单？
因为版本号改了、分发名单却没跟着改，正是一份受控副本在某人手里逐渐过期的原因。分发名单记录的是谁有资格持有该文件的现行副本；如果它和版本标注分开更新，或者更新得比版本标注晚，就会出现一个窗口期：新版本已经存在，但需要它的人还没被加进名单，或者已经离开相关岗位的人还在继续收到它。把两者当成一个步骤来处理，正是让文件上的版本号与持有它的人员名单不至于脱节的关键。
此流程所处的位置
在大多数组织中，此流程紧随文件审批工作流决策树之后，并交接给制度审查与审批流程图（从触发到签认）。
它是文件控制中的一个步骤。
第 1 步: 文件控制流程图
第 2 步: 文件版本控制模板
第 3 步: 文件审批工作流决策树
文件审批工作流的决策树：编辑性修改还是实质性修改、按文件类型确定的必审评审人、第二审批人，以及发布时的已读并理解要求。
第 4 步: 文件变更控制流程图 当前位置
文件变更控制流程图：涵盖小改/大改分类、评审人影响评估、审批、版本标注、分发名单更新，以及对前一版本的正式作废。
第 5 步: 制度审查与审批流程图（从触发到签认）
制度审查与审批流程图：按到期日或事件触发，确认责任人，差距分析，征求意见，法务与职工代表审核，分级审批，发布与签认。