ITIL流程体系之服务请求管理流程设计.docx

上传人:b****5 文档编号:7140701 上传时间:2023-01-21 格式:DOCX 页数:15 大小:57.40KB
下载 相关 举报
ITIL流程体系之服务请求管理流程设计.docx_第1页
第1页 / 共15页
ITIL流程体系之服务请求管理流程设计.docx_第2页
第2页 / 共15页
ITIL流程体系之服务请求管理流程设计.docx_第3页
第3页 / 共15页
ITIL流程体系之服务请求管理流程设计.docx_第4页
第4页 / 共15页
ITIL流程体系之服务请求管理流程设计.docx_第5页
第5页 / 共15页
点击查看更多>>
下载资源
资源描述

ITIL流程体系之服务请求管理流程设计.docx

《ITIL流程体系之服务请求管理流程设计.docx》由会员分享,可在线阅读,更多相关《ITIL流程体系之服务请求管理流程设计.docx(15页珍藏版)》请在冰豆网上搜索。

ITIL流程体系之服务请求管理流程设计.docx

ITIL流程体系之服务请求管理流程设计

密级分类:

 

**********

服务请求管理流程手册

文件编号:

版本:

1.0

 

 

2018-X-X颁布2018-X-X实施

文档修订记录

版本号

版本日期

修改人

审批人

修改章节

修改记录

 

 

1.概述

1.1.目标

规范服务请求管理流程的相关策略及活动,确保服务请求管理流程的执行质量和执行有效性。

1.2.范围

管理流程

适用范围

管理范围

对于所提供的服务在日常运维过程中出现事件的识别、记录、调查、解决和关闭的管理

2.术语、定义

序号

术语

定义

1

服务请求

用户对信息、建议、标准变更或服务访问的请求。

例如重置密码、为新用户提供标准的服务。

服务请求通常由服务台处理。

2

业务服务请求

来自业务部门对开通型业务的请求,主要由市场部接洽,市场部担任业务服务请求的服务台。

3

技术服务请求

来自技术维护中所涉及的请求,主要由客服接洽,客服担任技术服务请求的服务台。

4

知识管理

负责收集、分析、保存和共享组织内部的知识和信息的流程。

知识管理的主要目的是通过减少重新发现知识的需要,从而提高效率。

5

知识库

一个逻辑数据库,其中包含了服务知识管理系统使用的数据。

3.角色与职责

角色

职责描述

对应岗位

服务请求发起人

●发起服务请求流程

业务服务请求:

客户单位

技术服务请求:

服务请求经理

●服务请求流程监督,升级的处理和跟踪,对流程运行的有效性负责,不负责具体事务;

●负责服务请求的回顾分析以及评审关闭。

服务台

●与用户之间的主要接口;

●作为“首问负责人”,全程跟踪确保服务请求得到解决;

●负责服务请求的初步支持

●重分派服务请求;

●与用户确认服务请求已解决,可以关闭。

市场部(主要受理业务服务请求)客服(主要受理技术服务请求)

服务请求处理员

●处理服务请求,将处理结果反馈。

业务服务请求:

技术服务请求:

分管领导

●负责审批由处理员提交的请求审批单

4.输入

编号

输入项

来源

周期

1.

提交的服务请求

通过热线电话、邮件、微信、APP等方式,以及市场部的沟通平台

发生时

5.输出

编号

输出项

去向

周期

1.

服务请求记录

流程内部

发生时

2.

知识记录

知识管理流程

发生时

6.流程描述

6.1.管理定义

6.1.1.服务请求分类

一级分类

二级分类

业务服务请求

技术服务请求

6.1.2.服务请求状态

服务请求状态

描述

待受理(草案)

一个服务请求刚被记录或创建

已受理

服务请求已被服务台受理

已派单

一个服务请求已被分派给服务请求处理人

已受理

任何一个服务请求处理人接受了服务请求并开始受理服务请求

已升级

升级到服务请求经理

已解决

为一个服务请求找到解决方案或变通方法

已关闭

服务请求经客户确认已关闭

6.1.3.服务请求关闭

代码

描述

审批未通过

提交的请求审批未通过关闭

处理成功

处理成功

处理失败

处理失败

用户取消

用户请求取消直接关闭

6.1.4.通用服务请求单

通用服务请求单建议包含如下请求信息项:

信息项

说明

服务请求ID

服务请求单流水号(系统自动产生)

请求人信息

服务请求申报人的信息,包括:

