[p=30,2,center]学习资料：IT运维管理社区专家讲堂直播300期视频回放
今天我来谈谈事件流程中的KPI这个是我以前多年support经验的总结
首先什么是KPIKPI全称是KeyPerformanceIndicators关键业绩指标
1.事件和服务请求的解决率(resolutionrate)就是解决的事件和服务请求的数量除以总共创建事件和服务请求的数量
有了解决率可能就有人会提到未解决率不过一般有了解决率这个百分比的指标没有解决的事情和服务请求通常用数量来表示叫做backlog
2.TTO/TTR/TTU
TTO=TimeToOpen/Own
TTR=TimeToResolve
TTU=TimeToUpdate
我用下面2个表格来做表示下对于不同的优先级的事件相应的TTO/TTR/TTU是不一样的
有些地方例如微软不仅要满足规定时间的TTO还需要在TTO时间内用邮件或者电话第一次联系客户来达到InitialResponseTimeIRT这个KPI
TTU一般是指caselog的更新情况例如在客户联系你后TTU是一天回复如果客户没有联系或者回复你
TTU是2天如果客户一直没有回复你通常使用2天/2天/1天的3Strike方法关掉事件
3.Wordload
不同团队不同人的工作量的总结例如一个星期一个月个人的关闭事件的个数还有处理手中事件（可能还没有关闭）的总的时间这样的话把这个时间除以一个星期或者一个月的实际时间那样的话就能看出他总的工作效率如果百分比很低工作成绩优秀说明他已经完全掌握现在的技能可以提升他的职位或者升级到二线等反之如果百分比很高工作成绩很低说明这个人技能不够效率太低需要进行相应的技能培训
4.Survey/NagitiveCall
客户满意度一般会随机对一些关闭的case进行满意度调查也就是让客户对事件处理进行打分可能是1到5分也可能是1到9分这个看上去存在的偶然性其实只要Survey的数量到一定数量满意度的结果是必然的我们可以根据不同问题对这个工程是的技术、沟通技巧以及其他方面进行总结从而知道那个方面需要提升
5.重大事件的数量
因为被定义为P1级的重大事件最后都会升级为问题所以对重大事件的纪录和处理时间都需要进行相应的分析
6.Boun**Time
这个指标可能大家不太了解主要是看事件dispatch的次数也就是说看下为什么这个事件会分派到多个team或者为什么会分派到1个team多次可能会发现处理case的问题或者team间职责的问题例如如果只有5个team但是分派了6次肯定说明有一个team拿到case了然后觉得不是自己team处理的又转到其他team最后还是回到自己team手上如果把处理事件中的问题和职责分析清楚会减少分派case的时间也节省处理case的时间肯定会提高客户满意度有一定的提高
ITSM之服务台星期日,9月26th,2010服务台是一个职能(Function)是事件管理的实现手段，服务台是一种基于日志管理来记录所有事件、并为业务部门提供日常支持的服务平台。
服务台是用户与IT部门的唯一联系点(SPOCSinglePointofContact)
服务台专注于处理IT基础架构中事件、或由用户报告的事件，以尽快恢复服务的可用性
管理和维系用户和IT服务提供者之间的日常服务接口
现在服务台主要分为三种:呼叫中心(CallCenter)帮助台(HelpDesk)和服务台(ServiceDesk)
呼叫中心(CallCenter)处理并记录下大量的电话事务，然后交给其它部门处理
帮助台(HelpDesk)管理、协调并尽快解决突发事件
服务台(ServiceDesk)不仅能处理突发事件，还可提供与其它流程的接口
现在所有的服务台基本都做成FollowtheSun形式换而言之就是提供24小时服务
以下是一张项目中服务台和事件管理流程总的流程图大家可以参考下
ITSM之配置管理星期二,9月14th,2010作为ITIL十大流程之一我今天先来简单介绍一下配置管理流程
配置管理(ConfigurationManagement)流程负责核实IT基础设施中实施的变更以及配置项之间的关系是否已被正确地记录下来了监控IT组件的运行状态以确保配置管理数据库能够准确地反映现存配置项的实际版本状况
配置管理的目标主要是维护与IT组件以及运用这些组件提供的IT服务有关的记录并确保这些记录的可靠性和提供准确的信息和文档以支持其他服务管理流程。
说到这里大家可能对配置管理和资产管理有一点混淆下面我来解释一下
资产管理是对购买价格超过一定限额的资产进行监控的一套会计核算流程，它记录了购买价格、折旧、所属业务单元和所处位置等信息。一套有效的资产管理系统应该可以为建立配置管理系统提供基础。
配置管理超越了资产管理，它保留了有关配置项的技术信息、配置项相互关系的详细信息以及配置项的标准化和授权状况等方面的信息。配置管理还监控对当前信息的反馈，如IT组件的状态、位置以及对其实施了的变更
配置管理的活动主要包括以下五个部分
规划——确定该流程的战略、政策和目标，分析现有的信息，确定所需的工具和资源，创建与其他流程、项目和供应商的接口，等等。
识别——建立流程来维护对数据库的更新。该流程的活动包括开发数据模型来记录所有的IT基础设施组件及其相互关系、所有人或负责人、状态以及可用的文档等方面的信息。该流程还要开发一套用于增加新的配置项(CI)和对现有配置项进行变更的程序。由于对信息的需求是在不断变化的，对配置数据的识别也应随之进行不断的调整。
控制——通过只认可、记录和监控那些经过授权和确认的配置项来确保配置管理数据库(CMDB)的及时更新。控制流程还需要确保对配置项的增加、变更、替换或移除只有在获得必要的文档的前提下才能进行。这里的文档包括如被批准的、附有最新规程的变更请求(RFC)。
状态记录——存储有关配置项在其生命周期内所处状态的当前和历史信息。状态监控可用来识别变更所处的状态，如“开发中”、“测试中”、“库存中”、“使用中”以及“停止使用”。
核实——通过对IT基础设施进行审计来检验配置管理数据库，以确认已记录配置项的存在性和验证记录的准确性。
报告——为其他流程提供信息，并就配置项的使用情况报告其趋势和发展。
最后是我设计的一个配置管理的整体流程和配置流程的角色如有具体细化流程的讨论可以私下交流
关于ITIL的模型星期日,8月22nd,2010ITIL从最早的V1版本至今已经发展为V2和最新V3
虽说V3是最新的版本相比V2多了很多新的内容但是V2还是在项目实施和IT日常管理中用的最多的先比较下流程图以后会慢慢对每一个流程做出详解
V2的ServiceSupport模型
V2的ServiceDelivery模型
V3模型
转自：wordpress/tag/ITIL/
|
转播
分享
淘帖
()
