IT®变更管理的综合指南

商业环境和客户期望在不断变化，数字化转型已成为各行各业企业成功的关键因素。数字化转型就是利用现有技术来应对业务挑战并抓住机遇。当您分解它时，数字化转型基本上是 IT 管理做得更好，以消除有问题的领域并使您的 IT 基础架构能够应对业务挑战。这涉及实施 IT 变更，以帮助您的组织将新技术应用于现有业务和 IT 流程。

这些变化可以很简单，例如将协作应用迁移到云以提高运营效率，或者采用移动优先方法以获得更好的消费者体验。尽管表面上很简单，但这些变化带来了自身的后勤挑战。未正确实施更改可能会导致您的组织向前迈出一步，后退两步。

2018年12月，一家广受欢迎的银行的移动应用程序升级失败，这是一个很好的例子，说明了如何不实施变更。该银行计划推出一款新的、经过改进的手机银行应用程序，这是一个好主意，也是一个迫切需要的主意。但从这款新应用发布的那一刻起，它就出现问题了。该银行在旧的应用程序后，推出了新的应用程序。当新应用程序无法工作时，成千上万的客户无法通过该应用程序访问他们的银行账户。更糟糕的是，关于新应用程序修复的沟通很少，这让客户感到沮丧。在银行决定恢复原来的应用程序之前，该移动应用程序宕机了四天。

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

这就是变更管理的用武之地;它帮助您管理组织中的所有不同变更，并为您提供了一个在不影响组织其他部分的情况下高效地推出变更的流程。变更管理减少了类似于银行所面临的中断的机会。

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

让我们开始吧！

什么是变更管理？

IT将变更管理描述为在整个生命周期(从开始到结束)中跟踪和管理变更的过程，目的是最小化风险。

建立一个系统的变更管理过程可以帮助您的组织实现高成功率的无事件变更。

什么是变更？

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

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

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

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

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

IT改变管理目标

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

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

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

通过跟踪整个变更过程，变更管理使得组织能够控制所有变更请求。它还可以更容易地识别和控制未授权变更的数量。通过允许用户仅通过服务台工具提交变更请求(RFC)，组织可以在开始时收集关于变更的所有必要信息，然后决定是否需要实现变更。健壮的批准机制确保变更在实现之前获得所有必要的权限。

持续改进：

变更管理不仅仅是未雨绸缪;它的目的是帮助组织不断地改进他们的基础设施和流程，并通过确保他们能够顺利地推出必要的变更而不影响当前的服务操作，从而跟上行业趋势。

变更管理的好处

组织：

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

最终用户：

• 更好地沟通由于计划变更而导致的停机和服务不可用。
• 更流畅的服务操作，较少由于计划不佳的变更而导致的中断。

组织如何进行变更管理？

现在让我们看看如何在您的组织中实现变更管理。第一件事是建立一个有效的变更过程，使您能够计划变更，获得必要的批准，并实现变更。下面是一个您可以遵循的变更管理流程，以有效地处理变更。

变更管理过程

第一步：提交

第一阶段是开始改变。这涉及到收集基本的变更工单信息，比如变更类型和优先级。

• 产物：使用服务台工具启动变更工单。使用包含强制字段的变更表单在开始时收集必要的信息。
• 定义改变角色：通过使用变更角色，组织可以将变更责任委托给各种涉众，并控制每个角色在变更的每个阶段的访问级别。

第二步：规划

下一个阶段是对整个变更的计划。计划良好的变更是成功实现变更的秘密。获得执行变更所需的必要批准也是非常重要的。详细信息如影响、推出计划、取消计划和相关的停机时间都被记录下来，以清楚地向涉众传达变更计划，并说服他们变更是值得做的。

第三步：批准

接下来，变更计划需要得到变更咨询委员会(CAB)、紧急变更咨询委员会(ECAB)以及在变更或受变更影响的组织基础设施中有利害关系的任何其他权威的批准。创建自定义CABs有助于组织组织相关人员轻松管理审批。自动化审批流程加速了整个变更，并确保没有忽略任何审批请求。

注意：CAB是各种工作角色和团队的组合。它可能包括c级管理人员、团队经理、技术团队、财务人员等等，这取决于变更的严重程度和规模。

第四步：实现

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

• 通过任务分配工作： 任务被创建并分配给来自不同团队的不同技术人员，以轻松地管理所有参与变更实现的人员所完成的工作。可以使用父任务和子任务来设置任务依赖关系，并确保任务按照特定的顺序完成，不会遗漏任何任务。
• 利用项目管理： 组织可以使用项目来处理大规模变更，比如将组织的整个基础设施迁移到云。项目支持更大范围的实现，可以更好地处理更多的任务、人员和里程碑。变更管理和项目管理之间的强集成对组织非常有益。

第五步：评估

