Changes for page 02 网管系统维护管理流程梳理项目—ITIL问题管理流程细化说明书

Last modified by superadmin on 2024/10/10, 20:57

From version < 10.1 >

edited by superadmin
on 2024/07/08, 13:28

To version < 11.1 >

edited by superadmin
on 2024/07/08, 13:38

< >

Change comment: There is no comment for this version

Raw
Rendered

Summary

Page properties (3 modified, 0 added, 0 removed)

Details

Page properties

Title

...	...	@@ -1,0 +1,1 @@
	1	+02 网管系统维护管理流程梳理项目—ITIL问题管理流程细化说明书

Parent

...	...	@@ -1,0 +1,1 @@
	1	+G 参考资料.ITIL实施项目资料.ITIL实施项目流程设计方案集.问题管理.WebHome

Content

@@ -1,0
          +1,1246 @@
++[[返回本章节索引>>http://www.itil4hub.cn/bin/view/G%20%E5%8F%82%E8%80%83%E8%B5%84%E6%96%99/ITIL%E5%AE%9E%E6%96%BD%E9%A1%B9%E7%9B%AE%E8%B5%84%E6%96%99/ITIL%E5%AE%9E%E6%96%BD%E9%A1%B9%E7%9B%AE%E6%B5%81%E7%A8%8B%E8%AE%BE%E8%AE%A1%E6%96%B9%E6%A1%88%E9%9B%86/%E9%97%AE%E9%A2%98%E7%AE%A1%E7%90%86/]]    阅读下一篇
++
++
++= **网管系统维护管理流程梳理项目—ITIL问题管理流程细化说明书** =
++
++
++=== **1 综述** ===
++
++**1.1 设计目的**
++
++本问题管理细化流程说明书是在概要设计基础上，通过对各省业务支撑网维护管理流程现状的了解和分析得出。本流程说明书旨在帮助省公司业务支撑网维护管理能够有效降低或消除相应突发事件，提高IT系统和服务的质量，向业务人员和相关用户提供更优质的IT服务，以有效地帮助省公司的业务支撑网维护管理从被动管理转向主动管理。
++
++
++**1.2 适用范围**
++
++本问题管理流程适用于中国移动集团公司和省公司的业务支撑系统维护工作中的问题管理。
++
++
++**1.3 相关术语**
++
++* ITIL（IT Infrastructure Library ）
++
++是英国政府在1987年制定的有关IT服务管理的方法论，现已成为事实上的IT管理标准。
++
++* 帮助台（Service Desk）
++
++帮助台从根本上来说是提供了用户和IT部门的唯一接口。此项功能常通过集中方式提供服务。帮助台的根本目的是提供初始支持，并通过变通方法、解决方案或升级到一线、二线支持等手段帮助用户恢复到正常工作状态。
++
++* 事件管理（ Incident Management）
++
++ITIL流程之一，事件管理负责解决所有的IT事件、问题和用户请求。它的目的是尽快恢复被中断或受到影响的IT服务，所以它的特点往往是以解决表征现象为目的，而不在于查找根本原因。
++
++* 问题管理（Problem Management）
++
++ITIL流程之一，问题管理负责解决重大紧急事件或具有相同症状的一组事件。它的目的是找出事件的根本原因，并通过解除该根本原因从而防止类似事件的再次发生。同时问题管理流程也负责预防事件的发生。
++
++* 配置管理（Configuration Management）
++
++ITIL 流程之一，配置管理负责描述，跟踪和汇报所有IT基础架构中的每一个设备或系统的管理流程。这些设备和系统被称为配置项(CI) 。每一个CI必须有效管理，跟踪和控制以支持公司的IT服务和基础设施成功运行。
++
++* 配置管理数据库（CMDB - Configuration Management Database）
++
++是在配置管理流程中用于记录企业所有IT相关配置项信息及其相互关系而建立的数据库。
++
++* 变更管理（Change Management）
++
++ITIL流程之一， 通过控制和管理IT相关的变更， 使变更对生产环境可能的影响和风险将到最小，从而提高IT环境的整体稳定性。
++
++
++=== **2 问题管理流程设计** ===
++
++**2.1 流程目的**
++
++问题管理流程的根本目的是消除或减少生产环境中事件发生的数量和严重程度，从而为企业建立一个稳定的IT环境，提高IT服务的可用性。此流程对发生在中国移动业务支撑系统生产环境中的问题进行管理，找出产生这些问题的根本原因，然后根据需要通过变更请求(RFC)、变通方法或建议的预防性措施来防止事件的再次发生。问题管理流程常常需要和变更管理流程一起来实施找出的解决方案，以便从根本上解决问题。其目的包括：
++
++1. 分析并确定事件的根本原因，找到最终解决方案，以防止此类事件再次发生
++1. 确保问题分派了正确支持人员，提高解决率
++1. 根据问题优先级合理分派IT资源
++1. 对事件记录做趋势性分析，主动提供预防性措施
++1. 提高IT服务的可靠性
++1. 降低IT支持成本
++
++**2.2 流程主要内容**
++
++问题管理流程着重于消除事件或减少事件发生，确定事件的根本原因。主要活动包括分析事件、找出问题、分派问题、确定根本原因以及找出解决方案、回顾及关闭，以消除事件或在其发生时降低对用户或业务的影响。其主要内容如下：
++
++* 分析事件
++
++定期分析事件，找出潜在问题。
++
++* 生成问题记录
++
++在系统中生成问题记录并把所有相关事件与此记录关联起来
++
++○紧急事件处理完后定义为问题
++
++○技术支持专家在日常维护中发现的问题
++
++○事件历史记录趋势分析
++
++* 分派
++
++根据问题内容将问题记录分派给适当的技术小组。
++
++* 根本原因分析
++
++被分派的小组人员将调查问题以期找出其原因，制定解决方案、变通方法或提出预防性措施，以消除产生原因，或在重发时使其影响力最小化。 记录必须被更新以反映它是已定位原因状态，并且把任何变通方法、避免或最小化负面影响的动作行为也记录下来（如果需要添加到知识库中）。
++
++* 开发、确认、提出实施解决方案
++
++ 对问题的解决方案进行评估、测试，提出变更请求（RFC）或实施具体的解决方案。
++
++* 回顾
++
++对问题的解决方案进行回顾，确认解决方案达到了预期的效果。
++
++* 总结及关闭
++
++确认问题的信息记录填写完整，并关闭问题记录。
++
++
++**2.3 与其他流程的关系**
++
++* 和事件管理流程的关系
++
++紧急事件将升级为问题，或根据事件的趋势分析，发现潜在的问题，同时问题的解决方案实施为事件流程提供了解决办法。
++
++* 和变更管理流程的关系
++
++问题管理流程的解决方案常常需要通过变更管理流程来完成，因此问题管理将会提出变更申请给变更管理流程。
++
++* 和配置管理流程的关系
++
++配置管理提供配置项信息给问题管理流程。
++
++
++**2.4 流程范围**
++
++问题管理流程范围是对BOSS系统、客服系统、经营分析系统、容灾系统和BOSS网管的IT生产环境中发生的问题进行管理，以采取主动性预防措施来降低事件数量。
++
++问题管理范围不包括处于开发或测试环境的系统和应用
++
++
++**2.5 流程执行原则**
++
++**2.5.1 常规原则**
++
++* 建立独立问题管理流程，在整个企业范围内应该与事件管理流程相对独立，事件经理与问题经理应该尽可能的由不同的人员担任
++* 应该每半年对问题管理流程的流程关键衡量指标、流程执行效率、流程支撑工具有效性等进行回顾，以改进和优化流程
++* 应该每月定期回顾和产生问题管理报表，对没有解决的问题，应该举行定期的问题管理会议对这些问题进行评估
++
++
++**2.5.2 流程关联原则**
++
++* 和事件管理的关联
++
++○所有优先级为紧急的事件在恢复服务后，都应该创建问题单（问题单必须和事件单建立关联）
++
++* 和变更管理的关联
++
++○问题处理过程中，如果需要对系统进行变更，必须按照变更管理的定义，提交变更请求单（变更单必须和问题单建立关联），变更完成后，继续问题单的处理
++
++* 和配置管理的关联
++
++○问题处理过程中，可以通过配置管理查询相关的配置项信息
++
++○问题处理过程中，如果可以将根本原因定位到某个配置项，则必须将问题单与该配置项关联
++
++
++**2.5.3 所有权原则**
++
++有效管理问题的前提是必须确保每个问题在任何时段都有适当的人员负责
++
++* 问题首先由问题经理审核，再负责分派给合适的问题处理专家或组
++* 当问题分派到问题处理专家后，问题处理专家负责该问题的诊断与解决
++* 问题经理负责与服务台或问题请求者沟通问题处理过程中的关键信息
++
++
++**2.5.4 再分派原则**
++
++再分派又称转派，它确保问题单不被过于频繁的相互转派、以至于无法在规定时间内得到解决，应当尽量减少问题单再分派的几率，一个问题单再分派的次数不应该超过两次。
++
++问题单再分派必须经过问题经理。
++
++**2.5.5重复问题原则**
++
++重复问题是指经过分析之后，根本原因相同的问题。例如：问题处理专家提出了几个问题，但是经过分析之后，发现这几个问题的根本原因是相同的，这几个问题就可以定义为重复问题。对于重复问题需要进行标志，将相关问题记录进行关联，当问题解决时同时进行回顾。
++
++**2.5.6 问题关闭原则**
++
++通常，问题单在实施了解决方案之后，需要经过一段时间的回顾，由问题处理专家和问题经理一起来回顾解决方案是否达到了预期的效果，如果成功的实施，则提交给问题经理，由问题经理确认问题信息记录完整，关闭问题。
++
++**2.5.7** **问题单重开原则**
++
++已关闭的问题单不允许重开。如果问题重复发生，则创建一个新的问题单。
++
++**2.5.8** **趋势分析原则**
++
++问题经理定期组织会议，对所处理事件历史记录进行趋势分析：
++
++* 参加者应包括事件经理及问题处理专家
++* 会议定期组织
++* 定义趋势分析规则
++
++**2.5.9 问题协同处理原则**
++
++计费中心的问题处理专家在对问题进行分析、诊断过程中，如果需要外部主要服务商处理专家（如思特奇）来处理，则由该问题处理专家将该问题以工单等形式分派给服务商，并对服务商的分析、处理过程进行监控和管理。
++
++
++**2.6 流程相关定义**
++
++**2.6.1 问题信息项**
++
++问题单包含如下信息项：
++
++|**序号**|**信息项**|**描述**
++|1|问题ID|为每个问题分配一个唯一的序列号（系统自动产生）
++|2|请求人信息|问题请求人的信息，包括：姓名、省/分公司、部门、电子邮件、办公电话、手机（手工填写）
++|3|登记时间|生成问题记录的时间（系统自动产生）
++|4|地点|记录问题发生的地点（手工填写）
++|5|问题来源|参见“问题来源”定义
++|6|问题优先级|参见“问题优先级”定义
++|7|问题所属系统类型|参见“问题所属系统类型”定义
++|8|问题分类|参见“问题分类”定义
++|9|问题标题|简单描述问题（手工填写）
++|10|问题描述|详细描述问题内容（手工填写）
++|11|问题拒绝原因|详细描述拒绝问题原因，并推荐其他专家或专家组（手工填写）
++|12|变通方法|详细记录问题的变通方法
++|13|问题原因|详细记录问题产生的根本原因（手工填写）
++|14|重复问题标记|标记为重复问题，用已有标题号标注（手工填写）
++|15|问题状态|参见“问题状态”定义
++|16|分配对象|将问题分配到各组问题处理专家（手工填写）
++|17|问题日志|反映问题处理过程中问题信息项的变化历史，包括分配的人员，状态等信息（系统自动产生）
++|18|实际开始诊断时间|问题状态更新为“分析中”的时间（手工填写）
++|19|实际诊断结束时间|问题状态更新为“已有解决方案”的时间（手工填写）
++|20|解决方案|问题解决方案的详细描述（手工填写）
++|21|问题结束代码|参见“问题结束代码”定义
++|22|问题无法解决原因|解释问题无法解决的原因（手工填写）
++|23|关联配置项|记录问题的配置项代码（手工填写）
++|24|关联的事件单号|记录引发该问题的事件单号（手工填写）
++|25|关联的变更单号|记录由问题发变更时，关联的变更单号（手工填写）
++|26|是否由重大事件升级|“是”或“否”，在问题创建时，根据关联的事件手工填写
++|27|问题关闭时间|当问题状态更新为“结束并关闭“的时间（手工填写）
++
++
++各角色能对个信息项的操作
++
++
++A 增加
++
++U 修改
++
++R 只读
++
++
++
++|**信息项**|**问题管理流程负责人**|**问题经理**|**问题处理专家**
++|记录|W|A|W
++|问题ID| | |
++|请求人信息| | |
++|登记时间| | |
++|地点| | |
++|问题来源| | |
++|问题优先级| | |
++|问题所属系统类型| | |
++|问题分类| | |
++|问题标题| | |
++|问题描述| | |
++|问题拒绝原因| | |
++|变通方法| | |
++|问题原因| | |
++|重复问题标记| | |
++|问题状态| | |
++|分配对象| | |
++|问题日志| | |
++|实际开始诊断时间| | |
++|实际诊断结束时间| | |
++|解决方案| | |
++|问题结束代码| | |
++|问题无法解决原因| | |
++|关联配置项| | |
++|关联的事件单号| | |
++|关联的变更单号| | |
++|是否由重大事件升级| | |
++|问题关闭时间| | |
++
++
++2.6.2 **问题来源**
++
++根据问题的不同来源对问题分类如下：
++
++|**编号**|**代码**|**描述**
++|1| 事件升级|(((
++紧急事件恢复服务后提出的问题，以便进行紧急事件的根本原因分析。
++
++
++例如：某日发生了一起集群无法切换的事件，导致某台主机发生故障后，没有切换到备用主机中去，从而影响了业务，紧急事件的处理人员在采取了手工切换的替代措施后，恢复了服务。
++
++为了分析为什么会发生该紧急事件，以及查看其他的集群是否也存在类似的问题，此时可以提出一个问题记录，以便对该紧急事件进行分析。
++)))
++|2|维护中提出|(((
++技术专家在日常维护工作中提出的问题。
++
++
++例如：维护专家在日常维护中发现，目前的数据库版本可能会存在着死锁、心跳不一致等方面的问题，此时就可以提出一个问题记录，以便分析。
++)))
++|3|趋势分析|(((
++分析事件记录找出的问题。
++
++
++例如：在定期的会议中，对计费类的事件进行分析后发现，上周该类型的事件比平常的时候多了30％，超过了规定的阀值，这表明计费系统有可能存在着一些潜在的隐患，此时就可以提出一个问题记录，以找出问题的原因并解决。
++)))
++
++2.6.3 **问题优先级**
++
++问题的优先级是问题处理专家解决问题的参照标准，对于关键优先级的问题，管理层应该优先协调资源进行这些问题的解决。结合中国移动的实际情况，问题的优先级定义如下：
++
++|**编号**|**代码**|**描述**
++|1|关键|(((
++紧急事件升级来的问题；
++
++维护专家提出或趋势分析产生的问题从如下方面考虑，问题是否：
++
++1. 影响到关键业务（如：综合帐务、定单管理、电话呼叫中心等）
++1. 影响范围极大（如：一个关键地区或半数以上非关键地区）
++1.  紧迫程度最高（如：必须马上着手处理）
++1.  问题处理后可大幅节省投资、人力，有效提高服务质量和维护效率
++)))
++|2|重要|(((
++从如下方面考虑，问题是否：
++
++1. 影响到较关键业务（如：综合采集、融合计费、产品管理等）
++1. 影响范围较大（如：一个以上非关键地区）
++1. 紧迫程度较高
++1. 问题处理后可有效节省投资、人力，一定程度提高维护质量
++)))
++|3|普通|(((
++从如下方面考虑，问题是否：
++
++1. 影响到非关键业务
++1. 有一定影响范围
++1. 问题处理后对维护质量和效率的提升有限
++)))
++
++2.6.4 **问题状态**
++
++为了记录问题处理的生命周期，需要设置不同的状态加以描述，如下所示：
++
++|**编号**|**代码**|**描述**
++|1|已登记|问题登录到系统中
++|2|分析中|问题处理专家正在分析问题过程中
++|3|已定位原因|问题根本原因已找出
++|4|已有解决方案|解决方案已找到
++|5|已提出变更请求|已提交变更请求（RFC）
++|6|已回顾|已经对问题进行了回顾
++|7|结束并关闭|问题结束
++
++2.6.5 **问题所属系统类型**
++
++根据业务支撑系统架构的问题所属的业务系统定义，当问题发生时，可以初步定位到是哪个系统出现问题。
++
++注：各省在细化设计时不能修改此表中现有定义，第一层业务系统和第二层子类不能修改和扩充(注：第一层为”其它系统”的话，对应的子类可以扩充)，但可以有选择的基于第二层子类定义扩充进行第三层条目的细化。对没有覆盖到的业务系统用”其它系统”表示。
++
++|**业务系统**|**子类**
++|(% rowspan="17" %)BOSS系统|营销管理
++|渠道管理
++|客户服务
++|产品管理
++|客户管理
++|资源管理
++|订单管理
++|服务开通
++|综合采集
++|融合计费
++|综合帐务
++|综合结算
++|合作伙伴管理
++|系统管理
++|统计报表
++|一级BOSS
++|其它
++|(% rowspan="9" %)客服系统|电话呼叫中心
++|互联网呼叫中心
++|短信呼叫中心
++|工单管理
++|知识管理
++|人力资源
++|质量管理
++|数据统计分析
++|其它
++|(% rowspan="3" %)经营分析|通用分析
++|专题分析
++|其它
++|(% rowspan="4" %)容灾系统|BOSS数据保护
++|BOSS业务接管
++|BOSS资源复用
++|其它
++|(% rowspan="3" %)BOSS网管|监控管理
++|服务管理
++|其它
++|其它系统|
++
++2.6.6 **问题分类**
++
++问题分类是针对问题所属的专业类型进行划分的，通过问题分类可以定位解决问题的人，并针对问题分类进行分类统计。
++
++问题的分类层次设计不超过三层，第一级分类，称之为“类别”，第二级分类，称之为”子类”，第三级分类，称之为”条目”。
++
++注：各省可以在此表的基础上扩展子类和自定义条目，针对一个子类，可以定义多个条目。
++
++|**类别**|**子类**
++|(% rowspan="8" %)系统硬件|路由器
++|网络交换机
++|小型机
++|PC服务器
++|磁盘阵列
++|存储光纤交换机
++|磁带库
++|光盘库
++|(% rowspan="4" %)客服设备|排队机
++|CTI服务器
++|CCS
++|IVR服务器
++|(% rowspan="5" %)安全设施|防火墙
++|IDS入侵监测系统
++|IPS入侵防护系统
++|防毒墙
++|安全软件
++|(% rowspan="6" %)系统软件|操作系统
++|数据库
++|中间件
++|集群软件
++|备份软件
++|系统管理软件
++|(% rowspan="3" %)配套设施|UPS
++|空调
++|其它
++|(% rowspan="5" %)应用软件|进程
++|数据
++|参数
++|代码
++|接口
++
++2.6.7 **问题结束代码**
++
++为了表明问题的不同解决方式，定义如下结束代码：
++
++|**编号**|**代码**|**描述**
++|1|根本解决|找出问题的根本原因，并得到解决方案，成功解决
++|2|变通方法|没有根本解决方案或目前没有办法实施根本解决方案，但有临时解决方案作为变通方法
++|3|无法解决|未找到问题的根本原因，没有解决方案，或目前无法实施解决方案，也无变通方法
++|4|取消|问题被问题经理拒绝
++
++
++2.7 **流程概要设计**
++
++问题管理概要设计流程图如下：
++
++[[image:图片1.png]]
++
++
++ 问题管理概要流程描述如下：
++
++|**序号**|**步骤名称**|**责任人**|**说明**
++|300.1|问题识别与记录|问题处理专家/问题经理|(((
++1. 对紧急事件、来自维护管理技术专家发现的问题以及通过对事件记录进行的分析发现的潜在问题，根据需要在系统中进行记录，并对问题信息进行描述。
++1. 根据问题所属领域进行分类，并初步判断问题的优先级。
++)))
++|300.2|问题审核|问题经理|(((
++1. 问题经理对新建的问题进行审核：问题经理确定问题是否有效、是否是重复问题，优先级的分配是否合适，问题信息项填写是否完整。
++1. 如果问题确认无效，则关闭问题，并通知请求者。
++)))
++| |上报集团公司|问题经理|(((
++1. 对确认有效的问题，如果其优先级是”关键”，在处理的同时，将问题升级到部门主管领导、省公司领导及集团，同时也需要将问题处理的关键状态定时上报。
++)))
++|300.3|问题分派|问题经理|(((
++1. 根据问题的分类，把问题分派给相应问题处理专家。如问题处理专家发现问题应该由其他组分析解决，就把问题发回问题经理，注明拒绝理由并推荐其他分析组。
++)))
++|300.4|分析并诊断问题/提供变通方法|问题处理专家|(((
++问题处理专家接受问题，更新问题状态及实际开始诊断时间：
++
++1. 如需其他问题处理专家协助分析、诊断，则通知问题经理，由问题经理协调资源，成立问题分析小组，举行问题根本原因分析研讨会议，并确定问题的潜在原因，提供或更新问题变通方法，以降低问题在根本解决前对业务产生的影响；
++1. 将问题产生根本原因及变通方法及时更新到问题记录中；
++1. 将问题根本原因及变通方法通知问题经理；
++1. 如果问题处理专家预计无法找到问题的根本原因，及时通报问题经理。
++)))
++|300.5|问题监控|问题经理|(((
++问题经理负责问题分析、诊断、解决过程中的跟踪和监控：
++
++1. 在问题找到根本原因或解决方案之后，根据需要，向帮助台或问题请求人员通报该问题的解决情况，以帮助和提高事件的解决率。
++1. 对于问题处理专家认为无法找到根本原因或虽有解决方案，但目前无法实施（如实施的代价太大等），问题经理协调问题处理专家进行分析判断，决定该问题是继续诊断、解决还是关闭该问题。
++)))
++|300.6|开发、确认、实施解决方案|问题处理专家|(((
++对于已经找到根本原因的问题，需要确定解决方案，以便永久的解决。
++
++1. 推荐并测试根本性解决方案，并确保这些方案彻底解决问题，更新问题记录中的实际诊断结束时间。
++1. 判断实施上述解决方案/变通方法是否需要通过其他流程（如变更流程等）：
++
++- 如需要，提交到相应的流程，并和该流程人员保持沟通，了解问题的解决状况；
++
++- 如不需要变更，计划并组织实施解决方案以解决问题。
++
++1. 如果需要第三方介入，则问题处理专家负责与第三方的接口与协调。
++1. 如果问题处理专家预计在无法找到根本解决方案或虽有解决方案但目前无法实施（如实施的代价太大），通报问题经理。
++)))
++|300.7|问题回顾|问题处理专家|(((
++1. 问题处理专家对问题进行回顾，确认问题是否被正确的解决，如果没有解决，转到300.4分析并诊断问题/提供变通方法。
++)))
++|300.8|问题总结与关闭|问题经理|(((
++1. 问题经理对问题记录的信息项进行总结，更新问题记录并关闭问题。
++1. 对于由紧急事件产生的问题上报集团。
++)))
++
++
++**2.8** **流程详细设计**
++
++问题管理详细流程设计如下：
++
++**2.8.1（300.1）问题的识别与记录**
++
++ [[image:图片2.png]]
++
++
++详细流程描述如下:
++
++|**序号**|**步骤名称**|**责任人**|**输入**|**输出**|**说明**
++| |趋势分析|问题经理|事件详细记录|事件趋势，潜在问题|(((
++问题经理周期性的召集由事件经理、问题处理专家参加的会议，对事件记录详细信息进行趋势分析（可以每周/每月为周期）：
++
++1. 在本周期内每类事件的数量
++1. 发生的频度有不断增加的趋势的事件
++1. 对于没有根本解决的事件记录进行分析
++
++可采取趋势突变法（如有30%增长率的某类事件）或阈值法对事件进行分析，发现需进一步分析的潜在问题。
++
++
++另外，问题经理也可以根据需要召集问题处理专家等相关技术人员对于未根本解决的问题进行再次分析，以决定是否需要创建问题来进一步分析。
++)))
++| |事件升级|事件经理|紧急事件详细记录| |在紧急事件处理完成后(无论是否根本解决)，都由事件经理将紧急事件的处理情况、事件记录提交给问题经理。
++| |维护中提出|维护专家| | |(((
++由维护技术人员在日常维护工作中根据自己的经验或分析，在自己负责的领域内发现并提出的问题请求：
++
++1. 通过日常巡检发现的问题
++1. 对日常维护监控数据进行分析
++)))
++|300.1.1|创建问题记录|问题经理/问题处理专家| |问题记录|(((
++综合上述三种情况，由问题经理或问题处理专家在系统中创建问题记录：
++
++1. 选择问题来源；
++1. 记录问题详细描述，包括产生时间、地点、标题及现象描述等，例如在问题描述中也需要指出问题的来源具体人员；
++1. 问题状态设置为“已登记”。
++)))
++|300.1.2|初步确定问题优先级及分类|问题经理/问题处理专家|问题记录|问题优先级/分类|(((
++问题记录创建时，问题创建人需要完成：
++
++1. 根据问题记录的实际情况及预先制定的优先级描述，初步给问题记录分配相应的优先级代码；
++1. 根据问题的来源和所涉及的领域，及已定义的分类原则，初步对问题进行分类。
++)))
++|300.1.3|关联相关CI 及事件记录|问题经理/问题处理专家|问题记录|进行关联之后的问题记录|(((
++根据问题记录的信息描述，对创建的问题记录关联相关CI，并将问题与系统中的事件记录进行关联。以利于问题处理专家对问题的分析、解决。
++
++例如：问题记录是由紧急事件升级而成的，此处便可以将该问题记录与原紧急事件记录做关联。
++
++
++)))
++
++
++**2.8.2 （300.2）问题审核 **
++
++**[[image:图片3.png]]**
++
++
++详细流程描述如下:
++
++|**序号**|**步骤名称**|**责任人**|**输入**|**输出**|**说明**
++|300.2.1|审核问题记录的完整性|问题经理|审核后的问题记录|需完善的问题记录/通知问题请求者|(((
++1. 问题经理对新登记的问题记录进行审核，检查问题记录信息是否正确和完整；
++1. 如果问题记录信息不完整或不正确，则通知问题请求者，由其提供完善的问题信息。
++)))
++| |问题有效吗？|问题经理| | |(((
++1. 问题经理审核该问题的有效性，如问题经理需判断该问题是否值得解决、该问题是否在将来的版本中已经考虑等，如果是无效问题，到300.2.2关闭问题记录/通知问题请求者。
++)))
++|300.2.2|关闭问题记录/通知请求者|问题经理|问题记录|关闭问题记录|(((
++1. 更新该问题记录信息，更新该问题的状态代码为“关闭“，更新结束代码为“取消”，关闭该问题记录。
++1. 通知问题请求者，如自动触发email。
++)))
++| |重复问题吗？|问题经理| | |(((
++1. 判断该问题是否与系统中的其他问题记录匹配，如果是，到300.2.3标志重复问题。
++)))
++|300.2.3|标志重复问题|问题经理|问题记录|已标志重复的问题标记|(((
++1. 使用已有问题的问题ID更新该问题信息单中的问题重复标记。
++1. 该问题的分析诊断及状态变化将与原主问题保持一致。
++)))
++| |优先级/分类正确吗？|问题经理| | |(((
++1. 判断该问题的优先级及分类是否正确，如果不正确，到300.2.4更新正确优先级/分类。
++)))
++|300.2.4|更新正确优先级/分类|问题经理| |更新的问题记录|(((
++1. 更新问题记录中的优先级及分类代码。
++)))
++| |是关键问题吗？|问题经理|问题记录|关键问题上报集团公司|(((
++1. 如果是，将关键问题的信息上报集团公司。
++)))
++
++
++**2.8.3 （300.3）问题分派**
++
++**[[image:图片4.png]]**
++
++
++详细流程描述如下：
++
++|**序号**|**步骤名称**|**责任人**|**输入**|**输出**|**说明**
++|300.3.1|分派问题到问题处理专家|问题经理|问题记录|已分配的问题|根据问题所属类别，把问题分派给相应的问题处理专家。若问题比较复杂，问题经理需组建问题分析小组，并将该问题分配给当中最主要的处理人员。
++| |接受吗？|问题处理专家|已分派问题|拒绝分派问题|(((
++问题处理专家在收到问题经理分派的问题后，对问题进行初步分析，以决定接受与否：
++
++1. 如拒绝，注明拒绝的理由，并推荐相应的工作组或个人，将问题发回问题经理重新进行分派，并通知问题经理；
++1. 如接受，则将状态改为“分析中”，转向300.4分析并诊断问题/提供变通方法。
++)))
++
++
++**2.8.4 （300.4）分析并诊断问题/提供变通方法**
++
++
++**[[image:图片5.png]]**
++
++
++详细流程描述如下：
++
++|**序号**|**步骤名称**|**责任人**|**输入**|**输出**|**说明**
++|300.4.1|查找可能原因列表|问题处理专家|已分配问题记录|问题可能原因列表|(((
++1. 问题处理专家对问题进行分析，找出可能的原因列表。如果该问题比较复杂，需要其他专业组配合，则通知问题经理来协调资源，召开问题分析小组会议来共同分析。
++)))
++|300.4.2|确认问题根本原因|问题处理专家|问题可能的原因列表|问题根本原因|(((
++1. 分析问题的原因列表，找出最有可能的原因并测试，从而确定问题的根本原因；
++1. 当问题处理专家预见或确认目前不能确定问题的根本原因时，通报问题经理，来共同分析对该问题的处理。
++)))
++|300.4.3|推荐变通方法|问题处理专家|问题根本原因|变通方法|(((
++1. 问题处理专家根据需要制定相应的变通方法（如果已预见到根本性解决问题需要时间而问题需要首先临时性解决或得到控制），以降低问题的影响；
++1. 将问题根本原因及变通方法信息更新到问题管理系统中，并更新问题状态为“已定位原因”，并通报问题经理；
++1. 如需要，更新相应的知识库。
++)))
++
++
++2.8.5 **（300.5）问题监控**
++
++
++**[[image:图片6.png]]**
++
++
++详细流程描述如下：
++
++|**序号**|**步骤名称**|**责任人**|**输入**|**输出**|**说明**
++|300.5.1|检查问题状态|问题经理|问题记录| |(((
++问题经理定期检查问题状态，当：
++
++1. 检查问题的处理情况，认为需要时；
++1. 接受到问题处理专家在问题分析诊断及解决过程中发来的的通报时。
++
++问题经理（需要时协调问题处理专家）根据问题记录的当前状态、现在的解决进度等来分析判断该问题如何继续。
++)))
++| |需要通报吗？|问题经理| | |(((
++1. 判断该问题是否需要与帮助台、问题请求者等沟通，如果需要通报，则转到300.5.2通报问题原因/变通方法。
++)))
++|200.5.2|通报问题原因/变通方法/根本解决方案|问题经理|需要通报的问题信息| |(((
++1. 如需要，及时将问题根本原因/变通方法/根本解决方案通知（通过电话，email等）帮助台及问题请求者，使帮助台能快速响应类似或相关事件，降低对业务的影响。
++)))
++| |需要上报吗？| | | |(((
++1. 如果是关键问题的状态更新为“已定位原因”或“已有解决方案”，则需要将问题的信息单上报。
++)))
++| |需要关闭吗？|问题经理|问题信息| |(((
++1. 判断该问题记录是否需要关闭，例如：根据分析判断目前无法找到该问题的根本原因或无法根本解决该问题，或该问题已经消失等，或者由于其他原因需要将该问题记录关闭；
++1. 如果需要关闭，则转到300.5.3 协调/通知相关人员。
++)))
++|200.5.3|协调/通知相关人员|问题经理|问题记录|需关闭问题|(((
++1. 问题经理与问题处理专家沟通将关闭该问题，并通知问题请求者。
++)))
++
++
++2.8.6 **（300.6）开发、确认、实施解决方案**
++
++**[[image:图片7.png]]**
++
++
++详细流程描述如下：
++
++
++|(% colspan="2" %)**序号**|**步骤名称**|(% colspan="2" %)**责任人**|**输入**|**输出**|**说明**
++|300.6.1|(% colspan="2" %)尝试找出解决方案|问题处理专家|(% colspan="2" %)根本原因已找到的问题|可能解决方案|(((
++1. 根据问题的根本原因，问题处理专家尝试找出所有可能的解决方案。
++)))
++|300.6.2|(% colspan="2" %)记录最可能解决方案|问题处理专家|(% colspan="2" %) |解决方案|(((
++1. 对所有可能的解决方案进行分析，找出最有可能的解决方案，并对解决方案进行测试；
++1. 确认问题根本解决方案，并详细更新到问题记录系统中，更新问题记录的状态为“已有解决方案”，并通报问题经理；
++1. 当问题处理专家预见目前不能实施根本解决方案时，通报问题经理，来共同分析对该问题的处理。
++)))
++|(% colspan="2" %) |需要变更吗？|(% colspan="2" %)问题处理专家| | |(((
++1. 判断实施解决方案是否需要进行变更，如果需要转300.6.3 提交RFC/监视变更的实施；
++1. 如果不需要变更，转300.6.4 计划和安排实施。
++)))
++|(% colspan="2" %)300.6.3|提交RFC/监视变更的实施|(% colspan="2" %)问题处理专家| |变更请求|(((
++1. 填写变更请求单（RFC），提交到变更管理流程，并跟踪监视变更的实施情况，更新问题状态为“已提出变更请求”。
++)))
++|(% colspan="2" %)300.6.4|计划和安排实施|(% colspan="2" %)问题处理专家| |实施解决|(((
++问题处理专家（必要时协调问题经理）组织人员实施解决方案：
++
++1. 制定方案实施计划，包括参加人员，实施时间等；
++1. 实施解决方案。
++)))
++
++
++2.8.7**（300.7）问题回顾**
++
++**[[image:图片8.png]]**
++
++
++详细流程描述如下：
++
++|**序号**|**步骤名称**|**责任人**|**输入**|**输出**|**说明**
++|300.7.1|对问题进行回顾|问题处理专家|问题的解决方案已经实施| |(((
++1. 根据问题的描述、优先级以及具体的解决方案等内容，对问题的改正效果进行监控，以确保问题被正确的解决。
++)))
++| |问题都解决了吗？|问题处理专家| | |(((
++1. 判断问题是否被正确的解决，如果问题没有被正确解决，转300.4分析并诊断问题/提供变通方法，重新对问题的根本原因进行分析。
++)))
++| |问题优先级为关键吗？|问题处理专家| | |(((
++1. 判断是否是关键问题，如果是，转300.7.2 编写关键问题报告；如果不是，转300.8问题总结与关闭。
++)))
++|300.7.2|编写关键问题报告|问题处理专家|关键问题|问题分析报告|(((
++1. 编写关键问题报告，内容包括： 问题描述、原因分析、解决方案、经验总结。
++)))
++
++
++
++2.8.8 **（300.8）问题总结与关闭**
++
++**[[image:图片9.png]]**
++
++
++详细流程描述如下：
++
++|**序号**|**步骤名称**|**责任人**|**输入**|**输出**|**说明**
++|300.8.1|对问题记录进行检查|问题经理|问题信息|完善的问题信息|(((
++1. 检查问题信息项的填写情况，例如：问题描述是否恰当、问题的根本原因、变通方法及解决方案是否填写完整等，如需要，做必要调整，以确保每条问题的信息记录准确且完整。
++)))
++|300.8.2|对问题进行总结|问题经理|问题信息|预防措施|(((
++1. 针对问题产生原因，分析当前运营环境中是否有类似情况，借鉴本问题的根本原因及解决方案，提前预防；
++1. 对由重大事件产生的关键问题，参照问题处理专家编写的”关键问题报告”，完成”重大事件问题分析报告”，内容包括：问题的发生时间、处理人、处理过程、影响范围、原因分析、解决方案、后续工作及经验归纳；
++1. 对其他关键问题，审核相应的”关键问题报告”。
++)))
++|300.8.3|关闭问题|问题经理| |状态|(((
++1. 选择相应的结束代码，更新问题状态为“结束并关闭”；
++1. 对于重大事件产生的关键问题，需将问题信息单及”重大事件问题分析报告”上报集团公司；
++1. 对于其他关键问题，需将问题信息单及”关键问题报告”上报集团公司；
++1. 关闭问题记录，如需要，通报事件管理流程。
++)))
++
++
++**2.9 问题状态迁移图 **
++
++**[[image:图片10.png]]**
++
++
++当前状态为‘已登记’状态时，可迁移的状态
++
++|**状态**|**合法**|**描述**
++|分析中|是|问题经理将问题分派给问题处理专家，问题处理专家开始分析诊断
++|已定位原因|否|
++|已有解决方案|否|
++|已提出变更请求|否|
++|已回顾|否|
++|结束并关闭|是|对于无效问题，可以结束并关闭
++
++
++当前状态为‘分析中’状态时，可迁移的状态
++
++|**状态**|**合法**|**描述**
++|已登记|否|
++|已定位原因|是|经过问题处理专家分析，找到根本原因
++|已有解决方案|否|
++|已提出变更请求|否|
++|已回顾|否|
++|结束并关闭|是|对于现在判断无法找到根本原因，但需关闭的问题
++
++ 当前状态为‘已定位原因’状态时，可迁移的状态
++
++|**状态**|**合法**|**描述**
++|已登记|否|
++|分析中|否|
++|已有解决方案|是|经过问题处理专家分析测试，找到根本解决方案
++|已提出变更请求|否|
++|已回顾|否|
++|结束并关闭|是|对于现在判断无法找到根本解决方案，但需关闭的问题
++
++
++当前状态为‘已有解决方案’状态时，可迁移的状态
++
++|**状态**|**合法**|**描述**
++|已登记|否|已登记为问题单初始状态
++|分析中|否|
++|已定位原因|否|
++|已提出变更请求|是|如果实施问题解决方案需要通过变更管理流程，提出变更请求
++|已回顾|是|实施完成后，已对问题解决方案回顾完成
++|结束并关闭|是|对于现在判断无法实施解决方案，但需关闭的问题
++
++
++当前状态为‘已提出变更请求’状态时，可迁移的状态
++
++|**状态**|**合法**|**描述**
++|已登记|否|已登记为问题单初始状态
++|分析中|否|问题经理将问题分派给问题处理专家，问题处理专家开始分析诊断
++|已定位原因|否|
++|已有解决方案|否|
++|已回顾|是|问题经实施完成后，进入回顾
++|结束并关闭|否|
++
++
++当前状态为‘已回顾’状态时，可迁移的状态
++
++|**状态**|**合法**|**描述**
++|已登记|否|
++|分析中|是|对于问题回顾后发现没有根本解决的问题，由问题处理专家重新进行分析
++|已定位原因|否|
++|已有解决方案|否|
++|已提出变更请求|否|
++|已回顾|否|
++|结束并关闭|是|实施回顾后，结束并关闭
++
++
++当前状态为‘结束并关闭’状态时，可迁移的状态
++
++不迁移至任何状态。
++
++
++
++**2.10 关键角色、职责定义**
++
++流程的实现是通过不同的流程角色以及其所赋予的职责来实现的，因此流程的每一个角色可以被定义为一系列职责的集合。在实际的管理操作中，不同的角色可以将被赋予不同的人员，也可能一个人被赋予多个角色，同时也可以将其职责授权给其管理结构之下的人员。因此，以下所提及的问题管理流程和角色的目的是为了在充分满足流程所需角色的基础上，为具体的实现提供足够的灵活性。具体部署由中国移动在实际实施中的流程执行负责人决定。 问题管理流程主要分为问题管理流程负责人、问题经理及问题处理专家三个角色。
++
++2.10.1 **问题管理流程负责人**
++
++问题管理流程负责人从总体上对问题管理流程的设计、实施、执行及优化负责，确保问题管理流程在业务支持中心范围内被正确的执行。当流程不能够适应业务支持中心的情况时，流程负责人必须及时的对此进行分析、找出缺陷、进行改进，从而实现可持续提高。
++
++职责:
++
++1. 确保问题流程的设计、实施及执行，能够取得管理层的参与和支持
++1. 确保问题流程符合公司实际状况和公司 IT发展战略
++1. 整体上对问题流程负责，建立流程实施、评估和持续优化机制
++1. 确保问题流程的有效执行，定期评估流程，制定流程改进计划
++1. 保持与其他流程负责人的定期沟通
++
++技能要求：
++
++1. 深刻理解问题管理流程
++1.  充分理解业务支撑网维护管理流程梳理项目的其他流程，能够进行流程接口设计
++1.  能够很好地理解业务对于问题管理的需求
++1.  对质量控制与保障有很深入的了解
++1.  有决策权，能够确保问题管理流程设计要求在实施项目中得到贯彻和执行
++1.    具有很好的沟通技能，能够取得公司高层的支持，获得所需资源
++1. 具有较强的计划、组织、领导和控制才能，能够综合各方意见，按时制订和定期优化问题管理流程
++
++
++
++2.10.2 **问题经理**
++
++问题经理负责协调日常的问题管理工作，包括对问题的审核、监控、所需资源的协调、定期产生报表等。
++
++职责：
++
++1. 领导问题管理小组，确保大家的积极性、技能水平
++1. 定期组织相关人员对事件记录进行分析，发现潜在问题
++1. 确认和审核问题
++1. 必要时对问题进行上报
++1. 监视问题的诊断、分析和处理过程
++1. 必要时与帮助台及问题请求者沟通问题的相关信息
++1. 必要时协调所需资源
++1. 定期制定问题报表，提供正确决策信息
++
++技能要求：
++
++1. 具有较好的沟通和口头表达能力
++1. 熟悉技术平台和技术环境
++1. 较强的分析事件趋势的能力
++1. 深刻熟悉问题管理流程
++
++
++2.10.3 **问题处理专家**
++
++问题处理专家为问题的诊断及解决提供技术支持。通常由各专业组技术人员承担。
++
++职责：
++
++1. 接受问题经理分派过来的问题
++1. 分析和诊断问题，确定根本原因
++1. 确定和测试解决方案
++1. 提交变更请求并监控变更实施
++1. 协助事件支持人员进行重大或紧急事件的处理
++1. 需要时协调第三方的资源来帮助诊断和改正问题
++
++技能要求：
++
++1. 较强的问题解决能力， 能够对问题进行分析并给出解决方案
++1. 较强的专业知识
++1. 较强的分析问题的能力和技巧
++1. 较好的沟通和表达能力
++
++
++2.10.4 **流程角色和人员对应表**
++
++|(% colspan="2" %)**角色**|**成员**
++|问题管理流程负责人| |周晓伟
++|问题经理A| |苏伟杰
++|问题经理B| |周晓伟
++|(% rowspan="9" %)问题处理专家|基础平台组|郑水华、乔迎春
++|计费结算|苏伟杰、罗芳
++|客服组|温健军、魏亚菲
++|经分组|张航友
++|营业账务|刘三苏、陈伟
++|基础平台组|郑水华、乔迎春、卢定、高松、高雄英
++|开发组|张超、黄丽鹃
++|思特奇|
++|亚信|
++
++注：在系统实施时由四川移动公司根据实际运维架构在此表基础上完成具体的人员映射
++
++
++2.11 **关键流程衡量指标**
++
++为了较好地控制问题管理流程的质量，必须为问题管理流程设置考核指标，通过对指标的分析，可以有效地对流程的运行情况进行监控和改进。
++
++问题管理流程的关键衡量指标如下：
++
++|**序号**|**衡量指标**|**指标计算说明**
++|1|问题总数|(((
++数量：在问题单中根据以下条件过滤，
++
++1. 【重复问题标记】为空
++1. 【问题结束代码】不等于‘取消’
++1. 【登记时间】在统计周期内
++)))
++|2|已找到根本原因的问题数量|数量：在问题总数中，【问题状态】=‘已定位原因’ 的问题个数
++|3|趋势分析问题所占比率|(((
++数量：在问题总数中，【问题来源】=‘趋势分析’ 的问题个数
++
++比率：数量 / 问题总数  × 100 %
++)))
++|4|关闭问题数量|数量：【问题关闭时间】在统计周期内，【问题状态】=‘结束并关闭’的问题个数
++|5|通过变通办法解决的问题数量|数量：在关闭问题数量中，【问题结束代码】=‘变通方法’的问题个数
++|6|问题成功解决率|(((
++数量：在关闭问题数量中，【问题结束代码】=‘根本解决’的问题个数
++
++比率：数量 /关闭问题数量  × 100 %
++)))
++|7|平均诊断时间|(((
++诊断完成问题数量：【实际诊断结束时间】在统计周期内的问题个数
++
++平均诊断时间：累加诊断完成问题的（【实际诊断结束时间】－【实际诊断开始时间】）/ 诊断完成问题数量
++
++
++)))
++
++
++
++2.12 **集团、省公司两级交互**
++
++为便于集团公司及时、准确地了解各省业务支撑网的问题管理流程执行状况，指导各省IT服务管理模式的规范化，集团公司业务支撑网网管系统可以实时或定期地获取各省公司业务支撑网网管系统的重要指标数据及统计报表数据。
++
++对于优先级为“关键”的问题，省公司应上报集团公司，并在该问题处理过程中的关键状态点，将最新问题记录信息上传到集团公司。在将来条件成熟时，集团公司收到各个省公司上报的问题信息后，对相应的解决方案加以收集、归纳、整理，形成全集团的知识，可以向其他省公司通报，以提高各个省公司的支撑水平。
++
++|(% rowspan="2" %)(((
++**上报**
++
++**方式**
++)))|(% rowspan="2" %)(((
++**触发条件**
++
++
++)))|(% colspan="2" %)**上报内容**
++|**问题信息项**|**附件内容（问题报告）**
++|(% rowspan="4" %)服务管理平台|问题经理审核后确认优先级为关键时|所有问题信息项|N/A
++|问题状态更新为“已定位原因”时|所有问题信息项|N/A
++|问题状态更新为“已有解决方案”时|所有问题信息项|N/A
++|问题经理将问题关闭时|所有问题信息项|(((
++如果问题是由重大事件升级，上报时增加”重大事件问题分析报告”；报告内容包括：
++
++问题的发生时间、处理人、处理过程、影响范围、原因分析、解决方案、后续工作及经验归纳。
++
++其他关键问题提供”关键问题报告”：问题描述、原因分析、解决方案、经验总结。
++)))
++
++2.13 **省公司报表**
++
++省公司报表定义如下，同时，上报集团报表也可以供省公司使用。
++
++
++2.13.1 **问题目录列表**
++
++
++
++|**问题ID**|**  所属系统类型**|**问题分类**|**问题优先级**|**问题来源**|**问题处理专家**|**问题状态**|**问题描述**|**根本原因**|(((
++**变通方法**
++
++
++)))|**解决方案**|**实际诊断开始时间**
++| | | | | | | | | | | |
++| | | | | | | | | | | |
++| | | | | | | | | | | |
++| | | | | | | | | | | |
++| | | | | | | | | | | |
++
++
++
++指标说明：
++
++反映在统计周期内的未关闭的问题列表，包括问题ID、问题所属系统类型、问题分类、问题优先级、问题处理专家、问题状态，问题描述、根本原因、变通方法、解决方案及实际诊断开始时间。
++
++
++2.13.2 **按照不同优先级的新增问题的统计报表**
++
++
++|(% rowspan="2" %)**优先级**|(% rowspan="2" %)**问题总数**|(% colspan="3" %)**问题来源**|(% colspan="7" %)**问题状态**|**平均诊断时间**
++|**事件升级**|**维护中提出**|**趋势分析**|**已登记**|**分析中**|**已定位原因**|**已有解决方案**|(((
++**已提出变更请求**
++
++
++)))|**已回顾**|**结束并关闭**|
++|关键| | | | | | | | | | | |
++|重要| | | | | | | | | | | |
++|普通| | | | | | | | | | | |
++
++指标说明：
++
++|**序号**|**指标名称**|**指标计算说明**
++|1|问题总数|(((
++数量：在问题单中根据以下条件过滤
++
++1.【重复问题标记】为空
++
++2.【问题结束代码】不等于‘取消’
++
++3.【登记时间】在统计周期内
++)))
++|2|事件升级|数量：在问题总数中，【问题来源】＝‘事件升级‘的问题个数
++|3|维护中提出|数量：在问题总数中，【问题来源】＝‘维护中提出‘的问题个数
++|4|趋势分析|数量：在问题总数中，【问题来源】＝‘趋势分析‘的问题个数
++|5|已登记|数量：在问题总数中，【问题状态】＝‘已登记‘的问题个数
++|6|分析中|数量：在问题总数中，【问题状态】＝‘分析中‘的问题个数
++|7|已定位原因|数量：在问题总数中，【问题状态】＝‘已定位原因‘的问题个数
++|8|已有解决方案|数量：在问题总数中，【问题状态】＝‘已有解决方案‘的问题个数
++|9|已提出变更请求|数量：在问题总数中，【问题状态】＝‘已提出变更请求‘的问题个数
++|10|已回顾|数量：在问题总数中，【问题状态】＝‘已回顾‘的问题个数
++|11|结束并关闭|数量：在问题总数中，【问题状态】＝‘结束并关闭‘问题个数
++|12|平均诊断时间|(((
++诊断完成问题数量：【实际诊断结束时间】在统计周期内的问题个数
++
++平均诊断时间：累加诊断完成问题的（【实际诊断结束时间】－【实际诊断开始时间】）/ 诊断完成问题数量
++)))
++
++
++**2.14 省公司上报报表**
++
++**2.14.1 按照业务系统的新增问题的统计报表**
++
++|(% rowspan="2" %)**业务系统**|(% rowspan="2" %)**问题总数**|(% colspan="3" %)**问题来源**|(% colspan="7" %)**问题状态**|(% colspan="3" %)**优先级    **
++|**事件升级**|**维护中提出**|**趋势分析**|**已登记**|**分析中**|**已定位原因**|**已有解决方案**|**已提出变更请求**|**已回顾**|**结束并关闭**|**关键**|**重要**|**普通**
++|BOSS系统| | | | | | | | | | | | | |
++|客服系统| | | | | | | | | | | | | |
++|经营分析| | | | | | | | | | | | | |
++|容灾系统| | | | | | | | | | | | | |
++|BOSS网管| | | | | | | | | | | | | |
++
++指标说明：
++
++|**序号**|**指标名称**|**指标计算说明**
++|1|问题总数|(((
++数量：在问题单中根据以下条件过滤
++
++1.【重复问题标记】为空
++
++2.【问题结束代码】不等于‘取消’
++
++3.【登记时间】在统计周期内
++)))
++|2|事件升级|数量：在问题总数中，【问题来源】＝‘事件升级‘的问题个数
++|3|维护中提出|数量：在问题总数中，【问题来源】＝‘维护中提出‘的问题个数
++|4|趋势分析|数量：在问题总数中，【问题来源】＝‘趋势分析‘的问题个数
++|5|已登记|数量：在问题总数中，【问题状态】＝‘已登记‘的问题个数
++|6|分析中|数量：在问题总数中，【问题状态】＝‘分析中‘的问题个数
++|7|已定位原因|数量：在问题总数中，【问题状态】＝‘已定位原因‘的问题个数
++|8|已有解决方案|数量：在问题总数中，【问题状态】＝‘已有解决方案‘的问题个数
++|9|已提出变更请求|数量：在问题总数中，【问题状态】＝‘已提出变更请求‘的问题个数
++|10|已回顾|数量：在问题总数中，【问题状态】＝‘已回顾‘的问题个数
++|11|结束并关闭|数量：在问题总数中，【问题状态】＝‘结束并关闭‘问题个数
++|12|关键|数量：在问题总数中，【问题优先级】＝‘关键‘的问题个数
++|13|重要|数量：在问题总数中，【问题优先级】＝‘重要‘的问题个数
++|14|普通|数量：在问题总数中，【问题优先级】＝‘普通‘的问题个数
++
++2.14.2 **按照分类的新增问题的统计报表**
++
++|(% rowspan="2" %)**类别**|(% rowspan="2" %)**子类**|(% rowspan="2" %)**问题总数**|(% colspan="3" %)**问题来源**|(% colspan="7" %)**问题状态**|(% colspan="3" %)**优先级    **
++|**事件升级**|**维护中提出**|(((
++**趋**
++
++**势**
++
++**分**
++
++**析**
++)))|**已登记**|**分析中**|**已定位原因**|**已有解决方案**|**已提出变更请求**|**已回顾**|**结束并关闭**|**关键**|**重要**|**普通**
++|(% rowspan="8" %)系统硬件|路由器| | | | | | | | | | | | | |
++|网络交换机| | | | | | | | | | | | | |
++|小型机| | | | | | | | | | | | | |
++|PC服务器| | | | | | | | | | | | | |
++|磁盘阵列| | | | | | | | | | | | | |
++|存储光纤交换机| | | | | | | | | | | | | |
++|磁带库| | | | | | | | | | | | | |
++|光盘库| | | | | | | | | | | | | |
++|(% rowspan="4" %)客服设备|排队机| | | | | | | | | | | | | |
++|CTI服务器| | | | | | | | | | | | | |
++|CCS| | | | | | | | | | | | | |
++|IVR服务器| | | | | | | | | | | | | |
++|(% rowspan="5" %)安全设施|防火墙| | | | | | | | | | | | | |
++|IDS入侵监测系统| | | | | | | | | | | | | |
++|IPS入侵防护系统| | | | | | | | | | | | | |
++|防毒墙| | | | | | | | | | | | | |
++|安全软件| | | | | | | | | | | | | |
++|(% rowspan="6" %)系统软件|操作系统| | | | | | | | | | | | | |
++|数据库| | | | | | | | | | | | | |
++|中间件| | | | | | | | | | | | | |
++|集群软件| | | | | | | | | | | | | |
++|备份软件| | | | | | | | | | | | | |
++|系统管理软件| | | | | | | | | | | | | |
++|(% rowspan="3" %)配套设施|UPS| | | | | | | | | | | | | |
++|空调| | | | | | | | | | | | | |
++|其它| | | | | | | | | | | | | |
++|(% rowspan="5" %)应用软件|进程| | | | | | | | | | | | | |
++|数据| | | | | | | | | | | | | |
++|参数| | | | | | | | | | | | | |
++|代码| | | | | | | | | | | | | |
++|接口| | | | | | | | | | | | | |
++
++指标说明：
++
++|**序号**|**指标名称**|**指标计算说明**
++|1|问题总数|(((
++数量：在问题单中根据以下条件过滤
++
++1.【重复问题标记】为空
++
++2.【问题结束代码】不等于‘取消’
++
++3.【登记时间】在统计周期内
++)))
++|2|事件升级|数量：在问题总数中，【问题来源】＝‘事件升级‘的问题个数
++|3|维护中提出|数量：在问题总数中，【问题来源】＝‘维护中提出‘的问题个数
++|4|趋势分析|数量：在问题总数中，【问题来源】＝‘趋势分析‘的问题个数
++|5|已登记|数量：在问题总数中，【问题状态】＝‘已登记‘的问题个数
++|6|分析中|数量：在问题总数中，【问题状态】＝‘分析中‘的问题个数
++|7|已定位原因|数量：在问题总数中，【问题状态】＝‘已定位原因‘的问题个数
++|8|已有解决方案|数量：在问题总数中，【问题状态】＝‘已有解决方案‘的问题个数
++|9|已提出变更请求|数量：在问题总数中，【问题状态】＝‘已提出变更请求‘的问题个数
++|10|已回顾|数量：在问题总数中，【问题状态】＝‘已回顾‘的问题个数
++|11|结束并关闭|数量：在问题总数中，【问题状态】＝‘结束并关闭‘问题个数
++|12|关键|数量：在问题总数中，【问题优先级】＝‘关键‘的问题个数
++|13|重要|数量：在问题总数中，【问题优先级】＝‘重要‘的问题个数
++|14|普通|数量：在问题总数中，【问题优先级】＝‘普通‘的问题个数
++
++
++2.14.3 **按照业务系统的关闭问题的统计报表**
++
++|(% rowspan="2" %)**业务系统**|(% rowspan="2" %)**关闭问题数量**|(% colspan="4" %)**结束代码**|(% colspan="3" %)**平均诊断时间**
++|**根本解决**|**变通方法**|**无法解决**|**取消**|**关键**|**重要**|**普通**
++|BOSS系统| | | | | | | |
++|客服系统| | | | | | | |
++|经营分析| | | | | | | |
++|容灾系统| | | | | | | |
++|BOSS网管| | | | | | | |
++
++指标说明：
++
++|**序号**|**指标名称**|**指标计算说明**
++|1|关闭问题数量|数量：【问题关闭时间】在统计周期内，【问题状态】=‘结束并关闭’的问题个数
++|2|根本解决|数量：在关闭问题数量中，【问题结束代码】＝‘根本解决‘的问题个数
++|3|变通方法|数量：在关闭问题数量中，【问题结束代码】＝‘变通方法‘的问题个数
++|4|无法解决|数量：在关闭问题数量中，【问题结束代码】＝‘无法解决‘的问题个数
++|5|取消|数量：在关闭问题数量中，【问题结束代码】＝‘取消‘的问题个数
++|6|平均诊断时间（优先级为关键）|(((
++诊断完成问题数量：【实际诊断结束时间】在统计周期内，                                   【问题优先级】＝‘关键‘ 的问题个数
++
++平均诊断时间：累加诊断完成问题的（【实际诊断结束时间】－【实际诊断开始时间】）/ 诊断完成问题数量
++)))
++|7|平均诊断时间（优先级为重要）|(((
++诊断完成问题数量：【实际诊断结束时间】在统计周期内，                                   【问题优先级】＝‘重要‘ 的问题个数
++
++平均诊断时间：累加诊断完成问题的（【实际诊断结束时间】－【实际诊断开始时间】）/ 诊断完成问题数量
++)))
++|8|平均诊断时间（优先级为普通）|(((
++诊断完成问题数量：【实际诊断结束时间】在统计周期内，                                   【问题优先级】＝‘普通‘ 的问题个数
++
++平均诊断时间：累加诊断完成问题的（【实际诊断结束时间】－【实际诊断开始时间】）/ 诊断完成问题数量
++)))
++
++
++2.14.4 **按照分类的已关闭的问题统计报表**
++
++|(% rowspan="2" %)**类别**|(% rowspan="2" %)**子类**|(% rowspan="2" %)**关闭问题数量**|(% colspan="4" %)**结束代码**|(% colspan="3" %)**平均诊断时间**
++|**根本解决**|**变通方法**|**无法解决**|**取消**|**关键**|**重要**|**普通**
++|(% rowspan="9" %)系统硬件|路由器| | | | | | | |
++|网络交换机| | | | | | | |
++|小型机| | | | | | | |
++|PC服务器| | | | | | | |
++|磁盘阵列| | | | | | | |
++|存储光纤交换机| | | | | | | |
++|磁带库| | | | | | | |
++|光盘库| | | | | | | |
++|其它| | | | | | | |
++|(% rowspan="4" %)客服设备|排队机| | | | | | | |
++|CTI服务器| | | | | | | |
++|CCS| | | | | | | |
++|IVR服务器| | | | | | | |
++|(% rowspan="5" %)安全设施|防火墙| | | | | | | |
++|IDS入侵监测系统| | | | | | | |
++|IPS入侵防护系统| | | | | | | |
++|防毒墙| | | | | | | |
++|安全软件| | | | | | | |
++|(% rowspan="6" %)系统软件|操作系统| | | | | | | |
++|数据库| | | | | | | |
++|中间件| | | | | | | |
++|集群软件| | | | | | | |
++|备份软件| | | | | | | |
++|系统管理软件| | | | | | | |
++|(% rowspan="3" %)配套设施|UPS| | | | | | | |
++|空调| | | | | | | |
++|其它| | | | | | | |
++|(% rowspan="5" %)应用软件|进程| | | | | | | |
++|数据| | | | | | | |
++|参数| | | | | | | |
++|代码| | | | | | | |
++|接口| | | | | | | |
++
++指标说明：
++
++|**序号**|**指标名称**|**指标计算说明**
++|1|关闭问题数量|数量：【问题关闭时间】在统计周期内，【问题状态】=‘结束并关闭’的问题个数
++|2|根本解决|数量：在关闭问题数量中，【问题结束代码】＝‘根本解决‘的问题个数
++|3|变通方法|数量：在关闭问题数量中，【问题结束代码】＝‘变通方法‘的问题个数
++|4|无法解决|数量：在关闭问题数量中，【问题结束代码】＝‘无法解决‘的问题个数
++|5|取消|数量：在关闭问题数量中，【问题结束代码】＝‘取消‘的问题个数
++|6|平均诊断时间（优先级为关键）|(((
++诊断完成问题数量：【实际诊断结束时间】在统计周期内，                                   【问题优先级】＝‘关键‘ 的问题个数
++
++平均诊断时间：累加诊断完成问题的（【实际诊断结束时间】－【实际诊断开始时间】）/ 诊断完成问题数量
++)))
++|7|平均诊断时间（优先级为重要）|(((
++诊断完成问题数量：【实际诊断结束时间】在统计周期内，                                   【问题优先级】＝‘重要‘ 的问题个数
++
++平均诊断时间：累加诊断完成问题的（【实际诊断结束时间】－【实际诊断开始时间】）/ 诊断完成问题数量
++)))
++|8|平均诊断时间（优先级为普通）|(((
++诊断完成问题数量：【实际诊断结束时间】在统计周期内，                                   【问题优先级】＝‘普通‘ 的问题个数
++
++平均诊断时间：累加诊断完成问题的（【实际诊断结束时间】－【实际诊断开始时间】）/ 诊断完成问题数量
++)))
++
++
++

粤ICP备17056641号

深圳市艾拓先锋企业管理咨询有限公司