ITIL 的目标.docx
《ITIL 的目标.docx》由会员分享，可在线阅读，更多相关《ITIL 的目标.docx（27页珍藏版）》请在冰点文库上搜索。
ITIL的目标
ITIL的目标
简介
在大多数情况下，对于已受过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“故障管理”方案提供了更多的信息。
“找到引发事故的根源”：
此“故障管理”的目标要素与前面的目标要素是密切相关的。
真正的“故障管理”来自确定问题的根源，然后确定消除该问题的开销与从中得到的收益或节约效果相比是否划算。
有时让服务台继续处理发生的事故比消除该问题的开销还要少一些。
人们常会误解问题的根源。
例如，根据HelpDeskInstitute的调查，在服务台遇到的所有事故的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要素，因为遭受失败的常常是变更的发布，而不是变更本身。
有
升级会员 