# 22 某省通信公司挑战365ITIL问题管理流程实施细则

Last modified by superadmin on 2024/10/15, 16:43
Export
Office Formats
Export as PDF Export as ODT Export as RTF
Other Formats

Select the pages to export:

select all/ none

Legend:
  Created Page
  Modified Extension Page
  Clean Extension Page

Export as HTML

返回本章节索引 阅读下一章

文档资料信息

服务名称： | 某省通信公司挑战365服务
项目经理： | 杨XX | 文档版本号： | 2.0
服务阶段： | 流程优化 | 文档版本日期： |
准备者： | 单XX | 准备日期： |
审定者： |  | 审定日期： |

发送列表

发送者： | 日期： | 电话/传真：

接受者： | 目的： | 日期： | 电话/传真：
某省通信公司 | 审阅 |  |

版本历史

# 1.问题管理流程概要设计

## 1.1.流程目的

当事件管理需进行进一步分析，找出故障深层原因和根本解决方案，通过变更请求(RFC)、变通方法或建议的预防性措施来防止同类故障的再次发生时，应启动问题管理流程。

问题管理流程的根本目的是消除或减少C365生产环境中事件发生的数量和严重程度，从而为企业建立一个稳定的IT环境，提高IT服务的可用性。

其目的包括：

1. 分析并确定事件的根本原因，找到最终解决方案，以防止此类事件再次发生
2. 提高IT服务的可靠性，降低IT支持成本

##

## 1.2.流程主要内容

问题管理流程着重于消除事件或减少事件发生，确定事件的根本原因。主要活动包括分析事件、找出问题、分派问题、确定根本原因以及找出解决方案、回顾及关闭，以消除事件或在其发生时降低对用户或业务的影响。其主要内容如下：

- 分析事件

定期分析事件，找出潜在问题。

- 生成问题记录

在系统中生成问题记录并把所有相关事件与此记录关联起来。

- 紧急事件处理完后定义为问题
- 运维人员在日常维护中发现的问题
- 事件历史记录趋势分析发现的问题

- 分派

根据问题分类将问题记录分派给相应的问题处理人员。

- 根本原因分析

被分派的问题处理人员应调查问题找出其原因，提出变通方法或预防性措施在重发时使其影响力最小化、以及解决方案以消除产生原因。记录必须被更新以反映它是已定位原因状态，并且把任何变通方法、避免或最小化负面影响的动作行为也记录下来。

- 开发、确认、提出实施解决方案

对问题的解决方案进行评估、测试，提出变更请求（RFC）或通过其他流程实施相应解决方案。

- 回顾

问题主管组织对问题的解决方案的实施情况进行回顾，确认已成功实施。

由问题主管组织相关人员，在问题处理人的协助下，对问题的解决方案的实施情况进行整体回顾、总结。

由问题主管确认解决方案达到预期的效果；

- 总结及关闭

由问题主管确认问题的信息记录填写完整，标识为已知错误，总结问题信息项并关闭问题记录。

##

## 1.3.与其他流程的关系

- 和事件管理的关联
  - 紧急事件将升级为问题，或根据事件的趋势分析，发现潜在的问题，同时问题的解决方案实施为事件流程提供了解决办法
- 和变更管理的关联
  - 问题处理过程中，如果需要对系统进行变更，必须按照变更管理的定义，提交变更请求单（变更单必须和问题单建立关联），变更完成后，继续问题单的处理
- 和需求管理的关联
  - 问题处理过程中，如果需要进行代码变更，则须由问题主管根据问题处理人提供的诊断结果，转需求管理流程解决，需求管理流程处理完成后，应对问题处理进行回顾、总结
- 和工程管理的关联
  - 问题处理过程中，如果需要进行代码变更，则须由问题主管根据问题处理人提供的诊断结果，转工程管理流程解决，工程管理流程处理完成后，应对问题处理进行回顾、总结
- 和配置管理的关联
  - 问题处理过程中，可以通过配置管理查询相关的配置项信息
  - 问题处理过程中，如果可以将根本原因定位到某个配置项，则必须将问题单与该配置项关联
