Version 2.1 by superadmin on 2024/07/09, 13:06
Show last authors
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.1 流程目的** ===
8
9
10 问题管理流程是一个化被动为主动的管理流程，重点是通过解决事件的根本原因来达到减少生产环境中突发事件的数量。因此，问题管理流程不仅针对已经发生的问题，更主要是找出潜在的问题并及时解决。
11
12 综上，问题管理流程的目的包括：
13
14 1. 消除或减少生产环境中事件发生的数量和严重程度
15 1. 防止类似事件再次发生
16 1. 提高IT服务的可靠性和降低IT支持成本
17
18
19 === **1.2 流程主要内容** ===
20
21
22 问题管理流程着重于消除事件或减少事件发生，确定事件的根本原因。主要活动包括分析事件、找出问题、分派问题、确定根本原因以及找出解决方案、回顾及关闭，以消除事件或在其发生时降低对用户或业务的影响。其主要内容如下：
23
24 * 记录问题
25
26 IT部门根据问题单填写规范，生成问题单并将相关信息（如：事件单、变更单等）关联至问题单并启动问题管理流程。
27
28 * 分派问题 
29
30 问题经理判定问题属于基础架构范畴还是属于业务范畴后确定合适的问题专家并分派。
31
32 * 诊断问题并提供解决方案
33
34 问题专家调查分析问题、找出其根本原因后，制定解决方案、变通方法或提出预防性措施，旨在解决问题或问题复发时最大程度弱化对业务的影响。
35
36 * 开发、确认、实施解决方案
37
38 问题专家根据解决方案、变通方法或预防性措施开展准备工作、制定实施计划。若实施涉及变更，则需要启动变更管理流程。
39
40 * 回顾问题
41
42 在实施解决方案后，问题专家观察实施结果并决定是否进入问题总结和关闭阶段。
43
44 * 总结和关闭问题 
45
46 问题经理先根据实际需要和相关问题专家一起总结问题处理过程、问题解决方案等工作项，旨在确认问题已得到解决并问题信息记录完整后关闭问题单，同时为后续的问题处理积累经验。
47
48
49
50 === **1.3 与其他流程的关系** ===
51
52
53 ★和事件管理流程的关联
54
55 * 所有事件结束代码为“使用变通方法解决”和“无法重现”的事件原则上在事件关闭前都需要升级为问题
56 * 所有一级事件在事后补单时，原则上在关闭前都需要升级为问题。
57 * 定期分析突发事件是否有趋势或规律，以此找出潜在问题并创建问题单（问题单必须和所有相关事件单建立关联）
58
59 ★和变更管理流程的关联
60
61 * 问题处理过程中，如果需要对系统进行变更，必须按照变更管理的定义，提交变更请求单（变更单必须和问题单建立关联），变更完成后，继续问题单的处理
62
63 ★和配置和资产管理的关联
64
65 * 问题处理过程中，可以通过配置和资产管理流程查询相关的配置项信息
66 * 问题处理过程中，如果可以将根本原因定位到某个配置项，则必须将问题单与该配置项关联
67
68
69 === **1.4 流程范围** ===
70
71
72 问题管理流程的范围是对IT生产环境中发生的问题进行管理，以采取主动性预防措施来降低事件数量。
73
74 不包括：
75
76 * 处于开发环境的系统和应用
77
78
79 === **1.5 流程执行原则** ===
80
81
82 ===== **1.5.1 常规原则** =====
83
84 * 事件处理过程中故障消除、业务恢复后如需后续分析处理，应转问题管理流程
85 * 应该每月定期回顾和产生问题管理报表，对没有解决的问题，应该举行定期的问题管理会议对这些问题进行评估
86 * 应该每半年对问题管理流程的关键衡量指标、流程执行效率、流程支撑工具有效性等进行回顾，以改进和优化流程
87
88
89 ===== **1.5.2 所有权原则** =====
90
91 所有权原则用来确保每个问题在任何时段都有适当的人员负责，问题经理是每个问题的负责人。有效管理问题的前提是必须确保每个问题在任何时段都有适当的人员负责。
92
93 下表是各角色在各环节中承担不同责任的RACI模型。
94
95 | |(((
96 **问题经理**
97
98 **(职能经理)**
99 )))|(((
100 **问题专家**
101
102 **(员工)**
103 )))|(((
104 **问题相关厂商**
105
106 **(厂商)**
107 )))
108 |问题确定与记录|R|A|R/C
109 |问题确认与分派|A|C/I|I
110 |分析并诊断问题/提供变通方法|C/I|A/R|R/C
111 |开发、确认、实施解决方案|C/I|A/R|R/C
112 |问题监控|A|R|I
113 |问题回顾|R/C|A|C/I
114 |问题关闭|A|R/C|C/I
115 |(% colspan="4" %)RACI模型说明 A: 负全责; R: 有义务; C: 提建议; I: 需知会
116
117 ===== **1.5.3 问题流程启动原则** =====
118
119 1. 所有事件结束代码为“使用变通方法解决”和“无法重现”的事件原则上在事件关闭前都需要升级为问题
120 1. 所有一级事件在事后补单时，原则上在关闭前都需要升级为问题。
121 1. 定期分析突发事件是否有趋势或规律，以此找出潜在问题并创建问题单（问题单必须和所有相关事件单建立关联）
122 1. 因为变更实施导致的突发事件，可直接发起问题管理流程
123 1. 在会议上，相关人员提出需要按问题管理流程进行处理的事项，可直接发起问题管理流程
124 1. IT人员在日常运维工作中，应主动发现潜在问题并在Agile-ITSM管理系统中开问题单
125
126
127 ===== **1.5.4 转派原则** =====
128
129 问题专家认为问题分派错误或工作负载已满无法抽出足够时间排查问题时，可与问题经理线下沟通后，再由其转派给另一问题专家。为确保问题单不被过于频繁的相互转派、以至于无法在规定时间内得到解决，应当尽量减少问题单转派的几率。
130
131
132 ===== **​​​​​​​1.5.5 问题回退原则** =====
133
134 在问题回顾过程中，问题专家发现问题并未解决。此时，他可以选择将问题回退至问题处理环节或回退至问题经理请他协调其他专家一起处理该问题。
135
136
137 ===== **​​​​​​​1.5.6 问题关闭原则** =====
138
139 问题单在实施了解决方案之后并通过问题专家自己的回顾后，由问题经理根据实际需求负责组织问题专家参与确认解决方案是否达到了预期的效果，如果成功的实施，由问题经理确认问题信息记录完整后关闭问题。
140
141
142 ===== **​​​​​​​1.5.7 问题单重开原则** =====
143
144 已关闭的问题单不允许重开。如果问题重复发生，则创建一个新的问题单。
145
146
147 ===== **​​​​​​​1.5.8 趋势分析原则** =====
148
149 问题经理定期组织会议，对所处理事件历史记录进行趋势分析：
150
151 * 参加者应包括事件经理及问题专家
152 * 会议定期组织
153 * 定义趋势分析规则
154
155
156 === **1.6 流程相关定义** ===
157
158
159 ===== **1.6.1 问题信息项** =====
160
161 问题单包含如下信息项：
162
163 |序号|信息项|描述
164 |1|工单号|为每个问题分配一个唯一的序列号（系统自动产生）
165 |2|登记人|系统自动生成
166 |3|登记时间|生成问题记录的时间（系统自动产生）
167 |4|问题申请人|系统内查询并选择
168 |5|电话|根据问题申请人自动产生
169 |6|电子邮件|根据问题申请人自动产生
170 |7|申请人部门|根据问题申请人自动产生
171 |8|申请人工号|根据问题申请人自动产生
172 |9|地点|记录问题发生的地点（手工填写）
173 |10|问题来源|“事件”、“会议”、“性能”、“容量”、“趋势分析”、“变更”、“其他”、“监控”、“应用Bug”、“任务”
174 |11|优先级|参见“优先级”
175 |12|服务类别|参见“事件管理流程”的同类定义
176 |13|服务子类|参见“事件管理流程”的同类定义
177 |14|影响范围|“所有用户”、“多个用户”、“单个用户或无明显影响”
178 |15|问题描述|详细描述问题内容（手工填写）
179 |16|是否找到根本原因|“是”和“否”
180 |17|重复问题标记|“是”和“否”（重复问题指经问题专家分析判断后某几个问题是同一个根本原因，则重负问题标记选择为“是”）
181 |18|实际开始时间|手动填写
182 |19|实际结束时间|手动填写
183 |20|根本原因|详细记录问题产生的根本原因（手工填写）
184 |21|解决方案|问题解决方案的详细描述（手工填写）
185 |22|无法解决原因|解释问题无法解决的原因（手工填写）
186 |23|结束代码|“变更解决”、“变通解决”、“无法解决”、“取消”
187 |24|关联配置项|记录问题的配置项代码（手工填写）
188 |25|关联的事件单号|记录引发该问题的事件单号（手工填写）
189 |26|关联的变更单号|记录由问题发变更时，关联的变更单号（手工填写）
190 |27|关闭时间|当问题状态更新为“结束并关闭“的时间（手工填写）
191 |28|是否已知错误|“是”和“否”（已知错误指该问题已存在与知识库中，则是否已知错误选择为“是”，未来可与知识管理流程做集成）
192
193 表1-1问题信息项
194
195
196 ===== **​​​​​​​1.6.2 问题优先级** =====
197
198 问题的优先级是问题处理专家解决问题的参照标准，对于优先级为一级的问题，问题经理应该优先协调资源进行这些问题的解决。问题优先级将遵从事件优先级定义，确保问题优先级符合实际工作需要，定义如下：
199
200 |(% colspan="2" rowspan="2" %)问题优先级判定说明|(% colspan="3" %)影响范围
201 |所有用户|1个以上用户|1个用户或无明显影响
202 |(% colspan="2" %)业务关键性|关键（2）|重要（1）|一般（0）
203 |关键业务|关键（2）|一级|二级|四级
204 |重要业务|重要（1）|二级|三级|四级
205 |一般业务|一般（0）|三级|四级|五级
206
207 表1-2问题优先级
208
209
210 ===== **​​​​​​​1.6.3 问题响应时限和诊断时限** =====
211
212 在问题处理过程中，对于一个问题有响应时限和诊断时限。一方面，需要问题专家在响应问题的时候有时间的概念；另一方面，也需要问题专家在分析、解决问题的时候有时间的概念，并要求问题经理必须实时地督促问题的解决；如果该问题的响应或解决超过了时限，问题专家需要及时线下通告问题经理，由问题经理酌情协调其他问题专家协同解决。
213
214 问题优先级对应的响应时限和诊断时限参考下表：
215
216 |问题级别|响应时限|分析时限
217 |1级问题|5分钟|48小时
218 |2级问题|20分钟|72小时
219 |3级问题|20分钟|120小时
220 |4级问题|30分钟|168小时
221 |5级问题|60分钟|192小时
222
223 表1-3问题响应时限和诊断时限
224
225
226 ===== **​​​​​​​1.6.4 服务类别、服务子类** =====
227
228 请参照事件管理流程说明书的“服务类别、服务子类”章节。
229
230
231 === **​​​​​​​1.7 流程概要设计** ===
232
233 **[[image:微信图片_20240709130336.png]]**
234
235
236 问题管理流程文字说明：
237
238 |序号|步骤名称|责任人|说明
239 |300.1|问题记录|问题专家|问题专家是任意一名IT部门的同事。问题的记录可以通过事件管理流程直接升级或者直接开单。
240 |300.2|问题确认分派|问题经理|问题经理判断问题属于基础架构范畴还是业务应用范畴，然后选择合适的问题专家。
241 |300.3|诊断问题并提供解决方案|问题专家|问题专家诊断问题找出根本原因后提出解决方案、变通方法或预防性措施。
242 |300.4|开发、确认、实施解决方案|问题专家|问题专家开展解决问题的准备工作，制定实施计划等。若解决问题涉及变更，则启动变更管理流程。完成所有准备工作后，实施解决方案。
243 |300.5|问题回顾|问题专家|问题专家观察解决方案实施结果，问题是否已被解决。若问题复发，则问题专家可以选择将流程节点回退到300.3或300.2。若问题确认已解决，问题专家完成问题回顾。
244 |300.6|问题总结与关闭|问题经理|问题经理根据实际需要召集问题专家或点对点与问题专家一起总结该问题的各相关工作环节，并确认问题已解决同时问题信息记录完整可关闭问题
245
246
247 === ===
248
249 === **1.8 关键角色、职责定义** ===
250
251
252 问题管理流程主要包括问题管理流程负责人、问题经理和问题专家四个角色。
253
254
255 ===== **​​​​​​​1.8.1 问题管理流程负责人** =====
256
257 问题管理流程负责人从总体上对问题管理流程的设计、实施、执行及优化负责，确保问题管理流程在业务支持中心范围内被正确的执行。当流程不能够适应业务支持中心的情况时，流程负责人必须及时的对此进行分析、找出缺陷、进行改进，从而实现可持续提高。
258
259 职责:
260
261 1. 确保问题管理流程的设计、实施及执行，能够取得管理层的参与和支持
262 1. 确保问题管理流程符合公司实际状况和公司 IT发展战略
263 1. 整体上对问题管理流程负责，建立流程实施、评估和持续优化机制
264 1. 确保问题管理流程的有效执行，定期评估流程，制定流程改进计划
265 1. 保持与其他流程负责人的定期沟通
266
267 技能要求：
268
269 1. 深刻理解问题管理流程
270 1. 充分理解业务支撑网维护管理流程梳理项目的其他流程，能够进行流程接口设计
271 1. 能够很好地理解业务对于问题管理的需求
272 1. 对质量控制与保障有很深入的了解
273 1. 有决策权，能够确保问题管理流程设计要求在实施项目中得到贯彻和执行
274 1. 具有很好的沟通技能，能够取得公司高层的支持，获得所需资源
275 1. 具有较强的计划、组织、领导和控制才能，能够综合各方意见，按时制订和定期优化问题管理流程
276
277
278 ===== **1.8.2 问题经理** =====
279
280 问题经理负责协调日常的问题管理工作，包括对问题的审核、监控、所需资源的协调、定期产生报表等。
281
282 职责：
283
284 1. 领导问题管理小组，确保大家的积极性、技能水平
285 1. 定期组织相关人员对事件记录进行分析，发现潜在问题
286 1. 确认和审核问题
287 1. 必要时对问题进行上报
288 1. 监视问题的诊断、分析和处理过程
289 1. 必要时与问题专家沟通问题的相关信息
290 1. 必要时协调所需资源
291 1. 定期制定问题报表，提供正确决策信息
292
293 技能要求：
294
295 1. 具有较好的沟通和口头表达能力
296 1. 熟悉技术平台和技术环境
297 1. 较强的分析事件趋势的能力
298 1. 深刻熟悉问题管理流程
299
300
301 ===== **1.8.3 问题专家** =====
302
303 问题专家为问题的诊断及解决提供技术支持。通常由各专业组技术人员承担。
304
305 职责：
306
307 1. 接受问题经理分派过来的问题
308 1. 分析和诊断问题，确定根本原因
309 1. 确定和测试解决方案
310 1. 提交变更请求并监控变更实施
311 1. 协助事件支持人员进行重大或紧急事件的处理
312 1. 需要时协调第三方的资源来帮助诊断和改正问题
313
314 技能要求：
315
316 1. 较强的问题解决能力， 能够对问题进行分析并给出解决方案
317 1. 较强的专业知识
318 1. 较强的分析问题的能力和技巧
319 1. 较好的沟通和表达能力
320
321
322 ===== **1.8.4 流程角色和人员对应表** =====
323
324 |角色|成员
325 |问题管理流程负责人|Stanley
326 |问题经理|Stanley
327 |(% rowspan="2" %)问题专家|IT团队成员
328 |厂商和服务商的技术专家
329
330 表1-5流程角色和人员
331
332
333 ===== **​​​​​​​1.9 流程衡量指标和报表** =====
334
335 问题管理流程的关键衡量指标如下：
336
337 |序号|衡量指标|指标计算说明
338 |(% rowspan="4" %)1|(% rowspan="4" %)问题总数|数量：在问题单中根据以下条件过滤，
339 |1.   【重复问题标记】为空
340 |2.   【问题结束代码】不等于‘取消’
341 |3.   【登记时间】在统计周期内
342 |2|已找到根本原因的问题百分比|数量：在问题总数中，【找到根本原因】=‘是’ 的问题个数
343 |5|通过变通办法解决的问题百分比|数量：在关闭问题数量中，【问题结束代码】=‘变通方法’的问题个数
344 |(% rowspan="2" %)6|(% rowspan="2" %)问题成功解决率|数量：在关闭问题数量中，【结束代码】=‘变更解决 或 变通解决’的问题个数
345 |比率：数量 /关闭问题数量  × 100 %
346
347 表1-6问题响应时限和诊断时限
348
349
深圳市艾拓先锋企业管理咨询有限公司