变更管理流程图（ITIL）
ITIL 变更管理流程图：RFC 受理，标准、常规与紧急变更的分流，CAB 审批，变更日历排期，实施、验证、回滚与实施后评审。
运作方式
把泳道改成你们实际拥有的角色
把申请人、变更经理、CAB、实施团队与服务负责人替换成你们真实的职能。不少组织由同一个人兼任变更经理和 CAB 主席，规模更小的团队根本没有独立的实施团队。与其画一个你们并不存在的结构，不如把泳道合并，并且把泳道控制在五条以内——再多，这张图就没法一眼读懂了。
在分流决策处定义你们的三种变更类型
在“变更类型？”这个决策旁边写清楚什么算标准、什么算常规、什么算紧急，并按风险和影响范围而不是按工作量或工单大小来划界。把预先批准的标准变更清单保持得足够短，短到真的有人愿意维护它，并为每一项标准变更配一份必须遵循的成文变更模型。
指定变更授权方、它的会议节奏，以及它的紧急对应方
在 CAB 评审这一步记下审批人是谁、多久开一次会、上议程的截止时间。ECAB 要单独定义：有权批准非工作时间修复的，很少是整个委员会。多数团队最后采用的规则是：几分钟内口头授权，当天补齐记录，在下一次 CAB 上评审。
写明评估记录必须包含什么
把“记录评估与回滚方案”变成一份真正的检查表：受影响的服务与用户、风险评级、依赖关系、停机时间窗、测试方法、回滚步骤，以及由谁执行回滚。CAB 的决策不会好过这份记录的质量，而它正是审计员几个月之后会来索取的那份文件。
把排期与冲突规则写明白
写清楚你们的冻结期、最短提前量，以及变更日历由谁负责。这张图里的冲突检查被刻意画成一个决策而不是一道手续，因为大多数撞期是两个团队碰到了同一个共享依赖，而不是碰了同一个系统。事先决定：撞期意味着重新排期，还是意味着升级。
定义什么叫成功，然后发布并对程序做版本管理
说清楚“变更是否成功？”在你们这里意味着什么：哪些冒烟测试、服务负责人观察多久、什么情况下下达回滚指令。然后把图放到工作真正发生的地方——变更申请表旁边或者运行手册里——向图中点名的人收集审批，并保留历史版本，好让你们能说明程序是什么时候改的、为什么改。
常见问题
这是信息技术变更管理，还是组织变革管理？
是信息技术变更管理。两者共用一个名字，此外几乎毫无关系。这张流程图画的是 ITIL 风格的生产服务变更运营流程：提出 RFC，分流、评估、授权、排期、实施、验证、关闭。组织变革管理是与人相关的学科，帮助员工接受一种新的工作方式，通常围绕 ADKAR 或科特八步这类模型来组织，它没有 CAB、没有变更日历、也没有回滚方案。如果你们要找的是干系人分析与沟通规划，那就找错图了。
标准变更、常规变更和紧急变更有什么区别？
标准变更风险低、执行频繁，并且依据一份成文的变更模型预先获批，因此无需逐项审批，直接进入排期。常规变更是指必须就事论事地评估和审批的变更，走的是从风险与影响评估到 CAB 的那条路。紧急变更是指等到下一次 CAB 造成的损害会大于变更本身风险的情形，因此由紧急 CAB 加急授权。在这张图里三者都汇入同一个变更日历、同一套实施与评审，因为类别改变的是审批路径，而不是记录。
每一项变更都要上 CAB 吗？
不需要，而且把所有变更都送上去，是让人绕开流程的最快办法。CAB 存在的意义，是评审那些风险尚未被摸清的变更。当某一类变更执行的次数已经多到有了可靠的程序和已知的失效模式，就把它升为带成文模型的标准变更，并从议程上拿掉。一个把会议时间花在给日常工作盖章上的 CAB，其实什么也没有评审；而它造出来的队列，会把真正有风险的变更推向紧急通道。
变更失败了应该怎么办？
它走的是和成功变更完全一样的那条关闭路径。在这张图里，“变更是否成功？”处验证不通过会触发实施团队泳道中的回滚方案，随后这项已回滚的变更同样进入实施后评审与关闭。让这一点在实践中站得住的有两件事：回滚方案是在变更执行之前就写好并获批的，而不是在事故当中临时想出来的；以及评审既问变更是否奏效，也问当初的变更类型判断对不对。第二次尝试是一份新的 RFC，因此失败的那一次保留着它自己的记录。