- 和知识管理的关联
  - 问题处理完成后，均应整理提交到知识库中

##

## 1.4.流程范围

问题管理流程的范围是对C365范围的IT生产环境中发生的问题进行管理，以采取主动性预防措施来降低事件数量。

不包括：

- 处于开发或测试环境的系统和应用

##

## 1.5.流程执行原则

### 1.5.1.常规原则

- 问题管理流程应与事件管理流程相对独立，事件处理过程中故障消除、业务恢复后如需后续分析处理，应转问题管理流程
- 问题管理流程经理应每半年对问题管理流程的流程关键衡量指标、流程执行效率、流程支撑工具有效性等进行回顾，以改进和优化流程
- 问题经理应该每月组织定期回顾和产生问题管理报表，由事件经理对事件趋势进行分析。
  - 对需要解决的问题，问题经理应将问题安排给相应问题主管解决。
  - 对没有解决的问题，问题经理应该举行定期的问题管理会议对这些问题进行评估

###

### 1.5.2.所有权原则

所有权原则用来确保每个问题在任何时段都有适当的人员负责，问题主管是每个问题的负责人。有效管理问题的前提是必须确保每个问题在任何时段都有适当的人员负责。

下表是各角色在各环节中承担不同责任的RACI模型。

| 问题经理 | 问题主管 | 问题处理人
问题确定与记录 | I | A | C
问题确认与分派 | A | C | I
分析并诊断问题/提供变通方法 | I | A/I | R/C
开发、确认、实施解决方案 | I | A/I | R/C
问题监控 | I | A/I | R/C
问题回顾与关闭 | I | A/I | R/C
RACI模型说明 A: 负全责; R: 有义务; C: 提建议; I: 需知会

###

### 1.5.3.创建原则

- 紧急事件解决后，由事件经理告知相应问题主管进行问题解决
- 经问题主管确认，运维人员在运维中发现的潜在故障，尚未影响业务的，应建立问题单
- 经问题主管确认，运维人员在运维中遇到频繁发生的类似或相同的故障，应建立问题单
- 由问题经理定期组织事件分析会,工作分析会应包括对所处理事件历史记录的趋势分析。基于会议讨论、分析，须落实的潜在故障分析任务，应由问题经理指派相应问题主管建立问题单、由问题主管跟踪整个问题的处理过程。

###

### 1.5.4.退回和转派原则

问题处理人认为问题协同分派错误时，可退回问题主管，由其进行再分派(转派)。为确保问题协同单不被过于频繁的相互转派、以至于无法及时解决，应当尽量减少问题协同单再分派的几率，一个问题协同单再分派的次数不应该超过两次。问题协同单再分派必须经过问题主管。

###

### 1.5.5.重复问题原则

重复问题是指经过分析之后，根本原因相同的问题。例如：经问题主管确认，运维人员提出了几个问题，但是经过分析之后，发现这几个问题的根本原因是相同的，这几个问题就可以定义为重复问题。对于重复问题需要进行标志，将相关问题记录进行关联，当问题解决时同时进行回顾。

###

### 1.5.6.问题关闭原则

通常问题单在实施了解决方案之后，需要经过一段时间回顾，由问题主管负责组织、问题处理人参与回顾解决方案是否达到了预期的效果，如果成功的实施，由问题主管确认问题已回顾，和问题信息记录完整，关闭问题。

问题关闭时须确认为“已知错误” ,并须整理经验，提交已知错误库。

###

### 1.5.7.问题单重开原则

已关闭的问题单不允许重开。如果问题重复发生，则创建一个新的问题单。

###

### 1.5.8.问题升级原则

制定升级原则的目的是，在规定的诊断时限内无法诊断问题时，及时通知相关领导，引起更多的重视，提供合适的资源，从而快速找到解决问题的方案。

1. 各问题处理人员应及时响应和处理分配到自己的问题协同单;
2. 问题主管主动监督问题协同处理情况，应及时将无法诊断的问题和超时诊断的问题升级到问题经理；问题经理负责协调资源，如依然无法解决问题，应将问题上报领导，并同时督促问题协同及时被处理。

