# 07 某银行ITIL问题管理流程设计方案

Last modified by superadmin on 2024/10/01, 10: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

1. 综述
   1. 文档介绍

本文档《问题管理流程设计》, 是XX银行系统运行部（以下简称系统运行部）一起制定的问题管理的流程文档。通过制定该流程，可以帮助系统运行部的IT运维能够有效降低或消除相应突发事件发生的次数和影响程度，提高IT系统的稳定性和服务的质量，向业务人员和相关用户提供更优质的IT服务，并且可以有效地帮助系统运行部的IT运行管理从被动管理转向主动管理。

本文档的内容是根据系统运行部目前的IT服务状况而制定的问题管理流程，进一步的流程更新将有系统运行部流程负责人负责。

1. 1. 适用范围

本文档是系统运行部实施问题管理流程的蓝本和指导思想，目标读者是与问题管理流程相关的所有技术与管理人员。

本文档所描述的流程在IT服务管理中有许多重要的用途作用，比如：

1. 找出事件的根本原因，从而防止同类事件的再次发生
2. 确保进行问题根源的分析
3. 确保问题被赋予正确的优先级
4. 确保问题有责任人负责
5. 改进IT部门的服务可用性
6. 降低支持成本
7. 确保问题没有进一步恶化
8. 提高客户的满意度
9. 改进问题预防流程
   1. 相关术语

1. ITIL（IT Infrastructure Library ）
2. 服务台（Service Desk）

服务台从根本上来说是提供了用户和IT部门的唯一接口。此项功能常通过集中方式提供服务。服务台的根本目的是提供初始支持，并通过变通方法、解决方案或升级到一线、二线支持等手段帮助用户恢复到正常工作状态。

1. 事件管理（ Incident Management）

ITIL流程之一，事件管理负责解决所有的IT事件、问题和用户请求。它的目的是尽快恢复被中断或受到影响的IT服务，所以它的特点往往是以解决表征现象为目的，而不在于查找根本原因。

1. 问题管理（Problem Management）

ITIL流程之一，问题管理负责解决重大紧急事件或具有相同症状的一组事件。它的目的是找出事件的根本原因，并通过解除该根本原因从而防止类似事件的再次发生。同时问题管理流程也负责预防事件的发生。

1. 配置管理（Configuration Management）

ITIL 流程之一，配置管理负责描述，跟踪和汇报所有IT基础架构中的每一个设备或系统的管理流程。这些设备和系统被称为配置项(CI) 。每一个CI必须有效管理，跟踪和控制以支持公司的IT服务和基础设施成功运行。

1. 配置管理数据库（CMDB - Configuration Management Database）

是在配置管理流程中用于记录企业所有IT相关配置项信息及其相互关系而建立的数据库。

1. 变更管理（Change Management）

ITIL流程之一， 通过控制和管理IT相关的变更， 使变更对生产环境可能的影响和风险将到最小，从而提高IT环境的整体稳定性。

1. 知识管理

知识管理是指通过对企业知识资源的开发和有效利用，以提高企业运维能力，从而提高企业创造价值能力的管理活动，是一个不断积累，共享，利用和再创新的过程 。

1. 问题管理流程设计
   1. 流程目的

问题管理流程的根本目的是消除或减少生产环境中事件发生的数量和严重程度，从而为企业建立一个稳定的IT环境，提高IT服务的可用性。此流程对发生在系统运行部所管理的运行环境中的问题进行管理，找出产生这些问题的根本原因，然后根据需要通过变更请求(RFC)、变通方法或建议的预防性措施来防止事件的再次发生。问题管理流程常常需要和变更管理流程一起来实施找出的解决方案，以便从根本上解决问题。其目的包括：

1. 分析并确定事件的根本原因，找到最终解决方案，以防止此类事件再次发生
2. 确保问题分派了正确支持人员，提高解决率
3. 根据问题优先级合理分派IT资源
4. 对事件记录做趋势性分析，主动提供预防性措施
5. 提高IT服务的可靠性
6. 降低IT支持成本
7. 规范同类问题的标准化处理
8. 明确人员职责，确保问题管理的有效执行
9. 规范各功能小组提交性能、容量、风险等周期性报告的格式和内容并对相关内容进行检查并提出问题，从而实现主动管理的功能。
   1. 流程主要内容

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

1. 分析事件

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

1. 生成问题记录

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

- 紧急事件处理完后定义为问题
- 技术支持专家在日常维护中发现的问题
- 事件历史记录趋势分析
- 分析周期性报告，找出潜在问题
- 分析第三方提交的检查或审计报告，提出问题

1. 审核

对问题记录的有效性进行审核，确保进入问题管理的问题质量。

1. 升级

跨组问题或复杂问题，升级给问题经理协助处理，包括任务分派、资源协调。

1. 报备

高优先级的重大问题，向运行管理委员会报备，必要时管理层协助进行资源协调。

1. 分派

根据问题内容将问题记录分派给适当的技术小组。

1. 根本原因分析

被分派的小组人员将调查问题以期找出其原因，制定解决方案、变通方法或提出预防性措施，以消除产生原因，或在重发时使其影响力最小化。 记录必须被更新以反映它是已定位原因状态，并且把任何变通方法、避免或最小化负面影响的动作行为也记录下来（如果需要添加到知识库中）。

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

对问题的解决方案进行评估、测试，提出变更请求（RFC）或实施具体的解决方案。

1. 回顾

对问题的解决方案进行回顾，确认解决方案达到了预期的效果。

1. 总结及关闭

确认问题的信息记录已经填写完整，并关闭问题记录。

1. 知识发布

对于问题的发现、解决过程等具备参考价值的问题，在解决完成后发布进知识库。

1. 问题流程执行评估

定期对事件进行分析，对事件上报问题的情况进行评估。

1. 1. 与其他流程的关系
2. 和事件管理流程的关系

紧急事件或重大事件在恢复服务后，如果没有找到根本原因，可升级为问题；对重复发生的事件也可提交为问题进行分析，或根据事件的趋势分析，发现潜在的问题；同时问题的解决方案实施为事件流程提供了解决办法。

