ITIL 的目标-探究服务管理的目标
ITIL 的目标
探究服务管理的目标
目录
• 简介
• 第 1 章 - 事故管理目标
• 第 2 章 - 故障管理目标
• 第 3 章 - 变更管理目标
• 第 4 章 - 配置管理目标
• 第 5 章 - 发布管理目标
• 第 6 章 - 服务级别管理目标
• 第 7 章 - IT 服务的财务管理目标
• 第 8 章 - 容量管理目标
• 第 9 章 - 可用性管理目标
• 第 10 章 - IT 服务持续性管理目标
简介
在大多数情况下，对于已受过 ITIL 培训、阅读过 ITIL 书籍或参加过 ITIL 专门讨论会的人来说，ITIL 所带来的好处是显而易见的。但是，让其他人相信 ITIL 对公司的好处却并非一件容易的事情。
ITIL 的好处非常明显。但是，采用 ITIL 最佳惯例的过程并不能一蹴而就，ITIL 也不会将低劣的 IT 基础设施在一夜之间变成最优秀的。需要花费时间、进行规划，以及做出投入才能纠正公司的惯例，以便从已经改良的运行模式中受益。
将 ITIL 的目标视为揭示 ITIL 可对公司产生潜在影响的方式，似乎更为恰当，也是用于培养对贯彻由 ITIL 概括的某些或全部最佳惯例的约束感的极好方法。 如果能够让那些安于现状的人看到 ITIL 可以支持甚至可以提高其当前目标，那么您就能在培养对 ITIL 的约束感和拥护感的过程中发挥作用。
ITIL 对 10 个服务支持和服务交付流程及功能的目标分别进行了明确描述，包括：
服务支持
事故管理
故障管理
变更管理
配置管理
发布管理
服务交付
服务级别管理
财务管理
容量管理
可用性管理
持续性管理
在这本小册子中，我们将探究每个“服务支持”和“服务交付”目标的基本组成部分，并说明如何确定您的公司是否达到了这些目标。了解公司当前最佳惯例和 ITIL 最佳惯例之间的差异有助于制定实施 ITIL 的方案。
本小册子中所阐述的目标直接引自 ITIL 出版物。
事故管理目标
第 1 章
ITIL 出版物“服务支持”中定义的 ITIL“事故管理”目标如下：
“‘事故管理’流程的主要目标就是尽快恢复正常的服务运作并将事故对业务运营的负面影响减到最小，从而确保可以维持服务质量和可用性的最高水平。此处将‘正常的服务运作’定义为服务水平协议 (SLA) 所限定的服务运作。”
我们将该定义分解成几个基本组成部分，然后看看是否会找出有助于证明实施 ITIL 必要性的内容：
“恢复正常的服务运作”：ITIL 将正常的服务运作定义为服务水平协议。是否具有正式的 SLA？如果有正式的 SLA，您就可以确定在 SLA 指定的许可时间限度内您无法恢复服务的频率。其诀窍在于估算利用 ITIL 可降低该频率的程度。根据实际所作的评估是可用于传达在公司内实施 ITIL 的好处的交付成果。可选择新近发生的事故并将其作为案例进行分析。要努力确定是否曾经能够更快速地处理所有事故。注意寻找诸如以下所列的问题：二级支持反应迟钝、服务台分配了错误的优先级、或者服务台错误地诊断了事故的故障现象。可引用案例分析的数据来表示 ITIL 改善“事故管理”的效果。切记要将实际服务级别与您的 SLA 进行比较。
如果尚未签定 SLA，则无法确定成功的程度，因为没有基准点。在这种情况下，您需要确定一套“预期的”SLA 水平，并据其衡量实际性能，以便从 ITIL 获取潜在的好处。然后，可继续使用上一段中的例子，但是要根据您设置的预期服务级别而不是实际的 SLA 来对其进行衡量。（有趣的是，您没有 SLA 的事实本身就是需要 ITIL 的一个主要论据。）
“尽快地”：此外，可根据已签定的 SLA 或预期的服务级别来进行衡量。其诀窍不是仅仅满足服务级别，而是要未雨绸缪。所以要寻找反映当前处理事故的速度，以及 ITIL 对预估当前服务级别的作用大小的数据。例如，与“变更管理”的集成意味着您可对失败的变更作出更快的反应，并因此可更快地恢复服务。
“将对业务运营的负面影响减到最小”：这是关键的交付成果，因为如果您没有进行“配置管理”，就无法迅速确定出现故障的 IT 组件对业务的影响。因而，您可能要设置面向 IT 而不是业务驱动的目标。这可能会导致 IT 部门难以解决看起来对 IT 非常重要，但实际上对业务人员却不重要的事故。由于当前配备 IT 员工的限制，IT 员工集中支持业务运营是至关重要的。一定要寻找客户因其延迟而投诉、通过更合理的人员分工可防止其发生的事故。在此重提 SLA 的原因在于 SLA 中应该有关于 IT 系统和服务对业务造成影响的条款。如果没有这种关联，您可能只是推测业务影响。如果未签定 SLA，您就应该努力推导出制定业务驱动优先级和安排时间处理事故的方法。
“确保维持服务质量和可用性的最高水平”：此处的关键字是“最高”，或者换用另一种 ITIL 表达方式：“满足应用”。但是，“最高”意味着什么呢？您经常会听到世界级服务，但是您是否见过“世界级”的明确定义呢？您很可能没有见过，因为据我所知，这样的定义并不存在。“最高”也是如此。我将“最高”定义为以合理的开销提供适当的服务级别。如果可以做到这一点，您就可以自信地说您提供了公司所需的服务，而且公司也出得起费用。若要确定是否满足这一要求，您需要利用调查之类的方法确定服务级别并征求客户的定期反馈，以确定您是否满足既定的级别。需要与客户定期进行沟通以确定您是否提供了适当的服务级别。请不要带着情绪提问，如“我们有礼貌吗？”，而是要征求客户对您控制和处理事故的能力的看法。随后即可利用此数据制定方案。
“事故管理”是 ITIL 和客户服务的关键组成部分。切记客户是利用服务来与 IT 部门进行日常沟通的。对事故控制得越好，您的客户将会越满意。所以要仔细查看 ITIL“事故管理”目标，然后思考自己是否实现了该目标。如果没有实现，就要找出失败的原因，因为这正是您证明实施 ITIL 必要性的依据。如果您拥有良好的服务台，那么“事故管理”就是极其接近实现 ITIL 目标的流程。
故障管理目标
第 2 章
ITIL 出版物“服务支持”中定义的 ITIL“故障管理”目标如下：
“故障管理”的目标就是将 IT 基础设施内的错误引起的事故和问题对业务的负面影响减到最小，并防止与这些错误相关的事故再度发生。为了实现这个目标，“故障管理”力求找到引发事故的根源，然后才着手改善或纠正该情况。
“故障管理”流程具有被动和主动两个方面。被动方面是作为对一个或多个事故的反应而解决问题。主动“故障管理”是指在事故发生前确定并解决问题和已知错误。
现在我们将该定义分解成几个基本组成部分，然后看看是否可以找出有助于证明实施 ITIL 必要性的内容：
“将事故和问题对业务的负面影响减到最小并将事故和问题出现的频率降到最低”：这是一个争议的焦点，因为 IT 部门惯于将重心放在性能而不是质量上，放在提供支持而不是消除问题上。例如，服务台通常在首次接到电话时就设定了性能目标，如严重事故的解决，但他们并未对减少事故设定目标。其结果就是服务台在首次接到电话时挑简单的事故进行处理，而不是设法减少发生潜在事故的次数。这会导致客户遭受延迟和挫折，以及致使服务台人浮于事。
确定是否有通过“故障管理”减少事故发生次数的明确目标。如果没有，则找出在过去一段时间（比如一年）内事故发生的次数减少的原因。对于“故障管理”，还没有目标事故降低率的行业标准。但是，最常引用的是 30％ 到 70％ 的比例。如果您的公司内没有可以反映“故障管理”效果的数据，那就用服务台开销的 30％ 作为潜在的开销节约比例。
“着手改善或纠正情况”：将要采取的措施包括“解决方案”或“遍历操作”，这是服务台快速处理事故所必需的。还包括长期消除源自基础设施的错误和事件的必要措施。首先，我们看一下解决方案。您的服务台和二级支持小组能否对解决方案做了明确说明？他们在确定解决方案后能否立即对其进行传达？他们是将信息输入到支持数据库中还是输入到您的知识管理信息库中？如果对上述任一问题的回答是否定的，那么您很可能并未开始着手纠正各种情况。
在许多公司中，只有在作为支持和维护客户的唯一途径时，才会应用长期解决方案。在大多数情况下，如果在接到第一次电话后问题就可以由服务台迅速解决，那就不会努力去寻找长期解决方案。（这是高度集中处理首次打进的电话的直接结果。）您是否要执行“故障管理”并调查所有事故以确定长期解决方案？如果不是，请在您的服务台数据中查找最频繁发生的事故，并估算消除这些事故所带来的收益。这为您制定 ITIL“故障管理”方案提供了更多的信息。
“找到引发事故的根源”：此“故障管理”的目标要素与前面的目标要素是密切相关的。真正的“故障管理”来自确定问题的根源，然后确定消除该问题的开销与从中得到的收益或节约效果相比是否划算。有时让服务台继续处理发生的事故比消除该问题的开销还要少一些。人们常会误解问题的根源。例如，根据 Help Desk Institute 的调查，在服务台遇到的所有事故的 30％ 到 50％ 都是询问如何操作。在这些事故中，技术是可行的，但缺乏知识。服务台常会创建知识库或 FAQ 以解决这些问题。问题的根源在于客户缺少培训，而这正是作出努力和投入资金的方向。
努力确定您当前是否正在查找所有事故/问题的根源，以及是否正在做出根除这些事故/问题的合理的业务决定。如果不是，请执行前面目标要素中所描述的操作。另外，如果您出于合理的业务原因允许在系统中出现错误，那么您务必要完整地记录该解决方案。
“防止事故再度发生”：这也与前面的目标要素密切相关，但此处的主要因素是时机的选择和如何作出决定。首先，您是否具有一个无论何时何地都应该减少事故的策略？如果没有，那您就有理由实施 ITIL“故障管理”了。其次，您何时决定减少事故？您是寻求在第一次发生事故时就将其彻底消除，还是等到事故多得无法应付时再将其彻底消除呢？如果您并未关注每个新的事故，说明您还没有进行有效的“故障管理”。
“既被动又主动”：许多公司执行被动的“故障管理”，而只有少数公司执行主动的“故障管理”。本节前面提到的每个要素都是针对被动“故障管理”的，也就是说事故发生后我们再进行处理。很少有公司进行主动的“故障管理”，如通过复查/分析事故数据库，或者复查所有的变更或新增系统，以防止因此发生事故。您是否对事故数据库进行分析以确定将减少事故发生次数的趋势？如果不是，那么您应该将其作为一个需要进行“故障管理”的理由，利用“故障管理”还会提高客户服务质量。如果您确实对变更和新增系统进行复查，那就要看一下最近出故障的或者引发新事故的变更/新增系统。然后，通过估算在得到成功执行的情况下可以节省多少时间和金钱来得出支持的证据。
“故障管理”在大多数 IT 部门中一般不会得到重视，而可从中获得最高回报的 ITIL 作用却会受到重视。所以要将此处所描述的目标看作是冷酷无情的，并制定一个有力的“故障管理”方案。
变更管理目标
第 3 章
如果您并不熟悉 ITIL“变更管理”，那么您需要了解 ITIL 下的“变更管理”和“变更控制”之间的差异。只有了解了这一点，您才能为实施 ITIL“变更管理”的必要性提出有力的论据。
ITIL 将“变更控制”定义为：
确保所有变更都可得到控制的规程，其中包括变更的提交控制、分析控制、决策控制、批准控制、实施控制和实施后控制。
ITIL 对“变更管理”的描述却大相径庭：
以可控的方式控制对基础设施或服务的任何方面的变更，从而使得实施已经批准的变更产生最低限度的影响。
“变更管理”和“变更控制”的主要区别在于各自定义的开头。“变更控制”是一种规程，而“变更管理”是一个整体流程。换言之，在“变更管理”流程中可能存在着很多受控的变更。每个变更都需要有效的“变更控制”，而“变更管理”流程监视所有的变更。
在没有有效的“变更管理”的情况下也有可能进行良好的“变更控制”，但依然会出现故障。例如，两个不同的 IT 团队都各自对相同的服务器进行单独的改动。两个团队都非常有效地控制着各自的变更，但在实施时遇到了问题，因为这两个团队之间没有进行任何沟通，而他们所做的变更也是相左的。对于“变更管理”，应该注意两个团队即将改动同一服务器的状态的情况，而且应该让这两个团队进行协作以消除变更引起的故障。通过“变更管理”可同时控制很多受控变更的生命周期和状态，因为“变更控制”是“变更管理”的一个组成部分。
这并不奇怪，因为“变更管理”是具体的，而 ITIL 目标是综合的：
“变更管理”流程的目标是确保利用标准化的方法和规程有效、及时地处理所有变更，以便将由变更引起的事故对服务质量的影响减到最小，并因此改进公司的日常运作
若要对“变更请求”作出适当的回应，需要利用对风险和业务持续性、变更冲突、资源要求和变更批准等进行评估的、经过深思熟虑的方法。这种经过深思熟虑的方法对于维持变更需求与变更冲突之间适当的平衡是必要的。
当发生变更时，为了能够进行平稳的过渡，“变更管理”流程对其具有很高的能见度和畅通的沟通渠道尤为重要。
我们将这个相当冗长的目标分解成几个基本组成部分，然后看看是否会找出有助于证明实施 ITIL 必要性的内容：
“将与变更相关的事故对服务质量的影响减到最小”： 这句明确的话意味着“变更管理”肩负着重任。问题是：是否由于失败的变更，或者已起作用但在其他 IT 基础设施组件中引发了新事故或新问题的变更，而遭遇了一些新的事故和问题？例如，虽然成功地添加了一个新软件应用程序，但是内存不足，所以性能下降了。如果您对这个问题的答案并不确定，那就分析您的“事件和问题数据库”，以便看看是否存在表明失败的变更的证据。利用此数据可说明您未达到“变更管理”的目标。一个好的方法就是让服务台员工举出例子。如果变更失败，那么他们只有提供帮助。
“有效、及时地处理所有变更”：下面我们将讨论变更的进度安排和时间选择。如果您将“变更请求”的注册和管理集中到一点进行，那么您应该检查请求的交叉部分，以确定滞后或延迟的变更所占的比例。
这将提供用于确定是否满足该“变更管理”目标组成部分的数据。如果目前“变更管理”尚未就绪，那么量化该项目可能会很困难。通过会见客户以征求他们对于此时变更管理效率的意见，或者您可以收集和分析当前在不同 IT 位置处于活动状态的变更请求，您可能能够执行某些侦探性的工作。不管是如何得到数据的，这都是一个重要的主题，因为变更进度安排和时间选择是“变更管理”成功的关键。
未将“变更请求”的注册和管理集中到一点进行，这本来就是实施“变更管理”的理由，因为如果您不知道正在改动哪个基础设施项目，或者不知道何时对其进行改动，那就无法有效地控制变更。
“确保所用的是标准化的方法和规程”：所有的 IT 部门都惯于用其自己的方法将变更的生命周期控制在其范围之内。但是，如果不同的部门共同进行同一变更，这是无法接受的。最为苛刻的变更要求之一就是不但要成功地进行变更，而且还要确保变更周围的环境能够适应。例如，对网络浏览器的更改可能需要将基础设施组件的软件和内存进行升级，并进行用户培训。如果所有这些项目在发生变更的时候均未完成，那么该变更将会失败或引起问题。这就是标准化方法和规程至关重要的原因所在。这是一个易于核查的目标，因为您不是可利用已记录在案和已实施的标准化方法或规程就是束手无策。如果未使用标准化的方法和规程，您应该意识到如果不同的团队进行同一变更时没有遵循标准化的方法和规程，失败的可能性就会高很多。您可能能够利用失败变更的数据来证明这一点。
“一种用于对风险和业务持续性进行评估的、经过深思熟虑的方法”：此处需要注意对业务的影响是牵一发而动全身。所有对 IT 基础设施进行变更的决定都必须集中进行，并且受影响的各方都应该群策群力。在大多数情况下，变更的投资回报率 (ROI) 并不准确，因为其中不包括其他 IT 团队为该变更所付出的努力带来的回报。如果 IT 部门不知道变更的实际开销，那么如何进行预算和投资呢？
如果 IT 部门不知道有多少员工在进行变更工作，那么如何确定必要的员工数量呢？如果 IT 部门没有与其他部门共同对变更的影响进行评估，那么将会有更多的电话打到服务台。目前，如果变更失败了，那么即使是最简单的变更也会对公司产生严重影响，而在某些情况下这会直接影响到利润。所以，对于该目标，不是提出证明失败的证据，而是要说出使这些项目出现问题的潜在业务影响。
“维持变更需求和变更冲突之间适当的平衡”：在源于变更的潜在冲突、收益和交付成果与实施该变更的开销之间必然有一种平衡。例如，可能客户因为某个要求解决问题的“变更请求”而每天向服务台打三次电话却对业务影响很小。最初，听起来实施该变更是一个不错的主意。但如果要实施该变更需要花费 $200,000 该如何处理呢？这是一个夸张的例子，但它说明了在判断冲突和开销的平衡时要慎重行事。这是一个难以实现的目标，因为难以获取用于证明您观点的硬数据。您必须再次考虑集中管理“变更请求”。利用这种方式您可以确定实际开销，因为您可以从进行该变更工作的所有团队那里收集信息，然后可从 IT 部门和客户的不同群体的共同角度对该变更进行复查。
“具有高能见度和畅通的沟通渠道”：用简单的形式定期征求所有感兴趣的各方（包括 IT 和业务部门）对变更状态的反馈。这是一个易于评估的目标，因为您或者征求反馈或者不征求反馈。如果不征求反馈，那么这就是需要实施“变更管理”的理由。
“变更管理”是公司内 IT 部门成功的关键之一。目前，IT 是业务流程中的重要部分，并已被完全集成到普通业务活动的结构之中。失败的变更、滞后的变更、超预算的变更、资源不足的变更、传达不畅的变更、孤立的变更以及处理不当的变更都是无法容忍的。此外，一定要记住“变更控制”和“变更管理”之间的差异。
配置管理目标
第 4 章
许多 ITIL 专家都认为“配置管理”是 ITIL 的“太阳”，是其他 ITIL“行星”围绕的中心。这是一个贴切的比喻，因为所有其他的 ITIL 流程确实都与“配置管理”密切相关。因此，达到“配置管理”的目标是成功实施 ITIL 的基础。您是否达到了 ITIL“配置管理”目标？接下来我们看看这些目标：
“配置管理”通过识别、控制、维护和验证现有“配置对象”(CI) 的版本来制定基础设施或服务的逻辑模型。
“配置管理”的目标是：
• 对公司内部的所有 IT 资产和配置及其服务作出说明
• 提供有关配置及其记录的准确信息以支持 所有其他的“服务管理”流程
• 为“事故管理”、“故障管理”、“变更管理”和“发布管理”提供坚实的 基础
• 对照基础设施验证配置记录并纠正任何异常情况
我们将“配置管理”的目标分解成几个基本组成部分，然后看看是否会找出有助于证明实施 ITIL 必要性的内容：
“‘配置管理’通过识别、控制、维护和验证现有‘配置对象’(CI) 的版本来制定基础设施或服务的逻辑模型”：
在我们审视该要素之前，需要理解“配置对象”的 ITIL 定义：
它是基础设施的组件，或是一个对象，处于（或者将处于）“配置管理”的控制之下。各种 CI 的复杂性、大小和类型可能有很大的差异，可能是一个完整的系统（包括所有硬件、软件和文档），也可能是一个模块或较小的硬件组件。
“配置对象”是一个基础设施组件，必须能够提供服务、系统和应用程序，而这些又是为 IT 客户提供既定的服务所必需的。可随意选择 CI 的复杂度。例如，您可将工作站作为一个 CI，或者可将工作站分成若干个组件（处理器、键盘、鼠标和屏幕），然后将其中每个组件作为一个 CI。“配置管理”主要管理各个 CI 之间的关系，也就是说通过查看一个 CI，您就可以看到该 CI 与处理特定系统或服务所必需的其他 CI 之间的关系。服务台可以利用 CI 之间的关系建立影响和确定优先级。请注意，“资产管理”维护有关高于特定价值的资产、其业务部门及其位置的详细信息，然而“配置管理”还维护“资产管理”未涉及的资产之间的关系。
在尝试评估是否满足该目标要素的要求时遇到的第一个问题就是确定您是否具有反映 CI 或资产之间关系的数据库。如果没有，您如何确定影响呢？您将如何从远程灾难中进行恢复呢？首先，看一下您是否有中央“资产数据库”。如果有，请看一下它是否可反映出各个对象之间的关系并为制定方案做出相应的准备。您可能发现您并没有中央“资产数据库”，这本身就是一个强有力的理由。
有关该目标要素的特定议题包括：识别、控制、维护和验证“配置对象”的版本。在此您需要确定是否有用以管理 CI 从酝酿到终止的生命周期的标准方法。如果有，请核查它是否涵盖了所有 CI 并得到了很好的维护。数据不准确的一种迹象是服务台持续接到客户打来的有关与“配置/资产数据库”相关的组件并不存在的电话。例如，客户报告“我的扫描仪不能用了”。服务台的答复是“这并不奇怪，因为根据我们的记录，您根本就没有扫描仪”。（虽然有点言不由衷，但这确实说明了问题。）总之要核查的两件事情是您是否具备识别和控制 CI 的方法和规程，以及您是否具备维护这些 CI 状态的方法和规程。根据您得到的数据提出论据。
“对公司内部的所有 IT 资产和配置及其服务作出说明”：这是一个重要目标，因为并不是所有 CI 看上去都是资产。例如，内部编写的程序、规程记录以及人员通常不会被视为资产，但是它们都是“配置对象”。该目标要素意味着应该进行核查以确保所有可能的 CI 都应该包括在“配置管理数据库 (CMDB)”中。确定是否满足该要素的要求非常简单。是否进行了核查？当然，如果您没有 CMDB，的确也不会有什么内容可供核查。
“提供有关配置及其记录的准确信息以支持所有其他‘服务管理’流程”：假定您 CMDB 中的数据是准确的，问题是：如何使其可用于其他“服务管理”流程呢？将“服务管理”流程集成在一起是至关重要的。例如，当服务台在事故记录中输入数据时，CI 数据库能否自动地添加有关配置和文档信息的记录？或者，服务台代理是否必须手动输入该信息？或者更糟糕，由于无法得到数据而根本就无法输入？若要检查您是否满足该目标要素的要求，可查看其他“服务管理”流程，并确定其中是否存在 CMDB 数据可用但未被使用的区域。当然，如果您没有“配置数据库”，那就不会有什么内容可供核查。
“为‘事故管理’、‘故障管理’、‘变更管理’和‘发布管理’提供坚实的基础”：“事故管理”、“故障管理”和“变更管理”都是从 CMDB 中获取信息的流程，更为重要的是，它们用其作出决策。利用准确完整的 CMDB 信息可为确定问题或事件的影响作出精明的决定。这使得对潜在变更的开销所作的计算更为准确。此外，还提高了逐步升级的准确性。
关于“服务管理”中知识工具的议题有很多。可能最重要的知识就是对于您拥有哪些资产、资产的位置及其相互关系的知识；也就是 CMDB 中的信息。但 CMDB 的重要性常被忽视。该目标要素的重点在于 CI 中包含的属性。只有一个 CMDB 还不够好。 必须获取每个 CI 中的数据，这些数据对于其他“服务管理”流程是有意义的信息。查看 CI 的属性或字段以确定数据中是否含有对其他“服务管理”流程有用的信息。您将需要询问进行其他服务管理的人是否已经获得他们所需的数据，以及如果他们尚未获得所需的数据，还需要什么其他数据。您可借此确定是否已满足该目标要素的要求。当然，如果您没有 CMDB，的确也不会有什么可供核查的内容。
“对照基础设施验证配置记录并纠正任何异常情况”：如前所述，“配置管理”为所有其他流程提供信息和数据。该要素与前面的要素有关，除了该要素不要求 CMDB 中含有全部 CI 的信息，而是要求 CI 的内容是准确的。与前面的要素一样，验证是否满足该要素的要求非常简单，也就是您是否进行了核查？当然，如果您没有 CMDB，的确也不会有什么可供核查的内容。
到目前为止，“当然，如果您没有…，的确也不会有什么可供核查的内容”已出现许多次了。但是，该消息经常会被忽视。据估计，在 Y2K 上支出的收入的 70％ 只是用在跟踪资产及其关系上了。如果您没有一个集中、准确、完整的 CMDB，您就应该立即提高警惕。
发布管理目标
第 5 章
“发布管理”通常被看作是“变更管理”的一部分，但实际上它是一个重要的 ITIL 要素，因为遭受失败的常常是变更的发布，而不是变更本身。有关这个主题的 ITIL 目标是全面而精确的：
• 计划并监视软件和相关硬件成功的首次公开展示
• 设计和实施用于 IT 系统变更的发布和安装的有效规程
• 确保正在对其进行改动的硬件和软件是可跟踪的、安全的，而且已安装的版本都是正确的、经过授权和经过测试
• 在计划和首次展示新发布的过程中传达并管理客户的期望
• 通过与“变更管理”达成一致来确定发布的准确内容和首次公开展示计划
• 利用‘配置管理’和‘变更管理’的控制流程将新的软件发布或硬件添加到有效的环境中 － 发布应该受‘变更管理’控制，并可含有硬件、软件、固件和文档 CI
• 确保将所有软件的主副本保存在“留存软件库 (DSL)”中，并确保对 “配置管理数据库 (CMDB)” 进行更新
• 利用“配置管理”的服务确保所有正在对其进行首次公开展示或改动的硬件是安全的且是可跟踪的。
通常 8 个要素意味着这是一个复杂的目标，但是在这种情况下精确性非常重要，因为“发布管理”需要慎重行事。我们分别讨论每个要素：
“计划并监视软件和相关硬件成功的首次公开展示”：这里的关键字是“计划”和“监视”。您是否有用以管理软件和硬件的首次公开展示的明确计划？您是否确定在首次公开展示过程中定期的反馈已发送给所有感兴趣的各方？您是否将标准的计划/项目作为模板？如果对所有这些问题的回答都是肯定的，那么说明您已经满足该要素的要求。如果对这些问题不能作出肯定的回答，那么说明您很可能面临的失败将会证明您尚未满足该要素的要求。如果您不能确定是否是按计划行事，那么很可能就是未按计划行事。如果仍持怀疑态度，那就询问诸如服务台这样的关键团队，询问他们是否参与了首次公开展示、是否解答了关于首次公开展示的问题或者是否为首次公开展示发出通知。
“设计和实施用于 IT 系统变更的发布和安装的有效规程”：有效的规程通常被称为“清单”或“操作说明”。这些规程可用于确保流程中所必需的操作都得以执行，从而达到了预定的服务级别和标准。需要不断地对这些规程进行调整和纠正以确保最高的精确度。例如，在测试一个新工作站时，您可能要按照一个其中有十条说明的清单行事。但是，因为服务台不断接到有关新工作站问题的电话，所以您可再向清单中添加一条说明，以便将该问题根除。您是否有有效的规程并持续地监视其有效性？当它们看起来不够充分时，您是否会升级这些规程？若要满足该要素的要求，您应该有效地管理这些规程。如果没有进行有效管理，请查看服务台记录以验证这些规程是否就绪，那么您可能会遭遇更少的事故。
“设计和实施用于 IT “确保正在对其进行改动的每个硬件和软件是可跟踪的、安全的，而且已安装的版本都是正确的、经过授权和经过测试的”：该要素中隐含着许可的问题。对于符合许可协议的条款，您有多大把握呢？该要素表明对象必须是可跟踪的、安全的，而且只能安装正确的、经过授权和经过测试的版本。要满足可跟踪的要求，对象必须在 CMDB 中具有适当的 CI。要满足安全的要求，必须对其设定恰当的访问级别，对于软件而言，要将其副本保存在安全的位置。要满足正确的要求，必须在生产环境中移除对象的冗余版本。要满足经过授权的要求，该对象必须具有正确的签名级别，并且符合许可条款和条件。要满足经过测试的要求，必须按预定的标准对其进行单独测试。诸如此类的要求还有好多。您的公司与之相比差距有多大？如果尚未做好这些事情，那么这就是您的理由。如果根本就没做这些工作，或者只有部分 IT 人员做了，那就要在服务台求证。 有时直接的挑战可以奏效，例如让某人对公司完全符合许可条款和条件进行书面确认。
“在计划和首次展示新发布的过程中沟通并管理客户的期望”：这是一个非常易于核查的要素。首先，沟通是否按计划进行？其次，沟通是否令客户满意？如果您在计划和规程中考虑了沟通，那么您就满足该要素第一部分的要求。第二部分是，请不要让计划成为一纸空文。询问客户是否在看到返回的信息后感到很愉快，以及是否由于期望得到满足而感到满意。从此信息中您可以确定是否满足该目标要素的要求。
“通过与“变更管理”达成一致确定该发布的准确内容和首次公开展示计划”：如前所述，ITIL 的成功在于各个流程的集成。在此您必须复查“变更管理”和“发布管理”之间的关系。首次公开展示计划中包括“变更管理”是非常重要的。这就能够安排其他变更的进度，以致它们不会发生冲突或导致首次公开展示的延期。您是否在“变更管理”的控制下制定首次公开展示计划以得到一些意见？如果不是，那么您将会遭遇变更冲突和潜在的延迟，并且不会满足该要素的要求。
“利用‘配置管理’和‘变更管理’的控制流程将新的软件发布或硬件添加到有效的环境中 － 发布应该受“变更管理”控制，并可含有硬件、软件、固件和文档 CI”：更高度地集成。请注意，该要素表明一个发布可含有硬件、软件、固件和文档。若要确保首次公开展示能够成功，CMDB 必须在首次公开展示的过程中得到更新，以反映所有 CI 的当前状态，而“变更管理”是管理 CI 状态的工具。这就是将“配置管理”和“变更管理”完全融合到发布和首次公开展示过程中的关键所在。如果已将“配置管理”和“变更管理”完全融合到发布和首次公开展示过程中，那么您就已经满足该要素的要求了。如果没有这样做，那么您就必须提出一个明确的、充分的理由，证实将“配置管理”和“变更管理”完全融合到发布和首次公开展示过程中的重要性。此外，服务台记录可用以证明这一点。
“确保将所有软件的主副本保存在‘留存软件库 (DSL)’中，并确保对‘配置管理数据库 (CMDB)’进行更新”：保护软件主副本的要求始终与 IT 相伴，但是在大多数情况下我们并未对其进行有效的保护。需要核查是否所有软件主副本都被保存在安全的位置，而且只有副本用于生产环境中。这应该很容易查明。
“利用‘配置管理’确保所有正在对其进行首次公开展示或改动的硬件是安全的且是可跟踪的”：该最终要素可确保 CMDB 可随时反映所有 CI 的当前状态，并可确保 CMDB 中列出的所有对象都是实际存在的。通过审核或盘库即可轻松地对其进行核查，以便将 CMDB 中所列的硬件与某特定位置的实际硬件进行比较。如果所有核查的结果都是正确无误，那就表明您的工作无懈可击。如果查出了问题，那就表明您并未满足该要素的要求，并且在受到正式审核时可能会露出破绽。
随着 IT 在业务结构和流程中逐步的渗透，“发布管理”已随之成为一个越来越重要的关键流程。不要认为“发布管理”很少发生。“发布管理”是持久的工作。如果我们必须确保公司会从 IT 将来的发展中充分受益，那么我们就必须对发布进行有效地管理。
服务级别管理目标
第 6 章
“服务级别管理 (SLM)”是 ITIL 框架中的关键流程，因为它定义其他流程必须努力交付的服务级别。SLM 主要涉及为“服务管理”和客户群体设定目标。ITIL 阐述的 SLM 的目标如下：
SLM 的目标是通过持续的循环（认同、监视和报告 IT 服务成果）以及用于根除符合业务或开销理由的不良服务的行为指导来维护和改进 IT 服务质量。通过这些方法，可以在 IT 与其客户之间建立良好的关系。
这并不是冗长的目标，但是每个词都有具体的含义。通常情况下，业务群体对 IT 性能的期望和渴望是他们对服务和支持质量的理解，而不是可供他们使用的技术解决方案的范围。将期望值作为标准是很不可取的。根据实际对这些期望值进行调整非常重要，这也正是这些目标的意义所在。接下来我们看看这些目标的各个组成部分。
“SLM 是维护… IT 服务质量”：满足是我们所有人的敌人，尤其是对于维护质量来说更是如此。因此，真正的胜利者永远也不会满足。但是，在我们开始改进 IT 服务质量之前，我们必须确保我们已经拥有了流程、工作惯例和衡量标准，这有助于确保维护我们与客户达成的服务级别。这就是该要素所说明的内容。您是否定期与您的客户进行沟通以核查您是否正在维护所承诺的服务级别？您是否认为设定服务目标具有挑战性？您是否经常调查您的客户？如果不是，您可能没有达到服务质量的级别。下面是若干年前的一个经典方案。那时，服务器开始作为新的技术成为该时期的主导。许多公司开始忽视由旧的主机技术提供的服务，而将重点集中在服务器上。结果使客户很不满意，危及到关键业务系统以及代价非常昂贵的两千年问题。请始终将维护既定的服务级别摆在您的议程的首位。
“SLM 是… 改进 IT 服务质量”：请注意，该要素不是在讨论新的技术，而是在讨论当前的技术。我们必须不断提高而不是保持停滞。通常情况下，IT 先设定很容易达到的目标，然后每个月达到这些目标后都会进行自我庆祝。不过，如果那时这些目标并没有 100% 实现，也就不会得到满意的庆祝。在很多情况下，因为经常达到目标，就没有人真正去关心它，IT 人员只是走一下形式来制定并发布衡量标准。如果您要满足该目标要素的要求，就必须具有明确的策略声明以提高质量级别。
“通过持续的循环（认同、监视和报告 IT 服务成果）”：认同、监视和报告。该要素是清楚得不能再清楚、简单得不能再简单了。经常与您的客户进行沟通了解他们的技术要求以达到他们的业务目标。通常情况下，只有在 IT 及其客户进行沟通时才会出现问题。这就是为什么很多公司内存在那么多冲突的原因。基于面对面的关系经常会失败。这就是该要素之所以重要的原因。
您无法管理期望，但是您可以管理实际情况。将认同、监视和报告形式化以消除所有混乱并为关系提供一个具体的基础是非常重要的。要做到这一点，ITIL 建议您将服务和默认值在服务目录 (SC) 中进行分类。从该目录中可以看出，您的服务水平协议 (SLA) 可能是与您的客户达成的。ITIL 还建议您准备好在各个 IT 部门之间达成的称为运营水平协议 (OLA) 的内部协议，以及与外部供应商订立的称为基础设施合同 (UC) 的合同。这有助于确保您符合在服务目录或 SLA 中设定的值。开始与客户讨论服务级别并达成一致意见之前必须先准备好 OLA 和 UC。如果没有准备好 SC 或 SLA，您将会与您的客户发生冲突，因为您有可能没有一个既定的服务级别。即使您已准备好 SC 或 SLA，仍可能会发生冲突，因为该协议可能未经所有受影响的各方认同。
有时，您可能达到了您的服务目标，但是在满意度调查中仍然会得到很差的结果。这可能表明您调查的对象不对、提出的问题不对或者达成或制定的 SLA 不好。如果您未准备好 OLA 或 UC，您将会发现 IT 部门及其供应商之间的冲突。相关的典型案例是二级支持并没有按照服务台的要求先处理紧急事故，从而导致事故变得越来越严重。流露出的迹象有：IT 与其客户之间发生冲突、调查结果很差、IT 内部发生冲突、或者与外部供应商之间的关系恶化。如果您发现任意这些迹象，说明您未满足该要素的要求。
您是否定期与客户会面，就服务级别达成一致意见并记录服务级别？您是否实施了必要的监视以测定这些既定的服务级别？您是否发出带有推荐和建议的报告以确保对于既定服务级别的任何故障都会被消除？如果您无法完全肯定所有这些问题，说明您未满足该目标要素的要求。切记这应该是事件的持续循环，而不仅仅是每年一次。通过这个持续的循环我们就可以得到驱动这些 SLM 目标的最后两个要素的信息，因此故障是不可接受的。
最后，该要素中的关键字是“成果”。这激励 IT 采取积极的态度，争取取得成功。首先，兑现您的服务承诺，然后通过您的成果来提高它们。即使是在不良的情况下也可能会获得一定的成果。例如，如果出现一个意外的故障，成果可能不仅仅是让客户再次运行时快速通过，还可以采取措施防止相同的问题再次发生。成果来自不满足于仅仅达到既定的目标，而是要超越这些目标。您积极进取吗？您是否在努力超越既定的目标呢？这可能就是努力争取发展与原地踏步的差别所在。
“用于根除符合业务或开销理由的不良服务的行为指导”： 该要素与我们作为认同、监视和报告结果的操作相关。下图对这种关系进行了说明：
这是一个在任何阶段都可以产生潜在改进的持续循环。但是，改进仅对它们自身有好处，这并不够好。我们必须还要确保它们有良好的业务方案；也就是说它们符合业务或开销理由。要确保我们符合业务或开销理由，我们需要准备好特定的其他 ITIL 组件，即：实施改进的“变更管理”、了解开销含义的“财务管理”、确定改进范围和影响的“配置管理”。此外，在实施改进之后，还需要计算和证明投资回报率，并衡量总体拥有成本。当然，如果不使用这些组件您仍可以根据业务或开销理由来进行改进，但您可能会浪费时间与资金。
要满足该要素的要求，您将需要制定服务改进计划 (SIP)，通常与“故障管理”和“可用性管理”一起使用。ITIL 将 SIP 描述为：
所确定的存在潜在困难的方面对服务质量有负面影响，“服务级别管理”必须与“故障管理”和“可用性管理”一起促使 SIP 确定并实施克服困难和恢复服务质量所必需的任何操作。
当然，SIP 组件也必须符合业务或开销理由。您是否满足该目标要素的要求？您是否确保持续地改进符合业务和开销理由的服务？您是否具有有效的服务改进计划，或者您仅当出现故障时才做出反应？不断地努力改进服务的 IT 部门被视为企业的资产，因为它们增强了公司的业务能力。
“通过这些方法，可以在 IT 与其客户之间建立良好的关系”，该要素比任何其他要素都具有总结性。如果您满足该目标中所有其他要素的要求，那么您自然会满足最后这个要素的要求。当您在 IT 与其客户之间建立了良好的关系时，您将更得民心，而且将面临更多有意义的挑战。该要素是对 SLM 目标中所有其他要素的重要性测试。如果满足该要素的要求，您很可能会满足所有其他要素的要求。
“服务级别管理”无疑是一个关键流程，因为它管理着客户的要求和需求。但是，它却是最常被 IT 部门忽略的流程。了解了这些目标及其解释后，您可能很容易就会意识到 SLM 对于 IT 和客户的重要性。如果您可以达到这些目标，那么您很可能也会成功地实施众多其他流程，因为它们之间有着密切的联系。例如，要达到既定的可用性级别，您必须至少完成“可用性管理”所必需的某些任务。SLM 是成功的关键，因为它有助于 IT 作为业务部门与其他更传统的业务部门保持一致，而不再作为孤立的附加部门。
IT 服务的财务管理目标
第 7 章
“财务管理”目标是独特的，因为其中包括两种不同类型的目标：一个针对内部组织机构，另一个针对商业环境。商业环境可以被看作外部或内部收费，也就是费用分摊 (chargeback)。下面是由 ITIL 所阐述的目标：
对于内部组织机构，目标应该是：
• 提供用于提供 IT 服务的 IT 资产和资源的有成本效益的职位。
在商业环境中，目标陈述可能要反映公司的利润和市场目标。
任何 IT 服务公司的目标都应该包括：
• 能够充分考虑在 IT 服务上的开销，并且知道这些开销都是为公司的客户交付服务的结果
• 通过提供详尽的“对 IT 服务的变更”的业务案例来协助制定有关 IT 投资的管理决策。
正如您所看到的，IT 服务的“财务管理”不只是与预算有关，还与成本效益有关。但是，预算是该流程的一个关键组成部分。SLM 目标表明“符合业务或开销理由”，而“财务管理”流程就是管理开销的理由所在。讨论开销时，ITIL 通常使用短语“满足应用”。这是一个关键短语，因为它与明智地投资 IT 服务有关。例如，它可能花费 x 美元来提供 99.999％ 的可用性。要提供 100％ 的可用性需要再多花费多少资金？获得 100％ 可用性需要的成本可能不成比例，99.999% 的可用性就能满足应用。另一方面，当客户仅要求和需要 50% 的可用性时，为什么要提供 99.999% 的可用性呢？这可以看作是一个不明智的决定，因为为了获得 99.999% 的可用性而需要额外支付的资金可用于改进 IT 的其他领域，或者可以避免支付这笔资金以降低总体成本。
出于本书的目的，内部组织机构仅支持内部员工，并不实行费用分摊制度。另一方面，在商业环境中，存在对内部客户进行费用分摊或对受支持的外部客户收费的现象。接下来我们研究一下“财务管理”目标的各个基本组成部分。首先，来看一下内部组织机构：
“提供用于提供 IT 服务的 IT 资产和资源的有成本效益的职位”：话虽然很短，但包含大量的含义，因为对公司没有什么成本效益的工作职位可能很快就会因公司管理制度的变动或因业务外包而被免除。“成本效益”可以简单解释为与 IT 服务相关。例如，某些公司主张成本越低越好。其他公司则主张投资于质量服务会更好。成本效益通常受预算限制（而非可靠的业务决策）驱动。但是，对于该目标，您需要在整体目标中查看成本效益。不管预算或其他标准制定了哪些限制条件，都仍然必须对 IT 财务进行管理以保护和增加 IT 投资。您是否对您的 IT 部门内的成本效益有一个明确的理解？您是驱动各种因素来降低成本、维护质量还是在某种程度上介于两者之间？如果您并没有明确的理解和陈述，那么管理财务就变得非常困难。一个缺乏明确理解的迹象就是在用了好长时间作出涉及成本的决策时引发了更多争议。
“职位”具有几个潜在的含义，其中包括管理人、监护人、保管人、负责人、主管人以及保护人等等。查看这个同义词列表，您可以发现之所以选择“职位”是因为每个同义词都与该目标相关。请注意，职位同义词与监督和保护而不是与管理和命令相关。“职位”意味着指导和引导，而“成本效益”描述的是支出水平和支出目的。这些差别非常重要，因为“财务管理”与每个人的角色和责任都相关，IT 部门的每个人都需要用心理解它。
“用于提供 IT 服务的 IT 资产和资源”：在我们探究这一部分之前，我们应该提醒我们自己 ITIL 中资产的含义。
业务流程的组成部分资产可以包括人员、办公设施、计算机系统、网络、纸张记录、传真机等等。
如果要由有成本效益的职位来管理资产，那么必须对资产进行登记和控制。“配置管理”是专门用于管理 IT 资产的 ITIL 流程。是否已将您的资产置于中央数据库中？您是否了解与这些资产相关的成本？如果不了解，则说明您并没有有效地管理您的 IT 财务。接下来我们了解一下 ITIL 中资源的含义：
IT 服务环节需要为客户提供必需的服务。资源通常是指计算机和相关的设备、软件、机构或公司（人员）。
乍看起来，“资产”和“资源”的定义非常相似，但是存在一个主要的差异。资产是一个组件，而资源需要很多资产来提供服务。例如，提供电子邮件服务需要很多资产。在很多情况下，资产可能会在众多的资源中共享。例如，服务器是一项资产，但很多服务都将该服务器作为其资源的组成部分。
要满足该目标组件的要求，您不仅需要知道与您的资产相关的成本，还要知道如何分配您提供给客户的服务的成本。在这种情况下，您可以建立一个成本结构，以便清楚地知道成本是如何分配的。
商业环境的目标要素包括在前面介绍的内部 IT“财务管理”的目标要素，以及下面将要介绍的目标要素：
“能够充分考虑在 IT 服务上的开销”：这意味着您必须事先准备好允许您管理成本的财务软件和流程，才能考虑您的 IT 开销。例如，您是否知道您的电子邮件服务每个月的运行成本？这包括资产、处理器时间、变更成本、打到服务台的电话以及电信成本。充分考虑这笔开销意味着您将 IT 作为业务来驾驭。
“这些成本都是为公司的客户交付服务的结果”： “这些成本都是为公司的客户交付服务的结果”： 接着前面的要素继续，您如何为您的客户分配电子邮件服务的成本？对此，您将需要一个计算成本的公式。一个例子是根据每位客户使用该项服务的比例来计算其成本所占的百分比。另一个例子是使用“用多少，付多少”的计量方法。不管使用什么方法来满足该目标要素的要求，您必须知道您的所有服务的成本，因为它们与您的客户相关。您是否有分配成本的公式？如果没有，您将无法满足该目标要素的要求。
“通过提供详尽的‘对 IT 服务的变更’的业务案例来协助制定有关 IT 投资的管理决策”：这是一个非常简单的要素，但它确实依赖于要满足要求的“财务管理”中的所有其他要素。如果其他要素没有就绪，提供业务案例的数据就不可用。请不要将该陈述仅理解为成本数据，如服务器的成本。业务案例还需要用于计算投资回报率的数据以及其他关键业务信息。如果不符合所有其他标准，您就无法满足该要素的要求。
IT 的“财务管理”对于管理成本和在市场中保持竞争力变得越来越重要。通过使 IT 成为业务资产而不是业务支出，执行有效的财务 IT 管理的公司将受益匪浅。因此，达到这些目标对于 IT 和业务都有好处。
容量管理目标
第 8 章
“容量管理”是大多数 IT 部门一直面临的一个挑战，因为基础设施和服务需求每天都在发生变化。如果没有财务限制，“容量管理”就会很简单。但是，实际上财务限制以及合理利用旧系统中的投资这种需求将继续使容量管理成为一个挑战。
ITIL 对“容量管理”做了简单说明：
确保成本合理的 IT 容量始终存在并确保它与当前及将来确定的业务需求相符
说起来简单，做起来却很难。在我们分析“容量管理”的目标之前，ITIL 讨论的整体基础设施不只是一些技术组件的容量就没有什么意义了。通常情况下，我们认为容量是指带宽、处理能力、内存或磁盘空间，而忘记了其他重要的基础设施项目，如人员配备标准。当我们考虑“容量管理”目标时，应牢记这些目标将应用到整个 IT 基础设施中。
“确保成本合理的 IT 容量始终存在”：此处的关键是“成本合理”。很多公司都没有有效的容量计划，并且对他们将来的需求也知之甚少。因此，他们往往是要么购买的基础设施组件过多，要么就是购买的不足。那些购买过多的公司希望确保他们能够满足不断增长的需求，但却从未考虑过增长的程度有多大。这通常会导致资源的闲置，如服务器的利用率低于容量的 40％。那些购买不足的公司希望能够节省资金。这可能会导致容量不足，意味着服务质量将会有所降低。您是否仔细计算过容量以确保在基础设施项目上的开支能够满足当前和计划的需求？或者您仅仅是做一些假设？请记住，如果在某个领域超支，您在其他领域就会出现短缺。
短语“始终存在”准确地表达出了这个意思；也就是说，足够的容量始终可用于提供与客户达成的服务级别。因为“容量管理”还包括“性能管理”，这意味着不仅要提供足够的资源来满足需求，还要提供足够的资源来满足在达到 SLA 中既定的性能目标时的需求。 您的服务台是否接到了客户抱怨他们的工作站“速度变慢”的电话？通常，这些客户会在以后打来电话说他们的工作站再次“加速”了。如果接到有关工作站速度减慢的电话，则可能是由容量引起的。您是采取“下意识”的方式来解决容量问题，还是使用系统的方法来解决它们呢？下面是一些要在确定您的容量是否“始终存在”的过程中寻找的迹象。
“它与当前和将来确定的业务需求相符”：要与当前和将来的业务需求相符意味着必须经常地测定容量，并与客户讨论他们当前和将来的需求。进行磋商以确定应将客户需求作为服务水平管理 (SLM) 的一部分来满足。SLM 应为“容量管理”提供相关的数据以确保存在适当的容量。“容量管理”还应该与 SLM 一起配合使用，以从客户那里获得所需的信息，从而来执行容量管理活动。SLM 是否在您的客户和“容量管理”之间提供了一个纽带？您是否定期发布容量计划？您曾经是否有过由于容量不足而与客户发生冲突的情况？这里仅仅是一部分能够表明您的“容量管理”是否适当的迹象。
“容量管理”是一种正在进行的活动，它可确保典型的成本管理和业务效率。达到这些目标意味着 IT 可以顺利地发展，而不会徘徊不定、停滞不前：也就是说，一旦达到这些目标，要想发展 IT 就变得非常容易了，也不会带来代价高昂的损失
可用性管理目标
第 9 章
管理可用性对于 IT 是一项非常重要的活动，因为错误计算或误解可用性可能会使企业遭受重大损失。例如，一个新的应用程序可能要求服务台支持从每天 16 小时每周 5 天扩展到每天 24 小时每周 7 天，这项服务的代价很高。从早期的主机时期开始，管理可用性已经成为一个对 IT 的挑战，那时只有在白天主机上才提供联机服务，到了晚上，计算机需要进行批处理。如果夜间批处理窗口未完成批处理工作，则联机系统的可用性将会延迟到第二天。否则，如果客户晚于预定的时间关闭它们的联机系统，批处理工作就会推迟启动，而且会丢失其处理目标。目前，我们拥有更多的专用资源，但是确保可用性的问题仍然存在。接下来我们看看 ITIL 设定的管理可用性的目标：
“可用性管理”流程的目标就是优化 IT 基础设施的容量、服务和支持的公司，以便提供有成本效益且可使企业满足其业务目标的恒定的可用性级别。
一些类似的词和短语再次出现在该目标中：“优化”、“成本效益”和“业务目标”。这些词和短语已经在前面讨论过，因为它们的意思始终是相同的，所以不需要再次进行说明。仍然有一些重要的要素需要考虑：
“优化 IT 基础设施的容量、服务和支持的公司”：“容量”和“优化”这两个词在一起表达得很好，因为并不是始终都要求最大化，而且通常也无法实现最大化。参加马拉松的人们不可能全部都成为世界记录保持者，但是那些以此为乐趣的人们仍然尝试提高他们的赛跑能力。为什么不最大化呢？原因很简单，如果我们同时拥有一份全职工作，最大化要求很多我们无法提供的能力。该目标要素告诉我们不要试图去实现最大化，因为这样就不会留有扩展和发展的灵活性。它还告诉我们要利用我们所拥有的资源来做好工作。
该目标列出了三个组成部分：IT 基础设施、服务和支持的公司。“IT 基础设施”和“服务”从字面上就可以理解，但“支持的公司”需要一个简短的说明。这是指从 IT 公司外部供应资源的公司，如工程服务公司、外包商和电信公司。对于这些实体，优化它们的容量意味着确保它们满足其合同条款的要求，如 SLM 和客户之间达成的可用性条款。如果 IT 资源和支持的公司之间存在冲突，则说明您未满足该目标要素的要求。
“交付有成本效益且可使企业满足其业务目标的恒定的可用性级别”：这句话道出了该目标的核心所在。成本效益依赖于 SLM 和客户之间达成的可用性级别。因此，在不首先考虑“可用性管理”的情况下，不应该存在客户与 SLM 达成的可用性级别。当在 IT 和客户之间达成可用性级别时，是否涉及了“可用性管理”？如果没有，您可能面临着危险。
恒定的可用性级别意味着由 IT 提供的服务和系统的可用性是基于一致、持续的原则交付的。换言之，对于为提供既定的可用性而出现的任何故障都应予以调查并采取措施，以防止将来再次出现这样的故障。请注意，即使当您交付未实现的可用性时这也适用，但它不能很好地达到您的目标。例如，您已经与您的客户达成 99.9% 的可用性目标，而您却只达到了 99.8%。这项工作完成的很好，但仍有 0.1% 的差距，因为如果您不立即解决这些故障，它们可能会越积越多，使您进一步远离目标。ITIL 将其称之为“可靠性管理”，它是“可用性管理”的一部分。您是否调查了所有可用性故障的原因？您是否采取措施来防止它们再次发生？如果对以上两个问题的回答有一个为“否”，那么您就不会达到该目标。
使公司满足其业务目标意味着“服务级别管理”应该到位。如果不到位，负责“可用性管理”的 IT 人员应该定期与他们的客户进行协商，以确保他们提供的服务能够满足客户的需求。该要素应该是对 IT 的一个永久暗示，IT 应该服务于业务群体而不是由业务群体为其服务。 如果您不定期查看业务群体的可用性目标，您就不会满足该目标要求的要求。一个来自调查反馈的迹象表明，尽管您达到了您的目标，但客户仍然不高兴。另一个迹象表明您虽然每个月都超出可用性目标，但却从未提高过它们。虽然这可能对于客户来说可以接受，但却表明您并没有消除可用性性能问题。
“容量管理”和“可用性管理”一起提供了客户评定“IT 服务管理”的大多数依据以及重要事件。通过查看最简单的服务水平协议您都可以获得此信息。IT 客户认为，虽然同样都达到了这些目标，但有的是成功了，有的却失败了。
IT 服务持续性管理目标
第 10 章
随着对 IT 服务干扰的威胁日渐增长，这些威胁对业务的影响也由于更多重要业务流程的计算机化而不断增长，IT 服务持续性管理在战略上处于重要地位就不足为奇了。“服务持续性管理”不再仅仅涉及灾难恢复（尽管灾难恢复仍然非常重要）。它还涉及技术故障对业务造成的影响。例如，如果您有 90% 以上的业务来自 Internet，提供这些服务的 IT 基础设施中的任何故障都将会立即显露出来，并且可能会引起收入和业务声望的损失。因此，了解“IT 服务持续性管理”目标是支持业务的根本：
ITSCM 的目标就是支持整体“业务持续性管理”流程，方法是通过确保必需的 IT 技术和服务设备（包括计算机系统、网络、应用程序、电信、技术支持和服务台）可以在所要求的、既定的业务时限内进行恢复。
尽管该目标并不是很冗长，但不满足各种要素的要求可能会带来灾难性的影响。因此，我们需要仔细了解各个要素：
“ITSCM 的目标就是支持整体‘业务持续性管理’”： 这里的关键字是“业务持续性管理”。ITIL 建议公司执行“业务持续性管理”，因为有很多风险是 IT 无法控制的。例如，IT 无法确保对其不具备前提条件的远程位置的安全访问。如果建筑物着火倒塌会发生什么情况？IT 仅仅是恢复团队的组成部分。您的公司是否具有“业务持续性管理”？如果没有，就要朝着该目标要素努力，IT 必须主动确保公司意识到需要“业务持续性管理”，并且还要确保 IT 已经准备好周密的“业务恢复计划”。
“确保必需的 IT 技术和服务设备（包括计算机系统、网络、应用程序、电信、技术支持和服务台）可以在所要求的、既定的业务时限内进行恢复”：该目标要素的第一部分解释了所有 IT 基础设施要素及其相关的活动都是“IT 服务持续性管理”的组成部分；但实际上是最后的几个词定义了该要素，“可以在所要求的、既定的业务时限内进行恢复”。再次强调一点，SLM 在此处发挥一定的作用。SLM 与 ITSCM 一起负责与业务客户合作，首先确定需要恢复的 IT 技术和服务设备以及要求的时限，然后与业务客户对这些时限达成一致。您是否定期与客户会面以调查业务持续性需求和目标？您是否记录和发布这些需求与目标？如果您没有执行这些操作，您不仅未满足该目标要素的要求，还危及了公司的将来。
该要素中的关键词是“可以进行恢复”，因为如果没有使恢复流程和操作准备就绪，就不可能理解和同意。该要素要求我们将恢复操作、计划和流程准备就绪以提供业务群体所要求的恢复级别。当然，这受限于投资和所有其他正常的业务牵连。请记住，这不仅仅是“灾难恢复”，还是“业务持续性”。您是否已安排好“业务持续性”计划？如果没有，您将无法满足该要素的要求。
考虑 ITSCM 时，保护股东的投资非常重要。如果没有保护好股东的投资，则说明没有提供良好的 ITSCM。这不足以反映出高级 IT 管理，尤其是当某个 IT 基础设施组件出现严重的“业务持续性”故障时。
探究服务管理的目标
目录
• 简介
• 第 1 章 - 事故管理目标
• 第 2 章 - 故障管理目标
• 第 3 章 - 变更管理目标
• 第 4 章 - 配置管理目标
• 第 5 章 - 发布管理目标
• 第 6 章 - 服务级别管理目标
• 第 7 章 - IT 服务的财务管理目标
• 第 8 章 - 容量管理目标
• 第 9 章 - 可用性管理目标
• 第 10 章 - IT 服务持续性管理目标
简介
在大多数情况下，对于已受过 ITIL 培训、阅读过 ITIL 书籍或参加过 ITIL 专门讨论会的人来说，ITIL 所带来的好处是显而易见的。但是，让其他人相信 ITIL 对公司的好处却并非一件容易的事情。
ITIL 的好处非常明显。但是，采用 ITIL 最佳惯例的过程并不能一蹴而就，ITIL 也不会将低劣的 IT 基础设施在一夜之间变成最优秀的。需要花费时间、进行规划，以及做出投入才能纠正公司的惯例，以便从已经改良的运行模式中受益。
将 ITIL 的目标视为揭示 ITIL 可对公司产生潜在影响的方式，似乎更为恰当，也是用于培养对贯彻由 ITIL 概括的某些或全部最佳惯例的约束感的极好方法。 如果能够让那些安于现状的人看到 ITIL 可以支持甚至可以提高其当前目标，那么您就能在培养对 ITIL 的约束感和拥护感的过程中发挥作用。
ITIL 对 10 个服务支持和服务交付流程及功能的目标分别进行了明确描述，包括：
服务支持
事故管理
故障管理
变更管理
配置管理
发布管理
服务交付
服务级别管理
财务管理
容量管理
可用性管理
持续性管理
在这本小册子中，我们将探究每个“服务支持”和“服务交付”目标的基本组成部分，并说明如何确定您的公司是否达到了这些目标。了解公司当前最佳惯例和 ITIL 最佳惯例之间的差异有助于制定实施 ITIL 的方案。
本小册子中所阐述的目标直接引自 ITIL 出版物。
事故管理目标
第 1 章
ITIL 出版物“服务支持”中定义的 ITIL“事故管理”目标如下：
“‘事故管理’流程的主要目标就是尽快恢复正常的服务运作并将事故对业务运营的负面影响减到最小，从而确保可以维持服务质量和可用性的最高水平。此处将‘正常的服务运作’定义为服务水平协议 (SLA) 所限定的服务运作。”
我们将该定义分解成几个基本组成部分，然后看看是否会找出有助于证明实施 ITIL 必要性的内容：
“恢复正常的服务运作”：ITIL 将正常的服务运作定义为服务水平协议。是否具有正式的 SLA？如果有正式的 SLA，您就可以确定在 SLA 指定的许可时间限度内您无法恢复服务的频率。其诀窍在于估算利用 ITIL 可降低该频率的程度。根据实际所作的评估是可用于传达在公司内实施 ITIL 的好处的交付成果。可选择新近发生的事故并将其作为案例进行分析。要努力确定是否曾经能够更快速地处理所有事故。注意寻找诸如以下所列的问题：二级支持反应迟钝、服务台分配了错误的优先级、或者服务台错误地诊断了事故的故障现象。可引用案例分析的数据来表示 ITIL 改善“事故管理”的效果。切记要将实际服务级别与您的 SLA 进行比较。
如果尚未签定 SLA，则无法确定成功的程度，因为没有基准点。在这种情况下，您需要确定一套“预期的”SLA 水平，并据其衡量实际性能，以便从 ITIL 获取潜在的好处。然后，可继续使用上一段中的例子，但是要根据您设置的预期服务级别而不是实际的 SLA 来对其进行衡量。（有趣的是，您没有 SLA 的事实本身就是需要 ITIL 的一个主要论据。）
“尽快地”：此外，可根据已签定的 SLA 或预期的服务级别来进行衡量。其诀窍不是仅仅满足服务级别，而是要未雨绸缪。所以要寻找反映当前处理事故的速度，以及 ITIL 对预估当前服务级别的作用大小的数据。例如，与“变更管理”的集成意味着您可对失败的变更作出更快的反应，并因此可更快地恢复服务。
“将对业务运营的负面影响减到最小”：这是关键的交付成果，因为如果您没有进行“配置管理”，就无法迅速确定出现故障的 IT 组件对业务的影响。因而，您可能要设置面向 IT 而不是业务驱动的目标。这可能会导致 IT 部门难以解决看起来对 IT 非常重要，但实际上对业务人员却不重要的事故。由于当前配备 IT 员工的限制，IT 员工集中支持业务运营是至关重要的。一定要寻找客户因其延迟而投诉、通过更合理的人员分工可防止其发生的事故。在此重提 SLA 的原因在于 SLA 中应该有关于 IT 系统和服务对业务造成影响的条款。如果没有这种关联，您可能只是推测业务影响。如果未签定 SLA，您就应该努力推导出制定业务驱动优先级和安排时间处理事故的方法。
“确保维持服务质量和可用性的最高水平”：此处的关键字是“最高”，或者换用另一种 ITIL 表达方式：“满足应用”。但是，“最高”意味着什么呢？您经常会听到世界级服务，但是您是否见过“世界级”的明确定义呢？您很可能没有见过，因为据我所知，这样的定义并不存在。“最高”也是如此。我将“最高”定义为以合理的开销提供适当的服务级别。如果可以做到这一点，您就可以自信地说您提供了公司所需的服务，而且公司也出得起费用。若要确定是否满足这一要求，您需要利用调查之类的方法确定服务级别并征求客户的定期反馈，以确定您是否满足既定的级别。需要与客户定期进行沟通以确定您是否提供了适当的服务级别。请不要带着情绪提问，如“我们有礼貌吗？”，而是要征求客户对您控制和处理事故的能力的看法。随后即可利用此数据制定方案。
“事故管理”是 ITIL 和客户服务的关键组成部分。切记客户是利用服务来与 IT 部门进行日常沟通的。对事故控制得越好，您的客户将会越满意。所以要仔细查看 ITIL“事故管理”目标，然后思考自己是否实现了该目标。如果没有实现，就要找出失败的原因，因为这正是您证明实施 ITIL 必要性的依据。如果您拥有良好的服务台，那么“事故管理”就是极其接近实现 ITIL 目标的流程。
故障管理目标
第 2 章
ITIL 出版物“服务支持”中定义的 ITIL“故障管理”目标如下：
“故障管理”的目标就是将 IT 基础设施内的错误引起的事故和问题对业务的负面影响减到最小，并防止与这些错误相关的事故再度发生。为了实现这个目标，“故障管理”力求找到引发事故的根源，然后才着手改善或纠正该情况。
“故障管理”流程具有被动和主动两个方面。被动方面是作为对一个或多个事故的反应而解决问题。主动“故障管理”是指在事故发生前确定并解决问题和已知错误。
现在我们将该定义分解成几个基本组成部分，然后看看是否可以找出有助于证明实施 ITIL 必要性的内容：
“将事故和问题对业务的负面影响减到最小并将事故和问题出现的频率降到最低”：这是一个争议的焦点，因为 IT 部门惯于将重心放在性能而不是质量上，放在提供支持而不是消除问题上。例如，服务台通常在首次接到电话时就设定了性能目标，如严重事故的解决，但他们并未对减少事故设定目标。其结果就是服务台在首次接到电话时挑简单的事故进行处理，而不是设法减少发生潜在事故的次数。这会导致客户遭受延迟和挫折，以及致使服务台人浮于事。
确定是否有通过“故障管理”减少事故发生次数的明确目标。如果没有，则找出在过去一段时间（比如一年）内事故发生的次数减少的原因。对于“故障管理”，还没有目标事故降低率的行业标准。但是，最常引用的是 30％ 到 70％ 的比例。如果您的公司内没有可以反映“故障管理”效果的数据，那就用服务台开销的 30％ 作为潜在的开销节约比例。
“着手改善或纠正情况”：将要采取的措施包括“解决方案”或“遍历操作”，这是服务台快速处理事故所必需的。还包括长期消除源自基础设施的错误和事件的必要措施。首先，我们看一下解决方案。您的服务台和二级支持小组能否对解决方案做了明确说明？他们在确定解决方案后能否立即对其进行传达？他们是将信息输入到支持数据库中还是输入到您的知识管理信息库中？如果对上述任一问题的回答是否定的，那么您很可能并未开始着手纠正各种情况。
在许多公司中，只有在作为支持和维护客户的唯一途径时，才会应用长期解决方案。在大多数情况下，如果在接到第一次电话后问题就可以由服务台迅速解决，那就不会努力去寻找长期解决方案。（这是高度集中处理首次打进的电话的直接结果。）您是否要执行“故障管理”并调查所有事故以确定长期解决方案？如果不是，请在您的服务台数据中查找最频繁发生的事故，并估算消除这些事故所带来的收益。这为您制定 ITIL“故障管理”方案提供了更多的信息。
“找到引发事故的根源”：此“故障管理”的目标要素与前面的目标要素是密切相关的。真正的“故障管理”来自确定问题的根源，然后确定消除该问题的开销与从中得到的收益或节约效果相比是否划算。有时让服务台继续处理发生的事故比消除该问题的开销还要少一些。人们常会误解问题的根源。例如，根据 Help Desk Institute 的调查，在服务台遇到的所有事故的 30％ 到 50％ 都是询问如何操作。在这些事故中，技术是可行的，但缺乏知识。服务台常会创建知识库或 FAQ 以解决这些问题。问题的根源在于客户缺少培训，而这正是作出努力和投入资金的方向。
努力确定您当前是否正在查找所有事故/问题的根源，以及是否正在做出根除这些事故/问题的合理的业务决定。如果不是，请执行前面目标要素中所描述的操作。另外，如果您出于合理的业务原因允许在系统中出现错误，那么您务必要完整地记录该解决方案。
“防止事故再度发生”：这也与前面的目标要素密切相关，但此处的主要因素是时机的选择和如何作出决定。首先，您是否具有一个无论何时何地都应该减少事故的策略？如果没有，那您就有理由实施 ITIL“故障管理”了。其次，您何时决定减少事故？您是寻求在第一次发生事故时就将其彻底消除，还是等到事故多得无法应付时再将其彻底消除呢？如果您并未关注每个新的事故，说明您还没有进行有效的“故障管理”。
“既被动又主动”：许多公司执行被动的“故障管理”，而只有少数公司执行主动的“故障管理”。本节前面提到的每个要素都是针对被动“故障管理”的，也就是说事故发生后我们再进行处理。很少有公司进行主动的“故障管理”，如通过复查/分析事故数据库，或者复查所有的变更或新增系统，以防止因此发生事故。您是否对事故数据库进行分析以确定将减少事故发生次数的趋势？如果不是，那么您应该将其作为一个需要进行“故障管理”的理由，利用“故障管理”还会提高客户服务质量。如果您确实对变更和新增系统进行复查，那就要看一下最近出故障的或者引发新事故的变更/新增系统。然后，通过估算在得到成功执行的情况下可以节省多少时间和金钱来得出支持的证据。
“故障管理”在大多数 IT 部门中一般不会得到重视，而可从中获得最高回报的 ITIL 作用却会受到重视。所以要将此处所描述的目标看作是冷酷无情的，并制定一个有力的“故障管理”方案。
变更管理目标
第 3 章
如果您并不熟悉 ITIL“变更管理”，那么您需要了解 ITIL 下的“变更管理”和“变更控制”之间的差异。只有了解了这一点，您才能为实施 ITIL“变更管理”的必要性提出有力的论据。
ITIL 将“变更控制”定义为：
确保所有变更都可得到控制的规程，其中包括变更的提交控制、分析控制、决策控制、批准控制、实施控制和实施后控制。
ITIL 对“变更管理”的描述却大相径庭：
以可控的方式控制对基础设施或服务的任何方面的变更，从而使得实施已经批准的变更产生最低限度的影响。
“变更管理”和“变更控制”的主要区别在于各自定义的开头。“变更控制”是一种规程，而“变更管理”是一个整体流程。换言之，在“变更管理”流程中可能存在着很多受控的变更。每个变更都需要有效的“变更控制”，而“变更管理”流程监视所有的变更。
在没有有效的“变更管理”的情况下也有可能进行良好的“变更控制”，但依然会出现故障。例如，两个不同的 IT 团队都各自对相同的服务器进行单独的改动。两个团队都非常有效地控制着各自的变更，但在实施时遇到了问题，因为这两个团队之间没有进行任何沟通，而他们所做的变更也是相左的。对于“变更管理”，应该注意两个团队即将改动同一服务器的状态的情况，而且应该让这两个团队进行协作以消除变更引起的故障。通过“变更管理”可同时控制很多受控变更的生命周期和状态，因为“变更控制”是“变更管理”的一个组成部分。
这并不奇怪，因为“变更管理”是具体的，而 ITIL 目标是综合的：
“变更管理”流程的目标是确保利用标准化的方法和规程有效、及时地处理所有变更，以便将由变更引起的事故对服务质量的影响减到最小，并因此改进公司的日常运作
若要对“变更请求”作出适当的回应，需要利用对风险和业务持续性、变更冲突、资源要求和变更批准等进行评估的、经过深思熟虑的方法。这种经过深思熟虑的方法对于维持变更需求与变更冲突之间适当的平衡是必要的。
当发生变更时，为了能够进行平稳的过渡，“变更管理”流程对其具有很高的能见度和畅通的沟通渠道尤为重要。
我们将这个相当冗长的目标分解成几个基本组成部分，然后看看是否会找出有助于证明实施 ITIL 必要性的内容：
“将与变更相关的事故对服务质量的影响减到最小”： 这句明确的话意味着“变更管理”肩负着重任。问题是：是否由于失败的变更，或者已起作用但在其他 IT 基础设施组件中引发了新事故或新问题的变更，而遭遇了一些新的事故和问题？例如，虽然成功地添加了一个新软件应用程序，但是内存不足，所以性能下降了。如果您对这个问题的答案并不确定，那就分析您的“事件和问题数据库”，以便看看是否存在表明失败的变更的证据。利用此数据可说明您未达到“变更管理”的目标。一个好的方法就是让服务台员工举出例子。如果变更失败，那么他们只有提供帮助。
“有效、及时地处理所有变更”：下面我们将讨论变更的进度安排和时间选择。如果您将“变更请求”的注册和管理集中到一点进行，那么您应该检查请求的交叉部分，以确定滞后或延迟的变更所占的比例。
这将提供用于确定是否满足该“变更管理”目标组成部分的数据。如果目前“变更管理”尚未就绪，那么量化该项目可能会很困难。通过会见客户以征求他们对于此时变更管理效率的意见，或者您可以收集和分析当前在不同 IT 位置处于活动状态的变更请求，您可能能够执行某些侦探性的工作。不管是如何得到数据的，这都是一个重要的主题，因为变更进度安排和时间选择是“变更管理”成功的关键。
未将“变更请求”的注册和管理集中到一点进行，这本来就是实施“变更管理”的理由，因为如果您不知道正在改动哪个基础设施项目，或者不知道何时对其进行改动，那就无法有效地控制变更。
“确保所用的是标准化的方法和规程”：所有的 IT 部门都惯于用其自己的方法将变更的生命周期控制在其范围之内。但是，如果不同的部门共同进行同一变更，这是无法接受的。最为苛刻的变更要求之一就是不但要成功地进行变更，而且还要确保变更周围的环境能够适应。例如，对网络浏览器的更改可能需要将基础设施组件的软件和内存进行升级，并进行用户培训。如果所有这些项目在发生变更的时候均未完成，那么该变更将会失败或引起问题。这就是标准化方法和规程至关重要的原因所在。这是一个易于核查的目标，因为您不是可利用已记录在案和已实施的标准化方法或规程就是束手无策。如果未使用标准化的方法和规程，您应该意识到如果不同的团队进行同一变更时没有遵循标准化的方法和规程，失败的可能性就会高很多。您可能能够利用失败变更的数据来证明这一点。
“一种用于对风险和业务持续性进行评估的、经过深思熟虑的方法”：此处需要注意对业务的影响是牵一发而动全身。所有对 IT 基础设施进行变更的决定都必须集中进行，并且受影响的各方都应该群策群力。在大多数情况下，变更的投资回报率 (ROI) 并不准确，因为其中不包括其他 IT 团队为该变更所付出的努力带来的回报。如果 IT 部门不知道变更的实际开销，那么如何进行预算和投资呢？
如果 IT 部门不知道有多少员工在进行变更工作，那么如何确定必要的员工数量呢？如果 IT 部门没有与其他部门共同对变更的影响进行评估，那么将会有更多的电话打到服务台。目前，如果变更失败了，那么即使是最简单的变更也会对公司产生严重影响，而在某些情况下这会直接影响到利润。所以，对于该目标，不是提出证明失败的证据，而是要说出使这些项目出现问题的潜在业务影响。
“维持变更需求和变更冲突之间适当的平衡”：在源于变更的潜在冲突、收益和交付成果与实施该变更的开销之间必然有一种平衡。例如，可能客户因为某个要求解决问题的“变更请求”而每天向服务台打三次电话却对业务影响很小。最初，听起来实施该变更是一个不错的主意。但如果要实施该变更需要花费 $200,000 该如何处理呢？这是一个夸张的例子，但它说明了在判断冲突和开销的平衡时要慎重行事。这是一个难以实现的目标，因为难以获取用于证明您观点的硬数据。您必须再次考虑集中管理“变更请求”。利用这种方式您可以确定实际开销，因为您可以从进行该变更工作的所有团队那里收集信息，然后可从 IT 部门和客户的不同群体的共同角度对该变更进行复查。
“具有高能见度和畅通的沟通渠道”：用简单的形式定期征求所有感兴趣的各方（包括 IT 和业务部门）对变更状态的反馈。这是一个易于评估的目标，因为您或者征求反馈或者不征求反馈。如果不征求反馈，那么这就是需要实施“变更管理”的理由。
“变更管理”是公司内 IT 部门成功的关键之一。目前，IT 是业务流程中的重要部分，并已被完全集成到普通业务活动的结构之中。失败的变更、滞后的变更、超预算的变更、资源不足的变更、传达不畅的变更、孤立的变更以及处理不当的变更都是无法容忍的。此外，一定要记住“变更控制”和“变更管理”之间的差异。
配置管理目标
第 4 章
许多 ITIL 专家都认为“配置管理”是 ITIL 的“太阳”，是其他 ITIL“行星”围绕的中心。这是一个贴切的比喻，因为所有其他的 ITIL 流程确实都与“配置管理”密切相关。因此，达到“配置管理”的目标是成功实施 ITIL 的基础。您是否达到了 ITIL“配置管理”目标？接下来我们看看这些目标：
“配置管理”通过识别、控制、维护和验证现有“配置对象”(CI) 的版本来制定基础设施或服务的逻辑模型。
“配置管理”的目标是：
• 对公司内部的所有 IT 资产和配置及其服务作出说明
• 提供有关配置及其记录的准确信息以支持 所有其他的“服务管理”流程
• 为“事故管理”、“故障管理”、“变更管理”和“发布管理”提供坚实的 基础
• 对照基础设施验证配置记录并纠正任何异常情况
我们将“配置管理”的目标分解成几个基本组成部分，然后看看是否会找出有助于证明实施 ITIL 必要性的内容：
“‘配置管理’通过识别、控制、维护和验证现有‘配置对象’(CI) 的版本来制定基础设施或服务的逻辑模型”：
在我们审视该要素之前，需要理解“配置对象”的 ITIL 定义：
它是基础设施的组件，或是一个对象，处于（或者将处于）“配置管理”的控制之下。各种 CI 的复杂性、大小和类型可能有很大的差异，可能是一个完整的系统（包括所有硬件、软件和文档），也可能是一个模块或较小的硬件组件。
“配置对象”是一个基础设施组件，必须能够提供服务、系统和应用程序，而这些又是为 IT 客户提供既定的服务所必需的。可随意选择 CI 的复杂度。例如，您可将工作站作为一个 CI，或者可将工作站分成若干个组件（处理器、键盘、鼠标和屏幕），然后将其中每个组件作为一个 CI。“配置管理”主要管理各个 CI 之间的关系，也就是说通过查看一个 CI，您就可以看到该 CI 与处理特定系统或服务所必需的其他 CI 之间的关系。服务台可以利用 CI 之间的关系建立影响和确定优先级。请注意，“资产管理”维护有关高于特定价值的资产、其业务部门及其位置的详细信息，然而“配置管理”还维护“资产管理”未涉及的资产之间的关系。
在尝试评估是否满足该目标要素的要求时遇到的第一个问题就是确定您是否具有反映 CI 或资产之间关系的数据库。如果没有，您如何确定影响呢？您将如何从远程灾难中进行恢复呢？首先，看一下您是否有中央“资产数据库”。如果有，请看一下它是否可反映出各个对象之间的关系并为制定方案做出相应的准备。您可能发现您并没有中央“资产数据库”，这本身就是一个强有力的理由。
有关该目标要素的特定议题包括：识别、控制、维护和验证“配置对象”的版本。在此您需要确定是否有用以管理 CI 从酝酿到终止的生命周期的标准方法。如果有，请核查它是否涵盖了所有 CI 并得到了很好的维护。数据不准确的一种迹象是服务台持续接到客户打来的有关与“配置/资产数据库”相关的组件并不存在的电话。例如，客户报告“我的扫描仪不能用了”。服务台的答复是“这并不奇怪，因为根据我们的记录，您根本就没有扫描仪”。（虽然有点言不由衷，但这确实说明了问题。）总之要核查的两件事情是您是否具备识别和控制 CI 的方法和规程，以及您是否具备维护这些 CI 状态的方法和规程。根据您得到的数据提出论据。
“对公司内部的所有 IT 资产和配置及其服务作出说明”：这是一个重要目标，因为并不是所有 CI 看上去都是资产。例如，内部编写的程序、规程记录以及人员通常不会被视为资产，但是它们都是“配置对象”。该目标要素意味着应该进行核查以确保所有可能的 CI 都应该包括在“配置管理数据库 (CMDB)”中。确定是否满足该要素的要求非常简单。是否进行了核查？当然，如果您没有 CMDB，的确也不会有什么内容可供核查。
“提供有关配置及其记录的准确信息以支持所有其他‘服务管理’流程”：假定您 CMDB 中的数据是准确的，问题是：如何使其可用于其他“服务管理”流程呢？将“服务管理”流程集成在一起是至关重要的。例如，当服务台在事故记录中输入数据时，CI 数据库能否自动地添加有关配置和文档信息的记录？或者，服务台代理是否必须手动输入该信息？或者更糟糕，由于无法得到数据而根本就无法输入？若要检查您是否满足该目标要素的要求，可查看其他“服务管理”流程，并确定其中是否存在 CMDB 数据可用但未被使用的区域。当然，如果您没有“配置数据库”，那就不会有什么内容可供核查。
“为‘事故管理’、‘故障管理’、‘变更管理’和‘发布管理’提供坚实的基础”：“事故管理”、“故障管理”和“变更管理”都是从 CMDB 中获取信息的流程，更为重要的是，它们用其作出决策。利用准确完整的 CMDB 信息可为确定问题或事件的影响作出精明的决定。这使得对潜在变更的开销所作的计算更为准确。此外，还提高了逐步升级的准确性。
关于“服务管理”中知识工具的议题有很多。可能最重要的知识就是对于您拥有哪些资产、资产的位置及其相互关系的知识；也就是 CMDB 中的信息。但 CMDB 的重要性常被忽视。该目标要素的重点在于 CI 中包含的属性。只有一个 CMDB 还不够好。 必须获取每个 CI 中的数据，这些数据对于其他“服务管理”流程是有意义的信息。查看 CI 的属性或字段以确定数据中是否含有对其他“服务管理”流程有用的信息。您将需要询问进行其他服务管理的人是否已经获得他们所需的数据，以及如果他们尚未获得所需的数据，还需要什么其他数据。您可借此确定是否已满足该目标要素的要求。当然，如果您没有 CMDB，的确也不会有什么可供核查的内容。
“对照基础设施验证配置记录并纠正任何异常情况”：如前所述，“配置管理”为所有其他流程提供信息和数据。该要素与前面的要素有关，除了该要素不要求 CMDB 中含有全部 CI 的信息，而是要求 CI 的内容是准确的。与前面的要素一样，验证是否满足该要素的要求非常简单，也就是您是否进行了核查？当然，如果您没有 CMDB，的确也不会有什么可供核查的内容。
到目前为止，“当然，如果您没有…，的确也不会有什么可供核查的内容”已出现许多次了。但是，该消息经常会被忽视。据估计，在 Y2K 上支出的收入的 70％ 只是用在跟踪资产及其关系上了。如果您没有一个集中、准确、完整的 CMDB，您就应该立即提高警惕。
发布管理目标
第 5 章
“发布管理”通常被看作是“变更管理”的一部分，但实际上它是一个重要的 ITIL 要素，因为遭受失败的常常是变更的发布，而不是变更本身。有关这个主题的 ITIL 目标是全面而精确的：
• 计划并监视软件和相关硬件成功的首次公开展示
• 设计和实施用于 IT 系统变更的发布和安装的有效规程
• 确保正在对其进行改动的硬件和软件是可跟踪的、安全的，而且已安装的版本都是正确的、经过授权和经过测试
• 在计划和首次展示新发布的过程中传达并管理客户的期望
• 通过与“变更管理”达成一致来确定发布的准确内容和首次公开展示计划
• 利用‘配置管理’和‘变更管理’的控制流程将新的软件发布或硬件添加到有效的环境中 － 发布应该受‘变更管理’控制，并可含有硬件、软件、固件和文档 CI
• 确保将所有软件的主副本保存在“留存软件库 (DSL)”中，并确保对 “配置管理数据库 (CMDB)” 进行更新
• 利用“配置管理”的服务确保所有正在对其进行首次公开展示或改动的硬件是安全的且是可跟踪的。
通常 8 个要素意味着这是一个复杂的目标，但是在这种情况下精确性非常重要，因为“发布管理”需要慎重行事。我们分别讨论每个要素：
“计划并监视软件和相关硬件成功的首次公开展示”：这里的关键字是“计划”和“监视”。您是否有用以管理软件和硬件的首次公开展示的明确计划？您是否确定在首次公开展示过程中定期的反馈已发送给所有感兴趣的各方？您是否将标准的计划/项目作为模板？如果对所有这些问题的回答都是肯定的，那么说明您已经满足该要素的要求。如果对这些问题不能作出肯定的回答，那么说明您很可能面临的失败将会证明您尚未满足该要素的要求。如果您不能确定是否是按计划行事，那么很可能就是未按计划行事。如果仍持怀疑态度，那就询问诸如服务台这样的关键团队，询问他们是否参与了首次公开展示、是否解答了关于首次公开展示的问题或者是否为首次公开展示发出通知。
“设计和实施用于 IT 系统变更的发布和安装的有效规程”：有效的规程通常被称为“清单”或“操作说明”。这些规程可用于确保流程中所必需的操作都得以执行，从而达到了预定的服务级别和标准。需要不断地对这些规程进行调整和纠正以确保最高的精确度。例如，在测试一个新工作站时，您可能要按照一个其中有十条说明的清单行事。但是，因为服务台不断接到有关新工作站问题的电话，所以您可再向清单中添加一条说明，以便将该问题根除。您是否有有效的规程并持续地监视其有效性？当它们看起来不够充分时，您是否会升级这些规程？若要满足该要素的要求，您应该有效地管理这些规程。如果没有进行有效管理，请查看服务台记录以验证这些规程是否就绪，那么您可能会遭遇更少的事故。
“设计和实施用于 IT “确保正在对其进行改动的每个硬件和软件是可跟踪的、安全的，而且已安装的版本都是正确的、经过授权和经过测试的”：该要素中隐含着许可的问题。对于符合许可协议的条款，您有多大把握呢？该要素表明对象必须是可跟踪的、安全的，而且只能安装正确的、经过授权和经过测试的版本。要满足可跟踪的要求，对象必须在 CMDB 中具有适当的 CI。要满足安全的要求，必须对其设定恰当的访问级别，对于软件而言，要将其副本保存在安全的位置。要满足正确的要求，必须在生产环境中移除对象的冗余版本。要满足经过授权的要求，该对象必须具有正确的签名级别，并且符合许可条款和条件。要满足经过测试的要求，必须按预定的标准对其进行单独测试。诸如此类的要求还有好多。您的公司与之相比差距有多大？如果尚未做好这些事情，那么这就是您的理由。如果根本就没做这些工作，或者只有部分 IT 人员做了，那就要在服务台求证。 有时直接的挑战可以奏效，例如让某人对公司完全符合许可条款和条件进行书面确认。
“在计划和首次展示新发布的过程中沟通并管理客户的期望”：这是一个非常易于核查的要素。首先，沟通是否按计划进行？其次，沟通是否令客户满意？如果您在计划和规程中考虑了沟通，那么您就满足该要素第一部分的要求。第二部分是，请不要让计划成为一纸空文。询问客户是否在看到返回的信息后感到很愉快，以及是否由于期望得到满足而感到满意。从此信息中您可以确定是否满足该目标要素的要求。
“通过与“变更管理”达成一致确定该发布的准确内容和首次公开展示计划”：如前所述，ITIL 的成功在于各个流程的集成。在此您必须复查“变更管理”和“发布管理”之间的关系。首次公开展示计划中包括“变更管理”是非常重要的。这就能够安排其他变更的进度，以致它们不会发生冲突或导致首次公开展示的延期。您是否在“变更管理”的控制下制定首次公开展示计划以得到一些意见？如果不是，那么您将会遭遇变更冲突和潜在的延迟，并且不会满足该要素的要求。
“利用‘配置管理’和‘变更管理’的控制流程将新的软件发布或硬件添加到有效的环境中 － 发布应该受“变更管理”控制，并可含有硬件、软件、固件和文档 CI”：更高度地集成。请注意，该要素表明一个发布可含有硬件、软件、固件和文档。若要确保首次公开展示能够成功，CMDB 必须在首次公开展示的过程中得到更新，以反映所有 CI 的当前状态，而“变更管理”是管理 CI 状态的工具。这就是将“配置管理”和“变更管理”完全融合到发布和首次公开展示过程中的关键所在。如果已将“配置管理”和“变更管理”完全融合到发布和首次公开展示过程中，那么您就已经满足该要素的要求了。如果没有这样做，那么您就必须提出一个明确的、充分的理由，证实将“配置管理”和“变更管理”完全融合到发布和首次公开展示过程中的重要性。此外，服务台记录可用以证明这一点。
“确保将所有软件的主副本保存在‘留存软件库 (DSL)’中，并确保对‘配置管理数据库 (CMDB)’进行更新”：保护软件主副本的要求始终与 IT 相伴，但是在大多数情况下我们并未对其进行有效的保护。需要核查是否所有软件主副本都被保存在安全的位置，而且只有副本用于生产环境中。这应该很容易查明。
“利用‘配置管理’确保所有正在对其进行首次公开展示或改动的硬件是安全的且是可跟踪的”：该最终要素可确保 CMDB 可随时反映所有 CI 的当前状态，并可确保 CMDB 中列出的所有对象都是实际存在的。通过审核或盘库即可轻松地对其进行核查，以便将 CMDB 中所列的硬件与某特定位置的实际硬件进行比较。如果所有核查的结果都是正确无误，那就表明您的工作无懈可击。如果查出了问题，那就表明您并未满足该要素的要求，并且在受到正式审核时可能会露出破绽。
随着 IT 在业务结构和流程中逐步的渗透，“发布管理”已随之成为一个越来越重要的关键流程。不要认为“发布管理”很少发生。“发布管理”是持久的工作。如果我们必须确保公司会从 IT 将来的发展中充分受益，那么我们就必须对发布进行有效地管理。
服务级别管理目标
第 6 章
“服务级别管理 (SLM)”是 ITIL 框架中的关键流程，因为它定义其他流程必须努力交付的服务级别。SLM 主要涉及为“服务管理”和客户群体设定目标。ITIL 阐述的 SLM 的目标如下：
SLM 的目标是通过持续的循环（认同、监视和报告 IT 服务成果）以及用于根除符合业务或开销理由的不良服务的行为指导来维护和改进 IT 服务质量。通过这些方法，可以在 IT 与其客户之间建立良好的关系。
这并不是冗长的目标，但是每个词都有具体的含义。通常情况下，业务群体对 IT 性能的期望和渴望是他们对服务和支持质量的理解，而不是可供他们使用的技术解决方案的范围。将期望值作为标准是很不可取的。根据实际对这些期望值进行调整非常重要，这也正是这些目标的意义所在。接下来我们看看这些目标的各个组成部分。
“SLM 是维护… IT 服务质量”：满足是我们所有人的敌人，尤其是对于维护质量来说更是如此。因此，真正的胜利者永远也不会满足。但是，在我们开始改进 IT 服务质量之前，我们必须确保我们已经拥有了流程、工作惯例和衡量标准，这有助于确保维护我们与客户达成的服务级别。这就是该要素所说明的内容。您是否定期与您的客户进行沟通以核查您是否正在维护所承诺的服务级别？您是否认为设定服务目标具有挑战性？您是否经常调查您的客户？如果不是，您可能没有达到服务质量的级别。下面是若干年前的一个经典方案。那时，服务器开始作为新的技术成为该时期的主导。许多公司开始忽视由旧的主机技术提供的服务，而将重点集中在服务器上。结果使客户很不满意，危及到关键业务系统以及代价非常昂贵的两千年问题。请始终将维护既定的服务级别摆在您的议程的首位。
“SLM 是… 改进 IT 服务质量”：请注意，该要素不是在讨论新的技术，而是在讨论当前的技术。我们必须不断提高而不是保持停滞。通常情况下，IT 先设定很容易达到的目标，然后每个月达到这些目标后都会进行自我庆祝。不过，如果那时这些目标并没有 100% 实现，也就不会得到满意的庆祝。在很多情况下，因为经常达到目标，就没有人真正去关心它，IT 人员只是走一下形式来制定并发布衡量标准。如果您要满足该目标要素的要求，就必须具有明确的策略声明以提高质量级别。
“通过持续的循环（认同、监视和报告 IT 服务成果）”：认同、监视和报告。该要素是清楚得不能再清楚、简单得不能再简单了。经常与您的客户进行沟通了解他们的技术要求以达到他们的业务目标。通常情况下，只有在 IT 及其客户进行沟通时才会出现问题。这就是为什么很多公司内存在那么多冲突的原因。基于面对面的关系经常会失败。这就是该要素之所以重要的原因。
您无法管理期望，但是您可以管理实际情况。将认同、监视和报告形式化以消除所有混乱并为关系提供一个具体的基础是非常重要的。要做到这一点，ITIL 建议您将服务和默认值在服务目录 (SC) 中进行分类。从该目录中可以看出，您的服务水平协议 (SLA) 可能是与您的客户达成的。ITIL 还建议您准备好在各个 IT 部门之间达成的称为运营水平协议 (OLA) 的内部协议，以及与外部供应商订立的称为基础设施合同 (UC) 的合同。这有助于确保您符合在服务目录或 SLA 中设定的值。开始与客户讨论服务级别并达成一致意见之前必须先准备好 OLA 和 UC。如果没有准备好 SC 或 SLA，您将会与您的客户发生冲突，因为您有可能没有一个既定的服务级别。即使您已准备好 SC 或 SLA，仍可能会发生冲突，因为该协议可能未经所有受影响的各方认同。
有时，您可能达到了您的服务目标，但是在满意度调查中仍然会得到很差的结果。这可能表明您调查的对象不对、提出的问题不对或者达成或制定的 SLA 不好。如果您未准备好 OLA 或 UC，您将会发现 IT 部门及其供应商之间的冲突。相关的典型案例是二级支持并没有按照服务台的要求先处理紧急事故，从而导致事故变得越来越严重。流露出的迹象有：IT 与其客户之间发生冲突、调查结果很差、IT 内部发生冲突、或者与外部供应商之间的关系恶化。如果您发现任意这些迹象，说明您未满足该要素的要求。
您是否定期与客户会面，就服务级别达成一致意见并记录服务级别？您是否实施了必要的监视以测定这些既定的服务级别？您是否发出带有推荐和建议的报告以确保对于既定服务级别的任何故障都会被消除？如果您无法完全肯定所有这些问题，说明您未满足该目标要素的要求。切记这应该是事件的持续循环，而不仅仅是每年一次。通过这个持续的循环我们就可以得到驱动这些 SLM 目标的最后两个要素的信息，因此故障是不可接受的。
最后，该要素中的关键字是“成果”。这激励 IT 采取积极的态度，争取取得成功。首先，兑现您的服务承诺，然后通过您的成果来提高它们。即使是在不良的情况下也可能会获得一定的成果。例如，如果出现一个意外的故障，成果可能不仅仅是让客户再次运行时快速通过，还可以采取措施防止相同的问题再次发生。成果来自不满足于仅仅达到既定的目标，而是要超越这些目标。您积极进取吗？您是否在努力超越既定的目标呢？这可能就是努力争取发展与原地踏步的差别所在。
“用于根除符合业务或开销理由的不良服务的行为指导”： 该要素与我们作为认同、监视和报告结果的操作相关。下图对这种关系进行了说明：
这是一个在任何阶段都可以产生潜在改进的持续循环。但是，改进仅对它们自身有好处，这并不够好。我们必须还要确保它们有良好的业务方案；也就是说它们符合业务或开销理由。要确保我们符合业务或开销理由，我们需要准备好特定的其他 ITIL 组件，即：实施改进的“变更管理”、了解开销含义的“财务管理”、确定改进范围和影响的“配置管理”。此外，在实施改进之后，还需要计算和证明投资回报率，并衡量总体拥有成本。当然，如果不使用这些组件您仍可以根据业务或开销理由来进行改进，但您可能会浪费时间与资金。
要满足该要素的要求，您将需要制定服务改进计划 (SIP)，通常与“故障管理”和“可用性管理”一起使用。ITIL 将 SIP 描述为：
所确定的存在潜在困难的方面对服务质量有负面影响，“服务级别管理”必须与“故障管理”和“可用性管理”一起促使 SIP 确定并实施克服困难和恢复服务质量所必需的任何操作。
当然，SIP 组件也必须符合业务或开销理由。您是否满足该目标要素的要求？您是否确保持续地改进符合业务和开销理由的服务？您是否具有有效的服务改进计划，或者您仅当出现故障时才做出反应？不断地努力改进服务的 IT 部门被视为企业的资产，因为它们增强了公司的业务能力。
“通过这些方法，可以在 IT 与其客户之间建立良好的关系”，该要素比任何其他要素都具有总结性。如果您满足该目标中所有其他要素的要求，那么您自然会满足最后这个要素的要求。当您在 IT 与其客户之间建立了良好的关系时，您将更得民心，而且将面临更多有意义的挑战。该要素是对 SLM 目标中所有其他要素的重要性测试。如果满足该要素的要求，您很可能会满足所有其他要素的要求。
“服务级别管理”无疑是一个关键流程，因为它管理着客户的要求和需求。但是，它却是最常被 IT 部门忽略的流程。了解了这些目标及其解释后，您可能很容易就会意识到 SLM 对于 IT 和客户的重要性。如果您可以达到这些目标，那么您很可能也会成功地实施众多其他流程，因为它们之间有着密切的联系。例如，要达到既定的可用性级别，您必须至少完成“可用性管理”所必需的某些任务。SLM 是成功的关键，因为它有助于 IT 作为业务部门与其他更传统的业务部门保持一致，而不再作为孤立的附加部门。
IT 服务的财务管理目标
第 7 章
“财务管理”目标是独特的，因为其中包括两种不同类型的目标：一个针对内部组织机构，另一个针对商业环境。商业环境可以被看作外部或内部收费，也就是费用分摊 (chargeback)。下面是由 ITIL 所阐述的目标：
对于内部组织机构，目标应该是：
• 提供用于提供 IT 服务的 IT 资产和资源的有成本效益的职位。
在商业环境中，目标陈述可能要反映公司的利润和市场目标。
任何 IT 服务公司的目标都应该包括：
• 能够充分考虑在 IT 服务上的开销，并且知道这些开销都是为公司的客户交付服务的结果
• 通过提供详尽的“对 IT 服务的变更”的业务案例来协助制定有关 IT 投资的管理决策。
正如您所看到的，IT 服务的“财务管理”不只是与预算有关，还与成本效益有关。但是，预算是该流程的一个关键组成部分。SLM 目标表明“符合业务或开销理由”，而“财务管理”流程就是管理开销的理由所在。讨论开销时，ITIL 通常使用短语“满足应用”。这是一个关键短语，因为它与明智地投资 IT 服务有关。例如，它可能花费 x 美元来提供 99.999％ 的可用性。要提供 100％ 的可用性需要再多花费多少资金？获得 100％ 可用性需要的成本可能不成比例，99.999% 的可用性就能满足应用。另一方面，当客户仅要求和需要 50% 的可用性时，为什么要提供 99.999% 的可用性呢？这可以看作是一个不明智的决定，因为为了获得 99.999% 的可用性而需要额外支付的资金可用于改进 IT 的其他领域，或者可以避免支付这笔资金以降低总体成本。
出于本书的目的，内部组织机构仅支持内部员工，并不实行费用分摊制度。另一方面，在商业环境中，存在对内部客户进行费用分摊或对受支持的外部客户收费的现象。接下来我们研究一下“财务管理”目标的各个基本组成部分。首先，来看一下内部组织机构：
“提供用于提供 IT 服务的 IT 资产和资源的有成本效益的职位”：话虽然很短，但包含大量的含义，因为对公司没有什么成本效益的工作职位可能很快就会因公司管理制度的变动或因业务外包而被免除。“成本效益”可以简单解释为与 IT 服务相关。例如，某些公司主张成本越低越好。其他公司则主张投资于质量服务会更好。成本效益通常受预算限制（而非可靠的业务决策）驱动。但是，对于该目标，您需要在整体目标中查看成本效益。不管预算或其他标准制定了哪些限制条件，都仍然必须对 IT 财务进行管理以保护和增加 IT 投资。您是否对您的 IT 部门内的成本效益有一个明确的理解？您是驱动各种因素来降低成本、维护质量还是在某种程度上介于两者之间？如果您并没有明确的理解和陈述，那么管理财务就变得非常困难。一个缺乏明确理解的迹象就是在用了好长时间作出涉及成本的决策时引发了更多争议。
“职位”具有几个潜在的含义，其中包括管理人、监护人、保管人、负责人、主管人以及保护人等等。查看这个同义词列表，您可以发现之所以选择“职位”是因为每个同义词都与该目标相关。请注意，职位同义词与监督和保护而不是与管理和命令相关。“职位”意味着指导和引导，而“成本效益”描述的是支出水平和支出目的。这些差别非常重要，因为“财务管理”与每个人的角色和责任都相关，IT 部门的每个人都需要用心理解它。
“用于提供 IT 服务的 IT 资产和资源”：在我们探究这一部分之前，我们应该提醒我们自己 ITIL 中资产的含义。
业务流程的组成部分资产可以包括人员、办公设施、计算机系统、网络、纸张记录、传真机等等。
如果要由有成本效益的职位来管理资产，那么必须对资产进行登记和控制。“配置管理”是专门用于管理 IT 资产的 ITIL 流程。是否已将您的资产置于中央数据库中？您是否了解与这些资产相关的成本？如果不了解，则说明您并没有有效地管理您的 IT 财务。接下来我们了解一下 ITIL 中资源的含义：
IT 服务环节需要为客户提供必需的服务。资源通常是指计算机和相关的设备、软件、机构或公司（人员）。
乍看起来，“资产”和“资源”的定义非常相似，但是存在一个主要的差异。资产是一个组件，而资源需要很多资产来提供服务。例如，提供电子邮件服务需要很多资产。在很多情况下，资产可能会在众多的资源中共享。例如，服务器是一项资产，但很多服务都将该服务器作为其资源的组成部分。
要满足该目标组件的要求，您不仅需要知道与您的资产相关的成本，还要知道如何分配您提供给客户的服务的成本。在这种情况下，您可以建立一个成本结构，以便清楚地知道成本是如何分配的。
商业环境的目标要素包括在前面介绍的内部 IT“财务管理”的目标要素，以及下面将要介绍的目标要素：
“能够充分考虑在 IT 服务上的开销”：这意味着您必须事先准备好允许您管理成本的财务软件和流程，才能考虑您的 IT 开销。例如，您是否知道您的电子邮件服务每个月的运行成本？这包括资产、处理器时间、变更成本、打到服务台的电话以及电信成本。充分考虑这笔开销意味着您将 IT 作为业务来驾驭。
“这些成本都是为公司的客户交付服务的结果”： “这些成本都是为公司的客户交付服务的结果”： 接着前面的要素继续，您如何为您的客户分配电子邮件服务的成本？对此，您将需要一个计算成本的公式。一个例子是根据每位客户使用该项服务的比例来计算其成本所占的百分比。另一个例子是使用“用多少，付多少”的计量方法。不管使用什么方法来满足该目标要素的要求，您必须知道您的所有服务的成本，因为它们与您的客户相关。您是否有分配成本的公式？如果没有，您将无法满足该目标要素的要求。
“通过提供详尽的‘对 IT 服务的变更’的业务案例来协助制定有关 IT 投资的管理决策”：这是一个非常简单的要素，但它确实依赖于要满足要求的“财务管理”中的所有其他要素。如果其他要素没有就绪，提供业务案例的数据就不可用。请不要将该陈述仅理解为成本数据，如服务器的成本。业务案例还需要用于计算投资回报率的数据以及其他关键业务信息。如果不符合所有其他标准，您就无法满足该要素的要求。
IT 的“财务管理”对于管理成本和在市场中保持竞争力变得越来越重要。通过使 IT 成为业务资产而不是业务支出，执行有效的财务 IT 管理的公司将受益匪浅。因此，达到这些目标对于 IT 和业务都有好处。
容量管理目标
第 8 章
“容量管理”是大多数 IT 部门一直面临的一个挑战，因为基础设施和服务需求每天都在发生变化。如果没有财务限制，“容量管理”就会很简单。但是，实际上财务限制以及合理利用旧系统中的投资这种需求将继续使容量管理成为一个挑战。
ITIL 对“容量管理”做了简单说明：
确保成本合理的 IT 容量始终存在并确保它与当前及将来确定的业务需求相符
说起来简单，做起来却很难。在我们分析“容量管理”的目标之前，ITIL 讨论的整体基础设施不只是一些技术组件的容量就没有什么意义了。通常情况下，我们认为容量是指带宽、处理能力、内存或磁盘空间，而忘记了其他重要的基础设施项目，如人员配备标准。当我们考虑“容量管理”目标时，应牢记这些目标将应用到整个 IT 基础设施中。
“确保成本合理的 IT 容量始终存在”：此处的关键是“成本合理”。很多公司都没有有效的容量计划，并且对他们将来的需求也知之甚少。因此，他们往往是要么购买的基础设施组件过多，要么就是购买的不足。那些购买过多的公司希望确保他们能够满足不断增长的需求，但却从未考虑过增长的程度有多大。这通常会导致资源的闲置，如服务器的利用率低于容量的 40％。那些购买不足的公司希望能够节省资金。这可能会导致容量不足，意味着服务质量将会有所降低。您是否仔细计算过容量以确保在基础设施项目上的开支能够满足当前和计划的需求？或者您仅仅是做一些假设？请记住，如果在某个领域超支，您在其他领域就会出现短缺。
短语“始终存在”准确地表达出了这个意思；也就是说，足够的容量始终可用于提供与客户达成的服务级别。因为“容量管理”还包括“性能管理”，这意味着不仅要提供足够的资源来满足需求，还要提供足够的资源来满足在达到 SLA 中既定的性能目标时的需求。 您的服务台是否接到了客户抱怨他们的工作站“速度变慢”的电话？通常，这些客户会在以后打来电话说他们的工作站再次“加速”了。如果接到有关工作站速度减慢的电话，则可能是由容量引起的。您是采取“下意识”的方式来解决容量问题，还是使用系统的方法来解决它们呢？下面是一些要在确定您的容量是否“始终存在”的过程中寻找的迹象。
“它与当前和将来确定的业务需求相符”：要与当前和将来的业务需求相符意味着必须经常地测定容量，并与客户讨论他们当前和将来的需求。进行磋商以确定应将客户需求作为服务水平管理 (SLM) 的一部分来满足。SLM 应为“容量管理”提供相关的数据以确保存在适当的容量。“容量管理”还应该与 SLM 一起配合使用，以从客户那里获得所需的信息，从而来执行容量管理活动。SLM 是否在您的客户和“容量管理”之间提供了一个纽带？您是否定期发布容量计划？您曾经是否有过由于容量不足而与客户发生冲突的情况？这里仅仅是一部分能够表明您的“容量管理”是否适当的迹象。
“容量管理”是一种正在进行的活动，它可确保典型的成本管理和业务效率。达到这些目标意味着 IT 可以顺利地发展，而不会徘徊不定、停滞不前：也就是说，一旦达到这些目标，要想发展 IT 就变得非常容易了，也不会带来代价高昂的损失
可用性管理目标
第 9 章
管理可用性对于 IT 是一项非常重要的活动，因为错误计算或误解可用性可能会使企业遭受重大损失。例如，一个新的应用程序可能要求服务台支持从每天 16 小时每周 5 天扩展到每天 24 小时每周 7 天，这项服务的代价很高。从早期的主机时期开始，管理可用性已经成为一个对 IT 的挑战，那时只有在白天主机上才提供联机服务，到了晚上，计算机需要进行批处理。如果夜间批处理窗口未完成批处理工作，则联机系统的可用性将会延迟到第二天。否则，如果客户晚于预定的时间关闭它们的联机系统，批处理工作就会推迟启动，而且会丢失其处理目标。目前，我们拥有更多的专用资源，但是确保可用性的问题仍然存在。接下来我们看看 ITIL 设定的管理可用性的目标：
“可用性管理”流程的目标就是优化 IT 基础设施的容量、服务和支持的公司，以便提供有成本效益且可使企业满足其业务目标的恒定的可用性级别。
一些类似的词和短语再次出现在该目标中：“优化”、“成本效益”和“业务目标”。这些词和短语已经在前面讨论过，因为它们的意思始终是相同的，所以不需要再次进行说明。仍然有一些重要的要素需要考虑：
“优化 IT 基础设施的容量、服务和支持的公司”：“容量”和“优化”这两个词在一起表达得很好，因为并不是始终都要求最大化，而且通常也无法实现最大化。参加马拉松的人们不可能全部都成为世界记录保持者，但是那些以此为乐趣的人们仍然尝试提高他们的赛跑能力。为什么不最大化呢？原因很简单，如果我们同时拥有一份全职工作，最大化要求很多我们无法提供的能力。该目标要素告诉我们不要试图去实现最大化，因为这样就不会留有扩展和发展的灵活性。它还告诉我们要利用我们所拥有的资源来做好工作。
该目标列出了三个组成部分：IT 基础设施、服务和支持的公司。“IT 基础设施”和“服务”从字面上就可以理解，但“支持的公司”需要一个简短的说明。这是指从 IT 公司外部供应资源的公司，如工程服务公司、外包商和电信公司。对于这些实体，优化它们的容量意味着确保它们满足其合同条款的要求，如 SLM 和客户之间达成的可用性条款。如果 IT 资源和支持的公司之间存在冲突，则说明您未满足该目标要素的要求。
“交付有成本效益且可使企业满足其业务目标的恒定的可用性级别”：这句话道出了该目标的核心所在。成本效益依赖于 SLM 和客户之间达成的可用性级别。因此，在不首先考虑“可用性管理”的情况下，不应该存在客户与 SLM 达成的可用性级别。当在 IT 和客户之间达成可用性级别时，是否涉及了“可用性管理”？如果没有，您可能面临着危险。
恒定的可用性级别意味着由 IT 提供的服务和系统的可用性是基于一致、持续的原则交付的。换言之，对于为提供既定的可用性而出现的任何故障都应予以调查并采取措施，以防止将来再次出现这样的故障。请注意，即使当您交付未实现的可用性时这也适用，但它不能很好地达到您的目标。例如，您已经与您的客户达成 99.9% 的可用性目标，而您却只达到了 99.8%。这项工作完成的很好，但仍有 0.1% 的差距，因为如果您不立即解决这些故障，它们可能会越积越多，使您进一步远离目标。ITIL 将其称之为“可靠性管理”，它是“可用性管理”的一部分。您是否调查了所有可用性故障的原因？您是否采取措施来防止它们再次发生？如果对以上两个问题的回答有一个为“否”，那么您就不会达到该目标。
使公司满足其业务目标意味着“服务级别管理”应该到位。如果不到位，负责“可用性管理”的 IT 人员应该定期与他们的客户进行协商，以确保他们提供的服务能够满足客户的需求。该要素应该是对 IT 的一个永久暗示，IT 应该服务于业务群体而不是由业务群体为其服务。 如果您不定期查看业务群体的可用性目标，您就不会满足该目标要求的要求。一个来自调查反馈的迹象表明，尽管您达到了您的目标，但客户仍然不高兴。另一个迹象表明您虽然每个月都超出可用性目标，但却从未提高过它们。虽然这可能对于客户来说可以接受，但却表明您并没有消除可用性性能问题。
“容量管理”和“可用性管理”一起提供了客户评定“IT 服务管理”的大多数依据以及重要事件。通过查看最简单的服务水平协议您都可以获得此信息。IT 客户认为，虽然同样都达到了这些目标，但有的是成功了，有的却失败了。
IT 服务持续性管理目标
第 10 章
随着对 IT 服务干扰的威胁日渐增长，这些威胁对业务的影响也由于更多重要业务流程的计算机化而不断增长，IT 服务持续性管理在战略上处于重要地位就不足为奇了。“服务持续性管理”不再仅仅涉及灾难恢复（尽管灾难恢复仍然非常重要）。它还涉及技术故障对业务造成的影响。例如，如果您有 90% 以上的业务来自 Internet，提供这些服务的 IT 基础设施中的任何故障都将会立即显露出来，并且可能会引起收入和业务声望的损失。因此，了解“IT 服务持续性管理”目标是支持业务的根本：
ITSCM 的目标就是支持整体“业务持续性管理”流程，方法是通过确保必需的 IT 技术和服务设备（包括计算机系统、网络、应用程序、电信、技术支持和服务台）可以在所要求的、既定的业务时限内进行恢复。
尽管该目标并不是很冗长，但不满足各种要素的要求可能会带来灾难性的影响。因此，我们需要仔细了解各个要素：
“ITSCM 的目标就是支持整体‘业务持续性管理’”： 这里的关键字是“业务持续性管理”。ITIL 建议公司执行“业务持续性管理”，因为有很多风险是 IT 无法控制的。例如，IT 无法确保对其不具备前提条件的远程位置的安全访问。如果建筑物着火倒塌会发生什么情况？IT 仅仅是恢复团队的组成部分。您的公司是否具有“业务持续性管理”？如果没有，就要朝着该目标要素努力，IT 必须主动确保公司意识到需要“业务持续性管理”，并且还要确保 IT 已经准备好周密的“业务恢复计划”。
“确保必需的 IT 技术和服务设备（包括计算机系统、网络、应用程序、电信、技术支持和服务台）可以在所要求的、既定的业务时限内进行恢复”：该目标要素的第一部分解释了所有 IT 基础设施要素及其相关的活动都是“IT 服务持续性管理”的组成部分；但实际上是最后的几个词定义了该要素，“可以在所要求的、既定的业务时限内进行恢复”。再次强调一点，SLM 在此处发挥一定的作用。SLM 与 ITSCM 一起负责与业务客户合作，首先确定需要恢复的 IT 技术和服务设备以及要求的时限，然后与业务客户对这些时限达成一致。您是否定期与客户会面以调查业务持续性需求和目标？您是否记录和发布这些需求与目标？如果您没有执行这些操作，您不仅未满足该目标要素的要求，还危及了公司的将来。
该要素中的关键词是“可以进行恢复”，因为如果没有使恢复流程和操作准备就绪，就不可能理解和同意。该要素要求我们将恢复操作、计划和流程准备就绪以提供业务群体所要求的恢复级别。当然，这受限于投资和所有其他正常的业务牵连。请记住，这不仅仅是“灾难恢复”，还是“业务持续性”。您是否已安排好“业务持续性”计划？如果没有，您将无法满足该要素的要求。
考虑 ITSCM 时，保护股东的投资非常重要。如果没有保护好股东的投资，则说明没有提供良好的 ITSCM。这不足以反映出高级 IT 管理，尤其是当某个 IT 基础设施组件出现严重的“业务持续性”故障时。