20150721 淡然 续上
2.2 流程关系图 下图是某保险公司的热线支持与突发事件流程与其他流程的关系图: · 可用性管理:提供突发事件数据给可用性管理,来进行分析,从而提高服务的可用性。 · 服务级别管理要提供SLA给本流程 ITSS考试 · 当发现有异常事件时,运维管理流程提交突发事件给本流程。 · 在突发事件的解决过程中,可以发出变更请求给变更管理(当然,可能是紧急变更)。 · 问题管理提供问题数据库给本流程,同时需要分析突发事件的数据,来生成新的问题记录。
2.3 热线支持与突发事件 本章节所提供的活动需求,主要是根据最佳实践,同时结合某保险公司的具体情况,对本流程的活动进行高层描述,并对主要活动进行罗列、解释等,P16在进行热线支持与突发事件流程的具体设计时,应该考虑到这些活动,并且在功能上加以实现。 会采用一个表格的形式表达,每一个活动都包括以下内容: · 编号:唯一流程活动编号 · 管理活动:管理活动简述 · 描述:流程活动的具体描述 编号
| 管理活动
| 描述
| 2.1
| 登记突发事件
| 热线支持将突发事件登录入系统。应该包括如下内容: · 判别用户的身份,进行验证。 · 判别是否已经有相同的突发事件存在。 · 根据用户提供的信息,建立突发事件记录。 · 决定紧急程度、影响度,并决定优先级。 · 将突发事件分类。
| 2.2
| 分发突发事件
| 对于登录的突发事件,根据紧急程度、优先级等,分发给不同的支持人员进行解决。 · 对于服务请求,必须根据相应的服务请求流程进行处理。 · 其中,对于投诉,可以作为一类特殊的服务请求进行处理,或者执行单独的投诉处理流程。(注:在制定处理流程时,可以首先判别投诉的事件是否在系统中,若存在,则受理。这样可以提高流程的执行力度。) · 对于重大事件,执行重大事件的处理流程。同时,应该有重大事件的鉴定流程,保证所有的重大事件被正确的识别。 ITSS认证 · 对于一般的突发事件,分发给一线支持人员处理。
| 2.3
| 一线支持进行处理
| 对于分发来的突发事件,一线支持人员必须进行事件匹配处理,包括如下: · 在已有的突发事件记录中,寻找是否有相似的事件,或者根据自己的经验,判别是否有现成的解决方案。如果有则将解决方法拿来使用。 · 根据支持手册及服务目录文档,进行相应的处理。 · 若没有,在问题数据库中寻找是否有解决方案。 · 如果都没有,必须将事件升级到二线处理。
| 2.4
| 对重大事件的控制
| 当突发事件不能在规定的时间完成,或者事件影响非常重大时,需要进行相关升级处理,主要包括: · 具体评估该事件。 · 任命一个“重大事件经理”,来负责该重大事件的处理,他必须保证该重大事件不能影响到SLA。 · 制定沟通计划、解决方案。 · 执行沟通、执行解决方案。 · 解决方案中有可能包括紧急变更请求的提交等。 · 对于在运维系统中发现重大事件,应该重点考虑。
| 2.5
| 二线或其他支持人员进行处理
| 当事件在一线支持处不能够完全解决时,二线支持人员必须来协助解决。应该包括: · 对事件影响的隔离 · 对事件的分析 · 如果需要更加深入的分析,申请其他资源,直至解决。 · 如有必要,提交紧急变更申请。
| 2.6
| 关闭事件
| 热线支持必须主动的向用户询问,是否完成,如果完成,则关闭该事件。否则将事件重新分发给一线或二线的人员重新解决。
|
2.4 流程主要考核指标 定义考核指标应考虑的因素 可以从以下几个方面来考虑: · 所有的考核指标必须具有“可测量性”,即所有的考核指标的数据都是可以采集到的,当然,最好有自动化的工具进行收集及显示。 · 考核指标可以用来反映流程的执行进度,即做了多少工作。 · 考核指标可以用来反映流程的执行质量,即所完成工作的效果如何。 建议的考核指标 热线支持与突发事件流程设定如下的考核指标,可以按照每天、每月、每年进行统计: · 突发事件记录数,按照分类、紧急程度、影响度、优先级统计 · 一线支持人员的突发事件解决率。 · 每个热线支持人员的突发事件处理数 ITSS培训 · 可以被远端解决的突发事件的比率,即不需要当地的人员参与 · 重大事件的比率
本帖关键字:ITSS |