监理公司管理系统 | 工程企业管理系统 | OA系统 | ERP系统 | 造价咨询管理系统 | 工程设计管理系统 | 甲方项目管理系统 | 签约案例 | 客户案例 | 在线试用
X 关闭
重庆OA行业资讯

当前位置:工程项目OA系统 > 泛普各地 > 重庆OA系统 > 重庆OA行业资讯

[原创]面壁ITIL之框架搭建

申请免费试用、咨询电话:400-8352-114

ewaysun

本文发表于《中国计算机用户》 2007年1月29日 第5期 管理栏        

  随着业务的发展,客户服务越来越得到集团领导的重视。原来隶属于信息系统公司的客户服务部被分离出来,单独成立为客户服务中心(见图1)。业务上将原商用电子公司的硬件维护和原客户服务部的软件维护进行整合。整合不仅保证了客户服务中心统一的对外报修受理接口,而且也提高了客户服务中心整体的IT运维能力。客户服务中心设服务总监一名,负责中心的ITIL建设,并于2006初开始实施。

 

图1-集团组织结构图

岁末年初,ITIL服务支持框架已搭建一年有余。记得当时我还满怀激情地写了一篇文章发表于公司的简报。虽然当时并不太了解ITIL,但我们知道这么做意味着客户服务中心的IT运维由游击形式进入到正规整编阶段。

1个管理职能(服务台),5个子流程(事件管理流程、问题管理流程、变更管理流程、发布管理流程和配置管理流程)是ITIL服务支持的经典框架。可以说,我对这个“框架”的真正理解是源于对服务总监提出的客户服务中心IT服务支持框架的深入了解。

先来介绍一下目前客户服务中心所采用的IT服务支持框架。见下图:

2-客户服务中心组织结构图

从图2可以看出,服务管理部的结构就是ITIL服务支持的框架。但是,这种框架的实际内容和ITIL中服务支持的框架存在不小的差异。

为了更好地明白部门具体的服务内容,我把上图再简化一下:

3-客户服务中心组织结构简化图

  在图3中,我们看到实施管理部在客户服务中心是属于服务支持与保障部门,其实也就是ITIL框架中服务支持流程的服务台和事件管理。实施管理部是IT服务的直接提供者;服务管理部,这个名称虽未在ITIL中提及,但在客户服务中心的组织结构中却有着ITIL服务支持框架的精髓。虽然在名称上,ITSM实践与ITLIL理论的差异仅在于对原来的平顶房来了个“平改坡”(即在不改变整栋楼的结构情况下,将原来的平顶改造为坡顶,解决多层平顶房屋隔热、防漏,以及城市景观道路旁建筑的第五立面等问题)。但框架还是那个框架,只是为了适应客户服务中心的管理需要,结合原有的IT运维模式“最佳实践化”了。

 我曾在很长的一段时间里不明白:为何我们实际搭建的ITIL框架有异于理论中的ITIL?服务管理部存在的意义何在?为何实施管理部的活动更象ITIL描述的事件管理?服务管理部的事件管理因何而存在?

翻书,但没有答案。因为ITIL只是框架。Google,但没有回答。因为前无来者。有一天应同事之邀去听一个ITIL的培训课程。说是培训课程,实为培训课程的推荐会。这种课程一般而言费用太高,虽有心参加,但无力报名。听着台上的人卖力地介绍这些培训课程,我在下面无聊地翻着他们的培训课程指南。CISA,国际信息系统注册审计师。当CISA这个单词再次映入眼帘时,我想到了一个理解客户服务中心ITIL框架的切入点。服务总监持有CISA的认证,那么他所设计的ITIL框架中是否也带有IT审计的痕迹呢? 

我决定先去了解IT审计的定义。最终我选择了电子工业出版社出版的《IT审计》中对IT审计的定义来理解。书中对IT审计的定义引用了日本通产省在1996年对IT审计准则进行全面修订后,对IT审计的重新定义:“为了信息系统的安全、可靠和有效,由独立于审计对象的IT审计师,以第三方的客观立场对以计算机为核心的信息系统进行综合的检查和评价,向IT审计对象的最高领导,提出问题与建议的一连串的活动。”

了解了这个定义之后,我发现将其稍微修改一下就完全可以用于对客户服务中心服务管理部的理解:为了IT服务支持和保障的及时、可靠和有效,由独立于服务支持部门的服务管理部,以第三方的客观立场对以IT服务支持为核心的实施管理部进行综合的检查和评价,向客户服务中心或实施管理部的最高领导,提出问题与建议的一连串的活动。

至此,我想也许是因为服务总监持有CISA证书,他在设计IT服务支持框架时体现了一个审计的思想:对服务支持与保障建立起独立、客观、公正的服务过程监督,以此保证服务输出质量的稳定和持续改进。 

通过这件事情,我恍然有所悟:为何把自己拘泥于框架呢? ITIL不是IT服务的全部,仅为ITIL而理解ITIL就会象我一样陷入无端的苦恼之中。遵守框架但不拘泥于框架,这是我理解客户服务中心现行ITIL服务支持框架的出发点。

ITIL的精髓是“流程”和“最佳实践”。流程由谁来设计,由谁来监督执行,由谁来考核质量,由谁来持续改进。如果我们仅去理解ITIL的框架理论,那么以上这些动作就无从查找。我们一再强调ITIL只是一个指导性框架,没有细则,没告诉你具体该如何如何去做。所以,流程的设计、监督、考核以及日后的持续改进还需要我们自己去发现。

下图是我对ITIL框架有深入领会后,对事件管理所做的再认识。在客户服务中心的实践中,事件管理不再是尽可能快地恢复业务,使事件对业务运营的影响减小到最少。因为这些工作已经由实施管理部去承担了。如图所示,事件管理要尽的责任是如何保证由实施管理部输出的服务是直线,符合客户满意这个判断服务好与坏的惟一标准。一旦出现向上或向下的曲线变化,事件管理应及时发现并作出反应。

另外,不论是服务支持部门,还是服务监督部门在提供IT服务过程中都不可避免地会遇到资源问题。年底遇到离职高峰,维护人手不够要向资源管理部门提交招聘需求;设备的备品备件不足,需要及时采购;维护车辆的申请等等。而这些都是ITIL无法在框架内告诉我们,但这些又是做好IT服务必不可少的。说到这里,我想是否可以对ITIL的核心做一个改动,将“资源”添加进去变为“人、流程、技术、资源”。  

当回顾这一年的ITIL服务支持框架搭建之路,我感悟最深的就是:领悟ITIL精髓,不拘泥于框架,不断实践,持续改进。因为在ITIL世界里没有统一的答案,只有适境而为的选择。 

发布:2007-03-25 10:20    编辑:泛普软件 · xiaona    [打印此页]    [关闭]