事件管理流程定期提供事件分析报表，标识可能问题。

1. 和变更管理流程的关系

问题管理流程的解决方案常常需要通过变更管理流程来完成，因此问题管理将会提出变更申请给变更管理流程。

1. 和配置管理流程的关系

配置管理提供配置项信息给问题管理流程。

1. 和知识库的关系

知识库对问题管理流程提供支持，问题管理流程在处理过程中会引用知识；问题管理流程处理完成后，会向知识库发布知识。

1. 1. 流程范围

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

1. 1. 流程执行原则
      1. 常规原则
2. 应该每半年对问题管理流程的流程关键衡量指标、流程执行效率、流程支撑工具有效性等进行回顾，以改进和优化流程。

1. 应该每月定期回顾和产生问题管理报表，对没有解决的问题，应该举行定期的问题管理会议对这些问题进行评估。
   1. 1. 趋势分析原则

1. 事件管理流程定期提供事件分析报表，标识可能问题。
2. 问题管理员对事件管理流程提交的列表进行分析，发现问题。
   1. 1. 重复问题原则

重复问题是指经过分析之后，根本原因相同并且还未关闭的问题。例如：问题管理员提出了几个问题，但是经过分析之后，发现这几个问题的根本原因是相同的，这几个问题就可以定义为重复问题。重复问题单直接关闭（结束代码为“重复问题”）。

1. 1. 1. 解决方案审核原则
2. 优先级为L1的问题，实施解决方案之后，提交给运行管理委员会审核，确定该问题单是否可以关闭。
3. 优先级为L2的问题，实施解决方案之后，提交给问题管理委员会审核，确定该问题单是否可以关闭。
4. 其他较低优先级的问题单在实施了解决方案之后，由小组组长组织问题负责人回顾解决过程，然后由小组组长确认问题信息记录完整，关闭问题。
   1. 1. 问题关闭审核原则
5. 优先级为L1的问题，实施解决方案之后，提交给运行管理委员会审核，确定该问题单是否可以关闭。
6. 优先级为L2的问题，实施解决方案之后，提交给问题管理委员会审核，确定该问题单是否可以关闭。
7. 优先级为L3/L4/L5的问题单在实施了解决方案之后，如果为本组问题，小组组长组织问题负责人对解决过程进行回顾，如果为跨组问题，由主负责小组组长召集相关专业组人员解决过程进行回顾，然后由小组组长确认问题信息记录完整，关闭问题。
   1. 1. 问题关闭原则

关闭的问题需要满足以下标准：

1. 关联的所有变更已经完成，解决方案已经实施，并且回顾成功。
2. 所有关联的事件已经关闭。
3. 所引发的事件A时间内不再出现。
4. 各类性能、容量的指标恢复正常。
   1. 1. 问题单重开原则

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

1. 1. 流程相关定义
      1. 问题信息项

问题单包含如下信息项：

编号 | 属性 | 类型 | 说明
1 | ID | TEXT | PM+序列号（系统自动生成）
2 | 状态 | CODE | 参见“问题状态”定义
3 | 类别 | TEXT | 参见“问题分类”定义
4 | 影响范围 | CODE | 问题影响的范围，参见”问题影响度”定义
5 | 紧急程度 | CODE | 问题的紧急程度，参见”问题紧急度”定义
6 | 优先级 | CODE | 由影响范围和紧急程度计算得来
7 | 简要描述 | TEXT | 问题的简要描述
8 | 详细描述 | TEXT | 问题的详细描述
9 | 活动记录 | TEXT | 处理步骤的活动记录，包括类型、人员、日期、更新内容
10 | 登记人 | RELATION | 创建此单的人，默认当前登录人
11 | 申请人 | RELATION | 问题流程请求人，默认当前登录人
12 | 问题管理员 | RELATION | 问题管理员
13 | 处理室 | RELATION | 问题单分派人所在的室
14 | 处理组 | RELATION | 此单当前处理人所属的组别，建议按照目前运维组别来分
15 | 分派人 | RELATION | 此单是由谁分配问题负责人
16 | 解决方案 | TEXT | 问题最终解决方案的详细描述
17 | 关闭代码 | RELATION | 参见“问题结束代码”定义
18 | 打开时间 | DATE | 创建时间
19 | 更新时间 | DATE | 最后更新的时间
20 | 期望完成时间 | DATE | 由“优先级”决定
21 | 计划完成时间 | DATE | 小组组长根据问题的实际情况确定计划完成时间
22 | 实际开始时间 | DATE | 问题状态更新为“分析中”的时间
23 | 实际完成时间 | DATE | 当问题状态更新为“已解决“的时间
24 | 是否按时完成 | TEXT | 由“计划完成时间”“实际完成时间”比较的结果决定
25 | 处理时长（分钟） | TEXT | 手工填写
26 | 中断时长（分钟） | TEXT | 手工填写，是指“子类别”的中断时长
27 | 附件 | RELATION | 相关附件
28 | 配置项 | RELATION | 相关配置项（多个）
29 | 相关 | RELATION | 突发事件、服务请求、问题、变更之间的关联（多个）
30 | 问题来源 | CODE | 参见“问题来源”定义
31 | 问题涉及部室 | TEXT | 与问题相关的部室（多个）
32 | 临时解决方案 | TEXT | 详细记录问题的临时解决方案
33 | 问题原因 | TEXT | 详细记录问题产生的根本原因
34 | 重复问题标记 | LOGICAL | 标记为重复问题，用已有标题号标注
35 | 知识ID | TEXT | 在处理问题时引用的知识编号
36 | 是否主动发现 | LOGICAL | “是”或”否”，标记问题是否主动发现
37 | 问题关闭时间 | DATE | 当问题状态更新为“已关闭“的时间
38 | 问题关闭人 | RELATION | 关闭问题的人
39 | 是否报备 | LOGICAL | 问题是否升级到管理层
40 | 问题负责人 | TEXT | 当前问题的负责人
41 | 处理意见 | TEXT | 问题单关联的所有处理人员的意见
42 | 原因分类 | CODE | 参见“原因分类”定义
43 | 原因性质 | CODE | 参见“原因性质”定义
44 | 原因定位 | CODE | 参见“原因定位”定义

