体悟之四：妥协的流程管理——“捡芝麻丢西瓜”
在这个实际的案例中：组织为了节约人力，可能主观上是为了推动工作开展，让原来熟悉业务，原负责的人推动变更流程，结果变更经理直接由原来的组织负责担任，配置经理和问题经理直接受变更经理领导。
变更经理实际就是原组织的领导，以前需要关注资源协调，客户沟通，还有问题的处理，还关注事件的响应，还负责所有数据中心管理。但往往对变更关注不够，批复不及时，跟踪不够，难以评估、审查完成情况。在这种情况下，配置管理根本不能制衡更变管理流程，经常性滞后。
问题管理流程也糟糕，按说问题管理最容易做好。实际上，该案例中快速响应以前就是具体系统管理员(系统管理员、网络管理员、邮件管理员等)，刚建立的专家组实际是原来的几个方面技术相对较好的主管。这些主管原来的工作继续保留。因问题分析需要经过长期的分析跟踪，研究过往历史记录，长时间的分析不可能，而这些新的问题专家各管一方，日常事务杂且多。过往记录、厂商资源、运维经验、系统的基本状况基本上都掌握在原来快速响应工程师手中，没有形成共享资源，这些人对系统最了解，但仅限于他们自己的大脑中。相反问题专家要是研究的话，反而延误时间，协调不力。何况还没有时间做这个事情。因此问题管理始终还是以快速响应工程师为主在做，那么效果不可能好，自然大打折扣。另外，问题管理流程刚出来的时候，大家一下子就觉得——好啊，把以前的历史问题，新发生的不加严格筛选的问题，一股脑全部推给问题流程，问题管理流程根本就没有力量来处理这么多问题，结果也是不了了之。
不了了之的根本原因是没有人关注问题经理的考核。变更流程不要求问题流程，事件流程不升级到问题流程。所以问题流程在“众人合谋”中“瘫痪”。
配置管理在系统宣导的时候，客户发现这太好了。可以把涉及系统的所有的参数都管理起来。但实际发现，CMDB付出的时间与管理详细程度成几何级关系。每多管一个配置项，将增加成倍的管理成本。尤其是经常变化的项，难以用流程控制的项。惠普的CMDB查看管理非常不方便，尤其是关联关系表现非常不好。而且真正需要管理的，比如系统的关键参数，配置文件，表现为管理不到位，经常性滞后。客观原因是参数各系统差异性太大，就硬盘分区表示来说就好多种，比如Windows是一种，AIX是一种，Solaris又是一种。那么怎么办？使用文档附件，那么文档格式，及时更新，版本控制等等一系列的问题都需要大量的工作来做。主管原因是发现及时更新实在太困难，就放弃了配置管理中这个最有用的作用。因为变更不能正常进行，所以配置管理自动降低档次，只能做一个加强版的资产管理。配置的考核等等逐渐废弛，因为每次要核对配置管理都需要普查，难度越来越大，越来越难以准确。最后，配置管理没有了流程，仅保留配置经理一个岗位，同时兼任配置管理员，配置管理最终堕落为资产管理。
| 
转播
分享
淘帖
()
