Version 15.1 by superadmin on 2021/01/29, 22:33
Show last authors
1 (% class="jumbotron" %)
2 (((
3 (% class="container" %)
4 (((
5 = =
6
7
8
9 需要下载 **ITIL 4服务请求管理实践【中文】**pdf版全文，请关注微信公众号itilxf ，并回复“服务请求”即可。
10
11
12 [[image:微信图片_20200929154759.png]]
13
14
15
16 **申明：**
17
18 本系列ITIL 4实践中文版本由ITIL先锋论坛专家委员会组织翻译，国内众多从事ITIL理论推广及落地实践的专家们参与，需要下载最新翻译版本请关注微信公众号：ITILXF，也可访问ITIL4中文知识库网站：itil4hub.cn。
19
20 请注意，ITIL先锋论坛专家团队仅仅只是进行了这些著作的语种转换工作，我们并不拥有包括原著以及中文发行文件的任何版权，所有版权均为Axoles持有，读者在使用这些文件（含本中文翻译版本）时需完全遵守Axoles 和 TSO所申明的所有版权要求。
21
22
23 **翻译**：邹庆海 **审校**：卢曦 **审核**：刘晓慧
24 )))
25 )))
26
27 = **1 关于本文档** =
28
29 [[编辑>>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]]
30
31 本文档为服务请求管理实践提供了实践指南，内容分为五个主要部分，包括：
32
33 1. 实践的基本信息
34 1. 实践的流程和活动以及它们在服务价值链中的作用
35 1. 实践中涉及的组织和人员
36 1. 支持实践的信息和技术
37 1. 实践中关于合作伙伴和供应商的注意事项
38
39 == ==
40
41 [[编辑>>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]]
42
43 == 1.1 ITIL®4 认证方案 ==
44
45 [[编辑>>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]]
46
47 本文档中节选的内容可作为以下课程的一部分进行考核：
48
49 1. ITIL专家 创建、交付和支持
50 1. ITIL专家 高速IT
51
52 详细信息请参阅相应的教学大纲。
53
54
55 ----
56
57 (% style="color:#2d2d2d; font-size:29px" %)**2 基本信息**
58
59 [[编辑>>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]]
60
61 == 2.1 目的与描述 ==
62
63 [[编辑>>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]]
64
65 |(((
66
67
68 定义：服务请求
69
70 用户或用户授权代表发起的服务动作的请求，该服务动作已约定为服务交付的正常部分。
71 )))
72
73 |(((
74 关键信息
75
76 服务请求管理实践的目的是通过有效、友好的方式处理所有约定的、用户发起的服务请求，以此来支持约定的服务质量。
77 )))
78
79
80 服务请求是用户问询的重要类型，也是用户体验的重要组成部分。通常，服务请求包括以下内容：
81
82 1. 发起服务动作请求（由服务提供者或与用户一起执行）
83 1. 信息请求
84 1. 资源或服务访问请求
85 1. 反馈，表扬或投诉
86
87 服务请求的履行可能涉及对服务或其组件的变更，通常属于标准变更。由于服务请求是预定义的，并且已约定为服务交付的正常部分，因此通常可以通过明确的启动，批准，履行和管理的标准规程，来对其进行标准化。某些服务请求具有非常简单的工作流，例如信息请求。其他服务请求（例如，为新员工设置信息）可能很复杂，需要多个团队和系统的合作才能履行。无论复杂性如何，履行请求的步骤都应该是众所周知并经过测试的。这使得服务提供者可以约定履行请求的时间，并向用户提供服务请求状态的清晰沟通。
88
89 服务规程的开发和测试在产品和服务生命周期的相应阶段执行，涉及多种实践，其中包括业务分析，服务设计，风险管理，变更使能，服务目录管理和服务级别管理等。
90
91 根据财务、信息安全或其他策略要求，某些服务请求需要授权。为了恰当地处理此类请求，服务请求管理实践应该遵循以下准则：
92
93 * 服务请求及履行应尽可能标准化和自动化
94 * 对于可以通过有限的或无需额外批准就可以履行的服务请求，应制定策略以提高效率
95 * 应根据组织的交付能力明确设定用户对履行时间的期望
96 * 应识别改进服务的机会并加以实施，以加快履行速度和进一步利用自动化
97 * 应制定策略和工作流，以便对作为服务请求提交的事件或变更请求进行记录和转单
98
99 某些服务请求完全可以自动化履行从提交到关闭的过程，以提供完美的自助服务体验，例如，客户端的软件安装或虚拟服务器的提供。
100
101
102 == 2.2 术语和概念 ==
103
104 [[编辑>>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]]
105
106 服务请求的主要特征包括：
107
108 * 由用户或用户代表发起。
109 * 需要服务提供者的动作。
110 * 是一个具有约定服务成果的动作。这就意味着履行请求需要通过服务成果的预先测试，预先批准针对请求的批准和履行流动，进行人员的培训，以及设置履行请求所需的服务组件等。
111
112 服务请求是服务交付的正常部分，即“日常业务”。服务提供者的客户、用户和运维团队都要很好地理解结果和时间表，这些结果和时间表通常是可预测的。应该尽可能地自动化处理服务请求，并给用户提供有效方便的渠道（例如客户门户）进行访问。
113
114 服务请求对服务质量和服务体验的作用会有差异。在许多情况下，当服务动作作为服务交互的一种关键形式时，它们有助于提高服务功用。在某些情况下，服务请求可以提高到更高的服务级别，从而为标准化的服务产品增加有价值的选项。最后，当服务提供者的监控和事态管理能力受到限制，且服务组件的监控被委托给用户时，可以使用服务请求来发起对服务组件的维护。
115
116 请注意，服务请求是用户问询的一种形式，也是一种发起特定预定义活动的方式，这些活动对于服务体验很重要。相同的活动可以以不同的方式发起，尽管技术操作可能相同，但对用户体验的作用不同，如表2.1所示。
117
118
119 表2.1 其他实践指南中与服务请求实践相关的活动
120
121 (% style="width:645px" %)
122 |(% style="width:339px" %)示例|(% style="width:125px" %)活动|(% style="width:179px" %)实践指南
123 |(% style="width:339px" %)用户监控打印机状态。当打印机提示“碳粉不足”时，用户请求重新填充碳粉。服务提供者的技术人员更换碳粉盒。除了更换过程，打印服务并未中断。|(% style="width:125px" %)服务请求|(% style="width:179px" %)(((
124 服务台
125
126 服务请求管理
127
128 基础设施和平台管理
129 )))
130 |(% style="width:339px" %)(((
131 打印机将其状态和事态传送给运维团队。当发生“碳粉不足”的事态时，服务提供者的技术人员更换碳粉盒。除了更换过程，打印服务并未中断。
132
133
134 )))|(% style="width:125px" %)事态|(% style="width:179px" %)(((
135 监控和事态管理
136
137 基础设施和平台管理
138 )))
139 |(% style="width:339px" %)如果上述场景中出现问题，没有及时报告“碳粉不足”的状况（或未及时更换碳粉盒或未正确更换碳粉盒），打印服务中断。用户将情况反映到服务提供者，服务提供者的技术人员更换碳粉盒，打印服务恢复。|(% style="width:125px" %)事件|(% style="width:179px" %)(((
140 服务台
141
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 * 负责的角色和团队（通常以RACI职能矩阵的形式）
168 * 自动化和使用的工具
169 * 参与的第三方及其支持协议。
170
171 由于服务请求是由用户或其代表发起的，因此它们应该以方便、可操作的方式提供给用户。最常见的方式是在组织服务目录的面向用户视图中包括可用的服务请求。服务目录的管理在服务目录管理实践的范围内，但相关信息由服务请求管理实践提供。
172
173 |(((
174 **定义：请求目录**
175
176 服务目录的一种视图，提供了用户可用的已有服务和新服务的服务请求详细信息。
177 )))
178
179 通常，可以通过请求目录获得可用服务请求的以下信息：
180
181 * 服务请求所属的服务
182 * 服务请求邀请的前提/条件
183 * 发起请求所需的信息
184 * 批准工作流（如果适用）
185 * 履行请求的目标时间
186 * 其他相关信息。
187
188 服务请求目录视图应针对适用于访问该视图的用户的服务级别协议（SLA）进行定制，以便所有信息均可反映与用户约定的条件和目标。请求目录中的信息越相关，履行服务请求越高效，用户满意度越高。
189
190
191 == 2.3 范围 ==
192
193 [[编辑>>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]]
194
195 服务请求管理实践的范围包括：
196
197 1. 管理服务请求模型
198 1. 处理用户或其代表提交的服务请求
199 1. 根据约定的模型管理服务请求的履行
200 1. 评审并持续改进请求处理和履行的绩效
201
202 一些活动和职责范围尽管与服务请求管理密切相关，但仍未被包括在服务请求管理实践中，表2.2中列出了这些活动及其所在的实践。重要的是要记住，ITIL所有的实践都是要关联价值流来使用的工具；根据情况，应将它们组合在一起使用。
203
204 表2.2 其他实践指南中与服务请求管理实践相关的活动
205
206 |活动|实践指南
207 |解决事件|事件管理
208 |与用户沟通|服务台
209 |产品和服务变更的管理与实现|(((
210 变更使能
211
212 部署管理
213
214 发布管理
215 )))
216 |监控服务和技术|监控和事态管理
217 |持续改进的管理与执行|持续改进
218 |请求目录的管理|服务目录管理
219 |服务访问权限的管理和提供|信息安全管理
220 |创建服务请求模型|服务设计
221
222 == ==
223
224 [[编辑>>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]]
225
226 == 2.4 实践成功因素 ==
227
228 [[编辑>>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]]
229
230 |(((
231 **定义：实践成功因素**
232
233 为履行实践目的所需的一个复杂的实践功能组件。
234 )))
235
236 实践成功因素（PSF）不仅仅是一项任务或活动，因为它涉及到所有服务管理四维模型的组件。活动的性质和实践成功因素的资源可能有所不同，但它们共同确保实践的有效性。服务请求管理实践包含以下成功因素：
237
238 * 确保优化所有服务的服务请求履行规程
239 * 确保按照约定的规程及用户满意度履行所有服务请求
240
241 === ===
242
243 === **2.4.1 确保优化所有服务的服务请求履行规程** ===
244
245 服务请求规程的开发应该尽早集成到产品和服务生命周期管理中。服务请求实践应该有助于业务分析、架构管理和服务设计活动。根据在这些阶段做出的决定，服务可以针对无请求运维进行优化，或者可以将用户可以使用的多个请求作为正常消耗的一部分。在第一种情况下，用户仍然可以使用通用请求，例如表扬、投诉或请求操作指南。在第二种情况下，可能会有各种特定于服务功用的请求（履行这些请求对于服务质量很重要）。服务请求也可以用于区分不同级别的服务产品（高服务级别的用户可以发起更多请求）。
246
247 识别、记录、和测试服务请求履行规程并为活动分配责任很重要。同样重要的是，确保在请求目录中正确描述了请求，并且提供给能够发起请求的用户。这是与服务目录管理实践结合实现的。
248
249 应基于履行绩效和用户满意度的监控来持续改进服务请求履行规程。优化履行规程的一种方法是尽可能的使其自动执行。这适用于履行工作流中那些变化有限的常用的和例行的请求。特殊定制的，复杂的与不常用的请求仅在经过仔细的考量之后才能自动执行，以确保合理的自动化成本和风险。服务请求模型中记录了服务请求的履行规程以及资源，职责和其他相关信息。
250
251
252 === **2.4.2 确保按照约定的规程及用户满意度履行所有服务请求** ===
253
254 如果对履行规程进行了优化和记录，并且职责明确，则服务的请求很容易履行和规划。每种类型请求的统计信息都可以帮助优化资源规划并确保及时处理所有请求。与事件不同，服务的请求无需紧急处理。它们使得规划更轻松，但应在约定的时间范围内完成。
255
256 请求履行之后，可能需要评审。评审可以仅限于满意度调查，也可以包括详细的内部评审（通常在出现问题或用户满意度下降的时候才需要）。
257
258
259 == 2.5 关键指标 ==
260
261 [[编辑>>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]]
262
263 应该关联到每个实践所贡献的价值流来评估ITIL实践的效果和绩效。与任何工具的绩效一样，只能关联到其应用来评估实践的绩效。但是，工具在设计和质量上可能会有很大差异，这些差异限定了只有在符合其使用目的情况下，工具的潜力或能力才是有效的。有关度量指标，关键绩效指标（KPI）的更多指南以及方法，请参见度量和报告实践指南。
264
265 服务请求管理实践的关键度量指标已映射到其实践成功因素，可以关联价值流来用作服务请求实践的KPI，以评估其对价值流的效果和效率的贡献。表2.3中给出了一些关键度量指标的示例。
266
267 表2.3 实践成功因素的关键度量指标示例
268
269 |实践成功因素|关键指标
270 |确保优化所有服务的服务请求履行规程|(((
271 服务请求目录的完整性、数量、和支持范围外的服务请求的百分比
272
273 由于规程的错误或低效而无法遵循约定的规程来履行的服务请求的数量和百分比
274
275 通过为团队成员提供操作说明而获取的满意度
276
277 履行请求所需的平均时间和成本（按类型或模型）
278
279 完全或很大程度上自动履行的服务请求的百分比（数量，目录百分比，总数百分比和履行时间）
280 )))
281 |确保按照约定的规程及用户满意度履行所有服务请求|(((
282 符合SLA约定的数量和百分比
283
284 未正确履行请求导致的事件影响
285
286 用户满意度
287
288 不符合约定规程的数量和百分比
289 )))
290
291 将度量指标正确的融入到复杂的指标项中，将使它们更易于用于价值流管理和服务请求管理实践的定期评估和持续改进。没有单一的最佳解决方案。度量指标应基于组织的整体服务战略和优先级，以及实践所贡献的价值流的目标。
292
293
294
295 ----
296
297 = **3 价值流和流程** =
298
299 [[编辑>>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]]
300
301 == 3.1 价值流的贡献 ==
302
303 [[编辑>>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]]
304
305 像任何其他ITIL 管理实践一样，服务请求实践也对多个价值流做出贡献。重要的是要记住，价值流永远不会由单个实践形成。服务请求实践与其他实践相结合，可以为消费者提供高质量的服务。该实践贡献的主要价值链活动是：
306
307 * 契动
308 * 交付和支持
309 * 设计和转换
310 * 获取/构建。
311
312 图3.1 中显示了服务请求管理实践对服务价值链的贡献。
313
314 (% style="text-align:center" %)
315 [[image:1600507024415-772.png]]
316
317 图3.1 服务请求管理实践对价值链贡献的热力图
318
319
320 == 3.2 流程 ==
321
322 [[编辑>>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]]
323
324 每个实践可能包含一个或多个履行该实践目的所必需的流程和活动。
325
326 |(((
327 定义：流程
328
329 流程是一组相互关联，相互交互的，将输入转换为输出的活动。流程获得一个或多个定义的输入，并将其转换为定义的输出。流程定义动作的顺序及其依赖性。
330 )))
331
332 服务请求管理活动形成两个流程：
333
334 * 服务请求履行控制
335 * 服务请求评审和优化。  
336
337 === ===
338
339 === 3.2.1 **服务请求履行控制** ===
340
341 该流程包括表3.1 中列出的活动，并将输入转换为输出。
342
343 |**关键输入**|**活动**|**关键输出**
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 表3.1 服务请求履行控制流程的输入，活动和输出
369
370
371 图3.2 显示了流程的工作流。
372
373 [[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"]]
374
375 图3.2 服务请求履行的控制流程工作流
376
377
378 流程可能会根据请求模型而有所不同。表3.2 提供了不同模型下的示例
379
380 |活动|手动或不完整的服务请求模型|高度自动化的服务请求模型
381 |请求分类|(((
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 |临时性的履行控制|(% colspan="2" %)(((
408 在某些情况下，服务请求的履行需要一些非标准的，特殊定制的工作，或者有些新情况在计划服务请求时未考虑到。因此，遵循已有规程不会达到期望的结果，只能为服务请求提供临时性的履行方案。
409
410 临时性的履行是一种例外情况，应视为例外情况来处理。
411
412 应该决定是按照例外情况来处理还是直接拒绝履行服务请求。该决定通常由模型和模型处理例外情况的方式来定义。
413
414 不管做出什么决定，此类请求的细节应做为服务请求模型评审和优化的流程输入，这样就可以明确定义此类请求并将其添加到模型中，或者在经过附加的评估分类检查后，将此类请求纳入模型。
415 )))
416 |履行评审|(% colspan="2" %)(((
417 要根据模型对服务请求履行情况进行检验。
418
419 履行评审应该在模型中描述。履行评审会有相应的规程，以检查履行在多大程度上达到了预期的结果。
420
421 履行评审也包括收集用户反馈和衡量用户满意度。
422
423 履行评审的报告和记录用作服务请求评审和优化的流程输入。
424 )))
425
426 表3.2 服务请求履行的控制流程活动
427
428
429 === 3.2.2 **服务请求评审和优化** ===
430
431 本流程专注于服务请求模型管理实践的持续改进。建议定期执行此流程，或由用户调查结果触发执行。该流程包括表3.3中列出的活动，并将输入转换为输出。
432
433 表3.3 服务请求评审和优化流程的输入，活动，和输出.。
434
435 |关键输入|活动|关键输出
436 |(((
437 当前服务请求模型
438
439 用户调查结果
440
441 相关变更和变更模型
442
443 政策法规要求
444
445 服务目录
446
447 服务级别协议
448
449 IT资产信息
450
451 CMDB 配置管理
452
453 容量和性能信息
454 )))|(((
455 服务请求记录和报告分析
456
457 服务请求模型改进启动
458
459 服务请求模型更新沟通
460 )))|(((
461 更新过的服务请求模型
462
463 更新过的服务请求规程和操作说明
464 )))
465
466 图3.3 显示了该流程的工作流程图。
467
468 [[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"]]
469
470 图3.3 服务请求评审和优化流程的工作流
471
472
473 表3.4 提供了该流程活动的描述。
474
475 |活动|描述
476 |服务请求记录和报告分析|服务请求实践负责人与服务负责人和其他相关干系人一起，对在此期间内选定的服务请求和相关指标，以及/或者对来自变更使能实践中的相关重复变更进行评审。他们识别出创建新服务请求模型的机会，和/或当前服务请求模型所需的改进。
477 |服务请求模型改进启动|(((
478 服务请求实践负责人登记和提交模型的改进方案，并与持续改进实践和/或变更请求一起处理。
479
480 如果模型测试不能确认提交的服务请求模型的有效性，便将其退回以进行进一步分析。
481 )))
482 |服务请求模型更新的沟通|如果服务请求模型成功更新，则将其传达给相关干系人。通常由服务请求实践负责人或服务负责人来进行沟通。
483
484 表3.4 服务请求评审和优化流程的活动
深圳市艾拓先锋企业管理咨询有限公司