[p=30,2,left]

学习资料：IT运维管理社区专家讲堂直播300期视频回放

[转破子]IT服务管理指标体系与报表体系

近期由于工作需要，重新把以前丢掉的IT服务管理的报表体系与指标体系捡起来想了想，原来有过一个想法根据指标去设计一个服务管理系统，后面各种原因未能成行。现在的管理软件越来越多，越来越复杂，也越来越灵活，但我总觉得基本都是没有灵魂的产品，在设计一个管理软件时，设计师的思想是非常重要的，无论一个软件多么灵活，但在设计师的脑中一定有一个最好的组装形态，在它的背后需要有一系列的管理取向去支撑着，这会体现出设计者的管理哲学和把握事物本质的能力，遗憾的是，许多优秀的产品的设计思路没有被传导出来，实施者们并没有理解产品的功能设计，或者是无法把这些分散的功能组织成一套管理体系，由于灵活度的问题或定制的问题，最后实施出来的东西会离设计者的思考很远，这是一个方面，另一方面，一个良好的管理软件是不可能离开良好的报表设计的，设计者在设计之时，就需要考虑好用一把怎样的镜子去照射出业务过程中的扭曲或问题，这个镜子就是报表，它可以引导业务走向设计者的设计目标。

一谈到报表，人们马上会联想到指标，KPI，这几个概念相关之间是有关系的，许多人对这些名词并不做严谨的思考，这些词语只是一个个的从他们的嘴里蹦出来，或者当他们提问时，他们甚至根本没有考虑过这个问题意味着什么，就如苏格拉底所说的，我们首先需要定义我们的问题，所以有必要我们去把最基本的概念去理一下，比如，指标是什么，报表是什么，什么是KPI，这三者的关系是什么？。

指标是用来分析指出某种情况的，它代表了测量者对某种状况的信息渴求，指标事实上是先于报表而存在的，所以是先有指标才会有报表，而不是先有报表后有指标，当你不明确你需要了解什么时，你的信息一定是泛滥的，所以现在许多管理软件的报表多而杂乱，尤其是定制化程度高的软件更是如此，毕竟优秀的分析者是稀缺的。如果我们需要知道一个公司需要有哪一些报表，首先需要回答需要哪一些指标去反映我们的现状，而这个问题最终会回归到管理体系的层面，一个全面而均衡的指标体系或报表体系是离不开一个良好的管理体系的，本质上这些都是业务设计或规划的问题。

事实上我们可以有一些方法或步骤去设计我们的指标体系，即便是它目前可能不是那么好，但仍然可以建立一个大致的框架，先去收集整理现有的指标有哪一些，会形成一个清单，收集的方法可以基于不同的岗位或角色，从上到下的进行收集，一旦收集完成后，你才会发现我们现在关注的东西是多么低级或残缺，然后需要对指标进行一些分析与整理，大致步骤如下：

• 定义指标的作用：中国的管理现状是，领导们随时会想要不同的报表，当他们想要时，他们自己未必知道自己真正想要什么，这种行为象小孩子一样，不同的是是下属变着花样的编报表满足他们，他们会玩一段时间后就丢了，然后过段时间说没有新鲜感，要换个玩法。我们可以改变一种方式，从领导的个人角度出发，你永远只能做出满足一时的报表，便你从业务本身出发，你有可能做出一个全面而均衡的报表体系，它可以满足不同的角色在不同的时间的不同信息需要，因为业务本身其实没有变化。所以我们需要严格检视每一个现有指标的意义与作用，到底这个指标要来做什么？
• 
  
• 定义指标使用者：每一个指标的检查者及承担者是谁，这是第二个需要回答的问题，指标有了之后，需要有人去分析它或查看它是多少，当你有了一个完美的指标但没有人看是没有用的，有人看，但这个指标没有任何承担者也是没有用的，指标的意义在于可以衡量我们的现状，它类似一个GPS告诉我们现在处于什么位置，所以带来行动是它的终极目的，每一个指标出来后需要定义出谁来查看它，甚至需要定义出它的查看或回顾方式，比如是以会议的形式还是肉眼浏览，就象变更成功率或发布遵守率，你需要有一个角色的人员去关注这二个指标，分析这二个指标的人得清楚谁需要为这二个指标的改进负责，当每月需要进行指标分析，可以责成承担者解释原因或采取行动。
• 
  
