学习ITIL也有一段时间了，ITIL绝对是个好东西，实施ITIL绝对为会部门的IT管理带来质的变化，唯一的遗憾之处就是ITIL只告诉我们做了会怎么样，却没有告诉我们应该如何去做，这对我们来说既是一种机遇，也是一种挑战，如果谁能基于ITIL提供一套完美的解决方案，那市场就是它的了，但对于一些小公司，或者IT部门只是附属支撑部门的制造企业来说，难度太大了，要完整的实施ITIL“势比登山”啊！
怎么办，是知难而退，还是另寻它路，曲线救国呢？我们当然要选择后者，这就好似拍一部电影，大投入大制作当然好，不过小投入未必就不能一鸣惊人，下面就我们部门在实施ITIL事件管理过程中的一点心得与大家共享。

我们公司是一家以制造为主的工厂，IT部门的主要业务是维护工厂生产的正常进行，以及生产管理系统，客观条件决定了我们不可能大手笔的投入ITIL实施，只能因地制宜，自己动手，建立自己的基于ITIL标准的应用。

让我们再次重温“事件管理”的精髓，即：尽快恢复正常的业务运作并将事件对业务运营的负面影响减少到最小，从而确保维持服务质量和可用性的最高水平。

ITIL中工作职责划分清晰，带来的是更为详细的角色划分。不过在我们的IT部门，人员少，职务多，只有暂时一个人身兼多个职务了。

对于服务台，我们也将其功能简化成事件管理的入口，它的工作主要包括：
接受客户报障，并记录
将不同的业务分类将故障派发到指定小组（在我们这里主要就是三个方面，办公网络相关，制造现场相关，生产管理系统相关）
对于已经处理完成的故障，及时反馈跟进

通过简单的培训，并不需要太多的专业技能即可以完成这部分工作，虽然简单但很重要，因为它是IT部门与其它业务部门的接口。

对于事件处理，ITIL中所描述的N线支持非常好，但在我们这里基本上就是一线支持，所以也就省略了事件N次转发的过程，省时，省力。

我们同样依据ITIL标准，设立了事件经理一职，基本上他的职责是判断事件的优先级别，对完成的事件进行审核等等。未经过审核的事件是不能直接反馈给用户的，因为这毕竟是一个部门对一个事件的处理的认可。

以往我们的事件处理完成就完成了，对于用户反馈这块都不是很重视，所以基于ITIL的标准，我们认为经过反馈流程的事件才可以关闭。至此一个事件才真正的结束。

有了第一手的资料，对于部门工作情况的掌握不再是无根无据了，对于职员工作情况的考核也有据可循，更为关键的是业务流程规范了，在人员出现异动的情况下，不再是手忙脚乱，而是应对自如了。

只有这样，才可能提升客户的满意度，才可以提高IT部门的服务等级。

本文出自 “itil学习笔记” 博客，请务必保留此出处http://97741.blog.51cto.com/87741/16028