[ITIL] IT服務管理經典語錄---劉億舟

#億舟語錄#之 1： 信息化在給我們帶來巨大的生產力提升的同時，也把我們引入到一個“唯技術論”的誤區，即凡是遇到問題，首先想到的是如何從技術上加以解決。IT服務管理的 引入，開始逐步革新了大家的意識，將讓我們認識到，搞好IT，不僅僅是從技術着手，而是需要同時從管理着手。管理也是第一生產力！

#億舟語錄#之2：信息化的本質是通過技術手段弱化或者消除信息不對稱問題，信息化的結果則是實現了線下的工作線上化，信息傳遞容易化、信息共享便捷化，隱性的信息顯性化。

#億舟語錄#之3：就IT服務管理的信息化而言，很多情況下，半自動化半手工化的解決方案也許比所謂的全自動化的解決方案更容易推行起來，也更容易見效。

#億舟語錄#之4：就IT服務管理而言，過分地追求信息化，意味着從心態上放棄從管理和配套規則上解決問題，這是很危險的。一味地尋求技術的解決方案，會讓IT管理者走進技術的死衚衕。當然從長遠來看，能夠通過技術解決的，應該儘量減少人工干預。技術上一小步，管理上一大步嘛。

#億舟語錄#之 5：管理大師亨利明茨伯格說過，“未來的工廠只有兩個僱員，一個人和一條狗。人負責喂狗，狗負責看住這個人不要去亂碰工廠的自動化生產線”。IT管理的 信息化理論上也應該是這樣的,顯然，現階段是沒有這個可能的。因此，只要有人的介入，就必須採用管理的思維，而不單純是技術的套路。

#億舟語錄#之 6：有家製藥廠經常發現有些包裝好的藥品是空盒子，於是試圖通過技術手段解決這一問題。技術攻關小組嘗試着對包裝流線水線進行改進，花了很多錢但以失敗告 終。而新來的主管在包裝流水線邊上架起一座電風扇就輕易將那些空盒子吹跑了。此事不知是真是假，但卻很值得我們所有IT人員思考。

#億舟語錄#之 7：話說小張和小李小兩口都是搞軟件開發的也都很喜歡看書。小張（丈夫）提議開發一個小程序將所有的圖書管理起來。小李表示贊同。於是夫婦倆決定將所有的 圖書分成38大類、1236小類，並且買了買了很多書櫃和標籤。三年後你覺得會發生什麼情況？啓示：技術上能做到的我們就一定要做到嗎？

#億舟語錄#之8：不考慮成本而一味地追求高技術解決方案，只能說明你是一位技術愛好者和技術發燒友，而不能說明你是一位合格的信息化的管理者。

#億舟語錄#之9：中國有很多技術管理者，但還遠沒有形成成熟的IT職業經理人羣體。對技術和管理的深入理解和均衡駕馭是IT職業經理人走向成熟的體現。

#億舟語錄#之 10：對於IT管理者來說，管理和技術是他們看待問題的兩個維度。在他們看來，技術是一項相對嚴謹而又簡單的事情，而管理則是一項相對開放且複雜的事情。 因此，他們普遍認爲，技術問題容易使得上勁，而管理問題很多時候使不上勁。對於中國的IT職業經理人階層而言，管理是一門必修課。

#億舟語錄#之 11：隨着組織在信息化方面的投資不斷增加，組織對IT服務管理提出了越來越高的要求，信息技術部門也需要逐步從“成本中心”向“利潤中心”轉化，如何 “像經營企業一樣經營IT部門”是所有IT管理者必須要面對的課題。簡言之，組織內部IT服務的商業化和市場化是一個不可逆轉的趨勢。

#億舟語錄#之 12：在IT服務領域，有三類公司：（1）賣人—“只唱戲、不搭臺”，人才輸出；（2）賣軟件—“只搭臺、不唱戲”，管理輸出；（3）賣服務—“既搭臺， 又唱戲”，價值輸出。所有ITSP將來的方向必然是“既搭臺，又唱戲”這樣才能走出只收“賣人”的錢，卻要對“賣服務”的結果負責的痛苦境地。

#億舟語錄#之13：賣服務就是賣***！這是所有IT服務銷售人員必須深入理解的一句話。中國IT服務外包商要着力提高服務的保障（Warranty）價值，獲得甲方客戶的信賴，才能從“賣人頭”轉變到“賣SLA”。

#億舟語錄#之 14：對於SI，我有一個新的解釋，Service Integration（服務集成商）。對於選擇多家IT服務外包商的甲方客戶來說，各服務商技術上沒有短板，但各家服務商之間存在諸多的“縫隙”。有效 地整合這些服務外包商的資源需要甲方自己或者服務總包商充當服務集成商（IT服務管理）的角色。

#億舟語錄#之 15：系統集成商向服務提供商實現戰略轉型的演進路徑爲：技術服務化（在提供技術產品的同時提供配套的增值服務）→服務產品化（基於服務目錄和SLA的管 理實現服務契約化交付）→服務工程化（基於服務生命週期管理實現服務可大規模複製）。中國的IT服務商首先要實現的是服務產品化。

