为了更为明确地阐述事件管理流程，我们将分别从事件管理流程及紧急事件管理流程两个方面进行详尽阐述：
事件管理流程
事件管理流程文字说明：
| 序号 | 步骤名称 | 责任人 | 说明 |
| 104 | 一级事件处理模型 | 事件经理 | 一级事件即紧急事件必须由事件经理提出。 |
| 104.1 | 二次确认 | 应急小组 | 应急小组需要对一级事件再次确认。 |
| 104.2 | 参见一级事件流程 |
| 一级事件是运维过程中出现的极其特殊、重大的事件，因此有单独工作流程供参见。 |
| 100.1 | 事件记录-用户 | 用户 | 用户工作中遇见任何非业务系统类的IT故障或IT服务请求时，他们可以自行开单，工单将自动转派给一线（桌面支持小组）。 |
| 100.2 | 桌面支持尝试尝试解决 | 桌面支持小组 | 桌面支持二次判断事件类型，若确认事件属于桌面服务/服务请求，则着手解决或升级厂商；若不是上述服务类别则转派其他一线小组，具体参见一线互相转派子流程。 |
| 100.3 | 二线尝试解决 | 厂商 | 厂商通过线下方式接到一线升级的事件，着手解决并提供解决方案。 |
| 101.1 | 事件记录-IT | 基础架构小组 | 当故障或潜在故障涉及办公应用/IT管理平台/基础架构时，由基础架构小组开单，工单将自动转派给一线（基础架构支持小组）。 |
| 101.2 | 基础架构支持尝试解决 | 基础架构支持小组 | 基础架构支持小组尝试解决故障或潜在故障；若判断无法解决，则向二线厂商升级，并进入线下协调工作模式至问题解决。 |
| 101.3 | 二线尝试解决 | 厂商 | 厂商通过线下方式接到一线升级的事件，着手解决并提供解决方案。 |
| 102.1 | 事件记录-BA | BA支持小组 | 用户工作中遇见任何业务系统故障时，他们需要联系BA并告知故障现象，由BA开单，工单将自动转派给一线（BA支持小组）。 |
| 102.2 | BA尝试解决 | BA支持小组 | BA支持小组二次判断事件类型，若确认事件属于业务系统，则着手解决或升级厂商；若不是上述服务类别则转派其他一线小组，具体参见一线互相转派子流程。 |
| 102.3 | 二线尝试解决 | 厂商 | 厂商通过线下方式接到一线升级的事件，着手解决并提供解决方案。 |
| 103.1 | 事件记录-APP支持 | APP支持小组 | 当APP支持小组发现业务系统对应的中间件或数据库出现故障或潜在故障时，由APP支持小组开单，工单将自动转派给一线（APP支持小组）。 |
| 103.2 | APP支持尝试解决 | APP支持小组 | APP支持小组尝试解决故障或潜在故障；若判断无法解决，则向二线厂商升级，并进入线下协调工作模式至问题解决。 |
| 103.3 | 二线尝试解决 | 厂商 | 厂商通过线下方式接到一线升级的事件，着手解决并提供解决方案。 |
| 105 | 事件处理的监控 | 事件经理/开单人 | 事件经理可以全程关注事件流转过程，而事件每流转一次，则系统会发邮件告知开单人（事件上报人）。 |
| 106 | 记录解决方案细节 | 一线 | 无论由一线还是二线厂商提出最终的解决方案，均由一线完成记录并填入工单。 |
| 107 | 关闭事件 | 用户/BA/IT | 由开单人确认并关闭事件；若出现helpdesk替用户开单的状况，则helpdesk需要得到用户邮件确认方可关单。 |
一线互相转派子流程文字说明：
| 序号 | 步骤名称 | 子流程说明 | 执行原则 |
| 100.2 | 桌面支持尝试解决 | 桌面支持小组接受由用户开单的事件后，需要检查该事件的服务类别是否正确，若事件类别不合适，则需要修改服务类别并在一线内转派。 | 参见“服务类别、服务子类域、业务关键程度和对应一线映射表” |
| 101.2 | 基础架构支持尝试解决 | 基础架构支持小组可以分析事件，若是本组职能范围内的事件，则根据主流程尝试解决；若非职能范围内的事件，则需要修改服务类别并在一线内转派。 | 参见“服务类别、服务子类域、业务关键程度和对应一线映射表” |
| 102.2 | BA尝试解决 | BA小组在接到用户报告业务故障后判断故障非业务本身导致，但无法进一步判断是何原因导致，则可以转派给基础架构支持小组；若可以确定是哪个环节故障，则直接转派相应的一线。 | 参见“服务类别、服务子类域、业务关键程度和对应一线映射表” |
| 103.2 | APP支持尝试解决 | APP支持小组通常是接受一线内转派的事件工单；若由其自己开单则一般都确认事件属于其职能范围内，则直接解决。 | 参见“服务类别、服务子类域、业务关键程度和对应一线映射表” |
一级（紧急）事件管理流程
图示 一级（紧急）事件管理流程
制定一级（紧急）事件管理流程的目标：
◆当（一级）紧急事件发生时，尽可能采取措施减少对于业务带来的影响。
◆确保对紧急情况的有效管理：
加快一级（紧急）事件的响应和处理速度。
对紧急情况中的人员及采取的行动加强管理。
加强处理人员与用户之间的沟通和反馈。
对紧急情况妥善处理。
一级（紧急）事件处理的特殊性包括各系统应急处理预案的制定和使用，及时上报等。
应急处理预案是事先制定的针对某种特定故障的处理措施，可以确保系统发生重大故障时，能够尽快恢复业务，并充分调动技术力量，在最短时间内排除故障。预案中的内容至少应涵盖应急预案启动条件、应急处理小组负责人和成员联系名单和联系方式、应急处理步骤、应急信息通报、应急善后处理、应急保障措施（人员、培训、演习、场地）等。
由于一级（紧急）事件通常对企业造成非常严重的影响，从实际工作出发此时在进行电子化工单的流转不合适宜，因此当事件经理对一级（紧急）事件进行确认后，应急小组直接介入处理，待一级（紧急事件）解除后，由事件主要相关一线进行补单。
一级（紧急）事件管理流程文字说明：
| 序号 | 步骤名称 | 责任人 | 说明 |
| 104.1 | 召集应急小组,协调应急会议 | 事件经理 | 当事件经理确认一级（紧急）事件后，立即召集应急小组和上报CIO并召开应急会议；会议上，应急小组对一级（紧急）事件再次确认。 |
| 104.2 | 应急小组分析、制定处理方案并处理 | 应急小组 | 应急小组（包含CIO、事件经理、所有相关技术人员和厂商）确认一级（紧急）事件是否已有应急预案，若有则执行应急预案；若无适合应急预案，则制定处理方案再处理。 |
| 104.3 | 紧急事件解除确认？ | 应急小组 | 应急小组处理过事件后，由应急小组再次判断一级（紧急）事件是否解除；若未解除，则再次执行104.2流程节点；若解除，流程继续往下走。 |
| 104.4 | 善后处理和通报 | 应急小组 | 在解除一级（紧急）事件后，应急小组需要安抚受影响的用户并将事件原因和处理结果等信息上报CIO，再由事件主要相关一线事后补单。 |
| 104.5 | 关闭事件 | 应急小组 | 主要相关一线完成补单后，直接关单。 |
