直达原文： 【ITSM系列】ITSM流程落地经验之变更管理
大多数组织中都实施了变更管理，但是效果参差不齐，尤其在变更管理的核心环节，部分组织因缺乏有效的把控，使得变更管理的效果不尽人意，甚至可能面临失控的风险。为此，我们有必要深入探讨并详细分析变更管理中的关键活动，并通过实例加以说明。
变更模型与适用场景
变更模型是对特定变更的可重复管理方法，这种方法为处理一般变更提供指导，解决一般变更无法适应不同的管理模式的问题。组织可以根据评估，授权和持续控制的类型定义不同变更模型，提升变更效率和效果。
在设计变更模型时，可以基于以下因素定义不同的模型：
- 变更的系统/技术
- 变更的规模
- 地点/地区
- 客户/用户
- 影响变更的合规要求
以下是某个IT组织定义的多种不同的变更模型：
变更窗口的作用
在运维工作中，经常会出现缺乏计划和统筹的变更，甚至是随意实施变更，如果要避免这种现象，就需要把计划执行的变更进行统筹安排，也就是使用变更窗口。
变更窗口的作用是确定不同的业务线、业务系统实施变更的日期，减少随意的变更对服务的影响。
在制定变更窗口时需要考虑多个因素:
- 对业务的影响
- 不同的地域分布
- 个别客户的特定业务需求
- 变更实施和回退的时间
- ......
变更窗口在定义后应正式公布，供所有参与变更人员使用。
以下是变更窗示例：
标准变更的定义
标准变更也称为预授权变更，指的是经常发生、影响范围小、有标准操作步骤、实施风险小(不会带来重大后果)的变更，有频繁发生、容易执行、失败的概率小等特点。这种情况下可以对这些变更进行预授权，避免繁杂的变更审批流程，从而提高效率。例如新增用户账户、修改网络连接、重新安装操作系统等。
在日常运维工作中，有70%-80%是简单重复性的变更。标准变更为提高变更管理工作的效率提供了可能，将这些简单重复的变更工作标准化，取消审批环节，放权给变更的实施人员，从而提高整个变更管理流程的效率，这也是标准变更的价值所在。
但是值得注意的是：
- 标准变更是为了提高工作效率的，因此对于那些虽然简单、风险也小但是不常发生的变更没有必要定义为标准变更。
- 标准变更并不是忽略风险控制，而是在将其定义为标准变更前，已经对其进行了风险评估。因此如果要将一个变更定义为标准变更，必须重复过多次且没有失败过，否则它本身存在的风险就不足以使之成为标准变更。另外，标准变更必须是涉及金额较小的变更。当变更涉及的金额较大时，也是需要经过组织的各相关利益方审批，不能作为标准变更进行处理。
定义标准变更的方法
制定规则
这种方式是指通过规则描述的方式对标准进行定义。优点是规则容易定义，但缺点是执行过程中容易产生争议，在制定标准变更定义的规则时，只能定义标准变更的属性或者类别，但是无法准确列举所有可能。
以下为IT 部门利用规则法制定的标准变更示例：
- 参与实施的人员不超过2人；
- 不涉及技术架构调整；
- 涉及的费用在 3000 元以下。
枚举场景
这种方式是指将组织日常用到的标准变更逐一罗列，形成预先定义的标准变更清单的定义方法。标准变更清单并不是制定后就不再修改，而是随着组织的变更内容不断增加，标准变更也会不断增加。可以考虑每半年或每年对标准变更清单进行一次修订，并由CAB（Change Advisory Board）成员进行评审。这种方式的优点在于定义明确、针对性强、操作性强，缺点在于完备性不够，在列举标准变更时可能会出现遗漏。但由于标准变更清单会不断增加补充，因此在一定程度上弥补了这一缺陷。
CAB会议如何开展
CAB团队和CAB会议是实施变更管理中非常关键的一环，很多即将或已经实施ITSM的组织不清楚CAB会议应该如何开展，在这里进行简单和关键的介绍。
CAB的成员的构成和职责
CAB成员的选择需要综合考虑到各方面的需求，例如系统的基础设施架构、业务需求、SLA\OLA以及和供应商之间的关系，选择适当的成员才能够正确评估变更。
CAB会议人员的构成包含两类：CAB成员和参会人
- 成员必须参与所有的CAB会议，并且有权安排和决定是否批准变更，优先级和变更时间表安排。
- 参会人包括各领域专家、技术团队、供应商负责人和业务代表，他们需要提供与变更相关的具体信息和专业知识建议，参会人由变更经理按需邀请。
同时CAB需要承担典型的职责，并拥有相关的权力，以下是某IT部门制定的职责和权力清单：
CAB投票流程
CAB会议中最常见的活动是对变更清单中的内容进行投票，确定变更是否按计划执行，以下展示了某个IT部门的CAB投票相关的策略，包括会议前要求、会议中活动、投票的选项和会议议程，这些内容应被正式写入到变更评审委员会章程中，并正式发布。
1、会议前
如果使用变更管理工具，工具可能具备CAB成员在完成变更工单审核后投票的功能：
- 在并非所有 CAB 成员都能参加会议的情况下非常有用。如果符合这种情况，需要发送包含变更请求单（RFC）内容和投标按钮的通知，例如IM消息或邮件。
- 如果会前的投票结果不是决定性的，则需要在会议中进行二次投票。
2、会议中
- 在CAB会议期间进行投票。
3、投票的选项
- 通过票
- 拒绝票
- 推迟票（与其他版本捆绑）
- 要求进行更多的测试（推迟到下次投票和决议）
4、会议议程
议程应包括以下活动：
- 最终的变更请求单（RFC）的审核：在领域专家在场的情况下，了解和询问有关RFC的任何未解决或有疑义的问题。
- 对变更进行批准/拒绝的投票。
- 对变更进行优先级排序。
- 安排变更的时间表。
- 回顾上一次CAB会议后所有变更的实施结果（重点关注实施失败的变更）。
- 讨论其他事项：
- 变更管理活动中角色的变化；
- 标记和记录可能被设置为标准变更（或称预授权变更）的一般变更；
- 流程改进意见和措施；
- 指标和报告。
与所需要讨论和确定的内容复杂性相比，CAB会议的时间很紧张，因此会议的准备工作很重要，建议在1 小时的会议中，每项活动的时间尽量不要超过10-20 分钟。
变更风险的评估
风险评估是指根据变更各方面信息的综合评分来判断变更的风险等级，进而判断变更所属的类型。在判断出变更的类型后根据相应的审批路径逐步审批。
风险 = 影响 x 风险事件发生的可能性
下方的风险矩阵描述了根据影响和可能性的不同风险级别变更的分类，以及影响和可能性定义的示例
风险定义
影响的定义
可能性的定义
变更实施后的回顾
变更后的回顾活动的目的是确定：
- 此次变更达到了预期效果和目标；
- 用户、客户和其他相关方认可变更后的结果；
- 对服务水平（例如可用性、容量、安全性、性能或成本等）不会产生其他不利的影响；
- 用于实施变更的资源按计划进行；
- 发布和部署计划正确进行（回顾应包括实施人的评价）；
- 变更按时且符合预期成本进行了实施；
- 如果有必要，回退计划可以正确发挥作用。
组织可以参考下方内容实施后回顾，确认是否达到变更目标、发起人和其他相关方是否接受变更结果，并且没有引发其他的事件。
总的来看，设计有效的变更管理流程不仅能确保IT服务的稳定性和安全性，还能提升业务效率和用户满意度。通过明确变更类型、设定变更窗口、定义标准变更和组织CAB会议等步骤，企业可以更好地控制变更风险，实现变更的有序管理。
希望本文提供的详细指导和案例分析，能为各组织在实施ITSM变更管理过程中提供参考和借鉴，从而不断优化其IT运营管理实践。
直达原文： 【ITSM系列】ITSM流程落地经验之变更管理
扫一扫
2501
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