#億舟語錄#之16：乙方銷售人員跟甲方領導談的服務範圍是A，合同裏要求寫明的是B，甲方IT用戶要求的是C，乙方IT服務項目人員被要求做的是D，其實最後真正付費的服務範圍是E，這就是中國IT服務外包市場的“韓喬生定律”。

#億舟語錄#之17：中國IT服務外包市場“韓喬生定律”現象背後折射的是，中國IT服務市場契約精神的缺失以及甲方客戶對SLA的不信任，解決這一問題的根本在於乙方要建立完善的服務體系，實現“可預期、可承諾”的IT服務，而不是事前拍胸脯，事後拍腦袋，實在搞不定就拍屁股。

#億舟語錄#之 18：在中國IT服務外包行業，解決問題有兩種方法:正法和“邪”法。所謂的最佳實踐是正法，正法未必有用，但卻是我們要努力的方向；“邪”法未必真邪， 這是“中國式管理”的需要。問題在於，以“邪”治“邪”多了，從短期來看是糊弄得過去，但從長期來看會陷入無序，市場發展也會碰到瓶頸。

#億舟語錄#之19：IT服務外包商在甲方客戶處試圖實施一個規範ITIL流程時，經常碰到這樣的回答：你們別給我整這麼多花裏胡哨的，把服務做好就行了。可見，對於IT服務外包商來說，首先要做的是把自己打造成“音樂家”，其次是要把客戶培養成“知音”，如此才能“琴瑟和諧”！

#億舟語錄#之 20：IT人員眼中業務部門有“五宗罪”：IT部門做了100件好事記不住，做了1件錯事記得很清楚；認爲“只有業務部門想不到的，沒有IT部門做不到 的”；寧可浪費IT部門1個小時也不願意浪費自己5分鐘；認爲流程是IT部門自己的事與自己無關；認爲IT部門花了很多錢，卻總是做不好事。

#億舟語錄#之21：業務人員眼中IT部門有“七宗罪”：花錢而不賺錢；態度生硬、冷淡、缺乏服務意識；沒有明確的承諾，總是說“我儘快”、“我盡力”；自以爲技術可以打天下，偏好技術，不懂業務還很“牛”；頭痛醫頭，腳痛醫腳；辦事虎頭蛇尾，“愛踢球”；加班還浪費電費。

#億舟語錄#之 22：國內有些IT經理告訴我，他們不得不故意“掐斷”網絡來證明他們存在的價值，否則業務部門和領導就會忘了他們的存在。這絕對是搞IT維護的悲劇！這 種狀況表明，業務和管理層對於如何評價IT部門的價值是存在“價值觀分裂”的：既要網絡永不斷線，又不能看到我們閒着，而這本身就是矛盾的。

#億舟語錄#之23：作爲組織內部的IT部門，應當將業務部門視爲我們的客戶，客戶就是我們的上帝，但我們需要學會爲上帝立法！

#億舟語錄#之24：對於組織內部的IT部門來說，其定位應是雙重的：服務+管理。光有服務意識強調服務職能還不行，還必須要通過建立一定的管理體系（話語權）對客戶加以管理。過分地順從和“溺愛”用戶是一種“不作爲”的表現，最終來看，業務和領導不會因爲這點而高看IT部門。

#億舟語錄#之25：管理可以分爲三種境界：“術”、“略”、“道”。“術”是操作層面的，“略”是方法論層面的，而“道”則是思想理念層面的。

#億舟語錄#之26：對於所有的技術專家來說，如何才能成功地轉型爲一位勝任的管理者呢？我的建議是，技術型管理者除了需要積累“術”方面的經驗和功底之外，還應該多吸取一些“略”（方法論）方面的知識素養，在運用“略”的過程中實現“道”（理念和智慧）的修煉。

#億舟語錄#之27：如果說“術”是劍法，那麼“略”就是心法，“道”則是“內功”。一位成功的IT管理者，應當加強IT管理理論方面的修養，並在此基礎上結合自身的經驗去推動實踐的運用，並在此基礎上修煉自己的“道”。

#億舟語錄#之28：在進行管理體系設計時，我們必須基於以下對“人”的假設：自私、惰性、慣性、忘性、易疲勞、情緒化。簡單來說，在進行制度和流程設計階段我們要假設人是不可被相信的，而在制度和流程執行階段，我們又要假設人是可以被信任的。這是辨證的統一。

#億舟語錄#之 29：對於所有的管理者來說，都會面臨兩類因素：一類是可管理、可量化、可控制的因素；另一類是不可管理、不可量化、不可控制、不值得量化控制的因素。對 於前者，管理者應該儘可能採用制度化的管理手段，而對於後者需要通過建立組織文化來加以調節。組織文化是制度化管理不可缺少的補充。

