论itsm软件不可或缺.doc

论ITSM软件不可或缺
随着ITSM理念在全世界的普及,应运而生的一个独立的软件市场也在形成,即ITSM软件工具提供。下面是笔者所知的国内外一些公司的ITSM软件(估计仍有不少漏项)
     
 
这些软件的性价比不同,适用的对象亦有所区别,从数万到数百万不等,目前ITSM软件市场规模尚且有限,同时带着初生的气息,即混乱而充满生机,相信在未来的几年,ITSM的成熟与应用规模的壮大,ITSM软件市场也会成长。为什么会这样呢,难道引入ITSM方法就必须得有一款相应的ITSM软件才行吗?这其中道理是什么呢?
以下将从几个方面来探讨在ITSM过程中,软件支持的不可或缺:
 
一、             ITSM的数据记录
    以ITIL理论为主导的服务管理过程中,每个流程都有大量的数据产生,尤其是配置管理中的配置信息,事件管理中的事件信息,还有诸如问题信息、变更信息、能力信息、服务级别信息等,这大量的记录彼此还存在关联,以纸质记录不现实,电子表格无法有集成关联,搜索查询同样是大问题,仅仅一个CMDB都快成为一个独立的软件产品了,还有大量的基础数据,比如客户信息与支持团队的信息,这些都是组织与人的数据,还有大量的分类基础数据。所以在服务过程中产生的大量数据,这些数据首先要解决记录的问题,然后是查询的问题,最后是分析统计的问题。
二、             ITSM的逻辑运算
在具体的服务过程中,为了保障服务级别的执行,需要在许多数据之间做关联与计算,比如当一个应用系统发生故障时,服务台需要将此故障记录下来并调度工程师解决,这时就产生一个问题,这个故障需要派给哪一个工程师解决(服务体制、忙闲状态),工程师需要多久完成故障排除?这里就需要有一个约束,为了保障服务级别得到真正的执行,需要设置这个故障的解决要求时间,同时还要考虑到服务时间的问题,即我们承诺客户的服务是5*8,还是7*24,甚至5*8中,这8小时,分别几点至几点,才是服务时间。只有这些数据参与逻辑运算,才能得到故障(事件)的处理时长,才能将时长与要求时间进行比较,以计算出按时解决率。仅仅一个事件,就需要日历数据、服务级别数据,与单据的创建时间与工程师的完成时间记录,进行综合运算,甚至在故障过程中,还需要考虑到分派的问题(从一个工程师转给另一个工程师处理),还需要考虑到等待时间,最后还要考虑事件的责任归属,这些都是保障服务质量管理的基本要求。
关联性的问题同样是需要做比较复杂的运算,比如这个事件与哪一个配置项有关系,这个事件导致了哪一些变更,或者导致哪一个问题的产生。做得比较好的ITSM软件,还会考虑事件升级,即在一个事件处理时,如果达过某一个限定条件(事件长时间没有人响应,事件超过要求解决时间仍没有得到解决,发生一个严重事件),系统会发出邮件与短信通知处理者与相关的领导。这还仅仅是从单一事件本身出来,就有非常复杂的逻辑关系。
三、             ITSM的流程执行
     无数的管理者最头痛的一件事就是制度或流程的执行问题,我们很多时候,花费很大的精力与资源去设计出一套制度流程,但真正实施时,在日后漫长的作业过程中,要么是制度流程被丢在一边,要么执行得变了样。这里面一方面的教育与素质的问题,还有就是我们没有找到一种有力的方法来监管制度流程的执行,为流程的执