1. 1. 1. 问题来源

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

编号 | 代码 | 描述
1 | 事件升级 | 事件恢复服务后，对未找到根本原因的事件，需要提出问题，以便进行事件的根本原因分析。
2 | 维护中提出 | 运维人员在日常维护工作中提出的问题。
3 | 趋势分析 | 通过分析系统报告、事件记录、报表等找出的问题。
4 | 第三方检查或审计 | 第三方在检查或审计的过程中发现的问题，由相关小组负责提出
5 | 管理过程中提出 | 领导在管理过程中提出的问题

1. 1. 1. 问题影响范围

编号 | 影响范围 | 描述
1 | S1 | 全行所有业务系统
2 | S2 | 全行一个或者多个重要业务系统
3 | S3 | 一个或者多个分行所有业务系统
4 | S4 | 一个或者多个分行某个重要业务系统
5 | S5 | 总行或者分行的一个或者多个非重要业务系统
6 | S6 | 对业务有影响的一个或者多个办公系统

1. 1. 1. 问题影响度

编号 | 影响度 | 描述
1 | I1 | 引发服务中断，且没有临时规避措施
2 | I2 | 引发服务中断，但有临时规避措施
3 | I3 | 没有引发服务中断，但系统性能严重下降
4 | I4 | 没有引发服务中断，存在隐患，可能引发服务中断
5 | I5 | 没有引发服务中断，存在隐患，可能造成系统性能下降
6 | I6 | 没有引发服务中断，对服务没有直接影响(例如第三方审计提出的规范类的问题)

1. 1. 1. 问题优先级

问题的优先级是问题负责人解决问题的参照标准，对于优先级为紧急/高的问题，管理层应该优先协调资源进行这些问题的解决。结合系统运行部的实际情况，问题的优先级定义如下：

优先级 | 影响范围
S1 | S2 | S3 | S4 | S5 | S6
影响度 | I1 | L1 | L1 | L1 | L1 | L2 | L2
I2 | L1 | L1 | L1 | L1 | L3 | L3
I3 | L1 | L2 | L2 | L2 | L4 | L5
I4 | L1 | L2 | L3 | L3 | L5 | L5
I5 | L2 | L3 | L4 | L4 | L5 | L5
I6 | L3 | L4 | L4 | L4 | L5 | L5

1. 1. 1. 问题状态

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

编号 | 代码 | 描述
1 | 已登记待识别 | 问题登录到系统中
2 | 已识别待分派 | 问题管理员确定问题有效
3 | 已分派待分析 | 问题已由小组组长分派给问题负责人
4 | 分析中 | 问题负责人正在分析问题
5 | 已定位原因 | 问题根本原因已找出
6 | 已有临时解决方案 | 问题已有临时解决方案
7 | 临时解决方案实施中 | 临时解决方案处于实施中
8 | 已有解决方案 | 解决方案已找到
9 | 解决方案实施中 | 最终解决方案实施中
10 | 回顾中 | 实施完成，需要对解决效果进行回顾
11 | 已解决 | 问题得到解决
12 | 已关闭 | 问题结束

1. 1. 1. 问题结束代码

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

编号 | 代码 | 描述
1 | 根本解决 | 找出问题的根本原因，并得到解决方案，成功解决
2 | 变通方法 | 没有根本解决方案或目前没有办法实施根本解决方案，但有临时解决方案作为变通方法
3 | 无法解决 | 未找到问题的根本原因，没有解决方案，或目前无法实施解决方案，也无变通方法
4 | 找到根本原因、无解决方案 | 找到问题的根本原因，没有解决方案，也无变通方法
5 | 重复问题 | 该问题为重复问题
6 | 取消 | 问题被问题经理或小组组长审核后被取消

1. 1. 1. 原因分类

编号 | 代码 | 描述
0 | 技术 | 技术原因引起的问题
1 | 制度管理 | 制度管理方面的原因引起的问题
2 | 人为 | 人为导致

注：实施时需考虑对各分类的比例设置。

1. 1. 1. 原因性质

编号 | 代码 | 描述
0 | 非致命缺陷 | 目前或潜在地降低但不会中断服务
1 | 致命缺陷 | 中断服务

1. 1. 1. 原因定位

编号 | 代码 | 描述
00 | 人为 | 人为引起
10 | AS/400人为操作失误 | AS/400人为操作失误
11 | AS/400硬件故障 | AS/400硬件故障
12 | AS/400应用软件缺陷 | AS/400应用软件缺陷
13 | AS/400操作系统缺陷 | AS/400操作系统缺陷
14 | AS/400第三方软件缺陷 | AS/400第三方软件缺陷
15 | AS/400数据库缺陷 | AS/400数据库缺陷
20 | 服务器人为操作失误 | 服务器人为操作失误
21 | 服务器硬件故障 | 服务器硬件故障
22 | 服务器应用软件缺陷 | 服务器应用软件缺陷
23 | 服务器操作系统缺陷 | 服务器操作系统缺陷
24 | 服务器第三方软件缺陷 | 服务器第三方软件缺陷
25 | 服务器数据库缺陷 | 服务器数据库缺陷
30 | 网络人为操作失误 | 网络人为操作失误
31 | 网络硬件故障 | 网络硬件故障
33 | 网络操作系统缺陷 | 网络操作系统缺陷
41 | 系统支持硬件故障 | 供电、机房、空调等硬件故障
42 | 系统支持应用软件缺陷 | 供电、机房、空调等监控等应用软件缺陷
99 | 未知错误 | 未知错误

1. 1. 1. 问题分类（classification）

问题分类是针对问题所属的专业类型进行划分的，通过问题分类可以定位解决问题的人，并针对问题分类进行分类统计。

分类 | 一级子类 | 二级子类

1. 1. 关键角色、职责定义

流程的实现是通过不同的流程角色以及其所赋有的职责来实现的，因此流程的每一个角色可以被定义为一系列职责的集合，在实际的管理操作中，不同的人员将被赋予不同的职责，也可能一个人被赋予多个职责。

