本帖最后由 monicazhang 于 2015-10-22 11:39 编辑
20151022 淡然 续上
4.6 流程相关定义4.6.1 事件信息项 事件单必须包含如下事件信息项,各省可以在此基础上扩充。 表4-1 事件信息项 [td] | | | | | | | | 事件申报人的信息,包括:姓名、省/分公司、部门、电子邮件、办公电话、手机(手工填写) | | | | | | | | | 针对故障:指的是业务中断的实际时间(可能早于登记时间,需要手工填写) 针对其它:缺省值等于登记时间 | | | | | | | | | | | | | | | | | | 对应每一个事件优先级,系统根据流程相关定义中“事件解决时限”自动设定最终的完成期限(系统自动产生) | | | | | | | | | | | | | | | | | | | | | | | | 反映事件信息项的变化历史,如一个事件在处理过程中事件状态变化的时间点等信息(系统自动产生) | | | | | | 造成融合计费业务计划外中断的时间长度(分钟,手工填写) | | | 造成综合帐务业务计划外中断的时间长度(分钟,手工填写) | | | 造成客户服务业务计划外中断的时间长度(分钟,手工填写) | | | | | | | | | | | | | | | | | | | | | 参见《资源管理分册》厂商和集成商名称标准(手工填写) | | | | | | | | | |
4.6.2 事件性质 事件性质定义为如下五类事件: [td] | | | | | 与业务支撑系统相关的用户投诉,如10086、营业厅等面向客户的业务受理部门转来的因支撑系统问题引发的客户投诉 ITSS考试 | | | 指因业务支撑系统错误或反映支撑系统部分或全部功能不能正常使用的报障 监控管理平台上报的影响系统正常使用的告警 | | | | | | | | | |
4.6.3 事件来源 事件来源代码用来标明事件的提出方式,事件来源可以包括以下几种: [td] | | | | | 用户或地市维护人员通过电话/邮件/传真报告的事件,帮助台人员手工创建事件单 | | | | | | | | | | | | |
4.6.4 所属系统类型 定义业务系统。当事件发生时,应该由帮助台初步定位是哪个系统及子类出现问题,由一、二线进行进一步的明确。 注:各省在细化设计时不能修改此表中现有定义,第一层业务系统和第二层子类不能修改和扩充(注:第一层为“其他系统”的话,对应的子类可以扩充),但可以有选择的基于第二层子类定义扩充进行第三层条目的细化。对没有覆盖到的业务系统用“其他系统”表示。
4.6.5 事件分类 事件分类代码用于标识故障或申告的具体原因,由支持人员在处理过程中填写。在制作统计报表时,可以通过和所属系统类型代码的结合来统计分析故障或申告。 事件的分类层次设计不超过三层,第一级分类,称之为“类别”,第二级分类,称之为“子类”,第三级分类,称之为“条目”。 注:各省可以在此表的基础上扩展子类和自定义条目,针对一个子类,可以定义多个条目。
|