20150721 淡然
续上
5 现有流程的改进建议
5.1 现状描述
某保险公司现有的事件管理流程简单描述如下:· 有一套单独的网络事件管理流程,对所有A类及B类分公司进行管理。 · 现在有一套运维系统,来负责处理应用系统出错、OA系统等事件。 · 对于系统方面的事件,现在没有统一的流程来进行控制,都是直接拨打二线人员的电话进行解决。 · 现在没有统一的服务请求及申诉的处理流程。 ITSS考试
5.1.1 网络管理中的事件管理
1) 流程
现在网络管理中的事件管理流程已经有了初步的建立,正在电子化实施,具体描述见下图:
2)人员
为了适应网络管理的需要,某保险公司将全国的公司分为以下几类: · 集团总公司 · A类分公司:济南,南京,广州、杭州等4个城市的公司(业务量较大,拥有较大中支公司),共8家。 · B类:除A类分公司之外的其它分公司,共58家
在网络管理的变更流程中,涉及到如下的角色:
具体的角色、职责定义如下表: [td] 角色
| 职责
| 提交人
| · 提交故障/性能单 · 关闭已处理的故障/性能单 · 重开已处理的故障/性能单 · 应用知识库方案解决问题 · 填写调查问卷,作为对支持人员服务的考核
| 故障协调员
| · 处理分配给自己的请求 · 创建新的故障/性能请求 · 向本地控制员提交升级请求 · 向本地控制员提交BYPASS请求(故障) · 撤销分配给自己的故障/性能请求 · 向控制员提交将解决方案添加进知识库的请求 · 创建、修改或删除公告信息
| 故障控制员
| · 监控所在分公司的故障处理流程 · 对提升的请求进行重分配 · 对BYPASS请求进行审批 · 将故障请求提升到集团 · 检查提交的调查问卷 · 审核提交的希望进入知识库的解决方案 · 对知识库进行日常管理维护 · 创建并管理自己提交的公告信息
|
3)工具 现在采用Remedy Service Desk来进行电子化实施。
5.1.2 运维系统中的事件管理
现在有一套单独的运维系统, 来对日常运维过程中的事件进行管理。经过调研发现以下的现状描述:
· 现在运维系统中,主要处理应用系统中的突发事件以及OA系统中的故障。 · 对于系统中的事件,由于比较紧急,因此是通过直接拨打运维人员的电话来寻求支持。 · 对于总公司,由于主要是桌面系统的维护,因此一般是通过直接拨打运维人员的电话来寻求支持。
5.2 改进建议
根据以上现状描述,有如下的改进方法:
改进建议1:
立即在目前的运维单位内部树立热线支持与突发事件管理的理念,来更好的为用户服务。
具体要求: · 建议在目前的集团、总公司级别的IT运维系统中树立突发事件管理的理念;并保证相关系统被充分的使用。 · 确定流程中的人员角色,特别对于重大事件的处理需要专人负责。 ITSS认证 · 编写常见服务的处理文档,从而使处理标准化,同时,这也为将来的服务目录的编写提供基础, · 建立或加强主动的沟通和突发事件管理例会制度,建议例会周期设置为每月一次。
改进建议2:
记录突发事件,同时输入处理结果。
具体要求: · 对于收到的突发事件,应以一定的形式记录下来,基本内容包括: 记录内容
| 具体描述
| 突发事件编号
|
| 呼叫人
| 呼叫人的姓名、地址、联系电话
| 事件收到时间
|
| 事件描述
| 对事件的症状进行具体描述
| 分类
| 包括:事件的紧急程度、影响度及处理优先级、类别
| 处理人
| 处理人姓名、电话
| 具体处理方法
|
| 事件状态
| 包括:已登记、处理中、处理完成、结束等
|
· 应该公布一个热线支持电话,方便用户报告突发事件。并检查用户是否使用。
改进建议3:
提高一线支持人员的能力。
具体要求: · 在新服务上线的时候,可以按需从开发部门抽调一些人员进行一线支持的工作,来提高一线解决率。 · 可以对一线支持人员进行培训及知识共享,包括技术培训及沟通方法培训等。 · 在日常运维过程中,可以按需将二线或后台的支持人员,抽调进行一线支持的工作,这样不仅可以提高用户的满意度,也可以提高一线支持人员的能力。 · 同时,在日常运维过程中,可以选择一些热线支持人员到各个不同的业务部门去,从而可以更好的了解业务部门的需求,更好的为用户服务。 · 定期发布《用户手册》。
改进建议4: 提高突发事件的处理速度。
具体要求: · 根据业务目标,定义合理的突发事件分类标准,该分类应与问题管理流程中的分类统一,这样可以加快突发事件的匹配速度。分类参考如下: - 存储系统 - 服务器 - 网络 - 应用系统 ITSS培训 - 数据库等 · 应制定突发事件的升级条件,当没有能力解决或者需要高层介入时,自动或手动升级
本帖关键字:ITSS |