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

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

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

　　五、流程废弛的根本原因——兼职“变更经理”

　　流程管理是一个最佳实践，是和管理需要分不开的，流程管理是理想化的管理办法。

　　我们如何做适合自己的流程管理呢？任何单位都有这个需求，那么需要从目标管理过渡。流程管理的人员设置一定要符合权力制衡。

　　刚开始时，人员增加是可行的。因为你原来没有多余的人，坚决不建议兼职做流程关键点的控制，那样他们会有选择，有选择就不是流程管理，有选择就有“权力腐败”的可能。

　　变更管理的权力大，危险性大。各组织默认的就是原来谁负责，现在谁还继续负责变更管理，忽略了其他流程所对应的制衡关系。

　　原来变更对管理者来说是一个不受监督的权力，现在继续拥有这个权力。在没有好处的情况下受到了其他流程的监督。以最基本的常理逻辑来推断，变更经理会努力的推动流程良性执行吗？因为原来的方式已经习惯啦，习惯的力量有多大，没有人会反对吧？

　　把原来的集中的总负责权力分开成配置经理、变更经理、问题经理，这样便于流程制衡。定义变更经理为纳入变更流程范围配置项的变更才需要进入变更流程，没有纳入流程管理的人事、工作分派、绩效考核等等原来怎么管还是怎么管。这样分解了原来总负责的工作内容，减轻了负担，“配置、变更、问题流程”各司其职，相互制衡。这才是服务管理的精髓。

　　六、人的问题——选人来解决

　　服务管理实施就是服务业的ERP。一把手亲自负责，或者一把手指定专门的特派员负责，拒绝一把手挂名实际不参与开会。要求有一个就是能够协调流程涉及资源的人做项目总负责，最好是CIO。