ITIL电子书.doc

《ITIL电子书.doc》由会员分享，可在线阅读，更多相关《ITIL电子书.doc（53页珍藏版）》请在得力文库 - 分享文档赚钱的网站上搜索。

1、,ITIL 电子书以下是三本ITIL电子书章节。 这些章节阶段性地将被请您经常参观这个网站。我们将会不定期推出新的章节提供该您。推销 ITIL建立在公司中贯彻 ITIL 最佳惯例的方案 简介 第 1 章 - 公司中的关键层面 第 2 章 - 确定关键人物 第 3 章 - 不同层面，不同的期望 第 4 章 - 确定关键人物的期望 第 5 章 - 准备 ITIL 可交付成果以满足期望 第 6 章 - 准备方案，将 ITIL 推销给关键人物 ITIL 的目标探究服务管理的目标 简介 第 1 章 - 事故管理目标 第 2 章 - 故障管理目标 第 3 章 - 变更管理目标 第 4 章 - 配置管理目标

2、 第 5 章 - 发布管理目标 第 6 章 - 服务级别管理目标 第 7 章 - IT 服务的财务管理目标 第 8 章 - 容量管理目标 第 9 章 - 可用性管理目标 第 10 章 - IT 服务持续性管理目标 服务支持度量标准增强 ITIL 监视和测定框架 简介 第 1 章 - 智慧分层体系 第 2 章 - 驱动因素 第 3 章 - 固定的测定过程 第 4 章 - ITIL 服务支持的监视和测定 第 5 章 - 事故管理 第 6 章 - 故障管理 第 7 章 - 变更管理 第 8 章 - 发布管理 第 9 章 - 配置管理 推销 ITIL建立在公司中贯彻 ITIL 最佳惯例的方案简介在大多

3、数情况下，对于已受过 ITIL 培训、阅读过 ITIL 书籍或参加过 ITIL 专门讨论会的人来说，ITIL 所带来的好处是显而易见的。但是，让其他人相信 ITIL 对公司的好处却并非一件容易的事情。IT 管理者往往无法在其公司内充分宣传 ITIL。某些推广活动只能停留在一个层面而不是在公司的多个层面上进行。还有一些人只是在关键部门努力，而不是让公司的所有潜在受益者都感受到成功实施的 ITIL 的作用。重要的是知道 ITIL 的过程并不能一蹴而就，而 ITIL 也不会将低劣的 IT 基础架构在一夜之间变为最优秀的。需要时间、规划和投入才能从 ITIL 中充分受益。您和公司中其他关键人物的投入是

4、至关重要的。许多人更愿意成为 ITIL 的狂热者和信徒，而不愿向 IT 团队中其他热情较低的人充分说明 ITIL 的实际情况。ITIL 需要高度的义务感，花费时间在整个公司中培养这种义务感是实施 ITIL 的关键因素。公司的结构通常建立在三个层面上：战略层、战术层和执行层。每个层面对 IT 基础架构作用的看法和期望都有所不同。成功在于在公司内定义这些层面，确定其期望，以及说明 ITIL 是怎样帮助其达到预期效果的。在这本小册子中，您将了解到如何在内部推广 ITIL。按照其中概述的步骤进行，您将能够确定在 IT 公司内部不同层面的人所扮演的角色，并了解不同层面的关键人物的期望。您将了解到如何建立

5、 ITIL 方案，以满足整个公司的期望，以及培养采用最佳惯例的义务感。公司中的关键层面第 1 章公司的观点通常来自两个方面。一是来自经验。二是来自公司组织结构图。而这两个方面所提供的观点，都不是为在公司内部推广 ITIL 而准备有效的方案所需要的。经验常常拘泥于角色的界定、责任和在公司内部所花费的时间。在某些情况下，这可能已经足够了，但是一般而言这会使观点受到限制。公司组织结构图本应勾画出角色和职责，但却只显示了报告层次。需要重点理解的是公司内部责任的级别。所有的企业公司和很多部门都具有三个层面： 战略层。 作出决策、制定政策、设立规则和设置财务水平都是在此层进行的。 战术层。 在执行决策、落

6、实政策、实施规则以及在符合财务限制的原则下生效。 执行层。 此层面是基础层面，在这里执行实施的决策、贯彻政策、遵守规则、符合财务限制。 例如，当某个公司决定在网上销售其产品时，其决策是在战略层作出的。下一步是建立网站。这是在战术层进行的。然后，每天都要对网站进行管理、支持和维护。这是在执行层进行的。每个层面都具有不同的期望，这源于支持 IT 基础架构所需的过程。图 1. 战略层、战术层和执行层角色图 1 图解了三个层面，并显示了各个层面的构成：战略层图 1 所示的战略角色是规则制定者、专家和顾问。规则制定者设立规则并根据其经验和专家提供的信息作出决策。专家提供信息并对其分析以确保利用最为可用的