#億舟語錄#之30：制度產生的是一種外驅力，具有立竿見影的效果，但制度必然會有照不到的暗角，從而導致“上有政策、下有對策”；文化是一種內驅力，一旦形成，具有很有的持久性和***性。對於IT服務組織而言，進行服務和流程文化建設是不可或缺的。

#億舟語錄#之31：對於所有的管理者來說，進行組織文化的建設絕不是一種盲目的“趕時髦、隨大流”的行爲，組織文化的建設是對制度建設的有效補充。通過組織文化的建設來彌補制度建設“鞭長莫及”的地方，不僅能夠降低管理成本，而且能起到更好的效果。

#億舟語錄#之 32：我認爲西方式的管理科學遵循兩個基本邏輯：第一，“好記性不如爛筆頭”。西方式管理強調文檔、計劃、記錄的重要性，他們認爲，“按照我所寫的（計 劃、制度）去做、按照你做的去寫（記錄）”是達到“可管理”狀態的前提。第二，“用多拍幾次腦袋代替拍一次腦袋”，儘可能精細化。

#億舟語錄#之33：一般來說，我們追求精細化管理，但在某個局部或者某個時間點上，我們未必需要追求絕對的精確化的管理，因爲管理本身也是有成本的，不能把管理精細化的理念教條化。

#億舟語錄#之34：技術型人才的通常具有以下特點：具有強烈的技術情結；追求完美而無法忍受不確定性；過分關注小概率事件而不能從整體上考慮問題。當你和技術型人員討論管理問題而無法達成一致時，給他們不斷地灌輸“以偏差代替無序”的思想。
#億舟語錄#之35：做管理和做技術本質上是不一樣的，技術需要追求精確化，而管理只需要追求精細化。對於技術型人才向管理者轉型時，通常不可避免會經歷一段“思維衝突”的痛苦期和“自我洗腦”的思維轉換期。

#億舟語錄#之36：從技術專家向管理者轉型的五項基本修煉：習慣“以偏差代替無序”的管理智慧；“結構化思維、形象化表達”的文檔能力；從證明自身的多能到證明自己的“無能”；從自身的完美執行到容忍下屬的不完美執行；從管物到管人的轉變：以人爲本。

#億舟語錄#之 37：對於技術專家來說，一定要找到一個“萬無一失”的解決方案纔算是可行，而對於諮詢顧問來說，一個好的管理方案也許只能解決95%的問題，另外5%只能留給“上帝”（或時間）去解決，這也是“以偏差代替無序”的管理智慧的運用。

#億舟語錄#之 38：ITSP應深入理解並與甲方達成以下IT服務質量觀：（1）質量應具有持續性和一致性（Consistent）；（2）質量具有互動性：即質量是由甲方和乙方共同決定的；（3）質量具有相對性： IT服務質量是相對於SLA而言；（4）過程質量決定結果質量。

#億舟語錄#之 39：IT服務的無形性、不可封裝性以及客戶交互性決定了要提高服務質量，必須要建立良好的流程體系，而不能單純地依靠對服務結果質量的定義，即必須通過提高過程質量來保證結果質量。

#億舟語錄#之40：“劉氏新木桶原理”：一個木桶所能裝的水不僅僅取決於最短的那塊板，更重要的是取決於板和板之間的縫隙。

#億舟語錄#之 41：新木桶原理對於IT服務管理的啓示在於，僅僅關注IT服務人員個人的技術水平是不夠的，如何確保IT服務團隊之間無縫溝通和協作是非常關鍵的。從這個意義上來說，流程的價值在於有效地彌補了團隊成員之間的“縫隙”。

#億舟語錄#之42：一羣一流的工程師到了二流的企業，只能做出二流的服務，而一羣二流的工程師到了一流的企業，卻能做出一流的服務。一流的企業一定是建立了有效的管理體系來實現1+1＞2的效果。

#億舟語錄#之43：逆行超車是爲了節省自己的時間，車流量小的時候通常是可以的，一旦車流量大，就會造成堵車，這樣不僅不能節省自己的時間，還會浪費所有人的時間。不遵守既定的流程，也是這個道理。

#億舟語錄#之44：關於服務型團隊協作的啓示：團隊協作需要規則；團隊協作需要遵守規則；大規模、複雜的服務型項目更需要團隊擁有並遵守共同的規則。

#億舟語錄#之 45：流程經理們最感到無奈的是：流程的執行者以其“不主動、不拒絕、不負責”的消極態度勉強應付着執行了流程，結果是可想而知的。而流程的執行者往往用這種“壞”的結果來向流程經理們“示威”：“我說在這裏流程管理行不通吧？”。

#億舟語錄#之46：流程執行的質量會影響流程管理的效果，而流程管理的效果會強烈地影響整個團隊對流程的認同，而流程執行的質量本身又取決於團隊成員對流程的認同。於是，流程的推行往往會陷入“雞生蛋、蛋生雞”的悖論。因此，高層領導的支持是推行流程管理最強有力的支撐。

