返回 ITIL 4理论与实践整体知识体系中文版发布文件汇总

最新消息：本实践中文翻译发布版已经推出，请点击 http://ITIL-foundation.cn/thread-140690-1-1.html 下载。

需要下载最新翻译版本请关注微信公众号：ITILXF，并回复“服务请求管理”即可。

服务请求是用户查询的重要类型，也是用户体验的重要组成部分。通常，服务请求包括以下内容：
●        发起服务动作的请求（由服务提供者执行或与用户一起执行）
●        要求信息
●        访问资源或服务的请求
●        反馈，表扬或投诉。


满足服务请求可能包括对服务或其组件的更改；这些通常是标准的更改。由于服务的请求是预定义的，并且已预先同意作为服务交付的正常部分，因此通常可以使用清晰的标准发起，批准，实现和管理程序来对其进行形式化。某些服务请求具有非常简单的工作流，例如信息请求。其他服务请求（例如，新员工的设置）可能很复杂，需要许多团队和系统的帮助才能实现。无论复杂性如何，满足请求的步骤都应该众所周知并经过测试。这使服务提供者可以约定实现的时间，并向用户提供请求的状况的清晰通信。


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


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


●        服务请求及其实现应该尽可能标准化和自动化
●        应根据可以满足服务要求的情况建立政策，而有限或无其他批准可以简化实现
●        用户对实现时间的期望应根据组织可以提供的内容明确设定
●        应确定并实施改进点的机会，以产生更快的实现时间并利用自动化
●        应该包含策略和工作流，以记录和重定向作为服务请求提交的任何请求，但应将其作为事件或更改进行管理。


从提交到关闭，某些服务请求可以完全通过自动化来实现，从而实现完整的服务体验。例如，安装客户软件或提供虚拟服务器。



2.2        术语和概念
  
服务请求的主要特征包括：
●        它由用户或用户代表启动。
●        它需要服务提供者中的性能或绩效。
●        这是一个性能或绩效，它已同意服务成果。这意味着服务成果已经过测试，预先批准了针对该请求的批准流动和实现流动，对人员进行了培训，并设置了服务组件来实现此要求。


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


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


请注意，服务请求是用户查询的一种形式，也是一种初始化对服务体验有意义的预定义活动的方式。相同的活动可以以不同的方式启动，尽管技术操作可能相同，但用户体验中的角色可能不同，如表2.1所示。


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




例        
实现价值        
实践指南


用户监视打印机的状况。当打印机提示“碳粉不足”时，用户要求重新填充碳粉。服务提供者的技术人员更换了碳粉盒。除了更换的规程，打印不打断了。
               
服务请求        服务台
服务请求管理
基础设施和平台管理
打印机将其状况和事件传达给操作团队。当发生“碳粉不足”的事态时，服务提供者的技术人员将更换碳粉盒。除了更换的规程，打印不打断了。        

事态        监控和事态管理


基础设施和平台管理


如果上述场景中出现问题，请执行以下操作。没有及时报告“碳粉不足” 状况（或未及时更换碳粉盒或未正确更换碳粉盒）。打印中断。用户将报告的情况发送到服务提供者。服务提供者的技术人员取代了碳粉盒。打印为恢复。


事件        服务台

事件管理
基础设施和平台管理


同样，服务请求可以发起更改，通常是标准更改，但有时可以是一般变更。对变更的需求由公司采用的变更类型定义。服务请求和更改之间存在强制性的“关联。例如，



服务请求可以管理员工从办公室的一张桌子转移到另一张桌子。需求是变更还是多项更改，取决于技术上的影响和准则是否同意组织（作为变更使能实践的一部分）中的更改。某些此类的服务请求可能需要一个或多个更改。无需变更使能实践即可完成其他任务。


服务请求的生命周期始终涉及多种实践。满足服务请求的典型价值流可能涉及：
●        服务台：对流程进行用户查询
●        服务请求管理：路由和指导请求履行
●        基础设施和平台管理：执行必要的技术操作
●        发布管理：使服务组件对用户可用
●        变更使能：协调必要的更改
●        信息安全管理：提供或更改访问。


