主页.『慕斯娱乐』.主页配置管理（Management， CM）的目的，在使用配置识别、配置控制、配置状态记录及配置审计，来达到建立与维护工作产品的完整性。配置管理提供了结构化的，有序化的，产品化的管理软件工程的方法。它涵盖了软件生命周期的所有领域并影响所有数据和过程。配置管理是指用于控制系统一系列变化的学科。通过一系列技术，方法和手段来维护产品的历史，标识和定位产品独有的版本，并在产品的开发和发布阶段控制变化。通过有序管理和减少重复性工作，配置管理保证了生产的质量和效率。可以说不懂软件项目的配置管理，就不懂软件开发管理，不对软件项目进行配置管理，就没有进行软件项目开发管理。

　　IEEE中的定义：识别产品的结构、产品的构件及其类型，为其分配唯一的标识符，并以某种形式提供对它们的存取。 可以理解为：标识软件系统的结构，标识独立部件（工作产品），并使它们是可访问的。配置标识的目的，是在整个生命周期中标识系统各部件并提供对软件过程及其软件产品的跟踪能力。即：怎么命名？版本如何设置？放到哪里？哪些是受控的？受控的级别是什么？读写的权限是什么？

　　IEEE中的定义：通过建立产品基线，控制软件产品的发布和在整个软件生命周期中对软件产品的修改。 可以理解为：软件生命周期中控制软件产品的发布和变更，目的是建立确保软件产品质量的机制。即怎么变更？谁控制变更？谁来分析变更的影响范围？变更后如何验证、入库以及恢复？

　　IEEE中的定义：记录并报告构件和修改请求的状态，并收集关于产品构件的重要统计信息。 可以理解为：记录和报告变更过程，目标是不间断记录所有基线项的状态和历史，并进行维护。每次基线的生成和变更都能让相关者知道变了什么？为什么变？变化前后的状态是什么？

　　IEEE中的定义：确认产品的完整性并维护构件间的一致性，即确保产品是一个严格定义的构件集合。 可以理解为：验证软件产品的构造是否符合需求、标准、或合同的要求，目的是根据配置管理的过程和程序，验证所有的软件产品已经产生并有正确标识和描述，所有阶段的工作产品都一致并满足系统的需求，并且所有的变更需求都已解决。

　　《配置管理计划》一般是《项目综合管理计划》的子计划。在项目策划的时候我们就要制定这个计划。

　　a）配置管理员：识别和标识配置项，建立和维护配置库；配置库管理；执行配置审计

　　b）配置控制委员会（CCB）：批准基线库的生成；评估和审核变更请求，并确保批准的更改得到实施.

　　对于配置项，可以给出一个比较简单的定义，即软件过程的输出信息可以分为4个主要类别：

　　IEEE中基线的定义是这样的：已经正式通过审核批准的某规约或产品，它因此可作为进一步开发的基础，并且只能通过正式的变化控制过程改变。

　　b）受控项：受控项是指不需要进行基线控制但变更后需要得到相关人员确认或通知到相关人员的配置项。

　　在配置库中，配置项都应该有一个合适的目录去存放和分类。放入之特定目录下的配置项也必须严格按照“文件命名规则”来命名，并且这些配置项要按照“版本设置规则”来标识版本。在配置库中各种配置项的操作权限都应严格管理。我们一般是通过目录的访问权限来控制的，所以配置库的目录结构与配置项的访问权限也有着密切的关系，配置项的权限设置的原则如下：

　　b）受控配置项：PM、CCB读写权限，项目组全员或相关人员开放读的权限。

　　c）数据配置项：PM、CCB、配置项的责任人或开发小组开放读写权限，项目组全员开放读的权限。

　　在配置管理中基线发布是一个重要活动，基线发布的时间点一般就是项目里程碑时间点。通常会有下列基线：需求基线、设计基线、代码基线、交付基线等。 在计划中我们要依据《项目综合管理计划》的里程碑时间点，结合项目管理的需要，设定项目的基线计划。即项目过程中发布哪些基线，这些基线发布的时间点，发布的责任人。 同时我们也要明确定义基线的版本规则，因为基线也是在不断变更的。

