20150721   淡然

续上


2      流程需求详细说明

本章节的主要内容及用途如下所示：

·           提供了流程的指导方针，供P16在设计流程及流程将来的日常运行中使用。

·           提供了流程的关系图，指出了在某保险公司的整个服务管理体系中，本流程与其他流程的关系，即：本流程有那些输入，同时也应该提供那些输出。                                           ITSS培训

·           提供了流程的执行框架，指出了本流程应该具有的一些主要活动，从而供P16进行细化、归纳。

·           提供了主要考核指标，指出了如何对本流程进行衡量，P16在实施时，应该对这些指标进行细化、并实现。

2.1      指导原则

本指导方针的定义是基于ITIL的最佳实践，并根据某保险公司的具体情况进行了调整，可以用来指导热线支持与突发事件流程的设计，同时为了在日常的运行过程中取得最佳的效果，也必须将这些指导方针与流程的每一项活动相结合。

下面列出某保险公司热线支持与突发事件流程的指导方针：

方针1:

只能够有一个统一的热线支持与突发事件处理流程，并且应该支持所有的用户。

最佳实践：

·           应该尽快的恢复服务。

·           热线支持与突发事件流程应该避免成为一个“事件转发”的平台，应该积极的解决事件，从而最快的响应用户的请求。

·           热线支持与突发事件流程最好能够有一个集成的IT系统的支持，从而提高效率。

·           不管采用那种热线支持的架构，分布式的还是集中式的，都必须采用相同的管理流程。

·           对于当地的支持人员，应该配合当地业务部门的时间安排。

·           对热线支持人员提供必要的培训。

启示或需求：

·           必须把已存在的系统进行集成。

·           必须确定热线支持与突发事件流程的拥有者。

·           应该有人员及经费的支持。

·           制定所有的代码体系，包括：紧急程度、影响度、优先级、处理状态、结束状态等。

·           应与服务级别管理一起，来制定服务目录。应用开发和测试流程、运维管理流程一起，制定相关的维护、支持手册。

方针2:

应该提供唯一的日常的支持接口，来响应所有用户的突发事件及服务请求。

最佳实践：

·           从最终用户的角度出发，只能够有唯一的窗口，从而方便他们提交突发事件或服务请求。

启示或需求：

·           需要足够的扩展能力来满足不断增长的支持要求。

·           最终用户在请求支持前，有可能需要拨打电话或使用相关的自助工具。

方针3:

服务请求及突发事件记录应保存在一个集中的数据库中。

最佳实践：

·           服务请求以及突发事件都必须保存，且应该赋予相应的优先级。

·           突发事件的解决方案应该被记录。

·           集中化的数据库存储便于生成相关的管理报表。

启示或需求：

·           需要设计、实现、管理一个集中化的数据库。

·           培训相应的操作人员如何访问该数据库。

·           需要制定一个服务请求及突发事件的存储结构。

方针4:

热线支持与突发事件管理流程应该给最终用户提供状态查询服务。

最佳实践：

·           最终用户需要知道事件现在的处理状态。

·           支持人员在制定解决方案时需要和用户进行沟通。

·           所有的服务请求及突发事件记录都被存储在了一个集中的数据库中。

启示或需求：                                              ITSS认证

·           事件的状态及优先级需要及时更新。

·           如何通知用户以及什么时候通知用户需要在流程制定时考虑。

·           事件的支持平台需要集成相关的工具，例如：Email、手机等，从而便于消息的发送。

·           需要给用户提供自助查询系统。

方针5:

在关闭服务请求及突发事件处理时，需要考虑：SLA是否满足、服务是否恢复、突发事件是否解决、服务请求是否完成等因素。

最佳实践：

·           当支持人员处理结束后，必须主动与用户联系，来确认“该服务请求或突发事件真正的被解决。”。

启示或需求：

·           在流程制定时，必须有“与用户确认”这一个动作。

·           在设计流程的状态时，必须将“事件解决”与“事件关闭”状态分开。

·           应该制定一个缺省的“事件结束流程”。

·           系统中必须明确记录SLA是否被满足的数据。

方针6:

应该定义相应流程，来确保重大事件能够被及时的解决。

最佳实践：

·           重大事件处理流程应该存在，且应该与业务需要一致。

·           流程执行过程中，每个动作应该有明确的负责人。

·           重大事件经理只负责对重大事件进行协调、处理。而突发事件经理需对所有事件负责。

启示或需求：

·           应该制定统一的重大事件判别条件，且该判别条件必须有可操作性。

·           在流程上应该保证重大事件被正确的识别。

·           应该有一个很好的工具、流程来监控整个重大事件的处理过程。

·           应该与SLA相结合。

方针7:

应该提供相关的报表。

最佳实践：

·           流程的执行质量必须靠报表来衡量。

·           报表中可以提供相应的管理信息。

·           报表数据的定义及收集工作，必须有明确的定义。

启示或需求：

·           应该确定流程的衡量指标。                 ITSS培训

·           报表数据的收集及报表的生成，应该有明确的人员来负责，并且应该有明确的时间表。

·           工具必须能够自动生成相应的报表。

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

本帖关键字：ITSS