然后，进行实施后的审查，以确保在实施中没有任何偏差，并且在变更结束之前解决任何问题。

第六步：关闭

这是变更管理过程中的最后一步。完成的变更的性质被记录为成功、失败或不完整。记录正确的闭包代码可以使组织的度量更加准确和有用。

并不是所有的变更都是相同的，因为有些有不同的需求。有些变更需要尽快实施，有些则需要得到组织高层的批准，而有些则只是每周实施一次的常规变更。

根据ITSM，变更可以大致分为三种类型:标准变更、正常变更和紧急变更。

标准的变更：

这些是预先批准的变更，影响较小，众所周知，并且有文档记录。第一次实现标准变更时，需要进行风险评估和授权，但是只要没有修改变更，后续的实现可以在没有这些预防措施的情况下完成。
例如：更换打印机的墨盒

正常的变更：

一个正常的变更需要遵循整个变更过程;它应该被安排，进行风险评估，并得到授权。正常的变更包括小的(低到中等的影响和紧迫性)和大的变更(高的影响和紧迫性)。所有不是标准的或紧急的变更都应该作为正常的变更处理，并遵循变更过程。
示例：将本地服务迁移到云

紧急变更：

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

变更持有者

变更所有者负责整个变更管理过程，包括其改进。因为他们负责组织的变更管理，所以他们通常是高级官员。

变更经理：

变更经理处理变更的实施以及与之相关的活动。他们还管理 CAB 以及所涉及的各个团队和利益相关者，并与他们协调。

任何发起变更的人员：

变更发起者是发起变更并添加变更计划、实现计划和其他所需细节的人。他们还组织实施变更计划。变更发起者可以是技术人员，也可以是最终用户。

变更顾问委员会：

CAB是来自不同团队和工作职能的不同成员的集合。他们一起分析提议的变更，并就变更及其实施给出他们的批准和建议。

额外的角色

一些组织除了这四个主要角色外，还使用自定义角色来委派工作和分解职责。能够创建自定义角色可以帮助您根据组织的需要调整变更管理。以下是一些常用的附加角色：

• 变更批准人
• 变更实施人员
• 变更回顾人员
• 变更计划

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

1. 失败的变更：

   变更会占用相当多的资源，因为计划变更需要大量的时间和研究。如果不进行检查，大量失败的变更会很快变得代价高昂。在基础设施变更的情况下，高失败率可能会在执行期间或执行回退计划时导致更大的问题。许多失败的变更也是不良变更管理过程的指示器。

   例如：Zylker计划升级其主要网络基础设施，因此公司与第三方网络供应商建立了一个备用网络;它计划在周末实施这一改变。在实施过程中，Zylker收到了关于服务关闭的罚单，考虑到该公司已经建立了一个备用网络，这是令人惊讶的。事实证明，备用网络提供商也在那个周末执行预定的维护，这意味着Zylker的主网络和备用网络都关闭了，导致Zylker的服务不可用。由于没有正确地计划变更，它最终失败了。

2. 未经授权的改变：

   未经授权的变更是由于缺乏适当的批准机制和未能在批准阶段包括正确的涉众所导致的。这些变更绕过了必要的权限，如果没有及时标记，就可能无法实现。未经授权的变更可能导致组织不需要或尚未准备好实现的变更。底线是，未经授权的变更是不好的，是不必要的开销。

3. 紧急变更太多：

   如前所述，紧急变更需要快速批准，以便尽快实施。将太多的变更视为紧急变更可能会导致在需要执行的严重紧急变更发生时出现延迟。在将变更归类为紧急变更时，保持谨慎总是好的。

   注：关于那个喊狼来了的男孩的流行故事是一个很好的类比，说明为什么把太多的变更当作紧急变更会适得其反。在发生实际的紧急情况时，您的组织可能不会以其要求的严重性接受变更，并且您可能没有处理紧急情况所需的资源。

4. 改变碰撞：

   糟糕的计划可能导致变更冲突。变更冲突是指两个或多个变更被意外地计划同时实现，从而中断了其中一个变更的实现。利用变更日历来更好地计划您的变更可以帮助防止变更冲突。

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

1. 确定变更的类型：

   并不是所有的改变都是一样的。变更有不同的优先级和不同的需求，正如在变更类型部分中所解释的那样。 因此，首先确定您的组织可能执行的变更类型，然后创建不同的变更类型以有效地将它们推出，这一点非常重要。

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

   由于不同的变更类型有它们自己独特的需求，您需要设计独特的过程来满足这些需求。对所有变更类型使用相同的变更过程只会导致不必要的延迟和不完整的变更实现。

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

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

   定义角色允许变更管理人员将活动和职责委派给其他人。角色使管理变更更容易，并且它们清楚地定义了每个人可以执行的活动。

