流程是指按照一个既定的目标组织起来的一组逻辑上相关的活动。一个流程是将输入转化为输出的一组活动,我们可以通过质量特征和标准来比较每个流程的输入和输出,并提供该流程目标实现情况方面的信息。具体流程设计时,我们会从流程概述、流程范围、流程制定策略和流程详述四个方面来开展流程设计。ITSS考试
| | | | | |
| | 服务台关闭事件不够及时,工程师未按规范要求操作单据状态,无法正确反映故障管理流程的KPI实际情况 | | 制定规范要求工程师准确记录事件处理状态,及时挂起事件,以便于收集正确的事件处理时长;语音平台需传送主叫号和通话时长;优化工单关闭操作规范 | |
| | 服务台工作人员没有完全遵照既定的问答脚本和统一礼貌用语回答用户的问题。 | | | |
| | 服务台查询配置库的操作不够便利,无法实时对用户信息与资产信息进行核对 | | SM平台开发功能,让服务台登记事件时可即时查询用户、资产和配置信息 | |
| | 故障管理中用户已有基本的分级方式,但无事件影响度、紧急度等优先级分类的准则 | 故障管理
ISO200008.2
事件分类与分级依据《项目作业书》 | | |
| | | | | |
| | 服务台未将咨询来电记录下来,导致很多来电无法跟踪,影响服务台绩效指标和整体服务质量 | | 在未来的工具中,将咨询类的来电也做为事件或服务请求登记在案 | |
| | 服务台即将升级的语音平台与即将上线的SM管理平台的服务台功能部分重叠 | | 与外包商协商开发接口,协调操作功能整合。由于需要把所有流程关联起来,如服务台界面和事件,服务台界面和变更、服务台界面和请求等,语音平台自带的所有ITSM流程相关的功能都应该集成到SM管理平台上ITSS认证 | |
| | 事件管理没有与监控系统接口,无法记录监控报警类事件
| | 考虑开发事件管理与监控系统的接口(监控系统需开放接口),将监控系统传过来的信息自动登记为事件。 | |
| | | | | |
| | 由于工具功能限制,事件管理流程KPI指标还有待完善 | 故障管理
ISO200008.2
IM6重大事件需要单独进行分析与报告 | 完善绩效指标:一线解决率、SLA达标率、接通等待时长、通过web提交的请求、及时响应率、首次正确派单率、事件平均解决时间、事件满意度评分、事故总数、通过监控产生的事件百分比 | |
| | | 故障管理
ISO200008.2
所有事件都通过事件管理程序处理 | | |
| | 新应用系统在暂管期间,无法监管升级给项目团队的事件单 | 故障管理
ISO200008.2
所有事件都通过事件管理程序处理 | | |
编号
| | | | | |
| | 暂无文档化的问题管理流程,使用交班会形式来进行基础性的问题管理活动 | 问题管理
ISO200008.3
流程综述:记录识别所有的问题 | 建立问题管理流程,确定流程接口人制度,确定四个团队的问题入口方式:开发团队、网络团队、应用管理团队、桌面维护团队 | |
| | 目前的问题流程除与事件管理流程有接口外,和其他流程尚无接口 | | | |
| | 通过日常监控和巡查措施,建立了初步的主动问题识别机制,尚不能很好地预防问题的发生 | | | |
| | 具有初步的事件升级问题的机制,及时性和准确性还有待提高 | | | |
| | 目前对问题无任何分类和分级机制,造成问题解决安排上不合理,重大和紧急类问题不能得到优先处理 | 问题管理
ISO200008.3
流程综述:问题要记录、分类解决和关闭 | 对问题进行分类和分级梳理,考虑与事件管理的分类和分级方法保持一致 | |
| | 尚无问题关闭和变更实施后评审制度,造成问题实施效果没有得到应有的回顾 | 问题管理
ISO200008.3
PM12:问题处理情况每月进行分析 | 建立问题关闭流程,建立RFC实施后评审制度ITSS培训 | |
| | 对于某个事件可能由未知的原因导致的,多个部门涉及到需要各自找问题根源,但没有相关协同工作机制,可能会造成互相推诿 | | 这类事件即时升级为问题,并在安排一个主要团队负责该问题时,系统同时派生一个或多个协查问题工单给其他团队,便于多个团队协同工作。进一步,可以考虑成立运维管理办公室,专门负责跨部门跨项目的协调问题 | |
| | | 问题管理
ISO200008.3
PM12:问题处理情况每月进行分析 | 绩效指标和报表:问题解决率、已关闭的问题数量、问题流程提交RFC的数量、开放问题的平均数量、问题解决时长、未解决关闭的时间百分比、前5名问题类别、主动问题占比 |