问题管理流程主要分为问题经理、小组组长、问题管理员、问题负责人、问题支持小组和问题管理委员会职责角色，分别简述如下：

1. 1. 1. 问题经理

问题经理从总体上对问题管理流程的设计、实施、执行及优化负责，确保问题管理流程在系统运行部范围内被正确的执行。当流程不能够适应系统运行部的情况时，问题经理必须及时的对此进行分析、找出缺陷、进行改进，从而实现可持续提高。同时负责协调日常的问题管理工作，包括对问题的审核、监控、所需资源的协调、定期产生报表等。

职责：

1. 整体上对问题流程负责，建立流程实施、评估和持续优化机制
2. 确保问题流程的有效执行，定期评估流程，制定流程改进计划
3. 领导问题管理人员，确保大家的积极性
4. 进行事后回顾、检查或重大问题审查
5. 监视问题的诊断、分析和处理过程
6. 必要时与服务台及问题请求者沟通问题的相关信息
7. 确定或定义问题基本规则信息，并确保有效协调资源
8. 分析和评价主动问题管理活动的有效性。
9. 定期制定问题报表，提供正确决策信息
10. 定期收集、汇总、并分析生成各小组运维系统状态报告，提出改进建议
11. 制订问题管理相关制度及规范并推广执行
12. 召开问题管理委员会例会
13. 提供管理信息并运用这些信息来主动预防事件和问题的发生
14. 对问题管理委员会、问题管理员、问题负责人等问题管理人员进行管理
15. 向管理层报备重大问题

技能要求：

1. 深刻理解问题管理流程
2. 充分理解系统运行部其他的运维流程，能够进行流程接口设计
3. 能够很好地理解业务对于问题管理的需求
4. 对质量控制与保障有很深入的了解
5. 有决策权，能够确保问题管理流程设计要求在实施项目中得到贯彻和执行
6. 具有很好的沟通技能，能够取得公司高层的支持，获得所需资源
7. 具有较强的计划、组织、领导和控制才能，能够综合各方意见，按时制订和定期优化问题管理流程
   1. 1. 小组组长
8. 小组组长为当前各专业组组长
9. 领导本组问题管理人员，确保人员的技能水平
10. 评估问题并分派相应资源（指派问题负责人并建议问题支持小组）
11. 评估问题的临时措施解决方案
12. 评估问题的永久解决方案
13. 回顾所有已完成的问题，确保解决问题
14. 协助问题经理确定问题解决的优先级及调配资源
15. 必要时，协调资源为问题负责人提供支持

技能要求：

1. 具有较好的沟通和口头表达能力
2. 熟悉技术平台和技术环境
3. 较强的分析事件趋势的能力
4. 深刻熟悉问题管理流程
   1. 1. 问题管理员
5. 对事件定期提供的事件问题列表进行检视、归纳并提出问题
6. 审核问题的有效性
7. 检查并规范问题的入口
8. 对跨组、重大或其他复杂问题，申请问题经理协调各个问题管理员
9. 督促问题解决的进展
10. 补充完善问题单的内容
11. 参与问题管理委员会定期例会，对问题管理的流程、执行效率作出分析并提出改进措施
12. 提交问题至所属组组长
13. 问题管理委员会成员
14. 定义并维护周期性问题分析报告，并对报告进行分析，发现隐患
15. 督促审核问题流程执行情况

技能要求：

1. 较强的专业知识
2. 较强的分析问题的能力和技巧，能够对问题的有效性提出建议
3. 较好的沟通和表达能力
4. 较强的统计分析能力
   1. 1. 问题负责人

问题负责人为问题的诊断及解决提供技术支持。通常由各专业组技术人员承担。

职责：

1. 接受小组组长分派过来的问题
2. 分析和诊断问题，确定根本原因
3. 提交变更请求并监控变更实施
4. 协助事件支持人员进行重大或紧急事件的处理
5. 需要时协调第三方的资源来帮助诊断和改正问题
6. 根据实际情况修改问题单的内容
7. 指派问题支持小组
8. 联系第三方技术支持并协调安排其解决问题的活动
9. 问题的解决方案制定
10. 问题的解决方案执行
11. 问题的解决方案校验
12. 问题的解决方案的知识发布

技能要求：

1. 较强的问题解决能力， 能够对问题进行分析并给出解决方案
2. 较强的专业知识
3. 较强的分析问题的能力和技巧
4. 较好的沟通和表达能力
   1. 1. 问题管理委员会
5. 问题管理委员会由问题经理及各个问题管理员组成
6. 问题管理委员定期召开例会，对问题管理的流程、执行效率作出分析并提出改进措施
7. 问题管理委员会根据KPI对问题管理参与者提出奖惩措施
8. 问题管理委员会负责制定并修订问题管理相关制度

技能要求：

1. 较强的专业知识
2. 较强的分析问题的能力和技巧，能够对问题的有效性提出建议
3. 较好的沟通和表达能力
   1. 1. 问题支持小组

问题支持小组为问题的诊断及解决提供技术支持。

职责：

1. 按负责技术、专业及业务等不同分为多个问题支持小组
2. 接受问题负责人分派过来的问题任务
3. 分析和诊断问题，确定根本原因
4. 监控已知错误的进展情况；
5. 确定和测试解决方案
6. 防止问题扩散到其他系统

技能要求：

1. 较强的问题解决能力， 能够对问题进行分析并给出解决方案
2. 较强的专业知识
3. 较强的分析问题的能力和技巧
4. 较好的沟通和表达能力
   1. 1. 流程角色和人员对应表

在系统实施时由系统运行部根据实际运维在此表基础上完成具体的人员映射

角色 | 成员 | 备注
问题经理 |  |
小组组长 | 系统运行室 |  |
系统管理室 |  |
网络室 |  |
系统支持室 |  |
XX灾备中心 |  |
安全室 |  |
问题管理员 | 系统运行室 |  |
系统管理室 |  |
网络室 |  |
系统支持室 |  |
XX灾备中心 |  |
安全室 |  |
问题支持小组 |  |
问题负责人 |  |
问题管理委员会 |  |

1. 1. 概要流程设计

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

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

