|
20150730淡然 续上
4.事件管理流程设计4.1流程执行原则4.1.1.流程常规原则q所有某公司B2B内部及集团子公司用户申告至某公司B2B座席的事件，连同主动监控发现事件，都应该被完整准确的记录下来，记录的信息应足够详细，包括事件处理交互过程，详细的解决方案和相关的附件等。ITSS考试 q某公司B2B服务支持体系是由一线和二线共同组成的，事件的处理过程中必须加强一线和二线的沟通，沟通的方式优先使用工具（服务管理平台），在需要的时候必须辅助电话、短信、邮件等手段。 q事件处理过程中，在需要寻求第三方的情况下，遵循下述原则： -根据事件实际处理情况，各自由一线和二线支持寻找相应供应商 -在供应商参与解决事件的过程中，事件当前处理责任仍保留在一线人员或二线人员处 q所有支持人员优先处理优先级较高的事件。 q定期产生事件管理报表，分析服务质量，对重大事件、重复发生的事件或者利用变通方法解决的事件，应提交问题管理流程进行问题定义分析和解决，并定期对这些事件进行评估跟踪。 q建议每半年对流程进行回顾，包括流程执行效率和流程支持工具的有效性，以改进和优化事件管理流程；上线之后一年中，可每季度对流程进行回顾。
4.1.2.责任制原则责任制原则用来确保每个事件在任何时段都有适当的人员负责。 q由监控系统上报或用户通过内网上报的事件，系统应提供相关机制（最少单量优先或轮询）自动分派给相应服务台人员，被指派的服务台人员是该事件的责任人，该人员有责任确保事件得到有效跟踪与解决，并负责事件单的关闭 q由用户电话上报的事件，首次接听电话并进行支持的服务台人员负责在系统中进行登记，并由该员工成为该事件的责任人，确保事件得到有效跟踪与解决，并负责事件单的关闭 q服务台员工换班时，由服务台值班主管负责对事件重新分派过程进行监控和统一协调；交接班后，事件责任人也由此转移 q事件被服务台人员转至二线人员后，二线人员成为该事件的当前责任人，但服务台人员仍然是事件的整体负责人，有义务对事件处理状态进行跟踪和推动，并及时反馈给用户。具体跟踪机制参见下表3-1。 q事件如需第三方处理，相应服务台人员或二线人员是事件的当前负责人，有义务定期向第三方查询当前事件的处理进展，并及时在系统中更新事件处理过程信息。 表4‑1服务台事件跟踪机制 优先级
| 责任人员
| 跟踪对象
| 跟踪周期
| 跟踪方式
| 跟踪内容
| P1
| 服务台
| 二线支持人员
| 10分钟
| 电话查询 系统查询
| 当前处理人员 当前处理进展 预计完成时间
| P2
| 服务台
| 二线支持人员
| 15分钟
| 电话查询 系统查询
| 当前处理人员 当前处理进展 预计完成时间
| P3
| 服务台
| 二线支持人员
| 30分钟
| 系统查询
| 当前处理人员 当前处理进展 预计完成时间
| P4
| 服务台
| 二线支持人员
| 1小时
| 系统查询
| 当前处理人员 当前处理进展 预计完成时间
|
4.1.3.事件分派原则事件分派原则是确保事件在服务目标时段内处理和解决的重要因素。 q事件分派可参考事件分类及被分派人员的忙闲程度 q事件分派应尽量指定到具体支持人员，如无法确认则分派给相应团队主管 q服务台一线支持人员在规定的一线处理时限内，可按情况选择转给其他在值服务台一线支持人员进行处理 q服务台一线支持人员在规定的一线处理时限内不能解决事件时，原则上根据事件分类分派到相应二线支持人员。 q支持人员如判断事件需要第三方支持，原则上不在系统中进行事件单的分派，事件单仍保持在相应的一线或二线支持人员处。第三方处理完毕后，由相应一线或二线支持人员负责更新事件单状态、解决方案等相关信息。 q服务台一线支持人员转二线支持的处理时限定义如下： 表4‑2一线转出时间点 [p=16,null,left]事件优先级
| [p=16,null,left]一线派二线/第三方时间点
| [p=16,null,left]P1（最高）
| [p=16,null,left]5分钟
| [p=16,null,left]P2（高）
| [p=16,null,left]10分钟
| [p=16,null,left]P3（中）
| [p=16,null,left]30分钟
| [p=16,null,left]P4（低）
| [p=16,null,left]1小时
|
4.1.4.事件重分派原则q二线支持接受服务台分派事件后，如果该事件不属于本人支持范围，二线人员需填写原因和分派建议，然后将事件返回到服务台，由服务台重新分配。 q二线支持接受服务台分派事件后，如属于其所在团队支持范围，但由于个人原因无法受理时，可在团队内部协调其他支持工程师资源，并直接转派事件单。 q为提高事件解决效率，应当尽量减少事件单重分派。原则上建议事件单的重分派次数不应该超过3次。[注：二线转回服务台不算转派次数]
4.1.5.重复/复发事件原则重复事件是指在一个较短时间段（通常30分钟至1小时），针对同一应用或设备，故障症状相同的事件。当被报告的事件与某个已经创建且尚未解决的事件单相同，则该事件被认为是重复的。由于此时已创建的事件尚未解决，还没有采取修正措施来恢复服务，因此，应创建新的事件单，复制原有事件单内容，并标识为原有事件单对应的“重复”的事件。在原有事件单解决时，所有的重复事件单也同时获得解决。 如果被监控系统或者用户上报的事件与一个已经关闭的事件症状相同，该事件被认为是“复发”事件。这意味着为了解决原有事件而采取的解决方案是失败的。此时，应创建一个新的事件单，复制原有事件单内容，并标识这是“复发”的事件。
4.1.6.事件关闭原则q所有事件单的关闭必须由服务台一线人员完成。二线支持人员确定解决方案并解决事件后，必须把事件返回到服务台。 q服务台人员关闭事件前，需获得客户对解决方案的确认和反馈。ITSS认证 q关闭事件时，根据实际解决情况填写事件的结束代码。 q已关闭的事件单不允许重开。如果事件再次发生，则创建一个新的事件单，并标识为复发事件。 q对于以“变通方法解决”、“不能重现”或“不成功解决”的结束代码关闭的事件，需通知问题经理对此类事件进行分析并在必要时生成问题，通过问题流程对问题进行根源分析并提供解决方案。 q所有优先级为最高的事件在关闭后，需通知问题经理对此类事件进行分析并在必要时生成问题，通过问题流程对问题进行根源分析并提供解决方案。 q对于未及时取得用户反馈的已解决事件，系统将对其保留3日。3日内服务台人员应至少每天主动与用户联系1次。若3日后仍未得到用户有效反馈，系统将自动关闭事件，并标识结束代码为“自动关闭”字样。
4.1.7.事件挂起原则设置事件挂起原则的目的在于指导服务台人员选择正确时机执行“挂起”操作，以帮助准确统计“事件解决时间”等与SLA相关的服务指标。具体规则如下： q如在处理故障过程中，由于用户方资源配合问题（如需用户提供详细信息或需用户进行解决结果确认等）导致时延，则应将事件状态设置为“挂起”，当用户方资源到位后进行解挂。 q事后统计时应将“挂起”时长从整体解决时间中扣除。
4.1.8.事件升级原则制定升级原则的目的是确保事件在规定的解决时限内能够及时通知相关技术人员和管理人员，引起足够的重视，协助提供合适的资源，从而快速找到解决事件的方案。 q优先级为最高的事件，需要立即事件升级至事件流程经理及事件流程负责人，同时，事件继续按事件管理流程进行快速处理 q超出规定的响应、分派或者解决时限之后，需要立即升级事件，同时，事件继续按流程进行快速处理。升级机制如下表所示，具体升级触发时间点参见“事件时限”相关定义： 表4‑3事件超时升级机制 事件优先级
| 当前处理人/事件责任人
| 事件经理
| 事件流程负责人
| P1
| 超时响应 超时分派 超时解决
| 超时分派 超时解决
| 超时解决
| P2
| 超时响应 超时分派 超时解决
| 超时分派 超时解决
| 超时解决
| P3
| 超时分派 超时解决
| 超时解决
| N/A
| P4
| 超时分派 超时解决
| N/A
| N/A
|
4.1.9.流程关联原则q和问题管理的关联 -一线支持在解决事件的过程中，可以通过问题记录查找相应的解决方案 -通过分析事件记录，形成问题，并使该问题与相关事件建立关联 -对重大事件或者“变通方法解决”、“无法重现”、“不成功解决”等结束代码而关闭的事件，由问题管理流程生成问题进行进一步分析，直到确定根本原因，得到根本解决。事件单和问题应建立关联。 q和变更发布管理的关联 -事件处理过程中，如果需要对相关基础架构进行变更，必须按照变更管理的定义，提交变更请求（变更单必须和事件单建立关联），变更完成后，继续事件的处理。 -重大事件的处理过程中，如果需要对相关基础架构进行变更，必须按照变更管理的定义，提出紧急变更请求，变更完成后，可补录紧急变更单，并和重大事件单建立关联。 q和配置管理的关联 -事件处理过程中，可以通过配置管理查询相关的配置项信息（尤其是关系信息）以及该配置项历史上发生的事件、问题或变更，来帮助故障的定位 -事件处理过程中，如果可以将故障定位到某个配置项，则必须将事件单与该配置项关联 q和服务级别管理的关联 -事件处理过程中，依照用户签订的SLA及相应服务级别对事件进行诊断和恢复。 -事件记录为服务级别管理中各项服务是否违背SLA中相关定义提供数据支持。ITSS培训 q和知识管理的关联 -事件管理流程中，服务台及二线人员利用知识库帮助诊断和分析事件，并参考知识库中相关信息生成解决方案或变通方法。 -事件管理流程中部分事件信息也可被提交给知识库成为知识记录，成为知识库的重要输入之一。
本帖关键字：ITSS | 
转播
分享
淘帖
()