　　c）产品交付前必须要进行配置审计。 我们在计划中要规划好配置审计的概要时间。这样有利于配置审计的及时开展。

　　定义各类配置项如库、出库的准则和操作流程。 定义基线变更的准则和操作流程。 明确配置库的备份及维护的方法，当出现异常后如何恢复的预案等。 版本发布的准则、发布流程及发布计划，如测试版本、β版本、Release版本等。

　　配置状态报告是一个配置管理中一个很重要的活动，多个开发组保持开发一致的重要活动。我们的配置状态报告的主要对象是基线库。 配置状态报告要报告的内容有：基线库的基线项的清单、基线项的名称、版本、存放位置。 在每次基线变更后，状态报告还要能说明。哪些基线项变了、为什么变、变化前的版本是什么、变化后的版本是什么。

　　一般项目管理中，基线变更的控制权限是CCB（配置变更委员会）。基线变更控制一般是由两种变更方式，需求变更、内部变更。下图是基线变更的流程。

　　在CMMI模型中明确将配置审计分为物理审计和功能审计，在定义中与IEEE是没有冲突的。

　　a）物理审计：验证已构建出的配置项符合定义和描述它的技术文档的审计行为。

　　b）功能审计：验证配置项的开发已经被完全满足的审计行为，即验证配置项已经达到了在功能或已分配的配置标识中刻画的性能和功能特性，并且其运行和支持文档是完整的和满意的。配置审计的范围：物理审计的范围是受控项和基线项，功能审计的范围是基线项。 功能审计是验收的前提条件，不同的角色所做的功能审计侧重点不同。 配置审计的步骤：

　　a）准备《配置审计检查单》，这个检查单包含所有受控项和基线项的状态，受控项清单包含受控项的命名、控制级别、存放位置、当前版本、控制权限等状态信息。基线项的状态就是最新的《配置状态报告》中配置项的状态。b）依据配置审计的计划时间去执行配置审计。

　　c）根据《配置审计检查单》对配置库进行物理审计。责任人：CM发起并参与、CCB。

　　d）根据《配置审计检查单》对配置库进行功能审计。责任人：CM发起并参与、需求人员、CCB（PM、及各Leader）及相关人员。

　　f）每次配置审计要将审计结果记录到《配置审计报告》中，记录和跟踪配置审计检查出的问题。

　　根据《配置审计检查单》去检查，该有的配置项是否都有了？文件命名与计划中的命名规则是否一致？存放位置与计划是否一致？版本设置与计划中的版本设置规则是否一致？控制权限是正确？功能审计的方法：

　　a）检查与需求的一致性、完整性：根据《需求追踪矩阵》对配置库的基线项进行检查，看看所有需求是否都已经不多不少地被实现了？并纳入了基线库？如果物理审计中基线项的审计没有问题，我们也可以通过《需求追踪矩阵》对《配置状态报告》中基线项进行检查，看看所有需求是否都已经不多不少地被实现了？

　　b）验证工作产品与需求的符合程度：查看所有基线项评审和测试报告，看看所有的基线项是否都已经通过各级评审及测试？

　　c）交付给客户的文档与软件的功能一致性：检查交付客户的文档是否与当前最新的基线、配置管理活动的QA审查

　　a）检查配置管理的各种记录、报告等与配置库中的物理的配置项实体是否一致、完整、准确

　　配置管理系统项目管理系统的一个子系统。它由一系列正式的书面程序组成，该系统包括文件和跟踪系统，并明确了为核准和控制变更所需的批准层次。

　　配置管理系统是PMIS系统的子系统。该系统识别可交付成果状态、指导记录变更。在项目管理中，其功能是作为整体变更控制过程的一部分体现的。