20150721   淡然

续上


2      流程需求详细说明

本章节的主要内容及用途如下所示：

·           提供了流程的指导方针，供P16在设计流程及流程将来的日常运行中使用。

·           提供了流程的关系图，指出了在某保险公司的整个服务管理体系中，本流程与其他流程的关系，即：本流程有那些输入，同时也应该提供那些输出。                                           ITSS培训

·           提供了流程的执行框架，指出了本流程应该具有的一些主要活动，从而供P16进行细化、归纳。

·           提供了主要考核指标，指出了如何对本流程进行衡量，P16在实施时，应该对这些指标进行细化、并实现。

2.1      指导原则

本指导方针的定义是基于ITIL的最佳实践，并根据某保险公司的具体情况进行了调整，可以用来指导热线支持与突发事件流程的设计，同时为了在日常的运行过程中取得最佳的效果，也必须将这些指导方针与流程的每一项活动相结合。

下面列出某保险公司热线支持与突发事件流程的指导方针：

方针1:

只能够有一个统一的热线支持与突发事件处理流程，并且应该支持所有的用户。

最佳实践：

·           应该尽快的恢复服务。

·           热线支持与突发事件流程应该避免成为一个“事件转发”的平台，应该积极的解决事件，从而最快的响应用户的请求。

·           热线支持与突发事件流程最好能够有一个集成的IT系统的支持，从而提高效率。

·           不管采用那种热线支持的架构，分布式的还是集中式的，都必须采用相同的管理流程。

·           对于当地的支持人员，应该配合当地业务部门的时间安排。

·           对热线支持人员提供必要的培训。

启示或需求：

·           必须把已存在的系统进行集成。

·           必须确定热线支持与突发事件流程的拥有者。

·           应该有人员及经费的支持。

·           制定所有的代码体系，包括：紧急程度、影响度、优先级、处理状态、结束状态等。

·           应与服务级别管理一起，来制定服务目录。应用开发和测试流程、运维管理流程一起，制定相关的维护、支持手册。

方针2:

应该提供唯一的日常的支持接口，来响应所有用户的突发事件及服务请求。

最佳实践：

·           从最终用户的角度出发，只能够有唯一的窗口，从而方便他们提交突发事件或服务请求。

启示或需求：

·           需要足够的扩展能力来满足不断增长的支持要求。

·           最终用户在请求支持前，有可能需要拨打电话或使用相关的自助工具。

方针3:

服务请求及突发事件记录应保存在一个集中的数据库中。

最佳实践：

·           服务请求以及突发事件都必须保存，且应该赋予相应的优先级。

·           突发事件的解决方案应该被记录。

·           集中化的数据库存储便于生成相关的管理报表。

启示或需求：

·           需要设计、实现、管理一个集中化的数据库。

·           培训相应的操作人员如何访问该数据库。

·           需要制定一个服务请求及突发事件的存储结构。

方针4:

热线支持与突发事件管理流程应该给最终用户提供状态查询服务。

最佳实践：

·           最终用户需要知道事件现在的处理状态。

·           支持人员在制定解决方案时需要和用户进行沟通。

·           所有的服务请求及突发事件记录都被存储在了一个集中的数据库中。

启示或需求：                                              ITSS认证

·           事件的状态及优先级需要及时更新。

·           如何通知用户以及什么时候通知用户需要在流程制定时考虑。

·           事件的支持平台需要集成相关的工具，例如：Email、手机等，从而便于消息的发送。

·           需要给用户提供自助查询系统。

方针5:

在关闭服务请求及突发事件处理时，需要考虑：SLA是否满足、服务是否恢复、突发事件是否解决、服务请求是否完成等因素。

最佳实践：

·           当支持人员处理结束后，必须主动与用户联系，来确认“该服务请求或突发事件真正的被解决。”。

启示或需求：

·           在流程制定时，必须有“与用户确认”这一个动作。

·           在设计流程的状态时，必须将“事件解决”与“事件关闭”状态分开。

·           应该制定一个缺省的“事件结束流程”。

·           系统中必须明确记录SLA是否被满足的数据。

方针6:

应该定义相应流程，来确保重大事件能够被及时的解决。

最佳实践：

·           重大事件处理流程应该存在，且应该与业务需要一致。

·           流程执行过程中，每个动作应该有明确的负责人。

·           重大事件经理只负责对重大事件进行协调、处理。而突发事件经理需对所有事件负责。

启示或需求：

·           应该制定统一的重大事件判别条件，且该判别条件必须有可操作性。

·           在流程上应该保证重大事件被正确的识别。

·           应该有一个很好的工具、流程来监控整个重大事件的处理过程。

·           应该与SLA相结合。

方针7:

应该提供相关的报表。

最佳实践：

·           流程的执行质量必须靠报表来衡量。

·           报表中可以提供相应的管理信息。

·           报表数据的定义及收集工作，必须有明确的定义。

启示或需求：

·           应该确定流程的衡量指标。                 ITSS培训

·           报表数据的收集及报表的生成，应该有明确的人员来负责，并且应该有明确的时间表。

·           工具必须能够自动生成相应的报表。

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

本帖关键字：ITSS