服务支持度量标准精品资料(完整版)资料.doc

《服务支持度量标准精品资料(完整版)资料.doc》由会员分享，可在线阅读，更多相关《服务支持度量标准精品资料(完整版)资料.doc（226页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、服务支持度量标准精品资料（完整版）资料(可以直接使用，可编辑 优秀版资料，欢迎下载）服务支持度量标准简介对于已受过 ITIL 培训、阅读过 ITIL 书籍或参加过 ITIL 讨论会或集训的人来说，ITIL 所带来的好处往往是显而易见的。通过推介对公司不同部门具有重要意义的内容，以及传达ITIL 服务交付和服务支持中概括的目标，本系列的前两册的重点集中在 ITIL 高级概念上，这些概念有助于 ITIL 专家培养公司内部非 ITIL 专家的约束感。在本系列的第三册中，将通过重点讨论ITIL 服务支持一书中介绍的监视和测定最佳惯例来继续探讨 ITIL 高级概念，包括以下内容： 事故管理 故障管理 变

2、更管理 发布管理 配置管理 ITIL 服务支持一书的各节详列了管理功能区域的人员需要思考的度量标准。本书总共列出了 80 个推荐的测定方法，以便用于监视和测定这些流程的性能。 在本书中将通过引用 ITIL 定义、用清晰而简明的术语进行表述，以及向 IT 经理和业务经理建议如何充分利用数据来复查每个 ITIL 度量标准。通过重点强调这些关键指标，可以帮助您向 IT 部门内负责管理相关功能区域的人员阐明 ITIL 最佳惯例的价值。本书还将继续介绍 ITIL 推荐的度量标准，并介绍“业务取向指标”。这些关键的度量标准用于拓展 ITIL 最佳惯例，以便凸显那些有助于利用业务优先级定位 IT 目标和目的

3、的信息。第 1 章 - 智慧分层体系信息技术 (IT) 小组一般精于收集大量数据。然而，对于作出与业务相关的决策，收集来的数据并不总是得到了充分地利用。大多数情况恰恰相反。例如，许多 IT 部门测定和监视在服务台发生的所有事件，却仍可能未注意到一台关键服务器已经接近满负荷运转。为什么会出现这种情况？这是因为服务台技术可以自动收集有关服务台性能的大量数据，而测定服务器容量方面的增长则需要进行其他工作和干预。 我们将讨论如何充分利用数据，以协助 IT 经理和业务经理作出有助于保持 IT 不偏离业务目标的决策。我们从了解服务管理中最常用的几个术语开始：“数据”、“信息”、“知识”以及程度较低的“智慧

4、”。虽然这些词的使用率很高，但这些词并不总是用在了适当的语境中。Merriam-Webster 在线辞典 对这些词的定义如下：数据1. 是用作推理、讨论或计算的依据 的实际信息（测定结果或统计信息）。 2. 传感设备或感觉器官输出的信息，包括有用以及无关或冗余信息，必须对其进行处理才能使其具有意义 信息3. 通过调查、研究或指示获取的知识 4. 智力、消息 5. 事实、数据 知识6. 某人的信息范围 智慧7. 累积的哲学或科学学识：知识 8. 明智的态度或行为过程 根据上述定义，“数据”是“信息”的基本单位，“信息”是“知识”的基本单位，而“知识”本身又是“智慧”的基本单位。因此，在理解和决策

5、分层体系中有四个层次。收集数据、信息和知识完全是为了能够做出明智的决策。然而，如果数据来源有问题，那么大多数情况下决策也会出现问题。下图是数据、信息、知识和智慧之间关系的图解：图 1：基于数据构建的智慧分层体系如图所示，“数据包”是从一个层次传递到下一个层次。“智慧”层次具有作出明智决策必需的所有组成部分 数据、信息和知识。当然，可以在任意层次作出决策，这取决于现有的结果和条件。下面的例子用于说明在各个层次进行决策的过程：数据层：服务台经理发现有二十位客户等待打入 。他可能会决定临时增加一线客户服务人员的数量，这是根据一条数据制定的决策。信息层：在另一类似的情况下，有 20 位客户等待打入 ，

6、但这次经理掌握了更多的数据。他知道有一台目前已停机但马上将恢复正常的服务器。在这种情况下，经理可能决定稍后再增加一线客户服务人员的数量，因为他（或她）怀疑这两个问题是相关的。在拥有多个数据源的情况下，经理掌握的信息更多，并将根据可用信息作出决策。知识层：服务台经理发现等待打入 的客户不断增多，而且某台服务器即将接近满负荷运转。因为她拥有用以说明如何应对此情况的信息，所以可以立即采取适当的行动隔离并解决问题。这个决策是基于知识作出的。 智慧层：IT 执行官正在温习上个月的知识，并发现某一供应商提供的几台服务器出了问题。他们将决定要求供应商评估其所有服务器，以确定其他服务器是否会出现同样的问题。这

7、个决策是基于智慧作出的。 尽管这些例子可能过于简单，但它们可作为理解“智慧分层体系”的参考。 第 2 章 - 驱动因素进行监视或测定应该总是事出有因。您应该不断思考“为什么要进行测定？”或“为什么要整理数据？”监视和测定的理由主要有四个：定向：这包括进行监视和测定，以便为活动设定方向，以达到既定的目标。这是进行监视和测定最一般的理由。例如，服务水平协议 (SLA) 用于设定目标度量标准，而 IT 部门的测定是对照这些目标进行的。这些目标为 IT 部门指明了方向。介入：通过进行监视和测定来确定介入点，包括后续变更和纠正措施。例如，可对网络进行监视，并确定网速很慢。结果是 IT 人员将进行调查，这

8、会导致对其进行改动以提高网络性能。可能还会为进行调查执行特殊的监视，以跟踪改动的效果。此外，通常只有在改动期间才会基于这些度量标准进行监视。不过，为了进行定向并确保性能在将来不会恶化，可能必须持续地进行测定。证明：利用实际的征兆或证据证明某一行为过程是必要的。例如，在进行大宗采购之前必须预测投资回报。进行可行性证明通常需要预测趋势、制定财务计划和/或建立财务模型。在通常情况下，我们首先要证明某一项目的可行性，其次验证其交付成果。 验证：进行监视和测定以验证先前作出的决策是否正确。例如，实施配置（资产）管理的理由可能是将购置资产的费用降低 10%。这需要利用测定工具跟踪和监视项目的节约效果，以便

9、验证是否实现了 10% 的节约目标。项目完成后，就不再需要测定以进行验证了。进行监视和测定的四个主要理由引出了两个关键问题：“为什么要进行监视和测定？”和“何时停止？”若要回答上述问题，您必须确定是上述哪个原因导致需要进行或停止测定和监视。在大多数情况下，我们会在无需进行测定之后再持续一段时间。在每次报告时都应考虑“我们是否仍然需要进行监视和测定？”第 3 章 - 固定的测定过程不论是为了定向、介入、证明还是验证而进行测定，您都应该遵循下列的简单过程：图 2：简单监视和测定过程这个过程可能很简单，但执行起来可能很耗费时间且有难度。现在我们详细地了解这个过程：收集：收集 主要是集中搜集监视和测定

10、 IT 服务和组件必需的原始数据。因为 IT 自动收集大量数据，所以乍看起来收集必要数据显得比较简单。不过，收集工作并非总是如此简单。例如，服务台工具主要收集服务台代理输入的数据，但是如果某个关键字段与“事故”记录无关，那就不会收集到有关该参数的数据。您应该确保已准备好数据收集的正确方法。 另外，往往需要收集比所需更多的信息，以便在测定质量很差的情况下，还有可用以进一步调查的数据。有一点是肯定的 若要成功地进行测定和监视，必须收集正确的数据。为了正确地收集数据，您必须了解为什么要收集数据 是要进行定向、介入、验证还是证明？ 处理：收集完数据后，下一步就是处理 数据，将其转换为符合要求的格式。例

11、如，您可能每周遇到 3,000 个事故，但仅希望查看每小时的总事故数，以确定需要的员工数量。在这个阶段，您可以使用报告生成技术。这通常意味着将大量数据压缩成将在后续阶段中使用的信息。 分析：数据经过处理转化为信息后，您可以分析 其结果，为下列问题寻找答案，如： 是否可看出任何趋势？ 是否需要改动？ 是否在按照计划行事？ 是否正在超目标努力？ 是否需要采取纠正措施？ 是否存在潜在的结构性问题？ 在寻找问题的答案过程中您要利用知识进行信息的处理。否则，您得到的将仅仅是一串数字，代表着毫无意义的度量标准。仅仅查看这个月的数字并毫无异议地予以接受，这还不够，即使已经达到 SLA 目标。您应该分析数字以

12、占取先机。不进行分析，您所拥有的仅是信息。进行分析后，您所拥有的将是知识。如果发现异常情况或得到很差的结果，那就要寻求改进的方法。呈现或使用：最后的阶段就是将知识呈现出来，即利用知识将其转变为智慧： 报告 监视器 行动计划 复查 评估 变更请求 新机会 可以看出，利用测定和监视可作出明智的决策，以构造性和结构化方式推进 IT 的发展。现在可以合并上面的两幅图，将“智慧分层体系”映射到“测定过程”上：图 3：合并后的智慧分层体系和简单过程此过程定义了一个用以遵循的逻辑方法，但是您如何确保可以有效地进行监视和测定？您需要具备适当的驱动因素，以确保可以生成有效的度量标准： 图 4：固定的测定过程驱动

13、因素影响您收集的数据以及此过程中的所有其他阶段。除非您要构造性地使用这些数据，收集大量数据是毫无意义的。首先确定为什么要监视某一参数。掌握此信息后，就可以确定所需的数据以及可以从哪里获取这些数据。此后您就可以按此过程操作，但要切记一开始就确定驱动因素是成功的关键。 第 4 章 - ITIL 服务支持的监视和测定既然具备了基本条件，我们就可以转而关注监视和测定，因为它们与 ITIL 服务支持流程的每一步都是相关的。对于大多数流程，ITIL 出版物都有说明需要测定和监视内容的章节。这些小节并未标准化，具有不同的标题，如“关键性能指标”、“报告和复查”以及“测定和报告”。在此我们首先将查看 ITIL

14、 推荐的每个流程。然后，在必要时将提出与这些流程尤其是与业务取向领域相关的其他建议。ITIL 出版物中所描述的许多度量标准都是指总体总数和平均数。这些数据适于快速查看，但在试图据其确定工作量和实际值的情况下可能会极易令人误解。接下来看一个例子。服务台一天内收到的事故总数为 1,960 起，而允许发生事故的上限为 2,600 起。每小时的平均事故数为 151 起，而每小时允许发生事故的上限为 200 起。从上述数据看起来一切都很正常。但客户一直对服务质量表示不满。从图 5 中可以看出客户不满意的原因：图 5：每小时的事故总数服务台的工作人员每小时能够处理的最大事故数量为 200 起，但如图所示，

15、在上午 7 点和 11 点以及下午 4 点和 5 点之间，他们每小时遇到的事故数量大于 200 起。怪不得客户不满意。这个简单的例子说明了仅看总数和平均数是不保险的，同时也说明了对总体的把握为何如此重要。 ITIL 推荐的监视和测定最佳惯例往往包括百分比，这也同样令人误解。例如，99.8 % 的系统可用性听起来很高，因为已经接近 100 %。然而，如果某个 100 人的部门连续 10 个小时不能访问系统，那么 99.8 % 的系统可用性并不能反映此情况。此额外数据大大地影响了“99.8 % 系统可用性”的含义。只有在对其进行概括或描述的情况下百分比值才有用。 记住，在我们浏览每个服务支持推荐度

16、量标准的过程中，ITIL 出版物中含有的是推荐标准而非绝对标准，并应该根据公司的特定需要进行调整。 第 5 章 - 事故管理ITIL 服务支持一书中的“事故管理”一节将监视和测定称为关键性能指标 (KPI)。关于 KPI，ITIL 表述如下： “若要判断流程的性能，应该设定定义明确且具有可测定对象的目标 也称为关键性能指标 (KPI)”。 当查看 ITIL 列举的例子时，切记这些例子是与事故管理而非服务台本身相关。对于“事故管理”流程的效果和效率，ITIL 将以下列度量标准为例： 事故总数。 事故得到解决或得以规避的平均时间（按影响代码划分）。 在约定响应时间内已处理事故所占的百分比（如通过影

17、响代码可在 SLA 中指定事故响应时间目标）。 每个事故的平均成本。 在没有求助于其他支持人员的情况下，由服务台查明的事故所占的百分比。 每个服务台工作站处理的事故数量。 无需进行访问而远程解决的事故数量和百分比。 在我们详解这些例子之前，请注意它们都是用于定向的度量标准，而不是用于验证、介入或证明的度量标准。这些度量大部分都将有预设定的对象或目标。 现在我们来仔细研究这些度量标准：事故总数。事故总数是个显而易见的度量标准，但仅在事故报告周期小于等于一天时，此标准才最有用。报告周期也可更长，例如 1 个月或 1 年。 不过，这些报告中的信息应该划分得更细致，可以显示工作流的高峰和低谷。高峰尤其

18、重要。例如，一周中的某一天可能总是比其他时候更为忙碌，或者一个在其中发生更多事故的特定月份。高峰度量标准对于安排员工和制定休假方案很有用。 可设定各个时间段的目标承受能力大小，并将目标承受能力与实际发生的事故量相比较，以便保持适当的员工人数。例如，如果每小时可以处理的事故最多为 200 起，那么实际发生的事故量接近此最大承受能力的频率是多少？如果实际发生的事故量非常接近最大承受能力，那么您就可能需要进行特殊的监视 即介入监视或证明监视。您可以确定容量何时用尽以取得主动。 业务取向指标 用于衡量与您的关键业务客户和合作伙伴之间的工作量，以便根据预计的业务增长量来预测事故的增长量。 事故得到解决或

19、得以规避的平均时间（按影响代码划分）。乍看起来，此度量标准的含义可能并不明显。现在我们来进行分析。在 ITIL 中，“平均用时”通常可以与术语“平均时间”互换。“规避方法”通常称为“解决方案”，而 ITIL 将“影响”描述为“事故对业务危险程度的测定”。对于大多数人来说，“影响”是优先级代码或严重程度代码。此度量标准着眼于事故得到解决或处理所用的平均时间（按照优先级代码或严重程度代码划分）。这是一个很有用的度量标准，因为它有助于确定员工数量的多少。例如，如果知道每个优先级/严重程度级别的平均用时，以及事故的总量，那么您就掌握了用以确定工作用时的基本数据。此外，如果可从近期历史数据中看出平均用时

20、已被改动，那么您就可以通过考虑其对事故管理员工能力的影响来计算其对工作量的影响。 业务取向指标 与您的关键客户和合作伙伴保持紧密联系，以便在业务环境发生变化需要更改影响代码的情况下可立即作出响应。 在约定响应时间内已处理事故所占的百分比（通过影响代码可在 SLA 中指定事故响应时间目标）。 这是一个重要的度量标准。 不过，在约定响应时间内未处理的事故数量更为重要。在每当事故的处理未达到所签定的 SLA 的要求时，您的客户就不会满意。应该对这些事故进行调查，以确定为何在约定的响应时间内这些事故没有得到处理，然后确定将要采取的措施，以确保减少发生此类事情的次数。 业务取向指标 业务经理应该能够跟踪

21、任何用时未达到约定服务级别的事故的进度。当解决事故用时超过约定的时间限制时，将会自动通知业务经理。另外，业务经理应该能够复查与未达到约定服务级别的事故相关的历史数据。 每个事故的平均成本。只需进行简单计算即可算出每个事故的平均成本，并可用于许多财务计算，包括费用分摊。然而，要意识到术语“平均成本”可能会令人误解。例如，重新设定口令用时可能少于一分钟，费用也最低，然而一个准时培训问题可能用时 30 分钟，导致高的多的费用。因此，您应该按事故类型计算平均成本。 业务取向指标 业务经理应该能够随时查看与其业务范围相关的事故成本。理想状态下，应该按种类（如日期或部门）来划分此数据。 在没有求助于其他支

22、持人员的情况下，由服务台查明的事故所占的百分比。这通常也称为“在第一级别解决的事故”，是大多数服务台的主要度量标准。通常，将为第一级别的解决方案设定一个目标，而某些 SLA 包括第一级别的解决方案度量标准。请注意，此度量标准不会错误地塑造服务台的行为，如通过使得查明事故比解决事故更重要进行塑造。 业务取向指标 业务经理倾向于“减少事故”而不是“在第一级别解决事故”。确保有用以通过故障管理减少事故数量的结构化方法。允许业务经理在故障管理中复查第一级别解决方案数据和事故减少情况。 每个服务台工作站处理的事故数量。这是另一个经典的服务台度量标准，用于监视和测定员工的业绩和能力。 必须尽可能高效地处理

23、事故；因此，这是复查事故管理流程性能的重要度量标准。理想状态下，每个服务台工作站发生事故的数量应该是均衡的。失去平衡表明向服务台工作站分配事故时可能出了问题，这可能会导致效率降低。（当然，除非此不平衡情况是事先安排的，例如，某些工作站可能未处在非高峰期）。意外的失衡情况必须加以调查和纠正。 业务取向指标 业务经理可能对此总体度量标准不感兴趣。然而，如果此失衡状态是由业务经理或其员工所致，那就需要与其进行协商，并与其讨论导致失衡的原因。例如，某位业务经理或其员工打进 ，指名寻找某个服务台代理，或者将与事故相关的电子邮件直接发给某个代理。 无需进行访问而远程解决的事故数量和百分比。这是一个越来越重

24、要的度量标准。由于采用了越来越多基于知识的技术，这个比例应该增高，而服务台的工作量应该减少。一定还要确保收集有关反映何种工具用于远程处理事故的数据。 业务取向指标 在远程事故解决过程的所有方面与业务经理进行合作。例如，有时可能给服务台打 会更快、更经济。业务经理应该能够复查与远程事故解决过程相关的所有活动，从进行这些活动的人员到所用时间及其费用。 如前所述，事故管理的大多数测定和监视活动都是基于定向 进行的。不过，这些度量标准中的某一些可能需要您进行验证或干预，如服务质量下降或成本升高等情况。第 6 章 - 故障管理ITIL 服务支持中的“故障管理”一节讨论从两个方面进行测定和监视：管理信息和

25、比照“服务级别”的性能优劣。首先我们来看管理信息，然后再来讨论“服务级别”。对于管理信息，请记住 ITIL 的故障管理目标：“故障管理的目标就是尽量减少由 IT 基础设施出现问题而导致的事故和故障对业务产生的负面影响，并防止与这些错误相关的事故再度出现。”“为了达到此目标，故障管理寻求找到引发事故的根源，并随后采取措施改善或纠正此情况。” 在 ITIL 中还说明了应该从被动和主动两个角度进行故障管理：“故障管理流程有被动和主动两个方面。被动方面是指作为对出现的一个或多个事故的反应来解决故障。主动故障管理是指在出现事故前预先确定并解决故障和已知错误”。用于衡量管理信息的大多数度量标准的用意并不是

26、如此直接，而是用于获取就员工工作量和 IT 质量作出决策所需的信息。如果通过主动故障管理发现了潜在的缺陷和/或进行干预以更改行动过程，这些度量标准通常用于获取进行证明所需的有用信息。ITIL 推荐用以下度量标准进行测定： 变更请求的数量上升了，而这些变更请求对服务可用性和可靠性产生的影响却被掩盖了起来。 每个公司的部门或供应商用在调查和诊断上的时间（按故障类型划分）。 查明根本故障或确认已知错误之前出现的事故的数量和影响。 故障管理中直接（被动）支持与计划支持间的比率。 未解决故障的解决方案涉及以下资源： 人员 其他已用资源 成本（相对于预算） 将要采取的行为的简短描述。 这些度量标准可能会在

27、任何特定时段内发生变动，这取决于故障的数量。引发变动的因素可能多种多样，包括实施新系统和新服务、升级系统和服务、新变更、软件的新版本以及其他更新所引起的新故障。切记其目的就是为了消除故障。对于刚刚实施 ITIL 的公司，与那些先行采用 ITIL 从而已大大减少其故障的公司相比，其信息管理度量标准通常远未达标。 我们分别介绍每个度量标准： 变更请求的数量上升了，而这些变更请求对服务可用性和可靠性产生的影响却被掩盖了起来。该度量标准的第一部分规定变更请求 (RFC) 数量的上升是由故障管理引起的，并且是是一个非常简单的指导方针。第二部分则不同，需要相似但实际不同的度量标准。该指标与影响有关，但并未

28、指明影响是自上个报告以来新 RFC 数量的上升所致（潜在影响），还是自上个报告以来实施 RFC 的结果。如果假设这两种情况都包括，那么我们需要制定用以测定自上个报告以来发生的 RFC 的合理性的标准，并制定用以验证自上个报告以来已实施的变更的标准。对于自上个报告后由于进行故障管理而导致的变更，用以对 RFC 合理性进行测定的标准所产生的影响与用以对已实施的 RFC 验证 进行测定的标准所产生的实际效果之间的差异尚未得到确定。通过此分析，我们可以更好地理解由进行故障管理而导致的变更所造成的影响。例如，如果根据服务台每天遇到的事故数量减少 50 起来证明 原始 RFC 的合理性，但经验证 服务台每

29、天遇到的事故数量只减少了 30 起，那么我们可能需要重新审视该证明 方法。 业务取向指标 客户必须接收（或者能够在线查看）已经提交的关于所有 RFC 的定期报告及更新，这些报告和更新将对有关其服务的可用性和可靠性所产生的冲突产生影响。还应该向客户征求有关 RFC 验证和证明测定标准的信息和看法。 每个公司的部门或供应商用在调查和诊断上的时间（按故障类型划分）。经理和项目经理可以利用此测定标准确定其员工查找故障根源所耗费的时间和作出的努力。对于经理和项目经理而言，这是非常重要的数据。该数据有助于他们更好地控制当前和未来的员工工作量，并可由经理和项目经理用以计算在特定 RFC 上其员工的开销。 业

30、务取向指标 业务经理需要查看此报告。切记将协助调查和诊断的业务群体成员所花费的全部时间包括在内。查明根本故障或确认已知错误之前出现的事故的数量和影响。在我们讨论该测定标准前进行一下澄清是有益的。在 ITIL 中说明了当发生新事故时应该打开故障记录。每当出现与故障相关的新事故时都应该更新故障记录，并将故障记录中“事故”字段中的数量增加 1。此数据非常重要，因为事故的数量及其影响可以改变故障的优先级。例如，对于每天仅引发两起事故并对业务影响较小的故障可能会分配较低的优先级。然而，如果事故数量突然增加到每天 50 起，那么故障的优先级也会相应增加。同样，每天仅引发两起事故但对业务影响较大的故障的优先

31、级可能会很高。 这是一个关键的报告，需要完全集成的“事故管理”和“故障管理”技术。此报告应该发送给所有的 IT 经理。 业务取向指标 对于需要了解故障数量以及故障对各自业务范围所产生影响的业务经理，此报告同样重要。业务经理需要确保他们的优先级能够得到满足。理想状态下，业务经理应该能够在线查看此报告，并且当影响其业务范围的新故障的发生次数增加时，这些业务经理应该能够迅速地得到通知。故障管理中直接（被动）支持与计划支持间的比率。下面我们将再次讨论工作量，但所用的方法更为结构化。ITIL 建议所有的支持小组都应花时间进行故障管理，以确保能够为消除故障争取足够的时间。这些时间通常耗费在为主动和被动活动

32、进行分配的过程中。不幸的是，IT 通常会以经常与推荐的模式相悖的模式来运行。例如，员工将立即处理那些除非确定根源并实施永久解决方案之后才能解决的事故。IT 经理可以利用此报告复查直接支持和计划支持的比率，以便可以改善将来的工作量计划工作。 业务取向指标 起初您可能认为业务经理对此报告不会感兴趣。然而，如果业务经理可为其支持工作得到报酬（例如通过费用分摊），那么他们可能会对此报告非常感兴趣。业务经理应该能够收到此报告，如果可能还可以在线查看此报告。未解决故障的解决方案涉及的资源包括人员、其他已用资源，以及成本（相对于预算）。所有 IT 部门都必须提交此报告，但是只有在已经为故障管理作出预算且已掌

33、握作出报告的技术时才能创建此报告。作为计划文档，此报告非常重要。 业务取向指标 因为要了解成本要素，业务经理需要查看此报告。此外，此度量标准中提到的“人员和其他资源”可能包括业务方面的人员或资源。业务经理应该能够收到此报告，而且在理想状态下还可以在线查看此报告。将要采取的行为的简短描述。因为该报告篇幅可能很长，可能需要花费很长时间才能读完，所以此报告应该作为参考，并将其发布到网上，以便用于管理访问。例如，如果有 50 个尚未处理的故障，那么将有 50 项将要采取的行为的说明。经理将会只对一或两个故障所采取的行为感兴趣，这些故障是为进行故障管理而作出的其他管理报告中所重点强调的。 业务取向指标

34、如果业务经理能够收到其他报告，那么他们还应该收到此报告，最好是在线接收。上述管理信息报告非常重要，因为从中可加深对管理工作的理解。其中还有关键计划数据，特别是支持员工工作量方面的数据。然而，要对故障管理进行控制，我们还需要 ITIL 推荐的更多详细报告，具体如下： 故障数量和错误数量的分类如下： o 状态 o 服务 o 影响 o 种类 o 用户/业务组 已查明故障的总用时。 到目前为止在尚在对其进行处理的故障上所耗费的时间。 从打开故障记录开始直到查明故障或确认“已知”错误的平均用时和最长用时，按影响代码和支持小组（包括供应商）分类。 任何临时的排除故障的行为。 尚未得到处理的故障的预期解决时

35、间。 假设您已经掌握了必要的技术，在“故障管理”流程中可能需要提交上述报告。仔细查看这些报告可能会看出： 故障和错误的数量的分类为：状态、服务、影响、种类和用户/业务组。虽然此报告只含有总体统计数字，但它很有用，因为可用其将故障分成若干不同的种类。上述种类只是推荐的分类。可随意添加您的公司特别感兴趣的种类，如技术或供应商。参加“故障管理”会议的“服务管理”人员和来自不同“支持小组”的代表会用到此报告中的数据。 业务取向指标 业务群体可能对作出这些种类中的大多数报告并不感兴趣，而“用户/业务组”却脱不了干系，并且应该将其提交给高级业务经理。可询问业务经理，以便确定他们是否还希望进行其他的分类。已

36、查明故障的总用时。在此报告中应列出自上个报告或时间段以来所有已查明的故障，列出每个已查明故障的总用时并在结尾进行摘要汇总。此数据对于将来进行工作量计划的工作很有用。 业务取向指标 应该将此报告提交给业务经理，用作可以从中查看所用时间的“异常报告”。到目前为止在尚在对其进行处理的故障上所耗费的时间。此报告与上一个报告类似，但列出的是未解决的而不是已查明故障的状态。在此报告末尾的摘要汇总中所列的是所有未解决故障的总用时。此数据对于将来进行工作量计划工作很有用。 业务取向指标 应该将此报告提交给业务经理，用作可以从中查看所用时间的“异常报告”。如果业务经理认为在解决对于业务不重要的故障上浪费了时间，

37、那就应该进行干预。从打开故障记录开始直到查明“故障”或确认“已知”错误的平均用时和最长用时，按影响代码和支持小组（包括供应商）分类。平均用时和最长用时是很有用的，但也是容易令人误解的。应用此数据时务必小心，并一定不要只根据此数据安排将来的员工工作量。 业务取向指标 与其认为这是是业务取向，不如将其视为一个警告。请注意不要让业务经理曲解此数据，并误将其视为用于衡量查明其特殊故障的平均用时。您也可不将此报告提交给业务经理。如果确实要提交报告，那就需要澄清这些是基本计划指标而不必受其约束。任何临时的排除故障的行为。临时排除故障行为 例如，经安装“修补程序”用以消除事故的行为，但其不是正式的或已批准的

38、解决方案 也称为规避方法。此报告是很重要的，因为一旦将临时解决方案用于排除故障，支持小组可能禁不住想忽略该故障，而不是继续寻求和实施已批准的长期解决方案。应该将此报告提交给所有服务和支持小组经理，以确保执行的是已批准的解决方案而不是临时行动。当提出使用新版软件的理由或使用新版软件时，此报告尤为重要。例如，使用新版软件的关键理由可能就是减少应用临时解决方案的次数。同样，利用此报告可确保所有适当的临时解决方案都会应用到新版本中。 业务取向指标 业务经理是否需要了解临时解决方案，这一点是有争议的。大多数情况下，如果修补程序有助于他们排除故障，那么他们就不会在乎进行更持久的修复。然而，如果是有偿劳动，

39、那么他们可能就会乐于对此报告进行分析。 尚未得到处理的故障的预期解决时间。在对每个故障作出的起因报告中将说明预期的解决时间。负责排除故障的人员应该能够通过复查每个尚未得到处理的故障的状态算出预期的解决用时长度。对于服务和支持小组经理，这是一个很重要的报告，因为此报告有助于他们安排短期工作量。 业务取向指标 业务经理在下列情况下才会查看此报告：他们为此将获得报酬，他们有迅速锁定故障的迫切需要，他们已经为其进行工作，或他们是 IT 计划人员。否则，业务经理通常对此报告不感兴趣。虽然您可以精确地安排 IT 其他方面的工作，但您无法为故障及其影响作出充分的准备。然而，故障管理报告有助于公司改进其对故障

40、的处理方式。第 7 章 - 变更管理与故障管理一样，ITIL 建议对变更管理分两级进行监视。第一个监视级别是管理报告，这与故障管理相同。第二个级别稍有不同，因为 ITIL 在此交叉引用了英国标准学会的出版物“IT 服务管理实施规范 (PD0005)”。第二个级别的重点是详细的“变更管理”报告。切记这两个级别“变更管理”的主要目标都是：“变更管理”流程的目标是确保利用标准化的方法和规程有效、及时地处理所有变更，以便将由变更引起的事故对服务质量的影响降到最低，并因此改进公司的日常运作。通过变更管理可获取用于监视、测定和度量标准的大量宝贵测量数据。ITIL 将重点集中在如下主要问题上： 一段时间内实

41、施的变更总数，以及按配置项 (CI)、配置类型、服务等实施的变更数。 变更原因的分类（用户请求、功能增强、业务需求、服务呼叫/事故/故障的解决、规程/培训方式的改进等）。 成功的变更数。 放弃的变更数及其原因（例如，不当的评估、不合理的结构）。 由变更引发的事故数（按故障严重程度分类）及其原因（例如，不当的评估、不合理的结构）。 变更请求数（及由此形成的任何发展趋势）。 复查过的已实施变更数，以及待查的已实施变更数（按时间分类）。 由特定原因（例如，用户需求经常发生变化、薄弱的环节、不合理的结构）引起的与某个配置项有关的变更请求/问题记录的出现几率居高不下（这特别值得关注）。 沿用先前周期（上

42、个周期，去年）内得出的数字进行比较。 拒绝的变更请求数。 已失败的变更数占变更总数的比例（按配置项和总数进行分类）。 待实施的变更数，按配置项及“变更管理”流程的阶段分类。 可以看出，推荐管理报告的范围很广，但其重点是更高级的测定而不是具体变更的细节。对以下报告都应进行深入分析： 一段时间内实施的变更总数，以及按配置项 (CI)、配置类型、服务等实施的变更数。该报告中的变更总数是直接了当，并且是按种类划分的。照这样，报告中数字变化与晴雨表相比差不了多少，因为变更数和变更种类极易受 IT 和业务变更的影响。该报告对配置（资产）管理的管理人员来说很重要，因为 ITIL 建议必须通过“变更管理”流程

43、来改变配置项（资产）的状态。您需要判断适用于自己公司的种类，但一定要注意分类不要过多。过多的分类将令人困惑，而不是传达信息。 业务取向指标 虽然几乎每种“变更管理”报告都会引起业务群体的注意，但业务经理对此种报告特别在意，尤其是在报告中按业务区域分类的情况下。 变更原因的分类（用户请求、功能增强、业务需求、服务呼叫/事故/故障的解决、规程/培训方式的改进等）。此种报告中含有有用但却是在很高级别上的数据。ITIL 中并未列举对于此种报告的推荐时段，但可根据上一个时段作出详细的报告，也可根据许多时段作出累计报告（如根据过去的 12 个月），以便预测所有可能产生的发展趋向。 业务取向指标 应该对可能

44、想要查明变更原因，特别是想要查明业务群体不想查明的变更原因的业务经理提交此种报告。 成功的变更数。虽然 ITIL 没有说明“成功”的含义，但显而易见，“成功”就是指成功实施所有变更。但对于那些已成功实施但为时已晚的变更、放弃后又重新实施的变更，或者并未引发新事故的变更又将如何衡量呢？您必须先定义对于自己公司“成功”变更的含义，以使此种报告生效。结果可能是按照每一成功变更类型对此种报告进行分类。其中只有一个总体数字的报告对于变更管理没有什么用处。 业务取向指标 这对业务经理来说是一个很重要的报告。业务经理与 IT 部门对“成功变更”可能有完全不同的看法。业务经理希望查看每一成功变更的简要概述，该

45、简述是这个报告的附件，或者可以在线查看。希望业务经理可对报告中的“成功”变更作出反应和反馈意见。 放弃的变更数及其原因（例如，不当的评估、不合理的结构）。ITIL 术语“放弃”的含义是指实施变更后又取消了变更，并恢复原来的状态。放弃变更可能有多种原因，如性能差、新的事故太多、变更给另一组件带来了负面影响、或者变更不符合变更请求 (RFC) 中所提出的要求。这是一个非常重要的报告，特别是在我们考虑到 ITIL 变更管理的目标中说明的变更必须能够用以改进公司的日常运作 的时候。显然，放弃的变更不符合这一要求。提交此种报告的同时还要提供每个放弃的变更的说明，其中包括放弃变更的理由，纠正错误所采取的措

46、施，以及为避免将来重蹈覆辙所实施的变更。 业务取向指标 这对业务经理来说又是一个重要的报告。业务经理希望查看与自己所在业务区域有关的所有放弃的变更的相关说明。许多业务经理将利用此种报告确定在其所处环境中放弃变更的开销、影响和作用。除了此种报告，当“变更管理”流程指出需要放弃的变更时，业务经理还应立即得到通知。 由变更引发的事故数（按故障严重程度分类）及其原因（例如，不当的评估、不合理的结构）。这是另一个关键度量标准，因为它直接与变更管理目标相关，也就是将与变更相关的事故 产生的影响降到最低。虽然多数事故都是由失败或放弃的变更所致，但并非所有事故的起因都是如此。许多成功的变更也会引发事故。例如，

47、对于某个变更请求，变更可能是成功的，但客户可能不了解变更的某些方面，并且可能需要即时培训。在这种情况下，是变更过程而不是变更本身失败了。 跟踪并报告由变更引发的事故是至关重要的。这意味着需要将“事故”和“变更”软件紧密地集成在一起，以便迅速、轻松地跟踪由变更引发的事故。还意味着必须培训服务台人员，以便识别与变更有关的事故。服务台人员还必须正确地记录详细信息，包括变更索引号，以进行跟踪。 这是一个极为重要的报告。这个报告中还应包括每个事故出现的原因，以便吸取教训避免将来重蹈覆辙。 业务取向指标 业务经理对这些事故的警惕性都很高，因为在大多数情况下，他们或他们的员工都引发过此类事故。除了能够收到此种报告，业务经理还必须能够随时复查与变更相关的事故，最好可在线复查。 变更请求数（及由此形成的任何发展趋势）。变更请求数是一个简单明了的度量标准。难以理解的是“由此形成的任何发展趋势”。首先，变更请求数并不总是等于将要实施的变更数。例如，某些变更请求将遭到拒绝，而多个变更请求可能会针对同一变更。其结果就是变更请求数总等于或多于已实施的变更数。在这个报告的第一部分中应列出变更请求数。如果能在报告中分别列出“接受的”和“拒绝的”变更请求数的小计就更好了。 当需要预测发展趋势时，我们将要运用知识并进行干预。在