吉宁博士观点
IT服务战略专家DerekLonsdale是PAConsultingGroupLtd（总部位于伦敦）在马萨诸塞Cambridge办公室的CIO顾问。在本系列采访的第二篇中，Lonsdale谈到了CIO该如何减少变更管理流程中的中断，并且解释了为何CIO们需要将其变更管理的技能用于IT之外。在本系列的第一篇《消灭变更管理流程的障碍》中，Lonsdale谈到了CIO及其变更管理流程团队该如何识别并规避可能的障碍。
记者：CIO是否有其他方法来加速变更管理流程，以此跟上业务变化的步伐？
Lonsdale：我之前曾任职于一家员工数超过13万的大型能源公司。他们有一个全球三个本地共四个顾问委员会。对于如此规模的公司，你可能会认为这种机制形同虚设，但是由于事先过滤了会上讨论的事宜，这四个委员会确实运转有效。常规的变更事项不会被提交到委员会。而当一项变更提交到委员会之前，所有的批准和审核流程都已经走完了。
在很多企业中，顾问委员会在很多本无必要的问题上浪费大量时间，比如“你是否获得了批准？”或者“他们同意了吗？”。很多本该在之前就完成的事情被扔到了会上，从而导致会议效率极其低下。
记者：就变更管理而言，你是怎么保证所有人都协调一致的？
Lonsdale：对于每个自主设计的管理流程，我们都有相应的流程原则。这些原则可能没有包含在IT基础架构库中。这是一种将重要事宜聚集到一个流程中的方法，以此确保相关人员知道事件的重要级别。所有原则都是一种默认的共识，比如“在获得批准之前任何事情不能提交到顾问委员会”、“顾问委员会应该由哪些人组成”、“怎样才算得上是变更”以及“服务请求的定义”等。
下面举一个流程变更规则的例子：我曾经供职于一家制药公司，当时经常发现有大量的变更作为紧急事件出现。后来我们发现，是项目管理的问题导致了这种情况。
通常情况下，一个项目经理都会有自己的规划，知道什么时候需要服务器并将其放到数据中心里。由于现实总是不如人意，项目经理经常不得不在最后一分钟应对变化，提出紧急变更请求以便根据项目要求变化服务器的位置。
记者：那么你是如何解决这个问题的？
Lonsdale：我们为紧急变更设置了限制–在上面提到的情况里，只有出现系统失效的情况才能被考虑为紧急变更。如果不是，那么你必须耐心等待其他变更处理完成。项目经理们肯定不愿意这样，但是IT经理们会告诉他们常规变更的处理就是这样，别无选择。
记者：CIO们应该怎么评估变更管理流程的效果？
Lonsdale：这一点是非常重要的。如果你没有相应的评测方法，人们就不会改变以往的行为规范。因为变更失败而导致的事故就是一种有效的评测方法–看看到底有多少紧急变更被提交到了顾问委员会。
记者：你是如何让IT把变更管理看作一个持续改进的流程？
Lonsdale：持续改进的思想必须牢牢固化到变更管理流程团队中。该团队的责任就在于审阅失败变更和紧急变更的报告，并且提出问题，比如“为什么因为Oracle数据库而导致的中断会越来越多？”。在此之后他们还要指定相应的人力去解决问题。
记者：IT是否被要求参与到业务流程管理中，而非仅仅关注IT本身的变更流程管理？
Lonsdale：IT现有的流程框架是针对通用服务管理流程而建立的，但是也可以用于业务服务管理。我没见到很多CIO能主动地关注业务，他们通常都比较被动。尽管CIO们常被问到：“你能怎么帮助我们呢？”每当此时，IT会提出很多的建议，但他们还是会更多关注管理IT而不是服务。
记者：你认为这种情况会持续下去吗？
Lonsdale：由于服务（而不是技术）的理念已经开始逐渐树立，这种情况会有所改变。一些大公司已经开始关注诸如业务服务或者全球业务服务（面向更广范围的共享服务）。不仅仅限于IT，而是有一个单一明确的责任人来管理所有的IT、财务、人力和采购服务–所有这些都可以在更大范围内被共享。
记者：CIO怎样以自身的技能来支持业务服务的运转？
Lonsdale：通过服务目录来完成。与人力资源、财务和采购部门相比，IT在服务定义和成本核算方面比较擅长，能够提供很大的帮助。在制药领域，相关的行动已经开始。这是未来发展的正确方向，CIO们应该成为公司业务发展的领导者。
