一头是上级的要求、一头是员工的抵制。要想在“行驶中换轮子”，还真有些力不从心。他怎样解决运行管理的问题呢？
“南桔”成“北枳”
王主任是某省电信公司计费业务中心主任。五、六十人的计费业务中心负责全省计费、经营分析等重要业务系统的建设和运行工作。 计费业务中心虽说人不少，但具体到每个系统，也就一、两个人负责。由于业务变化快、系统升级改造频繁，这些人的主要精力放在了项目建设和工程施工上，运行保障工作基本处在比较初级的自发状态：工作以“救火队”方式的被动响应为主，故障处理和系统维护过程基本没有记录和总结。王主任理解，ITIL（信息技术基础架构库）建设是管理项目，ITIL标准的确先进，咨询专家说得也绝对正确，大厂商昂贵的软件功能确实很多，但落实到本部门实际工作中，总感到很隔膜。听专家和厂家介绍起来头头是道，只要买了他们的产品和服务就能包治百病，但真花了很多钱之后似乎什么病也没治好，还说不清人家的东西哪里不好。是ITIL到了国内水土不服，还是国际大厂商开出的药方不对症？总不能说自己生的病不对吧？
ITIL在该企业中的应用归结下来主要有以下几方面问题：
◆ 系统建设耗费大量部门资源，无力进行运行保障工作；
◆ 部分员工不愿接受ITIL带来的变化；
◆ 流程“一人多角”现象严重，执行层面阻力较大；
◆ 流程工具使用情况不理想，系统建设成效不够显著。
勿让ITIL成“北枳”
企业在IT运营过程中遇到的80%的问题是由管理原因导致，而管理问题需要采用管理的手段加以解决，这也是身为IT管理最佳实践的ITIL如此受到推崇的原因之一。 然而，尽管ITIL拥有国外各大企业成功实践的“纯正血统”，但正如“南桔北枳”的道理一样，对他人成功的简单移植却并不一定能够确保自己的成功。根据我们对国内各大企业的调查表明，国内企业上马ITIL的不少，但真正能够有效利用并体现其价值的却寥寥无己。大家讨论的话题也逐渐地由What转移到了How。如何在组织内部正确地实施ITIL，使其最佳实践的理念和方法在国内IT的土壤中生根发芽、茁壮成长，最终收获期望的果实，如何让“北枳”与“南桔”一样甜美，甚至超过“南桔”变成世人称道的“北桔”，成为一个严峻而富有挑战的现实问题。
北方如何收“南桔”-建立故障点关联裙带展现
故障分析往往是最头痛的，因为在这个过程中寻找问题原因需要花费很多的时间，但是在我们以往的操作中往往会出现一种现象，就是费了很大工作量将一个故障处理完毕后，马上有人打电话过来说怎么这个问题解决了另外的一个功能又不好用了呢？
其实，当管理人员全心去处理故障的时候往往忽略了与这个故障点相关的其他IT资源，所以导致我们工作中可能会出现“拆东墙补西墙”的现象，如果有一种机制可以做到在一个故障点处理的过程中帮助管理员将与之有依赖关系的IT资源也同时列出来的话，那么管理员在处理故障时就会有一个参考，事先做到故障处理过程中的风险分析，这样一来，就不会出现解决老问题引起新问题的现象了，比如下面这个故障：
“南桔”成“北枳”
王主任是某省电信公司计费业务中心主任。五、六十人的计费业务中心负责全省计费、经营分析等重要业务系统的建设和运行工作。 计费业务中心虽说人不少，但具体到每个系统，也就一、两个人负责。由于业务变化快、系统升级改造频繁，这些人的主要精力放在了项目建设和工程施工上，运行保障工作基本处在比较初级的自发状态：工作以“救火队”方式的被动响应为主，故障处理和系统维护过程基本没有记录和总结。王主任理解，ITIL（信息技术基础架构库）建设是管理项目，ITIL标准的确先进，咨询专家说得也绝对正确，大厂商昂贵的软件功能确实很多，但落实到本部门实际工作中，总感到很隔膜。听专家和厂家介绍起来头头是道，只要买了他们的产品和服务就能包治百病，但真花了很多钱之后似乎什么病也没治好，还说不清人家的东西哪里不好。是ITIL到了国内水土不服，还是国际大厂商开出的药方不对症？总不能说自己生的病不对吧？
ITIL在该企业中的应用归结下来主要有以下几方面问题：
◆ 系统建设耗费大量部门资源，无力进行运行保障工作；
◆ 部分员工不愿接受ITIL带来的变化；
◆ 流程“一人多角”现象严重，执行层面阻力较大；
◆ 流程工具使用情况不理想，系统建设成效不够显著。
勿让ITIL成“北枳”
企业在IT运营过程中遇到的80%的问题是由管理原因导致，而管理问题需要采用管理的手段加以解决，这也是身为IT管理最佳实践的ITIL如此受到推崇的原因之一。 然而，尽管ITIL拥有国外各大企业成功实践的“纯正血统”，但正如“南桔北枳”的道理一样，对他人成功的简单移植却并不一定能够确保自己的成功。根据我们对国内各大企业的调查表明，国内企业上马ITIL的不少，但真正能够有效利用并体现其价值的却寥寥无己。大家讨论的话题也逐渐地由What转移到了How。如何在组织内部正确地实施ITIL，使其最佳实践的理念和方法在国内IT的土壤中生根发芽、茁壮成长，最终收获期望的果实，如何让“北枳”与“南桔”一样甜美，甚至超过“南桔”变成世人称道的“北桔”，成为一个严峻而富有挑战的现实问题。
北方如何收“南桔”-建立故障点关联裙带展现
故障分析往往是最头痛的，因为在这个过程中寻找问题原因需要花费很多的时间，但是在我们以往的操作中往往会出现一种现象，就是费了很大工作量将一个故障处理完毕后，马上有人打电话过来说怎么这个问题解决了另外的一个功能又不好用了呢？
其实，当管理人员全心去处理故障的时候往往忽略了与这个故障点相关的其他IT资源，所以导致我们工作中可能会出现“拆东墙补西墙”的现象，如果有一种机制可以做到在一个故障点处理的过程中帮助管理员将与之有依赖关系的IT资源也同时列出来的话，那么管理员在处理故障时就会有一个参考，事先做到故障处理过程中的风险分析，这样一来，就不会出现解决老问题引起新问题的现象了，比如下面这个故障：
我们看到，如果故障点在Latte-OA2上，那我们在对这个应用进行故障处理的过程中自然会考虑到其他两个相关的IT设备，易于风险控制。
当然，风险控制是一方面，如果我们在处理这个问题的时候需要厂家或者供货商的支持人员给予协助时，怎么面对数量非常多的供货商和厂家，立即找到这个故障点所对应的厂家或供应商的技术支持联系方式，这个问题也是在故障处理的协作中非常重要的一点。
比如下面这个页面，就是在故障点上点击右键查看资源详细信息时能够带给我们的信息：
当然，风险控制是一方面，如果我们在处理这个问题的时候需要厂家或者供货商的支持人员给予协助时，怎么面对数量非常多的供货商和厂家，立即找到这个故障点所对应的厂家或供应商的技术支持联系方式，这个问题也是在故障处理的协作中非常重要的一点。
比如下面这个页面，就是在故障点上点击右键查看资源详细信息时能够带给我们的信息：
本文转自赖永锋51CTO博客，原文链接：http://blog.51cto.com/mochasoft/160998
，如需转载请自行联系原作者