7、信息作出决策。有时可能需要附加或特定的信息，公司就会咨询顾问以获取信息和建议。如上例，战略层决定在网上销售公司的产品。由于此决策需要完整而准确的信息，所以由专家来提供决策过程所需的信息。此外，也可能会咨询顾问，这要视专家的知识水平而定。战术层图 1 所示的战术角色是监护者和协调者角色。协调者负责实施决策，而监护者负责确保按照战略层所指定的时间和预算实施该决策。注意，因为这是公司级的观点，所以并不是全部的参与者都是 IT 领域的。战术层是确保投资回报率 (ROI) 达到容许水平的关键因素，因为将来或低估的开发计划会严重影响 ROI。如上例，协调者负责管理安装在线购物资源所需的全部开发和实施活动。

8、同时，监护者对该项目进行监控以确保其符合由战略层所指定的规范和预算。执行层图 1 中还有最后两种角色，供应商和客户。供应商负责确保 IT 基础架构足以满足作为该系统受益者的客户的要求。供应商提供的服务越高效、开销越低，该公司的总体拥有开销 (TCO) 就越低。例如，如果仍无法排除某个系统由于已知的错误而引起的客户延迟故障，那么该系统的 TCO 将会很高。如上例，供应商必须确保在实施在线购物系统之后，该系统的可用性符合所签定的服务水平协议的描述。各层面的梯形结构三层概念的引人之处就在于对分公司和部门应用了与公司同样优秀的梯形结构（层内的层面）。例如，典型的 IT 部门可能具有战略层（IT 执行官

9、）、战术层（开发和项目经理），以及执行层（服务管理）。这意味着，如有必要，ITIL 可被定位在公司层面和 IT 层面。但在大多数情况下，复查 ITIL 时未必会包括公司战略层。您必须能够确定用于定位 ITIL 的恰当梯形结构。例如，如果 IT 是在某个公司后台运行的，那么企业战略层将几乎不可能对 ITIL 感兴趣。在这种情况下，企业战略层可能会让 IT 自己处理自己的问题。反过来，如果公司将 IT 视为业务优势，则企业战略层几乎肯定会对 ITIL 及其可交付成果产生感兴趣。确定恰当的梯形结构由于所有的公司都各不相同，您必须对公司进行认真考虑，然后再决定要走什么样的路线。有 5 个常量参数可以帮

10、助您从总体上了解公司对 IT 状态的看法： 财务 表明某个公司对其 IT 投资的看法。如果该公司将 IT 视为一种开销而不是投资，那么该公司很有可能会尽力减少 IT 开销，而不是在 IT 中投资以开发商业惯例。该公司越是将 IT 看作是一种投资，其战略层涉及 ITIL 相关决策的可能性就越大。相反，如果该公司将 IT 视为开销，那么其战略层将对 ITIL 几乎或根本就不感兴趣，除非是从开销的立场出发。 管理 说明某个公司对 IT 资源所有权的看法。问题是应该将管理集中在 IT 上，还是将其散布在各个地点，因为通常大规模的跨国公司才会进行 IT 管理。当 IT 管理分散化时，取得 ITIL 承诺

11、就可能会非常艰难。 所有权 表明公司如何看待 IT 外包，即，IT 资源是应该外包还是保留在公司内部。决定将 IT 保留在内部的公司的各个层面都将对 ITIL 产生兴趣。反之，决定外包 IT 的公司将可能在任何层面对 ITIL 都不感兴趣，除非公司建立了符合 ITIL 的标准，并将之作为外包商必须达到的标准之一。 创新 反映某个公司使用前沿技术或停留在已经尝试并得到信任的技术。对于此参数，ITIL 适用于整个领域。 关系 与 IT 同其客户基础之间的正式程度相关。关系越正式，公司的战略层就越会对 ITIL 感兴趣。在大多数情况下，公司从非正式走向正式的愿望恰恰就是 ITIL 的驱动因素。 可将