姓名、所属单位、部门、电子邮件、办公电话、手机(初次录入手工填写,再次输入由系统自动填写)

创建人信息

服务请求单创建人的信息

登记时间

在服务台生成服务请求记录的时间(系统自动产生)

地点

服务请求发生的地点(手工填写)

服务请求分类

参见“服务请求分类”定义

服务请求标题

服务请求的简要描述(手工填写)

服务请求描述

对于整个服务请求内容的详细描述(手工填写)

服务请求受理人

服务请求的当前受理人(手工填写)

服务请求受理组

服务请求的当前受理组(手工填写)

服务请求状态

参见“服务请求状态”定义

服务请求日志

反映服务请求信息项的变化历史,如一个服务请求在处理过程中服务请求状态变化的时间点等信息(系统自动产生)

审批未通过代码

填写审批未通过代码

服务请求关闭代码

参见“服务请求关闭代码”定义

完成时间

记录服务请求已解决的时间(系统自动产生)

完成信息

服务请求完成信息

备注

填写服务请求备注信息(如审批批注)

附件

服务请求附件

6.2.管理策略

●服务台是所有报至服务台的服务请求的负责人,即服务台必须负责全程跟踪直至关闭;服务台在业务服务请求中主要由市场部担任,在技术服务请求中主要由客服担任。

●所有在流程范围内发生的服务请求,都应该被完整准确的记录下来,记录的信息应足够详细,包括请求处理交互过程,详细的解决方案和相关的附件等。

●服务请求的处理过程中必须加强各支持团队之间的沟通,沟通的方式优先使用工具(IT服务管理平台),并辅助以邮件、电话、短信、即时通信工具和当面交流等手段;

●每月产生服务请求管理报表,对超时未解决的服务请求,应该举行定期的服务请求管理会议对这些服务请求进行评估,以改进服务请求管理流程;

●每年对服务请求流程进行回顾,以改进服务请求管理流程,丰富服务请求目录。

回顾内容包括关键衡量指标、流程执行效率和流程支持工具的有效性等。

●采用首问负责制,用户上报的服务请求由首次受理并进行支持的服务台人员负责在系统中进行登记;该员工为该服务请求的责任人,须确保服务请求得到有效跟踪与解决,并负责服务请求单的关闭;服务请求被服务台人员转至服务请求处理人后,服务请求处理人成为该服务请求的当前责任人,但服务台人员仍然是该服务请求的整体负责人,有义务对服务请求处理状态进行跟踪和推动,并及时反馈给用户。

●服务请求再分派是指服务请求升级至某一支持组后,在同一支持组内或跨组进行重新分派。

退单须说明理由和转派建议,服务台可以通过与服务请求经理沟通咨询后再进行跨组分派;服务请求在同一组内允许互相转派,但必须说明转派理由,并将转派信息通知服务台(可通过运维工具共享给服务台);服务请求处理过程中的跨组转派允许工程师直接转派,但必须说明转派理由,并将转派信息通知服务台(可通过运维工具共享给服务台)。

6.3.服务请求管理流程

6.3.1.请求识别与记录

序号

步骤名称

责任人

说明

1.1

识别和验证用户基本信息

服务台

服务台人员接受来自用户上报的服务请求,用户可以通过电话、QQ、邮件、web页面和移动平台等方式报告服务请求;

服务台人员鉴别并记录服务请求;

服务台人员识别用户身份并验证用户信息。

1.2

用户信息是否正确?

服务台

服务台判断用户信息及其使用的业务系统信息是否正确;

若是,则进入1.4,确定服务请求类型;

若否,则进入1.3,更改用户及其使用的业务系统信息。

1.3

更改用户信息

服务台

服务台更改用户及其使用的业务系统信息,但仅限于用户基本信息,比如联系电话、邮箱、使用的系统或设备名称等。

1.4

确定服务请求类型

服务台

服务台根据服务请求类别表确认该服务请求类型,并根据不同服务请求类型识别服务请求处理路径。

1.5

确定优先级

服务台

服务台根据服务请求影响度和紧急度确定服务请求优先级;可根据服务请求类型设置默认优先级。

1.6

提交服务请求单

服务台

服务台在ITSM平台提交服务请求单,服务请求基本信息不可再编辑。

6.3.2.请求分派和审批

序号

步骤名称

责任人

说明

2.1

转派服务请求处理人员

服务台

服务台根据不同服务请求类型识别服务请求处理路径,并将服务请求转派至对应的服务请求处理人。

2.2

