由 superadmin 于 2024/12/25, 15:38 最后修改
Show last authors
1 {{info}}
2
3 {{/info}}
4
5
6 **申明：**
7
8 本系列ITIL 4中文版本由长河领导的ITIL先锋论坛专家委员会组织翻译，国内众多从事ITIL理论推广及落地实践的专家们参与。需要下载最新翻译版本请关注微信公众号：**ITILXF**，并回复“**问题管理**”即可。
9
10
11 请注意，ITIL先锋论坛专家团队仅仅只是进行了这些著作的语种转换工作，我们并不拥有包括原著以及中文发行文件的任何版权，所有版权均为Axoles持有，读者在使用这些文件（含本中文翻译版本）时需完全遵守Axoles 和 TSO所申明的所有版权要求。
12
13
14 本文档翻译工作参与人员：
15
16 翻译：孔彦波
17
18 审校：刘雨龙
19
20
21 总审：长河
22
23 审核：王庆、李坤
24
25 统筹：常宏
26
27
28
29 ----
30
31 {{box cssClass="floatinginfobox" title="**Contents**"}}
32 {{toc/}}
33 {{/box}}
34
35 = **1. 关于本文件** =
36
37 本文档提供问题管理实践实用指南，分为五个主要部分，涵盖：
38
39 * 本实践的一般信息
40 * 本实践相关的流程和活动及其在服务价值链中的作用
41 * 参与本实践的组织和人员
42 * 支持实践的信息和技术
43 * 对本实践的合作伙伴和供应商的考虑
44
45 == **1.1 ITIL4资格认证计划** ==
46
47 本文件中所选内容可作为以下教学大纲的一部分进行考查：
48
49 * ITIL专家创建、交付和支持
50
51 详情请参阅教学大纲文件。
52
53
54
55 ----
56
57 = **2. 一般信息** =
58
59
60 == **2.1** **目的和描述** ==
61
62 **关键信息**
63
64 问题管理实践的目的是通过查明事件的实际和潜在原因，以及管理临时解决方案和已知错误，减少事件发生的可能性及其影响。
65
66 没有完美的服务。每个服务都存在可能导致事件的错误或缺陷。错误可能源于服务管理四维模型中的任何一个维度。例如，第三方合同中的错误与组件故障一样可能导致事件。许多错误在服务上线之前就能被识别出来，然后在设计、开发或测试期间得到解决。但是，有一些仍未被发现，将存在生产环境中，它们可能会导致事件产生。为了管理生产环境中出现的错误，组织开发了问题管理实践。该实践旨在识别和分析组织产品中的错误，以最大程度地减少其对所提供服务的负面影响。
67
68
69 == **2.2 术语和概念** ==
70
71 可能导致（或已经导致）事件的错误称为问题。
72
73
74 **​​​​​​​​​​​​​​定义：问题**
75
76 一个或多个事件的原因或潜在原因。
77
78 问题管理实践有三个不同的阶段，如图2.1中所示。
79
80 (% style="text-align:center" %)
81 [[image:1639732499315-764.png]]
82
83 图2.1 问题管理实践的三个阶段
84
85
86 === **​​​​​​​2.2.1 问题识别** ===
87
88 有两种主要方法来识别问题。第一种方法是调查已经发生的事件的原因。这种方法先要了解症状，再了解原因。它目的是防止事件再次发生，也可能有助于解决处于解决中的事件。这称为被动问题管理，因为它是对事件的被动反应。
89
90 第二种方法是在问题导致事件发生之前识别到它，评估相关风险，并优化响应，以最小化事件发生的可能性和/或影响。这称为主动问题管理，基于有关问题的信息，尤其是在生产环境中可能存在的问题。这些信息来源可能包括：
91
92 * 供应商告知其产品中的漏洞
93 * 开发人员、设计人员或测试人员在使用下一版本时发现生产版本中的错误
94 * 用户和专家社区分享其他组织的经验
95 * 基础设施的监控发现系统性能中的偏差，但这些偏差还不属于事件
96 * 技术审计和其他评估
97
98 问题管理实践总是被动的对问题作出反应：它不能防止问题的第一次出现。主动与被动的区别是指问题调查与事件之间的关系：
99
100 * 主动问题管理有助于预防事件第一次发生
101 * 被动问题管理有助于预防事件再次发生，并可能有助于解决进行中的事件
102
103 === **​​​​​​​2.2.2 问题控制** ===
104
105 问题识别使得问题被登记形成问题记录。可能形成一系列待分析问题列表。已记录的问题将根据其最初的分类和优先级进行分析。问题完成分析之后，问题初始分类很可能会发生改变，特别是基于事件（症状）信息登记的问题。
106
107
108 **​​​​​​​定义**
109
110 **任务优先级**是一个任务相较于其他任务的重要性。具有更高优先级的任务应优先被处理。优先级基于待办事项中所有任务的情况来定义。无法为待办事项中所有的任务分配资源时，通过**优先级排序**选择优先要处理的任务。
111
112 问题控制专注于问题的分析。在被动问题管理中，问题分析可使用关于产品架构和配置的信息来识别可能导致相关事件的配置项（CI）。分析不限于配置项，还包括其它因素，例如：用户行为、人为错误和规程错误等。
113
114 主动问题管理通常从更好地掌握配置项和服务管理四维模型中所有维度开始，这些组件可能导致事件。例如，如果供应商将其软件中的漏洞告知组织，则问题控制的任务将是掌握组织使用该软件的情况，以便评估与漏洞相关的风险以及对所提供服务的潜在影响。
115
116 对问题完成分析后，将为其分配为“ 已知错误”状态。
117
118
119 **​​​​​​​定义：已知错误**
120
121 已经分析过但尚未解决的问题。
122
123
124 **问题优先级**
125
126 问题很多属于低紧急度。服务团队有一些更紧迫的任务需要完成，使得紧急度低的问题在待办事项中总处于保持的状况。但是，确保对识别到的问题进行分析和解决是非常重要的。从中长期的角度来看，问题既影响所提供的服务的质量，也影响服务提供者的工作量。
127
128 问题优先级划分有许多简单的准则：
129
130 * 评估问题的影响度和紧急度（以及调查和解决的时间限制），评估结果可用于确定优先级和其他重要的考虑因素，例如，预估完成工作所需的时间
131 * 只有存在资源冲突时才需要确定优先级。当有足够的资源在有限的时间内处理每一项任务时，优先级排序不是必须的
132 * 应该使用包含其他任务（计划内的和计划外）的统一待办事项来计划问题处理
133 * 优先级排序是为团队内部成员分配任务的一种工具。如果问题由多个团队处理，则可根据每个团队的资源可用性、目标完成时间以及预计处理时间来确定优先级。
134 * 资源可用性和预计处理时间由团队定义。目标完成时间取决于问题的影响，当问题被确定并初步分类时，它可能被定义。随着问题分析过程中发现新的信息，问题的影响，预计完成（解决）时间可能会发生变化
135 * 可视化工具（例如，看板和精益原则，限制进行中任务数量）有助于有效的优先级排序
136
137 这些规则适用于服务提供者的专业团队执行的所有类型的工作（计划的和计划外的）。重要的是，在所有实践中涉及组织服务管理活动的每个人都应该同意并遵循它们。
138
139 这些规则适用于服务提供商的专家团队执行的所有类型的工作(计划的和计划外的)。重要的是，在所有实践中，参与组织服务管理活动的每个人应达成一致，并遵循它们。
140
141 问题分析过程中可能会发现错误已经从组织的环境中消除，或者它们不会影响所提供的服务。根据上面的示例，组织可能未使用该软件易受攻击的版本，或者漏洞可能不会影响组织的服务。在这些情况下，问题记录经过分析后可以设置为已关闭。在其他情况下，它可能保持处理状态，并启动错误控制。
142
143 问题控制其他的重要输出可能是解决事件的建议。通常，了解导致事件的原因有助于，为处理事件提出更有效的解决方案，包括临时解决方案。
144
145
146 **​​​​​​​定义：临时解决方案**
147
148 减少或消除尚未获得永久解决方案的事件或问题的影响的解决方案。一些临时解决方案可以降低事件发生的可能性。
149
150 请注意，从问题分析得出的临时解决方案通常不会减少发生事件的可能性，而是，有助于在事件发生时，更快、更好地解决事件。有助于防止事件再次发生的临时解决方案通常在错误控制阶段被找到。
151
152
153 === **​​​​​​​2.2.3 ​​​​​​​错误控制** ===
154
155 对问题进行分析后（如，产品中的错误对组织自身服务的影响已经被评估），应该对其进行控制。仅当满足以下条件之一时，问题记录才可能关闭：
156
157 * 问题被解决：与问题相关事件的风险被移除，或降低到可接受的水平。
158 * 问题不再影响组织。
159
160 请注意，尽管“ 已知错误”是问题的状态，但是某些组织更喜欢使用独立的记录来进行问题控制和错误控制。在这些情况下，当问题分析完成时，问题记录可能被关闭，并且随后的活动可能被登记到相关的已知错误记录中。上述关闭条件适用于已知错误，无论它们是否是问题。
161
162 如果许多已知错误无法得到有效解决，并且它们会继续影响服务，那么它们将长期处于未关闭状态。在这些情况下，组织可能集中精力，最大程度地提高事件处理的效果和效率（有时达到完全自动检测和解决的水平），但问题记录应保持未关闭状态，并定期进行审查。
163
164 如果解决问题的成本高于处理已知错误或有效事件管理的成本时，则上述错误控制方法是有效的。这通常用于与第三方组件相关的典型问题，尤其是在第三方无响应或组件不受支持的情况下。相反，如果组件可用于改进并可以进行改进时（特别是在组织自己控制下的软件），则应迅速消除已知错误。
165
166 已知错误是组织技术债务的一部分，应在合理可行的情况下予以消除。
167
168
169 **​​​​​​​​​​​​​​定义：技术债务**
170
171 选择临时解决方案，而不是需要花费更长的时间的系统性解决方案。
172
173 错误控制确保组织拥有与其产品相关的已知错误有足够的最新信息，包括它们的状态及对服务的影响。
174
175 错误控制对问题解决方案进行了优化，使其成本、负面影响、正面影响相平衡。
176
177 定期检查已知错误有助于识别环境中的变化（例如，业务影响、永久解决方案的可用性和相关成本，以及资源可用性等），这些变化可能会导致对错误的重新评估，并启动错误的解决。
178
179 错误控制的关键输出是改进措施和变更请求，它们启动问题的解决。某些解决方案修复了配置项和其他产品组件中的错误。其他的可能会引入永久的变通方法：对产品配置的更改不会修复错误，但可以将事件发生的可能性降到最低，相关的问题记录可能会被关闭。保持错误相关知识的可用性是很重要的，这些知识对于将来的服务设计以及规划可能非常有价值。
180
181 永久性变通方法通常用于组织无法修复的组件（旧系统、第三方提供的工程基础结构等）。但是，使用永久性变通方法来防止事件会增加组织的技术债务。因此，应尽可能避免使用。
182
183 总而言之，表2.1中列出了消减问题的可能类型。
184
185
186 表 2.1 问题消减的方法  
187
188 [[image:1639732688979-363.png]]
189
190
191 === **​​​​​​​2.2.4** **问题模型** ===
192
193 不同的问题来源和类型可能需要不同的方法来识别和控制问题。例如，以下类型问题中的一种或多种可能对问题管理实践需要特殊的处理方法。这些问题包括以下方面：
194
195 * 软件
196 * 硬件
197 * 程序
198 * 第三方组件
199 * 消费者的资源
200 * 数据
201 * 数据与敏感信息相关
202 * 高度规范的服务和系统
203
204 为了优化这些问题和其他类型问题的处理与解决，服务提供者通常定义问题模型。问题模型有助于有效地管理问题，由于应用程序相关的经过验证和测试的方法，通常可以得到更好的结果。
205
206
207 **​​​​​​​​​​​​​​定义模型**
208
209 一种管理特定类型问题的可重复方法。
210
211 问题模型的创建和使用对于问题管理实践中的活动很重要。它们将在第3节中进行介绍。
212
213
214
215 == **​​​​​​​2.3 ​​​​​​​范围** ==
216
217 问题管理实践的范围包括：
218
219 * 问题的识别与分析，包括已知错误的分析与控制
220 * 启动变更以消除或减少问题的影响
221 * 向干系人提供有关问题信息
222 * 监控错误和持续改进解决方法
223
224 有一些活动和责任范围不包括在问题管理实践中，尽管它们仍然与问题密切相关。表2.2中列出了这些内容，以及对可以找到它们的实践的引用。重要的是要记住，ITIL实践只是价值流的背景中使用的工具的集合，应根据情况需要将它们组合在一起。
225
226 表2.2 与其他实践指南中描述的问题管理实践相关的活动
227
228 (% style="width:560px" %)
229 |(% style="width:276px" %)**实现价值**|(% style="width:283px" %)**实践指南**
230 |(% style="width:276px" %)事件解决|(% style="width:283px" %)事件管理
231 |(% rowspan="4" style="width:276px" %)控制和实现为解决问题而启动的变更|(% style="width:283px" %)变更启动部署管理
232 |(% style="width:283px" %)基础设施和平台管理发布管理
233 |(% style="width:283px" %)软件开发和管理
234 |(% style="width:283px" %) 其他做法
235 |(% style="width:276px" %)风险评估和控制|(% style="width:283px" %)风险管理
236 |(% rowspan="3" style="width:276px" %)检测和控制产品在部署到运行环境之前的错误|(% style="width:283px" %)部署管理服务设计
237 |(% style="width:283px" %)服务验证和测试
238 |(% style="width:283px" %)软件开发和管理
239 |(% style="width:276px" %)沟通事件的解决方法给用户|(% style="width:283px" %)服务台
240
241 == **​​​​​​​2.4 实践成功因素** ==
242
243 **​​​​​​​定义：实践成功因素**
244
245 达成实践目标所必须的一系列复杂功能组件
246
247 实践成功因素（PSF）不仅是一个任务或活动，还包含所有服务管理思维模型组件。实践中PSF的活动和资源的性质可能有所不同，但它们共同确保了实践有效。
248
249 问题管理实践包含以下成功因素（PSF）：
250
251 * 识别并了解问题及其对服务的影响
252 * 优化问题解决和消解措施。
253
254 === **​​​​​​​2.4.1** **识别并理解问题及其对服务的影响** ===
255
256 组织应该掌握其产品中的存在错误。因为，它们可能导致事件并影响服务质量和客户满意度。问题管理实践确保问题被识别，从而有助于持续改进的产品和服务。如果是主动执行而不是被动执行，这将更加有效。
257
258
259 === **​​​​​​​2.4.2** **优化问题解决和消解措施** ===
260
261 发现问题后，应有效和高效地进行处理。修复（消除）组织产品中的所有问题几乎是不可能的，但是，对于组织及其客户而言，没有解决方案的问题识别，其价值就会大大降低。应该为问题消解定义一种平衡的方法，即一种考虑相关成本，风险和对服务质量的影响的方法。
262
263
264
265 == **​​​​​​​2.5** **关键指标** ==
266
267 ITIL实践的绩效应在每种实践所贡献的价值流的背景下进行评估。与任何工具的表现一样，该实践的表现只能在其应用范围内评估。但是工具的设计和质量会有很大差异，这些差异定义了不同用途下的潜力或能力。有关度量、绩效（KPI）和其他有助于实现这一目标的其他技术，请参见《度量和报告实践指南》。
268
269 问题管理实践的关键指标已映射到其PSF。 它们可以用作价值流中的KPI，以评估实践对这些价值流的有效性和效率的贡献。 表2.3中给出了一些关键指标的示例。
270
271 表2.3 实践成功因素的关键指标示例
272
273 [[image:1639732840425-688.png]]
274
275 将度量指标正确汇总到复杂的指标中，才更易于将数据用于正在进行的价值流管理，更利于问题管理实践的定期评估和持续改进。这并没有单一的最佳解决方案。度量标准将基于组织的整体服务战略和优先级，以及实践贡献的价值流的目标。
276
277
278
279
280 ----
281
282 = **3. 价值流和流程** =
283
284
285 == **​​​​​​​3.1 ​​​​​​​价值流贡献** ==
286
287 与任何其他ITIL 管理实践一样，问题管理实践也有助于实现多个价值流。请谨记单一实践不会形成价值流。问题管理实践与其他实践相结合，可以为消费者提供高质量服务。实践贡献的主要价值链活动是：
288
289 * 交付和支持
290 * 改进
291
292 问题管理实践对服务价值链的贡献如下图片3.1 所示：
293
294 (% style="text-align:center" %)
295 [[image:1639732920116-788.png]]
296
297 图3.1 问题管理实践对价值链的贡献的热图活动
298
299
300
301 == **​​​​​​​3.2 ​​​​​​​流程** ==
302
303 每个实践可能包含一个或多个流程和活动，它们对于实现该实践的目的可能是必需的。
304
305
306 **​​​​​​​定义：流程**
307
308 一组相互关联或交互的活动，可将输入转化为输出。一个流程接受一个或多个已定义的输入并将其转换为输出。流程根据活动的顺序与依赖性定义次序。
309
310 问题管理活动分为四个过程：
311
312 * 主动问题识别
313 * 被动式问题标识
314 * 问题控制
315 * 错误控制
316
317 === **​​​​​​​3.2.1** **主动问题识别** ===
318
319 该流程包括表3.1中列出的活动，并将输入转换为输出。
320
321 表3.1 主动问题标识流程的输入活动和输出
322
323 (% style="width:820px" %)
324 |(% style="width:351px" %)**关键输入**|(% style="width:205px" %)**活动**|(% style="width:263px" %)**关键输出**
325 |(% style="width:351px" %)(((
326 来自供应商和供应商的错误信息
327
328 有关专家团队提交的潜在错误的信息
329 )))|(% rowspan="4" style="width:205px" %)(((
330 评审的提交信息
331
332 问题登记
333
334 问题的初步分类和分派
335
336
337 )))|(% rowspan="4" style="width:263px" %)问题记录反馈给问题发起者
338 |(% style="width:351px" %)外部用户和专业团体提交的有关潜在错误的信息
339 |(% style="width:351px" %)用户提交的有关潜在错误的信息监控数据
340 |(% style="width:351px" %)服务配置数据
341
342 图3.2 显示了流程的工作流程图。
343
344
345 (% style="text-align:center" %)
346 [[image:1639733001742-715.png]]
347
348 图3.2 主动问题识别流程的工作流程
349
350 主动问题用于识别到组织产品中存在的，来源于事件记录以外的潜在错误。可以考虑将问题的主动标识和控制作为风险管理的一种形式执行，即重点关注组织产品中的漏洞，它包括对漏洞和相关风险的识别、评估和分析。
351
352 表3.2 中列出了组织产品相关错误可能的信息来源。
353
354 表3.2 主动识别问题的信息来源 
355
356 [[image:1639733031760-434.png]]
357
358
359 主动的风险管理活动应尽可能的专注于对组织及其客户具有最大潜在影响的关键系统和组件。
360
361 然而，其他系统中错误的迹象不应被忽视。在为提高可用性而设计的复杂技术环境中，导致事件可能有多种原因，这些原因通常是各类因素组合后产生的结果。非核心系统中，看似不重要的错误可能导致严重事件。主动问题识别应包括对已识别漏洞的发生概率和影响进行仔细评估。
362
363 表3.3提供了流程活动的示例。
364
365 表3.3 主动问题识别过程的活动
366
367 [[image:1639733057971-341.png]]
368
369 表3.3 主动问题识别过程的活动
370
371
372 谁可以登记问题？
373
374 有几种方法可以分配问题登记的职责。一种方法是鼓励每一位专家提出并登记问题。这将增加改进的数量，并提高组织产品中错误的可见性。
375
376 但是，这可能会显著增加登记问题的数量，没有人关注这些问题，或者这些问题被错误地分类了。为防止这种情况发生，一些组织更愿意让一个或多个角色负责对潜在问题的初始筛选并进行登记。只要角色中的人员拥有所需的资源，并且可以使来自各种来源的流程信息一致且透明地进行，此方法就有效。
377
378
379 === **​​​​​​​​​​​​​​3.2.2** **被动问题识别** ===
380
381 该流程包括表3.4中列出的活动，并将输入转换为输出。
382
383 表3.4 被动问题识别过程的输入，活动和输出
384
385 (% style="width:521px" %)
386 |(% style="width:229px" %)**关键输入**|(% style="width:153px" %)**活动**|(% style="width:137px" %)**关键输出**
387 |(% style="width:229px" %)(((
388 有关持续事件的信息
389
390 事件记录和报告监控数据
391
392 服务配置数据
393
394 服务级别协议（SLA）
395 )))|(% style="width:153px" %)(((
396 问题登记
397
398 问题初步分类与分派
399 )))|(% style="width:137px" %)问题记录
400
401 被动问题识别过程的工作流程图如下图3.3所示：
402
403 (% style="text-align:center" %)
404 [[image:1639733098725-460.png]]
405
406
407 被动问题识别使用过去或正在发生事件的相关信息来调查其原因。可能问题是在诊断分析发生中事件的性质遇到难题而触发的。在这种情况下，问题识别和控制可能很紧急，事件管理和问题管理实践在同一个价值流中，同时，它们需要相同（或重叠）的资源，包括团队，工具和过程。
408
409 基于对过去事件的分析时，问题的识别可能包括：基于各种角度的统计分析、影响分析和趋势分析。这是为了识别具有可能的共同原因或其他相关性的一组事件。
410
411 过程随触发点不同而略有差异。表3.5中说明了这些差异。
412
413 表3.5 被动问题识别过程的活动
414
415 [[image:1642236652061-588.png]]
416
417 [[image:1642236633390-520.png]]
418
419
420 === **​​​​​​​3.2.3** **问题控制** ===
421
422 该流程专注于问题的调查。它包括表3.6中所示的活动，并将输入转换为输出。
423
424 表3.6 问题控制过程的输入活动和输出
425
426 (% style="width:532px" %)
427 |(% style="width:256px" %)**关键输入**|(% style="width:147px" %)**活动**|(% style="width:127px" %)**关键输出**
428 |(% style="width:256px" %)(((
429 问题记录
430
431 服务配置数据
432
433 配置项、产品和服务等技术信息
434
435 事件记录
436
437 监控数据
438 )))|(% style="width:147px" %)(((
439 问题调查
440
441 已知错误沟通
442 )))|(% style="width:127px" %)(((
443 问题记录
444
445 已知错误
446
447 事件解决方案
448 )))
449
450 图3.4显示了问题控制流程的工作流程图。
451
452 图3.4 问题控制流程的工作流程
453
454
455 (% style="text-align:center" %)
456 [[image:1639733148807-930.png]]
457
458 表3.7提供了流程活动的示例。
459
460 表3.7 问题控制流程的活动
461
462 [[image:1639733190223-917.png]]
463
464 组织使用各种分析技术进行问题调查。这些可能包括：
465
466 * 根本因分析技术，例如5 Whys分析法、K&F分析以及故障分析树
467 * 影响分析技术，例如组件失效影响分析、业务影响分析
468 * 风险分析技术。
469
470 记住以下一点很重要。单一根源的情况在复杂的、不断发展的环境中具有非常有限的适用性。事件常常是由不可预料的因素经过预料之外的组合后导致的。因此，对问题的调查（尤其是在被动问题管理中）不应仅限于确定事件的一项可能原因。问题调查应始终考虑整个服务管理四维模型。可以在补充ITIL出版物中找到有关使用特定技术进行问题调查的进一步指南。
471
472
473 === **​​​​​​​​​​​​​​3.2.4** **错误控制** ===
474
475 这一过程的重点是监测和控制已知错误（已分析但尚未解决的问题）的状况及其解决方案。它有助于确保已知错误对服务的负面影响得以掌握并使其最小化；有关事件的解决方案是有效的；已知错误的缓解方法是有效的，可行且高效的。
476
477 该流程包括表3.8中所示的活动，并将输入转换为输出。
478
479 表3.8 错误控制的输入活动和输出流程
480
481 (% style="width:453px" %)
482 |(% style="width:145px" %)**关键输入**|(% style="width:177px" %)**活动**|(% style="width:129px" %)**关键输出**
483 |(% style="width:145px" %)(((
484 问题记录
485
486 服务配置数据
487
488 配置项、产品和服务等技术信息
489
490 事件记录
491
492 监控数据
493
494 知识管理数据
495 )))|(% style="width:177px" %)(((
496 问题解决方案开发
497
498 问题解决启动
499
500 已知错误监控和检查
501
502 问题关闭
503 )))|(% style="width:129px" %)(((
504 问题记录
505
506 问题型号
507
508 变更请求
509
510 改进计划
511
512 问题解决方案
513 )))
514
515 图3.5显示了流程的工作流程图。
516
517 图3.5 错误控制的工作流程
518
519 (% style="text-align:center" %)
520 [[image:1639733225356-658.png]]
521
522
523 表3.9提供了流程活动的示例。
524
525
526 表3.9 错误控制的活动流程
527
528 [[image:1642236751919-789.png]]
529
530 [[image:1642236783017-518.png]]
531
532 [[image:1642236807230-396.png]]
533
534 问题管理活动由服务提供者执行，如表3.3、3.5、3.7和3.9中所述。他们可能涉及供应商和合作伙伴，甚至有时还涉及客户和用户。这些活动可以利用工具和技术支持开展（有时甚至是全自动化或很高程度的自动化）。这些将在以下部分中进行阐述。
535
536
537
538
539 ----
540
541 = **4. 组织和人员** =
542
543
544 == **​​​​​​​4.1** **角色，能力和责任** ==
545
546 实践指南没有描述实践管理的角色，例如实践负责人，实践主管或实践教练。相反，他们专注于每个实践的专家角色。组织不同，每个角色的结构和命名也可能不同，因此ITIL中定义的任何角色都不应被视为强制性的，甚至不应被视为推荐性的。请记住角色不是职务。一个人可以担任多个角色，一个角色也可以分配给多个人。
547
548 角色是关联到流程和活动中来描述的。每个角色都具有基于表4.1中所示的模型的能力概况特征。
549
550 表4.1 能力代码和描述
551
552 |能力代码|能力概况（活动和技能）
553 |L|**领导者 **决策、授权、监督其他活动，激励团队，提供动力以及评估结果
554 |A|**管理员** 分配任务并确定优先级，保留记录，持续报告并启动基本的改进
555 |C|**协调员/沟通者** 多方协调，维护干系人之间的沟通，并负责有关认知的宣传活动
556 |M|**方法和技术专家** 设计和实施技术工作，编织规范文档，提供流程、工作分析和持续改进的咨询
557 |T|**技术专家** 提供技术（IT）专业知识，并执行基于专业知识的任务
558
559 在组织中可以设定两个实践特定的角色：问题经理和问题协调人。这些角色通常在问题数量很多的组织中引入。在其他组织中，问题管理活动由负责与问题关联配置项的服务或产品的个人或团队协调。，可能是资源所有者，服务负责人或产品负责人。
560
561
562 === **​​​​​​​4.1.1** **问题经理角色** ===
563
564 在定义专门的问题经理角色的情况下，通常将其分配给专家，这些专家结合了组织产品（架构，配置和相互依赖性）的丰富知识以及扎实的分析技能（协调团队合作并提供出色风险管理的能力和权威）。该角色的能力概要是TMAC。角色通常负责管理和协调问题管理流程中的专家活动，包括：
565
566 * 根据提交的信息进行和协调问题登记
567 * 问题的初步分类
568 * 与负责事件解决和变更实施的团队协调沟通
569 * 开发和交流问题模型（如适用）
570 * 协调已知错误监视和评审
571 * 问题规范的关闭
572
573 === **​​​​​​​4.1.2 ​​​​​​​问题协调人角色** ===
574
575 在较复杂的组织中，问题管理实践的某些职责可以委托给问题协调人。问题协调人专注规范的问题管理，例如，对提交的关于可能出现的问题的信息评审、问题评审和问题关闭。
576
577 表4.2中列出了问题管理活动中可能涉及的其他角色的示例，以及相关的能力概况和特定技能。
578
579 表4.2 负责问题管理活动的角色示例
580
581 [[image:1642236862713-306.png]]
582
583 [[image:1642236898589-438.png]]
584
585 [[image:1642236931692-643.png]]
586
587 [[image:1642236958142-525.png]]
588
589
590
591 == **​​​​​​​4.2** **组织结构和团队** ==
592
593 尽管问题管理的角色有时与正式职称相关联，但问题管理实践的专用组织结构却很少见。这对于具有复杂官僚机构和大量需要管理的问题的组织来说是典型的。许多组织发现组建临时团队调查影响度高的问题和/或开发解决方案很有用。
594
595 在以产品为中心的组织中，通常不采用问题管理工作的头衔和角色。相反，这种实践被集成到产品开发和管理团队的日常活动中。它在任何可能的地方都是自动化的。
596
597
598
599 ----
600
601 = **5. 信息和技术** =
602
603
604 == **​​​​​​​5.1 信息交流** ==
605
606 问题管理实践的有效性取决于所使用信息的质量。该信息包括但不限于以下信息：
607
608 * 产品和服务及其架构和设计，包括配置信息
609 * 客户和用户
610 * 合作伙伴和供应商，包括有关它们提供的服务的合同和SLA信息
611 * 正在进行和发生的事件
612 * 计划的，正在进行的和发生的变更
613 * 第三方的产品和组件，包括漏洞和事件。
614
615 这些信息可能以各种形式出现。实践的关键输入和输出在第3节中列出。
616
617
618
619 == **​​​​​​​5.2 ​​​​​​​自动化和工具** ==
620
621 在大多数情况下，问题管理实践可以从自动化中受益匪浅。在可行且有效的情况下，可能涉及表5.1中概述的解决方案。
622
623 表5.1 问题管理活动的自动化解决方案
624
625 [[image:1642237130977-375.png]]
626
627 [[image:1642237200059-275.png]]
628
629 [[image:1642237214689-525.png]]
630
631
632
633
634 ----
635
636 = **6. 合作伙伴和供应商** =
637
638 组织完全使用自己资源提供服务的这种情况很少。大多数(不是全部)依赖于其他服务。这些通常:是由第三方提供的(请参阅ITIL Foundation：ITIL 4 Edition的2.4节服务关系的模型)。在实践指南中，针对服务设计、架构管理和供应商管理引入了支持服务的依赖关系。所有问题管理流程中都使用了有关对第三方服务的依赖性的信息。
639
640 问题管理实践通常会发现组织使用的第三方产品中的错误。解决这些错误的可能性以及解决方案的有效性，取决于多种因素，包括：
641
642 * 解决方案的架构
643 * 供应商的灵活性
644 * 供应商与组织的服务关系的重要性
645 * 合同条款和条件
646
647 了解组织如何依赖第三方组件，以及如何与包括问题管理实践在内的许多活动的主要供应商和合作伙伴建立有效，高效的协作至关重要。
648
649 问题模型应定义第三方如何参与问题控制，以及组织如何确保有效的协作。这取决于产品，服务和价值流的架构和设计解决方案。通常，在为问题选择了正确的模型之后，需要在问题和错误控制过程中进一步考虑第三方依赖关系。
650
651 当组织的目标是确保快速和有效的问题管理时，他们通常试图与合作伙伴和供应商达成紧密合作，消除沟通，协作和决策制定方面的正式官僚障碍（有关更多信息，请参见供应商管理实践指南）。
652
653
654
655
656 ----
657
658 = **7. 重要提醒** =
659
660 实践指南的大部分内容都可以作为组织在建立和培养自己实践时提供可参考的建议。实践指南为组织提供了解决问题的框架，而不是答案本身。使用实践指南时，组织应始终遵循ITIL指导原则：
661
662 * 专注于价值
663 * 从你现在的位置开始
664 * 基于反馈迭代推进
665 * 协作并提升可视化程度
666 * 通盘思考和工作
667 * 保持简单实用
668 * 优化和自动化。
669
670 有关指导原则及其应用程序的更多信息，请参见ITIL 4基础版中的第4.3节
671
672
673
674 ----
675
676 = **8. 致谢** =
677
678 AXELOS Ltd非常感谢为本指南的开发做出贡献的每一个人。这些实践指南融合了ITIL社区前所未有的热情和反馈。AXELOS特别要感谢以下人员。
679
680
681 == **​​​​​​​8.1** **作者** ==
682
683 Barry Corless, Roman Jouravlev, Andrew Vermes.
684
685
686 == **​​​​​​​8.2** **审稿人** ==
687
688 James Ainsworth，Akshay Anand，Sofi Fahlberg，Michael G.Hall，Steve Harrop，Piia Karvonen，Anton Lykov，PaulaMättänen，Caspar Miller，Christian F.Nissen，Mark O'Loughlin，Tatiana Orlova，Elina Pirjanti，Stuart Rance。
深圳市艾拓先锋企业管理咨询有限公司