12、这 5 个参数整理到一个图表中，以便进行公司业务驱动力和焦点的比较。公司成员需要评定自己是将 IT 公司视为服务供应商还是业务的成功启动者。图 2 和图 3 显示了对 IT 持有不同观点的两个公司的图表。在图 2 中，公司将 IT 视为服务供应商。在图 3 中，公司将 IT 视为业务启动者。图表显示的是其中每个公司与上述 5 个参数的符合程度。从此种分析中，公司可洞悉其各个层面关键决策者对 IT 的认识。焦点锁定在业务上，IT 只是服务供应商图 2. 将 IT 视为服务供应商的公司的分析IT 是业务的成功启动者图 3. 将 IT 视为业务启动者的公司的分析通过比较图 2 和图 3 中的反映和观

13、点，从图 3 中所述的公司获得对 ITIL 的支持要比图 2 中的公司容易得多。要判断哪种观点更准确地反映了您公司的情况，请创建一个与图 2 中类似的空白表格，然后将您的公司情况填入表格中。再在自己公司内找几个人填写此表，然后对比所得的结果，这也是一个好主意。您可能需要与公司内不同层面的人进行交谈。从中您可弄清楚是否要在公司层面、分公司层面或部门层面推广 ITIL。无论作何决定都要切记您仍需效法这三个层面：战略层、战术层和执行层。确定关键人物第 2 章选定方法之后，您需要确定公司内的关键人物。这将为您勾画出结构，并帮助您确定战略层、战术层和执行层的关键人物。在开始之前，需要将图 1 作为模板创

14、建空白表格，然后在相应的框内输入梯形结构或所选定层面内的关键名称。可能您决定在不同的层面推广 ITIL。为了避免将层面与您想要推广的概念弄混，首选要预备并填写分别用于每个梯形结构或层面的表格，尽量不要让同一图表内的名称产生混淆。填完这些表格之后查看其中的关系和层面。决定哪个选择将是您的首要途径，以便在时间紧迫和资源吃紧时能够沿用回报最高的途径，这就是展开行动的小窍门。不同层面，不同的期望第 3 章如前所述，三个层面具有特定的作用和目的，以及对 ITIL 的一些不同的期望。若要成功地推广 ITIL，您必须将行动集中在这三个层面上，其中的每个层面都具有与其余各层面不相同的期望传达方式。ITIL 功

15、能战略层战术层执行层服务台 维持公司的运行 减少业务压力和摩擦 提供客户呼叫信息库 提供用以改善当前系统的信息（降低 TCO） 改善新系统和技术的实施（提高 ROI） 管理客户关系 避免对技术人员不必要的打扰，从而提高其效率（降低 TCO） 图 4. 服务台期望图 4 说明了三个层面对服务台的不同期望。从该图中可看出，战略层对于服务台具有最为高效的业务功能，以及为公司提供有关所有客户问题和投诉的数据是最感兴趣的。战术层却对有关当前系统的修改和改进的信息更为关注。此层面还对将来系统和技术的顺利与成功实施抱有期望。而执行层将服务台视为通过在首次通话时建立关系，以及解决尽可能多的问题提供前线客户服务

16、的平台。在理想状态下，需要说服的人将是那些专家，并有可能是将会把案例交给战略层的顾问们。如果 ITIL 在战略层得到认可，那就会取得更大的成功。然而，如期望模型中所示，若要将 ITIL 作为业务启动者进行推广，必须提出所有层面都认可并理解的成熟论点。重温先前决定在网上销售产品的例子，战略层决定采用 ITIL，战术层实施 ITIL，而执行层每天都要使用 ITIL。服务台是 ITIL 服务管理产品中的唯一功能。ITIL 的所有其他组件都与流程和针对每个层面的一些不同的期望相关。图 5 显示的是可应用在 ITIL 服务管理流程中的普通期望。ITIL 功能战略层战术层执行层事故管理 事故对业务关键系统

17、的影响 支持新系统和应用程序的能力（提高 ROI） 及时准确地解决事故的能力（降低 TCO） 故障管理 从业务关键系统中排除故障 所有与节约、开销和工作量相关的问题的状态（降低 TCO） 提前保护基础设施（降低 TCO） 减少事故（降低 TCO） 变更管理 实施业务驱动的变更以符合公司设置的时间表的速度 实施不会出故障的变更，从而将对公司的影响降到最低的精确度 对执行变更所需的资源的计划和管理（根据变更的类型降低 TCO 和/或提高 ROI） 变更的生命周期控制（降低 TCO） 发布管理 快速准确的发布，使对业务运营的负面影响最小化 对发布有成功实施的正确信息抱有信心（提高 ROI），计划发布