4. 记录、管理和确定变更建议的优先级：

   最好的做法是用一种有组织的方式记录您的变更，以及在一个地方管理和优先化它们。有了对组织变更的更好的可见性，您就可以优先考虑哪些变更需要在其他人之前执行。

5. 对变更的风险和影响有清晰的认识：

   所有的变更都需要经过风险和影响分析，以更好地理解变更并分配必要的资源。风险和影响细节应在计划阶段添加，以便驾驶室对变更有一个清晰的了解，并能给出他们的建议。

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

   定义批准过程可以轻松地获得实现变更所需的权限。它确保所有关键的涉众都知道变更，并在变更实现之前给出他们的建议。这有助于遏制未经授权的变更。

7. 与利益相关者沟通时间表和停机时间：

   让涉众了解计划中的变更可以减少由变更引起的事件数量。提供及时的信息还可以确保服务不会因为变更而受到影响，并且变更可以有效地执行。作为奖励，当管理层在整个变更生命周期中得到通知时，他们也会更高兴。

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

   在整个变更生命周期中关注变更，确保没有出错，并且变更是根据变更计划实现的。度量关键指标可以让您清楚地了解变更过程的效率，还可以让您确定可以改进的领域。

9. 制定应急计划：

   您永远不能准备得太充分，所以最好是为最坏的情况做好准备，并在变更计划阶段制定一个退出计划。这种深入的计划可能意味着普通的失败变更和对您的IT基础设施的不可逆转的破坏之间的差别。

10. 持续改善服务：

    尽管救火是变更管理的一个重要功能，但是变更在您的组织中具有更广泛的范围。使用变更来改进技术和流程，从而不断增强组织提供更好服务的能力，这正在成为变更管理的一个重要功能。

变更管理不仅仅是完成一个变更。变更管理有效地展开变更的能力可以从其他ITSM过程中收集的信息中获益，反之亦然。将事件与它们引起的或由它们引起的变更关联起来，或者基于IT基础设施变更更新CMDB的能力，只是创建一个健康的ITSM实践的开始，这种实践可以协同工作，帮助更好地管理您的组织。

以下是变更管理如何与您的其他ITSM流程协同工作：

1. 事故管理：

   跟踪引起变更的事件和由变更引起的事件可以让您更好地理解变更是如何影响您的组织的。例如，当一个路由器被更新时，您可能会收到报告internet宕机的意外罚单。将变更与它们所引起的事件关联起来，可以帮助您快速识别事件的原因，并避免必须分配资源来修复特定的事件，因为一旦完成了变更，就会修复该事件。

2. 请求履行：

   对于影响很大的服务请求，使用变更来保持It基础设施的更新非常重要。如果不进行变更，对服务器升级的服务请求或对Azure存储空间升级的请求将以交付服务结束。但是，当您使用变更来实现服务请求时，您可以收集更多的信息，比如变更的原因和实现计划，从所有涉众获得必要的批准，并使用新的信息更新CMDB。

   注意：在请求实现中使用变更对于高影响的服务请求和任何需要对CMDB进行变更的服务请求最有效。如果它需要更新CMDB，那么它就需要变更！

3. 问题管理：

   问题管理需要创建一个变更来修复问题的根源。能够从问题工单中直接创建RFC使跟踪相关的变更和问题变得很容易。它还让CAB更好地了解为什么需要进行变更，并指示发起变更的问题的严重性。

4. 发布和部署管理：

   发布和部署升级受益于变更过程带来的结构化方法。您可以使用变更轻松地跟踪实现计划、推出计划以及发布和部署的实际实现。透明性和可见性的变更也有助于保持所有涉众的知情。

5. 配置管理数据库：

   对CMDB的任何更新都应该通过变更来完成。变更提供了关于为什么、如何以及何时进行更新的许多有用信息。与变更一起执行的影响分析还确保对CMDB的任何更新都得到了正确的分析，并且该更新不会对组织的其他部分造成任何破坏。您可以使用变更类型 记录不同优先级的CMDB更新。

变更管理KPI

这里有一些重要的度量标准来度量变更管理过程的有效性。

让我们详细了解一下变更，以了解如何改进变更管理流程。

拥有大量远程用户的Zylker公司决定走云计算路线。

目前，该公司所有的生产力应用程序和资源都是内部的，因此远程用户可以通过VPN访问网络。为了提供更快的数据访问，Zylker决定开始使用云应用程序。它选择Zoho One作为其生产力套件，选择Office 365作为电子邮件套件。该公司的部分资源，如文件服务器和数据库，仍在本地，因此远程用户也必须有权访问这些资源。

为了实现这个需求，IT团队设置了一个混合的Azure Active Directory (AD)环境。他们提供一个联合服务器来在基于云的Azure广告中复制他们的本地广告。现在终端用户，甚至远程用户，都可以使用他们的AD凭证访问云资源。

第一步：提高RFC