如果需要，可以涉及其他实践。服务请求型号中记录了用于实现每种服务请求类型的参与度和规程。






服务请求模型通常在生产和服务设计期间生产。测试了这些模型并将其与服务的其他组件一起部署到操作中。服务请求管理实践在所有阶段都参与其中，以确保模型是现实的，并被参与其管理和执行的每个人所接受。产品和服务的持续改进可能包括相关服务请求型号的改进点。


服务请求模型描述了服务请求履行的条件和过程，涵盖了所有服务管理四维模型：
●        程序和工作流，包括可能的选项和决定
●        负责的角色和团队（通常是RACI职能矩阵矩阵型）
●        自动化和使用的工具
●        参与并支持协议的第三方。
由于服务请求是由用户或其代表发起的，因此它们应该以方便，可操作的方式提供给用户。最常见的方法是在面向组织的服务目录的面向用户的视图中包括可用的服务请求。目录的管理位于服务目录管理实践的范围中，但有关信息由服务请求管理实践提供。




通常，可以通过请求目录获得有关可用服务请求的以下信息：
●        服务请求所属的服务
●        服务请求邀请的先决条件/条件
●        发起请求所需的信息
●        批准工作流程（如果适用）
●        目标实现时间
●        其他相关信息。



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






Service requests are an important type of user query and an important part of the user experience. Typically, service requests include the following:
●        a request initiating a service action (performed by the service provider or jointly with the user)
●        a request for information
●        a request for access to a resource or service
●        feedback, compliments, or complaints.
Fulfilling service requests may include changes to services or their components; these are usually standard changes. As service requests are predefined and pre-agreed as a normal part of service delivery, they can usually be formalized with a clear, standard procedures for initiation, approval, fulfilment, and management. Some service requests have very simple workflows, such as a request for information. Other service requests, such as the setup of a new employee, may be complex and require contributions from many teams and systems in order for it to be fulfilled. Regardless of the complexity, the steps to fulfil the request should be well-known and tested. This allows the  service provider to agree times for fulfilment and provide clear communication of the status of the request to users.


The development and testing of the procedures are performed at the respective stages of the product and service lifecycle and involve multiple practices, such as the business analysis, service design, risk management, change enablement, service catalogue management, and service level management practices, among others.


Some service requests require authorization, according to financial, information security, or other policies. In order to handle this appropriately, the service request management practice should follow these guidelines:
●        service requests and their fulfilment should be standardized and automated as far as possible
●        policies should be established depending on which service requests can be fulfilled with limited or no additional approvals to streamline fulfilment
●        user expectations regarding fulfilment times should be clearly set based on what the organization can deliver
●        opportunities for improvement should be identified and implemented to produce faster fulfilment times and leverage automation
●        policies and workflows should be included for documenting and redirecting any requests that are submitted as service requests, but which should be managed as incidents or changes.
Some service requests can be completely fulfilled by automation, from submission to closure, allowing for a complete self-service experience. For example, client software installation or the provision of virtual servers.



2.2        TERMS AND CONCEPTS
  
The main characteristics of a service request includes the following:
●        It is initiated by a user or a user representative.
●        It requires an action from the service provider.
●        It is an action that has an agreed upon service outcome. This means the service outcome was tested in advance, the approval flow and fulfilment flow for the request were pre-approved, people were trained, and service components were setup to fulfil it.


A service request is a normal part of service delivery, which is ‘business as usual’. This means the results and the timelines are well understood by the customer, users, and operation teams of the service provider, and are usually predictable. Wherever possible, service requests should be automated and accessible through channels that are efficient and convenient for users, such as a client portal.


