学习资料： ITIL培训基地专家讲堂直播 300期视频回放

首先，在实施服务管理项目前，从领导决策层到技术实施团队都应该达成一个共识，即IT 服务管理是粗略的管理，不可能做到100%的精准与100%的控制。在这一点上，笔者的一个同事曾做过一个非常贴切的比喻，即IT 服务管理就好象是我们定期进行的体检，我们只能通过一些体征指标，大体上了解大体的状态；大多数人没有时间，没有能力，更负担不起去把身体的每个部件，从里到外，用各种能用的设备来都做一个全面的检查。同样，一个IT 服务管理项目，也是从一些关键的点入手，从三个层面来进行。从离基础架构最近的资源层：根据系统特点，选择关键的测试点，以实时或准实时的方式构建出基础架构的“关键运行指标”（即我们常说的KPI-Key Performance Index/Indicator）；在与管理者最近的业务服务管理层：要构建业务运行的KPI，使领导者，业务经理等管理层能够了解当前系统业务服务的状态；在以上两层之间，还需要有一个能够提供深度问题分析，问题关联，业务拓扑管理的一层。

在基础架构管理中，就像前面提到过的，要对资源的运行进行必要的度量，要有针对性的选择进行度量的切入点，但切记不能过分追求度量的范围与数量。在这一部分中，要收集资源的事件，资源的运行性能，并且通过必要的工具，收集并整理资源间的调用关系。通过资源管理工具，对收集到的信息进行整理和处理，并以相对直观的方式表现出来，使管理和运维人员对系统资源的运行状况有一个相对清晰的概念。

在业务服务管理中，应建立业务服务的模型和业务影响性分析，并且一切都应该从业务服务的角度出发（而不是从IT 的角度）。在这一部分中，最好有了解业务的人员参加，因为只有了解业务的人员才知道对于某一业务服务，什么是最重要的。

其次，要建立可行的手段了解业务服务的结果。尽量从业务服务的边际上发现并测量业务服务的状态，而不是通过若干个中间指标生成。那么，哪些业务服务的状态是最常要了解的？

系统的可用性，即在多长时间内某项服务是能够被最终用户所正常使用的。随着业务复杂性的不断提升，影响业务可用性的因素也越来越多，要通过分析，了解构成业务可用性的“短板”，及时加以度量，并通过手段进行提升。响应时间是另一个经常使用的指标，很多时候，它直接影响着用户对业务服务的满意程度。试想一下，您从网页上提交一个服务请求，您的耐心给您多长时间来等待网页的回应？对于响应时间的测量也有多种方式，如使用类似测试工具那样的交易模拟机制，定期通过网络触发测试交易并记录其响应时间；也可以从服务器的角度，通过性能管理工具直接记录后台服务器中交易的相应时间。这两种方法各有特点，应结合使用。

客户满意度也是一个重要的业务服务指标。业务服务的对象即为客户，所谓从业务服务出发，就不能不包含客户对业务服务的印象。越来越多的业务服务管理项目，把客户满意度作用一个关键的指标加以度量。读者可以都有经历，在电话银行服务后被要求对当次服务进行评价。其他的客户满意度还包括服务中心的正在处理案件数，平均处理时间等。在设计IT 服务管理项目中，应该考虑将现有的与客户满意度有关的数据如何包含进来，并从一个合适的切入点导入的到业务服务模型之中。

其他的与业务服务结果有关的指标还有很多，如系统/网络的吞吐量；重要组件（如批量处理，离线数据处理）的处理时间等。在项目设计过程中，应均衡考虑，从简单直接的指标入手，逐渐丰富。

第三点，从向与业务服务相关各方提供一个有关业务实时交付情况的集成监视仪表盘（Dashboard）开始开展项目。通过可视化的手段，让各方及时了解系统业务服务的状态，这往往能够在短时间内达到事半功倍的效果。所谓‘业务服务的相关各方’，是指那些系统服务的使用者，付费者，管理者，等等，在现今的企业中，可能涉及到企业中绝大多数的人员。让这些人有一个直接的手段或方法了解其所使用，其所购买，或其所管理的服务的运行状态，是实施系统服务管理的目的，而通过一个集成仪表盘式的界面将众多的KPI 合理有机的组合，展现，是项目成败的关键所在。

在构建集成监控仪表盘的初期，甚至可以考虑以‘只读’的模式进行展现。即在项目的初期，只是通过集成监控仪表盘对不同监控工具或用户相关数据进行有机的集成，展现，并不作为系统管理的‘门户’供使用者发现问题后能做深度问题发掘与分析。也就是说，‘业务服务的相关各方’只能通过这个界面了解服务状态，而不能直接通过它发现并处理问题的根源。这样做的好处是，在项目初期，尽量减少服务管理项目的复杂程度，使大家可以将更多的资源用在如何将各种手段获取的KPI 映射，转化为各方接受的业务服务状态。而关于问题跟踪，深度分析的功能，可以通过相关的专业工具或手段进行。

第四，应该看到，在当前的企业组织结构，尤其是IT 部门的组织中，依照技术特点或技术种类，IT 系统的管理被分成多个小组。这种分割基本上还完全是依技术而定，而没有依照IT 系统所服务的业务来分。这样的管理方式有其存在的必要性和必然性，当然从业务管理的角度也有其弊端。上面提到的建立整合的服务管理监控仪表盘，从某种程度上可以缓解个技术组织间的隔阂，使不同技术组织都对一个相关的业务服务有一个一致的了解；在另一方面，通过必要的技术手段，建立并强化流程式的管理，针对于某项业务服务管理，通过流程，串联起各个小组中的相关人员，形成临时的虚拟团队，也有利于开展以业务为导向的管理工作。

关于业务管理流程，是一个当前非常热门的话题，国际上众多标准化组织也针对IT 服务管理总结出很多的理论和体系，如ITIL 等。针对企业中IT 管理流程实施的成熟度，国际知名的IT 咨询研究公司Gartner 曾做过相关的市场调研，对于IT 管理流程的实施程度，从初始的阶段，到其高级阶段，分为0 到5 共6个层次。如下表：

[url=resources/2009_01/2009_01_12/200901124861231754132806.jpg][/url]
Gartner 的调查结果显示，在2007 年，绝大多数企业处于1 和2 之间，即对流程的重要性有了充分的认知，对部分IT 服务也开始指定并遵守一些必要的管理流程。调查的另一个出人意料的结果是，2012 年，大多数企业的流程成熟的也只能达到2 和3 之间。也就是说，对于企业中IT 服务管理流程的实施，并不像人们普遍认为的那样简单容易。

所以，对于企业计划IT 服务管理，我们的建议是从简单入手，如可以从实施可用性管理，性能管理等流程开始，将这些流程在企业中的实施提升到主动的阶段或层次，即针对上述管理，制定具有可重复的流程，并且实现这些流程的自动化。而对于诸如变更管理，服务生命周期管理等较复杂的管理流程，可以考虑稍后再开始进行。

一直在看