在做运维的时候，始终将注意力放在了流程上。设计完流程就开始执行。这也是中层管理人员需要考虑的事情。从来没有考虑过我设计的流程是否在现有的组织框架下能够体现最大价值。也可能是现行的IT组织框架比较合理，所以没有对流程的设计产生什么不利影响。当跳出自己工作的环境时，突然发现IT组织框架对流程的设计还是有很大影响。

    讲ITIL，我们喜欢拿职能型和流程型两种组织做比较。得出的结论就是流程型组织更适合实施ITIL。回头看看，如果当年我们没有对运维体系做了事先的变动，采用运维和管理分开。依然沿用按技术分运维小组的结构，每个小组有一个主管，分管各自一摊事情。那么设计流程时可能就会遇到一些障碍。比如：流程之间的协调涉及两个不同的运维组就会出现扯皮的现象。分开之后，运维流程基本上在运维小组中运行，好坏都是自己的事情没那么多借口推脱。运维和管理分开不仅可以减少“小国林立”带来的割据弊端，而且能够整合服务资源，统一对服务资源进行管理、监督和控制。

    也许实施ITIL的IT部门或多或少都会调整原有组织框架以适应新的IT管理需要，对于ITSM咨询而言，“望、闻、问、切”中的“望”首先是要来看看他们的IT部门组织框架。看看这种框架是否清晰明了，看看这种框架是否适合ITIL的推行。    一般而言，IT组织框架都是IT部门多年运行形成的稳定结构。不管是否清晰，能够应付客户的运维需求就有其存在的理由。也正是这个原因，他们在实践ITIL的时候可能会忽略组织架构的影响，进而在设计流程时受到一些不自主的约束。虽然有人能够大刀阔斧进行结构调整，但是更多的人还是默认了这种结构。不管默认与否，建议是在设计ITIL流程时，先考虑一下自己的组织框架。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。