许多IT机构通过已发布的框架来改进他们的服务水平，特别是ITIL及其基础的ITSM质量管理理念，以供指导。不幸的是，许多ITSM项目没有达到预期的收益，或者更糟的是，他们发现他们的服务指标和商业信誉已经走错了方向，一个表现是体系没有运转起来，ITSM工具没有完全用起来。 一个常见的反应是责怪ITIL，但真正的原因通常更为基本。本文试图结合多年的项目实践，说明ITSM项目负责人如何避免10个经常损害这些必要举措的败点，并提供了一些建议来最大限度地提高项目成功的机会。如果您的项目已经在进行中，评估每个要素的隐患，并采取行动来减轻影响。

一、对组织变革的关注度和难度认识不够

经常低估正式管理组织变革的需要，但变革是成功的基本要素。个人认证以及流程和服务交付培训可能是有帮助的，但IT领导者还必须确保他们的团队保持现有的持续发展的实践，如DevOps和数字业务。

解决方案：管理层必须将组织变革作为ITSM初始和持续规划的核心部分。 必须有指标来衡量个人和团队实施新方法的程度。如果个人天生不愿改变上升到团队一致抵制，那么项目治理者需要立刻采取行动。 简单的说：要有变革的意识和思维，有破局的魄力和能力，而不是遵守各种的现状，这点我在不少项目里都有遇到，客户会说“秦总，我知道您说的，但是这几年我们都是这样的……”

ITIL流程需要组织架构、文化、制度紧密协同与充分契合才能发挥作用。

二、机械的为了ITIL而ITIL

历史上，许多基础设施和运营团队认为ITIL是管理IT生产运营的唯一建议来源。 ITIL V3发行后，作者将ITIL的名称从“良好实践”改为“最佳实践“，这得到了支持。这致使许多IT服务组织觉得其他建议来源都是不必要的。然而，自从2011年ITIL最新更新以来，IT产生了巨大的变化，特别是随着敏捷方法的兴起，双模IT和数字产业主导成为大多数企业发展的引擎。

解决方案：

鼓励IT服务组织越过ITIL等已建立的框架，ITIL选择自己需要就要，IT服务的管理完全可以融合其它的标准和实践，包括DevOps。ITIL不能被逐字实施，就像是国际标准化组织（ISO）标准一样。适合自己，才是最好的。

三、咨询缺乏或者咨询顾问不当

有经验的咨询顾问可以用来提高服务改进项目的质量和速度。 但是，如果顾问的管理不善，则会占用项目成本的很大一部分，并且几乎没有好处。

我曾经遇到一个集团化的上市公司，在ITSM项目中，没有咨询环节，反倒是已经用了2家ITSM工具了。第3家选择了我们，问为什么为没有咨询呢？理由是“高层非常知道我们的现状，没有那样的成熟度，做不了咨询……”，其实，连咨询不敢做，那为什么上ITSM，实施ITIL呢，这种可能仅仅适合有一个简单的“工单系统”吧。

解决方案：如果可以，尽可能有专业的咨询和咨询环节。专业的咨询顾问，可以为客户清楚的分析项目的目标和现状、差距，以及改进措施，带来不同客户的好的实践，这点是非常有价值的。

使用顾问，如果他们能为您的项目带来特定技能和知识产权。 明确他们能带来的好处，并管理他们来提供这些好处。确保知识转移到团队内部，以便顾问离职后，改善势头可以持续下去。

ITSM项目要求服务改进，因此经常是需要一个组织能够承担的最佳项目管理和治理技能的重大变革性举措。

四、缺乏清晰的目标

ITSM必须致力于改善服务，服务于目标的达成。 如果该计划的业务要求没有被预先说明和密切管理，那么IT管理层就会将这些努力标记为无关紧要，从而浪费资源。有效的项目管理需要引入指标来显示正在进行中的项目的目标，而不仅仅是任务。团队应该定期开会并积极考虑这些项目指标是否仍然是最适当的，可以确保交付项目简报中所述业务价值的。确实这样，在项目在进行中，才有人跳出来说我们可能不该做ITSM，在项目快结束时，才反过来想我们应该做CMDB等等。

解决方案：尽可能早的确定项目目标，并在项目启动会前达成一致，在项目启动会上宣贯。以下是我在一个项目中为客户的ITSM项目确定的项目目标：

本期项目建设的IT服务管理平台，是基于ITIL V3，参考ISO20000标准，建立IT服务管理平台，以平台工具为技术基础，结合逐步完善优化的流程规范及人力资源，进一步提高IT服务质量与时效，提升整体IT服务水平，提高满意度。

当然，这是一个数百万级别的银行的项目目标，还是比较宏大的。合适的项目目标，是与IT所处的管理成熟度，文化和执行力，投入的成本和资源有关系的。

五、项目经理级别低，也缺乏高级管理支持

