Show last authors
1 {{box cssClass="floatinginfobox" title="**Contents**"}}
2 {{toc/}}
3 {{/box}}
4 (% class="jumbotron" %)
5 (((
6 (% class="container" %)
7 (((
8 = =
9
10
11
12 需要下载 **ITIL 4服务请求管理实践【中文】**pdf版全文,请关注微信公众号itilxf ,并回复“服务请求”即可。
13
14
15 [[image:微信图片_20200929154759.png]]
16
17
18
19 **申明:**
20
21 本系列ITIL 4实践中文版本由ITIL先锋论坛专家委员会组织翻译,国内众多从事ITIL理论推广及落地实践的专家们参与,需要下载最新翻译版本请关注微信公众号:ITILXF,也可访问ITIL4中文知识库网站:itil4hub.cn。
22
23 请注意,ITIL先锋论坛专家团队仅仅只是进行了这些著作的语种转换工作,我们并不拥有包括原著以及中文发行文件的任何版权,所有版权均为Axoles持有,读者在使用这些文件(含本中文翻译版本)时需完全遵守Axoles 和 TSO所申明的所有版权要求。
24
25
26 **翻译**:邹庆海 **审校**:卢曦 **审核**:刘晓慧
27 )))
28 )))
29
30 = **1 关于本文档** =
31
32 [[编辑>>url:http://itil4hub.cn/bin/edit/03%20%E6%9C%8D%E5%8A%A1%E8%AF%B7%E6%B1%82%E7%AE%A1%E7%90%86/1%20%E5%85%B3%E4%BA%8E%E6%9C%AC%E6%96%87%E4%BB%B6/WebHome?section=1]]
33
34 本文档为服务请求管理实践提供了实践指南,内容分为五个主要部分,包括:
35
36 1. 实践的基本信息
37 1. 实践的流程和活动以及它们在服务价值链中的作用
38 1. 实践中涉及的组织和人员
39 1. 支持实践的信息和技术
40 1. 实践中关于合作伙伴和供应商的注意事项
41
42 == ==
43
44 [[编辑>>url:http://itil4hub.cn/bin/edit/03%20%E6%9C%8D%E5%8A%A1%E8%AF%B7%E6%B1%82%E7%AE%A1%E7%90%86/1%20%E5%85%B3%E4%BA%8E%E6%9C%AC%E6%96%87%E4%BB%B6/WebHome?section=2]]
45
46 == 1.1 ITIL®4 认证方案 ==
47
48 [[编辑>>url:http://itil4hub.cn/bin/edit/03%20%E6%9C%8D%E5%8A%A1%E8%AF%B7%E6%B1%82%E7%AE%A1%E7%90%86/1%20%E5%85%B3%E4%BA%8E%E6%9C%AC%E6%96%87%E4%BB%B6/WebHome?section=3]]
49
50 本文档中节选的内容可作为以下课程的一部分进行考核:
51
52 1. ITIL专家 创建、交付和支持
53 1. ITIL专家 高速IT
54
55 详细信息请参阅相应的教学大纲。
56
57
58 ----
59
60 (% style="color:#2d2d2d; font-size:29px" %)**2 基本信息**
61
62 [[编辑>>url:http://itil4hub.cn/bin/edit/03%20%E6%9C%8D%E5%8A%A1%E8%AF%B7%E6%B1%82%E7%AE%A1%E7%90%86/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=1]]
63
64 == 2.1 目的与描述 ==
65
66 [[编辑>>url:http://itil4hub.cn/bin/edit/03%20%E6%9C%8D%E5%8A%A1%E8%AF%B7%E6%B1%82%E7%AE%A1%E7%90%86/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=2]]
67
68 |(((
69
70
71 定义:服务请求
72
73 用户或用户授权代表发起的服务动作的请求,该服务动作已约定为服务交付的正常部分。
74 )))
75
76 |(((
77 关键信息
78
79 服务请求管理实践的目的是通过有效、友好的方式处理所有约定的、用户发起的服务请求,以此来支持约定的服务质量。
80 )))
81
82 服务请求是用户问询的重要类型,也是用户体验的重要组成部分。通常,服务请求包括以下内容:
83
84 1. 发起服务动作请求(由服务提供者或与用户一起执行)
85 1. 信息请求
86 1. 资源或服务访问请求
87 1. 反馈,表扬或投诉
88
89 服务请求的履行可能涉及对服务或其组件的变更,通常属于标准变更。由于服务请求是预定义的,并且已约定为服务交付的正常部分,因此通常可以通过明确的启动,批准,履行和管理的标准规程,来对其进行标准化。某些服务请求具有非常简单的工作流,例如信息请求。其他服务请求(例如,为新员工设置信息)可能很复杂,需要多个团队和系统的合作才能履行。无论复杂性如何,履行请求的步骤都应该是众所周知并经过测试的。这使得服务提供者可以约定履行请求的时间,并向用户提供服务请求状态的清晰沟通。
90
91 服务规程的开发和测试在产品和服务生命周期的相应阶段执行,涉及多种实践,其中包括业务分析,服务设计,风险管理,变更使能,服务目录管理和服务级别管理等。
92
93 根据财务、信息安全或其他策略要求,某些服务请求需要授权。为了恰当地处理此类请求,服务请求管理实践应该遵循以下准则:
94
95 * 服务请求及履行应尽可能标准化和自动化
96 * 对于可以通过有限的或无需额外批准就可以履行的服务请求,应制定策略以提高效率
97 * 应根据组织的交付能力明确设定用户对履行时间的期望
98 * 应识别改进服务的机会并加以实施,以加快履行速度和进一步利用自动化
99 * 应制定策略和工作流,以便对作为服务请求提交的事件或变更请求进行记录和转单
100
101 某些服务请求完全可以自动化履行从提交到关闭的过程,以提供完美的自助服务体验,例如,客户端的软件安装或虚拟服务器的提供。
102
103
104 == 2.2 术语和概念 ==
105
106 [[编辑>>url:http://itil4hub.cn/bin/edit/03%20%E6%9C%8D%E5%8A%A1%E8%AF%B7%E6%B1%82%E7%AE%A1%E7%90%86/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=3]]
107
108 服务请求的主要特征包括:
109
110 * 由用户或用户代表发起。
111 * 需要服务提供者的动作。
112 * 是一个具有约定服务成果的动作。这就意味着履行请求需要通过服务成果的预先测试,预先批准针对请求的批准和履行流动,进行人员的培训,以及设置履行请求所需的服务组件等。
113
114 服务请求是服务交付的正常部分,即“日常业务”。服务提供者的客户、用户和运维团队都要很好地理解结果和时间表,这些结果和时间表通常是可预测的。应该尽可能地自动化处理服务请求,并给用户提供有效方便的渠道(例如客户门户)进行访问。
115
116 服务请求对服务质量和服务体验的作用会有差异。在许多情况下,当服务动作作为服务交互的一种关键形式时,它们有助于提高服务功用。在某些情况下,服务请求可以提高到更高的服务级别,从而为标准化的服务产品增加有价值的选项。最后,当服务提供者的监控和事态管理能力受到限制,且服务组件的监控被委托给用户时,可以使用服务请求来发起对服务组件的维护。
117
118 请注意,服务请求是用户问询的一种形式,也是一种发起特定预定义活动的方式,这些活动对于服务体验很重要。相同的活动可以以不同的方式发起,尽管技术操作可能相同,但对用户体验的作用不同,如表2.1所示。
119
120
121 表2.1 其他实践指南中与服务请求实践相关的活动
122
123 (% style="width:645px" %)
124 |(% style="width:339px" %)示例|(% style="width:125px" %)活动|(% style="width:179px" %)实践指南
125 |(% style="width:339px" %)用户监控打印机状态。当打印机提示“碳粉不足”时,用户请求重新填充碳粉。服务提供者的技术人员更换碳粉盒。除了更换过程,打印服务并未中断。|(% style="width:125px" %)服务请求|(% style="width:179px" %)(((
126 服务台
127
128 服务请求管理
129
130 基础设施和平台管理
131 )))
132 |(% style="width:339px" %)(((
133 打印机将其状态和事态传送给运维团队。当发生“碳粉不足”的事态时,服务提供者的技术人员更换碳粉盒。除了更换过程,打印服务并未中断。
134
135
136 )))|(% style="width:125px" %)事态|(% style="width:179px" %)(((
137 监控和事态管理
138
139 基础设施和平台管理
140 )))
141 |(% style="width:339px" %)如果上述场景中出现问题,没有及时报告“碳粉不足”的状况(或未及时更换碳粉盒或未正确更换碳粉盒),打印服务中断。用户将情况反映到服务提供者,服务提供者的技术人员更换碳粉盒,打印服务恢复。|(% style="width:125px" %)事件|(% style="width:179px" %)(((
142 服务台
143
144 事件管理
145
146 基础设施和平台管理
147 )))
148
149 同样,服务请求可以发起变更,通常是标准变更,但有时也可以是一般变更。是否需要变更由公司采用的变更类型方法定义,服务请求和变更之间存在强制性的“关联性”。例如,员工从办公室的一张桌子搬到另一张桌子就可能会被当做一个服务请求进行管理,是否需要进行一项变更还是多项变更,取决于该请求的技术影响,和组织约定的变更标准(作为变更使能实践的一部分)。此类服务请求可能需要实施一个或多个变更来履行,其他类型的服务请求无需涉及变更使能实践即可履行。服务请求的生命周期始终涉及多种实践。履行服务请求的典型价值流大致包括:
150
151 * 服务台:处理用户问询
152 * 服务请求管理:转单和指导履行请求
153 * 基础设施和平台管理:执行必要的技术操作
154 * 发布管理:使服务组件对用户可用
155 * 变更使能:协调必要的变更
156 * 信息安全管理:提供或更改访问权限
157
158 如有需要,可以引用其他实践。履行每种类型的服务请求所需的其他实践的参与度和规程记录在相应的服务请求模型中。
159
160 |(((
161 定义:服务请求模型
162
163 用于履行特定类型的服务请求的可重复的预定义方法。
164 )))
165
166 服务请求模型通常在产品和服务设计期间产出。这些模型会与服务的其他组件一起经过测试并部署到运维中。服务请求管理实践在每一阶段都要确保模型是现实可行的,并被参与其管理和执行的每个人所接受。产品和服务的持续改进也包括了相关服务请求模型的改进。服务请求模型描述了履行服务请求的条件和规程,涵盖了服务管理的四个维度:
167
168 * 规程和工作流,包括可能的选项和决定
169 * 负责的角色和团队(通常以RACI职能矩阵的形式)
170 * 自动化和使用的工具
171 * 参与的第三方及其支持协议。
172
173 由于服务请求是由用户或其代表发起的,因此它们应该以方便、可操作的方式提供给用户。最常见的方式是在组织服务目录的面向用户视图中包括可用的服务请求。服务目录的管理在服务目录管理实践的范围内,但相关信息由服务请求管理实践提供。
174
175 |(((
176 **定义:请求目录**
177
178 服务目录的一种视图,提供了用户可用的已有服务和新服务的服务请求详细信息。
179 )))
180
181 通常,可以通过请求目录获得可用服务请求的以下信息:
182
183 * 服务请求所属的服务
184 * 服务请求邀请的前提/条件
185 * 发起请求所需的信息
186 * 批准工作流(如果适用)
187 * 履行请求的目标时间
188 * 其他相关信息。
189
190 服务请求目录视图应针对适用于访问该视图的用户的服务级别协议(SLA)进行定制,以便所有信息均可反映与用户约定的条件和目标。请求目录中的信息越相关,履行服务请求越高效,用户满意度越高。
191
192
193 == 2.3 范围 ==
194
195 [[编辑>>url:http://itil4hub.cn/bin/edit/03%20%E6%9C%8D%E5%8A%A1%E8%AF%B7%E6%B1%82%E7%AE%A1%E7%90%86/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=4]]
196
197 服务请求管理实践的范围包括:
198
199 1. 管理服务请求模型
200 1. 处理用户或其代表提交的服务请求
201 1. 根据约定的模型管理服务请求的履行
202 1. 评审并持续改进请求处理和履行的绩效
203
204 一些活动和职责范围尽管与服务请求管理密切相关,但仍未被包括在服务请求管理实践中,表2.2中列出了这些活动及其所在的实践。重要的是要记住,ITIL所有的实践都是要关联价值流来使用的工具;根据情况,应将它们组合在一起使用。
205
206 表2.2 其他实践指南中与服务请求管理实践相关的活动
207
208 |活动|实践指南
209 |解决事件|事件管理
210 |与用户沟通|服务台
211 |产品和服务变更的管理与实现|(((
212 变更使能
213
214 部署管理
215
216 发布管理
217 )))
218 |监控服务和技术|监控和事态管理
219 |持续改进的管理与执行|持续改进
220 |请求目录的管理|服务目录管理
221 |服务访问权限的管理和提供|信息安全管理
222 |创建服务请求模型|服务设计
223
224 == ==
225
226 [[编辑>>url:http://itil4hub.cn/bin/edit/03%20%E6%9C%8D%E5%8A%A1%E8%AF%B7%E6%B1%82%E7%AE%A1%E7%90%86/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=5]]
227
228 == 2.4 实践成功因素 ==
229
230 [[编辑>>url:http://itil4hub.cn/bin/edit/03%20%E6%9C%8D%E5%8A%A1%E8%AF%B7%E6%B1%82%E7%AE%A1%E7%90%86/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=6]]
231
232 |(((
233 **定义:实践成功因素**
234
235 为履行实践目的所需的一个复杂的实践功能组件。
236 )))
237
238 实践成功因素(PSF)不仅仅是一项任务或活动,因为它涉及到所有服务管理四维模型的组件。活动的性质和实践成功因素的资源可能有所不同,但它们共同确保实践的有效性。服务请求管理实践包含以下成功因素:
239
240 * 确保优化所有服务的服务请求履行规程
241 * 确保按照约定的规程及用户满意度履行所有服务请求
242
243 === ===
244
245 === **2.4.1 确保优化所有服务的服务请求履行规程** ===
246
247 服务请求规程的开发应该尽早集成到产品和服务生命周期管理中。服务请求实践应该有助于业务分析、架构管理和服务设计活动。根据在这些阶段做出的决定,服务可以针对无请求运维进行优化,或者可以将用户可以使用的多个请求作为正常消耗的一部分。在第一种情况下,用户仍然可以使用通用请求,例如表扬、投诉或请求操作指南。在第二种情况下,可能会有各种特定于服务功用的请求(履行这些请求对于服务质量很重要)。服务请求也可以用于区分不同级别的服务产品(高服务级别的用户可以发起更多请求)。
248
249 识别、记录、和测试服务请求履行规程并为活动分配责任很重要。同样重要的是,确保在请求目录中正确描述了请求,并且提供给能够发起请求的用户。这是与服务目录管理实践结合实现的。
250
251 应基于履行绩效和用户满意度的监控来持续改进服务请求履行规程。优化履行规程的一种方法是尽可能的使其自动执行。这适用于履行工作流中那些变化有限的常用的和例行的请求。特殊定制的,复杂的与不常用的请求仅在经过仔细的考量之后才能自动执行,以确保合理的自动化成本和风险。服务请求模型中记录了服务请求的履行规程以及资源,职责和其他相关信息。
252
253
254 === **2.4.2 确保按照约定的规程及用户满意度履行所有服务请求** ===
255
256 如果对履行规程进行了优化和记录,并且职责明确,则服务的请求很容易履行和规划。每种类型请求的统计信息都可以帮助优化资源规划并确保及时处理所有请求。与事件不同,服务的请求无需紧急处理。它们使得规划更轻松,但应在约定的时间范围内完成。
257
258 请求履行之后,可能需要评审。评审可以仅限于满意度调查,也可以包括详细的内部评审(通常在出现问题或用户满意度下降的时候才需要)。
259
260
261 == 2.5 关键指标 ==
262
263 [[编辑>>url:http://itil4hub.cn/bin/edit/03%20%E6%9C%8D%E5%8A%A1%E8%AF%B7%E6%B1%82%E7%AE%A1%E7%90%86/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=7]]
264
265 应该关联到每个实践所贡献的价值流来评估ITIL实践的效果和绩效。与任何工具的绩效一样,只能关联到其应用来评估实践的绩效。但是,工具在设计和质量上可能会有很大差异,这些差异限定了只有在符合其使用目的情况下,工具的潜力或能力才是有效的。有关度量指标,关键绩效指标(KPI)的更多指南以及方法,请参见度量和报告实践指南。
266
267 服务请求管理实践的关键度量指标已映射到其实践成功因素,可以关联价值流来用作服务请求实践的KPI,以评估其对价值流的效果和效率的贡献。表2.3中给出了一些关键度量指标的示例。
268
269 表2.3 实践成功因素的关键度量指标示例
270
271 |实践成功因素|关键指标
272 |确保优化所有服务的服务请求履行规程|(((
273 服务请求目录的完整性、数量、和支持范围外的服务请求的百分比
274
275 由于规程的错误或低效而无法遵循约定的规程来履行的服务请求的数量和百分比
276
277 通过为团队成员提供操作说明而获取的满意度
278
279 履行请求所需的平均时间和成本(按类型或模型)
280
281 完全或很大程度上自动履行的服务请求的百分比(数量,目录百分比,总数百分比和履行时间)
282 )))
283 |确保按照约定的规程及用户满意度履行所有服务请求|(((
284 符合SLA约定的数量和百分比
285
286 未正确履行请求导致的事件影响
287
288 用户满意度
289
290 不符合约定规程的数量和百分比
291 )))
292
293 将度量指标正确的融入到复杂的指标项中,将使它们更易于用于价值流管理和服务请求管理实践的定期评估和持续改进。没有单一的最佳解决方案。度量指标应基于组织的整体服务战略和优先级,以及实践所贡献的价值流的目标。
294
295
296
297 ----
298
299 = **3 价值流和流程** =
300
301 [[编辑>>url:http://itil4hub.cn/bin/edit/03%20%E6%9C%8D%E5%8A%A1%E8%AF%B7%E6%B1%82%E7%AE%A1%E7%90%86/3%20%E4%BB%B7%E5%80%BC%E6%B5%81%E5%92%8C%E6%B5%81%E7%A8%8B/WebHome?section=1]]
302
303 == 3.1 价值流的贡献 ==
304
305 [[编辑>>url:http://itil4hub.cn/bin/edit/03%20%E6%9C%8D%E5%8A%A1%E8%AF%B7%E6%B1%82%E7%AE%A1%E7%90%86/3%20%E4%BB%B7%E5%80%BC%E6%B5%81%E5%92%8C%E6%B5%81%E7%A8%8B/WebHome?section=2]]
306
307 像任何其他ITIL 管理实践一样,服务请求实践也对多个价值流做出贡献。重要的是要记住,价值流永远不会由单个实践形成。服务请求实践与其他实践相结合,可以为消费者提供高质量的服务。该实践贡献的主要价值链活动是:
308
309 * 契动
310 * 交付和支持
311 * 设计和转换
312 * 获取/构建。
313
314 图3.1 中显示了服务请求管理实践对服务价值链的贡献。
315
316 (% style="text-align:center" %)
317 [[image:1600507024415-772.png]]
318
319 图3.1 服务请求管理实践对价值链贡献的热力图
320
321
322 == 3.2 流程 ==
323
324 [[编辑>>url:http://itil4hub.cn/bin/edit/03%20%E6%9C%8D%E5%8A%A1%E8%AF%B7%E6%B1%82%E7%AE%A1%E7%90%86/3%20%E4%BB%B7%E5%80%BC%E6%B5%81%E5%92%8C%E6%B5%81%E7%A8%8B/WebHome?section=4]]
325
326 每个实践可能包含一个或多个履行该实践目的所必需的流程和活动。
327
328 |(((
329 定义:流程
330
331 流程是一组相互关联,相互交互的,将输入转换为输出的活动。流程获得一个或多个定义的输入,并将其转换为定义的输出。流程定义动作的顺序及其依赖性。
332 )))
333
334 服务请求管理活动形成两个流程:
335
336 * 服务请求履行控制
337 * 服务请求评审和优化。  
338
339 === ===
340
341 === 3.2.1 **服务请求履行控制** ===
342
343 该流程包括表3.1 中列出的活动,并将输入转换为输出。
344
345 |**关键输入**|**活动**|**关键输出**
346 |(((
347 服务请求问询
348
349 服务请求模型
350
351 服务级别协议
352
353 履行动作记录和报告
354 )))|(((
355 请求分类
356
357 服务请求模型初始化和控制
358
359 临时性的履行控制
360
361 履行评审
362 )))|(((
363 履行服务请求
364
365 履行动作记录和报告
366
367 用户满意度调查
368 )))
369
370 表3.1 服务请求履行控制流程的输入,活动和输出
371
372
373 图3.2 显示了流程的工作流。
374
375 (% style="text-align:center" %)
376 [[image:http://itil4hub.cn/bin/download/03%20%E6%9C%8D%E5%8A%A1%E8%AF%B7%E6%B1%82%E7%AE%A1%E7%90%86/3%20%E4%BB%B7%E5%80%BC%E6%B5%81%E5%92%8C%E6%B5%81%E7%A8%8B/WebHome/1600507060947-247.png?rev=1.1||alt="1600507060947-247.png"]]
377
378 图3.2 服务请求履行的控制流程工作流
379
380
381 流程可能会根据请求模型而有所不同。表3.2 提供了不同模型下的示例
382
383 |活动|手动或不完整的服务请求模型|高度自动化的服务请求模型
384 |请求分类|(((
385 完全或部分依赖手动来核对服务请求和用户资格。需要人工联系用户提供缺少的信息或纸质文件。
386
387 服务台专员选择适当的服务请求模型。
388 )))|(((
389 在高度自动化的环境中,系统将自动核对服务请求。系统联系用户提供缺少的信息或纸质文件。
390
391 根据服务请求的特征选择适当的模型和自动化规程。                                                             
392 )))
393 |服务请求模型初始化和控制|(((
394 根据服务请求模型,服务台专员可能需要手动选择合适的支持团队或专家。分配的支持团队遵循为模型定义的服务请求履行规程。
395
396 如有必要,可以根据服务请求规程要求额外的批准。
397
398 在某些情况下,需要同时履行多个服务请求任务。需要由服务台专员进行手动分配和控制,以及发送用户通知。
399
400 负责的团队可以履行整个服务请求或特定任务。
401
402 如有必要,负责的团队也要更新相关的配置项。
403
404 服务请求需要经过履行评审。
405 )))|(((
406 根据所选的服务请求模型,请求履行会被启动,并且由系统来控制规程流向和履行请求的脚本。
407
408 服务请求需要经过履行评审。
409 )))
410 |临时性的履行控制|(% colspan="2" %)(((
411 在某些情况下,服务请求的履行需要一些非标准的,特殊定制的工作,或者有些新情况在计划服务请求时未考虑到。因此,遵循已有规程不会达到期望的结果,只能为服务请求提供临时性的履行方案。
412
413 临时性的履行是一种例外情况,应视为例外情况来处理。
414
415 应该决定是按照例外情况来处理还是直接拒绝履行服务请求。该决定通常由模型和模型处理例外情况的方式来定义。
416
417 不管做出什么决定,此类请求的细节应做为服务请求模型评审和优化的流程输入,这样就可以明确定义此类请求并将其添加到模型中,或者在经过附加的评估分类检查后,将此类请求纳入模型。
418 )))
419 |履行评审|(% colspan="2" %)(((
420 要根据模型对服务请求履行情况进行检验。
421
422 履行评审应该在模型中描述。履行评审会有相应的规程,以检查履行在多大程度上达到了预期的结果。
423
424 履行评审也包括收集用户反馈和衡量用户满意度。
425
426 履行评审的报告和记录用作服务请求评审和优化的流程输入。
427 )))
428
429 表3.2 服务请求履行的控制流程活动
430
431
432 === 3.2.2 **服务请求评审和优化** ===
433
434 本流程专注于服务请求模型管理实践的持续改进。建议定期执行此流程,或由用户调查结果触发执行。该流程包括表3.3中列出的活动,并将输入转换为输出。
435
436 表3.3 服务请求评审和优化流程的输入,活动,和输出.。
437
438 |关键输入|活动|关键输出
439 |(((
440 当前服务请求模型
441
442 用户调查结果
443
444 相关变更和变更模型
445
446 政策法规要求
447
448 服务目录
449
450 服务级别协议
451
452 IT资产信息
453
454 CMDB 配置管理
455
456 容量和性能信息
457 )))|(((
458 服务请求记录和报告分析
459
460 服务请求模型改进启动
461
462 服务请求模型更新沟通
463 )))|(((
464 更新过的服务请求模型
465
466 更新过的服务请求规程和操作说明
467 )))
468
469 图3.3 显示了该流程的工作流程图。
470
471 (% style="text-align:center" %)
472 [[image:http://itil4hub.cn/bin/download/03%20%E6%9C%8D%E5%8A%A1%E8%AF%B7%E6%B1%82%E7%AE%A1%E7%90%86/3%20%E4%BB%B7%E5%80%BC%E6%B5%81%E5%92%8C%E6%B5%81%E7%A8%8B/WebHome/1600507084085-268.png?rev=1.1||alt="1600507084085-268.png"]]
473
474 图3.3 服务请求评审和优化流程的工作流
475
476
477 表3.4 提供了该流程活动的描述。
478
479 |活动|描述
480 |服务请求记录和报告分析|服务请求实践负责人与服务负责人和其他相关干系人一起,对在此期间内选定的服务请求和相关指标,以及/或者对来自变更使能实践中的相关重复变更进行评审。他们识别出创建新服务请求模型的机会,和/或当前服务请求模型所需的改进。
481 |服务请求模型改进启动|(((
482 服务请求实践负责人登记和提交模型的改进方案,并与持续改进实践和/或变更请求一起处理。
483
484 如果模型测试不能确认提交的服务请求模型的有效性,便将其退回以进行进一步分析。
485 )))
486 |服务请求模型更新的沟通|如果服务请求模型成功更新,则将其传达给相关干系人。通常由服务请求实践负责人或服务负责人来进行沟通。
487
488 表3.4 服务请求评审和优化流程的活动
489
490
491
492 ----
493
494 = **4 组织和人员** =
495
496 [[编辑>>url:http://itil4hub.cn/bin/edit/03%20%E6%9C%8D%E5%8A%A1%E8%AF%B7%E6%B1%82%E7%AE%A1%E7%90%86/4%20%E7%BB%84%E7%BB%87%E5%92%8C%E4%BA%BA%E5%91%98/WebHome?section=1]]
497
498 == 4.1角色,能力和责任 ==
499
500 [[编辑>>url:http://itil4hub.cn/bin/edit/03%20%E6%9C%8D%E5%8A%A1%E8%AF%B7%E6%B1%82%E7%AE%A1%E7%90%86/4%20%E7%BB%84%E7%BB%87%E5%92%8C%E4%BA%BA%E5%91%98/WebHome?section=2]]
501
502 实践指南没有描述实践管理的角色,例如实践负责人,实践主管或实践教练。相反,他们专注于针对每个实践的专家角色。组织不同,每个角色的结构和命名也可能不同,因此ITIL中定义的任何角色都不应被视为强制性的,甚至不应被视为推荐性的。请记住,角色不是职务。一个人可以担任多个角色,一个角色也可以分配给多个人。
503
504 角色是关联到流程和活动中来描述的。每个角色都具有基于表4.1中所示的模型的能力概况特征。
505
506 |能力代码|能力描述(活动和技能)
507 |**L**|**领导者 **决策,委派,监督其他活动,激励团队,提供动力以及评估成果
508 |**А**|**管理员** 分配任务并确定优先级,保留记录,持续报告并启动基本的改进
509 |**C**|**协调员/沟通者** 多方协调,维护相关干系人之间的沟通,并负责有关认知的宣传活动
510 |**М**|**方法和技术专家** 设计和实施工作技术,编制规程文档,提供流程、工作分析和持续改进的咨询
511 |**Т**|**技术专家** 提供技术(IT)专业知识,并执行基于专业知识的任务
512
513 表4.1 能力代码和描述
514
515
516 服务请求管理实践没有特定的专家角色。请求发起方的角色可以是任何用户或用户授权代表;不需要特殊的技能或能力。上面描述的服务流程的关键活动通常由服务提供者的技术专家,服务负责人和用户支持专员执行,但是没有或只有非常少的针对该实践的能力类型。
517
518
519 表4.2 中列出了服务请求管理活动中可能涉及的其他角色的示例,以及相关的能力类型和特定技能。
520
521 |**活动**|**负责角色**|**能力类型**|**特定技能**
522 |(% colspan="4" %)服务请求履行控制流程
523 |请求分类|(((
524 用户支持专员
525
526 产品负责人
527
528 服务负责人
529 )))|CTM|熟悉组织的产品和服务
530 | |技术专家| |(((
531 了解服务目录,SLA,
532
533 请求模型
534 )))
535 |服务请求模型初始化和控制|(((
536 用户支持专员
537
538 服务负责人
539
540 技术专家
541 )))|CAT|熟悉服务请求模型和服务提供者组织
542 |临时性的履行控制|(((
543 服务负责人
544
545 技术团队主管
546 )))|CTA|(((
547 熟悉产品,服务和SLA
548
549 了解业务需求
550
551 有权分配资源和计划临时性工作
552 )))
553 |履行评审|(((
554 服务负责人
555
556 实践负责人
557
558 实践经理/协调人
559 )))|MCT|(((
560 熟悉产品,服务和SLA
561
562 了解业务需求
563
564 熟悉服务请求模型和服务提供者组织
565 )))
566 |服务请求和评审优化| | |
567 |服务请求记录和报告分析|(((
568 产品负责人
569
570 服务负责人
571
572 实践负责人
573
574 实践经理/协调人
575 )))|TM|熟悉服务和产品,及服务请求模型
576 |服务请求模型改进启动|(((
577 实践负责人
578
579 实践经理/协调人
580
581 产品负责人
582
583 服务负责人
584
585 资源负责人
586
587 ITSM工具顾问
588 )))|TCA|(((
589 熟悉服务和产品,及服务请求模型
590
591 熟悉可用的工具和方法
592 )))
593 |服务请求模型更新沟通|(((
594 实践负责人
595
596 实践经理/协调人
597 )))|C|(((
598 了解服务请求模型
599
600 沟通技巧
601 )))
602 | |(((
603 产品负责人
604
605 服务负责人
606
607 资源负责人
608 )))| |
609
610 表4.2 服务请求管理实践活动中涉及的角色示例
611
612
613 == 4.2 组织结构和团队 ==
614
615 [[编辑>>url:http://itil4hub.cn/bin/edit/03%20%E6%9C%8D%E5%8A%A1%E8%AF%B7%E6%B1%82%E7%AE%A1%E7%90%86/4%20%E7%BB%84%E7%BB%87%E5%92%8C%E4%BA%BA%E5%91%98/WebHome?section=3]]
616
617 设立专门的组织结构来管理服务请求管理实践是不常见的。该实践集成在服务交付和实现团队或技术人员的日常活动中,这些都是在服务请求模型定义期间预先定义好的。服务请求管理实践与事件管理实践通常共享相同的团队结构。但是,如果把服务请求作为服务功用的一部分,并且需求量很高的时候,则可以成立专门的团队来处理和履行所有或某些类型的服务请求。在许多情况下,实施自动化可以减少对此类团队的需求,并可改进服务质量。
618
619
620
621 ----
622
623 = **5 信息和技术** =
624
625 [[编辑>>url:http://itil4hub.cn/bin/edit/03%20%E6%9C%8D%E5%8A%A1%E8%AF%B7%E6%B1%82%E7%AE%A1%E7%90%86/5%20%E4%BF%A1%E6%81%AF%E5%92%8C%E6%8A%80%E6%9C%AF/WebHome?section=1]]
626
627 == 5.1 信息交流 ==
628
629 [[编辑>>url:http://itil4hub.cn/bin/edit/03%20%E6%9C%8D%E5%8A%A1%E8%AF%B7%E6%B1%82%E7%AE%A1%E7%90%86/5%20%E4%BF%A1%E6%81%AF%E5%92%8C%E6%8A%80%E6%9C%AF/WebHome?section=2]]
630
631 服务请求管理实践的效果基于所使用信息的质量。这里提到的信息包括但不限于以下信息:
632
633 1. 客户和用户
634 1. 服务及其关联的请求目录和请求模型
635 1. 合作伙伴和供应商,以及它们提供的服务的信息
636 1. 规范提供服务的政策和要求
637 1. 相关干系人对实践的满意度。
638
639 该信息可以采用各种形式。实践的关键输入和输出在本指南的价值流和流程部分中列出。
640
641
642 == 5.2 自动化和工具 ==
643
644
645 [[编辑>>url:http://itil4hub.cn/bin/edit/03%20%E6%9C%8D%E5%8A%A1%E8%AF%B7%E6%B1%82%E7%AE%A1%E7%90%86/5%20%E4%BF%A1%E6%81%AF%E5%92%8C%E6%8A%80%E6%9C%AF/WebHome?section=4]]
646
647 在某些情况下,服务请求管理实践的工作可以大大受益于自动化。在可能且有效的情况下,可能涉及表5.1中概述的解决方案。
648
649 表5.1 服务请求管理活动的自动化解决方案
650
651 |流程活动 |自动化手段|关键功能|对实践效果的影响
652 |(% colspan="4" %)服务请求履行控制
653 |请求分类|(((
654 工作流管理和协作工具
655
656 ITSM工具集
657 )))|(((
658 请求目录管理
659
660 工作分配
661
662 预定义的规程流向
663 )))|高
664 |服务请求模型初始化和控制|(((
665 工作流管理和协作工具
666
667 ITSM工具集
668 )))|(((
669 工作分配
670
671 预定义的规程流向
672
673 协作,任务                                   
674 )))|高
675 |临时性的履行控制|(((
676 工作流管理和协作工具
677
678 ITSM工具集
679
680 系统监控工具
681 )))|(((
682 监控工作进度
683
684 沟通
685
686 通知,升级
687 )))|中到高
688 |履行评审|(((
689 工作流管理和协作工具
690
691 ITSM工具集
692 )))|(((
693 沟通与协作
694
695 报告与分析
696 )))|中
697 |(% colspan="4" %)服务请求和评审优化
698 |服务请求记录和报告分析|分析和报告工具|(((
699 服务请求的统计分析
700
701 工作量和流量
702 )))|高
703 |服务请求模型改进启动|工作流管理和协作工具|(((
704 待办项和工作流的管理与可视化
705
706 沟通与协作
707 )))|中到高
708 |服务请求模型更新沟通|(((
709 发布工具
710
711 社交媒体
712
713 工作流管理工具
714 )))|(((
715 邮件
716
717 推送通知
718
719 Web门户
720
721 认知消息发布
722 )))|高
723
724
725 ----
726
727 = **6 合作伙伴和供应商** =
728
729 [[编辑>>url:http://itil4hub.cn/bin/edit/03%20%E6%9C%8D%E5%8A%A1%E8%AF%B7%E6%B1%82%E7%AE%A1%E7%90%86/6%20%E5%90%88%E4%BD%9C%E4%BC%99%E4%BC%B4%E5%92%8C%E4%BE%9B%E5%BA%94%E5%95%86/WebHome?section=1]]
730
731 组织很少只使用自己的资源来交付服务,多数(如果不是全部)依赖于其他服务,这些服务通常由组织之外的第三方提供(请参阅ITIL Foundation:ITIL 4 Edition的2.4节:服务关系模型)。通过服务支持所引入的第三方的关联性和依赖性是通过服务设计、架构管理,和供应商管理这些实践所描述的。
732
733 由于服务请求的内在特性(例如预定义,预先批准和可预测),组织会自然地将服务请求管理外包。组织应该慎重地维持服务请求管理的高标准,因为它会直接影响用户的满意度,而且可能对服务价值带来不良影响。
734
735 服务请求模型应定义第三方如何参与服务请求履行以及如何确保组织有效的协作。这将取决于产品、服务和价值流的架构和设计解决方案。不过支持这些解决方案的服务请求模型优化仍将涉及服务请求管理实践。
736
737 为了使供应商成为组织生态系统的一部分,沟通协作条件和要求的一个简便方法是定义好标准的接口、接口描述可以包括数据交换规则、工具以及流程,来创建一种多厂商环境中的共同语言。
738
739 当组织想要确保快速有效的服务请求管理实践时,他们通常会设法与其合作伙伴和供应商约定紧密的合作,并消除沟通,协作和决策方面的形式化的官僚壁垒(更多信息,请参见供应商管理实践指南)。
740
741
742
743 ----
744
745 = **7 重要提醒** =
746
747 [[编辑>>url:http://itil4hub.cn/bin/edit/03%20%E6%9C%8D%E5%8A%A1%E8%AF%B7%E6%B1%82%E7%AE%A1%E7%90%86/7%20%E9%87%8D%E8%A6%81%E6%8F%90%E9%86%92/WebHome?section=1]]
748
749 组织在建立和发展自己的实践时,应考虑将实践指南的大部分内容只作为建议参考。实践指南是组织可以考虑的主题目录,而不是答案列表。使用实践指南的内容时,组织应始终遵循ITIL 指导原则:
750
751 1. 聚焦价值
752 1. 从你所处的地方开始
753 1. 基于反馈迭代推进
754 1. 协作和提升可视化程度
755 1. 通盘思考和工作
756 1. 保持简单实用
757 1. 优化和自动化。
758
759 有关指导原则及其应用的更多信息,请参见ITIL Foundation:ITIL 4 Edition的4.3节。
760
761
762
763 ----
764
765 = **8 致谢** =
766
767 [[编辑>>url:http://itil4hub.cn/bin/edit/03%20%E6%9C%8D%E5%8A%A1%E8%AF%B7%E6%B1%82%E7%AE%A1%E7%90%86/8%20%E8%87%B4%E8%B0%A2/WebHome?section=1]]
768
769 AXELOS Ltd非常感谢为本指南的开发做出贡献的每一个人。这些实践指南融合了ITIL社区前所未有的热情和反馈。AXELOS特别要感谢以下人员。
770
771 == ==
772
773 [[编辑>>url:http://itil4hub.cn/bin/edit/03%20%E6%9C%8D%E5%8A%A1%E8%AF%B7%E6%B1%82%E7%AE%A1%E7%90%86/8%20%E8%87%B4%E8%B0%A2/WebHome?section=2]]
774
775 == 8.1 作者 ==
776
777 [[编辑>>url:http://itil4hub.cn/bin/edit/03%20%E6%9C%8D%E5%8A%A1%E8%AF%B7%E6%B1%82%E7%AE%A1%E7%90%86/8%20%E8%87%B4%E8%B0%A2/WebHome?section=3]]
778
779 MiroslavHlohovsky,Don Page,RobertPinnington。
780
781 == ==
782
783 [[编辑>>url:http://itil4hub.cn/bin/edit/03%20%E6%9C%8D%E5%8A%A1%E8%AF%B7%E6%B1%82%E7%AE%A1%E7%90%86/8%20%E8%87%B4%E8%B0%A2/WebHome?section=4]]
784
785 == 8.2 审稿人 ==
786
787 [[编辑>>url:http://itil4hub.cn/bin/edit/03%20%E6%9C%8D%E5%8A%A1%E8%AF%B7%E6%B1%82%E7%AE%A1%E7%90%86/8%20%E8%87%B4%E8%B0%A2/WebHome?section=5]]
788
789 DinaraAdyrbayeva,Cheryl Grimes,RomanJouravlev,GeorgesKemmerling,HennyKerkvliet,Niels Loader,AntonLykov,PauloTourinho。
深圳市艾拓先锋企业管理咨询有限公司