松岛枫 发表于 2010-9-25 01:45:00

ITIL流程管理实施贴身感悟

学习资料:IT运维管理社区专家讲堂直播300期视频回放

体悟之四:妥协的流程管理——“捡芝麻丢西瓜”


  在这个实际的案例中:组织为了节约人力,可能主观上是为了推动工作开展,让原来熟悉业务,原负责的人推动变更流程,结果变更经理直接由原来的组织负责担任,配置经理和问题经理直接受变更经理领导。

  变更经理实际就是原组织的领导,以前需要关注资源协调,客户沟通,还有问题的处理,还关注事件的响应,还负责所有数据中心管理。但往往对变更关注不够,批复不及时,跟踪不够,难以评估、审查完成情况。在这种情况下,配置管理根本不能制衡更变管理流程,经常性滞后。

  问题管理流程也糟糕,按说问题管理最容易做好。实际上,该案例中快速响应以前就是具体系统管理员(系统管理员、网络管理员、邮件管理员等),刚建立的专家组实际是原来的几个方面技术相对较好的主管。这些主管原来的工作继续保留。因问题分析需要经过长期的分析跟踪,研究过往历史记录,长时间的分析不可能,而这些新的问题专家各管一方,日常事务杂且多。过往记录、厂商资源、运维经验、系统的基本状况基本上都掌握在原来快速响应工程师手中,没有形成共享资源,这些人对系统最了解,但仅限于他们自己的大脑中。相反问题专家要是研究的话,反而延误时间,协调不力。何况还没有时间做这个事情。因此问题管理始终还是以快速响应工程师为主在做,那么效果不可能好,自然大打折扣。另外,问题管理流程刚出来的时候,大家一下子就觉得——好啊,把以前的历史问题,新发生的不加严格筛选的问题,一股脑全部推给问题流程,问题管理流程根本就没有力量来处理这么多问题,结果也是不了了之。





不了了之的根本原因是没有人关注问题经理的考核。变更流程不要求问题流程,事件流程不升级到问题流程。所以问题流程在“众人合谋”中“瘫痪”。


  配置管理在系统宣导的时候,客户发现这太好了。可以把涉及系统的所有的参数都管理起来。但实际发现,CMDB付出的时间与管理详细程度成几何级关系。每多管一个配置项,将增加成倍的管理成本。尤其是经常变化的项,难以用流程控制的项。惠普的CMDB查看管理非常不方便,尤其是关联关系表现非常不好。而且真正需要管理的,比如系统的关键参数,配置文件,表现为管理不到位,经常性滞后。客观原因是参数各系统差异性太大,就硬盘分区表示来说就好多种,比如Windows是一种,AIX是一种,Solaris又是一种。那么怎么办?使用文档附件,那么文档格式,及时更新,版本控制等等一系列的问题都需要大量的工作来做。主管原因是发现及时更新实在太困难,就放弃了配置管理中这个最有用的作用。因为变更不能正常进行,所以配置管理自动降低档次,只能做一个加强版的资产管理。配置的考核等等逐渐废弛,因为每次要核对配置管理都需要普查,难度越来越大,越来越难以准确。最后,配置管理没有了流程,仅保留配置经理一个岗位,同时兼任配置管理员,配置管理最终堕落为资产管理。

manm 发表于 2011-7-14 11:23:00

看看看看

孤独无败 发表于 2014-4-7 21:01:35

锄禾日当午,发帖真辛苦。谁知坛中餐,帖帖皆辛苦!

简单生活 发表于 2014-4-7 23:18:40

打酱油的人拉,回复下赚取积分
页: [1]
查看完整版本: ITIL流程管理实施贴身感悟