第一步是提出一个变更单，并收集关于变更的必要信息，如变更类型、变更影响和紧迫性，并设置变更角色。变更发起者可以使用他们的web门户轻松地发起变更工单，并选择相关的变更模板和变更类型。变更模板使用必填字段收集所有必要的信息。在这里，变更发起者将变更类型设置为正常，选择适当的变更模板，分配变更角色，并给出为什么需要变更的描述。

第二步：计划改变

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

发行计划：

• 获得Azure AD和Office 365帐户
• 设置活动目录联合服务(ADFS)
• 启动prem AD和Azure AD之间的同步
• 单点登录配置
• 与office365同步现场交换

撤销计划：

因为现有的配置是完整的，所以恢复到旧的配置并恢复服务。

Planned downtime: 12 hours

第三步：获得正确的批准

变更经理设置cab来审查变更计划，并就是否需要实施变更或是否需要修改计划给出他们的建议。由于这是一个大范围的变更，需要来自跨越各种功能的不同工作角色的批准。以下是参与审批过程的出租车和会员名单：

1. Executive CAB:
   • 首席信息官(CIO)
   • 首席技术官(CTO)
   • 首席财务官(CFO)
   • 首席执行官(CEO)
2. 技术的变更顾问委员会：
   • 服务交付经理
   • 运营经理
   • 信息安全经理
   • 数据保护官员
3. 商业的变更顾问委员会：
   • 工商管理经理
   • 人力资源经理
   • 业务关系管理

第四步：以正确的方式实施改变

Zylker利用任务来跟踪实现。任务被分配给不同的技术人员，需要完成任务的顺序是使用任务依赖项定义的。变更所有者可以轻松地跟踪变更实现的进度，并在一个地方管理所有任务。

以下是Zylker如何将实现分解为任务，以方便跟踪和管理变更的实现：

• 准备Office 365和Azure AD
• 设置一个摄取服务器
• 启动数据迁移
• 配置Azure AD代理
• 检查数据完整性

第五步：坚持计划

接下来，变更所有者/经理将检查变更实现，以检查计划中的任何偏差。在变更被认为是成功之前，任何偏差都会被报告和修正。

第六步：关闭变更工单

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

第七步：收集指标

变更管理人员度量某些KPI，以确定变更过程的效率，并确定可以改进的领域。

以下是选择服务台工具时需要注意的一些特性。具备这些特性将帮助您在组织中实现有效的变更管理过程。

变更管理

变更创建和日志记录

• 从事件和问题中产生变更，并传递必要的信息。
• 使用自定义变更模板收集所需信息。
• 创建不同类型的变更，并为每种类型构建惟一的工作流。
• 让正确的涉众参与进来，比如变更所有者、审批人、直线经理和变更审阅人，使用变更角色。

变更计划和评估

• 创建详细的变更计划，包括影响分析和推出、取消和停机计划。
• 保持一个要完成的重要步骤的清单。

变更批准

• 形成多个变更顾问委员会
• 配置多级审批。请注明是否须经驾驶室全体成员或任何一名成员批准。
• 允许变更经理对变更的批准有最终的发言权。
• 绕过变更管理器的批准，并在所有CAB成员推荐变更时自动批准变更。
• 将最终用户标记为服务请求批准人。

协调变更实现

• 将变更分解为任务，并使用工作日志来估计变更实现团队完成活动所需的时间。
• 通过从变更创建项目或将变更与现有项目关联来简化实现。
• 跟踪所有由变更引起的相关事件和问题。
• 计划停机时间，并向主要涉众宣布。
• 通过定期通知让涉众了解情况。

变更评审和关闭

• 文件实施后审查(PIR)。

改变工作流程

• 为具有不同复杂性和功能级别的不同变更类型和流程创建不同的工作流。
• 在阶段之间的转换期间配置各种操作，如条件、开关、通知、字段更新和批准。
• 在拖放画布上绘制变更工作流。

变更：

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

改变顾问委员会(CAB)：

一个由不同的涉众组成的团队，他们给出关于变更的建议并批准变更计划。

改变碰撞：

当两个或多个变更被意外地计划同时实现时，会中断其中一个变更的实现。

变更管理：

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

变更角色：

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

关闭代码：

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

配置管理数据库(CMDB)：

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

持续的服务改进：

确定和修复可以改进以使服务更好的领域的过程。

停工期：

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

事件：

对IT服务的意外中断，或IT服务质量的降低。配置项的失败，即使它还没有影响到服务，也是一个事件(例如，来自镜像集的一个磁盘的失败)。

问题：

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

实现后复查：

评估变更计划是否执行得没有偏差的过程，以及检查执行情况以确定是否有需要变更的地方。

请求改变(RFC)：

用正当理由发起变更的过程。

风险估计：

评估变更所涉及的潜在风险的过程。

服务台：

服务提供者和组织用户之间的通信点。