###

### 1.5.9.趋势分析原则

问题经理每月组织会议，对所处理事件历史记录进行趋势分析：

- 参加者应包括事件经理及问题处理人
- 会议定期组织

##

## 1.6.流程相关定义

### 1.6.1.问题信息项

问题单包含如下信息项：

序号 | 信息项 | 描述
1 | 问题ID | 为每个问题分配一个唯一的序列号（系统自动产生）
2 | 请求人信息 | 问题请求人的信息，包括：姓名、省/分公司、部门、电子邮件、办公电话、手机（手工填写）
3 | 登记时间 | 生成问题记录的时间（系统自动产生）
4 | 完成时间 | 问题解决完成时间(收到处理结果的时间)
5 | 关闭时间 | 问题确认关闭的时间
6 | 地点 | 记录问题发生的地点（手工填写）
7 | 问题标题 | 简单描述问题（手工填写）
8 | 问题描述 | 问题主管详细描述问题内容（手工填写）
9 | 问题来源 | 参见“问题来源”定义
10 | 影响系统 | 服务开通、综合采集、一级BOSS、采集预处理、融合计费、产品管理、融合控制、综合帐务、综合结算、合作伙伴管理、基础功能、统计报表、局数据管理与发布、信息管理、客户服务、电子渠道、市场营销、销售管理、渠道管理、客户管理、资源管理、产品管理、系统管理、服务管理、监控管理、经分（下拉菜单供选择）
11 | 影响范围 | 全省、全省多个地市 (6~11个)、少数地市(1~5个)。（下拉菜单供选择）
12 | 问题优先级 | 参见“问题优先级”定义 ，备注：通过"影响系统"、与“影响范围”的手工选择，系统自动匹配优先级别。
13 | 所属系统类型 | 参见“所属系统类型”定义
14 | 问题分类 | 参见“问题分类”定义
15 | 问题状态 | 参见“问题状态”定义
16 | 问题主管 | 该问题对应的问题主管 (展示)
17 | 问题处理人 | 负责该问题的问题处理人 (手工选择)
18 | 问题经理 | (系统自动生成)
19 | 审核结果 | 同意或驳回(下拉选项)
20 | 审核意见 | 填写审核意见(问题经理手工填写)
21 | 建议解决方案 | 提供初步解决建议及初步方案 （手工填写）
22 | 问题原因 | 综合描述问题产生的根本原因（问题主管手工填写）
23 | 重复问题标记 | 标记为重复问题，用已有标题号标注（问题主管手工填写）
24 | 变通方法及解决方案 | 问题变通方法及解决方案的详细描述（问题主管整合各协同单提供的解决方案进行填写）
25 | 解决流程 | 变更管理流程/需求管理流程/工程管理流程（下拉选项）
26 | 处理结果 | 通过接口同步，得出处理结果
27 | 方案附件 | 由需求管理平台等接口同步
28 | 处理描述 | 问题主管描述转解决流程单号、处理人、处理结果等处理信息
29 | 是否由紧急事件升级 | “是”或“否”，在问题创建时，根据关联的事件手工填写
30 | 关联的事件单号 | 记录引发该问题的事件单号（手工填写）
31 | 关联的变更单号 | 问题单转派的变更单号（系统自动生成）
32 | 关联的需求单号 | 问题单转派的需求单号（系统自动生成）
33 | 关联配置项 | 记录问题的配置项代码（手工填写）
34 | 是否已知错误 | 是/否 (问题主管选择)
35 | 问题总结 | 对问题处理过程进行总结(问题主管填写)

协同单包含如下信息项：

