20151106   淡然

续上

6.6.   事件管理流程详细设计

事件管理流程详细设计是在概要流程设计的基础上，逐个环节细化，同时结合事件流程代码，把整个事件流程具体处理过程详细描述。

6.6.1.     （SO2.1）突发事件记录

突发事件记录流程环节SO2.1的细化流程如下图所示：

描述如下：

[td]

序号	步骤名称	责任人	流程描述
SO2.1.1	升级交互为突发事件	服务台人员	用户交互无法在第一次联系即得以解决，将升级到突发事件管理流程。交互将会与新创建的突发事件自动关联。服务台人员根据交互创建突发事件。
SO2.1.2	是否分类为投诉？	服务台人员	此突发事件是否分类为服务台人员无法解决的投诉？如果是，请转至 SO2.1.5。如果不是，请转至 SO2.1.3。                      ITSS考试
SO2.1.3	将突发事件分配给组/人	服务台人员	突发事件会根据分类和受影响的服务分配到相应的支持组或人。CIM部门的突发事件同时要求电话确认分配人。
SO2.1.4	为用户提供交互编号	服务台人员	服务台人员为用户提供交互编号。用户需将此交互编号保存下来，以用作此突发事件的参考。
SO2.1.5	将投诉突发事件分配给服务台组	服务台人员	最初会将分类为投诉的突发事件分配给服务台组。
SO2.1.6	为用户提供交互编号和服务级别协议目标	服务台人员	服务台人员为用户提供交互编号。用户需将此交互编号保存下来，以用作此突发事件的参考。另外，服务台人员还将根据 SLA 提供目标解决日期。
SO2.1.7	将突发事件分配给服务台经理	服务台人员	突发事件保存后，将其分配给服务台经理（请参见 SO2.9 投诉管理）。
SO2.1.8	审核突发事件信息	服务台人员	突发事件可能会由于分配错误或信息不完整被分配组拒绝。在这种情况下，服务台人员需要审核记录的注释并更正信息或分配。
SO2.1.9	信息是否完整？	服务台人员	如果不是，请转至 SO2.1.10。如果是，请转至 SO2.1.3。
SO2.1.10	收集所需信息	服务台人员	收集丢失的必需信息，并使用这些信息更新突发事件。如果有必要，请与用户联系。
SO2.1.11	创建新的突发事件	服务台人员	从监控系统发现突发事件，根据实际情况，服务台手动登记突发事件记录或由监控系统集成自动打开突发事件记录。
SO2.1.12	选择合适的突发事件模板	服务台人员	服务台人员从列表中选择突发事件模板
SO2.1.13	按照模板说明操作	服务台人员	服务台人员将根据突发事件模板中的说明记录突发事件详细信息。
SO2.1.14	提供描述/配置项	服务台人员	为突发事件提供适当的描述。这可以是基于事件文本得出的。如果可能，应选择受影响的配置项。
SO2.1.15	选择类别和优先级	服务台人员	通过选择适用的影响级别和紧急程度选择适当的类别和优先级。
SO2.1.16	将突发事件分配给组	服务台人员	突发事件会根据分类和相关受影响的服务自动分配到相应的支持组。

注意：

l   事件创建的时候，将会遇到重复事件的问题。

重复事件一般可分为三类：一，同一个用户在处理时限内提交的重复事件；二，不同用户反映的同一个问题，并且第一个用户反映的问题还在处理时限范围内；三，超过处理时限，同一用户提交的重复事件。                                 ITSS认证

一般来说，用户告知的事件都是要新建记录的，但对于不同具体情况，可选择不同的处理方式：

对于第一类，不用建立新的事件，但如果用户描述的现象与之前记录的内容不一致，还是新建；

对于第二类，如果能够确信几个用户描述确实是一个问题，可不新建，将之于现有交互或突发事件关联；

对于第三类，可不新建，此类情况应该可以避免发生，之前处理过程中，应该与用户主动沟通。