序号 | 步骤名称 | 责任人 | 说明
300.1 | 问题的识别和提交 | 问题管理员 | 对事件定期提供的事件问题列表进行检视、归纳并提出问题。 对上报的问题进行初步审核，确定问题是否有效、是否重复问题、问题信息项填写是否完整。 如果问题确认无效，则关闭问题，并通知请求者。 根据问题所属领域进行分类，并初步判断问题的优先级。 如果属于跨组或重大问题，将问题单分配给问题经理，由问题经理协调问题的负责人，以及确定是否需要向管理层报备；一般问题则直接提交给相应的小组组长。
| 是否跨组问题/重大问题 | 问题管理员 | 判断是否是跨组问题或者重大问题。 是，升级给问题经理。 否，提交给本组组长。
| 资源协调、重大问题报备 | 问题经理 | 对于跨组问题问题经理负责协调资源，确定主处理组。 重大问题，问题经理向运行管理委员会报备。
| 是否继续处理 | 问题经理 | 问题经理协调后确定问题是否需要继续处理。 是，确定资源。 否，直接关闭。
300.2 | 问题审核与分派 | 小组组长 | 小组组长对新建的问题进行审核初步评估，确定优先级设置是否正确，如果不正确，退回由问题管理员修改优先级。 根据问题的分类，把问题分派给相应问题负责人。 如问题负责人发现问题应该由其他组分析解决，分派到相应的专业组。
300.3 | 分析根本原因 | 问题负责人 | 问题负责人接收问题，更新问题状态。 如需其他组资源协助分析、诊断，则通知问题经理，由问题经理协调资源。 如需问题支持小组协助分析诊断，分派任务给问题支持小组人员，并负责跟踪、汇总分析结果。 记录根本原因并发布已知错误。 如果问题负责人预计无法找到问题的根本原因，也应及时通报问题经理，由其决定是否需要继续分析。
问题支持小组 | 接收问题负责人分派的任务，协助调查诊断问题根本原因。
300.4 | 推荐解决方案 | 问题负责人 | 问题负责人提供变通方法。 可能需要对方案进行测试。 将临时解决方案或根本解决方法及时更新到问题记录中。
问题支持小组 | 协助提供问题的临时解决方案或根本解决方法。
300.5 | 解决方案审核 | 小组组长 | 审核提交的解决方案/临时解决方案。 审核相应的文档。 审核方案是否可行，如果不可行，是否需要问题经理进行资源协调，如果不需要，发回对应的责任人。如需要，则由问题经理协调资源，然后发给指派的问题负责人。 如果方案可行，填写审核意见，发回对应的问题负责人安排实施。
| 是否需要变更 | 问题责任人 | 问题责任人判断是否需要变更。 是，在变更流程提交变更。 否，直接实施解决方案。
300.6 | 实施解决方案 | 问题负责人 | 根据解决方案/临时解决方案制定实施方案，并负责实施。 根据制定的解决方案或临时解决方案，确定是否需要变更。如果需要变更，填写变更请求单，递交到变更管理，并监视变更的实施过程，和变更管理保持沟通。
300.7 | 监控及回顾 | 小组组长 | 对实施了解决方案，监控一段时间以确保问题已经根治，如果问题没有被解决，问题负责人必须重新评估问题的解决方案改正措施。 如果问题被解决，回顾问题并更新问题记录。
| 是否需要继续处理？ | 小组组长 | 小组组长判断问题是否需要继续处理。 如果问题没有解决，或者实施的仅是临时解决方案，并且需要找出最终解决方案，转回，继续处理。 如果问题已经彻底解决，或者实施了临时解决方案之后不需要找出最终解决方案，进入关闭问题阶段。
300.8 | 关闭问题 | 小组组长 | 提交问题总结报告。 选择合适的问题异常来源代码。 选择合适的结束代码，关闭问题记录。
300.9 | 问题跟踪与升级 | 小组组长/问题管理员 | 跟踪问题的状态和进展。 在问题处理过程中出现异常时，如果必要则升级到问题经理，由问题经理进行协调。问题经理根据情况确定是否需要问题管理委员会或运行管理委员会协调。

1. 1. 流程详细设计
      1. （300.1）问题的识别和提交

描述如下：

序号 | 步骤名称 | 责任人 | 输入 | 输出 | 说明
| 趋势分析 | 事件管理人员、问题经理、问题管理员 | 事件详细记录 | 问题记录 | 事件管理人员对事件趋势分析得出的事件问题列表， 问题管理员对事件问题列表进行分析，发现问题。 问题经理可周期性的召集由事件经理、问题管理员、问题负责人参加的会议，对事件记录详细信息进行趋势分析（可以每周/每月为周期）： 在本周期内每类事件的数量。 发生的频度有不断增加的趋势的事件。 对于没有根本解决的事件记录进行分析。 可采取趋势突变法（如有30%增长率的某类事件）或阈值法对事件进行分析，发现需进一步分析的潜在问题。
| 事件升级 | 事件经理 | 紧急或重大事件详细记录 | 问题记录 | 在紧急事件或重大事件处理完成后，如果未找到根本原因，则都由事件经理根据该事件的处理情况，提交问题。
| 维护中提出 | 问题负责人 | 监控数据、日常维护等 | 问题记录 | 由运维人员在日常维护工作中根据自己的经验或分析，在自己负责的领域内发现并提出的问题请求： 通过日常巡检发现的问题。 对日常维护监控数据进行分析。
| 管理过程中提出 | 管理层 | 日常管理 | 问题记录 | 管理层在管理过程中发现的问题。
| 第三方检查或审计 | 管理员 | 第三方检查或审计报告 | 问题记录 | 根据第三方提供的检查或审计报告，提交问题。
300.1.1 | 审核问题记录 | 问题管理员 | 问题记录 | 问题记录 | 对上报的问题进行初步审核，确定问题是否有效、问题信息项填写是否完整。 如果问题记录信息不完整或不正确，则通知问题请求者，由其提供完善的问题信息。
300.1.2 | 审核通过吗？ | 问题管理员 | 问题记录 | 审核后的问题记录 | 判断审核是否通过。 是，转到300.1.3 否，转到300.7
300.1.3 | 重复问题吗？ | 问题管理员 | 问题记录 | 判断结果 | 判断该问题请求是否与某个未关闭的问题重复。 是，转到300.1.4 否，转到300.1.5
300.1.4 | 标识重复问题 | 问题管理员 | 问题记录 | 标识后的重复问题 | 在重复问题上做重复标识。
300.1.5 | 确定问题优先级及分类 | 问题管理员 | 问题记录 | 问题优先级/分类 | 根据问题记录的实际情况及预先制定的优先级描述，初步给问题记录分配相应的优先级代码。 根据问题的来源和所涉及的领域，及已定义的分类原则，初步对问题进行分类。 问题状态表示为“已识别”。
300.1.6 | 问题升级 | 问题管理员 | 问题记录 |  | 对于跨组问题或优先级高的问题，将问题升级给问题经理，进行资源协调。
| 是否重大问题 | 问题经理 | 问题记录 | 判断结果 | 问题经理确定是否是重大问题，如果是重大问题向管理层报备，否则直接到300.1.7。
300.1.7 | 资源协调 | 问题经理 | 问题记录 | 主负责组 | 问题经理接收升级的问题，通过分派任务、会议、电话、邮件等方式召集各相关小组组长，确定问题的主负责组。
| 是否处理 | 问题经理 | 问题记录 | 是否处理 | 问题经理通过与各组沟通，确定是否继续处理问题。 是，转到300.2 否，转到300.8，关闭问题
300.1.8 | 报备 | 运行管理委员会 | 重大问题 |  | 当需要协调外部门或供应商时，负责协调相关的资源。 跟踪督促重大问题的处理。
300.1.9 | 分派任务 | 问题经理 | 跨组问题/重大问题 | 任务 | 问题经理给各小组组长分派任务，知会各组长。
300.1.10 | 反馈 | 小组组长 | 任务 | 反馈意见 | 小组组长针对任务反馈意见。

