ITIL 4官方核心著作
01 某地铁公司信息化基础架构平台建设项目ITIL问题管理流程
复制
导出
注释
打印预览
查看源代码
子项
评论
附件 (11)
历史记录
信息
某地铁公司信息化基础架构平台建设项目ITIL问题管理流程
1 目标
问题管理流程的根本目的是消除或减少生产环境中事件发生的数量和严重程度，从而为企业建立一个稳定的IT环境，提高IT服务的可用性。问题管理流程常常需要和变更管理流程一起来实施找出的解决方案，以便从根本上解决问题。其目的包括：
- 分析并确定事件的根本原因，找到最终解决方案，以防止此类事件再次发生
- 确保问题分派了正确支持人员，提高解决率
- 根据问题优先级合理分派IT资源
- 对事件记录做趋势性分析，主动提供预防性措施
- 提高IT服务的可靠性
- 降低IT支持成本
2 流程范围
XX地铁问题管理流程的范围包括： 正式环境中IT基础架构、信息系统所发生的各种问题
XX地铁问题管理流程的范围不包括： 处于开发或测试环境中的各种问题
3 流程主要内容
4 常规原则
4.1 建立独立问题管理流程，在整个企业范围内应该与事件管理流程相对独立，事件经理与问题经理应该尽可能的由不同的人员担任
4.2 问题经理负责问题分析、诊断、解决过程中的跟踪和监控，对于问题处理专家认为无法找到根本原因或虽有解决方案，但目前无法实施（如实施的代价太大等），问题经理协调问题处理专家进行分析判断，决定该问题是继续诊断、解决还是关闭该问题。
4.3 应该每季度对问题管理流程的流程关键衡量指标、流程执行效率、流程支撑工具有效性等进行回顾，以改进和优化流程
4.4 应该每月定期回顾和产生问题管理报表，并对没有解决的问题进行评估和分析，明确这些问题后续应如何处理
5 协查原则
根据实际情况，同一问题可通过子任务单的形式分派至多人进行协同分析与评估，协查人员将意见、解决办法通过子任务单反馈后，由本问题单所分派的问题处理专家进行汇总，制定最终方案，同时根据需要可由问题经理协调相关资源、人员进行线下的相关研讨会议
6 流程关联原则
6.1 和事件管理的关联—— 群体性、重复性事件或影响较大的事件等在恢复服务后，都应该创建问题单（问题单必须和事件单建立关联）
6.2 和变更管理的关联—— 问题处理过程中，如果需要对系统进行变更，必须按照变更管理的定义，提交变更请求单（变更单必须和问题单建立关联），变更完成后，继续问题单的处理
6.3 和配置管理的关联—— 问题处理过程中，可以通过配置管理查询相关的配置项信息
—— 问题处理过程中，如果可以将根本原因定位到某个配置项，则必须将问题单与该配置项关联
6.4 和知识管理的关联—— 问题管理流程结束后，将提炼出相关知识条目，并将其输入给知识管理流程
7 所有权原则
有效管理问题的前提是必须确保每个问题在任何时段都有适当的人员负责
- 问题首先由问题经理审核，再负责分派给合适的问题处理专家
- 当问题分派到问题处理专家后，问题处理专家负责该问题的诊断与解决
- 协查人员负责从所属的专业领域对问题进行分析，通过子任务单的方式反馈解决方案以便问题处理专家汇总、分析
- 问题经理负责与问题请求者沟通问题处理过程中的关键信息
8 再分派原则
再分派又称转派，它确保问题单不被过于频繁的相互转派、以至于无法在规定时间内得到解决，应当尽量减少问题单再分派的几率，一个问题单再分派的次数不应该超过两次。
问题单再分派必须经过问题经理。
9 重复问题原则
重复问题是指经过分析之后，根本原因相同的问题。例如：问题处理专家提出了几个问题，但是经过分析之后，发现这几个问题的根本原因是相同的，这几个问题就可以定义为重复问题。对于重复问题需要进行标志，将相关问题记录进行关联，当问题解决时同时进行回顾。
10 问题关闭原则
通常，问题单在实施了解决方案之后，需要经过一段时间的回顾，由问题处理专家和问题经理一起来回顾解决方案是否达到了预期的效果，如果成功的实施，则提交给问题经理，由问题经理确认问题信息记录完整，关闭问题。
11 问题单重开原则
已关闭的问题单不允许重开。如果问题重复发生，则创建一个新的问题单，新问题单需要关联之前的问题单。
12 趋势分析原则
问题经理应定期组织会议（如每季度），对所处理事件的历史记录进行趋势分析：
- 参加者应包括事件经理及问题处理专家
- 会议定期组织
13 问题管理概要流程
14 详细设计：问题的识别与记录
15 详细设计：问题审核
16 详细设计：问题分派
17 详细设计：分析并诊断问题/提供变通方法
18 详细设计：开发、确认、实施解决方案
19 详细设计：问题回顾
20 详细设计：问题总结与关闭
21 问题状态迁移图
22 问题经理
问题经理从总体上对问题管理流程的设计、实施、执行及优化负责， 确保问题管理流程被正确的执行；负责协调日常的问题管理工作，包括对问题的审核、监控、所需资源的协调、定期产生报表等。
职责：
- 确保问题流程的设计、实施及执行，能够取得管理层的参与和支持
- 确保问题流程符合公司实际状况和公司 IT发展战略
- 整体上对问题流程负责，建立流程实施、评估和持续优化机制
- 确保问题流程的有效执行，定期评估流程，制定流程改进计划
- 保持与其他流程负责人的定期沟通
- 定期组织相关人员对事件记录进行分析，发现潜在问题
- 确认和审核问题 必要时对问题进行上报
- 监视问题的诊断、分析和处理过程
- 必要时与帮助台及问题请求者沟通问题的相关信息
- 必要时协调所需资源
- 定期制定问题报表，提供正确决策信息
技能要求：
- 深刻理解问题管理流程
- 能够很好地理解业务对于问题管理的需求
- 对质量控制与保障有很深入的了解
- 有决策权，能够确保问题管理流程设计要求在实施项目中得到贯彻和执行
- 具有很好的沟通技能，能够取得公司高层的支持，获得所需资源
- 具有较强的计划、组织、领导和控制才能，能够综合各方意见，按时制订和定期优化问题管理流程
- 具有较好的沟通和口头表达能力
- 熟悉技术平台和技术环境
- 较强的分析事件趋势的能力
23 问题处理专家
问题处理专家为问题的诊断及解决提供技术支持。通常由各专业组技术人员承担。
职责：
- 接受问题经理分派过来的问题
- 分析和诊断问题，确定根本原因
- 确定和测试解决方案
- 提交变更请求并监控变更实施
- 需要时协调第三方的资源来帮助诊断和改正问题
技能要求：
- 较强的问题解决能力， 能够对问题进行分析并给出解决方案
- 较强的专业知识 较强的分析问题的能力和技巧
- 较好的沟通和表达能力
24 流程活动矩阵表
| 流程主要活动 | 问题处理专家 | 问题经理 |
| 问题的识别与记录 | C/R | R |
| 问题审核 | R | R/A |
| 问题分派 | C | R |
| 分析、诊断问题 | R | A |
| 开发、确认、实施解决方案 | R | A |
| 问题回顾 | R | R/A |
| 问题总结与关闭 | R |
25 问题信息项
| 序号 | 信息项 | 描述 |
| 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 问题来源
| 编号 | 代码 | 描述 |
| 1 | 事件管理流程 | 事件恢复服务后提出的问题，以便进行事件的根本原因分析。 |
| 例如：某日发生了一起集群无法切换的事件，导致某台主机发生故障后，没有切换到备用主机中去，从而影响了业务，事件的处理人员在采取了手工切换的替代措施后，恢复了服务。 | ||
| 为了分析为什么会发生该事件，以及查看其他的集群是否也存在类似的问题，此时可以提出一个问题记录，以便对该事件根本原因进行分析。 | ||
| 2 | 维护中提出 | 在维护中技术专家发现或监控系统发现的问题 |
| （1）技术专家在日常维护工作中提出的问题 | ||
| 例如：维护专家在日常维护中发现，目前的数据库版本可能会存在着死锁等方面的问题，此时就可以提出一个问题记录，以便分析。 | ||
| （2）监控系统前瞻性发现问题 | ||
| 例如，监控系统检测到某一台关键主机在某一个时间段，CPU的使用率一直是100％，此时可以提出一个问题记录，以找出问题的原因并解决。 | ||
| 3 | 趋势分析 | 分析事件记录找出的问题 |
| （1）有明显发展趋势的一类事件 | ||
| 例如：在定期的会议中，对某类的事件进行分析后发现，上周该类型的事件比平常的时候多了30％，超过了规定的阀值，这表明该系统有可能存在着一些潜在的隐患，此时就可以提出一个问题记录，以找出问题的原因并解决。 | ||
| （2）已发生的多个有共同征兆的事件 | ||
| 例如：发生多起网络不能连接的事件，当时都采用临时措施解决了，此时就可以提出一个问题记录，以找出问题的原因并解决。 |
27 问题优先级
| 编号 | 代码 | 描述 |
| 1 | 关键 | 维护专家提出或趋势分析产生的问题从如下方面考虑，问题是否： |
| 紧迫程度最高（如：必须马上着手处理）（按照关键业务和影响范围考虑紧迫程度） | ||
| 资源现状 | ||
| 问题处理后可大幅节省投资、人力，有效提高服务质量和维护效率 | ||
| 2 | 重要 | 从如下方面考虑，问题是否： |
| 紧迫程度较高（按照关键业务和影响范围考虑紧迫程度） | ||
| 资源现状 | ||
| 问题处理后可有效节省投资、人力，一定程度提高维护质量 | ||
| 3 | 普通 | 从如下方面考虑，问题是否： |
| 紧迫程度低（按照关键业务和影响范围考虑紧迫程度） | ||
| 资源现状 | ||
| 问题处理后对维护质量和效率的提升有限 |
28 问题状态
| 编号 | 代码 | 描述 |
| 1 | 已登记 | 问题登录到系统中 |
| 2 | 分析中 | 问题处理专家正在分析问题过程中 |
| 3 | 已定位原因 | 问题根本原因已找出 |
| 4 | 已有解决方案 | 解决方案已找到 |
| 5 | 已提出变更请求 | 已提交变更请求（RFC） |
| 6 | 已回顾 | 已经对问题进行了回顾 |
| 7 | 结束并关闭 | 问题结束 |
29 应用系统
| 类别 | 子类 |
| 已委托运维类系统 | SPS平台 |
| IT运维系统 | |
| 办公自动化系统 | |
| 合同管理系统 | |
| 档案管理系统 | |
| P3E | |
| 统一通讯平台 | |
| 视频会议系统 | |
| 基建物流管理系统 | |
| 人力资源管理系统 | |
| 财务管理系统 | |
| 运营物流管理系统 | |
| 企业内部门户 | |
| 工程设计管理系统 | |
| 内部专家评标系统 | |
| 内部网站 | |
| 交流园地 | |
| WCM | |
| 外部网站 | |
| 内部网站后台 | |
| 外部网站后台 | |
| 外部网站招聘管理 | |
| 外部网站招投标管理 | |
| 资产标识码系统 | |
| 企业统计报表系统 | |
| 运营日报 | |
| MAXINMO系统 | |
| 施工调度管理系统 | |
| 运营调度命令发布系统 | |
| 票务管理系统 | |
| 工作证管理系统 | |
| 车站收益系统 |
30 问题结束代码
| 编号 | 代码 | 描述 |
| 1 | 根本解决 | 找出问题的根本原因，并得到解决方案，成功解决 |
| 2 | 变通方法 | 没有根本解决方案或目前没有办法实施根本解决方案，但有临时解决方案作为变通方法 |
| 3 | 无法解决 | 未找到问题的根本原因，没有解决方案，或目前无法实施解决方案，也无变通方法 |
| 4 | 取消 | 问题被拒绝、问题误报等 |
31 与其他流程间关系
32关键流程衡量指标
| 序号 | 衡量指标 | 指标计算说明 |
| 1 | 问题总数 | 数量：在问题单中根据以下条件过滤， |
| 【重复问题标记】为空 | ||
| 【问题结束代码】不等于‘取消’ | ||
| 【登记时间】在统计周期内 | ||
| 2 | 已关闭的问题按照问题结束代码的数量分布和各自比率 | 数量：在问题单中根据以下条件过滤， |
| 1. 【重复问题标记】为空 | ||
| 2. 【问题结束代码】分别等于‘根本解决’, ‘变通方法’, ‘无法解决’ | ||
| 3. 【登记时间】在统计周期内 | ||
| 比率：数量/已关闭问题数量 × 100 % | ||
| 3 | 未关闭的问题按照问题状态的数量分布和各自比率 | 数量：在问题单中根据以下条件过滤， |
| 1. 【重复问题标记】为空 | ||
| 2. 【问题结束代码】为空 | ||
| 3. 【问题状态】分别等于’已登记’, ‘分析中’, ‘已定位原因’, ‘已有解决方案’, ‘已提出变更请求’, ‘已回顾’ | ||
| 4. 【登记时间】在统计周期内 | ||
| 比率：数量/未关闭问题数量 × 100 % | ||
| 4 | 所有问题按照问题来源的数量分布和各自比率 | 数量：在问题单中根据以下条件过滤， |
| 1. 【重复问题标记】为空 | ||
| 2. 【问题来源】分别等于’事件管理流程’, ‘维护中提出’, ‘趋势分析’ | ||
| 3. 【登记时间】在统计周期内 | ||
| 比率：数量/问题总数 × 100 % | ||
| 5 | 问题成功解决率 | 数量：在关闭问题数量中，【问题结束代码】=‘根本解决’的问题个数 |
| 比率：数量 /已关闭问题数量 × 100 % | ||
| 6 | 变通方法解决率 | 数量：在关闭问题数量中，【问题结束代码】=‘变通方法’的问题个数 |
| 比率：数量 /已关闭问题数量 × 100 % | ||
| 7 | 未解决问题率 | 数量：在关闭问题数量中，【问题结束代码】=‘无法解决’的问题个数 |
| 比率：数量 /已关闭问题数量 × 100 % |
33问题目录列表
| 问题ID | 应用系统 | 问题分类 | 问题优先级 | 问题来源 | 问题处理专家 | 问题状态 | 问题描述 | 根本原因 | 变通方法 | 解决方案 | 实际诊断开始时间 |
指标说明： 反映在统计周期内的未关闭的问题列表，包括问题ID、问题所属系统类型、问题分 类、问题优先级、问题处理专家、问题状态，问题描述、根本原因、变通方法、解 决方案、问题结束代码及实际诊断开始时间
34 按照应用系统的问题统计报表
| 应用系统 | 问题总数 | |||||||||||||
| 事件管理流程 | 维护中提出 | 趋势分析 | 已登记 | 分析中 | 已定位原因 | 已有解决方案 | 已提出变更请求 | 已回顾 | 结束并关闭 | 关键 | 重要 | 普通 | ||
| SPS平台 | ||||||||||||||
| IT运维系统 | ||||||||||||||
| 办公自动化系统 | ||||||||||||||
| …… | ||||||||||||||
| 汇总 | ||||||||||||||
| 序号 | 指标名称 | 指标计算说明 |
| 1 | 问题总数 | 数量：在问题单中根据以下条件过滤 |
| 1.【重复问题标记】为空 | ||
| 2.【问题结束代码】不等于‘取消’ | ||
| 3.【登记时间】在统计周期内 | ||
| 2 | 事件管理流程 | 数量：在问题总数中，【问题来源】＝‘事件管理流程‘的问题个数 |
| 3 | 维护中提出 | 数量：在问题总数中，【问题来源】＝‘维护中提出‘的问题个数 |
| 4 | 趋势分析 | 数量：在问题总数中，【问题来源】＝‘趋势分析‘的问题个数 |
| 5 | 已登记 | 数量：在问题总数中，【问题状态】＝‘已登记‘的问题个数 |
| 6 | 分析中 | 数量：在问题总数中，【问题状态】＝‘分析中‘的问题个数 |
| 7 | 已定位原因 | 数量：在问题总数中，【问题状态】＝‘已定位原因‘的问题个数 |
| 8 | 已有解决方案 | 数量：在问题总数中，【问题状态】＝‘已有解决方案‘的问题个数 |
| 9 | 已提出变更请求 | 数量：在问题总数中，【问题状态】＝‘已提出变更请求‘的问题个数 |
| 10 | 已回顾 | 数量：在问题总数中，【问题状态】＝‘已回顾‘的问题个数 |
| 11 | 结束并关闭 | 数量：在问题总数中，【问题状态】＝‘结束并关闭‘问题个数 |
| 12 | 关键 | 数量：在问题总数中，【问题优先级】＝‘关键‘的问题个数 |
| 13 | 重要 | 数量：在问题总数中，【问题优先级】＝‘重要‘的问题个数 |
| 14 | 普通 | 数量：在问题总数中，【问题优先级】＝‘普通‘的问题个数 |