• 定义告警值：当指标达到多少时，就必须采取行动进行干预，你不能等到油箱的油烧完了，才告警，这时车都不动了。此时我们会发现我们不能把一些基于的事实数值当成指标，比如事件数量，我们需要把事件增长率，或事件下降率当成指标，绝对的事件数量可能是没有意义的，一个大型系统的事件量每天可能几十个，一个小型的事件量才几个，所以对一个大型系统而是言一天增长或下降几个事件很正常，此时用事件增长率或下降率做指标时，这样无论大型还是小型系统都可以拉到一个平面上做分析，这样可以计算出平均系统事件增长率了或做排序了。事件下降率的指标可以强制管理者分析进步的原因与机理，所以指标不仅仅是用来关注负面的。
• 
  
• 定义测量范围：同一种指标可能会因为测量范围不同而出现多个，事实上这是一个指标分解的过程了，比如当定义一个变更成功率的指标时，而公司总体而言会有一个变更成功率，但分解时，会得出每一个系统或服务的变更成功率，此时背负指标的人员与指标检查者会有所不同。
• 
  
• 定义数据来源：一些看上去很好的指标，最后很可能是无法采集的，因为它没有确切的数据来源，我们需要弄明白每一个指标的基础数据取自何方，是哪一些系统或是哪一张表单。
• 
  
• 定义数据信息：确定指标由哪一些基础数据构成，确定它的所有列或字段，比如平均事件响应时间这个指标，可能包括的字段有：月份、服务名称、事件类型、平均事件响应时间这几个字段。
• 
  
• 定义计算方法：确定指标的计算公式，比如通常所说的发布遵守率，大家都知道用总发布遵守数量除以总发布数，但总发布遵守数是否包括提前发布的数量？或者是否包括紧急发布？总发布数这个分母到底从哪一时间点起算，如果算每月的发布遵守率的话，总发布数是本月所有发布的总数吗？是否要剔除紧急发布？是否剔除发布失败数？是否剔除提前发布数？
• 
  
• 定义测量频率：指标设计好后，必须确定多久进行测量一次，如果这个测量频率定好后，你会发现你的日例会、周例会、月例会、季度例会、年度总结会的核心内容基本上都定义好了。
• 
  
• 是否纳入KPI：指标成百上千，但在一个历史时期中，人们的精力总是有限的，我们只能把行动放在最需要关注的状况上，所以每一年我们可以从指标集中选取出一些纳入到KPI之中，当状况改善后，我们又转向另外一些指标，这些就形成一个PDCA的过程。
  
• 
  
  

上面说的几个步骤，事实上可以形成一个表格，形成一个公司的指标库，然后每年进化，事实上在设计指标的过程中，由于定义了数据内容与计算方法，报表的产生是自然而然的，一定要设计好分析之后的行动或产出，并形成记录，报表不是用来愉悦领导的，我们要想好当一个人员看完它之后应做什么，这个做的动作不应是由由这个个体来临时决定的，而是要提前设计并约定，这样才把管理者锁在管理体系之中，而不是让他们成为体系最大的破坏者。事实上当把指标的阀值设定好后，指标异常是无须用肉眼去分析看查看的，当一个事件的增长率突破了20%或50个的绝对数量时，是完全可以用逻辑的计算方法得出异常的原因分布的，你可以把利用事件的类型、申报部门、事件等级、事件时间、系统服务、关联的配置项属性等进行逻辑的穷尽演绎，所以所谓的图形钻取事实上意义不大，因为它依据人脑来做逻辑的演绎，而一个表单的字较多时，你不可能用肉眼把每一个种逻辑组合全部查看一遍，你的脑子也不可能记得清楚这些逻辑组合，这个层面就开始进入了BI的层面。

另一个值得一提的是指标的均衡性，当指标体系本身不全面时，一昧的以运动方式去追求单一指标，会带来一系列的恶果与虚假现象，所以指标有时是一个与人性博弈的过程，比如当我们非常追求事件解决率时，可能会带来满意度的下降，当我们非常追求事件响应时间时，员工会有单就先接单再说，这样事件的处理时长会大大拉长，当你关注事件的处理时长，他们可能又会把事件挂起（事件等待的时间一般不计入事件处理时间），这些类似的情况很多，这也是为什么指标要成体系的一个原因，就如人体一样，你片面的追求体重指标，可能牺牲了其它健康指标。你片面追求GDP指标，人民的幸福感却不断下降，这些道理是类似的。