总的来说，建议服务台除非能够明确判断事件的重复性，否则还是新建事件。

如果是真正的重复，可以通过统计，分析出用户的实际忍受时限，便于优化处理时限；如果不是真正的重复，可避免故障的遗漏。

l   设置分配组和分配用户的原则

如果服务台人员不能解决， 则转给相应突发事件分析员（二线）进行处理；

l

  事件通知

通过服务管理平台派发事件的方式，能够很好的记录日常处理的事件，但同时也会面临响应延迟的问题。响应延迟的问题主要体现在事件分配后，被分配人员因为某种原因，不能及时登录服务管理平台查询需要自己处理的事件，导致延迟处理事件。

响应延迟可能存在多种原因，如：正在处理一个事件；正在开会，不具备条件，不能够马上登陆服务管理平台察看并处理；正在休假；不能察看邮件等等。随着事件管理流程的执行，可能还会有其它的原因。但都不是流程能够解决的问题，需要制定管理制度，并有效执行才能解决。

当前为避免该问题发生的建议如下：

–   当前每次事件的分派前电话通知被分派人员，同时通过服务管理平台邮件；

–   如果被分派人员未联系上，直接联系突发事件协调员，由突发事件协调员协调处理；

–   及时更新各个系统具体负责的运维人员相关信息，并通知服务台人员。                     ITSS培训

后续随着事件管理流程的运转，通过服务台把各种情况记录下来，定期统计分析，发现响应延迟的根本原因，再进一步完善弥补响应延迟的措施。如果是管理制度不完善，如：休假制度、出差制度，则完善相应的制度；如果是资源配置不合理，如：工作量大但只有一个人负责，则合理增配运维人员。后续各个流程在分派响应问题上可参考此处描述，不再复述。

待续http://www.ITILxf.com/thread-52982-1-1.html

本帖关键字：ITSS

展开全部

微信扫一扫，阅读更方便^_^

20151106   淡然

续上

6.6.   事件管理流程详细设计

事件管理流程详细设计是在概要流程设计的基础上，逐个环节细化，同时结合事件流程代码，把整个事件流程具体处理过程详细描述。

6.6.1.     （SO2.1）突发事件记录

突发事件记录流程环节SO2.1的细化流程如下图所示：

描述如下：

[td]

序号	步骤名称	责任人	流程描述
SO2.1.1	升级交互为突发事件	服务台人员	用户交互无法在第一次联系即得以解决，将升级到突发事件管理流程。交互将会与新创建的突发事件自动关联。服务台人员根据交互创建突发事件。
SO2.1.2	是否分类为投诉？	服务台人员	此突发事件是否分类为服务台人员无法解决的投诉？如果是，请转至 SO2.1.5。如果不是，请转至 SO2.1.3。                      ITSS考试
SO2.1.3	将突发事件分配给组/人	服务台人员	突发事件会根据分类和受影响的服务分配到相应的支持组或人。CIM部门的突发事件同时要求电话确认分配人。
SO2.1.4	为用户提供交互编号	服务台人员	服务台人员为用户提供交互编号。用户需将此交互编号保存下来，以用作此突发事件的参考。
SO2.1.5	将投诉突发事件分配给服务台组	服务台人员	最初会将分类为投诉的突发事件分配给服务台组。
SO2.1.6	为用户提供交互编号和服务级别协议目标	服务台人员	服务台人员为用户提供交互编号。用户需将此交互编号保存下来，以用作此突发事件的参考。另外，服务台人员还将根据 SLA 提供目标解决日期。
SO2.1.7	将突发事件分配给服务台经理	服务台人员	突发事件保存后，将其分配给服务台经理（请参见 SO2.9 投诉管理）。
SO2.1.8	审核突发事件信息	服务台人员	突发事件可能会由于分配错误或信息不完整被分配组拒绝。在这种情况下，服务台人员需要审核记录的注释并更正信息或分配。
SO2.1.9	信息是否完整？	服务台人员	如果不是，请转至 SO2.1.10。如果是，请转至 SO2.1.3。
SO2.1.10	收集所需信息	服务台人员	收集丢失的必需信息，并使用这些信息更新突发事件。如果有必要，请与用户联系。
SO2.1.11	创建新的突发事件	服务台人员	从监控系统发现突发事件，根据实际情况，服务台手动登记突发事件记录或由监控系统集成自动打开突发事件记录。
SO2.1.12	选择合适的突发事件模板	服务台人员	服务台人员从列表中选择突发事件模板
SO2.1.13	按照模板说明操作	服务台人员	服务台人员将根据突发事件模板中的说明记录突发事件详细信息。
SO2.1.14	提供描述/配置项	服务台人员	为突发事件提供适当的描述。这可以是基于事件文本得出的。如果可能，应选择受影响的配置项。
SO2.1.15	选择类别和优先级	服务台人员	通过选择适用的影响级别和紧急程度选择适当的类别和优先级。
SO2.1.16	将突发事件分配给组	服务台人员	突发事件会根据分类和相关受影响的服务自动分配到相应的支持组。

