ITIL® 中变更管理全面指南

业务格局和客户期望不断变化，数字化转型已成为各行业业务成功的关键因素。数字化转型就是利用可用技术来应对业务挑战并抓住机遇。具体而言，数字化转型可以从根本上更好地解决 IT 管理问题，以消除问题所在，并使您的 IT 基础设施足以应对业务挑战。这涉及实施 IT 变更，帮助您的组织将新技术应用于现有业务和 IT 流程。

这些变更十分简单，例如将协作应用程序移至云中以提高运营效率，或者采用移动优先的方法改善消费者体验。尽管表面上很简单，但是这些变化也会带来相关的后勤挑战。如果未正确实施变更，可能会导致组织出现前进一步后退两步的后果。

一家受欢迎的银行在 2018 年 12 月未能成功升级移动应用程序，这是未能妥善实施变更的一个很好示例。该银行计划推出全新和改进的移动银行应用程序，这是一个好主意，也是迫切需求。但是从推出新应用程序的那一刻起，它就出现了问题。该银行在淘汰旧版应用程序之后才推出新版应用程序。当新应用程序无法正常工作时，成千上万的客户无法通过该应用访问其银行帐户。更糟糕的是，关于新应用程序修复方案的沟通很少，这让客户感到沮丧。在旧版移动应用程序停用四天后，银行决定恢复该应用程序。

我们可以看到，该银行在其拟议变更的各个阶段都失败了：在尚未准备好部署新应用程序时就发布了该应用程序，未能将与更新相关的停机时间透明地传达给最终用户，且没有提出出现故障时的替代方案。这绝对不是您希望实施变更的方式。

这就是为什么需要变更管理。它可以帮助您管理组织中的所有不同变更，并为您提供一个在不影响组织其他部门的情况下有效进行变更的流程。变更管理减少了发生上面所述银行所面临情况的机会。

在本指南中，我们将介绍变更管理的内容、原因和方式。您将学习如何通过有效的变更来帮助组织跟上行业趋势。

让我们开始吧！

什么是变更管理?

ITIL 对于变更管理的定义是，在从始至终的整个生命周期中跟踪和管理变更以最大程序降低风险的过程。

建立系统化的变更管理流程有助于您的组织以高成功率实施无事故变更。

根据 ITIL 的定义，变更是“添加、修改或删除可能对服务产生直接或间接影响的任何内容”。

简单地说，对组织的 IT 基础设施进行的任何可能影响组织运营的变更都称为 IT 变更。这包括更换打印机、投影仪、服务器等。

事件、问题和变更之间有什么区别？

为什么组织需要变更管理?

现在，我们已经了解了变更管理是什么，让我们从变更管理的目标开始，看看组织为什么需要变更管理。

赋予组织控制和管理变更的能力：

变更管理将使您更好地控制变更过程，并帮助您以最小的风险实施变更。通过遵循标准流程，变更管理可确保有效管理每个变更的各个方面，如计划、风险评估和跟踪实施。利用服务台工具从始至终跟踪变更可以产生奇妙的效果，并使组织能通过精心计划和执行变更，更好地管理其 IT 基础设施。

帮助组织更好地实施更改：

通过跟踪整个变更过程，变更管理让组织能够始终了解所有变更请求。它还能协助轻松识别和限制未经授权变更的数量。仅允许用户通过服务台工具提交变更请求 (RFC)，组织可以从一开始就收集有关变更的所有必要信息，然后决定是否需要实施变更。强大的审批机制可确保在获得所有必要权限后才能实施变更。

带来持续改进：

变更管理不只是为了未雨绸缪；其目的是帮助组织持续改进他们的基础设施和流程，并通过确保他们能够顺利地实行必要的变更而不影响当前的服务运营，从而跟上行业趋势。

对于组织：

• 由于对变更的有效管理，减少变更冲突。
• 能够在不影响运营的情况下实行升级。
• 减少变更失败的情况。
• 对变更进行精确分类。

对于最终用户：

• 已提前对变更做好安排，可以更好地传达有关停机时间和服务不可用的信息。
• 减少因计划不周的变更而造成的中断，实现更顺畅的服务运营。

组织如何进行变更管理?

现在让我们看一下如何在组织中实施变更管理。首先要建立一个有效的变更流程，让您能够计划变更、获得必要的批准并实施变更。您可以按照以下变更管理流程来有效处理变更。

