在中国的企业里，做什么事必须有领导的支持。首先是自己要学习领悟ITIL理念，然后是说服公司高层领导，最后让中层管理者在认识上达成一致。ITIL给企业带来的变革不仅在IT层面，而且也体现在经营管理层面。比如原来组织内部的人员和岗位，从一定程度上可能都不适合ITIL架构，需要先把大家的岗位打散，然后再定岗定角色安置人员，这可以算是组织结构的大调整。当然在岗位调整过程中，有些人员可能和位子不太搭配了，就做调换，挑选合适的人来做。这样的大调整，没有领导的支持基本是没法做的。在不少企业中，往往囿于组织结构变革的压力，采用了硬往ITIL上面靠的办法。说到底，还是领导的支持力度不够。
在实际工作中，你还会发现，每个公司本身往往都有多年的历史沉淀，如果完全按照ITIL的理想标准去做，可能根本就行不通。如何把ITIL最佳实践标准的理想和公司运营的实际状况去磨合，这将是我们应该花费更多时间和精力去考虑的。比如一个明显的问题--公司人员专业化细分。按照ITIL的要求，职员角色划分得越细、越清晰越好。
这样做的有利之处在于容易避免工作中的扯皮。但实际上一个公司的运维部根本没有那么多人，很多时候都是一个人身兼多重角色和多个职务。这种详细的职责划分和专业分工也只有在公司业务达到相当规模后，才会产生规模效应。纯粹按照理想的标准去做，不现实也不可能。最后我们采取了折中的办法：人员少，职务多，只有暂时一个人身兼多个职务。随着人员的扩充，逐渐把多重角色分出去。实施ITIL标准化运维一年后，公司运维人员增长了近一倍。
再一个人员考核的问题也比较多。按照ITTL顾问制定的考核标准，要对公司员工进行细致的考核。从定性到定量，每个人的考核要素都很齐备。以现场运维工作人员为例，就包括一次性问题解决率和客户对运维工程师工作质量的评价等。如果人员分工做不到那么细，一人身兼多重角色，也为量化考核带来了难题。虽然各种管理工具能够给出一些量化的数据，但具体到某个员工的考核，系统工具也不能完全反映一个人的各种角色所完成工作的成绩和质量，但工程师做过的这些工作并不应该被抹煞。
在过去，无论是对网络的维护还是服务器、数据库的运维管理，工程师的经验往往最重要。好多故障的处理也多是“救火”，治标不治本。每一个技术问题，其实都会有多种解决方法。甲和乙两个工程师的解决方法可能完全不同，但结果可能都挺好，客户都满意。如果这两位工程师跳槽了走了，解决问题的办法也就随之流失，新来的员工还要重新摸索重新熟悉环境。如果有统一的流程和事件管理及事后的案例积累和知识库的建立，就可以不管谁来做，都能按照这个流程和规范来走。这样即使公司有人员流动，但流程一致确保了整个运维服务质量的稳定。
在运维工程师解决问题的过程中还可能会涉及到变更管理和配置管理。比如说，一个服务器的性能较差，可能会引起很多问题，换内存、换硬盘、调试系统的问题可能频繁发生。这些就会带来系统变更。而如果找到了真正原因，对服务器进行了参数配置变化，就涉及配置管理了。
对于企业来说实施ITIL，将有助于最终实现完善的服务管理。在ITIL的各个流程管理中，可以直接与企业各个业务部门相互作用，实现对业务功能及流程进行重新设计，降低成本、缩短周转时间、提高质量和增进用户满意度。但ITIL的流程固化，人员分工也固定，感觉运维的灵活性多多少少会有些损失。问题在于，一个工程师在一个岗位上干得久了，就会有一定的职业倦怠感，而轮岗就会更不适应了。同时精细的分工会导致一个问题的处理会需要多个部门和多个人员的参与，无形中延长了处理问题的时间。
