許多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或任何其他產業最佳實踐。