事件管理流程是IT服务管理流程中的一个核心流程，提升事件管理时效性、回归事件管理本身属性，可以提高IT服务的质量，有效改变目前我国企业普遍存在的重开发、轻运维的现象，真正践行以服务为导向的ITIL理念，通过切实有效的IT服务管理为企业创造价值。但是，据E客看到的情况，其实在这个流程中还是有很多地方有分歧的，先在这里描述几点。

1、事件管理中重大事件如何处理

在设计事件管理流程的时候，事件流程经理会觉得如果一些重大事件也要事件这个流程负责，压力太大，事件管理流程应该只是做日常的服务故障，承担不了重大中断事故的责任。

这有几种选择：

一种是将事件管理和连续性管理建立关联。普通事件和重大事件的来源和监控是一样的，在事件管理流程中如果遇到突发事件（或叫重大事件），应该转如突发事件应急预案处理。突发事件也应该做不同的分级，并做不同的处理。突发应急处置过程中，如果需要，可以进行灾难宣告，再转入灾难恢复流程。

第二种选择是专门做一个重大事件的处理流程和办法。这在有些企业也是有案例的。

2、事件管理和问题管理的关联

按照ITIL的理论，事件管理的目的应该是快速解决故障，恢复服务。问题管理应该是查找原因，并解决疑难杂症。

在实践中，关于事件和问题的接口有两种情况。

一种是在事件处理过程中，如果处理不了，可以转到问题管理流程中，由问题管理流程来解决。但是这样存在一个问题，如果事件管理流程解决不了，意味着二线（有的企业有3线）员工都解决不了。这时候转到问题管理流程中去，其实问题分析专家角色对应的其实还是这些人。这样就没有意义，而且还浪费效率。同时，如果是事件解决不了就可以转入问题管理流程，就会造成事件流程中的不尽心尽力（反正可以转让问题管理流程）。而且容易造成这两个流程的流程经理（如果不是同一个人）互相推诿。

另一种情况是在事件处理过程中不转问题流程，事件处理可以根本解决，也可以用临时措施解决，在事件关闭后，再来作为问题，以期得到根本解决。

3、事件管理和变更管理的关联

事件应该可以转入变更流程，这个应该没有什么疑问，关键事件转到变更流程后，什么时候转回事件流程。这个在不同的企业，是有不同的做法的。

一种做法是事件处理过程中，如果需要变更，可以转让变更流程，事件这时候设置为‘挂起’状态，等变更实施完成后，再转入事件流程，这时候才可以关闭。

另一种做法是事件处理过程中，如果需要变更，则转入变更流程，这时候和客户沟通后，告诉他转入变更流程，关闭事件。

第一种做法的好处是这是一个闭环的流程，故障没有处理完成，是不关闭的。坏处是有时候挂起时间很长，影响事件快速完成的目标。

第二种做法的好处是事件可以很快得到关闭，坏处是关闭的时候，可能事件还没有得到妥善解决。

以上就是E客为您带来的IT服务管理历程之事件管理流程，希望对您有所帮助！