　　建立一种先进的方法，以便规范地识别和提出对既定基准的变更，并评估变更的价值和有效性；

　　建立一种机制，以便项目管理团队规范地向有关干系人沟通变更的批准和否决情况。

　　注意：分清哪个是目的，哪个是手段。配置管理目的与手段的区分是一个常考点，也易错。

　　配置识别。选择与识别配置项，从而为定义与核实产品配置、标志产品和文件、管理变更和明确责任提供基础。（相当于一个命名的规划过程）配置状态记录。包括已批准的配置识别清单、配置变更请求的状态和已批准的变更的实施状态。（相当于执行过程）配置核实与审计。确保配置文件所规定的功能要求都已实现。（相当于监控过程）

　　通常作为配置管理系统的一个子系统。整体变更控制通过变更控制系统来完成。一系列正式的书面程序，包括文档、跟踪系统和批准层次。任何变更请求都必须是正式提出的。该系统主要关注绩效测量基准的变更，如范围、进度、成本等。

　　配置管理系统的对象：要么是可交付成果，要么是各个过程的技术规范。配置管理重点关注技术规范。

　　变更控制系统的管理对象：项目及产品基准（变更）。可以是产品的特性与性能（即产品范围），可以是为实现这些特性与功能的各种具体的项目工作（即项目范围）。变更控制系统重点关注基准的变更。

　　信息技术基础设施库(ITIL)是世界上被广泛接受的IT服务管理 IT service management(ITSM)方法。ITIL提供了一套具有凝聚力的最佳实践，从国际上的公共和私营部门汲取。一组IT服务管理的最佳实践出版物ITIL为提供高质量的IT服务以及支持这些服务所需的过程、功能和其他能力提供了指导。核心组合由五个手册组成，每一个都是服务生命周期的关键阶段/阶段:（1）服务策略（2）服务设计（3）服务转换（4）服务操作（5）持续的服务改进一、变更管理过程所有者Change Management Process Owner全面负责确保变更管理过程对组织的适宜性 suitability。责任：（1）通过确保变更经理Change Manager拥有足够的资源来设计符合最佳实践和满足组织需求的变更管理过程，从而支持过程。（2）解决关于责任分配的争议，并赞助 sponsor沟通活动，以促进对变更管理过程的认识和接受。（3）提供描述、任务陈述、路线图、战略、过程目标和度量成功的标准，并获得过程及其相关程序的正式批准。（4）在高层监视和审查过程的执行，确保它与组织当前的文化和itsm战略保持一致，并确保与所有其他itsm和it基础设施管理过程的协调。（5）必须理解和管理ITSM过程之间的集成。（6）参与IT治理活动。

　　负责变更管理过程的执行execution。这包括操作定义好的和商定的过程，确保它与所有其他相关过程的接口，设定目标并审查过程的有效性和效率，执行过程审计和管理过程改进周期。责任：（1）管理和协调所有必要的活动，以控制、跟踪和审核环境变化。（2）领导变更管理功能，对所指派员工的技能水平和表现负责。（3）确保变更的状态，进展和问题与适当的团队沟通。（4）审核和管理过程生命周期，并向上级管理层报告（5）必要时安排紧急CAB/XCAB会议（6）根据定义的关键成功因素评估绩效指标，并制定行动纠正缺点或进一步简化过程（7）负责审核变更计划(CS)的冲突（9）在CAB中任职（10）向上级管理层报告变更管理活动。（11）生产管理报告（12）负责变更管理过程的教育

　　负责变更的整体计划、启动和执行，从而为变更分配工作。责任：（1）收集变更相关信息（2）创建变更请求（3）评估、评价并设置变更的风险（4）创建变更实施计划（5）提出变更时间表（6）确定实现变更的资源，在某些情况下实现变更本身（7）沟通变更状态和结果（8）必要时参加CAB/XCAB会议（9）为持续维护和改进变更管理过程向变更经理提供输入

