×

微信扫一扫,快捷登录!

标签: 暂无标签
本帖最后由monicazhang于2015-11-1815:09编辑

20151118淡然
续上











3.3
实施ITIL流程改进
流程是指按照一个既定的目标组织起来的一组逻辑上相关的活动。一个流程是将输入转化为输出的一组活动,我们可以通过质量特征和标准来比较每个流程的输入和输出,并提供该流程目标实现情况方面的信息。具体流程设计时,我们会从流程概述、流程范围、流程制定策略和流程详述四个方面来开展流程设计。ITSS考试
本期项目中,我们将实施8大流程,同时,我们也对其他的流程进行了规划,根据第2章制定的流程改进点,这里按照各个流程进行了分类汇总如下:




3.3.1
故障管理流程改进方案
编号
实施阶段
现状
应对条款
改进建议
优先级
IM1
本期实施
服务台关闭事件不够及时,工程师未按规范要求操作单据状态,无法正确反映故障管理流程的KPI实际情况
故障管理
制定规范要求工程师准确记录事件处理状态,及时挂起事件,以便于收集正确的事件处理时长;语音平台需传送主叫号和通话时长;优化工单关闭操作规范
IM2
本期实施
服务台工作人员没有完全遵照既定的问答脚本和统一礼貌用语回答用户的问题。
故障管理
优化服务台管理规范、问答脚本、规范用语等
IM3
本期实施
服务台查询配置库的操作不够便利,无法实时对用户信息与资产信息进行核对
故障管理
SM平台开发功能,让服务台登记事件时可即时查询用户、资产和配置信息
IM4
本期实施
故障管理中用户已有基本的分级方式,但无事件影响度、紧急度等优先级分类的准则
故障管理
ISO200008.2
事件分类与分级依据《项目作业书》
结合SLA制定事件分类、分级原则
IM5
本期实施
未及时完工的事件可能会被忽略或者不能及时升级
故障管理
开发和设置系统自动超时告警、升级功能
IM6
本期实施
服务台未将咨询来电记录下来,导致很多来电无法跟踪,影响服务台绩效指标和整体服务质量
故障管理
在未来的工具中,将咨询类的来电也做为事件或服务请求登记在案
IM7
本期实施
服务台即将升级的语音平台与即将上线的SM管理平台的服务台功能部分重叠
故障管理
与外包商协商开发接口,协调操作功能整合。由于需要把所有流程关联起来,如服务台界面和事件,服务台界面和变更、服务台界面和请求等,语音平台自带的所有ITSM流程相关的功能都应该集成到SM管理平台上ITSS认证
IM8
本期实施
事件管理没有与监控系统接口,无法记录监控报警类事件

故障管理
考虑开发事件管理与监控系统的接口(监控系统需开放接口),将监控系统传过来的信息自动登记为事件。
IM9
本期实施
服务台没有文档化的供应商联络制度
故障管理
建立成文的供应商联络制度,区分保内、保外操作规范
IM10
本期实施
由于工具功能限制,事件管理流程KPI指标还有待完善
故障管理
ISO200008.2
IM6重大事件需要单独进行分析与报告
完善绩效指标:一线解决率、SLA达标率、接通等待时长、通过web提交的请求、及时响应率、首次正确派单率、事件平均解决时间、事件满意度评分、事故总数、通过监控产生的事件百分比
IM11
本期实施
应用维护工作尚未建立有效的事件管理机制
故障管理
ISO200008.2
所有事件都通过事件管理程序处理
在事件管理机制中考虑应用维护工作
IM12
本期实施
新应用系统在暂管期间,无法监管升级给项目团队的事件单
故障管理
ISO200008.2
所有事件都通过事件管理程序处理
服务台监控事件单的状态,并及时通报状态和关闭事件



3.3.2问题管理流程改进方案
编号

实施阶段
现状
应对条款
改进建议
优先级
PM1
本期实施
暂无文档化的问题管理流程,使用交班会形式来进行基础性的问题管理活动
问题管理
ISO200008.3
流程综述:记录识别所有的问题
建立问题管理流程,确定流程接口人制度,确定四个团队的问题入口方式:开发团队、网络团队、应用管理团队、桌面维护团队
PM2
本期实施
目前的问题流程除与事件管理流程有接口外,和其他流程尚无接口
问题管理
与知识库、配置、变更管理流程集成
PM3
本期实施
通过日常监控和巡查措施,建立了初步的主动问题识别机制,尚不能很好地预防问题的发生
5.3.1流程综述:记录识别所有的问题
加强与日常运维等流程的融合,建立主动问题识别规范
PM4
本期实施
具有初步的事件升级问题的机制,及时性和准确性还有待提高
问题管理
改进事件升级问题的机制
PM5
本期实施
目前对问题无任何分类和分级机制,造成问题解决安排上不合理,重大和紧急类问题不能得到优先处理
问题管理
ISO200008.3
流程综述:问题要记录、分类解决和关闭
对问题进行分类和分级梳理,考虑与事件管理的分类和分级方法保持一致
PM6
本期实施
尚无问题关闭和变更实施后评审制度,造成问题实施效果没有得到应有的回顾
问题管理
ISO200008.3
PM12:问题处理情况每月进行分析
建立问题关闭流程,建立RFC实施后评审制度ITSS培训
PM7
本期实施
对于某个事件可能由未知的原因导致的,多个部门涉及到需要各自找问题根源,但没有相关协同工作机制,可能会造成互相推诿
问题管理
这类事件即时升级为问题,并在安排一个主要团队负责该问题时,系统同时派生一个或多个协查问题工单给其他团队,便于多个团队协同工作。进一步,可以考虑成立运维管理办公室,专门负责跨部门跨项目的协调问题
PM8
本期实施
目前问题流程无KPI指标
问题管理
ISO200008.3
PM12:问题处理情况每月进行分析
绩效指标和报表:问题解决率、已关闭的问题数量、问题流程提交RFC的数量、开放问题的平均数量、问题解决时长、未解决关闭的时间百分比、前5名问题类别、主动问题占比






本帖关键字:ITSS




上一篇:怎样梳理ITSS岗位职责来优化服务体系流程
下一篇:变更、服务级别、ITSS配置管理流程改进方案详解
monicazhang

写了 2297 篇文章,拥有财富 12859,被 21 人关注

您需要登录后才可以回帖 登录 | 立即注册
B Color Link Quote Code Smilies

成为第一个吐槽的人

Powered by IT 运维管理
返回顶部