Wiki源代码06 ITIL问题管理流程设计文档
由 superadmin 于 2024/07/09, 14:53 最后修改
Show last authors
| author | version | line-number | content |
|---|---|---|---|
| 1 | [[返回本章节索引>>url: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/]] 阅读下一篇 | ||
| 2 | |||
| 3 | |||
| 4 | = **ITIL问题管理流程设计文档** = | ||
| 5 | |||
| 6 | |||
| 7 | === **1 概述** === | ||
| 8 | |||
| 9 | |||
| 10 | ===== **1.1 项目背景** ===== | ||
| 11 | |||
| 12 | 随着中国移动通信集团广东有限公司对 IT 管理工作的开展与深化,对网维中心 IT 管理部门的 IT 维护服务管理水平又提出了新的更高的要求,在认识到信息系统的对业务的推进作用后,网维支撑室着手了解、学习并参照国际上流行的 ITIL 运维管理模型对本单位内部开展运维管理。 | ||
| 13 | |||
| 14 | 本项目主要是将现有技术资源中的各类要素进行科学的组织管理,以达到合理调配人力资源、有效管理计算机设备、系统运行、提高管理工作水平的目标。 | ||
| 15 | |||
| 16 | 对于网维支撑室当前所面临的问题,因而如何进行全面而有效的 IT 管理已成为网维支撑室的主要工作。缺乏先进 IT 服务管理标准的 IT 管理只能是被动的、无序的、救火式的 IT服务管理,无法保障 IT 系统的无故障高效运行。只有利用先进的 IT 服务管理体系,对信息技术进行集中维护和集中管理,才能够形成主动的、具有优先级别及良好流程的、可管理的IT 服务模式,确保 IT 资源的高效运用、IT 服务的有效管理。 | ||
| 17 | |||
| 18 | 该改造过程不只是单纯地使用某种应用系统的改造,而是管理体制的改造,因而需要对IT 运营服务管理系统按照统一规划,分布实施的方式来推进,在内部逐步建立、推行一套先进的符合 ITIL 的 IT 运维管理体系。 | ||
| 19 | |||
| 20 | 本项目主要是对网维支撑室原有的 IT 服务管理进行符合 ITIL 标准的现状评估,根据评估的情况及结果对 IT 服务管理进行完善与改造,逐步建立 ITIL 模型中的服务台/事件管理、问题管理、变更管理、配置管理,做到“管理好 IT 基础设施”。 | ||
| 21 | |||
| 22 | |||
| 23 | ===== ===== | ||
| 24 | |||
| 25 | ===== **1.2 项目目标** ===== | ||
| 26 | |||
| 27 | 本文档是在《中国移动广东公司综合网维系统 IT 服务管理流程管理制度》基础上,结合广东移动网维支撑室维护管理的特点,制定的《问题管理流程详细设计文档》。 | ||
| 28 | |||
| 29 | 本文档具有如下目的: | ||
| 30 | |||
| 31 | * n 查明事件或问题产生的根本原因,制定解决方案和防止事件再次发生的预防措施。 | ||
| 32 | * 实施主动性问题管理,在事件发生之前发现和解决可能导致事件产生的潜在问题。 | ||
| 33 | * 确保问题已分派正确的支持人员,提高问题解决率。 | ||
| 34 | * 根据问题分类分级,科学合理地利用 IT 资源,降低 IT 支持成本。 | ||
| 35 | * 通过问题管理,提高 IT 服务质量和服务的可用性,提高客户服务满意度。 | ||
| 36 | |||
| 37 | |||
| 38 | ===== **1.3 适用范围** ===== | ||
| 39 | |||
| 40 | 本文档作为本次项目的问题管理流程详细设计的交付物,读者对象为与问题管理流程相关的所有技术与管理人员。 | ||
| 41 | |||
| 42 | |||
| 43 | ===== **1.4 相关术语** ===== | ||
| 44 | |||
| 45 | * ITIL(IT Infrastructure Library ) | ||
| 46 | |||
| 47 | 是英国政府在 1987 年制定的有关 IT 服务管理的方法论,现已成为事实上的 IT 管理标准。 | ||
| 48 | |||
| 49 | * 服务台(Service Desk) | ||
| 50 | |||
| 51 | 服务台从根本上来说是提供了用户和 IT 部门的唯一接口。此项功能常通过集中方式提供服务。服务台的根本目的是提供初始支持,并通过变通方法、解决方案或升级到一线、二线支持等手段帮助用户恢复到正常工作状态。 | ||
| 52 | |||
| 53 | * 事件管理( Incident Management) | ||
| 54 | |||
| 55 | ITIL 流程之一,事件管理负责解决所有的 IT 事件、问题和用户请求。它的目的是尽快恢复被中断或受到影响的 IT 服务,所以它的特点往往是以解决表征现象为目的,而不在于查找根本原因。 | ||
| 56 | |||
| 57 | * 问题管理(Problem Management) | ||
| 58 | |||
| 59 | ITIL 流程之一,问题管理负责解决重大紧急事件或具有相同症状的一组事件。它的目的是找出事件的根本原因,并通过解除该根本原因从而防止类似事件的再次发生。同时问题管理流程也负责预防事件的发生。 | ||
| 60 | |||
| 61 | * 配置管理(Configuration Management) | ||
| 62 | |||
| 63 | 本文中的所有信息均为广东省移动网管支撑室内部资料,未经许可,不得向外传播。 8 / 49ITIL 流程之一,配置管理负责描述,跟踪和汇报所有 IT 基础架构中的每一个设备或系统的管理流程。这些设备和系统被称为配置项(CI) 。每一个 CI 必须有效管理,跟踪和控制以支持移动的 IT 服务和基础设施成功运行。 | ||
| 64 | |||
| 65 | * 配置管理数据库(CMDB - Configuration Management Database) | ||
| 66 | |||
| 67 | 是在配置管理流程中用于记录企业所有 IT 相关配置项信息及其相互关系而建立的数据库。 | ||
| 68 | |||
| 69 | * 变更管理(Change Management) | ||
| 70 | |||
| 71 | ITIL 流程之一, 通过控制和管理 IT 相关的变更, 使变更对生产环境可能的影响和风险将到最小,从而提高 IT 环境的整体稳定性。 | ||
| 72 | |||
| 73 | |||
| 74 | === **2 问题管理流程设计** === | ||
| 75 | |||
| 76 | |||
| 77 | ===== **2.1 流程目的** ===== | ||
| 78 | |||
| 79 | 问题管理流程的根本目的是对发生在 IT 环境中的问题进行管理,找出产生问题的根本原因,并通过变更请求(RFC)、变通方法或建议方案等预防措施消除引起事件的深层次根源以防止事件再次发生,从而为客户提供更优质的 IT 服务,帮助网维中心的 IT 运维服务从被动管理向主导管理转变。 | ||
| 80 | |||
| 81 | |||
| 82 | ===== **2.2 问题来源** ===== | ||
| 83 | |||
| 84 | 问题来源包括但不限于以下情况: | ||
| 85 | |||
| 86 | * 一段时间内某一类事件频繁发生,占用大量人工。 | ||
| 87 | * 一段时间内某一设备频繁报同类事件单。 | ||
| 88 | * 对 IT 基础设施监控与分析,发现可能产生事件的薄弱环节。 | ||
| 89 | * 服务级别协议可能会受到的威胁。 | ||
| 90 | * 记录下来的事件不能与现有的问题或已知错误发生关联。 | ||
| 91 | * 客户直接提起的具有深层次原因的服务请求。 | ||
| 92 | |||
| 93 | 问题管理范围不涉及尚处于开发或测试环境中的问题。 | ||
| 94 | |||
| 95 | |||
| 96 | ===== **2.3 与其他流程的关系** ===== | ||
| 97 | |||
| 98 | 问题管理与事件管理、变更管理、配置管理、能力管理、可用性管理和服务级别管理都有关联关系,存在以下关联原则。 | ||
| 99 | |||
| 100 | ★和事件管理的关联 | ||
| 101 | |||
| 102 | * 事件管理对问题管理来说是一个重要的信息提供者,多次重复发生的事件在恢复服务后,都应创建问题。 | ||
| 103 | * 问题管理对故障进行分析,找出问题的根本原因及解决方案,并与事件关联,为事件管理提供有效的事件解决方案或变通办法。 | ||
| 104 | * 当明确了问题的原因并定义了一个已知错误后,也可提供事件管理一个临时修复办法以阻止事件的再次发生并降低事件的影响。 | ||
| 105 | |||
| 106 | ★和变更管理的关联 | ||
| 107 | |||
| 108 | * 问题处理过程中,如果需要进行变更,必须按照变更管理的流程,提交变更申请。 | ||
| 109 | * 变更管理负责控制执行变更。变更完成后,可能产生一个实施后评审,如果变更成功,所有相关的事件和问题记录(包括已知错误)都可以终止了。 | ||
| 110 | |||
| 111 | ★和配置管理的关联 | ||
| 112 | |||
| 113 | * 问题处理过程中,可以通过配置管理查询相关的配置项信息。 | ||
| 114 | * 问题处理过程中,如果可以将根本原因定位到某个配置项,则必须将问题与该配置项关联。 | ||
| 115 | |||
| 116 | |||
| 117 | ===== **2.4 关键角色、职责定义** ===== | ||
| 118 | |||
| 119 | 流程的实现是通过不同的流程角色以及其所赋有的职责来实现的,因此流程的每一个角色可以被定义为一系列职责的集合,在实际的管理操作中,不同的人员将被赋予不同的职责,也可能一个人被赋予多个职责。 | ||
| 120 | |||
| 121 | 问题管理流程的角色为:问题管理流程负责人、问题经理、问题专家 | ||
| 122 | |||
| 123 | |||
| 124 | ====== **2.4.1 流程负责人** ====== | ||
| 125 | |||
| 126 | **★职责:** | ||
| 127 | |||
| 128 | 问题管理流程负责人从总体上对问题管理流程的设计、实施、执行及优化负责,确保问题管理流程被正确的执行。当流程不能够适应实际情况时,流程负责人必须及时地进行分析诊断,找出缺陷,进行改进,从而实现问题管理流程的可持续提高。 | ||
| 129 | |||
| 130 | * 确保问题管理流程的设计、实施及执行,能够取得管理层的参与和支持。 | ||
| 131 | * 确保问题管理流程符合网维中心实际状况和网维中心 IT 服务发展思路。 | ||
| 132 | * 整体上对问题管理流程负责,建立流程的实施、评估和持续优化机制。 | ||
| 133 | * 确保问题管理流程的有效执行,定期评估流程,制定流程持续改进计划。 | ||
| 134 | * 保持与其他流程负责人的定期沟通。 | ||
| 135 | |||
| 136 | **★技能要求:** | ||
| 137 | |||
| 138 | * 深刻理解问题管理流程 | ||
| 139 | * 充分理解 IT 服务管理的其他流程,能够进行流程接口设计 | ||
| 140 | * 能够很好地理解业务对于问题管理的需求 | ||
| 141 | * 对质量控制与保障有深入的了解 | ||
| 142 | * 有决策权,能够确保问题管理流程设计要求在实施项目中得到贯彻和执行 | ||
| 143 | |||
| 144 | ★人员安排说明: | ||
| 145 | |||
| 146 | * 通常由负责决策权的人担任,一般为 IT 部门相关领导 | ||
| 147 | |||
| 148 | |||
| 149 | ====== **2.4.2 问题经理** ====== | ||
| 150 | |||
| 151 | 问题经理主要负责问题解决过程中的分派、协调和监控,以及问题最终关闭。 | ||
| 152 | |||
| 153 | ★职责: | ||
| 154 | |||
| 155 | * 定期组织问题专题会,组织问题专家对历史事件记录、各管理报告进行趋势分析,发现潜在问题。 | ||
| 156 | * 定期组织问题专题会,组织问题专家识别来自事件升级的问题、日常维护发现的问题和历史遗留的问题。 | ||
| 157 | * 确认和审核提出的问题,并进行问题分派。 | ||
| 158 | * 监督问题的诊断、分析和处理过程。 | ||
| 159 | * 必要时与问题申告者沟通问题的相关信息。 | ||
| 160 | * 必要时协调所需资源。 | ||
| 161 | * 定期产生问题管理报告,提供管理层正确的决策信息。 | ||
| 162 | * 问题解决并关闭前,监督问题专家将其文档化,并申请纳入知识库中。 | ||
| 163 | * 协助发现问题管理流程的不足,提出流程改进建议,并向问题管理流程负责人汇报。 | ||
| 164 | |||
| 165 | ★技能要求: | ||
| 166 | |||
| 167 | * 了解技术架构和技术环境 | ||
| 168 | * 处理纠纷的能力 | ||
| 169 | * 深刻了解问题管理流程 | ||
| 170 | * 较强的领导能力 | ||
| 171 | |||
| 172 | ★人员安排说明: | ||
| 173 | |||
| 174 | * 网维中心支撑室 IT 管理的的资深人员 | ||
| 175 | |||
| 176 | |||
| 177 | ====== **2.4.3 问题专家** ====== | ||
| 178 | |||
| 179 | ★职责: | ||
| 180 | |||
| 181 | * 定期参加问题专题会,回顾事件管理、能力管理、可用性管理等流程的管理报告,进行事件趋势分析,发现潜在问题。 | ||
| 182 | * 定期参加问题专题会,识别来自事件升级的问题、日常维护发现的问题和历史遗留的问题。 | ||
| 183 | * 对于分派给自己的问题,负责问题的控制,对问题进行分析、诊断,确定问题的根本原因,形成已知错误。 | ||
| 184 | * 负责错误的控制,对已知错误进行分析诊断,研究可行的解决方案或变通方法。 | ||
| 185 | * 负责解决方案实施计划的制定与落实,并负责验证解决方案的实施效果,确保问题的根本解决。 | ||
| 186 | * 负责记录问题解决的相关信息,确保问题描述准确、问题根本原因正确、解决方案完整。 | ||
| 187 | * 编制问题分析报告,包括问题描述、问题根本原因、解决方案、实施效果、经验总结等。 | ||
| 188 | * 及时与问题经理沟通,通报问题实施的进度、困难和结果。 | ||
| 189 | * 负责问题的根本原因、问题的解决方案的整理与文档化,为申请纳入知识库做准备。 | ||
| 190 | |||
| 191 | ★技能要求: | ||
| 192 | |||
| 193 | * 熟悉自己业务/技术范围内的技术平台和技术环境. | ||
| 194 | * 很强的问题分析、诊断能力和解决问题的能力 | ||
| 195 | * 拥有一定的沟通和管理能力,对于涉及多个问题处理专家协同解决的问题能够和相关人员进行沟通并最终解决问题 | ||
| 196 | |||
| 197 | ★人员安排说明: | ||
| 198 | |||
| 199 | * 技术专家的人担任 | ||
| 200 | |||
| 201 | |||
| 202 | ====== **2.4.4 实际岗位与方案角色的映射 ** ====== | ||
| 203 | |||
| 204 | |||
| 205 | **[[image:微信图片_20240709140406.png]]** | ||
| 206 | |||
| 207 | |||
| 208 | **[[image:微信图片_20240709140604.png]]** | ||
| 209 | |||
| 210 | |||
| 211 | ===== **2.5 执行原则** ===== | ||
| 212 | |||
| 213 | |||
| 214 | ====== **2.5.1 常规原则** ====== | ||
| 215 | |||
| 216 | * 要建立独立的问题管理流程。在整个网维中心范围内,应该与事件管理流程相对独立,事件经理与问题经理应尽可能的由不同的人员担任。 | ||
| 217 | * 应该每半年对问题管理流程的流程关键衡量指标、流程执行效率、流程支撑工具有效性等进行回顾,以改进和优化流程。 | ||
| 218 | * 应该每月定期回顾和产生问题管理报表,对没有解决的问题,应定期举行问题管理专题会评估这些问题。 | ||
| 219 | * 问题经理应定期跟踪与检查问题的解决状态。 | ||
| 220 | * 已明确的问题根本原因和问题解决方案应申请纳入知识库。 | ||
| 221 | * 问题的分类与事件的分类应尽量保持一致。 | ||
| 222 | |||
| 223 | ====== ====== | ||
| 224 | |||
| 225 | ====== **2.5.2 重复问题原则** ====== | ||
| 226 | |||
| 227 | 重复问题存在两种处理情况,具体处理方式如下: | ||
| 228 | |||
| 229 | 一是指经过分析之后,根本原因相同的问题。例如:问题专家提出了几个问题,但是经过分析之后,发现这几个问题的根本原因是相同的,则这几个问题就可以定义为重复问题。 | ||
| 230 | |||
| 231 | 对于重复问题需要进行标志(重复问题标记上做重复标识),将相关问题记录进行关联,重复问题直接关闭。同时,当问题解决时,需进行回顾。 | ||
| 232 | |||
| 233 | 二是指发现重复的问题,但是有新的解决方案。此时需要将相关的问题记录进行关联,并记录新的解决方案。 | ||
| 234 | |||
| 235 | |||
| 236 | ====== **2.5.3 问题重开原则** ====== | ||
| 237 | |||
| 238 | 已关闭的问题允许重开。当发起的问题已找到问题根本原因,但无法获得解决方案而关闭后,如果需要重新解决该问题,需重新创建一个新的问题申请单,走问题管理流程。 | ||
| 239 | |||
| 240 | |||
| 241 | ====== **2.5.4 问题关闭原则** ====== | ||
| 242 | |||
| 243 | 通常,问题在实施解决方案之后,需要经过一段时间的回顾,由问题专家回顾解决方案是否达到了预期的效果,如果达到预期效果,则由问题经理确认问题信息记录完整,关闭问题。 | ||
| 244 | |||
| 245 | |||
| 246 | ====== **2.5.5 趋势分析原则** ====== | ||
| 247 | |||
| 248 | 问题经理定期组织问题专题会,对事件历史记录及管理报告进行趋势分析: | ||
| 249 | |||
| 250 | * 参加者应包括事件经理及问题专家 | ||
| 251 | * 会议应定期组织 | ||
| 252 | * 应定义趋势分析规则 | ||
| 253 | |||
| 254 | |||
| 255 | ====== **2.5.6 入口原则** ====== | ||
| 256 | |||
| 257 | 问题管理流程运作过程中需要输入的信息包括: | ||
| 258 | |||
| 259 | * 事件管理流程提供的相关事件信息,以及事件直接升级为问题的描述信息。 | ||
| 260 | * 事件管理、可用性管理和能力管理定期提供的各类管理报告,是问题趋势分析的基础与依据。 | ||
| 261 | * 问题处理过程中,与配置管理数据库(CMDB)相关的配置信息。 | ||
| 262 | * 知识库提供的已知错误及解决方案信息 | ||
| 263 | * 供应商提供的其产品信息,包括产品技术细节和产品本身存在的已知错误 | ||
| 264 | * 服务目录和服务级别协议(SLA)。 | ||
| 265 | |||
| 266 | |||
| 267 | [[image:微信图片_20240709141109.png]] | ||
| 268 | |||
| 269 | [[image:微信图片_20240709141156.png]] | ||
| 270 | |||
| 271 | |||
| 272 | ====== **2.5.7 出口原则** ====== | ||
| 273 | |||
| 274 | 问题管理流程输出的信息包括: | ||
| 275 | |||
| 276 | * 发现的已知错误,以及解决已知错误的解决方案或变通方案。 | ||
| 277 | * 问题解决过程中,涉及变更时需向变更管理流程提出变更申请。 | ||
| 278 | * 最新的问题信息,主要更新与已知错误、解决方案和应急措施相关的信息。 | ||
| 279 | * 根据问题处理结果,形成相关的问题分析报告。 | ||
| 280 | * 根据问题管理情况,定期提供问题管理的相关分析报告。 | ||
| 281 | |||
| 282 | |||
| 283 | [[image:微信图片_20240709141403.png]] | ||
| 284 | |||
| 285 | [[image:微信图片_20240709141434.png]] | ||
| 286 | |||
| 287 | |||
| 288 | ===== **2.6 流程相关定义** ===== | ||
| 289 | |||
| 290 | 问题表单 | ||
| 291 | |||
| 292 | [[image:微信图片_20240709141543.png||height="764" width="553"]] | ||
| 293 | |||
| 294 | |||
| 295 | [[image:微信图片_20240709141612.png||height="904" width="557"]] | ||
| 296 | |||
| 297 | |||
| 298 | [[image:微信图片_20240709141714.png||height="754" width="470"]] | ||
| 299 | |||
| 300 | |||
| 301 | [[image:微信图片_20240709141754.png||height="283" width="473"]] | ||
| 302 | |||
| 303 | |||
| 304 | ===== **2.7 问题流程概要设计** ===== | ||
| 305 | |||
| 306 | |||
| 307 | ====== **2.7.1 流程描述** ====== | ||
| 308 | |||
| 309 | 此流程是问题管理的主流程,它涵盖了问题识别与记录、问题审核与分派、问题分析与诊断、问题解决、问题回顾、问题关闭等子流程。问题管理流程主要是为了帮助找出事件发生的潜在问题与根本原因,从而进一步提高 IT 服务的质量与可用性,降低对于业务的不利影响。 | ||
| 310 | |||
| 311 | 2.7.2 流程图 | ||
| 312 | |||
| 313 | [[image:微信图片_20240709141854.png]] | ||
| 314 | |||
| 315 | |||
| 316 | ====== **2.7.3 流程说明** ====== | ||
| 317 | |||
| 318 | |||
| 319 | **[[image:微信图片_20240709141932.png||height="116" width="595"]]** | ||
| 320 | |||
| 321 | **[[image:微信图片_20240709142001.png||height="867" width="599"]]** | ||
| 322 | |||
| 323 | |||
| 324 | [[image:微信图片_20240709142232.png||height="798" width="549"]] | ||
| 325 | |||
| 326 | |||
| 327 | [[image:微信图片_20240709142400.png||height="795" width="547"]] | ||
| 328 | |||
| 329 | |||
| 330 | [[image:微信图片_20240709142639.png||height="781" width="536"]] | ||
| 331 | |||
| 332 | |||
| 333 | [[image:微信图片_20240709142719.png||height="505" width="541"]] | ||
| 334 | |||
| 335 | |||
| 336 | ===== **2.8 流程详细设计** ===== | ||
| 337 | |||
| 338 | ====== **2.8.1 (300.1):问题识别与记录** ====== | ||
| 339 | |||
| 340 | **2.8.1.1 子流程描述** | ||
| 341 | |||
| 342 | 该子流程是问题管理流程的起始点,问题经理定期组织问题专家,对事件升级的问题、日常维护发现的问题、历史已知错误而未解决的问题进行问题识别与分析,同时,组织问题专家根据各类管理分析报告进行各种事件的趋势分析,进而找出有待解决的潜在问题。问题经理通过定期组织问题专题会,识别与判断所发起的问题是否为有效问题和新问题,同时,为问题的解决收集与汇总事件关联信息和配置关联信息。 | ||
| 343 | |||
| 344 | **2.8.1.2 流程图** | ||
| 345 | |||
| 346 | **[[image:微信图片_20240709143216.png]]** | ||
| 347 | |||
| 348 | |||
| 349 | **2.8.1.3 流程说明** | ||
| 350 | |||
| 351 | **[[image:微信图片_20240709143253.png||height="208" width="627"]]** | ||
| 352 | |||
| 353 | **[[image:微信图片_20240709143321.png||height="846" width="632"]]** | ||
| 354 | |||
| 355 | |||
| 356 | [[image:微信图片_20240709143403.png||height="605" width="627"]] | ||
| 357 | |||
| 358 | |||
| 359 | ====== **2.8.2 (300.2):问题分派** ====== | ||
| 360 | |||
| 361 | **2.8.2.1 子流程描述** | ||
| 362 | |||
| 363 | 该子流程是通过判断问题的重复性,将问题有效分派适合的责任人识别与解决问题的管理流程。问题经理通过分析问题信息,判断问题是否为一个重复问题,若是重复问题,则直接标注为重复问题,不再分派;若不是重复问题,则确认问题的优先级和分类,并分派给适合的问题专家处理。问题专家如果无法接受任务分派,则可退回问题经理重新分派。 | ||
| 364 | |||
| 365 | **2.8.2.2 流程图** | ||
| 366 | |||
| 367 | **[[image:微信图片_20240709143643.png]]** | ||
| 368 | |||
| 369 | **2.8.2.3 流程说明** | ||
| 370 | |||
| 371 | [[image:微信图片_20240709143719.png||height="303" width="522"]] | ||
| 372 | |||
| 373 | [[image:微信图片_20240709143749.png||height="714" width="516"]] | ||
| 374 | |||
| 375 | |||
| 376 | ====== **2.8.3 (300.3):问题分析与诊断** ====== | ||
| 377 | |||
| 378 | **2.8.3.1 子流程描述** | ||
| 379 | |||
| 380 | 该子流程是为了分析与诊断问题,确定问题根本原因,找出已知错误的管理过程,其目标是要明确问题的根本原因。问题专家在接到问题经理分派的问题后,借助知识库分析与诊断问题原因,确认问题是否为已知错误,或定位问题根本原因。如果可以定位问题的根本原因,则要记录问题原因信息,并标注问题为已知错误,转入“问题解决”子流程;如果问题专家能力不够或问题过于复杂,无法定位问题的根本原因,则可向问题经理申请其他资源的支持。 | ||
| 381 | |||
| 382 | **2.8.3.2 流程图** | ||
| 383 | |||
| 384 | **[[image:微信图片_20240709144021.png]]** | ||
| 385 | |||
| 386 | |||
| 387 | **2.8.3.3 流程说明** | ||
| 388 | |||
| 389 | **[[image:微信图片_20240709144057.png||height="232" width="531"]]** | ||
| 390 | |||
| 391 | **[[image:微信图片_20240709144125.png||height="784" width="524"]]** | ||
| 392 | |||
| 393 | |||
| 394 | **[[image:微信图片_20240709144158.png||height="783" width="524"]]** | ||
| 395 | |||
| 396 | |||
| 397 | **[[image:微信图片_20240709144224.png||height="197" width="517"]]** | ||
| 398 | |||
| 399 | |||
| 400 | ====== **2.8.4 (300.4):问题解决** ====== | ||
| 401 | |||
| 402 | **2.8.4.1 子流程描述** | ||
| 403 | |||
| 404 | 该子流程是针对已诊断出的已知错误,提出并实施可行的解决方案与措施的管理过程。 | ||
| 405 | |||
| 406 | 问题专家根据已判断的问题的根本原因,尝试查找并提出解决方案或变通方法,并制定计划与实施。如果问题专家无法找到解决方案,可向问题经理申请其他资源的支持;如果问题解决方案涉及变更,则在方案实施过程中,需提交变更申请单,走变更管理流程。 | ||
| 407 | |||
| 408 | **2.8.4.2 流程图** | ||
| 409 | |||
| 410 | **[[image:微信图片_20240709144318.png]]** | ||
| 411 | |||
| 412 | |||
| 413 | **2.8.4.3 流程说明** | ||
| 414 | |||
| 415 | |||
| 416 | **[[image:微信图片_20240709144612.png||height="221" width="524"]]** | ||
| 417 | |||
| 418 | **[[image:微信图片_20240709144634.png||height="753" width="516"]]** | ||
| 419 | |||
| 420 | |||
| 421 | [[image:微信图片_20240709144707.png||height="742" width="511"]] | ||
| 422 | |||
| 423 | |||
| 424 | [[image:微信图片_20240709144738.png||height="532" width="506"]] | ||
| 425 | |||
| 426 | |||
| 427 | ====== **2.8.5 (300.5):问题回顾** ====== | ||
| 428 | |||
| 429 | **2.8.5.1 子流程描述** | ||
| 430 | |||
| 431 | 该子流程是指问题已有解决方案,并按计划实施之后,验证解决方案有效性的管理过程。 | ||
| 432 | |||
| 433 | 通过与用户或问题发起者的沟通与评价,如果问题解决方案并没有真正解决问题,则需返回问题分析与诊断子流程,重新分析问题的根本原因;如果问题得到根本解决,则对本次问题的解决形成文档报告。 | ||
| 434 | |||
| 435 | **2.8.5.2 流程图** | ||
| 436 | |||
| 437 | **[[image:微信图片_20240709144826.png]]** | ||
| 438 | |||
| 439 | |||
| 440 | **2.8.5.3 流程说明** | ||
| 441 | |||
| 442 | **[[image:微信图片_20240709144917.png||height="323" width="569"]]** | ||
| 443 | |||
| 444 | **[[image:微信图片_20240709144902.png||height="494" width="566"]]** | ||
| 445 | |||
| 446 | ====== **2.8.6 (300.6):问题关闭** ====== | ||
| 447 | |||
| 448 | **2.8.6.1 子流程描述** | ||
| 449 | |||
| 450 | 问题关闭子流程是问题管理流程的最后阶段,需要在关闭问题前完成必要的收尾工作。 | ||
| 451 | |||
| 452 | 问题的关闭由问题经理执行的,在问题关闭阶段,问题经理应对问题的记录信息进行回顾总结,确保信息的完整性与准确性。如果问题无法解决,需要通过新项目的研究,则应建立项目需求书,转相关项目管理部门处理。 | ||
| 453 | |||
| 454 | **2.8.6.2 流程图** | ||
| 455 | |||
| 456 | **[[image:微信图片_20240709145025.png]]** | ||
| 457 | |||
| 458 | |||
| 459 | **2.8.6.3 流程说明** | ||
| 460 | |||
| 461 | **[[image:微信图片_20240709145058.png||height="146" width="586"]]** | ||
| 462 | |||
| 463 | **[[image:微信图片_20240709145110.png||height="815" width="584"]]** | ||
| 464 | |||
| 465 | **[[image:微信图片_20240709145145.png||height="571" width="568"]]** | ||
| 466 | |||
| 467 | |||
| 468 | ===== **2.9 关键绩效指标(KPI)** ===== | ||
| 469 | |||
| 470 | 为了较好地控制流程的质量,必须为流程设置衡量指标,通过对指标的分析,可以有效地对流程的运行情况进行监控和改进。 | ||
| 471 | |||
| 472 | 以下为问题管理流程的关键衡量指标: | ||
| 473 | |||
| 474 | |||
| 475 | [[image:微信图片_20240709145253.png]] |