变更管理流程

第1步：提交

第一个阶段是发起变更。这涉及收集基本变更单信息，如变更类型和优先级。

• 创建： 使用服务台工具发起变更单。使用包含必填字段的变更表，从一开始就收集必要的信息。
• 定义变更角色: 通过使用变更角色，组织可以将变更责任委派给各个相关方，并控制每个角色在变更的每个阶段所具有的访问级别。

第2步：计划

下一阶段是整个变更的计划。计划周密的变更是成功实施变更的秘诀。获得实施变更所需的必要批准也很重要。记录影响、推出计划、回退计划和相关的停机时间等详细信息，以将变更计划清楚地传达给相关方，并说服他们认为变更值得进行。

第3步：审批

接下来，变更计划需要由变更咨询委员会 (CAB)、紧急变更咨询委员会 (ECAB) 以及与变更或受变更影响的组织基础结构有利益关系的任何其他机构审批。创建自定义 CAB 可帮助组织对相关人员进行分组，以轻松管理审批。自动化审批流程可加快整个变更的速度，并确保不会忽略任何审批请求。

注：CAB 是各种工作角色和团队的结合。它可能包括 C 级高管、团队经理、技术团队、财务人员等，具体取决于变更的严重性和规模。

第4步：实施

获得必要的批准后，就可以实施变更了。组织可以通过创建任务或使用项目来跟踪和管理变更的实施。

• 通过任务委派工作: 创建任务并将其分配给来自不同团队的不同技术人员，以轻松管理所有实施变更的人员所完成的工作。父任务和子任务可用于设置任务依赖性，并确保任务以特定顺序完成，且不会遗漏任何任务。
• 利用项目管理: 组织可以使用项目来处理大规模变更，例如将组织的整个基础设施移至云中。项目支持更大的实施范围，且可以更好地处理更多的任务、人员和里程碑。变更管理与项目管理之间的强大集成可能对组织大有助益。

第5步：查看

接下来，进行实施后审查，以确保在实施中不存在偏差，并在变更关闭之前解决所有问题。

第6步：关闭

这是变更管理流程的最后一步。已完成变更的性质会记录为成功、失败或不完整。记录正确的关闭代码可使组织的指标更加准确和有用。

并非所有变更都是相同的，因为某些变更具有不同的要求。有些变更需要尽快实施，有些需要组织上级的批准，而有些只是每周进行的一般变更。

根据 ITIL 的定义，变更可以大致分为三种类型：标准变更、一般变更和紧急变更。

标准变更：

这些是预先批准的变更，影响较小，众所周知，且已记录在案。首次实施标准变更时，需要进行风险评估和授权，但是，只要不对变更进行修改，就可以在没有这些预防措施的情况下进行后续实施。
示例：更换打印机的墨盒

一般变更：

一般变更需要遵循整个变更流程。应该提前安排、进行风险评估并获得授权。一般变更包括次要变更（低到中度影响和紧急性）和重大变更（高影响和紧急性）。所有非标准或紧急变更都应视为一般变更，并遵守变更流程。
示例：将本地服务移至云中

紧急变更：

紧急变更具有高影响和紧急性，需要加快评估、批准和实施，以尽快启动和运行服务。对影响业务运营并因此导致停机的组件的修改被视为紧急变更。
示例：主服务器故障、数据中心中断、针对安全漏洞的紧急补丁

变更负责人：

变更负责人负责整个变更管理流程，包括其改进。由于他们负责组织的变更管理，因此通常是高层领导。

变更经理：

变更经理负责变更的实施以及与之相关的活动。他们还管理 CAB 以及所涉及的各个团队和相关方，并与他们进行协调。

变更发起人：

变更发起人是发起变更并添加变更计划、实施计划和其他所需详细信息的人员。他们还制定变更实施计划。变更发起人可以是技术人员或最终用户。

CAB：

CAB 是来自不同团队和职能部门的各种成员的集合。他们共同分析拟议的变更，并就变更及其实施给予审批和建议。

其他角色：

除这四个主要角色外，某些组织还使用自定义角色来委派工作并分担职责。创建自定义角色有助于您根据组织的需要调整变更管理。一些常用的其他角色有：

• 变更审批者
• 变更实施者
• 变更审查者
• 变更计划员

以下是四个可能阻碍变更管理的常见挑战。