　　负责执行变更提交人 Change Submitter提交的变更。责任：（1）必要时向变更提交人 Change Submitter提供变更相关信息（2）审核变更请求的技术准确性和可行性（3）必要时参加CAB/XCAB会议（4）执行变更请求中记录的与变更相关的活动，确保变更按照计划实施（5）在变更记录中记录收尾活动并完成变更记录（6）将任何偏离计划的情况上报给相应的管理层(直接经理和变更经理)(direct manager and change manager)（7）为持续维护和改进变更管理过程向变更经理提供输入

　　对变更提交人提交的变更负责。责任：变更请求的初步批准审核变更请求的技术准确性和可行性必要时参加CAB/XCAB会议为持续维护和改进变更管理过程向变更经理提供输入

　　一个为了批准变更和协助变更的日程安排和评估而召开会议的小组。应该选择能够确保业务和技术观点都得到考虑的成员。责任：（1）确保同时考虑业务和技术观点（2）评审变更记录的完整性和准确性（3）确保适当地考虑客户和供应商的观点（4）为持续维护和改进变更管理过程向变更经理提供输入

　　一个为批准高风险变更和协助变更的优先次序和评估而召集的小组。应该选择能够确保业务和技术观点都得到考虑的成员。责任：（1）参加XCAB walkthrough1级风险变更（2）确保同时考虑业务和技术观点（3）评审变更记录的完整性和准确性（4）确保适当地考虑客户和供应商的观点来源：

　　bmc.com/blogs/asset-management-vs-configuration-management/发布管理与变更和配置管理紧密结合。人们需要清楚地了解这三者之间的关系，这样才能了解整体情况。一、什么是发布管理?发布管理是一个软件管理过程，它指导从代码开发到测试再到生产的技术工作，专注于协调各种产品的可交付件，这些可交付件必须作为一个集成的解决方案和结果一起工作，从而有效地交付业务所需的新的和增强的IT服务/功能，同时保护现有服务的完整性。二、什么是变更管理?变更管理是一个用于管理对配置管理数据库(或CMDB中的“CIs”)中所有配置项进行变更的计划部署的过程，这些配置项是业务的活动(“生产”)环境的一部分。变更管理的目标是确保采用标准化的方法和程序，以有效和迅速地处理所有变更，以控制IT基础设施，以尽量减少任何相关事件对服务的数量和影响。三、什么是配置管理?配置管理(CM)是一种由标准过程和技术组成的软件工程规程，组织经常使用这些标准过程和技术来管理引入到其软件产品中的变更。配置管理有助于识别单个元素和配置，跟踪变更，以及版本选择、控制和基线。它精确地回答了配置管理数据库(或CMDB中的“CIs”)中所有配置项configuration items的谁、什么、什么时候和为什么。四、这些学科是如何相互关联的?变更管理Change management 提供授权和跟踪机制(变更请求(RFC)、变更日志和评审)，以确保只部署已批准的变更。配置管理Configuration management 为变更日志、rfc、权威软件库(DSL)、权威硬件存储(DHS)、发布包和所有CIs提供了一个托管数据库(CMDB)。发布管理Release management为部署到生产中的所有变更提供了一个打包的发布。这种相互依存关系可以清楚地理解为:1、变更管理（1）需要配置管理来评估变更对所有潜在CI的影响。（2）需要发布管理来打包变更，以便在对生产造成最小干扰的情况下成功部署。２、配置管理（１）需要变更管理，以确保只部署已批准的变更，并完成对授权过程的所有跟踪。（２）需要发布管理来在部署后使用发布包更新CMDB。３、发布管理（１）需要变更管理来批准变更，并在整个发布过程中跟踪变更。（２）需要配置管理来评估变更对ci的影响，并为发布包提供一个确定的存储。变更管理角色和职责来源：greycampus.com/blog/it-service-management/itil-change-management-roles-and-responsibilities