#億舟語錄#之47：在管理實踐中，很多管理者往往習慣於採用以結果爲導向的管理方式，而忽視流程規範。他們通常認爲，採用流程化的管理方式把本來很簡單的事情搞複雜了。事實上，對於管理方式的選擇，並不能依賴於管理者自身的認識，而應當取決於管理對象本身的特徵。

#億舟語錄#之48：如果管理對象滿足以下四個條件，我們必須加強流程管理：1、無法直接通過結果約束到行爲；2、從結果進行考覈效果不佳或者結果測量（或測評）的成本太高；3、過程比較複雜、需要團隊協作，且無法準確而方便地分解；4、可接受風險水平較低。

#億舟語錄#之49：關於流程的另類定義：流程是團隊的遊戲規則；流程是一堆人做事的協作機制；流程是一種預先設定的默契；流程是一種信息溝通機制；流程是一種執行力保障機制。

#億舟語錄#之50：流程管理的本質就是：用過程管理結果，用流程驅動人。這應當成爲流程管理者的信仰，並儘可能成爲整個團隊的信仰！

#億舟語錄#之 51：很多人的潛意識中通常會默認一點，那就是流程重組後一定可以提高效率。而很多IT管理者在ITSM項目初期爲了減少阻力，也會做出類似的暗示或者許 諾。而在新的流程推行之後很多人感覺“把簡單的事情搞複雜了”，通常他們又會以新的流程導致效率下降而拒絕執行。事實上這是一個很大的誤區！

#億舟語錄#之 52：流程管理的目標是多元的，這些目標包括：效率、成本、質量、風險、合規性、客戶體驗等。也就是說，效率並不是流程管理追求的唯一的目標。而當流程的 執行者單純從效率或局部的視角來看時，流程必然是有缺陷的。因此，不能因爲流程降低了效率就認爲流程是不好的就可以拒絕執行。

#億舟語錄#之53：即便是“絕對好的”流程從局部來看也未必一定可以提高效率，這取決於在這個局部的點上流程管理需要實現的首要目標是什麼。因此，在推行ITSM項目時，有效管理各方在“效率”方面的期望是非常關鍵的。

#億舟語錄#之54：流程管理的要義在於：“不惜犧牲效率來保證質量、風險、合規等要求”、“不惜犧牲局部的靈活性來保證整體的統一性”、“不惜犧牲個人的效率來保證團隊的效率”、“不惜犧牲當前的效率來保證長遠的效率”。

#億舟語錄#之55：流程就是例行公事，“不怕一萬，只怕萬一”。因此，對於關鍵的操作，遵循既定的流程就是要犧牲9999次的效率來杜絕最後1次可能帶來的風險。IT運維工程師們如果有這個認識，流程管理推行的難度將降低很多。

#億舟語錄#之 56：每個IT工程師都好比是一顆珍珠，而有效的流程就好比是一根華麗的繩子，可以將單個的珍珠串成珍珠項鍊，缺少了這根繩子，就只能是一盤散沙。

#億舟語錄#之57：流程建設的關鍵在於要在組織內培育流程文化。流程文化的核心在於，組織所有成員都能認可並不折不扣地執行既定的流程，而不是在自以爲流程不合理的地方“自作聰明”地繞着流程走。

#億舟語錄#之58：推動流程文化形成的關鍵在於四點：1、高層認可並親自推動；2、宣貫、宣貫、再宣貫！3、將流程執行情況與績效考覈掛鉤；4、絕不姑息所謂的“善意”的流程違規者，並懲罰惡意的違規者。

#億舟語錄#之59：不同的崗位關注的焦點肯定是不一樣的，因此流程管理得以有效推行的基礎在於流程設計時需要充分考慮多方面的訴求，並在流程設計階段儘可能讓所有關鍵利益相關者參與討論並相互“吵架”，事先達成妥協和一致。

#億舟語錄#之 60：很多人都存在這樣的“人格分裂”：開車的時候討厭別人亂穿馬路，而不開車的時候又隨意亂穿馬路。在整個團隊缺少超脫的認同感和公共理性的情況下，流 程機制很難推行下去。用局部利益代替公共理性的結果就是：大家不願意爲了整體利益最大化而做出妥協，從而最終導致“囚徒的困境”。

#億舟語錄#之61：執行力= 領導力（目標明確+質量要求+資源保障+執行力機制+組織文化）+被領導力（理解認同+合作精神+必備技能）。一句話，執行力不完全取決於被領導力，同時也取決於領導力。當我們要求下屬的執行力時，先自檢自身的領導力。

#億舟語錄#之62：流程設計時需要遵守的八項基本原則：可定義、可複製、可理解、可執行、可計量、可改進、可追溯、可審計。

#億舟語錄#之63：“劉氏IT服務成熟度模型”：對於大部分的甲方內部IT運維部門來說，可以參照以下五個級別的成熟度去評估和規劃其IT服務管理髮展路徑：1、無序的被動服務；2、有序的被動服務；3、主動的預防***；4、可預期可承諾的服務；5、可財務計量的服務。