序号 | 信息项 | 描述
1 | 协同单ID | 为每个协同单分配一个唯一的序列号（系统自动产生）
2 | 协同单标题 | 简单描述协同单（系统自动产生）
3 | 登记时间 | 生成协同单记录的时间（系统自动产生）
4 | 完成时间 | 协同处理完成的时间
5 | 协同关闭时间 | 确认协同单关闭的时间
6 | 诊断时限 | 相应问题优先级的问题协同诊断时限，参见“诊断时限”定义
7 | 问题主管 | 该问题的问题主管
8 | 问题处理人 | 负责该问题的问题处理人
9 | 问题来源 | 参见“问题来源”定义
10 | 问题优先级 | 参见“问题优先级”定义
11 | 所属系统类型 | 参见“所属系统类型”定义
12 | 问题分类 | 参见“问题分类”定义
13 | 问题描述 | 问题主管详细描述问题内容
14 | 协同状态 | 参见“协同状态”定义
15 | 建议解决方案 | 问题主管提供的初步建议解决方案
16 | 问题原因 | 详细描述问题产生的根本原因（问题处理人手工填写）
17 | 解决方案 | 问题变通方法及最终解决方案的详细描述（问题处理人手工填写）
18 | 是否已超时 | 是或否(系统自动判断协同是否已经超过诊断时限)
19 | 满意度 | 满意\一般\不满意(下拉菜单)

###

### 1.6.2.问题来源

根据问题的不同来源对问题分类如下：

编号 | 代码 | 描述
1 | 事件研究 | 紧急事件恢复服务后提出的问题，以便进行紧急事件的根本原因分析。 例如：某日发生了一起集群无法切换的事件，导致某台主机发生故障后，没有切换到备用主机中去，从而影响了业务，紧急事件的处理人员在采取了手工切换的替代措施后，恢复了服务。 为了分析为什么会发生该紧急事件，以及查看其他的集群是否也存在类似的问题，此时可以提出一个问题记录，以便对该紧急事件进行分析。
2 | 维护中提出 | 运维人员在日常维护工作中提出的问题。 例如：维护人员在日常维护中发现，目前的数据库版本可能会存在着死锁、心跳不一致等方面的问题，此时就可以提出一个问题记录，以便分析。
3 | 趋势分析 | 分析事件记录找出的问题。 例如：在定期的会议中，对计费类的事件进行分析后发现，上周该类型的事件比平常的时候多了30％，超过了规定的阀值，这表明计费系统有可能存在着一些潜在的隐患，此时就可以提出一个问题记录，以找出问题的原因并解决。

###

### 1.6.3.问题优先级

问题的优先级是问题处理人解决问题的参照标准，对于关键优先级的问题，管理层应该优先协调资源进行这些问题的解决。结合中国移动的实际情况，问题的优先级定义如下：

编号 | 代码 | 描述
1 | 关键 | 紧急事件升级来的问题； 运维分析会得出的问题和运维人员提出的问题从如下方面考虑，问题发生是否会导致： BOSS系统中客户服务、客户管理、服务开通、综合帐务任一业务不可用，影响面为全省或至少包括一个关键地市 客服系统的电话呼叫中心业务不可用，影响面为全省或至少包括一个关键地市 电子渠道（如，网厅、短厅）业务不可能用，影响面为全省或至少包括一个关键地市 因系统原因数据处理错误，导致大量用户投诉 来自新闻媒体、消费者协会、国家行政机关（工商、物价等）的反映或申告 部分重要数据丢失，且无法全部恢复
2 | 重要 | 运维分析会得出的问题和运维人员提出的问题从如下方面考虑，问题发生是否会导致： BOSS系统中客户服务、客户管理、服务开通、综合帐务任一业务不可用，影响面为一个或多个非关键地市 BOSS系统中综合采集、融合计费、产品管理、资源管理、一级BOSS、营销管理、渠道管理、合作伙伴管理、综合结算、系统管理、统计报表任一业务不可用，影响面为全省或至少包括一个关键地市 客服系统的电话呼叫中心业务不可用，影响面为一个或多个非关键地市 客服系统中互联网呼叫中心、短信呼叫中心、工单管理、知识管理、人力资源、质量管理、数据统计分析任一业务不可用，影响面为全省或至少包括一个关键地市 电渠的业务受理不可用，影响面为一个或多个非关键地市 经分系统的通用分析不可用，影响面为全省 BOMC系统的服务管理或监控管理不可用，影响面为全省 用户在营业现场反应激烈
3 | 普通 | 运维分析会得出的问题和运维人员提出的问题从如下方面考虑，问题发生是否会导致： 一般性系统故障

