本帖最后由 monicazhang 于 2015-7-15 09:54 编辑
20150714 淡然
续上
8.3 流程相关定义
8.3.1 事件信息项
事件单通常包含如下主要信息项,立白集团可以根据自身的情况在此该信息项上进行扩充或删减:
[td] | | | | | | | | 事件申报人的信息,包括:姓名、所属单位、部门、电子邮件、办公电话、手机(初次录入手工填写,再次输入由系统自动填写) ITSS培训 | | | | | | 事件发生的地点 (列表项+手工填写“楼号+ 房号”) | | | "针对故障:指的是业务中断的实际时间(可能早于登记时间,需要手工填写)针对其它:缺省值等于登记时间" | | | | | | | | | | | | | | | | | | 对应每一个事件优先级,系统根据流程相关定义中“事件解决时限”自动设定最终的完成期限 (系统自动产生) | | | | | | | | | | | | | | | | | | | | | 反映事件信息项的变化历史,如一个事件在处理过程中事件状态变化的时间点等信息(系统自动产生) | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
8.3.2 事件来源
事件来源代码用来标明事件的提出方式,事件来源可以包括以下几种:
| | | | | 用户通过电话/邮件等提出的事件,服务台人员手工创建事件单 | | | | | | | | | | | | | | | |
8.3.3 事件性质
8.3.4 事件分类
事件分类用于标识事件或申告的具体原因,由支持人员在处理过程中根据事件分类表来填写。当事件发生时,应该由服务台初步分析和定位事件的分类,一方面便于与历史事件/问题或者知识库匹配,另一方面也便于选择合适的运维人员提供支持。事件最终分类可由后续支持人员作进一步的确认,并在事件关闭前进行调整。
事件分类表的层次设计不超过三层,第一级分类,称之为“类别”;第二级分类,称之为“子类”;第三级分类,称之为“条目”。
8.3.5 事件优先级
优先级是事件管理的一个关键要素,优先级决定了事件处理的顺序。在本次项目中,事件优先级可分为四级:极高、高、中、低。为了方便服务台人员判断事件优先级,咨元建议从事件的影响程度和事件紧急程度两个维度来确定优先级。
事件的影响程度主要是对事件发生影响的关键程度以及事件发生后的影响范围综合考虑得出的。在本项目的影响度判断中,要考虑以下几个方面: q 用户身份; q 受影响的用户数量和范围; q 受影响设备; q 受影响系统。 具体影响程度的定义如下:
| | | | | | 重大的应用停机,影响很大数量的用户和业务单位。 关键业务不能运行。 | | | |
事件的紧急程度主要是以用户能容忍的事件解决时间来进行判定,按照此规则,事件紧急程度定义具体如下:
结合事件发生时的影响程度和紧急程度,可以通过如下表确定事件的优先级:
8.3.6 事件状态
事件状态代码表明事件所处的处理状态,事件状态代码如表
| | | | | | | 事件信息不完整,或在某些情况下阻止事件记录员或事件分析员对事件,问题分析员对问题进行处理,需要填写等待代码: | | | | | | | | |
8.3.7 事件解决/关闭代码
事件结束代码说明了事件是在何种情况下解决/关闭的,本次项目的结束代码如下表定义:
| | | | | 事件已通过变通方法解决,但需要进行更进一步的根源分析 | | | | 该事件已转交研发人员或厂商,在可预见的短期内无法解决。直接关闭此事件 | | | | | | |
8.3.8 事件等待代码
事件等待代码说明了事件是在何种情况下被挂起,本次项目的等待代码如下表定义:
本帖关键字:ITSS |