ITIL 4服务请求管理实践【中文】

陈小宝

2 J5 p* A5 x+ a- f
" I- b! X4 O5 Q

需要下载 ITIL 4服务请求管理实践【中文】pdf版全文，请关注微信公众号itilxf ，并回复“服务请求”即可。

6 |5 y* {7 y; X2 s- f3 W

                                                     

( a" i. \* @7 _9 d* j# [9 s9 w

申明：

) |. y# B8 l0 H1 i$ S- \1 M+ ]

本系列ITIL 4实践中文版本由ITIL先锋论坛专家委员会组织翻译，国内众多从事ITIL理论推广及落地实践的专家们参与，需要下载最新翻译版本请关注微信公众号：ITILXF，也可访问ITIL4中文知识库网站：itil4hub.cn。

  ]  e7 A& H( [; l- Z( y! B, {

请注意，ITIL先锋论坛专家团队仅仅只是进行了这些著作的语种转换工作，我们并不拥有包括原著以及中文发行文件的任何版权，所有版权均为Axoles持有，读者在使用这些文件（含本中文翻译版本）时需完全遵守Axoles 和 TSO所申明的所有版权要求。

翻译：邹庆海        审校：卢曦        审核：刘晓慧   

   

9 Y% P$ q4 N8 ^. @+ F

----

1 关于本文档
$ ]6 ?0 H6 p& }, s7 O0 o/ h5 I' c

本文档为服务请求管理实践提供了实践指南，内容分为五个主要部分，包括：

• 实践的基本信息
• 实践的流程和活动以及它们在服务价值链中的作用
• 实践中涉及的组织和人员
• 支持实践的信息和技术
• 实践中关于合作伙伴和供应商的注意事项
  

1.1 ITIL®4 认证方案
5 {! X% Z8 e0 O7 y& w8 \* L  X

本文档中节选的内容可作为以下课程的一部分进行考核：

' k! {) M3 t; @, M# C+ z* Q5 [$ w

• ITIL专家 创建、交付和支持
• ITIL专家 高速IT
  

& ^  a3 X- m) T, j" R% h

详细信息请参阅相应的教学大纲。

3 N; ~) F9 _! t0 V$ L. m" R. M( `2 基本信息
1 G  F; c/ ~" R' k' ?# D

2.1 目的与描述

定义：服务请求 用户或用户授权代表发起的服务动作的请求，该服务动作已约定为服务交付的正常部分。 : H$ b5 w' y% n; M. X

关键信息 服务请求管理实践的目的是通过有效、友好的方式处理所有约定的、用户发起的服务请求，以此来支持约定的服务质量。

. m9 q" y; X6 g

服务请求是用户问询的重要类型，也是用户体验的重要组成部分。通常，服务请求包括以下内容：

9 y- V9 l+ b/ _

• 发起服务动作请求（由服务提供者或与用户一起执行）
• 信息请求
• 资源或服务访问请求
• 反馈，表扬或投诉
  . f9 v. Q/ o  ~

+ B" }9 t. z! d6 r

服务请求的履行可能涉及对服务或其组件的变更，通常属于标准变更。由于服务请求是预定义的，并且已约定为服务交付的正常部分，因此通常可以通过明确的启动，批准，履行和管理的标准规程，来对其进行标准化。某些服务请求具有非常简单的工作流，例如信息请求。其他服务请求（例如，为新员工设置信息）可能很复杂，需要多个团队和系统的合作才能履行。无论复杂性如何，履行请求的步骤都应该是众所周知并经过测试的。这使得服务提供者可以约定履行请求的时间，并向用户提供服务请求状态的清晰沟通。

服务规程的开发和测试在产品和服务生命周期的相应阶段执行，涉及多种实践，其中包括业务分析，服务设计，风险管理，变更使能，服务目录管理和服务级别管理等。

& m! {* ?9 H% h5 s/ N8 c) U* P

根据财务、信息安全或其他策略要求，某些服务请求需要授权。为了恰当地处理此类请求，服务请求管理实践应该遵循以下准则：

• 服务请求及履行应尽可能标准化和自动化
• 对于可以通过有限的或无需额外批准就可以履行的服务请求，应制定策略以提高效率
• 应根据组织的交付能力明确设定用户对履行时间的期望
• 应识别改进服务的机会并加以实施，以加快履行速度和进一步利用自动化
• 应制定策略和工作流，以便对作为服务请求提交的事件或变更请求进行记录和转单
  9 B7 i+ Z' l. s

某些服务请求完全可以自动化履行从提交到关闭的过程，以提供完美的自助服务体验，例如，客户端的软件安装或虚拟服务器的提供。

2.2 术语和概念

; e& Z( a( Q* W& Y; `0 c0 v

服务请求的主要特征包括：

• 由用户或用户代表发起。
• 需要服务提供者的动作。
• 是一个具有约定服务成果的动作。这就意味着履行请求需要通过服务成果的预先测试，预先批准针对请求的批准和履行流动，进行人员的培训，以及设置履行请求所需的服务组件等。
  2 t9 c* ~  `: `- c1 `3 n7 i

服务请求是服务交付的正常部分，即“日常业务”。服务提供者的客户、用户和运维团队都要很好地理解结果和时间表，这些结果和时间表通常是可预测的。应该尽可能地自动化处理服务请求，并给用户提供有效方便的渠道（例如客户门户）进行访问。

服务请求对服务质量和服务体验的作用会有差异。在许多情况下，当服务动作作为服务交互的一种关键形式时，它们有助于提高服务功用。在某些情况下，服务请求可以提高到更高的服务级别，从而为标准化的服务产品增加有价值的选项。最后，当服务提供者的监控和事态管理能力受到限制，且服务组件的监控被委托给用户时，可以使用服务请求来发起对服务组件的维护。

请注意，服务请求是用户问询的一种形式，也是一种发起特定预定义活动的方式，这些活动对于服务体验很重要。相同的活动可以以不同的方式发起，尽管技术操作可能相同，但对用户体验的作用不同，如表2.1所示。

  {! V+ \$ T$ Z+ o3 U* E2 |

表2.1 其他实践指南中与服务请求实践相关的活动

示例 活动 实践指南 用户监控打印机状态。当打印机提示“碳粉不足”时，用户请求重新填充碳粉。服务提供者的技术人员更换碳粉盒。除了更换过程，打印服务并未中断。 服务请求 服务台 服务请求管理 基础设施和平台管理 打印机将其状态和事态传送给运维团队。当发生“碳粉不足”的事态时，服务提供者的技术人员更换碳粉盒。除了更换过程，打印服务并未中断。 ' @# X2 I5 c% G: f+ ^, r 事态 监控和事态管理 基础设施和平台管理 如果上述场景中出现问题，没有及时报告“碳粉不足”的状况（或未及时更换碳粉盒或未正确更换碳粉盒），打印服务中断。用户将情况反映到服务提供者，服务提供者的技术人员更换碳粉盒，打印服务恢复。 事件 服务台 事件管理 基础设施和平台管理

! m  L3 f4 J- d6 u0 s2 W

5 K1 c2 |3 q7 M

同样，服务请求可以发起变更，通常是标准变更，但有时也可以是一般变更。是否需要变更由公司采用的变更类型方法定义，服务请求和变更之间存在强制性的“关联性”。例如，员工从办公室的一张桌子搬到另一张桌子就可能会被当做一个服务请求进行管理，是否需要进行一项变更还是多项变更，取决于该请求的技术影响，和组织约定的变更标准（作为变更使能实践的一部分）。此类服务请求可能需要实施一个或多个变更来履行，其他类型的服务请求无需涉及变更使能实践即可履行。服务请求的生命周期始终涉及多种实践。履行服务请求的典型价值流大致包括：

3 m" a" N: k1 T$ i% U" d

• 服务台：处理用户问询
• 服务请求管理：转单和指导履行请求
• 基础设施和平台管理：执行必要的技术操作
• 发布管理：使服务组件对用户可用
• 变更使能：协调必要的变更
• 信息安全管理：提供或更改访问权限
  
  : W7 }9 ]+ w5 ]1 D* F

3 w. B6 E5 C  g5 T4 A6 C  N

如有需要，可以引用其他实践。履行每种类型的服务请求所需的其他实践的参与度和规程记录在相应的服务请求模型中。

4 O7 A4 q: L7 W5 o, |7 O3 d

定义：服务请求模型 用于履行特定类型的服务请求的可重复的预定义方法。

* l6 D% \, N9 P8 g

服务请求模型通常在产品和服务设计期间产出。这些模型会与服务的其他组件一起经过测试并部署到运维中。服务请求管理实践在每一阶段都要确保模型是现实可行的，并被参与其管理和执行的每个人所接受。产品和服务的持续改进也包括了相关服务请求模型的改进。服务请求模型描述了履行服务请求的条件和规程，涵盖了服务管理的四个维度：

• 规程和工作流，包括可能的选项和决定
• 负责的角色和团队（通常以RACI职能矩阵的形式）
• 自动化和使用的工具
• 参与的第三方及其支持协议
  
  , E; @, Y+ ]. Y- M2 }