18、日程安排（提高 ROI） 在实施时支持新的发布的能力（降低 TCO） 通过以有序方式进行发布来管理员工和资源（降低 TCO） 服务级别管理 对估算开销及新业务系统的影响的当前服务级别的认识 创建可与新业务系统成功整合的新服务级别的能力（提高 ROI） 比较实际服务级别和既定级别，以便找出差异并采取适当的措施（降低 TCO） 满足将来对当前系统需求的足够能力（降低 TCO） 容量管理 对提供对于新业务系统潜在影响和开销数据的当前能力的认识 可用于实施新业务系统的足够能力（提高 ROI） 可用于实施新业务系统的足够能力（提高 ROI） 可用性管理 对当前可用性程度的足够认识，用于对满足潜在新业务可

19、用性需求过程中所涉及的影响和开销进行评估 用以实施新业务系统的足够可用性（提高 ROI） 用以满足业务系统日常需求的足够可用性 已经核对的数据，用以改善可靠性，以便 IT 员工能够继续为业务团体提供更好的服务（降低 TCO） 财务管理 对 IT 发展作出未来决策所需的准确可靠的财务信息 精确计算支持新业务系统和新商业服务的开销（提高 ROI） 可准确估算实施新业务系统和新业务服务的开销（提高 ROI） 具有充足的财务资源以满足和提高相对于客户期望的性能（降低 TCO） IT 服务持续性管理 业务可在出现危机或灾难时以既定参数持续运转 IT 可在既定时限内从危机和灾难中恢复 新业务系统在实施后做

20、了充分的持续性管理计划 新业务系统不会对当前系统的持续性计划产生负面影响 当前经过充分测试的持续性计划存在，IT 人员为了执行那些计划接受了全面培训 配置管理 IT 可完全控制其资产，并维护一个准确的数据库，包含对全部资产、位置及其关系的说明 IT 可完全控制所有的许可证，不会超出与第三方厂商或其他供应商的合同中的任何既定许可证条款的要求 IT 具有准确而完整的配置数据库，以确保公司不会购买不具备或不需要的资源 IT 具有准确而完整的配置数据库，以评估新业务系统的影响（提高了 ROI） IT具有准确而完整的配置数据库，以确保实施后新业务系统可以以最小的潜在失败风险充分实施（提高了 ROI） I

21、T 具有准确而完整的配置数据库，以确保可建立准确的影响和优先级 IT 具有准确而完整的配置数据库，以帮助服务台和服务传送过程减少花费的时间和精力，将数据库作为动态服务传送和自动化恢复等活动的资源（降低了 TCO） 图 5. 期望矩阵 ITIL 服务管理过程期望通过检查这些期望，您可以衡量出他们与您的公司的关系。理想情况下，您应当将图 5 作为模板创建自己的期望表格，然后进行适当的修改以反映您的公司的情况。在下一阶段，您可能希望添加一些与统计和财务标准相对应的利益和节约。图 5 中的期望矩阵提供了很大的灵活性，以帮助您制作报告和演示文稿。您可使用栏中的信息准备特定处理（如变更管理）的方案。精心准

22、备报告和演示文稿可以使您快速一致地建立针对特定人员或部门的观点。确定关键人物的期望第 4 章如前所述，在公司中推销 ITIL 的第一步是创建一个与图 1 类似的空白的“关键人物表”，然后输入关键人物的名字。可能需要做一些调查来确定适当的人物。请注意，图 1 中列出的一些关键人物在您的公司中可能不存在，或者也可能存在，但与您的方案无关。在安排会面之前，您应该首先准备一篇 ITIL 概述演示文稿，帮助您解释 ITIL 的适用范围和优点。您可能需要在您的演示文稿中包含一些其他公司已经证实的费用节约或提升的统计数据等等。请与 itSMF 或 Pink Elephant 联系以寻求此类信息的帮助。一旦您

23、有了关键人物的名字，下一步就是安排与他们见面。这是十分关键的一步，因为这里开始播下 ITIL 的种子，以待将来的收获。为关键人物演示方案的最佳方式是使用一些例子中的期望，并寻求对这些期望的扩展。在您安排了会面之后，下一步就是确定每个关键人物对 ITIL 处理的兴趣点所在。与您的听众讨论他们不感兴趣或只是稍稍感兴趣的程序无疑是在浪费时间。您需要向关键人物提出一个基本性的问题：“您期望从以后的 IT 处理中得到什么？”由于关键人物的时间有限，您必须尽量不要偏离话题，以确保在有限的时间内获得所需的信息。如果对方提出了新的期望，请将之填入“期望表”中。当您完成所有的会面和讨论之后，期望表中应该包含特定

