论ITIL精华之变更管理.docVIP

论ITIL精华之变更管理 转自EwaySun的博客 在ITIL中，事件从服务台到事件管理再到问题管理是一个解决力度逐步加强的过程，但也是一个治标未治本的过程。要真正做到防范于未然或者减少事件影响，必须实施一定的变更以消除事件产生的根本原因。有变更必然会有风险，因此，加强对变更过程的控制，以防变更过程中的疏忽、资源短缺、准备不足等等原因造成变更失败或产生新的事件已经成为IT服务提供者必须重视和认识考虑的问题。 图1是客户服务中心的ITIL服务支持框架，细心的读者会发现在服务支持中缺少了变更管理一项。有人会问：没有变更管理如何做好问题管理，找到了问题的根本原因应该如何变更？没有变更管理，发布管理又依何而生？这个问题长久以来也一直萦绕在笔者的脑海中。客户服务中心究竟有没有变更管理的需求？如果有，在哪里？如果没有，那又在哪里？ 此主题相关图片如下： 图1－客户服务中心ITIL框架 目前的IT服务提供者分为两种，一种是企业内部的IT部门，一种是第三方的IT服务提供商。随着业务的发展，IT技术也越来紧密地深入到业务管理过程，而IT服务商们则面临着一个急需解决的问题：企业或者外包方购买的软硬件产品越来越多地来自不同的外部厂商。不论是IT部门还是IT服务商，以一己之力独立地完成软硬问题根源性的解决变得越来越困难，甚至不可行。当IT服务发展到问题管理无法在内部解决根源性问题，变更变得越来越不可控时，变更管理在哪里控制，如何控制就需要好好琢磨了。同样，客户服务中心现在也面临这个问题。 客户服务中心为客户提供零售系统的软硬件外包服务。如图2所示，当事件发生并升级为问题，提交到问题管理时，问题管理对问题做出简单的判断并分类。硬件问题转硬件提供商，软件问题转软件提供商。在收到他们的变更后，问题管理安排变更计划，准备变更。由此我们看到的变更管理出现在外部软硬件变更管理流程中，只是变更的最后实施在客户服务中心的管理范围之内。也就是说，变更的过程管理是存在的，但主要的变更控制不在客户服务中心。笔者曾下过一个片面的结论：客户服务中心不需要变更管理。这么看来这句话好像是对的，但是，再仔细琢磨这句话好像又有些不对。 此主题相关图片如下： 图2－客户服务中心变更处理流程 变更是什么？变更是指在维护过程中对系统或服务所作出的各种改变，包括增补、移除和其他修改。说的再具体一点，变更的对象是两个，一个是IT基础架构，一个是IT服务（包括与流程和文档），与这两个对象相关的改变都要归入变更的范围。客户服务中心没有变更管理，果真如此吗？不是，IT基础架构中的软硬件变更的确不在客户服务中心的管理范围，但是IT服务的变更是存在于客户服务中心的管理范围之内。笔者之前把变更的认识局限在IT基础架构上，而忽视了对IT服务的变更认识。因此，从变更的对象来看，客户服务中心不仅存在着变更管理的需求，而且还必须建立起变更管理控制。 不论是企业的IT部门，还是第三方的IT服务商，都认识到协调好与软硬件供应商之间的关系是做好IT基础架构变更管理工作的前提。我们甚至可以把这种关系进一步深化为变更协作管理，充分运用SLA（服务水平协议）、OLA（服务支持协议）和UC（支持合同）来协调、约束各方面的这种协作关系，确保变更的可控。变更管理的要求、流程和相关的文档由软硬件供应商和IT服务商之间事先商定并共同遵守。内部的问题管理根据协商确定的格式和要求提交变更请求表，由外部的软硬件供应商接受并记录、登记，之后变更管理流程由外部的软硬件供应商负责变更请求的筛选、接受、变更优先级确定、变更规划、变更实施和中止。当变更走完外部的变更流程再次回到内部的问题管理流程时，问题管理协同发布管理安排变更计划和实施变更。由此笔者认为，在IT基础架构的变更控制过程中，问题管理已经嬗变为问题与变更协调管理。这也是在客户服务中心的服务支持框架下，看不到变更管理踪迹的原因。 如果变更的对象仅仅是指IT基础架构，那么对IT服务提供商而言是可以考虑不再设置变更管理流程了。但是，IT服务变更的存在使得这样的考虑不得不审慎。服务单据格式的变更、维护时间的调整、客户的搬迁等等都可以作为内部IT服务的变更请求。如果不设置变更管理，那么这些变更请求应该如何提交？变更应该如何控制，是事件管理、问题管理还是发布管理？ 也许这个问题需要具体情况具体分析。比如，服务单据格式的变更请求可以归入到事件管理，由事件管理负责发起服务单据变更讨论协调会，将最后的变更结果再提交至发布管理。IT服务的变更控制此时就体现在事件管理；问题管理在受理事件的升级报告时发现原有的升级流程比较繁琐，效率不高。于是提出事件升级流程的变更，经过一番的讨论后，如果认可变更，那么执行变更。如果不被认可，变更中止，继续使用原有的事件升级流程。此时，IT服务的变更又可以在问题管理控制。