由于服务请求是由用户或其代表发起的，因此它们应该以方便、可操作的方式提供给用户。最常见的方式是在组织服务目录的面向用户视图中包括可用的服务请求。服务目录的管理在服务目录管理实践的范围内，但相关信息由服务请求管理实践提供。

6 h* c% Q  w1 m0 F7 {( N! e- Z

定义：请求目录 服务目录的一种视图，提供了用户可用的已有服务和新服务的服务请求详细信息。

通常，可以通过请求目录获得可用服务请求的以下信息：

5 j, y3 s! }. ~+ O- Z7 r

• 服务请求所属的服务
• 服务请求邀请的前提/条件
• 发起请求所需的信息
• 批准工作流（如果适用）
• 履行请求的目标时间
• 其他相关信息
  & d9 {+ M- l$ H
  
  % t5 Z* E. p; c

服务请求目录视图应针对适用于访问该视图的用户的服务级别协议（SLA）进行定制，以便所有信息均可反映与用户约定的条件和目标。请求目录中的信息越相关，履行服务请求越高效，用户满意度越高。

$ @6 N. K5 Z: o( Z+ L7 \2 t2.3 范围
, b) `) @8 S# {( [4 D+ T- z: K" |5 x5 |

服务请求管理实践的范围包括：

( b8 r+ `+ G" N9 I. x5 P

• 管理服务请求模型
• 处理用户或其代表提交的服务请求
• 根据约定的模型管理服务请求的履行
• 评审并持续改进请求处理和履行的绩效
  

! e& z/ c0 }8 N" H% w

一些活动和职责范围尽管与服务请求管理密切相关，但仍未被包括在服务请求管理实践中，表2.2中列出了这些活动及其所在的实践。重要的是要记住，ITIL所有的实践都是要关联价值流来使用的工具；根据情况，应将它们组合在一起使用。

+ v/ J  g1 s2 S- d; V

表2.2 其他实践指南中与服务请求管理实践相关的活动

活动	实践指南
解决事件	事件管理
与用户沟通	服务台
产品和服务变更的管理与实现	变更使能 部署管理 发布管理
监控服务和技术	监控和事态管理
持续改进的管理与执行	持续改进
请求目录的管理	服务目录管理
服务访问权限的管理和提供	信息安全管理
创建服务请求模型	服务设计

  [* I( i7 B- R( K8 {2.4 实践成功因素

定义：实践成功因素 为履行实践目的所需的一个复杂的实践功能组件。

! s. _8 _" M2 U
. R: p1 G6 B6 G" }) M

实践成功因素（PSF）不仅仅是一项任务或活动，因为它涉及到所有服务管理四维模型的组件。活动的性质和实践成功因素的资源可能有所不同，但它们共同确保实践的有效性。服务请求管理实践包含以下成功因素：

• 确保优化所有服务的服务请求履行规程
• 确保按照约定的规程及用户满意度履行所有服务请求
  

" r6 h$ t% _$ f8 a) l& ?2.4.1 确保优化所有服务的服务请求履行规程

  s6 I, z0 L. e+ j; E4 ]5 C6 W

服务请求规程的开发应该尽早集成到产品和服务生命周期管理中。服务请求实践应该有助于业务分析、架构管理和服务设计活动。根据在这些阶段做出的决定，服务可以针对无请求运维进行优化，或者可以将用户可以使用的多个请求作为正常消耗的一部分。在第一种情况下，用户仍然可以使用通用请求，例如表扬、投诉或请求操作指南。在第二种情况下，可能会有各种特定于服务功用的请求（履行这些请求对于服务质量很重要）。服务请求也可以用于区分不同级别的服务产品（高服务级别的用户可以发起更多请求）。

% j' B( s3 _: e* H4 S$ J1 @

识别、记录、和测试服务请求履行规程并为活动分配责任很重要。同样重要的是，确保在请求目录中正确描述了请求，并且提供给能够发起请求的用户。这是与服务目录管理实践结合实现的。

" X% A8 W8 T# z8 K% e/ L

应基于履行绩效和用户满意度的监控来持续改进服务请求履行规程。优化履行规程的一种方法是尽可能的使其自动执行。这适用于履行工作流中那些变化有限的常用的和例行的请求。特殊定制的，复杂的与不常用的请求仅在经过仔细的考量之后才能自动执行，以确保合理的自动化成本和风险。服务请求模型中记录了服务请求的履行规程以及资源，职责和其他相关信息。
+ {$ y) J0 v: w9 @1 H$ F2 t

2.4.2 确保按照约定的规程及用户满意度履行所有服务请求
' a, @+ ~/ v# l; w( }

如果对履行规程进行了优化和记录，并且职责明确，则服务的请求很容易履行和规划。每种类型请求的统计信息都可以帮助优化资源规划并确保及时处理所有请求。与事件不同，服务的请求无需紧急处理。它们使得规划更轻松，但应在约定的时间范围内完成。

请求履行之后，可能需要评审。评审可以仅限于满意度调查，也可以包括详细的内部评审（通常在出现问题或用户满意度下降的时候才需要）。

! ]9 a3 a) K$ ?" ]# u7 \2.5 关键指标

( x3 |4 E: o4 R$ m. O+ u  |

应该关联到每个实践所贡献的价值流来评估ITIL实践的效果和绩效。与任何工具的绩效一样，只能关联到其应用来评估实践的绩效。但是，工具在设计和质量上可能会有很大差异，这些差异限定了只有在符合其使用目的情况下，工具的潜力或能力才是有效的。有关度量指标，关键绩效指标（KPI）的更多指南以及方法，请参见度量和报告实践指南。

# l( y% q+ d: n: i6 j

服务请求管理实践的关键度量指标已映射到其实践成功因素，可以关联价值流来用作服务请求实践的KPI，以评估其对价值流的效果和效率的贡献。表2.3中给出了一些关键度量指标的示例。

表2.3 实践成功因素的关键度量指标示例

' E, x% n; d/ Z7 i

实践成功因素	关键指标
确保优化所有服务的服务请求履行规程	服务请求目录的完整性、数量、和支持范围外的服务请求的百分比 由于规程的错误或低效而无法遵循约定的规程来履行的服务请求的数量和百分比 通过为团队成员提供操作说明而获取的满意度 履行请求所需的平均时间和成本（按类型或模型） 完全或很大程度上自动履行的服务请求的百分比（数量，目录百分比，总数百分比和履行时间）
确保按照约定的规程及用户满意度履行所有服务请求	符合SLA约定的数量和百分比 未正确履行请求导致的事件影响 用户满意度 不符合约定规程的数量和百分比

将度量指标正确的融入到复杂的指标项中，将使它们更易于用于价值流管理和服务请求管理实践的定期评估和持续改进。没有单一的最佳解决方案。度量指标应基于组织的整体服务战略和优先级，以及实践所贡献的价值流的目标。

3 价值流和流程

3.1 价值流的贡献

像任何其他ITIL 管理实践一样，服务请求实践也对多个价值流做出贡献。重要的是要记住，价值流永远不会由单个实践形成。服务请求实践与其他实践相结合，可以为消费者提供高质量的服务。该实践贡献的主要价值链活动是：

• 契动
• 交付和支持
• 设计和转换
• 获取/构建。
  2 A$ ?- Q. h$ ~3 N: ?

图3.1 中显示了服务请求管理实践对服务价值链的贡献。

- q, @2 \' o4 X

图3.1 服务请求管理实践对价值链贡献的热力图

3.2 流程
8 i, y% k6 [- ]7 O

每个实践可能包含一个或多个履行该实践目的所必需的流程和活动。
! u$ l* [# c/ Z1 e; q

5 z6 `4 p. Y% W$ d4 L0 w

定义：流程 流程是一组相互关联，相互交互的，将输入转换为输出的活动。流程获得一个或多个定义的输入，并将其转换为定义的输出。流程定义动作的顺序及其依赖性。 5 g+ f. [" D1 ^

服务请求管理活动形成两个流程：

) k2 y) Z3 g& \! l4 |6 g1 T

• 服务请求履行控制
• 服务请求评审和优化
  

) x7 j' l: v7 Z" H: T$ F- x, s3.2.1 服务请求履行控制

该流程包括表3.1 中列出的活动，并将输入转换为输出。

关键输入	活动	关键输出
服务请求问询 服务请求模型 服务级别协议 履行动作记录和报告	请求分类 服务请求模型初始化和控制 临时性的履行控制 履行评审	履行服务请求 履行动作记录和报告 用户满意度调查

表3.1 服务请求履行控制流程的输入，活动和输出

9 }6 l' X1 d( q; d8 f! s

图3.2 显示了流程的工作流。

图3.2 服务请求履行的控制流程工作流

0 q' L- _  V& b& ?

流程可能会根据请求模型而有所不同。表3.2 提供了不同模型下的示例

活动	手动或不完整的服务请求模型	高度自动化的服务请求模型
请求分类	完全或部分依赖手动来核对服务请求和用户资格。需要人工联系用户提供缺少的信息或纸质文件。 服务台专员选择适当的服务请求模型。 * {8 r  S/ j% F& K( Z9 p4 B  b	在高度自动化的环境中，系统将自动核对服务请求。系统联系用户提供缺少的信息或纸质文件。 根据服务请求的特征选择适当的模型和自动化规程。    ' ?$ {& l9 p5 m) [4 v
服务请求模型初始化和控制	根据服务请求模型，服务台专员可能需要手动选择合适的支持团队或专家。分配的支持团队遵循为模型定义的服务请求履行规程。 如有必要，可以根据服务请求规程要求额外的批准。 在某些情况下，需要同时履行多个服务请求任务。需要由服务台专员进行手动分配和控制，以及发送用户通知。 负责的团队可以履行整个服务请求或特定任务。 如有必要，负责的团队也要更新相关的配置项。 服务请求需要经过履行评审。	根据所选的服务请求模型，请求履行会被启动，并且由系统来控制规程流向和履行请求的脚本。 服务请求需要经过履行评审。 + ~; g' \& |: a
临时性的履行控制	在某些情况下，服务请求的履行需要一些非标准的，特殊定制的工作，或者有些新情况在计划服务请求时未考虑到。因此，遵循已有规程不会达到期望的结果，只能为服务请求提供临时性的履行方案。 临时性的履行是一种例外情况，应视为例外情况来处理。 应该决定是按照例外情况来处理还是直接拒绝履行服务请求。该决定通常由模型和模型处理例外情况的方式来定义。 不管做出什么决定，此类请求的细节应做为服务请求模型评审和优化的流程输入，这样就可以明确定义此类请求并将其添加到模型中，或者在经过附加的评估分类检查后，将此类请求纳入模型。
履行评审	要根据模型对服务请求履行情况进行检验。 履行评审应该在模型中描述。履行评审会有相应的规程，以检查履行在多大程度上达到了预期的结果。 履行评审也包括收集用户反馈和衡量用户满意度。 履行评审的报告和记录用作服务请求评审和优化的流程输入。 4 c; t# L! `, P4 S

表3.2 服务请求履行的控制流程活动

3 R+ Q% @$ j3 U- W3.2.2 服务请求评审和优化
. H; L8 `5 y- H. ^

本流程专注于服务请求模型管理实践的持续改进。建议定期执行此流程，或由用户调查结果触发执行。该流程包括表3.3中列出的活动，并将输入转换为输出。

. W1 f% w" S, ^; }6 A  [

表3.3 服务请求评审和优化流程的输入，活动，和输出.。

关键输入	活动	关键输出
当前服务请求模型 用户调查结果 相关变更和变更模型 政策法规要求 服务目录 服务级别协议 IT资产信息 CMDB 配置管理 容量和性能信息	服务请求记录和报告分析 服务请求模型改进启动 服务请求模型更新沟通	更新过的服务请求模型 更新过的服务请求规程和操作说明

图3.3 显示了该流程的工作流程图。

) W6 t& D# A: p: D/ H" z

图3.3 服务请求评审和优化流程的工作流

4 J, w+ t' r& j7 M

表3.4 提供了该流程活动的描述。

9 D% |6 o2 p- Y8 N

活动	描述
服务请求记录和报告分析	服务请求实践负责人与服务负责人和其他相关干系人一起，对在此期间内选定的服务请求和相关指标，以及/或者对来自变更使能实践中的相关重复变更进行评审。他们识别出创建新服务请求模型的机会，和/或当前服务请求模型所需的改进。
服务请求模型改进启动	服务请求实践负责人登记和提交模型的改进方案，并与持续改进实践和/或变更请求一起处理。 如果模型测试不能确认 提交的服务请求模型的有效性，便将其退回以进行进一步分析。
服务请求模型更新的沟通	如果服务请求模型成功更新，则将其传达给相关干系人。通常由服务请求实践负责人或服务负责人来进行沟通。

表3.4 服务请求评审和优化流程的活动

, G6 w4 u1 ~4 }3 _1 C/ @
0 H; r, @1 n+ Z6 w

4 组织和人员

0 V- {7 K' A0 n$ p% @7 x4 Y

4.1角色，能力和责任

: y8 a+ o5 Z& v

实践指南没有描述实践管理的角色，例如实践负责人，实践主管或实践教练。相反，他们专注于针对每个实践的专家角色。组织不同，每个角色的结构和命名也可能不同，因此ITIL中定义的任何角色都不应被视为强制性的，甚至不应被视为推荐性的。请记住，角色不是职务。一个人可以担任多个角色，一个角色也可以分配给多个人。

$ b4 n( q9 A9 Z

角色是关联到流程和活动中来描述的。每个角色都具有基于表4.1中所示的模型的能力概况特征。

能力代码	能力描述（活动和技能）
L	领导者 决策，委派，监督其他活动，激励团队，提供动力以及评估成果
А	管理员 分配任务并确定优先级，保留记录，持续报告并启动基本的改进
C	协调员/沟通者 多方协调，维护相关干系人之间的沟通，并负责有关认知的宣传活动
М	方法和技术专家 设计和实施工作技术，编制规程文档，提供流程、工作分析和持续改进的咨询
Т	技术专家 提供技术（IT）专业知识，并执行基于专业知识的任务

表4.1 能力代码和描述

服务请求管理实践没有特定的专家角色。请求发起方的角色可以是任何用户或用户授权代表；不需要特殊的技能或能力。上面描述的服务流程的关键活动通常由服务提供者的技术专家，服务负责人和用户支持专员执行，但是没有或只有非常少的针对该实践的能力类型。

表4.2 中列出了服务请求管理活动中可能涉及的其他角色的示例，以及相关的能力类型和特定技能。

* a  P! ]/ T5 `4 K: C

活动	负责角色	能力类型	特定技能
服务请求履行控制流程
请求分类	用户支持专员 产品负责人 服务负责人	CTM	熟悉组织的产品和服务
	技术专家	7 n4 c' ]: g/ V( T7 `$ j& s1 x1 r	了解服务目录，SLA， 请求模型
服务请求模型初始化和控制	用户支持专员 服务负责人 技术专家	CAT	熟悉服务请求模型和服务提供者组织
临时性的履行控制	服务负责人 技术团队主管	CTA	熟悉产品，服务和SLA 了解业务需求 有权分配资源和计划临时性工作 ( b2 c* d5 d: `9 }7 ~  O2 O9 e
履行评审	服务负责人 实践负责人 实践经理/协调人	MCT	熟悉产品，服务和SLA 了解业务需求 熟悉服务请求模型和服务提供者组织
服务请求和评审优化	2 ~) b# S* g$ D$ @) E		% G0 g0 r# g9 d' {! }1 k+ R. D. M
服务请求记录和报告分析	产品负责人 服务负责人 实践负责人 实践经理/协调人 , Z. d7 o, j7 f2 }% c( o	TM	熟悉服务和产品，及服务请求模型
服务请求模型改进启动	实践负责人 实践经理/协调人 产品负责人 服务负责人 资源负责人 ITSM工具顾问 7 G* b: x  J! p( O# i* s& \3 T	TCA	熟悉服务和产品，及服务请求模型 熟悉可用的工具和方法 * `4 x% x* T. m" S' i0 v, @. a+ A
服务请求模型更新沟通	实践负责人 实践经理/协调人 . [& l. C2 g5 f. l	C	了解服务请求模型 沟通技巧 ! s+ T1 H+ {& A5 }" e. Y
( B* s5 V5 B; ?/ J	产品负责人 服务负责人 资源负责人

表4.2 服务请求管理实践活动中涉及的角色示例

4.2 组织结构和团队

设立专门的组织结构来管理服务请求管理实践是不常见的。该实践集成在服务交付和实现团队或技术人员的日常活动中，这些都是在服务请求模型定义期间预先定义好的。服务请求管理实践与事件管理实践通常共享相同的团队结构。但是，如果把服务请求作为服务功用的一部分，并且需求量很高的时候，则可以成立专门的团队来处理和履行所有或某些类型的服务请求。在许多情况下，实施自动化可以减少对此类团队的需求，并可改进服务质量。

" F  O! z. x* q# s1 [4 l8 Y" ]
5 信息和技术
& ~1 c1 {5 d5 n: q' n! R
5.1 信息交流
- m4 i# g, T( O

服务请求管理实践的效果基于所使用信息的质量。这里提到的信息包括但不限于以下信息：

) r& V+ H2 _$ |* y/ ]7 \

• 客户和用户
• 服务及其关联的请求目录和请求模型
• 合作伙伴和供应商，以及它们提供的服务的信息
• 规范提供服务的政策和要求
• 相关干系人对实践的满意度。
  

# C1 p1 Z2 M# n" n; F1 M4 S

该信息可以采用各种形式。实践的关键输入和输出在本指南的价值流和流程部分中列出。

0 s: |8 ]0 y0 ~2 h4 m! E- n5.2 自动化和工具   

! A) _3 M$ f4 A5 j3 j" e9 q

在某些情况下，服务请求管理实践的工作可以大大受益于自动化。在可能且有效的情况下，可能涉及表5.1中概述的解决方案。

6 _! H% J! \! J2 T& t% \

表5.1 服务请求管理活动的自动化解决方案

& M3 T2 l+ i" |5 Q7 E4 X7 Q0 w

流程活动	自动化手段	关键功能	对实践效果的影响
服务请求履行控制
请求分类	工作流管理和协作工具 ITSM工具集	请求目录管理 工作分配 预定义的规程流向	高
服务请求模型初始化和控制	工作流管理和协作工具 ITSM工具集 2 V$ l' H: f) A7 X" v	工作分配 预定义的规程流向 协作，任务	高
临时性的履行控制	工作流管理和协作工具 ITSM工具集 系统监控工具 ' W' U2 @6 q  ]# a  }8 ?6 v	监控工作进度 沟通 通知，升级 ; \* j( v4 Q. J: c) P/ w	中到高
履行评审	工作流管理和协作工具 ITSM工具集	沟通与协作 报告与分析	中
服务请求和评审优化
服务请求记录和报告分析	分析和报告工具	服务请求的统计分析 工作量和流量 & ~4 I" }( p  T/ P	高
服务请求模型改进启动	工作流管理和协作工具	待办项和工作流的管理与可视化 沟通与协作	中到高
服务请求模型更新沟通	发布工具 社交媒体 工作流管理工具	邮件 推送通知 Web门户 认知消息发布	高

6 合作伙伴和供应商

% C4 g% j$ ?4 ~( p$ C0 Z

组织很少只使用自己的资源来交付服务，多数（如果不是全部）依赖于其他服务，这些服务通常由组织之外的第三方提供（请参阅ITIL Foundation：ITIL 4 Edition的2.4节：服务关系模型）。通过服务支持所引入的第三方的关联性和依赖性是通过服务设计、架构管理，和供应商管理这些实践所描述的。

由于服务请求的内在特性（例如预定义，预先批准和可预测），组织会自然地将服务请求管理外包。组织应该慎重地维持服务请求管理的高标准，因为它会直接影响用户的满意度，而且可能对服务价值带来不良影响。

服务请求模型应定义第三方如何参与服务请求履行以及如何确保组织有效的协作。这将取决于产品、服务和价值流的架构和设计解决方案。不过支持这些解决方案的服务请求模型优化仍将涉及服务请求管理实践。

9 T& g1 c1 W5 w7 e  S) u

为了使供应商成为组织生态系统的一部分，沟通协作条件和要求的一个简便方法是定义好标准的接口、接口描述可以包括数据交换规则、工具以及流程，来创建一种多厂商环境中的共同语言。

当组织想要确保快速有效的服务请求管理实践时，他们通常会设法与其合作伙伴和供应商约定紧密的合作，并消除沟通，协作和决策方面的形式化的官僚壁垒（更多信息，请参见供应商管理实践指南）。

$ x! S7 y# G/ d: T7 W

! I4 h, {$ n& D6 C+ E' _' X

7 重要提醒
9 u* x* G3 M8 b5 f) T; d$ ~
9 R' F; Y+ C( [3 {$ i$ I# w组织在建立和发展自己的实践时，应考虑将实践指南的大部分内容只作为建议参考。实践指南是组织可以考虑的主题目录，而不是答案列表。使用实践指南的内容时，组织应始终遵循ITIL 指导原则：

9 P. s5 y7 t6 A" t0 q

• 聚焦价值
• 从你所处的地方开始
• 基于反馈迭代推进
• 协作和提升可视化程度
• 通盘思考和工作
• 保持简单实用
• 优化和自动化。
  

有关指导原则及其应用的更多信息，请参见ITIL Foundation：ITIL 4 Edition的4.3节。

8 致谢

3 Z1 X( n, a( z' i6 K3 J+ }, EAXELOS Ltd非常感谢为本指南的开发做出贡献的每一个人。这些实践指南融合了ITIL社区前所未有的热情和反馈。AXELOS特别要感谢以下人员。
% _! M3 x7 s* z  e" [' ]( x

8.1 作者

, c: N  A8 |# l5 M3 F# `

MiroslavHlohovsky，Don Page，RobertPinnington。

8.2 审稿人

DinaraAdyrbayeva，Cheryl Grimes，RomanJouravlev，GeorgesKemmerling，HennyKerkvliet，Niels Loader，AntonLykov，PauloTourinho。