#億舟語錄#之 64：就IT服務管理而言，從用戶滿意度的角度來看，充分認識到以下三點是至關重要的：1、用戶沒有義務判斷該找誰；2、用戶怕的不是等待，而是處理過程 完全不透明情況下的焦急的等待；3、用戶能夠容忍技術上有難度而需要耗時較多，但無法容忍故障的解決時間只有3分鐘，卻等了3天。

#億舟語錄#之 65：在流程建設中下定義是一件看上去簡單實則挺難的事情，定義不清則執行時會產生很多分歧。我推薦用用以下組合性的“下定義”的方法：1、描述法：通過 一段話概括性地對所要界定的“對象”進行描述性說明；2、列舉法：採用窮舉的方式進行舉例，列舉法又可以分爲正向列舉法和反向列舉法。

#億舟語錄#之 66：績效考覈的基礎是數據，而數據又可以分爲結果測量數據和過程統計數據，如果是一項績效考覈不能完全通過結果測量數據實現，那麼就需要進行過程數據的 採集。過程統計數據的採集，關鍵在於流程的設計，而流程設計的關鍵又在於表單的設計。表單設計直接決定了可獲得的過程統計數據。

#億舟語錄#之67：表單的設計需要遵循以下原則：1、標準化原則（儘可能做選擇題，實在不行，也應當給出填寫規範和模板）；2、從管理需求出發原則（每一個字段都對應着管理需求）；3、成本效益原則；4、可歸責原則；5、可執行原則。

#億舟語錄#之68：IT服務管理實施過程中會涉及各種分類，我總結的分類的基本原則是：1、從管理需求出發；2、完備性原則；3、互斥性原則；4、顆粒度適中原則；5、分層原則。

#億舟語錄#之69：ITSM與ITIL的關係：ITSM是目標，而ITIL只是手段之一。不能爲了實施ITIL而實施ITIL，實現卓越的IT服務管理，需要IT管理者在人、流程、技術三方面設計可執行的管理體系方案，否則，不會取得好的效果。

#億舟語錄#之70：I IT服務管理的“六脈神劍”：1、團隊思想統一；2、領導重視與參與；3、流程量身定做；4、執行量化考覈；5、適當選用平臺；6、持續改進優化。

#億舟語錄#之 71：ITIL中明確區分了用戶（User）和客戶（Customer）的區別，其中用戶是指IT服務的最終使用者，而客戶是指爲服務付費的組織或者人， 用戶提出的只是其個人角度的要求，而客戶則要代表某個用戶羣體的有效需求。同一個組織或部門作爲“客戶”代表的只能有一個，而用戶則可以有很多個。

#億舟語錄#之72：項目實踐中，我們經常被迫跟着用戶的“要求”而不是客戶的“需求”在交付項目（產品或服務）。控制項目的風險關鍵在於區分誰是客戶、誰是用戶。遵照“客戶”的需求、而不是聽從“用戶”的要求是項目經理需要掌握的第一要領。

#億舟語錄#之 73：從流程管理的角度來看，我們認爲用戶提出的是請求（request），而客戶提出的是需求（Requirement）。ITIL V2服務支持（Service Support）流程組主要面向用戶，負責受理用戶的請求；而服務交付（Service Delivery）流程組主要是面向客戶，負責管理客戶的需求。

#億舟語錄#之 74：七句話幫你理解ITIL：ITIL是一套流程管理最佳實踐指南；ITIL是一套IT服務質量控制體系；ITIL是一套IT服務風險控制體 系；ITIL是IT服務專業人士的“五線譜”；ITIL是IT服務管理者進行“流程架構設計的腳本”；ITIL是IT服務工程師的“通用語法”；ITIL 是IT服務領域的國際“工業標準”。

#億舟語錄#之75：ITIL就是衆多方法論中的一種，理論上來說，它適用於各種IT服務組織。但當我們在具體實踐時，就會碰到很多現實的困難。在實施ITIL時，需要根據組織的規模、人員結構、用戶成熟度、IT管理目標等要素做出適當的裁剪。

#億舟語錄#之77：ITIL V2的六大核心模塊，用打麻將的說法就是：“東風”（ICT基礎架構管理）、“南風”（應用管理）、“西風”（業務視角）、“北風”（服務管理實施規劃）、“紅中”（服務管理）、“發財”（安全管理）。

#億舟語錄#之 78：ITIL V2倡導的流程管理最佳實踐消除了“職能式”管理模式下的職能“豎井”，促進了部門之間的流程化運作。但隨着ITIL V2的深入運用，人們逐漸發現，基於ITIL V2的流程實踐又產生了新的流程“豎井”，即流程與流程之間缺乏一套有效的核心邏輯來進行整合，ITIL V3彌補了這一缺陷。

#億舟語錄#之 79：如果說ITIL V2幫助我們實現了Managed Service，那麼ITIL V3則有助於我們實現Designed Service。Managed Service意味着服務的交付是基於某一套標準的流程體系，如ITIL、ISO200000；而Designed Service意味着相比於Managed Service而言，更加註重強調圍繞客戶需求設計服務。

