Version 5.1 by superadmin on 2024/10/13, 16:40
Show last authors
1 [[返回本章节索引 >>http://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 **文档资料信息**
5
6 |**服务名称：**|(% colspan="3" %)(((
7 * **某省通信公司挑战365服务**
8 )))
9 |项目经理：|(((
10 * 杨XX
11 )))|文档版本号：|(((
12 * 2.0
13 )))
14 |服务阶段：|(((
15 * 流程优化
16 )))|文档版本日期：|(((
17 *
18 )))
19 |准备者：|(((
20 * 单XX
21 )))|准备日期：|(((
22 *
23 )))
24 |审定者：|(((
25 *
26 )))|审定日期：|(((
27 *
28 )))
29
30 **发送列表**
31
32 |**发送者：**|**日期：**|**电话/传真：**
33 |(((
34 *
35 )))|(((
36 *
37 )))|(((
38 *
39 )))
40
41 |**接受者：**|**目的：**|**日期：**|**电话/传真：**
42 |(((
43 * ** **某省通信公司
44 )))|(((
45 * 审阅
46 )))|(((
47 *
48 )))|(((
49 *
50 )))
51 |(((
52 *
53 )))|(((
54 *
55 )))|(((
56 *
57 )))|(((
58 *
59 )))
60
61 **版本历史**
62
63 [[image:1728808001314-390.png]]
64
65
66
67 = 1.问题管理流程概要设计 =
68
69 == 1.1.流程目的 ==
70
71 当事件管理需进行进一步分析，找出故障深层原因和根本解决方案，通过变更请求(RFC)、变通方法或建议的预防性措施来防止同类故障的再次发生时，应启动问题管理流程。
72
73 问题管理流程的根本目的是消除或减少C365生产环境中事件发生的数量和严重程度，从而为企业建立一个稳定的IT环境，提高IT服务的可用性。
74
75 其目的包括：
76
77 1. 分析并确定事件的根本原因，找到最终解决方案，以防止此类事件再次发生
78 1. 提高IT服务的可靠性，降低IT支持成本
79
80 == ==
81
82 == 1.2.流程主要内容 ==
83
84 问题管理流程着重于消除事件或减少事件发生，确定事件的根本原因。主要活动包括分析事件、找出问题、分派问题、确定根本原因以及找出解决方案、回顾及关闭，以消除事件或在其发生时降低对用户或业务的影响。其主要内容如下：
85
86 * 分析事件 
87
88 定期分析事件，找出潜在问题。
89
90 * 生成问题记录
91
92 在系统中生成问题记录并把所有相关事件与此记录关联起来。
93
94 * 紧急事件处理完后定义为问题
95 * 运维人员在日常维护中发现的问题
96 * 事件历史记录趋势分析发现的问题
97
98
99 * 分派 
100
101 根据问题分类将问题记录分派给相应的问题处理人员。
102
103 * 根本原因分析 
104
105 被分派的问题处理人员应调查问题找出其原因，提出变通方法或预防性措施在重发时使其影响力最小化、以及解决方案以消除产生原因。记录必须被更新以反映它是已定位原因状态，并且把任何变通方法、避免或最小化负面影响的动作行为也记录下来。
106
107 * 开发、确认、提出实施解决方案
108
109 对问题的解决方案进行评估、测试，提出变更请求（RFC）或通过其他流程实施相应解决方案。
110
111 * 回顾
112
113 问题主管组织对问题的解决方案的实施情况进行回顾，确认已成功实施。
114
115 由问题主管组织相关人员，在问题处理人的协助下，对问题的解决方案的实施情况进行整体回顾、总结。
116
117 由问题主管确认解决方案达到预期的效果；
118
119 * 总结及关闭
120
121 由问题主管确认问题的信息记录填写完整，标识为已知错误，总结问题信息项并关闭问题记录。
122
123 == ==
124
125 == 1.3.与其他流程的关系 ==
126
127 * 和事件管理的关联
128 ** 紧急事件将升级为问题，或根据事件的趋势分析，发现潜在的问题，同时问题的解决方案实施为事件流程提供了解决办法
129 * 和变更管理的关联
130 ** 问题处理过程中，如果需要对系统进行变更，必须按照变更管理的定义，提交变更请求单（变更单必须和问题单建立关联），变更完成后，继续问题单的处理
131 * 和需求管理的关联
132 ** 问题处理过程中，如果需要进行代码变更，则须由问题主管根据问题处理人提供的诊断结果，转需求管理流程解决，需求管理流程处理完成后，应对问题处理进行回顾、总结
133 * 和工程管理的关联
134 ** 问题处理过程中，如果需要进行代码变更，则须由问题主管根据问题处理人提供的诊断结果，转工程管理流程解决，工程管理流程处理完成后，应对问题处理进行回顾、总结
135 * 和配置管理的关联
136 ** 问题处理过程中，可以通过配置管理查询相关的配置项信息
137 ** 问题处理过程中，如果可以将根本原因定位到某个配置项，则必须将问题单与该配置项关联
138 * 和知识管理的关联
139 ** 问题处理完成后，均应整理提交到知识库中
140
141 == ==
142
143 == 1.4.流程范围 ==
144
145 问题管理流程的范围是对C365范围的IT生产环境中发生的问题进行管理，以采取主动性预防措施来降低事件数量。
146
147 不包括：
148
149 * 处于开发或测试环境的系统和应用
150
151 == ==
152
153 == 1.5.流程执行原则 ==
154
155 === 1.5.1.常规原则 ===
156
157 * 问题管理流程应与事件管理流程相对独立，事件处理过程中故障消除、业务恢复后如需后续分析处理，应转问题管理流程
158 * 问题管理流程经理应每半年对问题管理流程的流程关键衡量指标、流程执行效率、流程支撑工具有效性等进行回顾，以改进和优化流程
159 * 问题经理应该每月组织定期回顾和产生问题管理报表，由事件经理对事件趋势进行分析。
160 ** 对需要解决的问题，问题经理应将问题安排给相应问题主管解决。
161 ** 对没有解决的问题，问题经理应该举行定期的问题管理会议对这些问题进行评估
162
163 === ===
164
165 === 1.5.2.所有权原则 ===
166
167 所有权原则用来确保每个问题在任何时段都有适当的人员负责，问题主管是每个问题的负责人。有效管理问题的前提是必须确保每个问题在任何时段都有适当的人员负责。
168
169 下表是各角色在各环节中承担不同责任的RACI模型。
170
171 | |**问题经理**|**问题主管**|**问题处理人**
172 |问题确定与记录|I|A|C
173 |问题确认与分派|A|C|I
174 |分析并诊断问题/提供变通方法|I|A/I|R/C
175 |开发、确认、实施解决方案|I|A/I|R/C
176 |问题监控|I|A/I|R/C
177 |问题回顾与关闭|I|A/I|R/C
178 |(% colspan="4" %)RACI模型说明 A: 负全责; R: 有义务; C: 提建议; I: 需知会
179
180 === ===
181
182 === 1.5.3.创建原则 ===
183
184 * 紧急事件解决后，由事件经理告知相应问题主管进行问题解决
185 * 经问题主管确认，运维人员在运维中发现的潜在故障，尚未影响业务的，应建立问题单
186 * 经问题主管确认，运维人员在运维中遇到频繁发生的类似或相同的故障，应建立问题单
187 * 由问题经理定期组织事件分析会,工作分析会应包括对所处理事件历史记录的趋势分析。基于会议讨论、分析，须落实的潜在故障分析任务，应由问题经理指派相应问题主管建立问题单、由问题主管跟踪整个问题的处理过程。
188
189 === ===
190
191 === 1.5.4.退回和转派原则 ===
192
193 问题处理人认为问题协同分派错误时，可退回问题主管，由其进行再分派(转派)。为确保问题协同单不被过于频繁的相互转派、以至于无法及时解决，应当尽量减少问题协同单再分派的几率，一个问题协同单再分派的次数不应该超过两次。问题协同单再分派必须经过问题主管。
194
195 === ===
196
197 === 1.5.5.重复问题原则 ===
198
199 重复问题是指经过分析之后，根本原因相同的问题。例如：经问题主管确认，运维人员提出了几个问题，但是经过分析之后，发现这几个问题的根本原因是相同的，这几个问题就可以定义为重复问题。对于重复问题需要进行标志，将相关问题记录进行关联，当问题解决时同时进行回顾。
200
201 === ===
202
203 === 1.5.6.问题关闭原则 ===
204
205 通常问题单在实施了解决方案之后，需要经过一段时间回顾，由问题主管负责组织、问题处理人参与回顾解决方案是否达到了预期的效果，如果成功的实施，由问题主管确认问题已回顾，和问题信息记录完整，关闭问题。
206
207 问题关闭时须确认为“已知错误” ,并须整理经验，提交已知错误库。
208
209 === ===
210
211 === 1.5.7.问题单重开原则 ===
212
213 已关闭的问题单不允许重开。如果问题重复发生，则创建一个新的问题单。
214
215 === ===
216
217 === 1.5.8.问题升级原则 ===
218
219 制定升级原则的目的是，在规定的诊断时限内无法诊断问题时，及时通知相关领导，引起更多的重视，提供合适的资源，从而快速找到解决问题的方案。
220
221 1. 各问题处理人员应及时响应和处理分配到自己的问题协同单;
222 1. 问题主管主动监督问题协同处理情况，应及时将无法诊断的问题和超时诊断的问题升级到问题经理；问题经理负责协调资源，如依然无法解决问题，应将问题上报领导，并同时督促问题协同及时被处理。
223
224 (% class="wikigeneratedid" %)
225 === ===
226
227 === 1.5.9.趋势分析原则 ===
228
229 问题经理每月组织会议，对所处理事件历史记录进行趋势分析：
230
231 * 参加者应包括事件经理及问题处理人
232 * 会议定期组织
233
234 == ==
235
236 == 1.6.流程相关定义 ==
237
238 === 1.6.1.问题信息项 ===
239
240 问题单包含如下信息项：
241
242 |**序号**|(% style="width:115px" %)**信息项**|(% style="width:973px" %)**描述**
243 |1|(% style="width:115px" %)问题ID|(% style="width:973px" %)为每个问题分配一个唯一的序列号（系统自动产生）
244 |2|(% style="width:115px" %)请求人信息|(% style="width:973px" %)问题请求人的信息，包括：姓名、省/分公司、部门、电子邮件、办公电话、手机（手工填写）
245 |3|(% style="width:115px" %)登记时间|(% style="width:973px" %)生成问题记录的时间（系统自动产生）
246 |4|(% style="width:115px" %)完成时间|(% style="width:973px" %)问题解决完成时间(收到处理结果的时间)
247 |5|(% style="width:115px" %)关闭时间|(% style="width:973px" %)问题确认关闭的时间
248 |6|(% style="width:115px" %)地点|(% style="width:973px" %)记录问题发生的地点（手工填写）
249 |7|(% style="width:115px" %)问题标题|(% style="width:973px" %)简单描述问题（手工填写）
250 |8|(% style="width:115px" %)问题描述|(% style="width:973px" %)问题主管详细描述问题内容（手工填写）
251 |9|(% style="width:115px" %)问题来源|(% style="width:973px" %)参见“问题来源”定义
252 |10|(% style="width:115px" %)影响系统|(% style="width:973px" %)服务开通、综合采集、一级BOSS、采集预处理、融合计费、产品管理、融合控制、综合帐务、综合结算、合作伙伴管理、基础功能、统计报表、局数据管理与发布、信息管理、客户服务、电子渠道、市场营销、销售管理、渠道管理、客户管理、资源管理、产品管理、系统管理、服务管理、监控管理、经分（下拉菜单供选择）
253 |11|(% style="width:115px" %)影响范围|(% style="width:973px" %)全省、全省多个地市 (6~~11个)、少数地市(1~~5个)。（下拉菜单供选择）
254 |12|(% style="width:115px" %)问题优先级|(% style="width:973px" %)参见“问题优先级”定义 ，备注：通过"影响系统"、与“影响范围”的手工选择，系统自动匹配优先级别。
255 |13|(% style="width:115px" %)所属系统类型|(% style="width:973px" %)参见“所属系统类型”定义
256 |14|(% style="width:115px" %)问题分类|(% style="width:973px" %)参见“问题分类”定义
257 |15|(% style="width:115px" %)问题状态|(% style="width:973px" %)参见“问题状态”定义
258 |16|(% style="width:115px" %)问题主管|(% style="width:973px" %)该问题对应的问题主管 (展示)
259 |17|(% style="width:115px" %)问题处理人|(% style="width:973px" %)负责该问题的问题处理人 (手工选择)
260 |18|(% style="width:115px" %)问题经理|(% style="width:973px" %)(系统自动生成)
261 |19|(% style="width:115px" %)审核结果|(% style="width:973px" %)同意或驳回(下拉选项)
262 |20|(% style="width:115px" %)审核意见|(% style="width:973px" %)填写审核意见(问题经理手工填写)
263 |21|(% style="width:115px" %)建议解决方案|(% style="width:973px" %)提供初步解决建议及初步方案 （手工填写）
264 |22|(% style="width:115px" %)问题原因|(% style="width:973px" %)综合描述问题产生的根本原因（问题主管手工填写）
265 |23|(% style="width:115px" %)重复问题标记|(% style="width:973px" %)标记为重复问题，用已有标题号标注（问题主管手工填写）
266 |24|(% style="width:115px" %)变通方法及解决方案|(% style="width:973px" %)问题变通方法及解决方案的详细描述（问题主管整合各协同单提供的解决方案进行填写）
267 |25|(% style="width:115px" %)解决流程|(% style="width:973px" %)变更管理流程/需求管理流程/工程管理流程（下拉选项）
268 |26|(% style="width:115px" %)处理结果|(% style="width:973px" %)通过接口同步，得出处理结果
269 |27|(% style="width:115px" %)方案附件|(% style="width:973px" %)由需求管理平台等接口同步
270 |28|(% style="width:115px" %)处理描述|(% style="width:973px" %)问题主管描述转解决流程单号、处理人、处理结果等处理信息
271 |29|(% style="width:115px" %)是否由紧急事件升级|(% style="width:973px" %)“是”或“否”，在问题创建时，根据关联的事件手工填写
272 |30|(% style="width:115px" %)关联的事件单号|(% style="width:973px" %)记录引发该问题的事件单号（手工填写）
273 |31|(% style="width:115px" %)关联的变更单号|(% style="width:973px" %)问题单转派的变更单号（系统自动生成）
274 |32|(% style="width:115px" %)关联的需求单号|(% style="width:973px" %)问题单转派的需求单号（系统自动生成）
275 |33|(% style="width:115px" %)关联配置项|(% style="width:973px" %)记录问题的配置项代码（手工填写）
276 |34|(% style="width:115px" %)是否已知错误|(% style="width:973px" %)是/否 (问题主管选择)
277 |35|(% style="width:115px" %)问题总结|(% style="width:973px" %)对问题处理过程进行总结(问题主管填写)
278
279 协同单包含如下信息项：
280
281 |**序号**|**信息项**|**描述**
282 |1|协同单ID|为每个协同单分配一个唯一的序列号（系统自动产生）
283 |2|协同单标题|简单描述协同单（系统自动产生）
284 |3|登记时间|生成协同单记录的时间（系统自动产生）
285 |4|完成时间|协同处理完成的时间
286 |5|协同关闭时间|确认协同单关闭的时间
287 |6|诊断时限|相应问题优先级的问题协同诊断时限，参见“诊断时限”定义
288 |7|问题主管|该问题的问题主管
289 |8|问题处理人|负责该问题的问题处理人
290 |9|问题来源|参见“问题来源”定义
291 |10|问题优先级|参见“问题优先级”定义
292 |11|所属系统类型|参见“所属系统类型”定义
293 |12|问题分类|参见“问题分类”定义
294 |13|问题描述|问题主管详细描述问题内容
295 |14|协同状态|参见“协同状态”定义
296 |15|建议解决方案|问题主管提供的初步建议解决方案
297 |16|问题原因|详细描述问题产生的根本原因（问题处理人手工填写）
298 |17|解决方案|问题变通方法及最终解决方案的详细描述（问题处理人手工填写）
299 |18|是否已超时|是或否(系统自动判断协同是否已经超过诊断时限)
300 |19|满意度|满意\一般\不满意(下拉菜单)
301
302 (% class="wikigeneratedid" %)
303 === ===
304
305 === 1.6.2.问题来源 ===
306
307 根据问题的不同来源对问题分类如下：
308
309 |**编号**|(% style="width:122px" %)**代码**|(% style="width:968px" %)**描述**
310 |1|(% style="width:122px" %) 事件研究|(% style="width:968px" %)(((
311 紧急事件恢复服务后提出的问题，以便进行紧急事件的根本原因分析。
312
313
314 例如：某日发生了一起集群无法切换的事件，导致某台主机发生故障后，没有切换到备用主机中去，从而影响了业务，紧急事件的处理人员在采取了手工切换的替代措施后，恢复了服务。
315
316 为了分析为什么会发生该紧急事件，以及查看其他的集群是否也存在类似的问题，此时可以提出一个问题记录，以便对该紧急事件进行分析。
317 )))
318 |2|(% style="width:122px" %)维护中提出|(% style="width:968px" %)(((
319 运维人员在日常维护工作中提出的问题。
320
321
322 例如：维护人员在日常维护中发现，目前的数据库版本可能会存在着死锁、心跳不一致等方面的问题，此时就可以提出一个问题记录，以便分析。
323 )))
324 |3|(% style="width:122px" %)趋势分析|(% style="width:968px" %)(((
325 分析事件记录找出的问题。
326
327
328 例如：在定期的会议中，对计费类的事件进行分析后发现，上周该类型的事件比平常的时候多了30％，超过了规定的阀值，这表明计费系统有可能存在着一些潜在的隐患，此时就可以提出一个问题记录，以找出问题的原因并解决。
329 )))
330
331 === ===
332
333 === 1.6.3.问题优先级 ===
334
335 问题的优先级是问题处理人解决问题的参照标准，对于关键优先级的问题，管理层应该优先协调资源进行这些问题的解决。结合中国移动的实际情况，问题的优先级定义如下：
336
337 |**编号**|(% style="width:76px" %)**代码**|(% style="width:1008px" %)**描述**
338 |1|(% style="width:76px" %)关键|(% style="width:1008px" %)(((
339 紧急事件升级来的问题；
340
341 运维分析会得出的问题和运维人员提出的问题从如下方面考虑，问题发生是否会导致：
342
343 BOSS系统中客户服务、客户管理、服务开通、综合帐务任一业务不可用，影响面为全省或至少包括一个关键地市
344
345 客服系统的电话呼叫中心业务不可用，影响面为全省或至少包括一个关键地市
346
347 电子渠道（如，网厅、短厅）业务不可能用，影响面为全省或至少包括一个关键地市
348
349 因系统原因数据处理错误，导致大量用户投诉
350
351 来自新闻媒体、消费者协会、国家行政机关（工商、物价等）的反映或申告
352
353 部分重要数据丢失，且无法全部恢复
354 )))
355 |2|(% style="width:76px" %)重要|(% style="width:1008px" %)(((
356 运维分析会得出的问题和运维人员提出的问题从如下方面考虑，问题发生是否会导致：
357
358 BOSS系统中客户服务、客户管理、服务开通、综合帐务任一业务不可用，影响面为一个或多个非关键地市
359
360 BOSS系统中综合采集、融合计费、产品管理、资源管理、一级BOSS、营销管理、渠道管理、合作伙伴管理、综合结算、系统管理、统计报表任一业务不可用，影响面为全省或至少包括一个关键地市
361
362 客服系统的电话呼叫中心业务不可用，影响面为一个或多个非关键地市
363
364 客服系统中互联网呼叫中心、短信呼叫中心、工单管理、知识管理、人力资源、质量管理、数据统计分析任一业务不可用，影响面为全省或至少包括一个关键地市
365
366 电渠的业务受理不可用，影响面为一个或多个非关键地市
367
368 经分系统的通用分析不可用，影响面为全省
369
370 BOMC系统的服务管理或监控管理不可用，影响面为全省
371
372 用户在营业现场反应激烈
373 )))
374 |3|(% style="width:76px" %)普通|(% style="width:1008px" %)(((
375 运维分析会得出的问题和运维人员提出的问题从如下方面考虑，问题发生是否会导致：
376
377 一般性系统故障
378 )))
379
380 问题的优先级设计依据事件的影响范围、业务系统的关键程度、和事件发生的频率。
381
382 由问题主管在优先级映射表中定位优先级。问题处理人不能修改优先级。
383
384 |(% colspan="2" style="width:809px" %)(((
385 影响范围
386
387 系统
388 )))|(% style="width:61px" %)全省|全省多个地市 (6~~11个)|少数地市(1~~5个)
389 |(% rowspan="2" %)BOSS（任意一个模块）|(% style="width:661px" %)服务开通、综合采集、一级BOSS、采集预处理、融合计费|(% style="width:61px" %)关键|重要|重要
390 |(% style="width:661px" %)产品管理、融合控制、综合帐务、综合结算、合作伙伴管理、基础功能、统计报表、局数据管理与发布、信息管理、其他|(% style="width:61px" %)重要|普通|普通
391 |(% rowspan="3" %)CRM（任意一个模块）|(% style="width:661px" %)客户服务|(% style="width:61px" %)关键|重要|重要
392 |(% style="width:661px" %)电子渠道|(% style="width:61px" %)关键|重要|重要
393 |(% style="width:661px" %)市场营销、销售管理、渠道管理、客户管理、资源管理、产品管理、系统管理、其他|(% style="width:61px" %)重要|普通|普通
394 |经分|(% style="width:661px" %) |(% style="width:61px" %)重要|重要|普通
395 |BOMC|(% style="width:661px" %)服务管理、监控管理|(% style="width:61px" %)重要|普通|普通
396
397 (% class="wikigeneratedid" %)
398 === ===
399
400 === 1.6.4.问题状态 ===
401
402 为了记录问题处理的生命周期，需要设置不同的状态加以描述，如下所示：
403
404 |(% colspan="3" %)**问题状态**
405 |**编号** |**代码** |**描述**
406 |1|已登记|问题已登录到系统中
407 |2|待审核|已经登录问题,但是尚未得到问题经理审核
408 |3|已审核|问题经理已审核\确认问题
409 |4|分析中|问题主管已经发协同单给问题处理人,问题处理人正在分析问题过程中
410 |5|已有解决方案|问题主管收到问题处理人的解决方案反馈
411 |6|已解决|问题主管收到需求管理\变更管理\工程管理流程等的反馈,得知问题已经得到解决
412 |7|回顾与关闭|问题主管已经组织对问题进行了回顾，关闭问题，问题结束
413
414 为了记录问题处理的生命周期，也需要设置协同单不同的状态加以描述，如下所示：
415
416 |(% colspan="3" %)**协同状态**
417 |**编号**|**代码**|**描述**
418 |1|已登记|协同已登录到系统中
419 |2|待分析|已派发至问题处理人，但问题处理人尚未开始分析
420 |3|分析中|问题处理人正在分析问题过程中
421 |4|已分析|协同部分的变通方法与解决方案已找到
422 |5|已关闭|将协同单关闭
423
424 (% class="wikigeneratedid" %)
425 === ===
426
427 === 1.6.5.所属系统类型 ===
428
429 |**业务系统** |**子类**
430 |(% rowspan="15" %)BOSS系统|产品管理
431 |服务开通
432 |综合采集
433 |融合控制
434 |融合计费
435 |综合帐务
436 |综合结算
437 |合作伙伴管理
438 |基础功能
439 |统计报表
440 |一级BOSS
441 |局数据管理与发布
442 |信息管理
443 |采集预处理
444 |其他
445 |(% rowspan="9" %)CRM系统|市场营销
446 |销售管理
447 |渠道管理
448 |客户服务
449 |客户管理
450 |资源管理
451 |产品管理
452 |系统管理
453 |其他
454 |经分系统|
455 |(% rowspan="2" %)BOMC|服务管理
456 |监控管理
457 |其他系统|
458
459 (% class="wikigeneratedid" %)
460 === ===
461
462 (% class="wikigeneratedid" %)
463 === 1.6.6.问题分类 ===
464
465 |(% rowspan="3" %)**问题类别**|(% colspan="2" rowspan="3" %)**问题子类**
466 |
467 |
468 |(% rowspan="17" %)需求类问题|计费帐务类 |
469 |(% rowspan="2" %)营业维护类 |个人
470 |集团
471 |客服维护类 |
472 |(% rowspan="5" %)电子渠道维护类 |短信
473 |网厅
474 |自助
475 |集团
476 |市场
477 |(% rowspan="7" %)经分维护类 |数据集市应用和接口
478 |市场部门应用
479 |集团客户应用
480 |客服
481 |数据
482 |网管
483 |计划
484 |接口维护类 |
485 |(% rowspan="5" %)工程类问题|全网工程类|
486 |软件系统架构调整|
487 |硬件系统架构调整|
488 |性能与容量|
489 |其他|
490 |(% rowspan="5" %)运维类问题|主机类 |
491 |网络类 |
492 |中间件类 |
493 |物理环境类 |
494 |数据库类 |
495
496 === ===
497
498 === 1.6.7.问题结束代码 ===
499
500 为了表明问题的不同解决方式，定义如下结束代码：
501
502 |**编号**|**代码**|**描述**
503 |1|根本解决|找出问题的根本原因，并得到解决方案，成功解决
504 |2|变通方法|没有根本解决方案或目前没有办法实施根本解决方案，但有临时解决方案作为变通方法
505 |3|取消|问题被问题经理拒绝
506
507 == ==
508
509 == 1.7.问题管理流程设计 ==
510
511 问题管理设计流程图如下：
512
513 [[image:1728808468651-573.png]]
514
515 图.1.1 问题管理流程
516
517
518 问题管理概要流程描述如下：
519
520 下表以问题管理概要图中的关键流程活动为主线，与问题管理概要设计中的其它重要内容进行了关联，以帮助业务支撑维护部门更好地理解流程设计内容。
521
522 |**序号**|**步骤名称**|(% style="width:95px" %)**责任人**|(% style="width:885px" %)**流程环节说明**
523 |(% rowspan="3" %)300.1|(% rowspan="3" %)问题确定与记录|(% rowspan="3" style="width:95px" %)问题主管|(% style="width:885px" %)运维人员在运维中发现重复事件发生或者认为有潜在隐患的问题，应向问题主管汇报、并提供问题描述、问题类别及初步建议解决方案等信息,问题主管对来自运维人员提出的问题进行初步判断，如确是问题,那么应在系统中对问题进行记录，选择问题处理人员,对问题信息进行描述,并提出建议解决方案
524 |(% style="width:885px" %)问题经理对通过事件趋势分析发现的潜在问题，通知相应问题类别的问题主管,由问题主管在系统中对问题进行记录，在问题提出者的协助下,对问题信息进行描述,并提出建议解决方案
525 |(% style="width:885px" %)在紧急事件处理完成后(无论是否根本解决)，都由事件经理将紧急事件的处理情况、事件信息通知相应问题类别的问题主管,由问题主管在系统中对问题进行记录，对问题信息进行描述,并提出建议解决方案
526 |300.2|问题审核|(% style="width:95px" %)问题经理|(% style="width:885px" %)问题经理审核问题(如果问题经理认为分派不合理,则可进行调整分派对象),审核后回给问题主管。
527 |(% rowspan="2" %)300.3|(% rowspan="2" %)分析并诊断问题|(% rowspan="2" style="width:95px" %)问题主管/问题处理人|(% style="width:885px" %)问题主管登记协同单,并派发相应问题处理人,问题处理人接受问题协同单，并展开问题原因分析,问题处理人将问题产生根本原因与变通方法、解决方案及时更新到协同单记录中，并反馈给问题主管，问题主管确认协同完成，并关闭协同单。
528 |(% style="width:885px" %)如需其他问题处理人协助分析、诊断，则通知问题主管，由问题主管负责协调资源，成立问题分析小组，举行问题根本原因分析研讨会议，并确定问题的潜在原因，提供或更新问题变通方法，以降低问题在根本解决前对业务产生的影响。
529 |(% rowspan="2" %)300.4|(% rowspan="2" %)问题监控|(% rowspan="2" style="width:95px" %)问题主管|(% style="width:885px" %)在问题分析和解决过程中，由问题主管与问题处理人保持沟通，监控问题解决的进展情况、及时更新问题状态并按需汇报。
530 |(% style="width:885px" %)在问题找到根本原因和解决方案之后，根据需要，向帮助台或问题发起人通报该问题的解决情况，以帮助和提高事件的解决率。
531 |(% rowspan="3" %)300.5|(% rowspan="3" %)开发、确认、实施解决方案|(% rowspan="3" style="width:95px" %)问题主管/问题处理人|(% style="width:885px" %)问题主管整合问题处理人提交的解决方案，根据问题类型转其他解决流程（如需求管理等）解决问题。
532 |(% style="width:885px" %)由问题处理人负责落实解决方案以最终解决问题。
533 |(% style="width:885px" %)如果需要第三方介入，则问题主管负责与第三方的接口与协调。
534 |(% rowspan="4" %)300.6|(% rowspan="4" %)问题回顾与总结|(% rowspan="4" style="width:95px" %)问题主管|(% style="width:885px" %)当问题解决后，由问题主管组织，问题处理人协助对问题方案的实施情况进行整体回顾。
535 |(% style="width:885px" %)如果经回顾问题已经得到解决，那么问题主管总结问题处理经验，并对问题记录的信息项进行总结，更新问题记录并关闭问题。
536 |(% style="width:885px" %)将问题标识为“已知错误”，启动知识单走知识管理流程进行知识积累。
537 |(% style="width:885px" %)如果经问题主管回顾问题没有解决，则予以驳回。
538
539 == ==
540
541 == 1.8.问题处理流程设计 ==
542
543 问题管理设计流程图如下：
544
545 [[image:1728808535542-474.png]]
546
547 图.1.2 问题处理流程
548
549
550 下表以问题处理流程图中的关键流程活动为主线，描述了问题处理过程中,用协同单的方式实现处理中的流程流转方式，以帮助业务支撑维护部门更好地理解流程设计内容。
551
552 |**步骤名称**|(% style="width:118px" %)**责任人**|(% style="width:721px" %)**流程环节说明**
553 |登记协同单|(% style="width:118px" %)问题主管|(% style="width:721px" %)问题主管将需要分析的问题信息整理，登记协同单并派发给相应问题处理人
554 |问题原因分析|(% style="width:118px" %)问题处理人|(% style="width:721px" %)问题处理人根据派发过来的协同单对问题原因进行诊断
555 |得出根本原因与变通方法、解决方案|(% style="width:118px" %)问题处理人|(% style="width:721px" %)问题处理人在诊断得出问题原因、变通方法（临时解决方法）、及解决方案，并通过协同单回馈上报给问题主管
556 |确认问题方案|(% style="width:118px" %)问题主管|(% style="width:721px" %)问题主管确认问题方案可行，如果认为方案不可行，则将协同单驳回给问题处理人做继续处理
557 |关闭协同单|(% style="width:118px" %)问题主管|(% style="width:721px" %)问题主管在确认问题方案可行后，关闭协同单
558 |更新问题单|(% style="width:118px" %)问题主管|(% style="width:721px" %)问题主管将协同单中得出的根本原因与变通方法、解决方案等信息更新录入问题单中，作为问题跟踪的记录基础
559 |转其他流程解决|(% style="width:118px" %)问题主管|(% style="width:721px" %)问题主管根据协同得出的解决方案要求，转需求管理、工程管理其他流程予以解决问题
560 |其他流程根据问题单提供的信息进行问题处理|(% style="width:118px" %)问题处理人|(% style="width:721px" %)问题处理人执行需求管理、工程管理等流程以解决问题，在解决之后给与问题主观问题处理的结果反馈
561 |确认问题解决|(% style="width:118px" %)问题主管|(% style="width:721px" %)问题主管对问题处理反馈结果进行确认，如果认为依然没有解决，则予以驳回
562 |(% rowspan="4" %)问题回顾与总结|(% rowspan="4" style="width:118px" %)问题主管|(% style="width:721px" %)当问题主管确认问题解决后，由问题主管组织，问题处理人协助对问题方案的实施情况进行整体回顾。
563 |(% style="width:721px" %)如果经回顾问题已经得到解决，那么问题主管总结问题处理经验，并对问题记录的信息项进行总结，更新问题记录并关闭问题。
564 |(% style="width:721px" %)将问题标识为“已知错误”，启动知识单走知识管理流程进行知识积累。
565 |(% style="width:721px" %)如果经问题主管回顾问题没有解决，则予以驳回。
566
567 == ==
568
569 == 1.9.关键角色、职责定义 ==
570
571 === 1.9.1.流程经理 ===
572
573 问题管理流程经理从总体上对问题管理流程的设计、实施、执行及优化负责，确保问题管理流程在业务支撑中心范围内被正确的执行。当流程不能够适应业务支撑中心的情况时，流程负责人必须及时的对此进行分析、找出缺陷、进行改进，从而实现可持续提高。
574
575 职责:
576
577 1. 确保问题管理流程的设计、实施及执行，能够取得管理层的参与和支持
578 1. 确保问题管理流程符合公司实际状况和公司 IT发展战略
579 1. 整体上对问题管理流程负责，建立流程实施、评估和持续优化机制
580 1. 确保问题管理流程的有效执行，定期评估流程，制定流程改进计划
581 1. 保持与其他流程负责人的定期沟通
582
583 (% class="wikigeneratedid" %)
584 === ===
585
586 === 1.9.2.问题经理 ===
587
588 问题经理负责协调日常的问题管理工作，包括对问题所需资源的协调、定期组织事件分析会、必要的时候对问题进行审核和协调分派等。
589
590 职责：
591
592 1. 定期组织相关人员对事件记录进行分析，发掘潜在问题
593 1. 确认和审核问题
594 1. 必要时对问题进行上报
595 1. 必要时协调所需资源
596
597 === ===
598
599 === 1.9.3.问题主管 ===
600
601 问题主管负责日常问题处理过程中的管控工作。
602
603 职责：
604
605 1. 监控问题的诊断、分析和处理过程
606 1. 必要时与帮助台及问题请求者沟通问题的相关信息
607 1. 问题回顾
608
609 (% class="wikigeneratedid" %)
610 === ===
611
612 === 1.9.4.问题处理人 ===
613
614 问题处理人负责问题为问题诊断及解决提供技术支持。
615
616 职责：
617
618 1. 接受问题主管分派过来的问题
619 1. 分析和诊断问题，确定根本原因
620 1. 确定和测试解决方案
621 1. 协助事件一线人员进行重大或紧急事件、以及大量反复发生（当天发生大于等于50件）的事件的处理
622 1. 实施解决方案,需要时协调第三方的资源来帮助诊断和改正问题
623
624 (% class="wikigeneratedid" %)
625 === ===
626
627 === 1.9.5.流程角色和人员对应表 ===
628
629 1. 问题经理由系统运维室专人统一负责；
630 1. 问题主管由系统运维室各专业小组长担任，对问题处理过程进行监督；
631 1. 问题处理人由各室专业技术人员分别担任，问题处理人负责对问题分析、诊断、方案制定和解决；
632 1. 问题处理人的处理过程和结果由问题主管在问题管理平台上进行整理、总结并记录。
633
634 |(% colspan="7" %)**问题管理流程角色表**
635 |**流程经理 **|(% colspan="6" %)** **
636 |**问题经理**|(% colspan="6" %)** **
637 |**问题类别**|(% colspan="2" %)**问题子类**|**问题主管部门**|**问题主管**|**问题处理部门 **|**问题处理人**
638 |(% rowspan="17" %)需求类问题|计费帐务类   | | | | |
639 |(% rowspan="2" %)营业类   |个人| | | |
640 |集团| | | |
641 |客服类   | | | | |
642 |(% rowspan="5" %)电子渠道类   |短信| | | |
643 |网厅| | | |
644 |自助| | | |
645 |集团| | | |
646 |市场| | | |
647 |(% rowspan="7" %)经分类   |数据集市应用和接口| | | |
648 |市场部门应用| | | |
649 |集团客户应用| | | |
650 |客服| | | |
651 |数据| | | |
652 |网管| | | |
653 |计划| | | |
654 |接口类   | | | | |
655 |(% rowspan="6" %)运维类问题|主机类   | | | | |
656 |网络类   | | | | |
657 |中间件类   | | | | |
658 |物理环境类   | | | | |
659 |数据库类   | | | | |
660 |安全系统类| | | | |
661 |(% rowspan="5" %)工程类问题|全网工程类| | | | |
662 |软件系统架构调整| | | | |
663 |硬件系统架构调整| | | | |
664 |性能与容量| | | | |
665 | | | | | |
666 |其他| | | | | |
667
668 (% class="wikigeneratedid" %)
669 == ==
670
671 == 1.10.流程衡量指标 ==
672
673 问题管理流程的关键衡量指标如下：
674
675 |**序号** |**衡量指标** |**指标计算说明**
676 |(% rowspan="3" %)1|(% rowspan="3" %)统计周期内 新增问题总数|数量：在问题单中根据以下条件过滤，
677 |1.【问题结束代码】不等于‘取消’
678 |2.【登记时间】在统计周期内
679 |(% rowspan="2" %)2|(% rowspan="2" %)统计周期内 新增协同总数|数量：在协同单中根据以下条件过滤，
680 |1.【登记时间】在统计周期内
681 |(% rowspan="3" %)3|(% rowspan="3" %)统计周期内关闭问题数量|数量：在问题单中根据以下条件过滤，
682 |1.【问题关闭时间】在统计周期内，
683 |2.【问题状态】=‘结束并关闭’的问题个数
684 |(% rowspan="3" %)4|(% rowspan="3" %)统计周期内关闭协同数量|数量：在协同单中根据以下条件过滤，
685 |1.【协同关闭时间】在统计周期内，
686 |2.【已关闭】在统计周期内，
687
688
689 == 1.11.问题管理报表 ==
690
691 === 1.11.1.新增问题统计报表 ===
692
693 |**类别** |**子类** |**新增问题总数**
694 |(% rowspan="6" %)需求类|计费帐务类  |
695 |营业类  |
696 |客服类  |
697 |电子渠道类  |
698 |经分类  |
699 |接口类  |
700 |(% rowspan="4" %)工程类|全网工程类|
701 |软件系统架构调整|
702 |硬件系统架构调整|
703 |性能与容量|
704 |(% rowspan="5" %)运维类|主机类  |
705 |网络类  |
706 |中间件类  |
707 |物理环境类  |
708 |数据库类|
709 |其他类| |
710
711 |**序号**|**指标名称**|**指标计算说明**
712 |(% rowspan="3" %)1|(% rowspan="3" %)统计周期内 新增问题总数|数量：在问题单中根据以下条件过滤
713 |1.【问题结束代码】不等于‘取消’
714 |2.【登记时间】在统计周期内
715
716 (% class="wikigeneratedid" %)
717 === ===
718
719 === 1.11.2.未关闭协同统计报表 ===
720
721 |(% rowspan="2" %)**类别** |(% rowspan="2" %)**子类** |(% rowspan="2" %)**未关闭协同总数**|(% colspan="3" %)**各部门未关闭协同数量**
722 |**电渠室**|**经分室**|**规划室**
723 |(% rowspan="6" %)需求类|计费帐务类  | | | |
724 |营业类  | | | |
725 |客服类  | | | |
726 |电子渠道类  | | | |
727 |经分类  | | | |
728 |接口类  | | | |
729 |(% rowspan="4" %)工程类|全网工程类| | | |
730 |软件系统架构调整| | | |
731 |硬件系统架构调整| | | |
732 |性能与容量| | | |
733 |(% rowspan="5" %)运维类|主机类  | | | |
734 |网络类  | | | |
735 |中间件类  | | | |
736 |物理环境类  | | | |
737 |数据库类  | | | |
738 |其他类| | | | |
739
740 |**序号**|**指标名称**|**指标计算说明**
741 |1|未关闭协同数量|数量：在协同单中根据以下条件过滤， 状态不等于“已关闭”的累计协同单总数
742
743 === ===
744
745 === 1.11.3.超诊断时限协同统计报表 ===
746
747 |(% rowspan="2" %)**类别** |(% rowspan="2" %)**子类** |(% rowspan="2" %)**超诊断时限协同总数**|(% colspan="3" %)**各部门超时协同数量**
748 |**电渠室**|**经分室**|**规划室**
749 |(% rowspan="6" %)需求类|计费帐务类  | | | |
750 |营业类  | | | |
751 |客服类| | | |
752 |电子渠道类  | | | |
753 |经分类  | | | |
754 |接口类  | | | |
755 |(% rowspan="4" %)工程类|全网工程类| | | |
756 |软件系统架构调整| | | |
757 |硬件系统架构调整| | | |
758 |性能与容量| | | |
759 |(% rowspan="5" %)运维类|主机类  | | | |
760 |网络类  | | | |
761 |中间件类  | | | |
762 |物理环境类  | | | |
763 |数据库类| | | |
764 |其他类| | | | |
765
766 |**序号**|**指标名称**|**指标计算说明**
767 |(% rowspan="3" %)1|(% rowspan="3" %)超时协同数量|数量：在问题单中根据以下条件过滤
768 |1.【登记时间】在统计周期内
769 |2. 包含未关闭的处理中的以及已经关闭的超过诊断时限的协同数量
770
771
深圳市艾拓先锋企业管理咨询有限公司