文档更改服务管理实践 - 06 变更支持

由 superadmin 于 2024/12/25, 15:38 最后修改

从版本< 7.1 >

由superadmin编辑
在2021/01/29, 23:00上

到版本

由superadmin编辑
在2021/01/29, 21:43上

< >

修改评论 Renamed back-links.

Raw
已渲染

Summary

Page properties (2 modified, 0 added, 0 removed)

Details

Page properties

父

@@ -1,1
          +1,1 @@
--Main.WebHome
++C 实践指南.WebHome

Content

@@ -2,7
          +2,7 @@
  (((
  (% class="container" %)
  (((
--=   =
++= [[开始阅读>>doc:06 变更与支持.1 关于本文件.WebHome]] =
  需要下载 **ITIL 4变更支持实践【中文】**pdf版全文，请关注微信公众号itilxf ，并回复“变更支持”即可。
@@ -16,1014
          +16,15 @@
  请注意，ITIL先锋论坛专家团队仅仅只是进行了这些著作的语种转换工作，我们并不拥有包括原著以及中文发行文件的任何版权，所有版权均为Axoles持有，读者在使用这些文件（含本中文翻译版本）时需完全遵守Axoles 和 TSO所申明的所有版权要求。
--**翻译**：马军        **审校**：康羿        **审核**：戚依军
--)))
--)))
--
--= 1 关于本文档 =
--
--[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/1%20%E5%85%B3%E4%BA%8E%E6%9C%AC%E6%96%87%E4%BB%B6/WebHome?section=1]]
--
--本文档提供变更支持实践实用指南，分为五个主要部分，涵盖：
--
--* 本实践的一般信息
--* 本实践相关的流程和活动及其在服务价值链中的作用
--* 参与本实践的组织和人员
--* 支持本实践的信息和技术
--* 对本实践的合作伙伴和供应商的考虑
--
--==   ==
--
--[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/1%20%E5%85%B3%E4%BA%8E%E6%9C%AC%E6%96%87%E4%BB%B6/WebHome?section=2]]
--
--== 1.1 ITIL 4资格认证计划 ==
--
--[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/1%20%E5%85%B3%E4%BA%8E%E6%9C%AC%E6%96%87%E4%BB%B6/WebHome?section=3]]
--
--本文档中的部分内容可作为以下教学大纲的一部分以供检查：
--
--* ITIL专家创建、交付和支持
--* ITIL专家交付利益干系人价值
--
--详情请参考各部分教学大纲。
--
--
--
------
--
--= 2 一般信息 =
--
--[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=1]]
--
--== 2.1目的和描述 ==
--
--[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=2]]
--
--* **关键信息**
--
--本次变更支持实践的目的是通过确保有效的风险评估、变更执行的授权和变更计划的管理最大化的保障服务和产品变更的成功。
--
--该实践指导旨在确保对服务及其组件的变更在可控的范围内，并确保它们能够满足组织变更的相关需求。授权的变更即要能保证满足预期，同时还要满足组织关于变更效率的管理（变更的数量和变更实现的速度）和风险管理的要求。因为灵活性和敏捷性是现代组织的核心要素，所以它们会一直贯穿在本次实践指导中。
--
--成功实现变更包含三个前提：
--
--* 在价值流中规划及实现变更。将实践融入到价值流中，并确保其有效，安全且及时，来满足利益相关者的期望。
--* 实践的目的并不是将组织中所有变更计划和行动统一为一种模式：在数字化环境中，可能同时发生数百个更改，这种要求既不现实也不是必需的。
--* 对于所有在定义范围内的变更，实践应该集中精力放在效率，合规性和风险控制上。
--
--==   ==
--
--[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=3]]
--
--== 2.2术语和概念 ==
--
--[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=4]]
--
--**变更**
--
--任何可能对服务产生直接或间接影响的添加，修改或删除行为。
--
--变更支持实践要确保每个变更都能达到预期的结果。这与'聚焦价值'的指导性原则是相互统一的。与变更的技术细节相比，利益相关者更关心变更带来的价值。有时候，虽然准确的实施了变更，但是未必能实现预期的结果，达到预期的目标。此外，变更可能会产生意想不到的结果，包括对用户的负面影响，服务停机，服务级别降低和不稳定。所以，对于这些结果的控制很重要。变更包括使用各种方式和方法，每种方式和方法都代表不同级别的业务风险。软件变更通常是通过频繁且定期地部署新功能和修改内容来进行的。这些变更可以通过持续集成/ 持续交付（CI / CD）的方式来完。如DevOps和其他形式的迭代/敏捷交付（有关CI / CD的更多信息，请参见ITIL专家：创建，交付和支持）。物理基础架构的变化可能较慢，需要分阶段的“瀑布式”方法。可以使用相关的项目控制管理技术将这种类型的变更作为项目进行管理。但是，在实践中，很少有组织完全处于单一的阶段内。在大多数的变更中，组织经常包含了多个价值流阶段。其中，变更实践必须是自适应的，才能满足各种开发方法的需求。
--
--
--=== 2.2.1 基于复杂性的变更方法 ===
--
--变更支持实践应该确保在变更效率，变更数量和风险控制之间达到有效的平衡。这意味着在计划授权和流程控制上要进行更为谨慎的选择。
--
--从常规型的业务到灾难型的业务都可能发生变更（请参阅图片2.1）的情况。组织应该能够在该范围内的任何情况下都能做出改变。
--
--[[image:http://itil4hub.cn/bin/download/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome/1600754487294-144.png?rev=1.1||alt="1600754487294-144.png"]]
--
--图2.1在所有的业务阶段下都需要进行变更
--
--
--虽然，常规型业务相对可预测，不确定性较低，灾难情况相比有很高的不确定性，但是，任何情况下的变化都具有不同程度的复杂性和不可预测性。
--
--在不确定性较低的情况下，可以对变更进行标准化和自动化，这有助于降低成本并提升变更效率。在这些情况下，可以使用检查清单，模板和标准化的工作方式。这会定义在标准变更的内容中。
--
--**标准变更**
--
--一种低风险、预先授权的变更，它能得到完全理解和记录，并且可以在不需要额外授权的情况下实施。
--
--标准变更的示例包括：
--
--* 服务请求的实现
--* 基础架构的维护
--* 日常应急检测
--* 日常软件更新
--
--当创建或修改标准变更的程序时，应授权该程序并对其进行全面的风险评估。这种风险评估不需要每次都重复，只有在程序本身进行了一次修改时才需要进行。
--
--尽管标准的变更通常与正常情况下的业务有关，但在不确定性较高的情况下，存在多个标准化示例。这些包括：
--
--* 标准的事件解决
--* 标准的灾难响应
--
--通过预定义和预先测试的方式，可以帮助组织减少极端情况下产生的不确定性。
--
--然而，标准解决方案可能不能完美执行。这些情况需要一种不同的方法来实现变更。
--
--当有些变更没有标准化的方法时，组织通常会制定计划、授权和控制变更。他们实施的措施包括集中专家评估，授权和控制过程等。该流程由一组专家或权威人士共同来执行完成。针对风险较低的“一般变更”，通常可以使用自动化来提升变更效率。当变更为高风险时，变更授权可能是管理委员会或类似的机构。
--
--**变更授权**
--
--负责授权变更的个人或团体。
--
--可以通过创建（手动或自动）变更请求来触发一般变更。然而，具有CI/CD自动化流程的组织通常会利用自动化执行大多数变更过程。某些步骤（如服务请求注册）实际上可能变得不可见。
--
--变更模型为处理一般变更提供了指导。组织通常会根据评估，授权和持续控制的类型来定义变更模型。
--
--**变更模型**
--
--对特定类型的变更可重复管理的方法。
--
--可以基于以下因素定义变更模型：
--
--* 变更的系统/技术
--* 变更的规模
--* 地点/地区
--* 客户
--* 影响变更的法规要求
--
--如表2.1所示，在服务管理中的四种关键因素可以定义一个变更模型
--
--表2.1 服务管理模型中可确定变更模型的四种关键因素
--
--|**价值流和流程**|**组织和人员**|**信息和技术**|**合作伙伴和供应商**
--|(((
--变更流程的程序，包括形式化级别、变更授权的级别和形式
--
--客户或用户体验过程
--)))|(((
--所需能力
--
--组织解决方案（例如变更咨询委员会或同行评审）
--
--问责制度
--
--责任委托制度
--)))|(((
--信息要求
--
--工具自动化
--)))|(((
--第三方的参与情况和实施规划的情况
--
--合作伙伴和供应商的沟通情况
++**翻译**：马军        **审校**：康羿        **审核**：戚依军
  )))
--
--此外，组织需要考虑变更的风险级别。例如，组织可以通过迭代的方式来控制变更的风险。变更的每个迭代都在可控的风险阈值以下，较小的变更也会降低变更的成本，并且更易于控制。基于这些注意事项，许多组织限制了单个更改的大小，尤其是软件和其他数字化资源的大小。
--
--在管理不确定的复杂情况下，变更模型可能会有更大的帮助。例如，在变更模型的流程中可能包括了实施某些解决方案的失败性测试。这可能对定位那些无法带来明确的变更内容的事件或灾难带来极大的帮助。尽管这种方法在不稳定情况下更常见，但也适用于常见的业务型变更。
--
--变更实践应该确保在紧急情况下，能够有效、安全且及时地实施变更。有助于解决紧急情况的变更通常称为紧急变更。
--
--**紧急变更**
--
--必须尽快处理的变更。
--
--尽管有一些紧急的场景可以提前预知并提供标准解决方案（包括所需的标准变更），但是许多情况下尚没有现成的解决方案或没有时间进行失败测试。用于紧急变更的变更模型通常包含了那些有时间延迟的流程，例如注册请求或变更计划的更新。紧急变更可以通过特殊的部署拥有更高的授权。目的是在保证可接受的风险下，加快变更。
--
--关于紧急变更的两个重要的注意事项：
--
--* “紧急情况”并不意味着“没有规则或约束”。紧急变更可以在可控的情况下，通过标准化和自动化得到加速。紧急情况并不总是意味着完全不可预测。
--* 一些紧急变更确实可以应对不可预测的未知情况。这些情况包括，他们可能需要快速实施最佳解决方案，而没有足够的信息或时间进行测试。且这些情况的延迟变更和失败变更的风险在同一个等级上。
--
--**关键信息**
--
--变更支持实践应该包括针对可预见性和不可预见性不同情况的方法。这些方法可能包括：
--
--* 标准的变更
--* 根据专家分析和计划的可控变更
--* 基于多个安全的失败测试的变更
--* 在没有足够的评估和规划的情况下实施的紧急变更。
--
--前三种方法适用于从日常型业务到灾难业务的所有情况。最后一种方法适用于延迟成本高于失败成本的特殊情况。
--
--标准化和自动化功能对于实践是非常有益的，因为它们可以在大大加速变更的同时保留足够的流程控制。对于数字化资源，产品和服务，这是实践变更的推荐方法。
--
--减小变更的大小可以增加实践的效率，同时降低风险的级别。对于组织的变更模型，大小应该是重要的考量因素。
--
--
--=== 2.2.2 变更定义和范围 ===
--
--变更实践支持所有价值流，并且可以与任何其他实践一起使用，因为它们都可以启动对产品和服务的更改。但是，组织通常根据要变更的内容和发生变更的[[[Q3]>>url:http://itil4hub.cn/bin/view/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/#_msocom_3]] 背景，将变更实践的应用程序限制为有限的变更类型。
--
--通常，变更实践用于更改组织的产品信息和服务技术，同时其他的实践也会在服务管理的另外三个方面发挥极大的作用。尽管有些更改包含了部分变更内容，但变更实践的范围中可能不完全包括它（有关变更的示例，请参见表2.2）。组织定义了在变更支持实践中，处于哪一类的变更和哪个级别的变更要得到优先处理。基于这几个注意事项，通常包括：
--
--* **风险等级** 考虑引入变更后所带来的风险是否可控
--* **成本和损失** 评估变更带来的成本和造成的损失是否可控
--* **配置范围和资产管理** 变更实践能够为注册的配置项目和资产提供修改方法
--* **内部和外部规则要求** 组织必须严格遵守变更的相关要求。
--* **可视化变更所带来的影响** 在组件是动态互连的环境中，变更影响的可视化需求是非常重要的
--
--表2.2 服务管理模型中的四个核心要素变更示例
--
--|**服务管理的要素**|**涉及变更的内容**|**注意事项**
--|信息和技术|(((
--硬件和软件的服务架构
--
--服务设计
--
--用户技术手册
--)))|通常由变更实践和项目管理，服务设计和架构管理实践一起解决
--|组织和人员|(((
--组织架构
--
--人员职责
--
--工作行为规范
--)))|通常由组织管理和项目管理实践解决
--| |个人能力|通常由员工和人才管理机构解决
--|价值流和流程|(((
--价值流架构
--
--工作流程和程序
--
--流程文档
--)))|可以通过变更实践或其他实践来解决
--|合作伙伴和供应商|(((
--在体系结构上对第三方的依赖
--
--与第三方的合同安排（新供应商，责任变更等）
--
--合同和其他文档（版本的变更，延期等）
--)))|变更支持实践，供应商管理或其他实践可能会解决
--
--根据这些以及其他注意事项，组织决定是否将对产品和服务的修改视为变更，如果是，再将其进行轻度，中等或重度的划分。变更支持实践通常针对不同程度的变更有不同的方法，通常在变更划分中对此进行了详细说明。
--
--
--=== 2.2.3 变更支持实践的自动化作用和可视化作用 ===
--
--当对软件和其他数字化资源进行变更时，为了使变更的内容（包括变更计划，完整性控制，版本控制，兼容性控制等）能够成功自动执行。自动化变更大大提高了变更效率，同时保证了变更的风险在一个可接受的水平。尤其是处理单个且体量较小的变更时（请参阅第5节软件开发管理，发布管理和部署管理指南）。
--
--当变更实践高度自动化时，会因为受控环境的高度复杂性，造成难以对整个组织计划和正在进行的变更进行完整的范围监督，同时，也很难确定变更是在哪里产生的。
--
--组织应该拥有在较高的不确定性和复杂性中，保证变更风险在可控范围内的能力。
--
--能够降低变更风险的主要方法是减小自动化变更的规模，同时对变更进行标准化的定义。
--
--
--== 2.3 范围 ==
--
--[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=5]]
--
--变更支持实践的范围包括：
--
--* 规划组织中受控环境的变更
--* 规划变更模型和变更标准化
--* 规划变更工作流，活动和控制点
--* 计划和协调所有正在进行的变更
--* 控制从启动到完成的变更进度
--* 与利益相关者沟通变更计划和进度
--* 评估变更的成功，包括输出，结果，效率，风险和成本
--
--变更支持实践中不包含以下几个活动和职责范围，尽管它们与变更密切相关。表2.3中列出了这些内容，需要着重注意的是，ITIL实践只是价值流中使用工具的集合；根据情况，应将它们组合在一起。
--
--表2.3 与变更支持实践相关的其他实践活动
--
--|(% colspan="3" %)**实践指南**
--|(% colspan="2" %)变更启动|所有其他实践
--|(% colspan="2" %)变更的实现|(((
--架构管理
--
--部署管理
--
--基础设施和平台管理
--
--IT资产管理
--
--发布管理
--
--服务目录管理
--
--服务配置管理
--
--服务设计
--
--服务级别管理
--
--软件开发和管理
--
--供应商管理
--
--劳动力和人才管理
  )))
--|(% colspan="1" %)变更风险评估与控制|(% colspan="2" %)风险管理
--|(% colspan="1" %)成本控制，变更财务评估|(% colspan="2" %)服务财务管理
--|(% colspan="1" %)管理项目|(% colspan="2" %)项目管理
--|(% colspan="1" %)管理的组织变更|(% colspan="2" %)组织变更管理
--|(% colspan="1" %)测试|(% colspan="2" %)服务验证和测试
--==   ==
--
--[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=6]]
--
--== 2.4实践成功因素 ==
--
--[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=7]]
--
--* **定义：实践成功因素**
--
--实践成功因素是满足实践所需复杂的功能组成部分的目标。
--
--实践的成功因素（PSF）不仅仅是一项任务或活动；它包括所有服务管理模型的四个要素。虽然活动的性质和实践中PSF的资源可能有所不同，但它们都保证了实践的有效性。
--
--变更支持实践包含以下PSF：
--
--* 确保及时有效地实现变更
--* 最小化变更的负面影响
--* 确保利益干系人对变更的满意度
--* 满足与变更相关合规性的要求
--
--===   ===
--
--=== 2.4.1 确保及时有效的实现变更 ===
--
--变更支持实践的重点是效果和变更的及时性。
--
--变更效果可以通过变更的结果和产出进行度量。在变更产出的结果中，有效的变更可描述为“将资源从初始状态成功转换为预定义目标状态的变更”。但是，目标状态很少是变更的目标。目标状态产出的成果才是变更的目标。在成果级别上，有效的变更可描述为“成功实现所需预定义结果的变更”。
--
--众所周知，对正在发生的变更进行控制和评估是非常重要的。针对特定的变更，我们可以进行重新定义和评估。通常通过多次的变更和其他措施来实现结果。对于正在进行变更的团队而言，这种差异对于管理和控制极为重要。这些团队应了解变更的价值和具体的变更内容。团队的绩效应根据其在职责范围内对目标做出的贡献来评估。
--
--有效性包括在变更范围内定义的资源和服务的各种质量特性。这些可能包括安全性、性能、法规遵从性和可用性。
--
--变更的及时性是变更满足启动期望和要求的另一种度量要素。可以根据授权的变更数量来衡量变更的及时性，但主要关注的是变更是否满足启动的需求。在计划，控制和评估变更时，这应该是重要的考量要素。
--
--有时，如果不能满足变更的及时性将会使变更变得失效，无用或有害。
--
--变更的有效性和及时性可以通过以下方法改进：
--
--* 减少单个变更的大小
--* 标准化和自动化变更
--* 在变更，规划和实现的每个迭代中都包含一个反馈环
--* 关注结果，同时针对变更的过程及时沟通
--* 针对价值流内容的变更采用多种有效的ITIL实践。
--
--===   ===
--
--=== 2.4.2 最小化变更的负面影响 ===
--
--变更是中断和风险的来源。变更支持实践有望将风险保持在可接受的水平。在简单，变化缓慢的环境中，可以通过在变更的每个步骤上施加控制，在授权步骤中引入更多的利益相关者并在每种情况下创建应急计划来实现。但是，这些控制将导致变更的实现效率低下和延迟，这在复杂的环境中是无法接受的。
--
--为了平衡变更的及时性，有效性和风险级别，组织定义了将手动和自动控制结合起来的变更模型，以使变更标准化，不断减小变更规模，并监控和评估变更对基础设施、服务和利益相关者的影响。通过减少每个单独变更的影响、在变更失败时快速自动返回到以前的稳定状态以及自动化配置管理，可以实现风险最小化。
--
--
--=== 2.4.3 确保利益干系人满意度 ===
--
--许多利益相关者都对变更感兴趣，包括：
--
--* 服务提供者团队
--* 使用者
--* 消费者
--* 服务提供的赞助商
--* 服务消费的赞助商
--* 供应商和合作伙伴
--
--变更支持实践确保利益相关者的期望能够得到考虑和满足。这将与关系管理、风险管理和业务分析实践等一起完成。变更支持实践主要集中在变更实现期间和变更完成后，对利益相关者参与度和满意度的持续监控。持续沟通、状态更新和反馈收集是管理满意度的重要组成部分。
--
--
--=== 2.4.4 满足变更相关的管理和合规性要求 ===
--
--许多与变更相关的管理和合规性要求都会影响变更支持实践以及个别变更。重要的是，组织必须找到它们，理解它们并确保它们得到满足。变更支持实践通过以下方式支持此需求：
--
--* 包括变更模型，流程和程序中所需的控制点
--* 提供所需的信息
--* 通过持续改进来防止非合规性情况发生
--
--==   ==
--
--[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=8]]
--
--== 2.5 关键指标 ==
--
--[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=9]]
--
--变更实践的有效性和绩效应在每种实践贡献的价值流的背景下进行评估。与任何工具的绩效一样，该实践的绩效只能在其应用范围内进行评估。但是，工具的设计和质量可能会有很大差异，这些差异定义了根据用途使用工具的潜力或能力。有关度量，关键绩效指标（KPI）以及其他可以帮助实现此目标的技术的进一步指南，可以在衡量和报告实践指南中找到。
--
--变更支持实践的关键指标已映射到其PSF。它们可以用作价值流环境中的KPI，以评估实践对这些价值流的有效性和效率的贡献。表2.4中给出了一些关键指标的示例。
--
--表2.4 实践成功因素的关键指标示例
--
--|**实践成功要素**|**关键指标**
--|确保及时有效地实现变更|(((
--整个时间段内汇总的及时性处理（TPI）
--
--每个变更模型成功实现的平均时间
--
--变更启动的满意度和变更的结果
--
--变更的时效性
--
--变更成功率/接受率
--
--特定变更的TPI
++(% class="row" %)
++(((
++(% class="col-xs-12 col-sm-4" %)
++(((
++
  )))
--|最小化负面影响|(((
--受到变更影响的相关业务事件
--
--变更所带来的问题以及影响相关事件的数量和持续时间
  )))
--
--|确保变更相关利益干系人的满意度|(((
--利益干系人对变更支持实践的程序和沟通的满意度
--
--利益干系人对实现特定变更的满意度
--)))
--|满足变更相关管理和合规性要求|(((
--根据审计报告，具有明确的合规性规定
--
--与变更相关且不合规性事件的数量和影响
--
--与变更相关的合规性事件的数量和影响
--)))
--
--将关键的指标汇总到复杂的实践中，更易于价值流的管理，且对于变更实践的定期评估和持续改进也有着极大的帮助。变更支持实践中，没有单一的最佳解决方案，所以度量标准是基于组织的优先级和价值流的首要目标来进行考虑的。
--
--
--
------
--
--= 3 价值流和流程 =
--
--[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/3%20%E4%BB%B7%E5%80%BC%E6%B5%81%E5%92%8C%E6%B5%81%E7%A8%8B/WebHome?section=1]]
--
--== 3.1 价值流的作用 ==
--
--[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/3%20%E4%BB%B7%E5%80%BC%E6%B5%81%E5%92%8C%E6%B5%81%E7%A8%8B/WebHome?section=2]]
--
--像任何其他ITIL 实践一样，变更支持实践也有助于多个价值流。重要的是要记住，价值流永远不会由单个实践形成。变更支持实践与其他实践相结合，可以为消费者提供高质量服务。价值流的主要活动形式是：
--
--* 获取和构建
--* 设计和转换
--* 交付和支持
--* 改进
--
--图3.1 中显示了变更支持实践对服务价值流的作用。
--
--[[image:http://itil4hub.cn/bin/download/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/3%20%E4%BB%B7%E5%80%BC%E6%B5%81%E5%92%8C%E6%B5%81%E7%A8%8B/WebHome/1600755273276-287.png?rev=1.1||alt="1600755273276-287.png"]]
--
--图3.1 变更支持实践对价值流活动的热力图
--
--
--== 3.2 流程 ==
--
--[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/3%20%E4%BB%B7%E5%80%BC%E6%B5%81%E5%92%8C%E6%B5%81%E7%A8%8B/WebHome?section=3]]
--
--每个实践都可能包含流程和活动，它们对于实现实践目的是必不可少的。
--
--* **定义：流程**
--
--一组相互关联或交互的活动，可将输入转换为输出。流程就是将一个或多个定义好的输入，转换为定义好的输出。流程定义了活动的顺序及其依赖关系。
--
--变更支持实践包括两个流程：
--
--* 变更生命周期管理
--* 变更优化
--
--
--=== 3.2.1 变更生命周期管理 ===
--
--变更生命周期管理流程包括表3.1中列出的活动，并将输入转换为输出。
--
--表3.1 变更生命周期管理流程的输入活动和输出活动
--
--|**关键输入**|**活动**|**关键输出**
--|(((
--变更请求
--
--变更模型和标准变更程序
--
--政策法规要求
--
--配置信息
--
--IT资产信息服务目录
--
--与消费者和供应商/合作伙伴
--
--服务级别协议（SLA）
--
--财务约束准则
--
--风险信息
--
--容量和性能信息
--
--连续性政策和计划
--
--信息安全政策和计划
--)))|(((
--变更登记
--
--变更评估
--
--变更授权
--
--变更规划
--
--变更实现控制
--
--变更评审和关闭
--)))|(((
--变更记录
--
--变更流程
--
--变更评审报告
--
--变更资源和服务
--)))
--
--图3.2 显示了变更生命周期管理的工作流程图
--
--[[image:http://itil4hub.cn/bin/download/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/3%20%E4%BB%B7%E5%80%BC%E6%B5%81%E5%92%8C%E6%B5%81%E7%A8%8B/WebHome/1600755315634-648.png?rev=1.1||alt="1600755315634-648.png"]]
--
--图3.2 变更生命周期管理流程的工作流程
--
--
--流程可能会因变更模型而异。
--
--
--表3.2 提供了两个变更模型中的活动的示例。
--
--表3.2 中的变更模型示例只是说明众多变更模型中的两个。组织应根据自身管理的体系结构来确保服务的灵活性并满足利益干系人的期望。
--
--|(% colspan="2" %)**活动**|(% colspan="3" %)**人工变更**|**自动化变更**
--|(% colspan="2" %)变更登记|(% colspan="3" %)(((
--从变更发起者收到变更请求，根据变更请求，服务所有者，资源所有者，变更管理者或变更协调者将创建变更记录。
--
--变更发起方收到变更请求接受的确认。
--)))|变更请求累积在生产或服务待办项中。生产开发团队决定将哪些请求纳入开发。
--|(% colspan="2" %)变更评估|(% colspan="3" %)服务负责人，资源所有者，变更经理或变更协调员执行变更影响的评估，相关风险和所需资源。如果需要，可能会涉及其他领域的专家。评估信息被添加到变更记录。|生产开发团队决定执行变更的最佳方法。
--|(% colspan="2" %)变更授权|(% colspan="3" %)根据变更模型分配的授权，授权机构检查变更记录并提供授权。如果变更未经授权，则将其发送以供审查或关闭。由于会需要进行其他评估，因此将变更记录连同评估理由一起返回评估。|(((
--不需要变更授权：
--
--因为标准的更改很可能是预先授权的对于该类型的变更，通过开发过程对待办任务列表的评估完成变更授权。
--)))
--|(% colspan="2" %)变更规划|(% colspan="3" %)根据变更模型，将有相关专业知识和权限的角色安排到规划中。规划中可能需要其他授权，具体取决于变更模型。该变更规划由变更协调员或变更经理来进行安排。|规划阶段被最小化：较小的工作量允许将规划委派给开发团队，并减少了为此需要时间。
--| |(% colspan="2" %)变更实现控制|(((
--资源的计划变更由内部和外部专家团队执行。其中可能包括：
--
--* 软件开发人员
--* 基础架构工程师
--* 合同/ 供应商管理员
--* 测试人员
--* 用户支持专家
--
--手动和自动控制操作由变更经理或其他约定的角色执行。变更经理定期进行检测并纠正。
--)))|(% colspan="2" %)(((
--资源的计划变更由内部和外部专家团队执行。
--
--变更的实现控制几乎是全自动的，包括：
--
--* 验证和测试
--* 配置控制和验证
--* 资产控制
--* 版本控制
--* 备份和还原
--)))
--| |(% colspan="2" %)变更评审和关闭|(((
--变更完成后，或变更如果未能及时完成，需由公认的机构审查变更。其中，可能涉及以下一个或多个角色：变更经理，服务负责人，变更发起者，资源所有者。
--
--在评审前还是评审后正式关闭变更，取决于具体的变更模型。
--)))|(% colspan="2" %)除非变更实现不成功，否则不会对单个更改执行变更评审。在确认变更成功后，变更将自动关闭。
--
--表3.2 变更生命周期管理流程的活动对比
--
--
--=== 3.2.2 变更优化 ===
--
--该流程专注于变更支持实践，变更模型和标准变更过程的持续改进。它由变更评审触发，目的是找到低效率和其他需要改进的流程，或者根据现有模型和程序定期执行。
--
--该流程包括表3.3 中列出的活动，并将输入转换为输出。
--
--
--表3.3 变更优化流程的输入，活动和输出
--
--|**关键输入**|**活动**|**关键输出**
--|(((
--变更记录
--
--当前的变更模型和标准变更程序
--
--政策法规要求
--
--配置信息IT资产信息服务目录
--
--与消费者和供应商/合作伙伴的SLA
--
--财务准则和约束
--
--风险信息
--
--容量和性能或绩效信息
--
--连续性政策和计划
--)))|(((
--变更评审分析
--
--变更模型改进点启动
--
--变更模型更新的沟通
--)))|(((
--变更评审分析报告
--
--改进启动
--
--变更请求
--
--更新的变更模型
--
--更新的标准变更程序
--)))
--
--图3.3 展示了变更的工作流程图。
--
--
--表3.4 提供了变更活动的示例。
--
--|**实践活动**|**示例**
--|变更评审分析|变更经理与资源所有者和其他相关的利益相关者一起，在此期间对选定的（通常是不成功的）变更执行评审。他们确定变更模型和标准变更程序优化的流程，包括新变更类型的标准化。
--|变更模型改进启动|变更经理或变更协调员要在变更实践中持续改进措施和发起变更请求（如果变更模型和过程包含在变更支持实践的范围内）。
--|变更模型更新沟通|如果变更模型成功更新，则将其传达给相关的利益相关者。这通常由变更经理或资源所有者完成。
--
--表3.4 变更优化的活动流程
--
--
--变更支持实践由服务提供者执行，如表3.2和3.4所述。他们可能涉及客户，供应商和合作伙伴。这些实践依赖工具和技术的支持（有时甚至完全或很大程度上依赖自动化）。下图是对工作流程的优化展示。
--
--[[image:http://itil4hub.cn/bin/download/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/3%20%E4%BB%B7%E5%80%BC%E6%B5%81%E5%92%8C%E6%B5%81%E7%A8%8B/WebHome/1600755414932-477.png?rev=1.1||alt="1600755414932-477.png"]]
--
--图3.3 变更工作流程优化
--
--
--
------
--
--= 4  组织和人员 =
--
--[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/4%20%E7%BB%84%E7%BB%87%E5%92%8C%E4%BA%BA%E5%91%98/WebHome?section=1]]
--
--== 4.1 角色、能力和责任 ==
--
--[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/4%20%E7%BB%84%E7%BB%87%E5%92%8C%E4%BA%BA%E5%91%98/WebHome?section=2]]
--
--实践指南虽然没有描述实践管理的角色，例如实践所有者，实践领导，或实践教练。因为每个角色的结构和命名都在不同的组织上有所区别，因此ITIL中定义的任何角色都不应被视为强制性的。
--
--请记住，角色不是职务。一个人可以担任多个角色，一个角色可以分配给多个人。
--
--在活动中我们描述了角色的背景。根据表4.1所示的模型，每个角色都有一个能力简介。
--
--|**能力代号**|**能力简介（活动和技能）**
--|L|**领导者**  决策，委派，监督其他活动，提供激励和动机以及评估结果
--|А|**管理员**  分配任务并确定优先级，保存记录，持续报告，并发起基本改进
--|C|**协调员/沟通者**  协调多方，维护利益相关者之间的沟通，并开展宣贯活动
--|М|**方法和技术专家**  设计和实施工作技术，文档程序，流程咨询，工作分析和持续改进
--|Т|**技术专家**  提供技术（IT）专业知识并执行基于专业知识的任务
--
--表4.1 能力代号和简介
--
--
--在组织中可能会发现三个实践特定角色：变更经理，变更协调员和变更授权者。这些角色通常在手动处理大量变更的组织中被引入。
--
--
--=== 4.1.1 变更经理和变更协调员角色 ===
--
--变更经理通常负责：
--
--* 变更流程的初始处理和验证变更请求
--* 根据变更模型，将变更分配给适当的团队进行评估和授权
--* 正式向受影响方传达变更授权方的决定
--* 监视、评审、构建和测试变更团队的活动
--* 发布变更计划并确保其在需要时可用
--* 进行定期和特别的服务评审分析；对变更模型和标准变更程序进行改进
--* 将组织在变更支持实践方法方面的专业知识进行记录总结
--
--在某些情况下，组织会引入变更协调员的角色，它具有相似的职责，但职责范围比较有限（特定类型的变更、或管区，或组织的一部分）。
--
--这些角色的能力配置文件是MTCLA，尽管这些能力的重要性因变更而异。表4.2 中列出了变更支持实践中可能涉及的角色以及相关的能力概况和所需技能。
--
--
--=== 4.1.2 变更授权角色 ===
--
--变更需要资源，并且会带来风险。这有时会导致组织建立复杂的、通常是形式化的变更授权系统，且该系统有正式的委员会定期开会，来审查和授权在此期间累积的变更。这些被称为变更顾问委员会（CAB），它们通常成为组织价值流的瓶颈。它们导致了延迟并影响了变更支持实践的效率。
--
--基于资源、成本和优先级考虑对变更进行授权是很重要的。这通常不需要一个形式化的程序。变更模型应定义授权的要求和程序，将变更权限的角色委派给适当的级别的角色，如开发团队、技术专家或服务和产品所有者。
--
--变更授权者在其生命周期（从发起到完成）期间负责评估和变更的授权。根据变更模型，评估和授权，可以手动，自动完成，也可以针对特定类型的变更跳过授权。
--
--
--=== 4.1.3 变更支持活动中涉及的其他角色 ===
--
--表4.2 中列出了变更支持活动中涉及的其他角色的示例。
--
--|(% colspan="3" %)**活动**|(% colspan="3" %)**负责角色**|**胜任力**|(% colspan="3" %)**具体技能简介**
--|(% colspan="10" %)**变更生命周期管理流程**
--|(% colspan="4" %)变更登记|(((
--变更协调员
--
--变更经理
--
--产品负责人
--
--生产开发团队
--
--资源服务负责人
--)))|(% colspan="3" %)TA|(% colspan="2" %)了解变更模型和登记程序
--|(% colspan="4" %)变更评估|(((
--变更协调员
--
--生产开发团队
--
--产品负责人
--
--服务负责人
--
--技术专家
--)))|(% colspan="3" %)TC|(% colspan="2" %)(((
--良好的产品知识
--
--包括其架构和配置
--
--业务影响分析风险分析
--)))
--|(% colspan="4" %)变更认证|(((
--变更协调员
--
--变更经理
--
--客户代表
--
--生产开发团队
--
--产品负责人
--
--资源负责人
--
--风险和合规性专家
--
--服务负责人
--
--技术专家
--)))|(% colspan="3" %)CTM|(% colspan="2" %)(((
--良好的产品知识，内容包括其架构和配置
--
--了解变更模型，业务影响分析
--)))
--|(% colspan="4" %)变更计划|(((
--变更协调员
--
--变更经理
--
--生产开发团队
--
--产品负责人
--
--资源负责人
--
--服务负责人
--)))|(% colspan="3" %)TAC|(% colspan="2" %)(((
--良好的产品知识，内容包括其架构和配置
--
--了解变更模型
--)))
--|(% colspan="4" %)变更实施控制|(((
--变更协调员
--
--变更经理
--
--生产开发团队
--
--产品负责人
--
--资源负责人
--
--服务负责人
--)))|(% colspan="3" %)ATC|(% colspan="2" %)(((
--良好的产品知识，内容包括其架构和配置
--
--了解变更模型
--)))
--|(% colspan="4" %)变更审核和关闭|(((
--变更协调员
--
--变更经理
--
--客户代表
--
--生产开发团队
--
--产品负责人
--
--资源负责人
--
--服务负责人
--)))|(% colspan="3" %)TCA|(% colspan="2" %)(((
--良好的产品知识，内容包括其架构和配置
--
--业务影响分析
--)))
--| |(% colspan="9" %)**变更优化流程**
--| |变更评审分析|(% colspan="4" %)(((
--变更协调员
--
--变更经理
--
--生产开发团队
--
--产品负责人
--
--资源负责人
--
--风险和合规性专家
--
--服务负责人
--)))|(% colspan="3" %)TC|(((
--良好的产品知识，内容包括其基础架构和配置
--
--了解变更模型
--
--业务影响分析
--
--风险分析
--)))
--| |(((
--变更模型
--
--改进举措
--)))|(% colspan="4" %)(((
--变更经理
--
--生产开发团队
--
--产品负责人
--
--风险和合规性专家
--
--服务负责人
--)))|(% colspan="3" %)TMA|(((
--良好的产品知识，内容包括其基础架构和配置
--
--了解变更模型
--
--业务影响分析
--
--风险分析
--)))
--| |(((
--变更模型
--
--更新通讯
--)))|(% colspan="4" %)(((
--变更经理
--
--产品负责人
--
--服务负责人
--)))|(% colspan="3" %)CT|(((
--了解变更模型
--
--沟通技巧
--)))
--| | | | | | | | | |
--
--表4.2 负责变更支持活动的角色示例
--
--
--== 4.2 组织结构和团队 ==
--
--[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/4%20%E7%BB%84%E7%BB%87%E5%92%8C%E4%BA%BA%E5%91%98/WebHome?section=3]]
--
--尽管变更经理角色可能与正式职位相关联，但很少看到单独的组织结构来支持变更实践。这样的结构更容易在具有复杂的政府机构的组织中找到，并且许多变更都是手工处理的。在以产品为中心的组织中，工作头衔和工作角色通常不用于此实践，因为它与产品开发团队的日常活动集成在一起，并且在任何可能的地方都是自动化的。正式团队在实践中可能包括变更授权团队(例如变更委员会)和为特定变更指定的临时团队，特别是当变更被视为一个项目时(有关项目团队的详细信息，请参阅项目管理实践指南)。
--
--
--
------
--
--= 5 信息和技术 =
--
--[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/5%20%E4%BF%A1%E6%81%AF%E5%92%8C%E6%8A%80%E6%9C%AF/WebHome?section=1]]
--
--== 5.1 信息交流 ==
--
--[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/5%20%E4%BF%A1%E6%81%AF%E5%92%8C%E6%8A%80%E6%9C%AF/WebHome?section=2]]
--
--变更支持实践的有效性是基于所有使用信息的质量。这包括但不限于以下信息：
--
--* 客户和用户
--* 服务及其体系架构和设计
--* 合作伙伴和供应商，包括有关它们提供的服务的合同和SLA信息
--* 规范服务提供的政策和要求
--* 提出变更
--* 消费者和组织的预期收益
--* 用户故事
--* 变更实施的预估时间和成本的实现
--* 影响变更的规定
--* 从过去的类似变更中学到的教训
--* 过去和正在进行的变化
--* 利益干系人满意度和实践
--
--该信息可以采用各种形式。变更支持实践的关键输入和输出在第3节中列出。
--
--
--== 5.2 自动化和工具 ==
--
--[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/5%20%E4%BF%A1%E6%81%AF%E5%92%8C%E6%8A%80%E6%9C%AF/WebHome?section=3]]
--
--大多数情况下，变更支持实践的自动化将工作变得可行且有效。表5.1中将概述自动化的解决方案。
--
--
--表5.1 变更支持实践的自动化解决方案
--
--|(% colspan="2" %)**实践流程**|**自动化方法**|(% colspan="2" %)**关键功能**|**影响效果**
--|(% colspan="6" %)**//变更生命周期管理流程//**
--|变更登记|(% colspan="2" %)工单和工作流程系统，代办项管理工具，以及看板|启用和控制变更工作流程；|(% colspan="2" %)很高，特别是对于大量的变更
--| |(% colspan="2" %) |待办项优先级和工作流程管理；|(% colspan="2" %)
--| |(% colspan="2" %) |工作流程可视化|(% colspan="2" %)
--|变更评估|(% colspan="2" %)工单和工作流系统，协作工具和资源规划工具|评估的形式化和结构化，可提供更准确，更可靠的数据授权|(% colspan="2" %)中到高，特别是对于手动处理复杂的变更
--|变更授权|(% colspan="2" %)工单和工作流系统以及协作工具|快速且可追溯的远程批准变更|(% colspan="2" %)高，特别是对于高速变更的授权。
--|变更计划|(% colspan="2" %)变更调度程序，项目管理工具，看板和编排系统|可视化对所有利益相关者共享的计划和正在进行的变更；自动化标准变更的规划|(% colspan="2" %)很高，特别是在并行实现许多变更时
--|变更实施控制|(% colspan="2" %)工作流程管理工具，协作和报告工具，看板以及编排系统|可视化和报告对正在进行的变更的最新视图|(% colspan="2" %)很高
--|变更评审和关闭|(% colspan="2" %)协作工具以及工单和工作流系统|远程评审和讨论；可追溯的正式关闭变更|(% colspan="2" %)中等到高，特别是在法规要求可追溯记录的情况下
--|(% colspan="6" %)**变更优化流程**
--|变更评审分析|(% colspan="2" %)协作系统、分析和报告系统|远程协作;变更数据分析|(% colspan="2" %)(((
--中到高，
--
--特别是对于大量变更
--)))
--|(((
--变更模型
--
--改进启动
--)))|(% colspan="2" %)工单和工作流系统以及待办项工具|主动改进的正式注册登记|(% colspan="2" %)中低
--|变更模型更新沟通  |(% colspan="2" %)(((
--沟通系统和
--
--协作系统
--)))|向受影响的团队同步最新情况|(% colspan="2" %)中等到高，特别是当组织很大并且变更的数量很多的时候
--
--
--
------
--
--= 6 合作伙伴和供应商 =
--
--[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/6%20%E5%90%88%E4%BD%9C%E4%BC%99%E4%BC%B4%E5%92%8C%E4%BE%9B%E5%BA%94%E5%95%86/WebHome?section=1]]
--
--组织完全使用自己资源提供服务的这种情况很少。大多数（不是全部）依赖于其他服务。这些通常是由第三方提供的（请参阅ITIL 4版ITIL^^® ^^Foundation的2.4节：服务关系的模型）。在实践指南中，针对服务设计，架构管理和供应商管理引入了支持服务的依赖关系。第三方服务依赖信息用于支持变更实践中生命周期管理过程的所有步骤，并且也适用于变更优化的过程。
--
--变更模型应定义第三方如何参与变更的实现以及组织如何确保变更的流程。这取决于产品的架构和设计解决方案,服务和价值来源。然而，支持这些解决方案的变更模型的优化涉及变更支持实践。通常，在选择了正确的变更模型之后，在变更，评估，规划，授权，实现控制和评审期间，还要有第三方依赖的考量。与客户和供应商签订合同时可能会对变更施加限制，将标准变更包括在内，通常情况下，将变更模型包括在合同中，并对有异议的变更提供明确的定义和批准程序。
--
--组织的目标是确保快速有效的执行变更流，他们通常试图同意与合作伙伴和供应商密切合作，消除沟通、协作和决策中的障碍。此类关系中的各方应以相互透明可见为目标，知晓可能影响各方的变更内容(有关更多信息，请参阅供应商管理实践指南)。
--
--
--
------
--
--= 7 重要提醒 =
--
--[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/7%20%E9%87%8D%E8%A6%81%E6%8F%90%E9%86%92/WebHome?section=1]]
--
--实践指南的大部分内容都可以为组织在建立和培养自己的实践时提供可参考的建议。实践指南为组织提供了解决问题的框架，而不是答案本身。使用实践指南时，组织应始终遵循ITIL 指导原则：
--
--* 聚焦价值
--* 从你所处的地方开始
--* 基于反馈迭代推进
--* 协作和提升可视化程度
--* 通盘思考和工作
--* 保持简单实用
--* 优化和自动化
--
--有关指导原则及其应用程序的更多信息，请参见ITIL 4 基础版中的第4.3节
--
--
--
------
--
--= 8 致谢 =
--
--[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/8%20%E8%87%B4%E8%B0%A2/WebHome?section=1]]
--
--AXELOS有限公司感谢所有为该指南的开发做出贡献的人。这些实践指南融合了ITIL社区前所未有的热情和反馈。AXELOS特别要感谢以下人员：
--
--==   ==
--
--[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/8%20%E8%87%B4%E8%B0%A2/WebHome?section=2]]
--
--== 8.1 作者 ==
--
--[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/8%20%E8%87%B4%E8%B0%A2/WebHome?section=3]]
--
--罗曼·朱拉夫列夫（Roman Jouravlev），格雷格·桑克（Greg Sanker）。
--
--==   ==
--
--[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/8%20%E8%87%B4%E8%B0%A2/WebHome?section=4]]
--
--== 8.2审阅者 ==
--
--[[编辑>>url:http://itil4hub.cn/bin/edit/06%20%E5%8F%98%E6%9B%B4%E4%B8%8E%E6%94%AF%E6%8C%81/8%20%E8%87%B4%E8%B0%A2/WebHome?section=5]]
--
--Akshay Anand，Roy Atkinson，Sofi Fahlberg，Cheryl Grimes，Piia Karvonen，Henny KerkvlietTerpstra，Antonina Klentsova，Anton Lykov，PaulaMäättänen，David Moskowitz，Christian F.Nissen，Mark O'Loughlin，Tatiana Orlova，Eina Pirjtutu Skrynnik，Mark Smalley。

粤ICP备17056641号

深圳市艾拓先锋企业管理咨询有限公司