#億舟語錄#之 80：ITIL只不過是一個最佳實踐的“工具箱”，IT組織完全可以根據自身的實際需要挑選必要和合適的流程進行實施。對於中國用戶來說，我們通常推薦從 梳理事件管理和變更管理流程入手，這樣可以快速地將組織從無序的被動維護轉變爲有序的被動維護。然後在此基礎上擴展其他流程。

#億舟語錄#之81：ITIL實施的七大誤區：1、ITSM＝ITIL；2、實施ITIL＝實施所有的ITIL流程；3、全自動全集成纔是最好的；4、當成一個IT部門內部的項目而不是作爲公司層面的業務流程重組，未能爭取到高層領導的支持，在IT部門內部“自娛自樂”；
#億舟語錄#之81（續）：ITIL實施的七大誤區：5、忽略人的因素，相信“技術可以固化流程從而帶來執行力”；6、項目野心勃勃，不能“沿途下蛋”；7、默認流程一定可以提高效率，所以當流程局部地導致效率下降時，就會遭遇抵制，從而使辛辛苦苦建立的流程毀於一旦。

#億舟語錄#之 82：ITIL實施落地可以從三個方面進行：1、理念落地（將ITIL理念融入日常行爲）；2、規則落地（制定制度性規範）；3、工具落地（將ITIL的 流程邏輯固化在軟件平臺上）。ITIL本身只是一套管理體系框架，並不是軟件架構設計的腳本。因此，未必所有的ITIL流程都能夠或都需要通過軟件落地。

#億舟語錄#之83：ITIL軟件實施的本質是實現IT部門的信息化。但ITIL軟件實施絕對不是一個“交鑰匙”工程，而是一個“技術+管理”的綜合性解決方案。光有技術平臺，缺少了配套的規則定義、角色定義、人員培訓、審計監督和績效考覈，ITIL軟件基本上無法用起來。

#億舟語錄#之84：什麼叫解決方案？理論界和實踐領域都沒有確切的定義，就IT服務管理軟件實施而言，我的理解是：解決方案= 軟件平臺+實施方案+配套的管理規則+培訓與推廣方案。

#億舟語錄#之85：針對ITIL V3在國內的實施，我有如下建議：1、帶着ITIL V3的視角去實施ITIL V2；2、一次規劃、分步實施；3、按需取用，無需追求大而全；4、不要過份依賴工具、加強配套的管理規則與人員意識培訓；5、爭取高層領導的支持。

#億舟語錄#之86：科學有效的ITSM項目實施過程必須至少包括以下六個環節：理念導入、現狀評估、流程設計、工具實施、上線推廣、持續改進。

#億舟語錄#之87：ITIL所引入的分級支持體系，相當於將IT組織從原來單純“橫向分工”（按職能分工）轉變成“縱向分工”（按“流水線”分工）和橫向分工相結合的矩陣式架構，即避免了“用大炮去打蚊子”的資源浪費，也保證了統一的跟蹤和監控。

#億舟語錄#之 88：針對IT服務的管理，我們至少應設立四種角色分別從四個維度進行管理：1、Product Manager（管理產品生命週期）；2、Process Manager（管理流程的運營效率和效果）；3、Account Manager（管理客戶的需求以及相應的SLA）；4、System Manager（從技術的角度對IT組件進行技術維護）。

#億舟語錄#之89：職能（Function）是流程（Process）有效運行的重要保證基礎，它爲流程的流轉提供必要的支持。區分流程和職能有一個非常便捷的方式，即職能通常可以在組織架構內找到對應的人員或者部門，而流程通常需要跨團隊或者跨部門運作。

#億舟語錄#之 90：按照ITIL V3的理論，實現優秀的IT服務管理需要“能力”和“資源”兩個關鍵要素。中國有句諺語叫做“巧婦難爲無米之炊”，在這裏，“米”屬於“資源”，而“巧 婦”具備的是一種“能力”。沒有米，巧婦很難做出香噴噴的米飯，而光有米，而缺少了巧婦，同樣做不出香噴噴的米飯。

#億舟語錄#之 91：服務檯運作模式的實質在於：1、知識前移和運維前移；2、將傳統的橫向分工拓展爲縱向分工和橫向分工相結合的模式；3、服務檯作爲一線支持實現了雲 服務；4、將原來“既當爹又當媽”的工程師從瑣碎的溝通性工作中解脫出來專注於技術的處理；5、通過改變用戶習慣而提高總體效率。

#億舟語錄#之92：典型的服務檯結構有三種：集中式、分佈式和虛擬式。在選擇服務結構時需要考慮以下幾個因素：1、最終用戶的地域分佈；2、各地用戶請求的數量3、各地應用的同質性；4、服務檯人力資源情況；5、語言和工作時段等個性化需求。

