执行摘要
服务品质管理 (SLM) 是改善 IT 服务质量的一大措施——但它是如此的庞大，以致许多 IT 经理都望而却步。即使所有人都认为 SLM 具有极其重要的意义，但事实上只有小部分人真正开展了 SLM 项目。本白皮书旨在消除人们对 SLM 的一些负面误解，并针对如何开展服务管理提供了各个阶段的简要实施方案。
许多管理人员都会觉得 SLM 是一种“一荣俱荣，一损俱损”的项目，因而必须全面考虑所有业务服务和所有构成要素。如果一开始就有这种观点，则不但会被它吓倒，还将一无所成。要获得成功，服务管理应首先着眼于某些构成要素，然后慢慢制定衡量、监控和报告等程序。预算不多的管理者会将价格作为重要的考虑因素，其实 SLM 与成本高昂两者并无必然联系。IT 部门原有的工具可以继续加以利用——它们可以用来衡量服务品质，只需添加其它一些工具即可。另一方面，改善服务可以为您节省时间和金钱。
另有一些管理者则惧怕与业务部门之间达成服务品质协议 (SLA) 后，会使自已置身于易受攻击的地位。他们从某些同行那里听到了一些关于服务承诺是如何的难以履行，以及带来的失败是何等惨痛的传言。这种问题有两个解决办法：第一是争取来自行政决策层的支持者，第二是订立切实可行的 SLA。来自行政决策层的支持者可帮助 IT 部门和业务部门之间相互协作，共同营造没有互相指责的环境并为整体业务目标而努力。他还可以保障为提高服务品质所需的意志和资金支持。确定当前的能力基线则是协商切实可行的 SLA 的关键。
企业管理联盟 (EMA) 提倡使用分四个阶段的服务品质管理实施方案。第一阶段：启动过程。其要点在于对记录数据和改进过程的理解，它是让众多 SLM 功能得以发挥的基础。IT 工作人员本身也通常需要经历一段之间来真正理解多付出一分汗水所带来的回报。第二阶段：监控、衡量和改进。讨论业务部门需要哪些度量数据来了解情况，以及工具的改善对消除出现问题后经常发生的互相指责现象的作用。第三阶段：服务品质报告。明确协商和订立 SLA 的一些要求，以及制定适用于 IT部门和业务部门的报告方式。第四阶段：积极主动、以业务为导向的服务品质管理。讨论业务目标如何在整个业务体系中对确立服务品质和 IT 资金投入优先顺序起主导作用。
恐惧、迷惘和疑虑
企业组织中的每个人似乎都在吹捧服务品质管理 (SLM) 的神奇功效：CEO 希望它可以使 IT 部门对公司的经营目标起促进作用，而各个业务部门的经理则认为有了它，就可以解决遇到的所有 IT 难题。这样，IT 部门开展 SLM 计划的重压也就越来越大。但另一方面，CIO 和 IT 主管对 SLM 则尚有疑虑。企业管理协会 (EMA) 经常遇到这种情形：IT 管理者可以列举 SLM 所谓的一些好处，但当要求他们提供 SLA 的案例或服务品质承诺时，却得不到任何的答案。
EMA 的调查显示，100% 的 IT 管理人员认为 SLM 非常重要或者对其组织极为关键，但其中只有 56% 的人真正实施了SLM 计划。
为什么尽管企业知道 SLM 有那么多的好处，仍然不肯实施 SLM 呢？答案是出于恐惧、迷惘和疑虑——这些因素阻碍了许多好的初始步骤开花结果。一些 IT 主管和经理听说某些同行由于无法兑现服务品质协议 (SLA)，结果受到了惩罚。于是他们便担心会丢掉自己的饭碗或者损害部门的声誉。而有更多的经理则不知道如何着手是好。SLM 已被描述成一种需要对 IT部门进行重组的冒险行为；此外，还要添置极为昂贵的工具，开展复杂的官僚式手续。结果，管理者们不禁质疑：这样一个未知数再加上所产生的成本和引起的混乱，究竟是否还能为 IT 服务带来任何实际的提高？
本白皮书就旨在针对人们关于 SLM 的种种误解和流言进行释疑解惑、去伪存真，同时为在企业组织如何启动 SLM 计划提供一些简单可行的步骤。事实上只要经过周密计划，采取有条不紊的步骤，您就会发现 SLM 实施起来并不困难。开展 SLM计划时，企业组织可以当前正在使用的工具为基础，制订出符合当前组织架构的规程。对于任何系统来说，关键都是将一个较大的任务化整为零，以具体的细节步骤推动企业前行。但即使它们只是一些很细小的动作，也会因为改善了管理而带来回报，并为实施更大的举措和获取更大的回报铺平了道路。如果您对如何开展服务品质管理计划感兴趣，请参见我们下面对有关步骤以及例子的说明。
对 SLM 的一些认识误区
与其它任何类型的 IT 管理工作，如系统、网络或应用管理一样，服务品质管理计划可大可小。SLM 的核心在于过程本身——而不在于工具、证书或某种流行风潮。有一些专门针对 SLM 的工具，但它们并非启动 SLM 计划的必须条件。对 SLM的认识则是必要的，首先应对 IT 内部员工，然后再对整个企业的员工进行培训。但培训的形式却不一定要很正规。首先，SLM 是一种 IT 管理方法，其侧重点在于设定基线并加以改进。它可以应用标准的循环方法：1} 收集数据，以确定和理解问题，2} 对系统加以改进，3} 返回步骤 1，衡量改善的效果。
本节重点落在解除许多 IT 经理对启动 SLM 计划抱有的恐惧、迷惘和疑虑心情。下一节将会提供开展 SLM 计划的各个详细步骤。
“SLM 过于昂贵”
围绕 SLM 的误导宣传大部分来自 SLM 工具提供商。它们想方设法销售其产品，于是便鼓吹在开始 SLM 计划之前，有必要花巨资购买新的 SLM 工具套件。然而，在制订出如何使用和支持这些工具的方案之前就购买的话，只会既浪费时间又浪费金钱。SLM 计划应以您当前拥有的工具为起点——可以是自行研发的工具、简易的系统或者网络监控工具，又或者是应用监控和管理工具——即使您不拥有任何工具也无妨。
但是，您的确需要一些衡量当前所提供服务的方法。SLM 计划需要设定当前服务的基线，从而让您清楚了解应将精力集中于哪一环节、情况是否有所改善等。曾经有一位经理下定决心实施 SLM 之后，开始做的第一件事就是统计帮助前台收到的求助电话数量，并在数据表中记录所牵涉的系统。通过这一举措，她确立了当前求助电话数目的基线，同时辨别出存在问题最多的区域。接下来，她便集中精力对该区域加以改进。结果，求助电话的数量也随之减少了。虽然这种数据表的方法简单和低技术含量，但它也是一种服务品质管理。现有的性能管理工具同样可以识别出 IT 架构中存在的性能问题。这些工具大都可以按设备类型、地域或用户组提供性能报告，并且所提供的数据会具体得多。
大多数 IT 部门都会有一些现有的管理工具或规程，它们可沿用于 SLM 计划中。IT 应以其原有的资源为基础，首先制定出用于量化和记录当前服务、识别问题所在、确定改进措施和衡量改善程度的一些内部规程。随着计划识别出常见问题的根源并初显成效后，就可以富有针对性地购买更多用于加强管理的工具。其成本应以帮助前台的求助电话数目、服务中断时间或其它指标进行度量。而管理工具的改善几乎无一例外地可在一年内收回了其购买成本，因为它们让最终用户的生产效能得到提高。
“SLM 过于庞大”
SLM 是一种系统，因而也适用分解的原则。在 IT 架构中分析出一个具相对独立性的构件，它应与系统中的其它部分没有过多的牵连，然后就开始对其进行测定。对整个 IT 架构进行全面和主动的管理是 SLM 的最终目标，而不是起点。为慎重起见，应以小型、非关键系统为起点。具关键意义的服务环节不应成为开展试验研究的对象——它不容许犯任何错误。应以影响小、规模具局限性的系统为起点（它可以局限于 IT 部门之内），然后逐渐扩大 SLM 计划的范围。
“我的员工已经不堪重负”
这是许多 IT 经理所面临的困境——陷入忙于应对频繁出现事故的泥淖而无暇开展系统性的改良计划。服务品质管理需要时间，但从长远考虑，花时间组织和整理工作总是值得的。要获得成功，决窍就在于让“长远”变得不那么遥远。可实现这一目的的方法有减小故障抢救的工作量，转而将时间投入到改善管理中去。在开始之初，SLM 的战略应为识别只需简单处理步骤又可带来显著成效的对象——一些造成很大问题但又无需过多处理成本的问题。这一意义上的成本包含实际成本和风险，也就是说，您需要确定所进行的改进措施能够解决 10% 或更多的系统现有问题。
对问题和补救措施进行跟踪是一种立竿见影的做法。前面所提及使用数据表的那位经理仅在一年之内便使服务帮助前台的员工数量得到显著减少。她将花在回答电话和记录问题上的劳动成本削减至 50%，并将节省下来的资金投入到提升服务品质当中。这样的事例无疑有助于消除 IT 经理和工作人员初期常常具有的一种抗拒心理。“我们只负责补救问题”，“我们不需要防患于未然”等想法需要及时澄清。所有服务品质管理计划都以可靠的数据记录为基础。没有系统性衡量、评估问题、作针对性改进等前期步骤，就无法发动 SLA 这辆车并让它驶往目的地。
“业务部门会不会将它用作对我进行攻击的工具？”
理想情况下的 SLM 应是 IT 部门和 IT 服务用户的一种协作行为。不幸的是，许多 IT 经理所面对的事实却远非如此：业务部门将 IT 视为“祸根”，甚至认为只有外包才是解决方案。如果对应如何在 SLM 框架内工作没有一个正确的理解，则这些经理在使用外部服务提供商的产品时，也同样会出现这种问题。EMA 的研究表时，约有 50% 的企业组织在外包 IT 业务时都犯有这种错误，结果就是得不到任何形式的服务品质保障。不论是使用内部或外部服务，要让 IT 符合业务部门的服务需求，关键都在于管理。SLM 还可以让业务部门的管理人员不再将希望寄托于外包。
一种方法是在 IT 部门内部启动 SLM 计划。“在学会跑步之前得先学会走路。”首先在自己的部门内部建立起初始的规程，以获取初步胜利。让 SLM 计划有足够的时间成熟起来，或者在改良工具方面下更多精力，以提高管理水平，然后才将计划扩大到外部。在关系最为紧张的环境中，IT 部门可能会无法与业务部门进行任何协作。但不能因为这样就放弃 SLM 计划——对业务有利的一些措施仍然可以在 IT 内部实行。随着 IT 部门声誉的改善，与公司业务部门之间的关系终会得到改善。
另一个要点是确保您可以履行立下的服务品质许诺。它要求设定当前服务品质的基线，采取可以保障实现该品质服务的措施，然后才与业务部门商讨 SLM 计划的开展。这样可以让所有人员都了解并掌握报告的程序，并为 IT 和业务部门提供保险措施。
“我如何能得到业务部门的支持？”
在 SLM 计划成熟之后，您仍然需要做一些准备工作，以确保它可以在 IT 与业务部门之间的关系变坏时得以生存。第一个要求是拥有向业务部门作陈述的工具，这些工具应能使您的语言可以被业务部门所理解。业务经理无法理解丢包或抖动对其最终用户的效能有何种影响。最终用户性能度量——如往返延迟——是最佳的指标；当然，也可以使用简单的可用性度量来衡量有否进步。可以使用一个计时器来测量实际超时响应，从而识别是否发生了不良情况——在当今的 Internet 时代，三到五秒是最终用户的忍受极限。IT 小组最好能在问题严重到可以威胁 SLA 之前就了解到问题的存在，而不应等到求助电话涌入帮助前台时才知道存在服务中断或性能下降等问题。
在将计划向业务部门推进之前，请确保您获得了行政决策层的支持。许多企业组织都存在着一种相互指责的文化：业务部门指责落后的 IT 服务造成了销售情况的不理想，系统小组则指责网络小组造成了响应迟缓的问题，反过来亦如此。这时候，就需要真正的支持者面对争端挺身而出，为整个组织定调，并带来解决问题的希望。他或她不仅在口头上给予支持，还应有一些实际行动，如召开一些前期会议，确保基调的合作性以及着眼于更高的业务目标。获得这一层次的支持是克服部门之间文化壁垒和敌对状态的需要。SLM 计划的目的在于打破官僚主义的坚冰并将所有派系团结起来为达成高质量、以业务为导向的服务这一共同目标而努力。
“什么是 ITIL，它与 SLM 之间的关系是什么？”
IT 基础架构库 (ITIL) 1992 年起源于英国，它由一套共八本书组成，包含了有助于组织 IT 部门的一些最佳做法。人们常常建议使用 ITIL 过程作为实施 SLM 的基础。这些有关服务提供的书籍对如何构建服务品质管理、应用管理、配置管理和其它 IT 管理提供了指导方针。ITIL 书籍对那些认为所在组织的发展已超越了当前 IT 结构，但却不知道下一步该采取何种对策的人较有帮助。它们也为希望开发内部过程支持软件的人员提供有用的流程图。
但是，因为 ITIL 旨在对每个 IT 部门都有帮助，而无论部门的复杂程度如何，因此它也只能做一般性的建议。总而言之，EMA 认为对于刚开始要实施 SLM 的人来说，要求其尝试实施 ITIL 的所有内容是矫枉过正的。可以阅读概述以及有关SLM 的章节，然后执行适用于您目前程序与架构的一些建议。ITIL 可以提供指导方针让 IT 成长并整顿为更好、更高效且更完善的架构；但是您不应该尝试将 ITIL 强行移植到您的企业。
IT 经理有必要对 ITIL 结构有一定程度的了解，但开始时不需要进行任何正规的培训。在获得更多经验之后，就可以决定是否将 ITIL 的结构和过程严格应用到 IT 当中。当然，好的架构管理不一定都得遵循 ITIL 这一套。
一步一步地迈向 SLM
解决了对 SLM 的一些常见顾虑和疑问之后，就可以采取实际的行动来开展 SLM 计划。它不一定要很大，也不一定要花费很高——当然需要一定的投入。在此时，IT 经理需要考虑希望通过 SLM 计划达到哪些目的。
对于 IT 本身，SLM 过程为改进管理提供了一个架构。它有助于正确分配资源和提供更好的服务。这既能使 IT 员工效能得到提高，又让 IT 部门的声誉得到提升——这两点都可以让 IT 员工从工作中获得更高的满意度。作为进行衡量的一种边际效益，IT 得到了新系统和新工具的有利条件，避免了过度部署和人员过剩，并能够将稀缺的资源用于最需要的地方。以过程为导向和进行资料记录还可以使 IT 脱离“独行侠”的 IT 管理方式，IT 专家无需为维护系统功能和应对系统崩溃而孤军奋战。解除了对个人的依赖之后，不仅让 IT 管理变得格外轻松，还将带来整体服务品质的提升。
对于公司业务来说，其好处也是显著的。可重复使用的过程和积极主动的管理可减少 IT 出现故障的机会，并降低随之而来的利润损失或花费额外开销的风险。服务中断时间的减少和服务品质的提升意味员工的工作效率提高，从而产生更高的利润和更低的成本。其它部门在真正了解服务品质的意义、影响品质的因素以及提高服务品质所需的真正成本之后，将对 IT部门更为信任。
对 SLM 计划的实施和推广不能像依菜谱下厨般简单，因为不同企业的 IT 成熟程度各不相同。然而，以下的这些阶段适用于大多数尚未具备完善的 IT 管理方案或 SLM 规程的企业。EMA 估计有 50% 的企业都属于这种情况——这可不是一个小数目！
图 1：SLM 的各个阶段
第一阶段：启动过程
确认一个存在有困难，但并非对任务具关键意义或处于突出位置的系统。例如，备份程序可能是问题所在，或者补丁管理不善是组织面对的难题。需要制定一套识别故障或问题并作记录的程序和步骤。例如，您可能会发现平均一周内发生两次备份程序超越了规定时间的事件，从而对员工开展生产工作造成障碍。一旦得出解决方案，就需要列明相关步骤。而记录的方法则可以使用简单的 excel 数据表，并让每个员工都可以存取；或者使用真正的数据库。记录内容包括日期和时间、遇到问题的个人、对问题严重性或级别的说明，以及其它可以收集到的任意系统信息。解决问题的步骤中还应加入其它有用的信息，如解决问题的个人、解决方案是如何得到的、尝试过其它哪些方法，以及问题的其它有关数据。管理最终需要建立分类方案，识别问题的类型，从而有利于对问题进行总结。随着经验的积累，需要对分类方法进行频繁的更改，如将某些代码分解为较小的片段，或者将若干个类别综合为一种常见问题类型。这也是建议采用小型系统作切入点的原因之一。
召开一个启动会议，以介绍新的过程，并说明多一分努力将获得哪些最终回报。跟进小组的工作，以确保他们对问题作了归档。您甚至可以为一些好的归档行为设立小奖励，如给予个人奖品，或在小组表现出某种团结一致时请他们吃比萨午宴。由于需要做除单纯解决问题之外的“额外”的工作，因而理所当然会存在一些报怨声音。让您的团队为共同的目标而努力是使得 IT 和业务部门可以开展协作的第一步。
经过一个月的问题输入后，即可使用任何一种度量标准设定当前系统的基线。使用的度量标准可以是记录条目，或者真实的系统度量。在输入了数十个问题的数据后，就要分析数据记录显示的趋向、起因、常用解决办法或其它对改进系统有用的任何信息。统计所遇到各种问题的数量，以辨认出最大的问题。逐一处理这些问题，并对结果进行存档。在备份的问题中，可能需要更换某盒磁带或磁盘，或者存在某个步骤常常超时。一旦实施了相应的补救措施，就能将备份超时问题的发生频率降低到每周仅一次。将错误发生频率减小达 50% 的情况加以存档。确保系统在发生大规模变更的前后能保持稳定。同时继续存档、应用修复并记录结果。对输入问题和重新利用解决方案的行为进行鼓励和奖赏。
虽然这一步看似微不足道，但产生的好处却不小，尽管好处不一定是对 IT 部门而言。IT 小组将获得一些过程管理的经验，并了解到反复的过程有何裨益，它是如何使工作更加高效，以及过程如何有助于识别常见问题的根本原因等。这种以过程为导向的行为对于大范围开展 SLM 计划具有关键意义。
由于“80/20 规则”的普遍性，它也会为服务提供带来好处。这一规则的内容为：80% 的问题和不足通常是由系统的 20% 所导致。因而识别和改进这 20% 对工作量具有极其重大的意义。如果服务中断让公司每年蒙受 50,000 美元的销售、产能损失或 IT 员工排除故障的开支等，则每年节省 40,000 美元绝对可以为 IT 带来高度的美誉。无论您将注意力集中到哪些过程，所带来的改善都会因为减少了修复问题所花的时间，从而使效能管理和服务改进获得更多的时间。
第二阶段：监控、衡量和改进
下一步是提炼和展开收集到的度量数据。度量应尽量接近业务部门所理解的概念。这些度量从简单到复杂，形成一个连续的整体——其中某些只需提供一些随时可用的系统工具即可，而其它则可能需要更为复杂的解决方案。系统和网络简单易用性、往返延迟、应用可用性、应用性能以及端到端被动和主动用户响应时间对于一个成熟的 SLM 计划来说都具有重要意义。要点则同样是“以目前所在位置为起点，然后向前推进。”使用第一阶段所准备好的数据以确定有助于改善服务的目标管理系统。对于前面所述的备份过程，问题的严重性可能不仅限于要求对问题作单纯识别，还对可以查明问题、向工作人员发出警告以及记录错误的工具提出要求。监控的能力会不断加强，测量和改进的手段也是如此。或者，收集到的信息可能会显示其它备份工具对于企业当前的数据负荷来说更能节省成本。
如果 IT 部门已经发展成为系统、网络、应用和数据库等多个强大而独立的责任单元，则需要让它们共同协作。在更高级别的 SLM 中，需要以业务部门的视角来定义业务服务。例如，会计系统可以包括应用本身、所运行的网络、各个部门的 Web界面、以及存放数据的数据库。IT 领域间更佳的合作以及那些独立单元的最终联合，对于真正支持广泛定义的服务而言十分必要。用于查清问题所在的工具可以减少互相指责的发生并加快排除故障。可能会需要一个坚定的行政官员来帮助各个 IT单元认识相互协作对解决业务上的一些问题的必要性。了解外包等共同威胁将有助于提高合作性。这样对 IT 的好处是使之能以一致的面孔面对业务部门。减少内讧可提高 IT 的声誉，并加快故障排除的速度。而服务的改善又会反过来促进这种趋势。
第三阶段：服务品质报告
现在，IT 部门应已对报告和解决问题的过程有所了解并较为得心应手了。第二阶段将进入到实质的服务品质协议和服务品质报告之中。如前面的部分所述，在开展任何 SLA 计划之前，IT 部门必须设定服务的基线。
在开始时，应制定出您认为可以合理实现的服务品质 SLA。Internet 上有各种 SLA 的范本可供免费下载。SLA 可以是一个合约或更概括性的协议。其正规程度应与企业组织相符。它应包含与服务利益攸关的各主体、SLA 的期限（截止日期）、对服务的定义（其范围限于系统和应用的一个特定子集）。SLA 所涵盖的服务品质目标 (SLO) 指定了服务的度量和品质，从而使 SLA 变得具体。服务品质可能会依服务时段的不同而有所不同。例如，以会计系统的可用性作为度量指标，并通过每秒执行一次 ping 操作来衡量。所保障的服务品质则是在一个月内从每天早上 8:00 到下午 5:00 这一服务时段中提供 98%的可用性。这只是举例子说明，具体可根据业务的需要而变更。
还应制定用于通报问题、月度报告以及对 SLA 的得失作年度评议的沟通和评审程序。报告应包括了 SLA 的整体实现情况，以及对较严重问题的存档，其中包括并未对整个 SLA 构成威胁的问题。
一旦 IT 部门已准备好与某一业务部门达成第一份 SLA 后，就需要有一个行政高层人员来帮助维持一种合作的气氛。重要的是 IT 和业务部门都以一种实际的眼光来评估和看待 IT 所能提供的服务品质以及为提供某种品质的服务而需要的成本。通过得到的数据，业务部门会开始明白：不同品质的服务都需要以一定的成本为前提，而并非都是人为因素所引起。服务品质必须以业务目标为导向；IT 所能提供的服务品质总额会有一个限度，在不同业务部门之间分配 IT 服务不应该由IT 部门来进行。
同理，应以小型而简单的系统为起点：挑选一个系统和较为合作的业务小组。弄清楚哪些条件有利于实现 SLA、哪些报告程序对 IT 有实际意义，这对 IT 和业务部门开展 SLM 会起推动作用。对于整个业务部门来说，SLA 报告可在 IT 和业务部门之间筑起信任的桥梁，它记录了 IT 提供的所有良好服务、并让 IT 承担起处理剩余问题的责任，从而提高 IT 的声誉。SLA 协商过程对于 IT 和业务部门来说，都是一种正面的了解过程，可获得更清晰的期望值并打开沟通的渠道。
第四阶段：积极主动、以业务为导向的服务品质管理
真正积极主动的 SLM 要求工具能在问题影响到最终用户之前识别并解决问题。与出现了中断和不良情况之后研究其模式，或者寻找问题报告的共同点以确定修复措施等做法不同，真正的关系分析和追根溯源型工具可以在 SLA 受到影响之前进行修复。一种方法是设置低于实际出错等级的触发事件，从而可以及早进行故障排除，避免发生不良情况。而更复杂的工具可以在考虑正常波动的同时分析趋势走向。
即使具有足够的工具改善服务，IT 仍只能提供有限的服务。并非每个服务都能达到最高的服务品质。因此，IT 必须以服务对于业务的重要性次序为导向。管理层首先按重要性的高低定义一些业务目标，然后将它们与业务服务和 IT 服务进行关联，这样可以帮助 IT 部门在提供服务时设定相应的优先次序。SLA 可以定义不同级别的服务品质，在解决问题时，可遵循“最高级别优先”的方法。负荷平衡工具通过为每种服务提供精确的资源，有助于让其达到特定的品质要求。最高的业务目标可能是每周实现 100,000 美元的销售额。排在第二位的目标则是减少逾期应收帐目的值。因此，为销售提供支持的 IT服务需要实现较高的服务品质，这可能是 99.99% 的可用性和 3 秒钟的响应时间。销售系统也需要获得更多的维护和更升级投入，以提供如此高的服务品质。如果销售系统和会计系统同时出现故障，SWAT 小组应首先将注意力集中在销售系统。应以业务部门定义的优先次序，而不是 IT 小组定义的优先次序对服务进行安排。
积极主动、以业务为导向的 SLM 将同时为 IT 和业务小组带来更高的效能。IT 可减少事故抢救所花时间，并将更多精力投入到服务管理和提高。问题报告和寻求解决方案只需花费较少的资源。中断的减少和修复的加快意味着更高效能的最终用户和更高的利润产出。IT 表现出对业务优先次序的支持和将基础架构直接对应于不同服务的能力后，就能更加顺利地获得提高服务品质所需的资源。IT 对业务部门更为透明，因而可得到更大的尊敬和信任。
EMA 的观点
EMA 坚信，服务品质管理可以将业务服务的提供方式得到彻底改观。SLM 可以带来更优质的 IT 服务，减少基础设置和管理的成本，提高最终用户和客户的满意度。许多经理对 SLM 的启动都显得无能为力。EMA 认为，这是因为他们对 SLM 项目的规模、成本或开展难度具有不切实际的预计所致。
如本白皮书所述，SLM 并不是一种可怕的、昂贵的或令人不快的事物。IT 需要主动权来定立其步骤和试验各种度量、衡量和报告手段。我们的忠告是：以小型、非关键性的系统为起点，积累一些经验后再扩大其复杂性和范围。一部分的成功将为其它成功铺平道路，随着 IT 声誉的提高，其提供更佳服务的能力也将增强。只有不肯迈出第一步才是最大的错误。
作者：美国福禄克网络公司 来源：C114(CHINA通信网)
