ITSM 流程落地经验之请求管理

直达原文:ITSM流程落地经验之请求管理

在IT服务管理中,流程的落地和执行至关重要。请求管理作为ITSM的重要组成部分,直接影响到组织内部的服务交付和用户满意度。为了确保请求管理流程的高效性和规范性,我们不仅需要清晰地区分不同类型的请求,还需要优化请求的履行工作流程。本文将分享一些在ITSM流程落地过程中关于请求管理的实际经验,探讨如何区分请求类型、优化请求履行工作流、标准化请求模型,以提升整体服务水平。

区分请求类型

不同的请求类型与不同的服务水平关联,并且具有不同的优先级和路由规则,例如某些组织的大部分事件都会在一个工作日内解决,但是服务请求可能会需要较长的时间才能够完成。

区分这些不同的类型,有利于明晰后续不同的处理策略,同时不会由于处理效率参差不齐让用户感到困惑。

在很多组织中对于事件和服务请求未进行区分,虽然在以往的最佳实践的版本中,曾经把二者融合在一起,但是由于管理的持续精细化,区分二者能够让IT服务组织提供的服务更加优质。那应该如何进行区分呢?

事件是指正常的服务意外中断或性能下降,目的是尽快恢复服务,例如打印机无法正常工作,系统访问速度缓慢等;

服务请求是不涉及损坏或对服务产生直接影响的任务。它们不需要被立刻解决,通常可以安排在某个时间进行处理(例如安装某个软件)。

以下是区分事件和服务请求的一些参考:

区分服务请求和项目

区分服务请求和项目非常重要。项目可能包括需求、任务等活动,在很多的组织中,服务请求的流程效率较低的原因,就是由于未进行区分,导致少数项目影响了整体服务水平。服务团队需要了解这两者之间的差异,确保遵循正确的流程,且项目的受理条件要比服务请求严格很多,需要避免最终用户为了逃避项目管理中的严格条件,进而选择通过使用服务请求的方式完成这些项目。

那服务请求和项目之间有什么区别?

  • 主要差异包括资源范围、频率和风险。
  • 与项目相比,请求可能需要更少的资源,更容易得到满足,并且涉及的风险也更小。
  • 请求通常由整个 IT 组织的 一线和二线团队完成。
  • 如果请求的范围超出正常请求的范围,则请求可能会变成一个小项目。

示例

一家中型公司正在进行集中招聘,需要在一个季度内招募150名新员工,然而,处理这150名新员工的“新员工入职”流程请求,将是一项耗时费力且资源密集型的任务。这种情况下,IT服务团队可能无法按照既定的服务水平为HR部门提供对应的服务。由于项目的服务请求在风险、工作量、资源需求上并不是一个量级,所以这种具备项目特征的请求,应由PMO团队进行收集和处理。在后续的内容中,包含区分服务请求和项目的示例。

请求履行工作流程的优化

简化流程

流程中存在冗余会影响流程的效率,并且许多组织几乎为每一个服务设计了独立不同的流程,在最初设计后和运行很长一段时间内并没有对流程的效率效果进行回顾,导致随着其他因素的变化,流程的运行变得臃肿缓慢。

参考以下问题检查服务的工作流程是否有冗余:

  • 哪些请求的批准率几乎为 100%?
  • 去掉个人审批环节有何影响?
  • 每个请求多少次会被流转多少次?
  • 每个团队在满足请求流程中的主要角色和任务是什么?
  • 是否有不必要角色?

定期对所有的流程进行回顾,并检查其中可以简化的环节,提升流程的效率和效果。

优化审批

请求的处理需要适当的授权,在不少组织中,经常出现请求履行和审批互相穿插的情况,这种方式会大大地降低流程整体的效率,在授权的过程中,建议通过审批前置和集中的方式进行授权,甚至对那些100%通过审批的过程,在合规的前提下,可以考虑去掉这些环节,加速整个过程的履行效率。

组织在ITSM实施初可能无法识别这些请求类型,通常会使用一个通用的请求模型,但持续使用这种通用的请求模型,在效率、自动化能力、用户体验上,都无法有效地提升。

因此,当组织在持续应用并优化通用请求模型的过程中,经过一定时间的积累,若已形成了较为丰富且高质量的数据基础,便可以抽象出多样化的请求模型。

在所有请求模型分布中,标准请求和咨询请求应占组织整体请求的大部分,仅少数无法做出判断的场景使用通用服务请求模型。通过持续对服务请求模型的梳理和抽象,形成多个不同的标准请求模型,也为后续的流程优化和自动化奠定基础,也为服务目录的整理和发布做好准备。

标准化请求

区分请求类型可以让标准请求按照既定的规则自动路由,避免工单积压和快速增长,也可以让用户/客户了解不同服务的内容,尤其是当前未提供的服务或者产品,并认识到后续可能会出现额外的审批或需要更多的时间寻求解决方案。

标准请求和通用服务请求各有一些特性,组织可以结合以下特点进行识别:

标准请求:

  • 非常常见,频繁和持续地被提出;
  • 完成这些请求通常需要几个小时或几天的时间;
  • 如果有服务目录,这些请求通常会使用服务目录进行处理;
  • 正式化定义了履行流程并应已记录在文档中;
  • 定义了处理时间。

通用服务请求:

  • 比标准请求要复杂很多;
  • 无法通过服务目录使用;
  • 没有明确的处理流程;
  • 未提供对应的产品或服务,可能需要时间进行技术方案分析,更多的审批甚至需要采购。

以下是某IT组织区别标准服务请求、通用服务请求和项目的策略的示例:

在ITSM流程中,通过科学地区分请求类型、明确事件与服务请求的界限,优化请求履行工作流程,以及标准化请求模型,IT服务团队可以更好地应对日常服务需求,提升服务质量。希望本文的经验分享能为各组织在ITSM流程的落地和优化中提供有价值的参考,助力实现更高效、更优质的IT服务管理。

直达原文:ITSM流程落地经验之请求管理

微软开源基于 Rust 的 OpenHCL 字节跳动商业化团队模型训练被“投毒”,内部人士称未影响豆包大模型 华为正式发布原生鸿蒙系统 OpenJDK 新提案:将 JDK 大小减少约 25% Node.js 23 正式发布,不再支持 32 位 Windows 系统 Linux 大规模移除疑似俄开发者,开源药丸? QUIC 在高速网络下不够快 RustDesk 远程桌面 Web 客户端 V2 预览 前端开发框架 Svelte 5 发布,历史上最重要的版本 开源日报 | 北大实习生攻击字节AI训练集群;Bitwarden进一步脱离开源;新一代MoE架构;给手机装Linux;英伟达真正的护城河是什么?
{{o.name}}
{{m.name}}

猜你喜欢

转载自my.oschina.net/u/4026796/blog/15081234