但是，您的确需要一些衡量当前所提供服务的方法。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 这一套。
对于 IT 本身，SLM 过程为改进管理提供了一个架构。它有助于正确分配资源和提供更好的服务。这既能使 IT 员工效能得到提高，又让 IT 部门的声誉得到提升——这两点都可以让 IT 员工从工作中获得更高的满意度。作为进行衡量的一种边际效益，IT 得到了新系统和新工具的有利条件，避免了过度部署和人员过剩，并能够将稀缺的资源用于最需要的地方。以过程为导向和进行资料记录还可以使 IT 脱离“独行侠”的 IT 管理方式，IT 专家无需为维护系统功能和应对系统崩溃而孤军奋战。解除了对个人的依赖之后，不仅让 IT 管理变得格外轻松，还将带来整体服务品质的提升。
对于公司业务来说，其好处也是显著的。可重复使用的过程和积极主动的管理可减少 IT 出现故障的机会，并降低随之而来的利润损失或花费额外开销的风险。服务中断时间的减少和服务品质的提升意味员工的工作效率提高，从而产生更高的利润和更低的成本。其它部门在真正了解服务品质的意义、影响品质的因素以及提高服务品质所需的真正成本之后，将对 IT部门更为信任。
对 SLM 计划的实施和推广不能像依菜谱下厨般简单，因为不同企业的 IT 成熟程度各不相同。然而，以下的这些阶段适用于大多数尚未具备完善的 IT 管理方案或 SLM 规程的企业。EMA 估计有 50% 的企业都属于这种情况——这可不是一个小数目！
召开一个启动会议，以介绍新的过程，并说明多一分努力将获得哪些最终回报。跟进小组的工作，以确保他们对问题作了归档。您甚至可以为一些好的归档行为设立小奖励，如给予个人奖品，或在小组表现出某种团结一致时请他们吃比萨午宴。由于需要做除单纯解决问题之外的“额外”的工作，因而理所当然会存在一些报怨声音。让您的团队为共同的目标而努力是使得 IT 和业务部门可以开展协作的第一步。
如果 IT 部门已经发展成为系统、网络、应用和数据库等多个强大而独立的责任单元，则需要让它们共同协作。在更高级别的 SLM 中，需要以业务部门的视角来定义业务服务。例如，会计系统可以包括应用本身、所运行的网络、各个部门的 Web界面、以及存放数据的数据库。IT 领域间更佳的合作以及那些独立单元的最终联合，对于真正支持广泛定义的服务而言十分必要。用于查清问题所在的工具可以减少互相指责的发生并加快排除故障。可能会需要一个坚定的行政官员来帮助各个 IT单元认识相互协作对解决业务上的一些问题的必要性。了解外包等共同威胁将有助于提高合作性。这样对 IT 的好处是使之能以一致的面孔面对业务部门。减少内讧可提高 IT 的声誉，并加快故障排除的速度。而服务的改善又会反过来促进这种趋势。
一旦 IT 部门已准备好与某一业务部门达成第一份 SLA 后，就需要有一个行政高层人员来帮助维持一种合作的气氛。重要的是 IT 和业务部门都以一种实际的眼光来评估和看待 IT 所能提供的服务品质以及为提供某种品质的服务而需要的成本。通过得到的数据，业务部门会开始明白：不同品质的服务都需要以一定的成本为前提，而并非都是人为因素所引起。服务品质必须以业务目标为导向；IT 所能提供的服务品质总额会有一个限度，在不同业务部门之间分配 IT 服务不应该由IT 部门来进行。
同理，应以小型而简单的系统为起点：挑选一个系统和较为合作的业务小组。弄清楚哪些条件有利于实现 SLA、哪些报告程序对 IT 有实际意义，这对 IT 和业务部门开展 SLM 会起推动作用。对于整个业务部门来说，SLA 报告可在 IT 和业务部门之间筑起信任的桥梁，它记录了 IT 提供的所有良好服务、并让 IT 承担起处理剩余问题的责任，从而提高 IT 的声誉。SLA 协商过程对于 IT 和业务部门来说，都是一种正面的了解过程，可获得更清晰的期望值并打开沟通的渠道。
即使具有足够的工具改善服务，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 声誉的提高，其提供更佳服务的能力也将增强。只有不肯迈出第一步才是最大的错误。