1. 变更失败：

   变更需要大量的资源，因为需要大量的时间和调查来进行变更规划。如果不加以检查，大量失败的变更很快将带来巨大的损失。如果是基础设施变更，高故障率可能会在实施过程中或实施回退计划时导致更大的问题。失败变更过多也表明变更管理流程不良。

   示例：Zylker 计划升级其主要网络基础设施，因此该公司与第三方网络提供商建立了备用网络。公司计划在一个周末内实施变更。实施期间，Zylker 收到了有关服务中断的工单，这令人惊讶，因为该公司已建立了备用网络。事情真相是，备用网络提供商也在周末进行定期维护，这意味着 Zylker 的主要网络和备用网络都已关闭，导致 Zylker 的服务不可用。由于变更计划不周，最终失败。

2. 未授权变更：

   未授权变更是因审批机制不佳以及在审批阶段未能包括适当的相关方所导致。这些变更会绕过必要的权限，如果未及时标记，则可能会终止实施。未授权变更可能会导致组织中出现不需要或尚未准备好实施的变更。最坏的结果是，未授权变更会产生不利影响，并带来不必要的支出。

3. 紧急变更过多：

   如前所述，紧急变更需要加急审批，以便可以尽快实施。将太多变更视为紧急变更可能会导致急需实施的严重紧急变更延迟。将变更归类为紧急变更时始终要谨慎行事。

   注：“狼来了”的故事就是一个很好的类比，这个故事说明了为什么将太多变更视为紧急变更会造成适得其反的效果。在发生实际紧急情况时，您的组织可能不会以所需的严肃性来进行变更，并且您可能没有所需的资源来处理紧急情况。

4. 变更冲突：

   计划不周可能导致变更冲突。变更冲突是指无意中计划同时实施两个或多个变更，从而扰乱了任一变更的实施。利用变更日历更好地计划变更可以帮助防止变更冲突。

以下是实施变更管理的最佳方法。

1. 确定变更类型：

   并非所有变更都是相同的。如“变更类型”部分中所述，变更具有不同的优先级和不同的要求。因此，务必要先确定组织可能执行的变更类型， 然后创建不同的变更类型以有效地进行实施。

2. 不同变更类型的设计流程：

   由于不同的变更类型有其独特的要求，因此您需要设计独特的流程来满足这些需求。对所有变更类型使用相同的变更流程只会导致不必要的延迟和变更实施不完整。

   注：您可以为每种变更类型创建不同的变更工作流程。

3. 定义主要角色和职责：

   定义角色可让变更经理向他人委派活动和职责。角色可简化变更管理流程，并能清晰地定义每个人可以执行的活动。

4. 记录和管理变更提案并对其进行优先级排序

   最佳做法是采用一种有组织的方式来记录您的变更，在一个地方进行管理并确定优先级。通过更好地了解组织的变更，您可以对需要执行的变更进行优先级排序。

5. 全面了解变更风险和影响：

   所有变更都需要进行风险和影响分析，以更好地了解变更并分配必要的资源。应在规划阶段添加风险和影响的详细信息，以便 CAB 清楚了解变更并提出建议。

6. 建立有效的审批机制：

   定义审批过程可轻松获得实施变更所需的权限。它确保所有主要相关方都知道变更，并在实施变更之前提出建议。这有助于避免未授权变更。

7. 与相关方沟通时间表和停机时间：

   让相关方始终了解计划的变更，可以减少变更引起的事件数量。发出提示信息还可以确保不会因变更而影响任何服务，并可以有效地执行变更。另外，如果管理层在整个变更期间都能始终了解最新进展，他们也会更满意。

8. 衡量变更实施的进度和有效性：

   在整个变更期间密切关注变更，可以确保不会出错以及根据变更计划实施变更。通过衡量关键指标，您可以清楚地了解变更过程的有效性，以及发现可以改进的领域。

9. 设定应变计划：

   预先防范永不嫌多，计划最坏的情况并在变更计划阶段制定回退计划始终是个不错的主意。这一深入计划可能意味着变更正常失败与对 IT 基础设施造成不可挽回的损害之间的区别。

10. 实施持续服务改进：

    尽管解决眼前问题是变更管理的关键功能，但变更在组织中的作用范围远不止于此。使用变更来改进技术和流程，从而不断增强组织提供更好服务的能力，已成为变更管理的重要功能。