　　变更经理作为一个促进者，负责整个变更管理过程。他的主要职责是：（1）授权和批准小的/低 minor/low的变更；（2）与变更顾问委员会(CAB)协调并组织会议，讨论高风险变更；（3）实施或拒绝变更的权力；（4）确保所有为实施变更而设计的活动都符合标准。政策和程序应得到很好的定义、承认和审查；（5）准备变更摘要表，总结所有RFC的变更。此表帮助CAB团队理解和评估所提议的变更。

　　它是一组个人，作为一个顾问委员会的变化被分类为主要或重要的。CAB，与变更经理一起负责最终评审;他们有权重新评估风险级别或影响级别。他们可以在批准变更前要求提供额外的信息，也可以根据需要拒绝变更。

　　Change Requestor or Change Initiator提出改变或要求改变的人。变更请求者需要为变更提供所有必要的信息和理由。除此之外，他的其他职责还包括组织和计划变更活动。（1）向变更的所有者提供必要的信息（2）参加CAB会议并提供必要的信息（3）评审和记录变更计划（4）解决与变更相关的问题（5）使用变更活动更新用户（6）支持并参与变更实施前后的测试活动

　　变更的所有者——如果变更请求者是其他人。他的职责包括:（1）就业务和技术问题与变更请求者保持联系（2）创建一个RFC(变更请求)，并在需要时更新它的状态。检查并确定实现日期，确保它不会与其他活动冲突（3）评估和管理相关的风险（4）测试并实现变更（5）在提交变更之前，与其他受影响的团队进行协调和沟通（6）一旦变更被批准，为计划的变更创建一个补救案例。按照预定的日期和时间执行更改。更新补救案例（7）成功完成后提供关闭状态（8）变更程序实施后的文件记录

　　在RFC进入CAB评审之前，向RFC提供第一级批准的经理。他的职责包括:（1）审查变更受让人提交的所有RFC（2）确保所有必要的沟通;文件编制和测试在批准之前完成（3）请求技术同行进行评审，以确保所有技术步骤都是正确的（4）批准或拒绝RFC（5）变更是通过变更管理系统来维护和控制的，这是一种用来跟踪和记录与拟议变更相关的所有活动(初始化、批准、更新、关闭)的工具。

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

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

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

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

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

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

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

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

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

　　创建问题单以执行根本原因分析 (RCA)。网络交换机发生故障，导致此事件。该交换机需要更换。

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

　　： 使用服务台工具发起变更单。使用包含必填字段的变更表，从一开始就收集必要的信息。

　　: 通过使用变更角色，组织可以将变更责任委派给各个相关方，并控制每个角色在变更的每个阶段所具有的访问级别。

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

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

　　: 创建任务并将其分配给来自不同团队的不同技术人员，以轻松管理所有实施变更的人员所完成的工作。父任务和子任务可用于设置任务依赖性，并确保任务以特定顺序完成，且不会遗漏任何任务。

　　: 组织可以使用项目来处理大规模变更，例如将组织的整个基础设施移至云中。项目支持更大的实施范围，且可以更好地处理更多的任务、人员和里程碑。变更管理与项目管理之间的强大集成可能对组织大有助益。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　高影响服务请求需要使用变更来实施。较大的数字表明您的基础设施容易受到诸如无法更新 CMDB 等问题的攻击。

　　这表明您的变更请求和变更计划的有效性。较大的数字表示您的变更和计划是可靠的。

　　这表明某个变更是否影响了其他服务运营。较大的数字表示需要更好地传达变更。

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

　　使用变更角色，让适当的相关方参与其中，如变更负责人、审批者、直属经理和变更审查者。

　　配置各个级别的审批。标记 RFC 必须由 CAB 的所有成员批准还是由任何一个成员批准。

　　当所有 CAB 成员都推荐变更时，可以通过自动批准变更，来绕过变更经理和变更审批者的审批。

　　将变更分解为任务，并使用工作日志来估计变更实施团队完成活动将花费的时间。

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

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

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

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