#億舟語錄#之 93：適宜建立服務檯的基礎條件：1、相對海量的終端用戶（500人以上）；2、相對海量的故障請求和服務請求（日均100單以上）；3、用戶地理位置較 爲分散；4、用戶請求同質性、重複性較高；5、經常出現丟單、串單等缺乏跟蹤的情形；6、用戶找不到正確的人，經常遭遇“踢球”的情形。

#億舟語錄#之94：服務檯推廣初期很容易出現用戶繞過服務檯的情形，我推薦以下解決辦法：1、多途徑立體式宣傳；2、改善服務檯的專業形象和服務意識；3、提高服務檯解決故障的能力；4、基於服務檯登記的工單對工程師進行考覈；5、對用戶進行培訓和期望管理。

#億舟語錄#之 95：在ITIL V2中，服務請求被當作一類特殊的故障（Incident）而通過故障管理流程進行處理。而在ITIL V3中，服務請求通過請求履行流程單獨進行處理。區分服務請求與故障有一個很簡便的判定原則，即故障通常是一個意外的事件，而服務請求常常是能夠事先定義 其操作路徑和步驟的。

#億舟語錄#之96：有效地實施故障管理和服務請求履行流程，能夠將IT組織的IT服務從“無序的被動維護”提升至“有序的被動維護”，但仍然沒有實現“預防性的主動維護”，問題管理和配置管理的引入有助於實現這個目標。

#億舟語錄#之 97：ITIL流程成功實施需要抓住7個關鍵點：1、表單設計（決定能獲取的信息）；2、角色定義與映射（決定流程的執行力）；3、判據規則（分類的判斷 依據）；4、輸入定義（觸發條件及規格要求）；5、輸出定義（KPI指標及規格要求）；6、工具實施（標準化、模板化、電子化）；7、培訓與推廣。

#億舟語錄#之98：表單是支撐流程有效運轉起來的前提。表單設計的基本原則是：“能做選擇題，就不要做填空題；能做填空題就不要做論述題；實在萬不得已必須做論述題時，也應當定義論述題答案的模版和答題規範”。這樣可以確保表單記錄的標準化，並可增強表單的可統計性以及執行力。

#億舟語錄#之 99：故障管理在實踐中最常見的問題有兩個：不填單或者填寫不符合要求（如在“解決方案”一欄中填寫“已解決”敷衍了事）。這兩個問題都無法通過軟件來解 決，而必須輔之以管理手段。針對前者，需要明確定義故障的範圍並納入績效考覈；針對後者，需要制定細化的故障單填寫規範同時加強審計。

#億舟語錄#之100：在實際工作中，很多人經常將“故障”與“問題”這兩個概念混淆。事實上，故障和問題是看待同一件“事情”的兩個不同的視角：故障是從“治標”的角度進行處理，確保“當前的”業務影響最小化，而問題則是從“治本”的角度進行處理，確保“長遠的”業務影響最小化。

#億舟語錄#之 101：問題管理實施成功的關鍵在於解決好問題單的提交和創建。解決的辦法有兩個：1、通過在故障管理流程中設定一系列的規則（“六個凡是”）而觸發問題 分析線索；2、通過設立“問題主動排查率”指標對問題經理強化考覈，而促進主動性問題管理（“四個基於”）機制發揮作用。

#億舟語錄#之 102：知識庫的構建和運營過程中必須要解決好以下三個問題：1、錄入者和使用者的積極性問題；2、知識庫搜索效率和定位準確性問題；3、知識庫的及時更 新和質量保證問題。由於這三個問題沒有有效地解決，很多IT知識庫都經歷了這樣一個過程：積累期、推廣期、享受期、苦惱期、頹廢期、廢止期。

#億舟語錄#之 103：變更管理、資產與配置管理以及發佈與部署管理之間形成的是一個“鐵三角”關係。這三者的關係有點類似於財務經理、出納和會計這三個角色之間的關 系：變更經理（相當於財務經理）負責“權”，發佈與部署管理（相當於出納）負責“錢”，而資產與配置管理（相當於會計）負責“賬”。

#億舟語錄#之 104：充分理解變更管理和發佈管理的界限，有助於劃分開發團隊和維護團隊之間的職責劃分。從邏輯上來講，IT生產環境的Owner應該是負責維護的團隊 （開發部門也可能有維護團隊），也就是說，對IT生產環境的變更控制應該由維護團隊主導，而開發團隊應當是充當發佈實施的角色。

#億舟語錄#之105：變更管理是IT生產環境的“海關”，其使命在於確保IT生產環境的變更沒有“偷渡者”和“走私犯”。有些開發團隊或者開發人員，在沒有通過變更流程的情況下對生產環境所做的各種操作其實就是一種“偷渡”行爲。

#億舟語錄#之 106：有些公司在實施變更管理和發佈管理時，將兩者視爲並行的兩個流程，即變更管理負責處理基礎架構硬件的變更，而發佈管理則負責處理軟件相關的變更。 從ITIL的角度來看，這是一種誤解。變更管理側重於審批、控制和協調，而發佈管理側重於實施和部署，發佈管理應處於變更管理的控制之下。

