AdvancedITIL: 服务支持度量标准
主办者:
服务支持度量标准
变更管理
第 7 章
与故障管理一样，ITIL 建议对变更管理分两级进行监视。第一个监视级别是管理报告，这与故障管理相同。第二个级别稍有不同，因为 ITIL 在此交叉引用了英国标准学会的出版物“IT 服务管理实施规范 (PD0005)”。第二个级别的重点是详细的“变更管理”报告。切记这两个级别“变更管理”的主要目标都是：
“变更管理”流程的目标是确保利用标准化的方法和规程有效、及时地处理所有变更，以便将由变更引起的事故对服务质量的影响降到最低，并因此改进公司的日常运作。
通过变更管理可获取用于监视、测定和度量标准的大量宝贵测量数据。ITIL 将重点集中在如下主要问题上：
- 一段时间内实施的变更总数，以及按配置项 (CI)、配置类型、服务等实施的变更数。
- 变更原因的分类（用户请求、功能增强、业务需求、服务呼叫/事故/故障的解决、规程/培训方式的改进等）。
- 成功的变更数。
- 放弃的变更数及其原因（例如，不当的评估、不合理的结构）。
- 由变更引发的事故数（按故障严重程度分类）及其原因（例如，不当的评估、不合理的结构）。
- 变更请求数（及由此形成的任何发展趋势）。
- 复查过的已实施变更数，以及待查的已实施变更数（按时间分类）。
- 由特定原因（例如，用户需求经常发生变化、薄弱的环节、不合理的结构）引起的与某个配置项有关的变更请求/问题记录的出现几率居高不下（这特别值得关注）。
- 沿用先前周期（上个周期，去年）内得出的数字进行比较。
- 拒绝的变更请求数。
- 已失败的变更数占变更总数的比例（按配置项和总数进行分类）。
- 待实施的变更数，按配置项及“变更管理”流程的阶段分类。
可以看出，推荐管理报告的范围很广，但其重点是更高级的测定而不是具体变更的细节。对以下报告都应进行深入分析：
一段时间内实施的变更总数，以及按配置项 (CI)、配置类型、服务等实施的变更数。该报告中的变更总数是直接了当，并且是按种类划分的。照这样，报告中数字变化与晴雨表相比差不了多少，因为变更数和变更种类极易受 IT 和业务变更的影响。该报告对配置（资产）管理的管理人员来说很重要，因为 ITIL 建议必须通过“变更管理”流程来改变配置项（资产）的状态。您需要判断适用于自己公司的种类，但一定要注意分类不要过多。过多的分类将令人困惑，而不是传达信息。
- 业务取向指标 — 虽然几乎每种“变更管理”报告都会引起业务群体的注意，但业务经理对此种报告特别在意，尤其是在报告中按业务区域分类的情况下。
变更原因的分类（用户请求、功能增强、业务需求、服务呼叫/事故/故障的解决、规程/培训方式的改进等）。此种报告中含有有用但却是在很高级别上的数据。ITIL 中并未列举对于此种报告的推荐时段，但可根据上一个时段作出详细的报告，也可根据许多时段作出累计报告（如根据过去的 12 个月），以便预测所有可能产生的发展趋向。
- 业务取向指标 — 应该对可能想要查明变更原因，特别是想要查明业务群体不想查明的变更原因的业务经理提交此种报告。
成功的变更数。虽然 ITIL 没有说明“成功”的含义，但显而易见，“成功”就是指成功实施所有变更。但对于那些已成功实施但为时已晚的变更、放弃后又重新实施的变更，或者并未引发新事故的变更又将如何衡量呢？您必须先定义对于自己公司“成功”变更的含义，以使此种报告生效。结果可能是按照每一成功变更类型对此种报告进行分类。其中只有一个总体数字的报告对于变更管理没有什么用处。
- 业务取向指标 — 这对业务经理来说是一个很重要的报告。业务经理与 IT 部门对“成功变更”可能有完全不同的看法。业务经理希望查看每一成功变更的简要概述，该简述是这个报告的附件，或者可以在线查看。希望业务经理可对报告中的“成功”变更作出反应和反馈意见。
放弃的变更数及其原因（例如，不当的评估、不合理的结构）。ITIL 术语“放弃”的含义是指实施变更后又取消了变更，并恢复原来的状态。放弃变更可能有多种原因，如性能差、新的事故太多、变更给另一组件带来了负面影响、或者变更不符合变更请求 (RFC) 中所提出的要求。这是一个非常重要的报告，特别是在我们考虑到 ITIL 变更管理的目标中说明的变更必须能够用以改进公司的日常运作 的时候。显然，放弃的变更不符合这一要求。提交此种报告的同时还要提供每个放弃的变更的说明，其中包括放弃变更的理由，纠正错误所采取的措施，以及为避免将来重蹈覆辙所实施的变更。
- 业务取向指标 — 这对业务经理来说又是一个重要的报告。业务经理希望查看与自己所在业务区域有关的所有放弃的变更的相关说明。许多业务经理将利用此种报告确定在其所处环境中放弃变更的开销、影响和作用。除了此种报告，当“变更管理”流程指出需要放弃的变更时，业务经理还应立即得到通知。
由变更引发的事故数（按故障严重程度分类）及其原因（例如，不当的评估、不合理的结构）。这是另一个关键度量标准，因为它直接与变更管理目标相关，也就是将与变更相关的事故 产生的影响降到最低。虽然多数事故都是由失败或放弃的变更所致，但并非所有事故的起因都是如此。许多成功的变更也会引发事故。例如，对于某个变更请求，变更可能是成功的，但客户可能不了解变更的某些方面，并且可能需要即时培训。在这种情况下，是变更过程而不是变更本身失败了。
跟踪并报告由变更引发的事故是至关重要的。这意味着需要将“事故”和“变更”软件紧密地集成在一起，以便迅速、轻松地跟踪由变更引发的事故。还意味着必须培训服务台人员，以便识别与变更有关的事故。服务台人员还必须正确地记录详细信息，包括变更索引号，以进行跟踪。
这是一个极为重要的报告。这个报告中还应包括每个事故出现的原因，以便吸取教训避免将来重蹈覆辙。
- 业务取向指标 — 业务经理对这些事故的警惕性都很高，因为在大多数情况下，他们或他们的员工都引发过此类事故。除了能够收到此种报告，业务经理还必须能够随时复查与变更相关的事故，最好可在线复查。
变更请求数（及由此形成的任何发展趋势）。变更请求数是一个简单明了的度量标准。难以理解的是“由此形成的任何发展趋势”。首先，变更请求数并不总是等于将要实施的变更数。例如，某些变更请求将遭到拒绝，而多个变更请求可能会针对同一变更。其结果就是变更请求数总等于或多于已实施的变更数。在这个报告的第一部分中应列出变更请求数。如果能在报告中分别列出“接受的”和“拒绝的”变更请求数的小计就更好了。
当需要预测发展趋势时，我们将要运用知识并进行干预。在 ITIL 中并未说明需要预测的发展趋势。这必须由每个公司自己决定。典型的趋势包括：来自于某个业务部门的变更请求数的增加或减少，与特定软件有关的变更请求数的增加或减少，或征求新技术的变更请求数的增加或减少。只有通过收集、分析信息才能发现这些发展趋势。通过分析作出的报告将特定于所报告的时段。
- 业务取向指标 — 业务经理虽然并不十分关心实际的变更请求数，但却对发展趋势极感兴趣。
复查过的已实施变更数，以及待查的已实施变更数（按时间分类）。 引自 ITIL： “实施无效的变更后，在“变更管理”流程中应当采取后续行动，以便纠正因此产生的任何问题，或者提高变更管理系统本身的性能。” 因此，作出与变更复查、记录复查和工作积压相关的报告是至关重要的。例如，大量的待实施变更可表明变更管理缺乏资源。大量的未成功变更可表明变更的评估或变更的创建不能令人满意。
通过复查变更记录也可发现其他流程中的问题。通过复查可发现在故障管理中错误地将问题的根源认定为不可靠的工艺部件，或是规程和/或培训的缺乏。进行报告的准备工作需要花些时间，并要求有熟练的分析技巧，但这对成功进行变更管理是至关重要的。具有讽刺意味的是，通过提交报告以改善变更管理也很有可能导致额外的变更请求。
- 业务取向指标 — 这个报告对业务经理是至关重要的，特别是在其规程或培训出问题时。在准备将这个报告提交给业务经理时，一定要让这个报告吸引该业务群体对其需要进行改进的领域的注意力。
由特定原因（例如，用户需求经常发生变化、薄弱的环节、不合理的结构）引起的与某个配置项有关的变更请求/问题记录的出现几率居高不下（这特别值得关注）。 要更好地理解这句话，可以不看括弧中的内容，即 “由特定原因引起的与某个配置项有关的变更请求/问题记录的出现几率居高不下”。于是其含义就更为明了了。利用变更请求数和问题记录数有助于发现配置项（资产组成部分）的弱点。这是一种基本报告，因为越早发现配置项的弱点，问题就能越快地得到解决，从而更好地为客户提供服务。若要作出此种报告，需要让故障数据库和变更数据库与配置（资产）数据库相匹配。为此，需要让故障数据库、变更数据库、配置数据库兼容（或一个综合数据库），还需要有人作出其中含有所需信息的报告。虽然要花些时间，但应要求所有 IT 经理都阅读这个报告。
- 业务取向指标 — 这对所有业务经理来说又是一种“必读”报告。应与业务经理一起讨论此种报告（不仅是将其提交）。业务经理可能就变更请求和问题记录的出现几率居高不下的原因给出额外的深入见解。
沿用先前周期（上个周期，去年）内得出的数字进行比较。这不应是一种孤立的报告，而应将其作为上述几个管理报告的一个基本组成部分。
- 业务取向指标 — 与业务经理协作以确定这些报告应包括的时段。
拒绝的变更请求数。这是一种简单的报告，可通过添加拒绝变更请求的原因这种分类标准对其进行改进。在公司中有可能会因各种原因提出过多的变更请求，如缺乏控制、不能胜任或不了解变更请求的内容。应当确定、发布拒绝变更请求的标准。
- 业务取向指标 — 应将此种报告，以及拒绝的变更请求的分类一并提交给业务经理。因为大多数被拒绝的变更请求很可能来自于公司内部，所以此种报告有助于业务经理改进其规程和流程，以便减少不必要的变更请求数量。
已失败的变更数占变更总数的比例（按配置项和总数进行分类）。此种报告与上述有关放弃变更的那种报告类似，所有原则都适用。然而，有一个关键的区别 — 并不是所有的失败变更都是由于放弃引起的。有时，放弃失败的变更也很难，因为已实施了解决方案或采取了规避措施。
虽然如此，这两种报告的属性和结构应保持一致。
- 业务取向指标 — 应将此种报告提交给业务经理。（请参考本节前面讨论的“放弃报告”复查部分。）
待实施的变更数，按配置项及“变更管理”流程的阶段分类。与前面讨论的工作积压报告类似。然而，那种报告只讨论总数，而此种报告则要求对积压的工作进行分类。可以自定义适合自己公司的种类。切记此种报告的主要目的是用于发现导致出现工作积压的瓶颈，并解决问题。避免出现工作积压是很重要的，所以应将此种报告提交给所有 IT 管理人员。
- 业务取向指标 — 这又是业务经理“必读”的报告，业务经理将会希望了解导致推迟实施变更的工作积压。另外，如果业务经理提出的变更请求将错过最后的时间期限，那就应当立即通知他们。
这些管理报告涵盖变更管理的方方面面。这些管理报告极为重要，因为 IT 变更管理的失败确实会导致混乱。在本节的开头，我们曾提到 ITIL 交叉引用了英国标准学会的出版物“IT 服务管理实施规范 (PD0005)”。以下是该实施规范中所作的建议：
- 变更请求数。
- 拒绝的变更请求数和所占的百分比。
- 紧急变更。
- 处于变更状态。
- 按下列标准分类的待实施变更数：
- 种类
- 等待时间
- 按下列标准分类的已实施变更数：
- 配置组成
- 服务
- 待实施变更和瓶颈。
- 每一变更的开销和开销汇总。
- 变更对业务的影响。
- 按业务区域分类的变更。
- 配置项的变更频率。
在前面的管理报告中已经讨论了上述大多数内容。除了下列内容：
- 紧急变更。
- 每一变更的开销和开销汇总。
- 变更对业务的影响。
下面将对其进行讨论：
紧急变更。紧急变更数量很大表明变更管理并未得到适当的实施，或者某些技术支持小组回避了很多紧急变更。应当只在特殊环境中实施紧急变更，如在发生事故时，只有通过实施变更以根除故障才能让客户回心转意的情况下。不应因工作人员能力太差而进行紧急变更，如决定进行变更的人忘记继续处理以前请求的变更。此种报告中应列出紧急变更总数，并且是按种类划分的，如：每个技术支持小组作出的变更数，每个业务部门作出的变更数和/或对每个配置项作出的变更数。在报告中还应列出紧急变更的原因。
- 业务取向指标 — 紧急变更对业务部门的影响各不相同，所以应将此种报告提交给各业务部门的管理人员。如果各个业务部门提交的紧急变更请求太多，那就要安排会议以讨论怎样更好地安排紧急变更的进度。
每一变更的开销和开销汇总。财务分类与公司的特征和性质有关。例如，与未实施费用分摊制度的公司相比，实施费用分摊制度的公司将需要更加详细的财务分类。然而，无论是否实施了费用分摊制度，每个公司都应了解其变更开销，并将其公之于众。应该将此种报告提交给所有 IT 经理。在进行中的变更的变更记录中应列出总运作开销、从而反映出每项变更的当前开销。
- 业务取向指标 — 业务经理将会希望了解所请求变更的开销，或影响其业务的变更的开销。此外，费用索回将影响这些报告的内容。应将这些报告提交给业务经理，以使其能够了解所请求变更的费用，或影响其业务的变更的费用。
变更对业务的影响。在许多情况下，变更对业务的影响是唯一的，依变更的性质和紧急程度而不同。因此，虽然不会就变更对业务的影响而提交报告，但在打开变更记录时，应该能够查看“变更管理”流程中任何类型的变更对业务影响的有关信息。
- 业务取向指标 — 对此种报告的复查较之首次查看更为重要。出于各种各样的原因，在变更的生命周期内可能会对变更对业务的影响或紧急程度进行修改。这就是为什么业务经理要复查所有变更对业务的影响。
如前所述，进行变更管理要求进行大量的测定和监视。再来讨论另一 ITIL 变更管理目标：
“当发生变更时，为了能够进行平稳的过渡，变更管理流程对其具有很高的能见度和畅通的沟通渠道尤为重要。”
关键词是“很高的能见度和畅通的沟通渠道”。此短语强调了为什么这些报告如此重要，以及为什么应优先考虑业务取向。变更管理是成功整合业务和 IT 的基础。因此，上述所有报告都是至关重要的。
> > 第 8 章 - 发布管理