问题的优先级设计依据事件的影响范围、业务系统的关键程度、和事件发生的频率。

由问题主管在优先级映射表中定位优先级。问题处理人不能修改优先级。

影响范围 系统 | 全省 | 全省多个地市 (6~11个) | 少数地市(1~5个)
BOSS（任意一个模块） | 服务开通、综合采集、一级BOSS、采集预处理、融合计费 | 关键 | 重要 | 重要
产品管理、融合控制、综合帐务、综合结算、合作伙伴管理、基础功能、统计报表、局数据管理与发布、信息管理、其他 | 重要 | 普通 | 普通
CRM（任意一个模块） | 客户服务 | 关键 | 重要 | 重要
电子渠道 | 关键 | 重要 | 重要
市场营销、销售管理、渠道管理、客户管理、资源管理、产品管理、系统管理、其他 | 重要 | 普通 | 普通
经分 |  | 重要 | 重要 | 普通
BOMC | 服务管理、监控管理 | 重要 | 普通 | 普通

###

### 1.6.4.问题状态

为了记录问题处理的生命周期，需要设置不同的状态加以描述，如下所示：

问题状态
编号 | 代码 | 描述
1 | 已登记 | 问题已登录到系统中
2 | 待审核 | 已经登录问题,但是尚未得到问题经理审核
3 | 已审核 | 问题经理已审核\确认问题
4 | 分析中 | 问题主管已经发协同单给问题处理人,问题处理人正在分析问题过程中
5 | 已有解决方案 | 问题主管收到问题处理人的解决方案反馈
6 | 已解决 | 问题主管收到需求管理\变更管理\工程管理流程等的反馈,得知问题已经得到解决
7 | 回顾与关闭 | 问题主管已经组织对问题进行了回顾，关闭问题，问题结束

为了记录问题处理的生命周期，也需要设置协同单不同的状态加以描述，如下所示：

协同状态
编号 | 代码 | 描述
1 | 已登记 | 协同已登录到系统中
2 | 待分析 | 已派发至问题处理人，但问题处理人尚未开始分析
3 | 分析中 | 问题处理人正在分析问题过程中
4 | 已分析 | 协同部分的变通方法与解决方案已找到
5 | 已关闭 | 将协同单关闭

###

### 1.6.5.所属系统类型

业务系统 | 子类
BOSS系统 | 产品管理
服务开通
综合采集
融合控制
融合计费
综合帐务
综合结算
合作伙伴管理
基础功能
统计报表
一级BOSS
局数据管理与发布
信息管理
采集预处理
其他
CRM系统 | 市场营销
销售管理
渠道管理
客户服务
客户管理
资源管理
产品管理
系统管理
其他
经分系统 |
BOMC | 服务管理
监控管理
其他系统 |

###

### 1.6.6.问题分类

问题类别 | 问题子类
需求类问题 | 计费帐务类 |
营业维护类 | 个人
集团
客服维护类 |
电子渠道维护类 | 短信
网厅
自助
集团
市场
经分维护类 | 数据集市应用和接口
市场部门应用
集团客户应用
客服
数据
网管
计划
接口维护类 |
工程类问题 | 全网工程类 |
软件系统架构调整 |
硬件系统架构调整 |
性能与容量 |
其他 |
运维类问题 | 主机类 |
网络类 |
中间件类 |
物理环境类 |
数据库类 |

###

### 1.6.7.问题结束代码

为了表明问题的不同解决方式，定义如下结束代码：

编号 | 代码 | 描述
1 | 根本解决 | 找出问题的根本原因，并得到解决方案，成功解决
2 | 变通方法 | 没有根本解决方案或目前没有办法实施根本解决方案，但有临时解决方案作为变通方法
3 | 取消 | 问题被问题经理拒绝

##

## 1.7.问题管理流程设计

问题管理设计流程图如下：

图.1.1 问题管理流程

问题管理概要流程描述如下：

下表以问题管理概要图中的关键流程活动为主线，与问题管理概要设计中的其它重要内容进行了关联，以帮助业务支撑维护部门更好地理解流程设计内容。