验证服务请求信息

服务请求处理人

服务请求处理人员查看服务请求信息,验证服务请求单信息是否完整。

2.3

是否属于业务范围内?

服务请求处理人

确认服务请求是否在自己部门的支持范围内;

若是,则进入2.5,确定处理方案(处理意见);

若否,则进入2.4,退回服务台,并说明退回理由和转派建议;

如果服务台提交的服务请求单信息不完整,服务请求处理人有权将服务请求单退回给服务台。

2.4

退回服务台

服务请求处理人

服务请求处理人将不在本部门支持范围内或信息不完整的服务请求退回服务台,并说明退回理由和转派建议。

2.5

确定处理方案(处理意见)

服务请求处理人

服务请求处理人根据服务请求的类别匹配预定义的服务请求处理方案;

也可将服务请求单与知识库进行匹配,寻找现有的解决方案或变通方案;

填写服务请求解决方案或处理意见。

2.6

是否需要领导审批?

服务请求处理人

服务请求处理人根据服务请求的处理方案判断是否需要领导审批;

若是,则进入2.7,选择审批服务请求的领导;

若否,则进入3.1,实施解决方案/变通方法。

2.7

选择审批领导

服务请求处理人

服务请求处理人根据服务请求处理方案选择审批服务请求的领导,并将服务请求单提交领导审批;

审批服务请求的领导可以有多个,单才有逐级审批的原则。

2.8

领导审批

分管领导

领导对服务请求进行审批,可通过移动平台审批;

审批意见可以是“同意”或“不同意”,如果不同意需说明原因。

2.9

是否审批通过?

分管领导

领导决定是否同意服务请求处理方案;

若是,则进入2.10,是否需要与客户确认金钱;

若否,则返回2.5,重新确定处理方案。

2.10

是否需要与客户确认金钱

服务请求处理人

服务请求处理人根据服务请求实施方案判断是否需要与客户进行金钱确认;

若是,则进入2.11,与客户进行金钱确认;

若否,则进入3.1,实施解决方案/变通方案。

2.11

与客户进行金钱确认

服务请求处理人

服务请求处理人与客户就实施请求方案所需的金钱进行确认,确认完成后,进入3.1。

6.3.3.请求处理

序号

步骤名称

责任人

说明

3.1

实施解决方案/变通方法

服务请求处理人

服务请求处理人执行服务请求解决方案或变通方法。

如该请求处理需要执行变更管理或者备件管理,走相应子流程。

3.2

提交实施过程

服务请求处理人

服务请求处理人在ITSM平台记录并提交服务请求解决方案或变通方法的执行过程。

3.3

是否创建知识?

服务请求处理人

服务请求处理人判断是否需要提交知识条目;

若是,则进入3.4,提交知识条目;

若否,则进入4.1,回访。

3.4

提交候选知识条目

服务请求处理人

服务请求处理人将服务请求作为典型案例创建知识条目,并递交至本部门知识库管理员。

6.3.4.请求关闭

序号

步骤名称

责任人

说明

4.1

回访

服务台

服务台人员收到已解决的服务请求,通过邮件、语音系统、QQ、电话确认等方式与用户进行确认;

服务台人员对服务请求的解决过程进行满意度调查。

4.2

是否创建知识?

服务台

服务台人员判断是否需要提交知识条目;

若是,则进入4.3,提交知识条目;

若否,则进入4.4,关闭服务请求。

4.3

提交知识条目

服务台

服务台人员将服务请求作为典型案例创建知识条目,并递交至知识库管理员。

4.4

关闭

服务台

如有必要,服务台人员更新服务请求信息,包括对分类、优先级进行确认和调整,补充服务请求处理信息;

服务台人员关闭服务请求单,并设置关闭代码。

7.关键绩效指标

绩效指标

目标值

衡量方式

负责人

服务请求总数

服务请求总数/周期(年,月,周,日)

服务请求关闭的数量/比率

服务请求服务请求数量/周期

数量/服务请求总数×100%

服务请求自动关闭的数量/比率

自动关闭服务请求数量/周期

数量/服务请求关闭数量×100%

服务请求成功关闭的数量/比率

成功解决服务请求并关闭数量/周期

数量/服务请求关闭数量×100%

平均响应时间

累计响应服务请求的时间/服务请求总数

平均处理时间

累加完成服务请求的时间/完成的服务请求数

用户满意度

服务请求记录中用户满意度分值总计/事件总数

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 高等教育 > 其它

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1