1. 1. 1. （300.2）问题审核与分派

描述如下：

序号 | 步骤名称 | 责任人 | 输入 | 输出 | 说明
300.2.1 | 审核问题记录 | 小组组长 | 问题记录 | 审核后的问题记录 | 问题经理对问题管理员提交的问题记录进行审核。
| 优先级/分类正确吗？ | 小组组长 | 问题记录 | 是否正确 | 判断该问题的优先级及分类是否正确，如果不正确，退回到300.1，由问题管理员更新正确优先级/分类。
300.2.2 | 分派问题 | 小组组长 | 问题记录 | 已分配的问题 | 根据问题所属类别，把问题分派给相应的问题负责人。若问题比较复杂，小组组长需组建问题分析小组，并将该问题分配给当中最主要的处理人员。 问题状态标识为“已分派”。
| 接受吗？ | 问题负责人 | 已分派问题 | 是否接受结果 | 问题负责人在收到小组组长分派的问题后，对问题进行初步分析，以决定接受与否。 如拒绝，注明拒绝的理由，并推荐相应的工作组或个人。 如接受，则将状态改为“分析中”，转向300.3分析根本原因。

1. 1. 1. （300.3）分析诊断问题

描述如下：

序号 | 步骤名称 | 责任人 | 输入 | 输出 | 说明
300.3.1 | 分析根本原因 | 问题负责人 | 问题记录 | 分析结果 | 利用经验或工具分析问题的根本原因。
| 需要其他资源吗 | 问题负责人 | 问题记录 | 其他的资源 | 如果需要其他资源，转到300.9。
| 需要支持小组支持吗 | 问题负责人 | 问题记录 | 问题支持小组 | 确定是否需要问题支持小组支持。 是，转到300.3.2 否，转到300.3.4
300.3.2 | 分派任务 | 问题负责人 | 问题记录 | 任务 | 根据问题分类，给相应的问题支持小组分派任务。
300.3.3 | 分析根本原因 | 问题支持小组 | 任务 | 根本原因 | 问题支持小组人员根据经验或工具分析问题的根本原因。
300.3.4 | 记录根本原因 | 问题负责人 | 根本原因 | 更新的问题记录 | 更新问题记录，将问题的根本原因填入问题记录中，问题状态更新为“已定位原因”。

1. 1. 1. （300.4）推荐解决方案

描述如下：

序号 | 步骤名称 | 责任人 | 输入 | 输出 | 说明
300.4.1 | 尝试找出解决方案 | 问题负责人 | 问题记录，相关信息及根本原因 | 分析结果 | 问题负责人尝试找出问题的解决方案。
| 需要其他资源吗 | 问题负责人 | 问题记录，相关信息及根本原因 | 可能需要的资源 | 问题负责人在推荐方案的过程中如果需要其他资源，可通过问题管理员协调，也可升级到问题经理处获得支持。
| 需要支持小组支持吗 | 问题负责人 | 问题记录，相关信息及根本原因 | 可能需要的支持 | 确定是否需要问题支持小组支持 是，转到300.4.2 否，转到300.4.6
300.4.2 | 分派任务 | 问题负责人 | 问题记录，相关信息及根本原因 | 派出的任务 | 根据问题分类及性质给相应的问题支持小组人员分派任务。
300.4.3 | 尝试找出解决方案 | 问题支持小组 | 问题记录，相关信息及根本原因 | 临时解决方案或最终解决方案 | 问题支持小组接收问题负责人分派的任务，尝试找出解决方案。
300.4.4 | 推荐解决方案 | 问题支持小组 | 问题记录，相关信息及根本原因 | 临时解决方案或最终解决方案 | 问题支持小组人员确定临时解决方案或最终解决方案。
300.4.5 | 推荐解决方案 | 问题负责人 | 问题记录，相关信息及根本原因 | 临时解决方案或最终解决方案 | 问题负责人确定问题解决方案或接收问题支持小组提交的解决方案，更新问题记录。 如果为临时解决方案，问题状态更新为“已有临时解决方案” 如果为最终解决方案，问题状态更新为“已有解决方案”
300.4.6 | 标识为已知错误 | 问题负责人 | 问题记录，相关信息、根本原因解决方案 | 已知错误 | 将问题发布为已知错误。

