要想跨所有IT流程整体一下子实施IT基础设施库（ITIL），即便不是不可能的，也是不现实的，组织必须决定他们到底想从哪里开始。变更支持实践的目的是通过确保风险得到适当评估,授权变更继续以及管理变更排程，最大限度地提高成功服务和产品变更的数量。

      理想情况下，我们应该基于仔细的实践评估和关于最大商业利益在哪里能快速达到的令人信服的分析，来决定这个启动点。然而，在IT组织中有相当大的比例在历史上都是从事件管理开始的。这种决定通常都是基于“直觉”，而不是其它方面因素。毕竟，事件管理就是使IT能快速为业务恢复服务，因此通过采用ITIL来改进这些流程，企业应该能降低停机时间，提升IT人员的工作效率，确保最终用户的满意。

       但是，CEO们真的基于IT能多快地解决问题来衡量IT的价值吗？IT组织能为ITIL的实施争取到行政级的支持吗？这种ITIL实施是基于修复时间和其他事件管理绩效度量指标的。可能不会。事实上，当IT绩效基于与业务和可量化业务价值交付的一致性进行度量时，许多IT组织将关注他们最初的ITIL成果和在变更管理上的投资。为什么变更管理越来越多地成为ITIL实施最开始的关注点呢？有两个基本原因：它可以在问题出现之前预防问题发生，而且它确实是有效的。

　　变更是许多事件的根本原因,ITIL变更管理确实有效;

　　技术方面的最新进展已经使得ITIL变更管理比以往更具吸引力。例如，配置管理数据库（CMDB）的改革已经给IT管理变更的方法带来了更多的灵活性。结果，配置管理正变得更成熟，超越了基本的IT资产清单，达到了自动识别和配置项定义的成熟度，关系和依赖使得变更管理和影响评估成为现实。这些技术，尤其是那些支持发现和IT服务映射的技术，还将用于帮组防止和管理未授权的变更。

　　打动持怀疑态度的人们

　　IT组织内存在不相信基于流程改进的群体，他们满足于关注与技术方面关联不大的任务管理，在这种情况下，IT组织怎么能发起ITIL变更管理实施呢？支持者如何能说服他们当中反对ITIL的人群呢？

　　许多人通过采取措施克服文化和业务冲突来开始工作。一个有效的方式是提供正式的ITIL模拟研讨会进行培训。这些研讨会切实地演示了流程模型在处理危机情况时的优势，比如阿波罗13号登月任务。因此，不要在没有实践经历或者示例的情况下强迫式地推行ITIL理论，参与者一起工作来理解流程模型怎么能同时提升组织和个人处理高压力情况的能力。

　　最成功的研讨会包括一批资深IT管理者和业务经理，以及跨职能部门的IT成员。高级管理代表的参与很重要，因为高级管理人员应该成为组织变更工作的领导者。来自跨职能部门IT组织的参与也非常重要，他们描述了基于流程的方法的优势，打破了狭隘的思考和技术孤岛。

　　我们开始吧,实际上，从哪方面开始实施ITIL并没有绝对的正确和不正确。这取决于你的服务交付模型和成熟度，某些流程很自然地会优先考虑。然而，管理变更应该被更快地审查，宜早不宜迟，因为它对于推动持续服务改善至为重要。如果不及时审查，它以后会给你带来麻烦的（问问你的规约审计师们就知道了）。

　　CIO们应该在支持变更管理法规遵从策略的流程自动化方面投资，同时不要忘了处理ITIL自身最大阻力（文化和组织对变更的抵制）的切实可行的方法。

ITIL实践定义:变更

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

变更支持的范围由每个组织定义。它通常包括所有 IT 基础设施、应用程序、文档、流程、供应商关系以及可能直接或间接影响产品或服务的任何其他内容。

区分变更支持与组织变更管理非常重要。组织变更管理是管理变更的人员方面，以确保改进和组织转型计划得到成功实施。变更支持通常侧重于产品和服务的变化。

变更支持必须在做出有益的变更(这些变更可以带来额外价值)与保护客户和用户免受变更的不利影响的需求之间取得平衡。所有变更都应由能够理解风险和预期收益的人员进行评估;然后必须在部署之前授权变更。但是，此评估不应引入不必要的延误。

授权变更的个人或团队称为变更授权。必须为每种类型的变更分配正确的变更授权，以确保变更支持既高效又有效。在高速组织中，分散变更批准的做法很普遍，这使同行评审成为高绩效的最佳预测指标。

变更的三种类型分别以不同的方式进行管理

标准变更:这些是低风险，预授权的变更，可以很好地理解和完整记录，并且无需额外授权即可实施。它们通常作为服务请求启动，但也可能是运行的变更。当创建或修改标准变更的规程时，应对任何其他变更进行全面的风险评估和授权。每次实施标准变更时都不需要重复进行风险评估;只有在对其执行方式进行修改时才需要执行。

一般变更:这些变更需要按照流程进行计划、评估和授权。基于变更类型的变更模型可确定评估和授权的角色。有些一般变更是低风险，而这些变更授权人通常是能够做出快速决策的人，通常使用自动化来加速变更。其他一般变更都是非常重大的，变更授权可能与管理委员会(或同等程度)一样高。一般变更的启动是由创建变更请求来触发。这可以手动创建，但具有用于持续集成和持续部署的自动管道的组织，通常会自动执行变更支持过程的大多数步骤。

紧急变更:这些变更必须尽快实施;例如，解决事件或实施安全补丁。紧急变更通常不包含在变更排程中，加快评估和授权流程以确保快速实施。紧急变更应尽可能与一般变更进行相同的测试、评估和授权，但可以接受将一些文件推迟到实施变更后，并且有时由于时间限制，有必要减少测试来实施变更。紧急变更可能还有一个单独的变更机构，通常包括少数了解所涉及的业务风险的高级管理人员。