说到一个IT服务公司或一个内部IT部门的指标或报表体系，往往有人会绕不开SLA，许多人认为SLA报表就是报表体系了，但事实上SLA只占到报表体系中的很小一块，一个完整的指标或报表体系是要面向整个业务过程的，要了解一个事物，必须通过不同的切面去剖析，了解一个人，你需要知道他的外貌，他的性格，他的职业，他的生活，他的爱好等等切面，对于IT服务或IT运维而言，可以用几个不同的面向去解构它，每一个面向都是一种管理角色去关注它，这种解构的原则要做到完全穷尽、相互独立，以下分别说明：

• 面向服务：首先需要关注的是服务，这是很重要的一个切面，这个层面的指标或报表以服务经理的角色为主，服务的指标可以分为结果类与过程类，结果类又可分为SLA类、OLA类、UC类，这主要是指契约类的承诺达成情况，或者说是服务质量结果，比如象电话接通率、事件响应时间、事件解决率、事件满意度、系统可用性这些跟SLA相关的，跟OLA相关的象发布的遵守率、故障解决时长、事件响应时长等等。过程类主要是对服务过程本身的监督或质量检查，比如事件增长率、投诉事件数、剩余事件比率，这些指标的设计目的是提前感知、测量服务的变化情况，提前预防质量问题。
• 面向对象：对于IT服务而言，最基本是要保障IT架构的正常，有了这一层的保障，IT服务不会出现大的问题，而IT架构其实就是由一个个的对象所组成，所以需要有一个从对象的视角出发的指标来监控IT架构的状况。所以既然有一个角色负责服务，同样需要有一个角色负责架构，这一层的指标源数据与监控系统有比较多的关系，对象类的指标可以根据不同分类进行展开，这个分类可以与CMDB的CI分类为准，比如主机类、网络类、安全类、软件类、数据库、中间件、存储类、动力类，每一个分类都根据各自的特性再行分细分，比较主机可以分为性能、状态、故障这几个方面的指标，比如主机类的性能主要是指CPU与内存、IO的负载情况，状态主要是目前的机器的启用率与健康率，故障主要是指目前机器的故障信息。
• 面向流程：IT服务的三权分立，前面讲了服务层面与架构层面，还有一个比较重要的层面是流程层面，这个层面在许多公司与服务层面没有切分清楚，造成了管理缺位，服务经理主要是管理实际的IT服务的，而流程经理主要是管理流程运行的，两者的关注点是截然不同的，流程的指标可以根据流程进行切分，或者根据ITILV3的生命周期切分后再根据流程切分，比如服务运营就包括：服务台管理、事件管理、事故管理、请求管理、访问管理等，服务强管理的指标可能包括：首问解决率、事件错派率、事件回访率、话术错误率。事件管理可能包括：一线解决率、二线平均响应时间、三线平均响应时间、事件平均解决时长、事件关闭失败率、变更导致的事件比率等等。
• 面向人员：在组织的层面，主要关注单位与个人的指标，这主要是由管理者与员工背负的指标，可以用来做绩效考核，比如部门层面会有一些象员工流失率、服务满意度等指标，个人的指标会为事件满意度、关单及时率与一些行为绩效方面的指标。
• 面向财务：针对财务的层面，主要关注营收的指标分析、与成本的指标分析，以及预算的指标分析，
  

以上的5个方面构成一个指标框架及报表框架，事实如果做服务的门户，这些指标就完全可以支撑了，需要做的是基于组织的当前情况，利用前面说的方法去完善这个框架内部的指标细项。指标的测量本身会带来许多有意思的现象，这有些象量子力学的概念，你的观察本身会改变事物本身，所以即便是你什么行动也不做，只是每月的把相关有人员拉在一起查看指标结果，业务本身的运行也一定会改变，一旦你建立自己的指标体系，真正开始PDCA，你会发现它的威力非常巨大，可惜的是每一个公司都在找标杆，不愿自己埋头独立思考与作业，这就造成大部份公司的管理体系或报表都比较糟糕，其实上在中国一个具有一定IT规模与基础的公司，只需要花一两季度的时间就完全可以设计出一个中国一流的指标及报表体系，因为大家都在找别人的东西，不愿抬头想，不愿低头干，标杆其实就是提前走一步的人建立的。

报表对于决策支撑的作用太重要了

好象IT运维管理社区上对整个报表体系的论述比较少哦