1. 1. 1. （300.5）解决方案审核

描述如下:

序号 | 步骤名称 | 责任人 | 输入 | 输出 | 说明
300.5.1 | 审核解决方案 | 小组组长 | 解决方案 CMDB | 审核结果 | 对问题负责人提交的解决方案进行审核：在技术上和执行上（如需要新的采购，需要多个部门配合等）进行评估。
| 是否需要运行管理委员会审核 | 小组组长 | 问题优先级 | 判断结果 | 根据问题优先级判断解决方案是否需要运行管理委员会审核。 是，转到300.5.2，提交给运行管理委员会审核。 否，判断是否需要问题管理委员会审核。
300.5.2 | 审核解决方案 | 运行管理委员会 | 方案和相关文档 | 审核结果 | 运行管理委员会判断解决方案是否可行，反馈审核意见。
| 是否需要问题管理委员会审核 | 小组组长 | 问题优先级 | 判断结果 | 根据问题优先级判断解决方案是否需要问题管理委员会审核。 是，转到300.5.3，提交给问题管理委员会审核 否，转到300.5.4
300.5.3 | 审核解决方案 | 问题管理委员会 | 方案和相关文档 | 审核结果 | 问题管理委员会判断解决方案是否可行，反馈审核意见。
300.5.3 | 填写审核意见 | 小组组长 | 审核意见 | 更新的问题单 | 小组组长根据审核的结果填写审核意见。
| 是否需要管理层复审 | 小组组长 | 审核意见 | 判断结果 | 小组组长填写审核意见之后，根据问题的优先级确定是否需要管理层进行核定。 是，转到300.5.5，提交给管理层复审 否，进入审核是否通过判断
300.5.5 | 核定审核意见 | 运行中心管理层 | 审核意见 | 核定结果 | 运行中心管理层对问题的审核意见进行复审，判断是否属实。
| 审核是否通过 |  | 审核结果 | 是否通过结果 | 根据各级审核意见确定是否同意解决方案。 是，如果是临时解决方案，更新问题状态为“临时解决方案实施中”，如果是最终解决方案，更新问题状态为“解决方案实施中”，转到300.6 否，转回300.4

1. 1. 1. （300.6）实施解决方案

描述如下:

序号 | 步骤名称 | 责任人 | 输入 | 输出 | 说明
| 是否需要变更 | 问题负责人 | 解决方案 CMDB 变更范围 | 是否需要变更的判断 | 判断解决方案是否在变更管理的范围之内，做出是否进行变更请求的判断。 是，转到300.6.1 否，转到300.6.2
300.6.1 | 提交变更 | 问题负责人 | 带有已批准的解决方案的问题记录 | 变更 | 提交变更请求。
300.6.2 | 计划、安排解决方案的实施 | 问题负责人 | 带有已批准的解决方案的问题记录 |  | 根据解决方案，计划安排解决方案的实施，实施完成后更新问题状态为“回顾中”,转入300.7。
300.6.3 | 提交问题总结 | 问题负责人 | 已实施解决方案问题记录 | 问题总结 | 问题解决完成后，对问题进行总结。
| 是否需要发布知识 | 问题负责人 | 已有解决方案的问题记录 | 是否需要发布知识 | 判断是否需要发布知识。 是，转到300.6.4
300.6.4 | 发布知识 | 问题负责人 | 已实施解决方案问题记录 | 知识记录 | 发布知识到知识库。

1. 1. 1. （300.7）监控及回顾

描述如下:

序号 | 步骤名称 | 责任人 | 输入 | 输出 | 说明
300.7.1 | 监控解决方案实施情况 | 小组组长 | 实施的解决方案或变更 | 监控结果 | 通过对实施过程的监控及事后通过工具或对IT环境的直接观察监控解决方案的实施结果。
| 是否需要继续处理 | 小组组长 | 实施的解决方案或变更 | 监控结果 | 确定问题是否需要继续处理。 如果问题没有解决，或者实施的仅是临时解决方案，并且需要找出最终解决方案，转回300.4，继续处理。 如果问题已经彻底解决，或者实施了临时解决方案之后不需要找出最终解决方案，转入300.7.2。
300.7.2 | 回顾问题过程 | 小组组长 | 解决的问题 | 更新整理的问题记录 | 回顾问题过程，整理不完善的记录信息。
300.7.3 | 更新问题记录 | 小组组长 | 更新整理的问题记录 | 更新的问题记录 | 根据问题解决的过程，更新问题记录。 更新问题状态为‘已解决’。

1. 1. 1. （300.8）关闭问题

描述如下:

序号 | 步骤名称 | 责任人 | 输入 | 输出 | 说明
300.8.1 | 审核问题总结报告 | 小组组长 | 问题总结报告 | 审核后问题总结报告 | 小组组长审核问题负责人提交的问题审核报告。
| 是否需要运行管理委员会审核 | 问题经理/小组组长 | 问题实施记录及结果 | 判断结果 | 根据问题优先级判断解决方案是否需要运行管理委员会审核。 是，转到300.8.2，提交给运行管理委员会审核。 否，判断是否需要问题管理委员会审核。
300.8.2 | 审核解决结果 | 运行管理委员会 | 问题实施记录及结果 | 审核结果 | 判断问题是否可以关闭。
| 是否需要问题管理委员会审核 | 问题经理/小组组长 | 问题实施记录及结果 | 判断结果 | 根据问题优先级判断解决方案是否需要问题管理委员会审核。 是，转到300.8.3，提交给问题管理委员会审核。 否，转到300.8.4。
300.8.4 | 记录审核结果 | 问题经理/小组组长 | 审核结果 | 更新的问题记录 | 根据各级审核结果填写审核意见。
| 是否需要管理层复审 | 问题经理/小组组长 | 审核结果 | 判断结果 | 问题经理/小组组长根据问题优先级判断是否需要运行中心管理层对审核意见进行复审。 是，转到300.8.5，提交给管理层复审 否，进入是否可以关闭判断
300.8.5 | 核定审核意见 | 运行中心管理层 | 审核意见 | 核定结果 | 运行中心管理层对问题的审核意见进行复审，判断是否属实。
| 是否可以关闭 | 问题经理/小组组长 | 审核结果 | 判断结果 | 问题经理/小组组长根据各级审核结果确定是否可以关闭。 是，转到300.8.6。 否，转到300.1/300.6。
300.8.6 | 选择结束代码 | 问题经理/小组组长 | 问题记录 | 更新结束代码的问题记录 | 选择合适的结束代码，更新问题记录。
300.8.7 | 关闭记录 | 问题经理/小组组长 | 更新结束代码的问题记录 | 关闭的问题记录 | 问题状态更新为‘结束’。 关闭问题记录。

