[原创]面壁ITIL之变更管理[本文被AMT公共知识库收录，奖励200金币，祝贺]

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

在ITIL中，事件从服务台到事件管理再到问题管理是一个解决力度逐步加强的过程，但也是一个治标未治本的过程。要真正做到防范于未然或者减少事件影响，必须实施一定的变更以消除事件产生的根本原因。有变更必然会有风险，因此，加强对变更过程的控制，以防变更过程中的疏忽、资源短缺、准备不足等等原因造成变更失败或产生新的事件已经成为IT服务提供者必须重视和认识考虑的问题。

图1是客户服务中心的ITIL服务支持框架，细心的读者会发现在服务支持中缺少了变更管理一项。有人会问：没有变更管理如何做好问题管理，找到了问题的根本原因应该如何变更？没有变更管理，发布管理又依何而生？这个问题长久以来也一直萦绕在笔者的脑海中。客户服务中心究竟有没有变更管理的需求？如果有，在哪里？如果没有，那又在哪里？

图1－客户服务中心ITIL框架 

目前的IT服务提供者分为两种，一种是企业内部的IT部门，一种是第三方的IT服务提供商。随着业务的发展，IT技术也越来紧密地深入到业务管理过程，而IT服务商们则面临着一个急需解决的问题：企业或者外包方购买的软硬件产品越来越多地来自不同的外部厂商。不论是IT部门还是IT服务商，以一己之力独立地完成软硬问题根源性的解决变得越来越困难，甚至不可行。当IT服务发展到问题管理无法在内部解决根源性问题，变更变得越来越不可控时，变更管理在哪里控制，如何控制就需要好好琢磨了。同样，客户服务中心现在也面临这个问题。

4月初，某个区的许多用户频频出现扫描商品时出现一码多品的现象，即扫描商品条形码时会跳出4，5个商品品名。由于事件涉及面比较广，该事件迅速地升级到问题管理员的桌面。问题管理员将该问题转至软件提供商。软件提供商费了几番周折找到了问题根源：每日由服务器下发的基本信息中一些商品的条形码信息被修改，导致不同的商品品名存在同一个条形码的问题。这种变更没有任何记录，也没有任何形式的通知。加之变更的过程不在客户服务中心的可控范围之内，在排除软件故障、数据通讯故障和服务问题之后才找到根源所在。此时，距事件发生已过去一周的时间。 

客户服务中心为客户提供零售系统的软硬件外包服务。如图2所示，当事件发生并升级为问题，提交到问题管理时，问题管理对问题做出简单的判断并分类。硬件问题转硬件提供商，软件问题转软件提供商。在收到他们的变更后，问题管理安排变更计划，准备变更。由此我们看到的变更管理出现在外部软硬件变更管理流程中，只是变更的最后实施在客户服务中心的管理范围之内。也就是说，变更的过程管理是存在的，但主要的变更控制不在客户服务中心。笔者曾下过一个片面的结论：客户服务中心不需要变更管理。这么看来这句话好像是对的，但是，再仔细琢磨这句话好像又有些不对。

图2－客户服务中心变更处理流程

变更是什么？变更是指在维护过程中对系统或服务所作出的各种改变，包括增补、移除和其他修改。说的再具体一点，变更的对象是两个，一个是IT基础架构，一个是IT服务（包括与流程和文档），与这两个对象相关的改变都要归入变更的范围。客户服务中心没有变更管理，果真如此吗？不是，IT基础架构中的软硬件变更的确不在客户服务中心的管理范围，但是IT服务的变更是存在于客户服务中心的管理范围之内。笔者之前把变更的认识局限在IT基础架构上，而忽视了对IT服务的变更认识。因此，从变更的对象来看，客户服务中心不仅存在着变更管理的需求，而且还必须建立起变更管理控制。

不论是企业的IT部门，还是第三方的IT服务商，都认识到协调好与软硬件供应商之间的关系是做好IT基础架构变更管理工作的前提。我们甚至可以把这种关系进一步深化为变更协作管理，充分运用SLA（服务水平协议）、OLA（服务支持协议）和UC（支持合同）来协调、约束各方面的这种协作关系，确保变更的可控。变更管理的要求、流程和相关的文档由软硬件供应商和IT服务商之间事先商定并共同遵守。内部的问题管理根据协商确定的格式和要求提交变更请求表，由外部的软硬件供应商接受并记录、登记，之后变更管理流程由外部的软硬件供应商负责变更请求的筛选、接受、变更优先级确定、变更规划、变更实施和中止。当变更走完外部的变更流程再次回到内部的问题管理流程时，问题管理协同发布管理安排变更计划和实施变更。由此笔者认为，在IT基础架构的变更控制过程中，问题管理已经嬗变为问题与变更协调管理。这也是在客户服务中心的服务支持框架下，看不到变更管理踪迹的原因。

如果变更的对象仅仅是指IT基础架构，那么对IT服务提供商而言是可以考虑不再设置变更管理流程了。但是，IT服务变更的存在使得这样的考虑不得不审慎。服务单据格式的变更、维护时间的调整、客户的搬迁等等都可以作为内部IT服务的变更请求。如果不设置变更管理，那么这些变更请求应该如何提交？变更应该如何控制，是事件管理、问题管理还是发布管理？

也许这个问题需要具体情况具体分析。比如，服务单据格式的变更请求可以归入到事件管理，由事件管理负责发起服务单据变更讨论协调会，将最后的变更结果再提交至发布管理。IT服务的变更控制此时就体现在事件管理；问题管理在受理事件的升级报告时发现原有的升级流程比较繁琐，效率不高。于是提出事件升级流程的变更，经过一番的讨论后，如果认可变更，那么执行变更。如果不被认可，变更中止，继续使用原有的事件升级流程。此时，IT服务的变更又可以在问题管理控制。不论使用哪一种管理流程来控制变更，其间都不能省略一个环节：变更讨论。这就是变更管理提到的变更影响和资源评估。

作为第三方的IT服务商，变更影响和资源的评估需要根据实际情况作出调整。对于客户服务中心而言设立变更委员会是解决变更控制问题的一个途径。凡是需要变更的内容，不论是IT基础架构还是IT服务的最终发布都必须在变更委员会上确定。IT基础架构的变更经变更委员会确定后统一安排变更计划并实施变更；IT服务的变更由相关的管理流程提出并变更，最后也需要经变更委员会确定后统一安排变更计划并实施变更。

在一个“变”作为惟一不变的环境中，变更管理尤显重要。有变更就有风险，有风险就必须控制。而变更管理的空缺，也从一个侧面说明作为IT服务主体的客户服务中心，其变更管理认识以及变更风险控制意识仍需要进一步提高。 

 

 

推荐到鲜果： 查阅更多相关主题的帖子: 变更管理 ITSM ITIL IT服务管理 IT治理