序号 | 步骤名称 | 责任人 | 流程环节说明
300.1 | 问题确定与记录 | 问题主管 | 运维人员在运维中发现重复事件发生或者认为有潜在隐患的问题，应向问题主管汇报、并提供问题描述、问题类别及初步建议解决方案等信息,问题主管对来自运维人员提出的问题进行初步判断，如确是问题,那么应在系统中对问题进行记录，选择问题处理人员,对问题信息进行描述,并提出建议解决方案
问题经理对通过事件趋势分析发现的潜在问题，通知相应问题类别的问题主管,由问题主管在系统中对问题进行记录，在问题提出者的协助下,对问题信息进行描述,并提出建议解决方案
在紧急事件处理完成后(无论是否根本解决)，都由事件经理将紧急事件的处理情况、事件信息通知相应问题类别的问题主管,由问题主管在系统中对问题进行记录，对问题信息进行描述,并提出建议解决方案
300.2 | 问题审核 | 问题经理 | 问题经理审核问题(如果问题经理认为分派不合理,则可进行调整分派对象),审核后回给问题主管。
300.3 | 分析并诊断问题 | 问题主管/问题处理人 | 问题主管登记协同单,并派发相应问题处理人,问题处理人接受问题协同单，并展开问题原因分析,问题处理人将问题产生根本原因与变通方法、解决方案及时更新到协同单记录中，并反馈给问题主管，问题主管确认协同完成，并关闭协同单。
如需其他问题处理人协助分析、诊断，则通知问题主管，由问题主管负责协调资源，成立问题分析小组，举行问题根本原因分析研讨会议，并确定问题的潜在原因，提供或更新问题变通方法，以降低问题在根本解决前对业务产生的影响。
300.4 | 问题监控 | 问题主管 | 在问题分析和解决过程中，由问题主管与问题处理人保持沟通，监控问题解决的进展情况、及时更新问题状态并按需汇报。
在问题找到根本原因和解决方案之后，根据需要，向帮助台或问题发起人通报该问题的解决情况，以帮助和提高事件的解决率。
300.5 | 开发、确认、实施解决方案 | 问题主管/问题处理人 | 问题主管整合问题处理人提交的解决方案，根据问题类型转其他解决流程（如需求管理等）解决问题。
由问题处理人负责落实解决方案以最终解决问题。
如果需要第三方介入，则问题主管负责与第三方的接口与协调。
300.6 | 问题回顾与总结 | 问题主管 | 当问题解决后，由问题主管组织，问题处理人协助对问题方案的实施情况进行整体回顾。
如果经回顾问题已经得到解决，那么问题主管总结问题处理经验，并对问题记录的信息项进行总结，更新问题记录并关闭问题。
将问题标识为“已知错误”，启动知识单走知识管理流程进行知识积累。
如果经问题主管回顾问题没有解决，则予以驳回。

##

## 1.8.问题处理流程设计

问题管理设计流程图如下：

图.1.2 问题处理流程

下表以问题处理流程图中的关键流程活动为主线，描述了问题处理过程中,用协同单的方式实现处理中的流程流转方式，以帮助业务支撑维护部门更好地理解流程设计内容。

步骤名称 | 责任人 | 流程环节说明
登记协同单 | 问题主管 | 问题主管将需要分析的问题信息整理，登记协同单并派发给相应问题处理人
问题原因分析 | 问题处理人 | 问题处理人根据派发过来的协同单对问题原因进行诊断
得出根本原因与变通方法、解决方案 | 问题处理人 | 问题处理人在诊断得出问题原因、变通方法（临时解决方法）、及解决方案，并通过协同单回馈上报给问题主管
确认问题方案 | 问题主管 | 问题主管确认问题方案可行，如果认为方案不可行，则将协同单驳回给问题处理人做继续处理
关闭协同单 | 问题主管 | 问题主管在确认问题方案可行后，关闭协同单
更新问题单 | 问题主管 | 问题主管将协同单中得出的根本原因与变通方法、解决方案等信息更新录入问题单中，作为问题跟踪的记录基础
转其他流程解决 | 问题主管 | 问题主管根据协同得出的解决方案要求，转需求管理、工程管理其他流程予以解决问题
其他流程根据问题单提供的信息进行问题处理 | 问题处理人 | 问题处理人执行需求管理、工程管理等流程以解决问题，在解决之后给与问题主观问题处理的结果反馈
确认问题解决 | 问题主管 | 问题主管对问题处理反馈结果进行确认，如果认为依然没有解决，则予以驳回
问题回顾与总结 | 问题主管 | 当问题主管确认问题解决后，由问题主管组织，问题处理人协助对问题方案的实施情况进行整体回顾。
如果经回顾问题已经得到解决，那么问题主管总结问题处理经验，并对问题记录的信息项进行总结，更新问题记录并关闭问题。
将问题标识为“已知错误”，启动知识单走知识管理流程进行知识积累。
如果经问题主管回顾问题没有解决，则予以驳回。