1. 1. 1. （300.9）问题跟踪与升级

描述如下:

序号 | 步骤名称 | 责任人 | 输入 | 输出 | 说明
300.9.1 | 检查当前问题状态 | 问题管理员 | 问题记录 | 跟踪结果 | 检查当前问题记录是否正常，跟踪问题负责人处理问题过程中是否按照优先级进行处理，是否在设定的时限前解决问题或处理质量如何。
| 处理过程正常么（基于优先级定义） | 问题管理员 | 问题记录 | 判断结果 | 检查是否有违反优先级处理现象，是否按照既定时间进行处理。 是，升级给小组组长。 否，跟踪结束。
| 需要升级，得到资源支持么 | 小组组长 | 问题记录 | 升级 | 检查问题处理是否需要其他资源支持，或由问题负责人申请资源，升级到问题经理进行资源协调。问题经理根据情况确定是否需要升级到问题管理委员会或运行管理委员会协调。
300.9.2 | 协调资源 | 问题经理/问题管理委员或/运行管理委员会 | 需要的资源 | 协调好的资源 | 问题经理/问题管理委员会/运行管理委员会，协调合适的资源。
| 跟踪结束 | 小组组长/问题管理员 | 问题记录 | 跟踪结果 | 跟踪过程结束

1. 关键流程衡量指标

为了较好地控制流程的质量，必须为流程设置衡量指标，通过对指标的分析，可以有效地对流程的运行情况进行监控和改进。

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

序号 | 衡量指标
1 | 每月记录的问题总数和分类数目以及各自的比例
2 | 按照优先级代码统计的问题数量、比例
3 | 按照原因分类统计的问题数量、比例
4 | 由各支持小组(包括供应商)解决的问题数量、比例
5 | 由各问题负责人解决的问题数量、比例
6 | 按照问题分类统计问题数量和比例
7 | 主动发现的问题数量、比例
8 | 超时解决问题数量、比例
9 | 按时解决问题数量、比例
10 | 重复问题数量、比例
11 | 按照问题分类统计当前处于各状态的问题的数量、比例
12 | 按照问题分类统计当前阶段内已解决问题的数量、比例
13 | 按照问题分类统计当前阶段未关闭的问题数量

1. 问题管理流程报表

报表可以分为两类：一类为周期性报表，一类为实时状态报表，现说明如下：

1. 周期性报表：定期（每周和每月）生成一系列的管理类报表提供给流程经理及管理层，监控流程的执行情况，以便于进一步优化流程；管理层可以从问题数量、解决率、解决时间等统计信息，分析IT基础设施的健康状况、IT人力资源、技术能力、人员培训等各方面可能存在的问题，为下一步的管理决策提供依据。
2. 时实状态报表：日常流程执行过程中时实生成的报表视图，提供给流程经理，以便于监控流程的执行情况及进一步优化流程。
3. 根据工作说明书分别定义如下：

序号 | 周期性报表
1 | 每月记录的问题总数和分类数目以及各自的比例
2 | 按照优先级代码统计的问题数量、比例
3 | 按照原因分类统计的问题数量、比例
4 | 由各支持小组(包括供应商)解决的问题数量、比例
5 | 由各问题负责人解决的问题数量、比例
6 | 按照问题分类统计问题数量和比例
7 | 主动发现的问题数量、比例
8 | 超时解决问题数量、比例
9 | 按时解决问题数量、比例
10 | 重复问题数量、比例
| 实时视图
11 | 按照问题分类统计当前处于各状态的问题的数量、比例
12 | 按照问题分类统计当前阶段内已解决问题的数量、比例
13 | 按照问题分类统计当前阶段未关闭的问题数量

1. 问题管理流程改进建议

问题管理流程改进可以与其他流程管理改进会议一起召开，作为一项内容，也可结合部门的例会一起召开， 这部分由问题经理负责， 建议的改进的流程如下：

描述如下：

序号 | 步骤名称 | 责任人 | 输入 | 输出 | 说明
300.10.1 | 评估流程 | 问题经理 | 流程报表， 问题经理反馈， 其他流程经理及负责人反馈 | 差距分析报告 | 定期进行流程有效性与执行效果的评估；周期可定为半年一次，或根据反馈紧急评估优化。
300.10.2 | 制定改进和实施计划 | 问题经理 | 差距分析报告 业务需求 | 得到认可的改进计划 | 根据差距分析，制定改进流程计划。 一个改进计划应该包括如下考虑： 流程不足和改进的机会 流程执行者的需求 改进期望及收益 对流程本身及流程外部可能的影响和风险 需要的资源和成本 测试和培训 建议的改进计划需要文档化，然后尽量给所有影响到的组审阅，以期得到在实施时的支持配合和协作。
300.10.3 | 建立和提交RFC | 问题经理 | 改进计划 | 提交的RFC | 建立和提交RFC，以得到批准实施计划
300.10.4 | 实施计划 | 问题经理 | 批准的RFC， 改进计划 | 实施的改进 | 协调进行流程设计上的改进及电子化平台的相应改进实施
300.10.5 | 回顾实施 | 问题经理 | 实施的改进 | 关闭的RFC 回顾结果 | 实施被监控以保证流程不被中断，流程按预期工作运行。实施结束后，立即开始回顾以判断实施是否真正成功
300.10.6 | 更新流程改进计划 | 问题经理 | 流程改进计划 回顾周期 | 更新的流程改进计划 | 按预定周期或紧急需要进行流程改进计划的更新

Tags:
Created by superadmin on 2024/10/01, 09:25

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

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