Service requests may play different roles within service quality and service experience. In many cases, they contribute to service utility when service actions are a key form of service interaction. In some cases, service requests can add to higher service levels, adding valuable options to otherwise standardized service offerings. Finally, service requests may be used to initiate the maintenance of service components, where the service provider’s monitoring and event management capability is limited and the monitoring of service components is delegated to users.


Note that service requests are a form of user query and a way to initiate certain predefined activities significant to service experience. The same activities may be initiated differently, and although technical operations may be identical, their role in the user experience would be different, as shown in Table 2.1.


Table 2.1 Activities related to the service request practice described in other practice guides




Example        
Activity        
Practice guide


A user monitors status of a printer. When the printer signals ‘low toner’, the user requests toner refill. The service provider’s technician replaces the toner cartridge. Except for the replacement procedure, printing is not
interrupted.               
Service request        Service desk
Service request management
Infrastructure and platform management
A printer communicates its status and events to the operations team. When a ‘low toner’ event occurs, the service provider’s technician replaces the toner cartridge. Except for the replacement procedure, printing is not
interrupted.                Event        Monitoring and event management
Infrastructure and platform management
In the case of something going wrong in the above scenarios. The ‘low toner’ status is not reported in time (or the cartridge is not replaced in time or replaced incorrectly). The printing is interrupted. Users report the situation to the service provider. The service provider’s technician replaces the
toner cartridge. Printing is restored.                Incident        Service desk
Incident management
Infrastructure and platform management


Similarly, service requests may initiate changes, which are usually standard changes but can sometimes be a normal change. The need for change is defined by the change typology adopted by the company; there is mandatory 'correlation between service requests and changes. For example,



moving an employee from one desk to another within the office is likely to be managed as a service request; whether it needs a change or multiple changes, depends on technical impact of the move and criteria for changes agreed in the organization (as part of the change enablement practice). Some service requests of this type may need one or more changes; others would be fulfilled without the change enablement practice involved.


The lifecycle of a service request always involves multiple practices. A typical value stream to fulfil a service request is likely to involve:
●        service desk: to process the user query
●        service request management: to route and guide the request fulfilment
●        infrastructure and platform management: to perform the necessary technical operations
●        release management: to make the service components available to users
●        change enablement: to coordinate the necessary changes
●        information security management: to provide or alter access.
Other practices may be involved, as needed. The involvement and procedure for fulfilling every type of service request is documented in the service request models.






Service request models are usually produced during product and service design. The models are tested and deployed to operations along with other components of the service. The service request management practice is involved at all stages to ensure that the models are realistic and accepted by everyone involved in their management and execution. The continual improvement of products and services may include the improvement of the related service request models.


Service request models describe the conditions and procedures for service request fulfilment, covering all four dimensions of service management:
●        procedures and workflows, including possible options and decisions
●        roles and teams responsible (usually as a RACI matrix)
●        automation and tools used
●        third parties involved in and supporting agreements.
As service requests are initiated by users or their representatives, they should be available to users in a convenient and actionable way. The most common approach is to include the available service requests in user-facing views of the organization’s service catalogue. Management of the catalogue is within the scope of the service catalogue management practice, but information for it is provided by the service request management practice.




Usually, the following information about the available service requests is available through a request catalogue:
●        service to which a service request belongs
●        prerequisites/conditions for a service request invitation
●        information required to initiate the request
●        approval workflow, if applicable
●        target fulfilment time
●        other relevant information.



The service request catalogue view is expected to be tailored for service level agreements (SLAs) that are applicable to the user accessing the view, so that all of the information reflects the conditions and targets agreed for the user. The more relevant the information in the request catalogue is, the more efficient the service request fulfilment will be, and the higher the user satisfaction.


申明：
本文档由长河（微信achotsao）在机译的基础上经初步整理而成，精细化翻译工作正由ITIL培训基地组织的ITIL专家团队进行之中，预计将于2020年年底之前全部完成。需要下载最终翻译版本请关注微信公众号：ITILXF，或访问www.ITIL4hub.cn  or  ITIL-foundation.cn。


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

写
谢谢

谢谢分享！