24、公司的期望的完整列表与图 5 中的普通期望。准备 ITIL 可交付成果以满足期望第 5 章在确定了期望并对其进行分类之后，需要将之与 ITIL 处理的可交付成果进行比较。您可将一些期望转换为证实节约，而将其他保留为期望。问题在于判断将哪些期望归结于 ITIL 的成功实施，哪些量化为可交付成果，即，他们将交付一些正面的成果，如财务节约或性能提高。您可通过图 6 中说明的简单重复过程来区分。图 6. 量化期望以下是对每个流程组件的说明：期望矩阵这是您从面谈和其他资源整理而来的期望矩阵。在此阶段，是未经分析的项目列表。是 ITIL 可交付成果吗？判断该项目是否为 ITIL 可交付成果。可交付成果定义

25、为可计算或者可分配给项目的切实回报，如开销节约。如果是可交付成果，则下一步是“计算可交付成果”以判定利益。如果不是可交付成果，则下一步是“是 ITIL 期望吗？”，以决定该项目是否为期望。计算可交付成果。如果您判定该项目是可交付成果，则必须计算可交付成果的价值，或者，根据可用信息进行估算。当计算可交付成果时可能出现的问题是，与当前处理相比数据较差。在这种情况下，必须进行评估，或者通过数据捕捉方法学获得所需数据。计算之后，将此信息传入下一步“准备方案”。如果您无法计算值，请转到“是 ITIL 期望吗？”这一步进行进一步分析。是 ITIL 期望吗？在此步骤中，您要判断该项目是否为期望。当您无法将特

26、定价值分配给节约或可交付成果但又希望状况得到改善时，该项目即为期望。如果您断定该项目是期望，则请转至“量化期望”这一步。如果不是期望，则请转到“从矩阵中移除”这一步。量化期望？期望是可改善的，但是其改善无法精确量化。例如，期望可为“提高工作满意度”，这是无法精确计算的 ITIL 整体期望。可进行员工调查，但是调查只是主观的，而不是客观的测量手段。不过，尽管可能没有足够的硬性数据来证实可交付成果，却有可用的常用数据和前提可用于量化期望。总之，您应该分析每个期望来判断哪些可以量化。可量化的那些期望转移到“准备方案”这一步，无法量化的传递到“从矩阵中移除”这一步。准备方案。在此阶段，可整理构建计算的

27、可交付成果和量化的期望，以便准备方案。本文后面的内容将对此步骤进行详细讨论。从矩阵中移除。无法量化或计算的期望和可交付成果应从矩阵中移除或搁置以待日后使用。在实施 ITIL 时，可能有新的信息可用于进行量化和计算。不过，为了证明合理性，您应该绕过这些项目。常犯的错误是花费了过多的时间试图证明一些不可能的事。不如将精力集中在可完成的事上。 对每个期望重复以上流程，认真考虑每项期望的优点。准备方案，将 ITIL 推销给关键人物第 6 章当前，我们已经确定了关键人物，量化了期望并计算了可交付成果。现在，是时候将这些集中起来准备 ITIL 的方案了。在准备方案之前，请检查以下几点，这对准备和拿出方案大

28、有益处： 有些人喜欢读报告，还有些人喜欢看演示。 您销售的层面越高，您就必须做得越简洁。 不要花费时间准备一篇针对各个关键人物的复杂报告，因为人们不喜欢听又臭又长的报告，而其中只有一小部分与他们或他们的部门相关。 把精力集中在对他们最有影响的因素上。 通过创建标准的介绍、总结、建议等等，采用模块的方式是比较合理的选择。随后您就可以在模块中选择，以针对不同的听众作出不同的演示。您可以在报告矩阵中整理构建出量化期望和计算可交付成果的结果，如图 7 中所示。可交付成果和期望战略层战术层执行层服务台DEDEDE事故DEDEDE故障DEDEDE变更DEDEDE发布DEDEDE服务管理DEDEDE能力DE

29、DEDE可用性DEDEDE财务DEDEDE意外事故DEDEDE配置DEDEDE图 7. 报告矩阵矩阵中的纵列代表三个关键层面（战略层、战术层和执行层）。纵列中细分为可交付成果 (D) 和期望 (E)。横排代表 ITIL 科目。您可将为准备方案而收集的结果填入矩阵相应的框中。例如，如果您在服务台有 3 个可交付成果，则可将之作为项目存储在相应的框（D 或 E）中。通过以下这种矩阵方式，可以迅速整理您制作的任何报告中的内容。可交付成果和期望战略层战术层执行层服务台DEDEDE事故DEDEDE故障DEDEDE变更DEDEDE发布DEDEDE服务管理DEDEDE能力DEDEDE可用性DEDEDE财务D