变更管理并不仅限于完成变更。变更管理有效实施变更的能力可以从其他 ITSM 流程中收集的信息中大大受益，反之亦然。将事件与其所引起的变更或引起该事件的变更相关联的能力，或基于 IT 基础设施变更更新 CMDB 的能力仅仅是创建全面的 ITSM 实践的起点，此类实践可与其他流程一起，帮助更好地管理组织。

以下是变更管理如何与其他 ITSM 流程一起使用的方法：

1. 事件管理：

   跟踪引起变更的事件和由变更引起的事件，可以让您更好地了解变更如何影响您的组织。例如，当更新路由器时，您可能会收到事件工单，报告互联网已停止运行。将变更与它们引起的事件相关联可帮助您快速确定事件的原因，且无需分配资源来解决该特定事件，因为变更完成后该事件将立即得到解决。

2. 请求实现：

   对影响较大的服务请求使用变更可使您的 IT 基础设置保持最新。如果没有变更，则服务器升级的服务请求或升级 Azure 存储空间的请求将以交付服务作为结束。但是，当您使用变更来实施服务请求时，您可以收集更多信息（如变更原因和实施计划），获得所有相关方的必要批准，并使用新信息更新 CMDB。

   注：对于影响较大的服务请求以及任何需要对 CMDB 进行变更的服务请求，使用变更来实现请求能获得最佳效果。如果需要更新 CMDB，则需要进行变更！

3. 问题管理：

   问题管理要求创建变更以解决问题的根本原因。能够直接从问题单中创建 RFC 使得跟踪相关变更和问题变得容易。它还可以让 CAB 更好地了解为什么需要进行变更，并指出引发变更的问题的严重性。

4. 发布和布署管理：

   发布和部署升级因变更流程带来的结构化方法而获益。您可以使用变更轻松跟踪实施计划、推出计划以及发布和部署的实际实施。公开透明的变更还有助于让所有相关方始终了解最新进展。

5. CMDB：

   CMDB 的任何更新都应通过变更来进行。变更能够提供有关更新原因、方式和时间的许多有用信息。与变更一起执行的影响分析还可以确保对 CMDB 的所有更新进行适当的分析，且该更新不会对组织的其余部分造成任何干扰。您可以使用变更类型来记录不同优先级的 CMDB 更新。

以下是用于衡量变更管理流程有效性的一些重要指标。

让我们详细查看一个变更，了解如何改进变更管理过程。

Zylker 是一家拥有大量远程用户的公司，他们决定采用云路由。

当前，公司的所有生产力应用程序和资源都在公司内部，因此为远程用户提供 VPN 访问网络的权限。为了让客户更快访问数据，Zylker 决定开始使用云应用程序。它选择 Zoho One 管理其生产力套件，选择 Office 365 管理电子邮件。公司的部分资源（如文件服务器和数据库）仍在本地，因此仍须向远程用户授予访问权限。

为了实现此要求，IT 团队设置了混合 Azure Active Directory (AD) 环境。他们提供联合服务器以在基于云的 Azure AD 中复制其本地AD。现在，最终用户（甚至是远程用户）可以使用其 AD 凭证访问云资源了。

第1步：提交 RFC

第一步是提交变更单并收集有关变更的必要信息，如变更类型、变更影响和紧急性，并设置变更角色。变更发起人可以使用其 Web 门户轻松提交变更单，并选择相关的变更模板和变更类型。变更模板使用必填字段收集所有必要的信息。在这里，变更发起人将变更类型设置为“一般”，选择适当的变更模板，分配变更角色，并说明为什么需要变更。

第2步：计划变更

接下来，变更发起人添加变更信息，如变更原因、有关其影响的详细信息、推出和回退计划以及计划的停机时间。变更发起人还需添加所有相关的事件和问题，以更好地跟踪变更及其影响。以下是变更发起人提出的各种计划。

推出计划：

• 获得 Azure AD 和 Office 365 帐户
• 设置 Active Directory 联合身份验证服务 (ADFS)
• 在本地 AD 和 Azure AD 之间启动同步
• 配置单点登录
• 将本地 Exchange 与 Office 365 同步

回退计划：

由于现有配置是完整的，因此可以还原到旧配置并恢复服务。

计划的停机时间：12 小时

第3步：获得适当的批准

变更经理设置 CAB 来审查变更计划，并就是否需要实施变更或是否需要修改计划提出建议。由于这是一次大规模的变更，因此需要获得各个职能部门领导的批准。以下是参与审批过程的 CAB 和成员的列表：

