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