30、EDEDE意外事故DEDEDE配置DEDEDE图 8. 报告矩阵示例可交付成果和期望战略层战术层执行层服务台DEDEDE事故DEDEDE故障DEDEDE变更DEDEDE发布DEDEDE服务管理DEDEDE能力DEDEDE可用性DEDEDE财务DEDEDE意外事故DEDEDE配置DEDEDE图 8. 报告矩阵示例图 8 中显示的两个示例对您整理内容的方式做了说明。在第一个示例中，从所有层面的角度来看，“服务台”报告的内容均显示在非阴影区域。在第二个示例中，战略层报告或演示的内容显示在非阴影区域。请记住，仅仅在每个框中创建电子表格或 Word 处理表格是远远不够的。需要认真地进行计划来决定版面和内

31、容。以下是显示各个可交付成果或期望的 Word 处理文档的示例格式： 主题。通常包含一位高层领导的期望或可交付成果的 简要主题。 提案人。建议或要求可交付成果或期望的 人员或部门的名称。 分析员。进行分析的人员的姓名。 期望/可交付成果描述。期望/可交付成果的简要 描述 数据来源。获取的数据或者实际数据的参考来源。 当涉及大量记录时，最好使用引用来源，而不要包括实际数据。例如，如果数据是给定月份的服务台记录，最好在引用中包括实际数据的数千条记录。 数据来源。获取的数据或者实际数据的参考来源。 操作。分析员执行的操作的描述。 结果。同时包括结果和计算或公式。 注释。包括项目，如观察、保留、建议

32、和指南。 理想情况下，这些部分中的每一个均是每个项目中的标题，主题作为最高层面的标题，而其他项目作为较低层面的标题。您可能不希望使用上面所示的所有不同的标题，但是需要全部的信息来确保每个期望或可交付成果是具有自身权限的独立文档。如果需要演示，您可生成包含相同信息的标准格式的幻灯片。一旦您完成了调查，进行了记录，并将所有可交付成果及期望存储在相应的框中，为关键人物构建一个剪裁讲究的报告就只是举手之劳了。您可以写出标准介绍并作出结论和建议的通用内容。最后一步是确定与关键人物会面的时间，以便您概述报告并进行演示。在说服他们购买时态度要坚决。为确保获得答复，您应该设定一个日期，在这天如果没有答复就意味

33、着完全接受。ITIL 的目标探究服务管理的目标简介在大多数情况下，对于已受过 ITIL 培训、阅读过 ITIL 书籍或参加过 ITIL 专门讨论会的人来说，ITIL 所带来的好处是显而易见的。但是，让其他人相信 ITIL 对公司的好处却并非一件容易的事情。ITIL 的好处非常明显。但是，采用 ITIL 最佳惯例的过程并不能一蹴而就，ITIL 也不会将低劣的 IT 基础设施在一夜之间变成最优秀的。需要花费时间、进行规划，以及做出投入才能纠正公司的惯例，以便从已经改良的运行模式中受益。将 ITIL 的目标视为揭示 ITIL 可对公司产生潜在影响的方式，似乎更为恰当，也是用于培养对贯彻由 ITIL

34、概括的某些或全部最佳惯例的约束感的极好方法。 如果能够让那些安于现状的人看到 ITIL 可以支持甚至可以提高其当前目标，那么您就能在培养对 ITIL 的约束感和拥护感的过程中发挥作用。ITIL 对 10 个服务支持和服务交付流程及功能的目标分别进行了明确描述，包括：服务支持 事故管理 故障管理 变更管理 配置管理 发布管理 服务交付 服务级别管理 财务管理 容量管理 可用性管理 持续性管理 在这本小册子中，我们将探究每个“服务支持”和“服务交付”目标的基本组成部分，并说明如何确定您的公司是否达到了这些目标。了解公司当前最佳惯例和 ITIL 最佳惯例之间的差异有助于制定实施 ITIL 的方案。本

