本帖最后由 FYIRH 于 2021-1-13 00:49 编辑
0 b% _3 z1 ^4 U3 x d6 V$ b+ K7 p# ?' g8 ^& ~
本文由长河、陈贺、傅盛原创,张翼、王岩校对。
+ A3 y( d! {, b! g
; S4 j a; a# M$ c9 |, b/ W: q. n9 b
在ISO/IEC20000-1:2011的标准条款8.1事件和服务请求管理中,有如下规定: - 对所有ITIL事件应有一套文件化的程序用于{定义} 记录;优先级分配;分类;记录更新;升级;解决;关闭。
8 f# y0 r; W4 ?2 C1 f1 b5 @ : Q! t1 r& G: z
- 应有一个文件化的程序用于管理服务请求从记录到关闭的完成。事件和服务请求应遵循这些程序进行管理。
- z; d* s, u @; y3 \6 Q
& t3 O; F" i! ]1 u( Z. j& K2 a- 在确定事件和服务请求优先级时,服务提供者应考虑事件和服务请求的影响和紧急程度。$ O+ F# v: `/ M1 L
$ B- V* w s% P( J
- 服务提供者应确保事件和服务请求管理流程相关的人员能够访问和使用相关信息。相关信息应包括服务请求管理程序、已知错误(Known Error)、问题解决方案和配置管理数据库(CMDB)。来自发布和部署管理流程的有关发布是否成功以及计划的发布日期等信息应用于事件和服务请求管理流程。
) h8 [' ?1 n/ F, {0 g 3 S8 P; e; u9 j4 c. |4 M
- 服务提供者应保持通知客户他们所报告的事件或服务请求的处理进展情况,如果服务的目标未达成,服务提供者应告知客户和利益相关方,并依照程序进行升级。
" K+ @' j/ k" l; Y
& \* K: [8 O$ k8 F* n" H- 服务提供者应文件化并与客户就重大事件的定义达成一致。重大事件应进行分类并依照程序进行管理。高管层应被告知重大事件。高管层应确保有指定的人员负责管理所分派的重大事件。在协商确定的服务被恢复后,应对重大事件进行回顾以识别改进的机会。”
& R+ j) O" l4 u9 L- W
# ]6 w6 b/ ~8 H, S
ISO20000标准并不是绝对的教条,实施或落地时需要体现有效性和适宜性。如果企业IT服务管理体系(本文中简称“体系”)成熟度较低,ISO20000可以对企业的服务管理起到领航的作用,让体系能相对安全地部署;当企业体系成熟度相对较高,ISO20000则起到保驾的作用,企业一边参照标准,一边进行落地,落地风险得到控制。当企业体系成熟度很高,标准也已成功落地,那么ISO20000体现的作用就是保底,随时警示企业体系的安全基线(底线)所在,不得越雷池半步。
; Z4 L0 ?' C, b5 _8 t1 d8 x. |
标准提出了事件和服务请求管理的最低要求,事件必须有文件化规范,完整的流程包括事件记录,事件优先级分配和分类,保持对记录更新,需要有事件升级、解决、关闭的规范。其中各阶段的要求在前述几个问答汇总均有涉及,不再叙述。此处仅补充两点: - 标准强调服务提供者要保持对利益相关者的信息开放,事件和服务请求管理流程相关的人员要能够访问和使用信息;而客户也应该被适时地告知;
5 e) g* T6 l z1 U) O1 z6 o1 \
1 K8 t0 p' ^' K* n) i* _! U- 重大事件也是事件的一类,应有指定的专人对其进行管理。任何重大事件都必须知会高层。同时我们往往会忽略可以通过服务台,适时做话务分流或主动对外进行宣传,一定程度减少用户的不满或者不安。在重大事件爆发后,不知就里的用户会不停致电服务台,若服务台无对应应急策略,未制定重大事件应急规范,则其呼损率必然大幅度飙升。另外,在重大事件关闭前,应该组织事件相关方进行复盘,以期从中找到工作提升的契机。
8 b! q& l2 P, N" F# M
) \; o! u/ i7 F9 G% @
5 s& u8 e5 z4 s! i4 V! [
ITIL先锋论坛原创文章,禁止任何形式的转载,侵权必究! |