#億舟語錄#之 107：發佈的實施過程本質上是一個項目實施過程，因此對於大型的發佈實施項目，運用項目管理的方法是可行的。ITIL的發佈管理的核心目標是對發佈實施 過程進行標準化和規範化控制，以確保每一個發佈都遵循了標準的流程規範、實現了全面而順暢的溝通、保持了良好的書面文檔記錄。

#億舟語錄#之108：由於每一個發佈在規模、時間跨度、複雜度、測試要求、影響範圍等方面都存在差異，因此，很難實施一套標準化的流程平臺跟蹤和管理不同類型的發佈。因此，發佈管理在實施落地時，通常並不單獨實施一套軟件平臺，而是與變更管理結合起來實施。

#億舟語錄#之109：發佈與部署管理在實施中通常通過以下兩種方式落地：1、制定保障發佈實施的制度性規範，以確保發佈執行過程遵循標準的程序並維持必要的文檔記錄；2、在變更管理軟件平臺中創建一系列的任務項（Task）以跟蹤和控制發佈任務的執行。

#億舟語錄#之 110：CMDB是IT部門的“技術地圖”，有效運作的CMDB可以實現幾方面的價值：1、實現快速的故障診斷；2、準確地評估變更的影響；3、削弱人員 流動給IT運維所帶來的風險；4、通過建立有效的IT資產臺帳提高年度資產審計的效率；5、爲實現主動性、預防性維護提供基礎。

#億舟語錄#之111：在進行CMDB建設時，識別CI的基本原則應包括：1、從管理需求出發；2、顆粒度適中原則；3、可維護、可更新、可操作、可管理、可審計原則；4、“適當超前、夠用就好”原則；5、成本效益原則。

#億舟語錄#之 112：CMDB實施諮詢的核心是“六定”：1、定目標（CMDB要實現的管理目標）；2、定範圍（納入管控的IT資產的範圍）；3、定顆粒度（納入管控 的IT資產的顆粒度大小）；4、定屬性（各種CI類別對應的屬性字段）；5、定關係（CI之間的關係類型及含義）；6、定流程規範（維護規範、角色與職 責）。

#億舟語錄#之113：對於CMDB的建設來說，“超前三年是前瞻、超前五年是找死、超前八年是犯罪”。過份超前有時候反而使項目陷入“植物人”狀態。結合組織的需求、人員成熟度、組織文化做出適當超前的規劃是保障CMDB項目成功的關鍵。

#億舟語錄#之 114：如何確保CMDB保持更新是確保CMDB項目最終成功的關鍵。要保證CMDB更新，全部依賴自動化工具是不可能的。通常可以採納三種手段：1、自 動掃描工具；2、由變更管理觸發《配置修改通知單》；3、在變更關閉之前點擊“更新CMDB”按鈕，將CMDB數據調出並直接由變更審實施人員修改。

#億舟語錄#之115：沒有納入變更控制的CMDB，就好比失去了財務控制的會計覈算，這樣的財務覈算數據你敢相信嗎？CMDB需要更新的源頭在於變更，因此，無論採用哪種更新機制，CMDB都必須納入變更控制。

#億舟語錄#之 116：服務級別管理過程應該涵蓋以下六個階段：1、需求識別與確認；2、服務設計與簽約；3、服務實施與交付；4、服務響應與支持；5、服務計量與報 告；6、服務評審與改進。僅就響應時間、解決時間等指標進行了約定並不能視爲實施了服務級別管理，服務級別管理應是一個服務生命週期的概念。

#億舟語錄#之 117：服務級別管理在落地實施時，難點有四個：1、標的物（即服務內容）的定義和識別（結合服務目錄梳理進行）；2、客戶的識別（誰能代表服務的甲 方）；3、服務級別的約定（可以用絕對數和相對數相結合、定性和定量相結合的辦法）；4、SLA如何分解爲OLA和SLA（關鍵在於建立關聯）。

#億舟語錄#之118：實踐中，很多組織的SLA對於服務內容和範圍的約定相當模糊。從而經常導致實際服務交付範圍失控。服務內容和服務範圍的約定可以採用描述法和列舉法（包括正向列舉和反向列舉）相結合的方法。同時，需要針對服務範圍的變更建立變更管理機制。

#億舟語錄#之119：IT服務財務管理體系由以下五大體系構成：1、IT財務預算管理體系；2、IT服務成本覈算體系；3、IT服務計費體系；4、IT服務財務報表體系；5、基於平衡計分卡的IT服務績效評價體系。

#億舟語錄#之120：IT服務預算制定的基本原則：1、以量定額；2、子項彙總；3、全面細化；4、口徑一致。

#億舟語錄#之121：IT服務預算科目體系設計應遵循的基本原則：1、從管理需求出發；2、2、顆粒度適中；3、成本效益原則；4、與IT成本覈算相匹配。