"我如何能得到业务部门的支持？"
在 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 对业务部门更为透明，因而可得到更大的尊敬和信任。
|