35、小册子中所阐述的目标直接引自 ITIL 出版物。事故管理目标第 1 章ITIL 出版物“服务支持”中定义的 ITIL“事故管理”目标如下：“事故管理流程的主要目标就是尽快恢复正常的服务运作并将事故对业务运营的负面影响减到最小，从而确保可以维持服务质量和可用性的最高水平。此处将正常的服务运作定义为服务水平协议 (SLA) 所限定的服务运作。” 我们将该定义分解成几个基本组成部分，然后看看是否会找出有助于证明实施 ITIL 必要性的内容：“恢复正常的服务运作”：ITIL 将正常的服务运作定义为服务水平协议。是否具有正式的 SLA？如果有正式的 SLA，您就可以确定在 SLA 指定的许可时间限度内您

36、无法恢复服务的频率。其诀窍在于估算利用 ITIL 可降低该频率的程度。根据实际所作的评估是可用于传达在公司内实施 ITIL 的好处的交付成果。可选择新近发生的事故并将其作为案例进行分析。要努力确定是否曾经能够更快速地处理所有事故。注意寻找诸如以下所列的问题：二级支持反应迟钝、服务台分配了错误的优先级、或者服务台错误地诊断了事故的故障现象。可引用案例分析的数据来表示 ITIL 改善“事故管理”的效果。切记要将实际服务级别与您的 SLA 进行比较。 如果尚未签定 SLA，则无法确定成功的程度，因为没有基准点。在这种情况下，您需要确定一套“预期的”SLA 水平，并据其衡量实际性能，以便从 ITIL

37、获取潜在的好处。然后，可继续使用上一段中的例子，但是要根据您设置的预期服务级别而不是实际的 SLA 来对其进行衡量。（有趣的是，您没有 SLA 的事实本身就是需要 ITIL 的一个主要论据。）“尽快地”：此外，可根据已签定的 SLA 或预期的服务级别来进行衡量。其诀窍不是仅仅满足服务级别，而是要未雨绸缪。所以要寻找反映当前处理事故的速度，以及 ITIL 对预估当前服务级别的作用大小的数据。例如，与“变更管理”的集成意味着您可对失败的变更作出更快的反应，并因此可更快地恢复服务。“将对业务运营的负面影响减到最小”：这是关键的交付成果，因为如果您没有进行“配置管理”，就无法迅速确定出现故障的 IT

38、组件对业务的影响。因而，您可能要设置面向 IT 而不是业务驱动的目标。这可能会导致 IT 部门难以解决看起来对 IT 非常重要，但实际上对业务人员却不重要的事故。由于当前配备 IT 员工的限制，IT 员工集中支持业务运营是至关重要的。一定要寻找客户因其延迟而投诉、通过更合理的人员分工可防止其发生的事故。在此重提 SLA 的原因在于 SLA 中应该有关于 IT 系统和服务对业务造成影响的条款。如果没有这种关联，您可能只是推测业务影响。如果未签定 SLA，您就应该努力推导出制定业务驱动优先级和安排时间处理事故的方法。 “确保维持服务质量和可用性的最高水平”：此处的关键字是“最高”，或者换用另一种

39、ITIL 表达方式：“满足应用”。但是，“最高”意味着什么呢？您经常会听到世界级服务，但是您是否见过“世界级”的明确定义呢？您很可能没有见过，因为据我所知，这样的定义并不存在。“最高”也是如此。我将“最高”定义为以合理的开销提供适当的服务级别。如果可以做到这一点，您就可以自信地说您提供了公司所需的服务，而且公司也出得起费用。若要确定是否满足这一要求，您需要利用调查之类的方法确定服务级别并征求客户的定期反馈，以确定您是否满足既定的级别。需要与客户定期进行沟通以确定您是否提供了适当的服务级别。请不要带着情绪提问，如“我们有礼貌吗？”，而是要征求客户对您控制和处理事故的能力的看法。随后即可利用此数据

40、制定方案。 “事故管理”是 ITIL 和客户服务的关键组成部分。切记客户是利用服务来与 IT 部门进行日常沟通的。对事故控制得越好，您的客户将会越满意。所以要仔细查看 ITIL“事故管理”目标，然后思考自己是否实现了该目标。如果没有实现，就要找出失败的原因，因为这正是您证明实施 ITIL 必要性的依据。如果您拥有良好的服务台，那么“事故管理”就是极其接近实现 ITIL 目标的流程。故障管理目标第 2 章ITIL 出版物“服务支持”中定义的 ITIL“故障管理”目标如下：“故障管理”的目标就是将 IT 基础设施内的错误引起的事故和问题对业务的负面影响减到最小，并防止与这些错误相关的事故再度发生。

