如何使IT服务的运作和维护不受影响?

在IT基础架构的变更控制过程中，问题管理已经嬗变为问题与变更的协调管理。这也是在客户服务中心的服务支持框架下，看不到变更管理踪迹的原因。

在ITIL中，事件从服务台到事件管理，再到问题管理是一个解决力度逐步加强的过程，但也是一个治标未治本的过程。要真正做到防患于未然或者减少事件影响，必须实施一定的变更以消除事件产生的根本原因。

有变更必然会有风险，因此，加强对变更过程的控制，以防变更过程中的疏忽、资源短缺、准备不足等原因造成变更失败或产生新的事件已经成为IT服务提供者必须重视和认识考虑的问题。

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

一码多品频频出现

目前的IT服务提供者分为两种，一种是企业内部的IT部门，一种是第三方的IT服务提供商。随着业务的发展，IT技术也越来越紧密地深入到业务管理过程，而IT服务商们则面临着一个急需解决的问题：企业或者外包方购买的软硬件产品越来越多地来自不同的外部厂商。不论是IT部门还是IT服务商，以一己之力独立地完成软硬件问题根本性的解决变得越来越困难，甚至不可行。

当IT服务发展到问题管理无法在内部解决根源性问题，变更变得越来越不可控时，变更管理在哪里控制，如何控制就需要好好琢磨了。同样，我们客户服务中心现在也面临这个问题。

2007年4月初，上海某个区的许多用户频频发生扫描商品时出现一码多品的现象，即扫描商品条形码时会跳出4～5个商品品名。由于事件涉及面比较广，该事件迅速地升级到问题管理员的桌面。问题管理员将该问题转至软件提供商。

软件提供商费了几番周折才找到了问题根源：每日由服务器下发的基本信息中一些商品的条形码信息被修改，导致不同的商品品名存在同一个条形码的问题。

这种变更没有任何记录，也没有任何形式的通知。加之变更的过程不在我们公司客户服务中心的可控范围之内，在排除软件故障、数据通讯故障和服务问题之后才找到根源所在。此时，距事件发生已过去一周的时间。

加强变更控制

客户服务中心为客户提供零售系统的软硬件外包服务。如图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服务主体的客户服务中心，其变更管理认识以及变更风险控制意识仍需要进一步提高。

图1 客户服务中心ITIL框架

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

关于变更管理

影响业务的IT事件往往与变更有关。如果与变更有关的事件无法得到控制，IT服务提供者，甚至于整个行业本身也会因此而逐渐失去控制。事件的数量还在增加，而每一个事件出现时都需要“救火”，它可能极易催生导致新的事件发生的新错误。对于变更的日常计划经常未能考虑到不断增加的工作压力，因此，变更没有得到很好的管理。这同时也会影响到IT服务日常事务的运作和维护。

变更管理旨在管理变更的过程，以及相应地减少错误和与变更有关的事件。变更管理的格言是：不是每一次变更都能带来进步，但每一次进步都由变更引起。

来源：赛迪网－中国计算机用户