事件管理的ITSS考核指标和差距分析
20151118淡然
续上
2.7.3.1.3考核关键指标
指标名称 | 指标值 | 指标说明ITSS考试 |
桌面安全软件安装率 | 95% | Landesk(蓝代斯克）软件桌面已安装可用比率 |
防病毒软件安装率 | 95% | Symantec(赛门铁克）软件桌面已安装可用比率 |
应用客户端安装率 | 95% | 各信息管理系统桌面客户端已安装可用比率 |
0线单服务支持率 | 10% | 驻地项目组人员不通过IT调度直接支持用户的事件比率 |
新电脑安装时限 | 48小时 | 接用户报装后至到达用户现场安装的时间 |
图25事件管理KPI
2.7.3.1.4已有优势
经过问卷、访谈和调查分析，可以发现某公司现有的IT服务管理存在以下的优势：
•有合格且较成熟的服务台功能；
•有合格的事件管理流程；
•有强烈的管理意识和水平；
•IT运维管理的重要性得到普遍认同；
•事件管理流程的管理目的和指导意识符合OGC推荐的管理水平；
•与用户的合作程度较高。
2.7.3.1.5需求与期望
•以ITIL（IT基础架构库）为理论基础，以流程为导向、以客户为中心，整合IT服务与单位业务，建立完善的IT事件管理流程；
•合理利用资源，提高工作效率，保证优质服务，提高单位的IT服务提供和服务支持的能力和水平。ITSS认证
2.7.3.1.6流程评估
通过问卷，我们得出目前的事件流程的成熟度如下图：
由此流程成熟度图可以看出，事件管理的基础条件和质量控制相对成熟，但由于事件管理文档化能力不足，而且没有很好的工具支撑，目前还有很大的改进提升空间，主要体现在以下几个方面：
•没有用于事件进度的跟踪监控和交流环节；
•由于没有问题管理流程，所以事件库无法定期将事件与问题/已知错误库进行比对；
•没有定期生成事件状态的报告并发送给事件解决过程中涉及的团队作为数据分析的来源。
2.7.3.2差距分析及改进建议
编号 | 现状 | 改进建议 |
IM1 | 服务台关闭事件不够及时，工程师未按规范要求操作单据状态，无法正确反映事件管理流程的KPI实际情况 | 制定规范要求工程师准确记录事件处理状态，及时挂起事件，以便于收集正确的事件处理时长；语音平台需传送主叫号和通话时长；优化工单关闭操作规范 |
IM2 | 服务台工作人员没有全部完全遵照既定的问答脚本和统一礼貌用语回答用户的问题。 | 优化服务台管理规范、问答脚本、规范用语等 |
IM3 | 服务台查询配置库的操作不够便利，无法实时对用户信息与资产信息进行核对 | SM平台开发功能，让服务台登记事件时可即时查询用户、资产和配置信息 |
IM4 | 事件管理中用户已有基本的分级方式，但无事件影响度、紧急度等优先级分类的准则 | 结合SLA制定事件分类、分级原则 |
IM5 | 未及时完工的事件可能会被忽略或者不能及时升级 | 开发和设置系统自动超时告警、升级功能 |
IM6 | 服务台未将咨询来电记录下来，导致很多来电无法跟踪，影响服务台绩效指标和整体服务质量 | 在未来的工具中，将咨询类的来电也做为事件或服务请求登记在案 |
IM7 | 服务台即将升级的语音平台与即将上线的HPSM管理平台的服务台功能部分重叠 | 与外包商协商开发接口，协调操作功能整合。由于需要把所有流程关联起来，如服务台界面和事件，服务台界面和变更、服务台界面和请求等，语音平台自带的所有ITSM流程相关的功能都应该集成到HPSM管理平台上 |
IM8 | 事件管理没有与监控系统接口，无法记录监控报警类事件 | 考虑开发事件管理与监控系统的接口（监控系统需开放接口），将监控系统传过来的信息自动登记为事件。 |
IM9 | 服务台没有文档化的供应商联络制度 | 建立成文的供应商联络制度，区分保内、保外操作规范 |
IM10 | 由于工具功能限制，事件管理流程KPI指标还有待完善 | 完善绩效指标：一线解决率、SLA达标率、接通等待时长、通过web提交的请求、及时响应率、首次正确派单率、事件平均解决时间、事件满意度评分、事故总数、通过监控产生的事件百分比 |
IM11 | 应用维护工作尚未建立有效的事件管理机制 | 在事件管理机制中考虑应用维护工作ITSS培训 |
IM12 | 新应用系统在暂管期间，无法监管升级给项目团队的事件单 | 服务台监控事件单的状态，并及时通报状态和关闭事件 |
待续
本帖关键字：ITSS