##

## 1.9.关键角色、职责定义

### 1.9.1.流程经理

问题管理流程经理从总体上对问题管理流程的设计、实施、执行及优化负责，确保问题管理流程在业务支撑中心范围内被正确的执行。当流程不能够适应业务支撑中心的情况时，流程负责人必须及时的对此进行分析、找出缺陷、进行改进，从而实现可持续提高。

职责:

1. 确保问题管理流程的设计、实施及执行，能够取得管理层的参与和支持
2. 确保问题管理流程符合公司实际状况和公司 IT发展战略
3. 整体上对问题管理流程负责，建立流程实施、评估和持续优化机制
4. 确保问题管理流程的有效执行，定期评估流程，制定流程改进计划
5. 保持与其他流程负责人的定期沟通

###

### 1.9.2.问题经理

问题经理负责协调日常的问题管理工作，包括对问题所需资源的协调、定期组织事件分析会、必要的时候对问题进行审核和协调分派等。

职责：

1. 定期组织相关人员对事件记录进行分析，发掘潜在问题
2. 确认和审核问题
3. 必要时对问题进行上报
4. 必要时协调所需资源

###

### 1.9.3.问题主管

问题主管负责日常问题处理过程中的管控工作。

职责：

1. 监控问题的诊断、分析和处理过程
2. 必要时与帮助台及问题请求者沟通问题的相关信息
3. 问题回顾

###

### 1.9.4.问题处理人

问题处理人负责问题为问题诊断及解决提供技术支持。

职责：

1. 接受问题主管分派过来的问题
2. 分析和诊断问题，确定根本原因
3. 确定和测试解决方案
4. 协助事件一线人员进行重大或紧急事件、以及大量反复发生（当天发生大于等于50件）的事件的处理
5. 实施解决方案,需要时协调第三方的资源来帮助诊断和改正问题

###

### 1.9.5.流程角色和人员对应表

1. 问题经理由系统运维室专人统一负责；
2. 问题主管由系统运维室各专业小组长担任，对问题处理过程进行监督；
3. 问题处理人由各室专业技术人员分别担任，问题处理人负责对问题分析、诊断、方案制定和解决；
4. 问题处理人的处理过程和结果由问题主管在问题管理平台上进行整理、总结并记录。

问题管理流程角色表
流程经理 |
问题经理 |
问题类别 | 问题子类 | 问题主管部门 | 问题主管 | 问题处理部门 | 问题处理人
需求类问题 | 计费帐务类 |  |  |  |  |
营业类 | 个人 |  |  |  |
集团 |  |  |  |
客服类 |  |  |  |  |
电子渠道类 | 短信 |  |  |  |
网厅 |  |  |  |
自助 |  |  |  |
集团 |  |  |  |
市场 |  |  |  |
经分类 | 数据集市应用和接口 |  |  |  |
市场部门应用 |  |  |  |
集团客户应用 |  |  |  |
客服 |  |  |  |
数据 |  |  |  |
网管 |  |  |  |
计划 |  |  |  |
接口类 |  |  |  |  |
运维类问题 | 主机类 |  |  |  |  |
网络类 |  |  |  |  |
中间件类 |  |  |  |  |
物理环境类 |  |  |  |  |
数据库类 |  |  |  |  |
安全系统类 |  |  |  |  |
工程类问题 | 全网工程类 |  |  |  |  |
软件系统架构调整 |  |  |  |  |
硬件系统架构调整 |  |  |  |  |
性能与容量 |  |  |  |  |
其他 |  |  |  |  |  |