1. 高管 CAB：
   • 首席信息官 (CIO)
   • 首席技术官 (CTO)
   • 财务总监 (CFO)
   • 首席执行官 (CEO)
2. 技术 CAB：
   • 服务交付经理
   • 营运经理
   • 信息安全经理
   • 数据保护官
3. 商务 CAB：
   • 商务主管
   • 人力资源经理
   • 商业关系经理

第4步：以正确的方式实施变更

Zylker 利用任务来跟踪实施。将任务分配给不同的技术人员，并使用任务相关性定义完成任务的顺序。变更负责人可以轻松跟踪变更实施的进度，并在一个位置管理所有任务。

以下是 Zylker 将实施分解为任务以便轻松跟踪和管理变更实施的细节：

• 准备 Office 365 和 Azure AD
• 设置引入服务器
• 发起数据迁移
• 配置 Azure AD 代理
• 检查数据完整性

第5步：遵循计划

接下来，由变更负责人/经理对变更实施进行审查，以检查是否与计划有任何偏差。报告并解决所有偏差后，变更才被视为成功。

第6步：关闭变更单

最后，关闭变更，并根据变更关闭的性质分配关闭代码。

第7步：检查指标

变更经理衡量某些 KPI，以确定变更流程的效率并发现可以改进的领域。

以下是选择服务台工具时需要注意的功能列表。具备这些功能将帮助您在组织中实施有效的变更管理流程。

变更管理

创建和记录变更

• 根据事件和问题创建变更，并保留必要的信息。
• 使用自定义变更模板收集所需的信息。
• 创建不同类型的变更，并为每种类型构建唯一的工作流程。
• 使用变更角色，让适当的相关方参与其中，如变更负责人、审批者、直属经理和变更审查者。

变更计划和评估

• 创建详细的变更计划，其中包含影响分析和推出、回退和停机时间计划。
• 保留要完成的基本步骤的清单。

变更审批

• 组建多个 CAB。
• 配置各个级别的审批。标记 RFC 必须由 CAB 的所有成员批准还是由任何一个成员批准。
• 允许变更经理对变更的审批拥有最终决定权。
• 当所有 CAB 成员都推荐变更时，可以通过自动批准变更，来绕过变更经理和变更审批者的审批。
• 将最终用户标记为服务请求审批者。

协调变更实施

• 将变更分解为任务，并使用工作日志来估计变更实施团队完成活动将花费的时间。
• 通过基于变更创建项目，或将变更与现有项目相关联来简化实施。
• 跟踪引起变更或由变更引起的所有相关事件和问题。
• 提前计划停机时间并告知主要相关方。
• 通过定期通知，让相关方始终了解最新进展。

变更审查和关闭

• 记录实施后审查 (PIR)。

变更工作流程

• 为具有不同级别的复杂性和功能的不同变更类型和流程创建独特的工作流程。
• 在阶段过渡期间配置各种操作，如条件、切换、通知、字段更新和审批。
• 在拖放型页面上草拟变更工作流程。

变更：

添加、修改或删除可能对服务产生直接或间接影响的任何内容。

变更顾问委员会 (CAB)：

一个由不同相关方组成的团队，他们提出有关变更的建议并审批变更计划。

变更冲突：

无意中计划同时实施两个或多个变更，从而扰乱了任一变更的实施。

变更管理：

以最少的中断和冲突完成变更的过程。

变更角色：

将变更的各个方面的责任委派给组织的不同成员。

关闭代码：

用于记录变更关闭的性质，如失败或成功。

配置管理数据库 (CMDB)：

所有配置项及其关系的存储库。

持续服务改进：

发现并修复可以改善的领域，有助于提供更好的服务。

停机时间：

特定服务不可用的时间段。

事件：

IT 服务的计划外中断或 IT 服务质量的降低。配置项发生故障，即使尚未影响服务，也被视为事件（例如，镜像集中的一个磁盘发生故障）。

问题：

一个或多个事件的原因或潜在原因。

实施后审查：

评估是否遵循了变更计划且不存在偏差，以及检查实施以查看是否需要进行更改的过程。

请求变更 (RFC)：

使用有效原因发起变更的过程。

风险评估：

评估与变更相关的潜在风险的过程。

服务台：

服务提供商与组织用户之间的沟通点。