ITSM 最佳实践课程与案例：
银行变更管理的全面改革

场景

印度一家中型银行决定通过实施 IT 服务管理（ITSM）来管理其基础设施运营和应用开发。因此，该银行的 IT 团队采用分阶段方法，重点关注三个 ITSM 流程——事件管理、请求履行和变更管理。首先，IT 团队基于 ITSM 框架为这三个流程设计了最佳实践方法，培训了其他员工，记录了流程的 RACI 和矩阵，并确定了用于跟踪绩效的关键绩效指标（KPI）。随后，银行购买了一款服务管理工具，以根据 ITSM 工具中嵌入的最佳实践来遵循工作流程或流程。

在接下来的三个月中，该工具为组织带来了显著变化。流程与合规负责人审查了指标和 KPI，指出事件和服务请求处理良好，但变更请求处理不佳。

以下是三个月期间记录的变更快照

如图 A 所示，标准变更较少，而普通变更和紧急变更持续增加。此外，存在多起失败变更，业务开始对 IT 失去信心。

核心团队采取正确的变更管理方法

由基础设施负责人、应用开发负责人、变更经理和服务台经理组成的核心团队成立，以纠正现状。该团队采访了支持和开发团队，分析数据以了解变更失败的原因，进行了差距分析，并提出了切实可行的解决方案。

导致众多变更失败的原因是什么？

基础设施和应用团队面临提升绩效、升级服务器以及缩短所有进入生产环境变更的周转时间的压力。他们无法看到正在变更的组件的上下游关系。例如，当 Exchange 服务器宕机时，基础设施团队无法在ITSM 工具中找到相关信息。团队不得不依赖主题专家（SMEs）或 Exchange 服务器团队。当 SMEs 不可用时，团队只能依靠独立流程进行变更。因此，变更未被充分分析，变更评审团队无法准确预测变更的影响。

核心团队如何应对这一问题？

核心团队认识到需要构建配置管理系统（CMS），以捕获完整的基础设施和应用拓扑结构及其属性和关系。

团队列出了关键业务服务，构建了嵌入各种设备属性的服务树结构，以及相关的父子关系，如图 D 所示。团队确定了完整的拓扑结构，并获得服务器、存储和网络 SMEs 的签字确认，然后导入到服务管理工具。

此外，团队无法看到计划、安排和部署的变更。没有适当的机制来发布变更的前瞻性计划或跟踪计划变更及其发布日期。

核心团队如何简化变更工作流程并确保可见性？

核心团队发现变更常常在最后一刻提交，缺乏足够时间评估和执行变更。这是由于缺乏适当的纪律和治理来管理变更的接收和执行。

定义变更管理规范和标准

为避免最后一刻变更，他们向业务负责人传达了变更的影响、理由和业务影响，并就以下条件获得了强制批准：

• 所有普通变更应每 15 天进入一次生产环境。
• 所有变更必须每 15 天与发布捆绑，普通变更无例外。
• 所有变更请求（RFC）必须至少提前两周提交。任何要求在一周内完成的 RFC 将被拒绝，并通知请求者的经理。
• 即使在极端情况下，任何加速普通变更的请求也必须经过管理层三级审批。IT 团队跟踪审批情况以管理提出的变更。
• 紧急变更仅在以下两种情况下受理：
• 解决计划外停机、重大中断或事件。
• 由于不可避免的原因未部署的完整发布。

定义不同类型的变更

标准变更与普通变更

标准变更是低风险、预先批准的频繁发生且周转时间快的变更。标准变更可以快速实施，有助于风险管理。

标准变更示例：

• 台式机或独立设备的移动。
• 一种标准补丁，每月在约定的维护窗口期间应用于服务器

什么是标准变更？

当一个正常变更成功实施多次后，相关的流程如规划、调度和实施得以建立，变得可预测且受控。也就是说，该变更成为常规任务，因此是标准的。

一些正常变更的示例：

• 升级 exchange 服务器或任何其他硬件
• 为关键业务功能（VBF）设置高可用性或集群
• 推出新版本以解决报告的问题

加速或快速通道变更

加急变更因法律或业务需求等紧迫需要而提出。这些变更与恢复服务无关。

紧急变更与加速变更的区别

change advisory board (CAB) 制定了明确的规则和条例以界定紧急和加急变更，并将这些规则传达至整个组织。

变更日历以提升可见性

核心团队使用服务管理工具中的变更日历报告计划的维护、变更和发布，并确保相关团队有更好的可见性。

定义关键绩效指标

为了吸收 change management process 的效率和效果，核心团队确定了以下关键绩效指标（KPI）。

• 标准、正常和紧急变更的失败次数和百分比
• 正常和紧急变更导致的事件数量和服务停机时间
• 非计划或紧急变更的数量或百分比
• 实施变更的平均时间
• 被 CAB 拒绝的变更数量和百分比
• 未授权变更的数量和百分比

前四个 KPI 来自服务管理工具，第五和第六个则需要专家介入。

变更咨询委员会确保更好的变更评审

核心团队确保 CAB 每周四当地时间晚上7点至9点召开会议。基础设施、应用、服务台和发布管理团队的代表审查所有计划变更，但变更经理是最终决策权威。

CAB 拒绝变更主要是因为未遵守预期的评估、审查和业务影响分析（BIA）步骤和协议。变更负责人对此失败承担责任。核心团队被迫采取严格措施以防止此类事件再次发生。变更在 CAB 会议前从所有可能的场景进行评估。

处理未经授权的变更

在与利益相关者讨论时，核心团队观察到约20%的变更未经授权完成，主要是因为基础设施团队承受快速完成变更的压力。因此，许多变更未提交变更请求，也未经过审查和批准流程。

为应对这种情况，基础设施、应用和数据库团队分别指定了阶段守门人，确保变更时不跳过任何步骤。阶段守门人持有“准备就绪”清单，包含测试结果、所有相关团队的批准和签名以及回退计划。若违规，阶段守门人承担责任，影响其考核和绩效。

未授权变更的另一个原因是应用团队在发布后更新了 CMDB 或 CMS。

核心团队确保每周进行审核，将 CMS 当前状态与相关 RFC 进行比较，任何偏差都会立即通知配置项（CI）负责人和服务负责人采取行动。服务负责人闭环处理并采取坚决措施。此流程持续四到六周，团队养成了无例外遵守规则的习惯。

沟通推广与培训

核心团队实施适当控制后，沟通流程得以简化，使相关团队能够及时获知新变更。因此，业务负责人推出了正式的 change management process, 并随后开展了意识提升和培训项目。

接下来三个月的执行显示出明显改进，如图 F 所示。

经验教训（CSI）

• 银行 IT 团队认识到，构建一个包含所有 IT 组件最新信息的强大配置管理系统，对于成功的变更和 release management process. 至关重要。
• 变更的前瞻性计划、计划维护窗口和发布计划对于管理变更的数量和持续时间以及确保顺利部署至关重要。
• 执行政策需要务实、勤勉和支持。新政策数量较少，但对变更管理过程的成功至关重要（例如：CAB、未授权变更和 PIR）。
• 相关且实用的 KPI 有助于团队提高效率和效果。
• 流程和工具必须协同工作，缺一不可，否则将严重影响持续服务改进（CSI）。
• 关键变更的实施后评审及其影响为改进和控制变更提供了宝贵见解。

底线：

银行通过确保良好治理、实施流程与工具的对齐以及提供强有力的领导力，提高了变更管理过程的整体效率和效果。

本案例研究为您提供了结构化、实施和顺利执行组织变更所需的工具。如果您有关于变更管理过程的有趣经验，欢迎在评论区分享。