##

## 1.10.流程衡量指标

问题管理流程的关键衡量指标如下：

序号 | 衡量指标 | 指标计算说明
1 | 统计周期内 新增问题总数 | 数量：在问题单中根据以下条件过滤，
1.【问题结束代码】不等于‘取消’
2.【登记时间】在统计周期内
2 | 统计周期内 新增协同总数 | 数量：在协同单中根据以下条件过滤，
1.【登记时间】在统计周期内
3 | 统计周期内关闭问题数量 | 数量：在问题单中根据以下条件过滤，
1.【问题关闭时间】在统计周期内，
2.【问题状态】=‘结束并关闭’的问题个数
4 | 统计周期内关闭协同数量 | 数量：在协同单中根据以下条件过滤，
1.【协同关闭时间】在统计周期内，
2.【已关闭】在统计周期内，

## 1.11.问题管理报表

### 1.11.1.新增问题统计报表

类别 | 子类 | 新增问题总数
需求类 | 计费帐务类 |
营业类 |
客服类 |
电子渠道类 |
经分类 |
接口类 |
工程类 | 全网工程类 |
软件系统架构调整 |
硬件系统架构调整 |
性能与容量 |
运维类 | 主机类 |
网络类 |
中间件类 |
物理环境类 |
数据库类 |
其他类 |  |

序号 | 指标名称 | 指标计算说明
1 | 统计周期内 新增问题总数 | 数量：在问题单中根据以下条件过滤
1.【问题结束代码】不等于‘取消’
2.【登记时间】在统计周期内

###

### 1.11.2.未关闭协同统计报表

类别 | 子类 | 未关闭协同总数 | 各部门未关闭协同数量
电渠室 | 经分室 | 规划室
需求类 | 计费帐务类 |  |  |  |
营业类 |  |  |  |
客服类 |  |  |  |
电子渠道类 |  |  |  |
经分类 |  |  |  |
接口类 |  |  |  |
工程类 | 全网工程类 |  |  |  |
软件系统架构调整 |  |  |  |
硬件系统架构调整 |  |  |  |
性能与容量 |  |  |  |
运维类 | 主机类 |  |  |  |
网络类 |  |  |  |
中间件类 |  |  |  |
物理环境类 |  |  |  |
数据库类 |  |  |  |
其他类 |  |  |  |  |

序号 | 指标名称 | 指标计算说明
1 | 未关闭协同数量 | 数量：在协同单中根据以下条件过滤， 状态不等于“已关闭”的累计协同单总数

###

### 1.11.3.超诊断时限协同统计报表

类别 | 子类 | 超诊断时限协同总数 | 各部门超时协同数量
电渠室 | 经分室 | 规划室
需求类 | 计费帐务类 |  |  |  |
营业类 |  |  |  |
客服类 |  |  |  |
电子渠道类 |  |  |  |
经分类 |  |  |  |
接口类 |  |  |  |
工程类 | 全网工程类 |  |  |  |
软件系统架构调整 |  |  |  |
硬件系统架构调整 |  |  |  |
性能与容量 |  |  |  |
运维类 | 主机类 |  |  |  |
网络类 |  |  |  |
中间件类 |  |  |  |
物理环境类 |  |  |  |
数据库类 |  |  |  |
其他类 |  |  |  |  |

序号 | 指标名称 | 指标计算说明
1 | 超时协同数量 | 数量：在问题单中根据以下条件过滤
1.【登记时间】在统计周期内
2. 包含未关闭的处理中的以及已经关闭的超过诊断时限的协同数量

Tags:
Created by superadmin on 2024/10/13, 16:26

- Comments (0)
- Annotations (0)
- Attachments (3)
- History
- Information

粤ICP备17056641号
深圳市艾拓先锋企业管理咨询有限公司