【ITIL4】34服务实践 - 服务请求管理

文章目录

[【ITIL4】34服务实践 - 服务请求管理](#【ITIL4】34服务实践 - 服务请求管理)
- [一. 服务请求](#一. 服务请求)
- 二、服务请求目的
- 三、服务请求管理实践内容
- 四、服务请求管理遵循的准则
- [五. 对价值链的贡献](#五. 对价值链的贡献)
- [六. 最佳实践建议](#六. 最佳实践建议)
- [七. 如何区分服务请求与事件](#七. 如何区分服务请求与事件)
- - 核心区别对比

一. 服务请求

ITIL4中的服务请求管理（Service Request Management）来自用户或用户授权代表的请求。该请求启动了一项服务行动，该行动已被同意为服务交付的正常部分。

二、服务请求目的

服务请求管理实践的目的是通过以有效和用户友好的方式处理所有预先定义的，由用户发起的服务请求来支持商定的服务质量。

三、服务请求管理实践内容

要求提供服务的行动
要求提供信息
提供资源或服务的请求
对资源或服务的访问请求
反馈、表扬和投诉

服务请求的履行可能包括对服务或其组成部分的变更；通常这些是标准变更 。服务请求是服务交付的正常部分，不是服务的失败或降级，后者作为事故（事件）处理。由于服务请求作为服务交付的正常部分被预先定义和预先约定，它们通常可以被正式化、具有明确的、标准的启动、批准、履行和管理程序。无论复杂的程度如何、满足请求的步骤应该是众所周知的，并且是经过验证的。这使得服务提供商能够商定履行的时间，并向用户提供清晰的请求状态的沟通。

四、服务请求管理遵循的准则

服务请求及其履行应尽可能地标准化和自动化；
应该制定政策、规定哪些服务请求可以在有限的甚至不需要额外批准的情况下得到满足，这样就可以简化履行程序；
用户对履行时间的期望，应该根据组织能够实际提供的情况明确设定；
应该确定和实践改进机会，以产生更快的履行时间并利用自动化的优势；
应包括政策和工作流程，以记录和重定向任何作为服务请求提交的请求但实际上应作为事故或变更来管理；

一些服务请求从提交到结束可以完全由自动化完成，从而实现完整的自动服务体验。服务请求管理依赖于精心设计的流程和程序，通过跟踪和自动化使之可操作化，从而使实践效率最大化。不同类型的服务请求将有不同的履行工作流程，但如果确定了有限数量的工作流程模型，效率和可维护性都将得到改进。当新的服务请求添加到服务目录中时，应尽量利用现有的工作流程模型

五. 对价值链的贡献

**改进：**服务请求可以为改进措施、表扬和来自用户的投诉提供一个渠道。它还通过提供关于请求满足情况的趋势、质量和反馈信息来促进改进。
**参与：**服务请求管理包括定期沟通、以收集用户的具体需求，设定预期，并提供状态更新。
**设计和转换：**标准的服务组件可通过服务请求的履行转换到实际环境。
**获取和构建：**获得预先批准的服务组件可通过服务请求完成。

六. 最佳实践建议

构建清晰的服务目录：使用业务语言而非技术术语，确保服务内容明确、易于查找和理解。
分层分类管理请求：不要"一刀切"。将请求分为标准、常规、复杂等不同类型，分别采用全自动、半自动、人工处理等不同模式。
简化审批流程：在满足合规要求的前提下，尽量减少不必要的审批环节，避免流程停滞。
推进运维自动化：优先识别高频、低风险的请求进行自动化改造，如新员工入职、权限调整等。
建立持续改进机制：定期收集用户反馈，分析请求数据（如处理时长、积压量），持续优化流程和模型。

七. 如何区分服务请求与事件

在 ITIL 框架中，准确区分服务请求与事件是高效 IT 服务管理的基础。两者最核心的区别在于：服务请求是用户主动发起的、预定义的常规需求，而事件是对计划外的服务中断或质量下降的响应。

核心区别对比

方面	事件 (Incident)	服务请求 (Service Request)
定义	IT 服务的计划外中断或服务质量下降。	用户对信息、建议、标准变更或访问 IT 服务的正式请求。
性质	被动响应，是系统出现了故障或异常。	主动发起，是用户需要一项标准服务。
目标	尽快恢复正常的服务运营，将对业务的影响降到最低。	通过标准化的流程，高效地满足用户的常规需求。
紧急度	通常较高，需要立即关注以恢复业务。	遵循预定义的服务级别协议（SLA），按计划处理。
审批	无需审批，重点是快速修复。	可能需要基于成本或策略的预定义审批。
示例	系统崩溃、网络中断、应用程序报错、无法登录。	密码重置、申请新软件、请求新硬件、信息查询。