41、为了实现这个目标，“故障管理”力求找到引发事故的根源，然后才着手改善或纠正该情况。“故障管理”流程具有被动和主动两个方面。被动方面是作为对一个或多个事故的反应而解决问题。主动“故障管理”是指在事故发生前确定并解决问题和已知错误。 现在我们将该定义分解成几个基本组成部分，然后看看是否可以找出有助于证明实施 ITIL 必要性的内容：“将事故和问题对业务的负面影响减到最小并将事故和问题出现的频率降到最低”：这是一个争议的焦点，因为 IT 部门惯于将重心放在性能而不是质量上，放在提供支持而不是消除问题上。例如，服务台通常在首次接到电话时就设定了性能目标，如严重事故的解决，但他们并未对减少事故设定目标。

42、其结果就是服务台在首次接到电话时挑简单的事故进行处理，而不是设法减少发生潜在事故的次数。这会导致客户遭受延迟和挫折，以及致使服务台人浮于事。 确定是否有通过“故障管理”减少事故发生次数的明确目标。如果没有，则找出在过去一段时间（比如一年）内事故发生的次数减少的原因。对于“故障管理”，还没有目标事故降低率的行业标准。但是，最常引用的是 30 到 70 的比例。如果您的公司内没有可以反映“故障管理”效果的数据，那就用服务台开销的 30 作为潜在的开销节约比例。“着手改善或纠正情况”：将要采取的措施包括“解决方案”或“遍历操作”，这是服务台快速处理事故所必需的。还包括长期消除源自基础设施的错误和事件

43、的必要措施。首先，我们看一下解决方案。您的服务台和二级支持小组能否对解决方案做了明确说明？他们在确定解决方案后能否立即对其进行传达？他们是将信息输入到支持数据库中还是输入到您的知识管理信息库中？如果对上述任一问题的回答是否定的，那么您很可能并未开始着手纠正各种情况。 在许多公司中，只有在作为支持和维护客户的唯一途径时，才会应用长期解决方案。在大多数情况下，如果在接到第一次电话后问题就可以由服务台迅速解决，那就不会努力去寻找长期解决方案。（这是高度集中处理首次打进的电话的直接结果。）您是否要执行“故障管理”并调查所有事故以确定长期解决方案？如果不是，请在您的服务台数据中查找最频繁发生的事故，并估

44、算消除这些事故所带来的收益。这为您制定 ITIL“故障管理”方案提供了更多的信息。“找到引发事故的根源”：此“故障管理”的目标要素与前面的目标要素是密切相关的。真正的“故障管理”来自确定问题的根源，然后确定消除该问题的开销与从中得到的收益或节约效果相比是否划算。有时让服务台继续处理发生的事故比消除该问题的开销还要少一些。人们常会误解问题的根源。例如，根据 Help Desk Institute 的调查，在服务台遇到的所有事故的 30 到 50 都是询问如何操作。在这些事故中，技术是可行的，但缺乏知识。服务台常会创建知识库或 FAQ 以解决这些问题。问题的根源在于客户缺少培训，而这正是作出努力和

45、投入资金的方向。努力确定您当前是否正在查找所有事故/问题的根源，以及是否正在做出根除这些事故/问题的合理的业务决定。如果不是，请执行前面目标要素中所描述的操作。另外，如果您出于合理的业务原因允许在系统中出现错误，那么您务必要完整地记录该解决方案。 “防止事故再度发生”：这也与前面的目标要素密切相关，但此处的主要因素是时机的选择和如何作出决定。首先，您是否具有一个无论何时何地都应该减少事故的策略？如果没有，那您就有理由实施 ITIL“故障管理”了。其次，您何时决定减少事故？您是寻求在第一次发生事故时就将其彻底消除，还是等到事故多得无法应付时再将其彻底消除呢？如果您并未关注每个新的事故，说明您还没有进行有效的“故障管理”。 “既被动又主动”：许多公司执行被动的“故障管理”，而只有少数公司执行主动的“故障管理”。本节前面提到的每个要素都是针对被动“故障管理”的，也就是说事故发生后我们再进行处理。很少有公司进行主动的“故障管理”，如通过复查/分析事故数据库，或者复查所有的变更或新增系统，以防止因此发生事故。您是否对事故数据库进行分析以确定将减少事故发生次数的趋势？如果不是，那么您应该将其作为一个需要进行“故障管理”的理由，利用“故障管理”还会提高客户服务质量。如果您确实对变更和新增系统进行复查，那就要看一下最近出故