注意：

l   事件创建的时候，将会遇到重复事件的问题。

重复事件一般可分为三类：一，同一个用户在处理时限内提交的重复事件；二，不同用户反映的同一个问题，并且第一个用户反映的问题还在处理时限范围内；三，超过处理时限，同一用户提交的重复事件。                                 ITSS认证

一般来说，用户告知的事件都是要新建记录的，但对于不同具体情况，可选择不同的处理方式：

对于第一类，不用建立新的事件，但如果用户描述的现象与之前记录的内容不一致，还是新建；

对于第二类，如果能够确信几个用户描述确实是一个问题，可不新建，将之于现有交互或突发事件关联；

对于第三类，可不新建，此类情况应该可以避免发生，之前处理过程中，应该与用户主动沟通。

总的来说，建议服务台除非能够明确判断事件的重复性，否则还是新建事件。

如果是真正的重复，可以通过统计，分析出用户的实际忍受时限，便于优化处理时限；如果不是真正的重复，可避免故障的遗漏。

l   设置分配组和分配用户的原则

如果服务台人员不能解决， 则转给相应突发事件分析员（二线）进行处理；

l

  事件通知

通过服务管理平台派发事件的方式，能够很好的记录日常处理的事件，但同时也会面临响应延迟的问题。响应延迟的问题主要体现在事件分配后，被分配人员因为某种原因，不能及时登录服务管理平台查询需要自己处理的事件，导致延迟处理事件。

响应延迟可能存在多种原因，如：正在处理一个事件；正在开会，不具备条件，不能够马上登陆服务管理平台察看并处理；正在休假；不能察看邮件等等。随着事件管理流程的执行，可能还会有其它的原因。但都不是流程能够解决的问题，需要制定管理制度，并有效执行才能解决。

当前为避免该问题发生的建议如下：

–   当前每次事件的分派前电话通知被分派人员，同时通过服务管理平台邮件；

–   如果被分派人员未联系上，直接联系突发事件协调员，由突发事件协调员协调处理；

–   及时更新各个系统具体负责的运维人员相关信息，并通知服务台人员。                     ITSS培训

后续随着事件管理流程的运转，通过服务台把各种情况记录下来，定期统计分析，发现响应延迟的根本原因，再进一步完善弥补响应延迟的措施。如果是管理制度不完善，如：休假制度、出差制度，则完善相应的制度；如果是资源配置不合理，如：工作量大但只有一个人负责，则合理增配运维人员。后续各个流程在分派响应问题上可参考此处描述，不再复述。

待续http://www.ITILxf.com/thread-52982-1-1.html

本帖关键字：ITSS

展开全部

微信扫一扫，阅读更方便^_^