ITSM是一个一把手的项目，这是毫无疑问，因为本质上ITSM项目是一个类似于ERP一样的管理项目。成功的领导者将IT视为由相互联系的功能领域组成的系统，以实现各种相关目标。 因此，领导者必须在一个系统的或战略的层面评估、规划和实施关键转型，以优化工作。所以，项目经理如果层级比较低，没有比较高的视野，再没有高层的强力支持，项目是很难成功的。

解决方案：至少是IT组织的中层来做PM，一把手或副总经理级别来做项目总监，并且获得一把手总经理的充分授权。这样的级别的项目经理可以清楚了解项目与IT中正在进行的转变及业务之间的联系。有一定层级的PM才能更好的规划与高级管理层的沟通，会议和其他互动，以获得并维持他们的支持。

实时上，我们有大量的项目就是如此，经理级别担任PM，副总作为项目的总监参与日常的项目中来，定期给CIO级别汇报。这样会有助于保证项目成功，反之，项目经理的层级较低，中高层的参与度不够，项目的结果就不太理想。

六、多项目齐头并进，资源不足，组织变更能力超载

多个管理流程模块齐头并进，人力资源协调、参与配合问题。这一点，如果项目已经启动，出现上面的情况那还真不好办，都是项目，大家都要完成任务。我们作为供应商，遇到这样的问题，还真的头疼，找人配合非常困难，因为大家都很忙。

解决方案：及早的把各个流程的流程负责人确定，确定项目组，把相关干系人绑在一条船上，资源保证，沟通协调。一定要避免项目经理单打独斗，带着供应商闭门造车。

七、过程缺乏充分沟通，参与度不够，缺乏评审过程

IT将ITSM计划的目标和进度有效地传达给各利益相关方是至关重要的。有些项目存在以下问题:

1）、项目经理过于强势或者主观，以其他人不懂过多的做做主张；

2）、客观上，项目比较多，相关团队的参与不够；

3）、目标不一致，误以为ITSM\ITIL项目是某个小组的事情，没有利益共同体。

解决方案：

1）、尽早的识别利益相关方有哪些，建立沟通机制和项目组；

2）、确定每个流程的责任部门和流程负责人，也就是“业主”，让他们的去发挥作用，而不是PM，PM做好协调即可；

3）、项目需求和调研阶段的访谈和现状分析报告、流程设计的报告的充分评审；

4）、周例会机制，相关利益方，要充分的参与到项目中。

当然，这个也要看项目的规模，和客户的复杂度。项目规模很大，动静太大也不合适。

八、贪大求全，迭代思维缺失

避免昂贵的，需要花费很长时间才能产生结果的，最终证明是相当危险的ITSM努力。 一般来说，努力越大，就越昂贵，就需要更久来产生结果。

解决方案：创建一个服务改进路线图，使用迭代或分阶段的方法，把一个大项目分为多个可以迭代的阶段。在管理层批准下一阶段之前，每个阶段都必须确定目标，确保预算和记录收益。 这样可以提高透明度和敏捷，因为它有助于利益相关方通过积木式模块努力方式来思考，设立多个检查点，以检查进度并更好地管理成本和收益。

九、项目中过早地聚焦在工具上而过多的定制化

警惕大量定制已确立的工具集。 定制化往往会破坏工具设计好的方法，并会明显增加升级成本。 因此，许多组织继续使用落后当前版本许多的服务管理工具。过多的定制，就是以为和定制化的工作的紧耦合，升级困难，结果他们错过了潜在的，可能已经是行业领先工具带来的进展。

我最近刚好也遇到了一个证券的客户，在HP Servicemanager的基础上，做了太多的定制化开发，导致后期的升级和持续维护困难，进一步开发的困难重重，替换的难度也很大，因为世面上没有完全满足他们需求的产品。

解决方案：避免大量工具定制，定制化尽可能限制在接口层面，这样可以更好的升级，享受厂家产品升级带来不同客户良好的实践的好处。另外，用户体验的重要，但是也没有重要到把管理做好的重要性。能专业化工具做好的，尽可能专门的工具来做。非高频的可以线下的，也可以线下。一句话：ITSM不能解决所有问题。

十、为了管理而管理，而不是关注价值

企业的目标是创造价值，所以IT的目的是提供服务和功能来支持业务目标。 因此，ITSM必须提供与战略业务优先级相关联的服务和改进措施。决定“实施ITIL”的IT管理团队如果不考虑业务优先级，则从一开始就可能毫无意义，所有IT部门必须努力使业务能够实现其明确的商业宗旨和目标。比如说，我们是不是一定要在先阶段建设CMDB，是否要建设一个全面的CMDB。

解决方案：确保ITSM的原因与组织的目的及目标相关。 IT管理层必须定义和传达服务管理愿景，确定为何创建和保护和组织目标相关价值是相当重要的。重点应在于服务改善和创造整体业务价值，而不仅仅是ITIL或任何其他产业最佳实践。