IT服務管理的指揮與智慧
在當今動盪不寧、不斷變化的 IT 環境中，IT服務管理（ITSM）的重要性不言而喻，它通過保證關鍵業務系統和服務的可用性和可靠性，爲整個企業提供至關重要的支持。隨着技術變得越來越複雜，解決問題也越來越耗時，對技能的要求不斷提高，維持優質服務的成本不斷上升。面對緊張的預算和有限的資源，優先級處理、響應能力和標準明確的工作流程對於最大限度地提高業務關鍵 IT 服務的可用性至關重要。
有時候我們常常在問：“爲什麼在標準化管理中，IT服務和產品中‘個性化’的詞彙會更加吸引人？而又爲了什麼在企業的IT服務管理中要把各種煩惱的事情都要提前解決，不再四處奔波？是要顯得我們的工作更加有價值，還是我們的肢體已經懶惰了，更依靠人腦和電腦的智慧？”但願我的這篇閒扯的blog是一絲清風，爲君解憂。
創業難 守業更難
從歷史到今天，從IT到建築，從餐飲到航空，從回顧歷史到探索未來，每一個領域都離不開“管理”。在遙遠的異域傳說中，人類的始祖亞當，最初就是伊甸園的管理者，也是人類的第一個管理者。他曾經那樣天真無邪，但自從他和他的女人一起吃了是非果之後，情況就開始變得不妙。有是非就有分歧，有分歧就有辯論，有辯論就有戰爭，有戰爭就有慾望，有慾望就有痛苦。
我們在應對一個企業網絡架構建設階段，更多的是一個“臨摹者”而非創造者，也就是說很多的技術方案可以支持你創建一個網絡從籌備到完工驗收。而當我們把網絡交付給用戶之後，兩種人的分歧就從來沒有消停過。以下 用戶因爲網絡緩慢而大發牢騷？
這些矛盾你可能都遇到過：
- 業務部門因爲服務器出現故障而指責IT部門不負責任？
- 新版本的報表軟件更新，遭到90%以上的員工投訴設計繁瑣？
- 永遠無法先行一步預防故障的發生，被別人和自己封爲“救火員”？
- 爲什麼IT服務部門的預算總是相對較高，遭到公司高層的白眼？
- 業務系統平穩無礙，又遭人妒忌，淪落爲企業最清閒的部門？
- 是否被其它部門利用，IT部門做了許多不必要的工作？
- ……
一切的分歧和矛盾是我們造成的嗎？爲什麼在信息化平臺已經運轉起來之後，這些問題都將逐個得冒了出來呢？我只能說：“因爲管理不到位！”IT管理的課題與領域相當之大，，在之前，由於我們也沒有可以參考的資料指導，所以只能摸着石頭過河。我曾經向一些同行調查他們的工作情況，我想只有我們這些人說出“真心話”才反映出了企業IT管理中的諸多難題。真心話的共同點就是：網絡建設中的技術已經無法滿足我們針對服務進行管理的要求。
企業網絡在對多種主機平臺、多種設備的管理維護時需要我們掌握所有平臺的維護法則，但我們不可能做到這一點。所以，企業必然要投入擁有其他幾項技術知識的管理維護人員，即使這樣，我們也無法同時對分散的主機、網絡設備、數據庫、業務系統性能進行統一的監控管理。業務結構不斷變化的本性造成系統的複雜性不斷增加，你不再能控制一個內部軟件系統，就像你不能控制氣候的變化一樣。另外，儘管我帶領的IT部門已經是一個很艱難的部門了，但是IT技術的發展，如雲計算、虛擬化等還將使管理變得更復雜。雖然我們自己也意識到在整個公司發展的過程中，特別是公司越來越習慣於IT服務的時候，客戶對於IT服務的期望值就會越來越高，IT部門所提供的服務也必須逐漸地有所提高。但對於有些IT部門來講，如果說對於需求的反映不及時，或者說服務質量不能夠快速提高，或者成本不能夠降低下來，就會成爲“破鼓萬人捶”的對象。
當然，已經有一些人已經籌措了整套的想法，但管理手段（一個電話或一封郵件）和工具落後，導致很多問題反覆出現：管理人員無法預測將要發生的故障，有時不能及時發現故障，運營維護人員整天忙於“救火”，“救火後”仍然沒有增加任何“消防知識”，同樣的故障反覆出現，都將促使“離職”事件的發生。
長期來看，作爲CIO，我也面臨着一個迫在眉睫的選擇。當前，外包的趨勢雖然在持續發展，但從以下兩方面來看，IT部門依然有生存空間：一是肯定還會有一些系統會由企業內部的IT部門來運作；其二，我擔心由於那些沒有很好採用外包的系統，將會遭受到系統失敗的結果，也將不得不改由自己的IT部門來做。作爲技術人員，近10年來我們可能嘗試了近百個網管軟件。但作爲管理者來說，將網絡監控技術運用的如火純青，仍然改變不了IT部門地位低下的現狀。當然，這不說“原生類”的IT技術不重要，由於採用的網絡管理及與設備管理不能積累相關的客戶信息，不能指導業務提高效率，也就無法讓用戶滿意。缺乏主動性能分析，運營管理人員缺乏對網絡、主機系統全面的性能統計分析，即使今天用戶說“可以了”，明天我們還可能犯同樣的錯誤。因此，如果我們永遠停留在“網絡設備管理”這個層面的，正是這種虛假的“成功”會阻止我們做出變革。
由智慧的產品所聯想到的IT管理
目前，IBM提出了整合服務管理（Integrated Service Management，以下簡稱ISM），那麼ISM提出的是在一個什麼情景中誕生的呢？我們以中小企業爲例，是“服務檯”一體化解決方案爲核心的，通過此方案內置的問題解決工具，中間市場客戶可提高操作人員的生產效率，進而降低企業成本。服務檯工作人員可憑藉該功能提高其服務支持功能的效率。此外，強大的自助式門戶，涵蓋針對常見問題開箱即用的最佳實踐解答，最終用戶利用此門戶可快速自行解決問題，而不必求助他人。這個方案中的一個概念非常重要，就是“服務檯”。
而在ISM整個方案中，又包括了Tivoli Foundations Application Manager ，它是 “應用程序管理”一體化解決方案。在這個一體化的交付軟件包中，包含了IT環境中所有實施應用程序管理所必須的重要支撐，包括： IT 資產發現、網絡監控、服務器監控以及關鍵 IT 元素（數據庫、郵件服務器和虛擬服務器等）的監控。其中包括實時和歷史信息查看功能，可讓IT部門瞭解其 IT 環境當前和過去的運營情況並製作相關的智能報告，憑藉該功能瞭解全部網絡、服務器、中間件和應用程序組件的服務性能和運行狀況，並改善服務質量。根據我的理解，這應該是指得是IT運維中必不可少的“工具”。
當您駛離行車道時，您的手機和您的車載語音指揮系統自動同步，車輛會向家裏的報警系統發送信號以啓動報警系統。對您的行駛模式進行分析後，車載全球定位系統（GPS）會建議您改道，以便節省燃油成本並且避免交通堵塞。最後，車輛會通知您的防抱死制動系統需要檢修，並且會在您的個人數字助理（PDA）上檢查您的日程安排，然後爲您安排檢修時間……在IBM這位IT巨人提出“智慧的地球”之後，“智慧的產品”更爲我們闡述了一個理念或者一種可以應對未來變化思路有多重要，人類的歷史也許因爲一個概念而徹底改變。
因此，要深入瞭解IT服務管理（IT Service Management，簡稱ITSM）對於我們現在能做什麼，就需要深入瞭解這個概念是否已經變成事實，也就是它是否已經能夠幫我們解決問題。
ITSM這個詞，最早從20世紀60年代即被開始使用，但是直到80年代英國政府有關部門組織開發ITIL，且ITIL被廣泛使用之後，IT服務管理才得以成爲一個特定的詞彙。縱觀最近30年，ITSM和ITIL兩個詞可以說是“相互提攜、相伴成長”。正如其他所謂國際先進概念在中國的遭遇一樣，ITSM也經歷了非常曲折經歷才被國內同行所認知。十年之前，ITIL在中國當時僅是偶見諸報端，基本上也是無人理會，很多人包括我，也覺得這只是一個模糊概念上的炒作，並不會提高我的IT技能，也不會對我的職業發展有什麼大的幫助。時過境遷，經過國內數年的應用，大家逐漸認識到，ITSM確實一種“以流程爲中心、以客戶爲導向”的通用方法，也是一種改變企業信息化命運的良藥。
可能你現在就想細細品味ITIL的果實，不過還是讓我們要從一位電器集團的CIO的經歷開始吧（內容涉及個人隱私，爲化名）。這家電器集團如今擁有450個銷售網點和分支機構，向大約26個省市和14個國家提供產品銷售和服務支持。
陳磊（男，現年34歲）從這個集團的網絡建設開始，他以早期CCIE證書擁有者的背景進入這家集團，並獲得了信息網絡部經理的職位。隨着公司業務的不斷髮展和壯大，業務部門對IT技術和自動化系統的依賴越來越大，他們需要IT來支持處理大量交易數據和庫存配貨。然而，由於公司缺少一支有組織且結構化的一線IT支持服務團隊，各個省市的店面僱員在面對時而發生的IT故障和問題時變得越來越沮喪：他們不知道向誰尋求幫助，在四處求救時浪費了大量的寶貴時間；另外，對於那些重複發生的問題和服務故障，沒有一個現成的經驗和知識幫他們直接解決問題，使得陳磊的手下陷入一遍遍解決同類問題的僵局。當他們處理分店即時的銷售和庫存調用業務時，每筆業務銷售額的準確性和調貨的即時性對他們來說至關重要。業務部門迫切需要一種最快，最準確的方法來協助完成所有交易。然而，他們卻搞不清一旦發生客戶端、網絡和服務器故障時，他們應該打電話找誰來尋求幫助。甚至即使打了電話，問題也不能得到很好解決，影響業務的進行。但此時的陳磊已經疲憊不堪，隊伍也很消沉，因爲時常發生的故障問題導致所有人幾乎1年來就沒有節假日，這直接導致了這些業務部門的領導和IT團隊本身對陳磊開始出現信任危機：IT服務與我們業務部門不是同路人，他並不是一個值得信任的，擁有共同業務目標的好的合作伙伴。IT技術支持團隊錯誤的認爲陳磊只不過是一個技術上的狂人，而對於“管理”還是乳臭未乾的毛頭小子。
另尋出路的陳磊開始找“下家”，而也許就是上天的安排，他在HR網站上搜索職位的時候發現了“IT服務檯經理 （Help Desk）”這個職位。通過對這個職位需求的瞭解，以及各個媒體的報道，陳磊終於再次從技術的角度重新樹立了自己在管理上的改變。
提示：當時的IT服務檯經理職能與現在的工作區別很大，爲何這樣說呢？
當時，幫助臺與服務檯兩個術語在實際應用中通常可以交替使用的，IT人對於它的理解也基本相同，但兩者在概念和麪向對象上並不完全一樣。
（1）幫助臺的主要任務是記錄、解決和監控IT 服務運作過程中產生的問題，主要和事故管理相關聯。面向的用戶主要是IT 部門內部人員。
（2）服務檯的概念則具有更廣泛的內涵，它通過提供一個集中和專職的服務聯絡點促進了組織業務流程與服務管理基礎架構的集成。服務檯適用於作爲一個廣泛的，集中受理的前臺支持角色，而不僅僅是幫助臺。 服務檯不僅負責處理事故、問題和客戶的詢問，同時還爲其它活動和流程提供接口。這些活動和流程包括客戶變更請求、維護合同、服務級別管理、配置管理、可用性管理和持續性管理等。 面向的用戶主要是IT 系統的實際使用者。
服務檯，在IT服務支持中扮演着一個極其重要的角色。完整意義上的服務檯可以理解爲系統應用部門和服務流程的“前臺”，它可以在不需要聯繫特定技術人員的情況下處理大量的客戶請求。對陳磊所要建立的服務檯就如他的CCIE證書一樣，都是“交換機”和“路由器”的重新解釋。在碰到任何問題或疑問時，只需通知和聯繫服務檯的工作人員，再由服務檯的工作人員指導和協調下一步的處理工作。陳磊對於管理和服務概念上的改編是巨大的，那個這個看似路由器或者交換機的東西，爲他解決了什麼問題呢？
- 由於只有一個聯繫點，發生服務故障時，所有網點的業務人員可以直接與IT技術服務人員聯繫，避免了不知找誰來解決問題的情況發生，從而縮短了“遺失時間”。
- 服務檯人員對所有IT用戶提交的服務請求，故障和問題等進行記錄，這些記錄提供了一種發現IT基礎設施問題的機制。
- 爲IT管理提供一種可量化的評價機制來評估業務 ，同時業務人員也可以瞭解IT部門現在的工作狀態，雙向溝通都在服務檯上進行。IT服務檯將徹底促進IT與業務的溝通，改善業務對IT的認識 。
- 通過配置管理中的配置管理數據庫，處於單一聯繫點的IT服務人員可以掌握所有配置項信息，使其可以更有效果且更有效率的使用各種配置項資源。
- 當面對同時發生的大量突發事件時，服務檯提供了一種結構化的流程來安排工作優先級，影響度大且緊急的問題優先解決；同時，服務檯選擇最快的方式來恢復發生故障的IT服務。由於所有解決問題的方法都將被記錄在問題管理數據庫中，IT人員只要搜索一下該數據庫，就可獲得解決已發生過問題的解決方案，縮短了平均不可用時間。
- 對於更簡單的客戶端技術問題，普通用戶可以通過服務檯的搜索功能得到技術解答和修復。
針對最後一點，可能陳磊都沒有想到自己竟然成了“先知”，這與IBM 提出Tivoli Foundations Service Manager一體化解決方案非常接近：強大的自助式門戶，涵蓋針對常見問題開箱即用的最佳實踐解答，最終用戶利用此門戶可快速自行解決問題，而不必求助他人。圍繞服務檯改變IT現狀的結果是喜人的，陳磊實現了所有既定目標。通過使用新建成的基於ITIL的服務檯，客戶可以方便的記錄所有發生的突發事件，並對事件進行分類和報告，支持並解決這些突發事件和問題。這樣最終用戶可以將注意力集中在如何實現其業務目標，增加主營業務收入，已經產品服務和技術更新反饋上等等，而不是被突如其來的IT服務故障所累，而其IT服務部門也不必再被誤解，不斷的陷入客戶的抱怨和指責聲中。IT真正變成了一個強有力且有效的內部工作工具，支持業務需求，是每一個業務部門好的合作伙伴。
回顧陳磊在職業道路上的坎坷，這讓我們明白了一個IT人從技術人員如何躋身管理人員的道理。因爲對IT部門而言，一方面需要對涉及IT的事項進行管理，另一方面也需要爲其他部門提供IT服務。IT部門做這兩類事情的方法，分別叫做“IT管理方法”和“IT服務方法”。將這兩種方法用一個詞來概括，就叫做“IT服務管理”，即IT Service Management = IT Service + IT Management。
基於上述分析，我們很容易理解，首先這個ITSM本身沒有任何新意，其次我們沒有任何必要討論要不要IT服務管理，因此只要存在IT部門，就存在IT服務管理。只不過以前是隱性的，現在被顯性了而已。
成功推銷ITSM是關鍵
ITIL作爲IT管理實踐的最佳指南，它的光環幾乎吸引所有大型企業的IT管理團隊，高管們都希望能夠通過它改善和提高IT服務的水平。然而，不是人人都會獲得成功，當企業藉助ITIL標準化實施ITSM的時，面臨的挑戰真可謂“豐富之至”！
企業實施ITSM項目時，制訂正確步驟就要比烹製“河豚”，正確的烹製流程會使ITSM變得相當美味，而錯誤的“刀工”很有可能造成“服毒身亡”。
第一步，並不是要設計什麼模型，也不需要按照英國發明人建議的那樣先取得ISO 20000認證，因爲你可能在一個儒家管理盛行的中國式管理的年代，所以你要在身邊培養起來更多的“知音”纔是關鍵。在一家專門針對 CIO 或者 CTO的網站上，我幫助一家諮詢公司做個兩份調查，這是針對參加過ITSM的培訓的管理層而言的調查表。我發現他們有一個非常相似的矛盾心理狀態，這就是 ITSM如果實施起來的內容太多、困難太大，付出的人員成本也會增加，與現在的流程很難匹配。爲了在自己的組織和部門推銷ITSM ，受過培訓的領導們會組織參與運維的工作人員培訓，讓他們知道什麼是ITSM？ITSM包含什麼內容？怎樣做好運維？怎樣在已有的基礎上如何提高水平？但定製培訓內容和ITSM的推銷過程卻是困難的，運維工程師很難掌握 ITIL 的精髓並利用到實踐中去。因此，我們相信發佈一份貼近與IT維護人員報告會起到ITSM宣傳的作用，推廣ITSM就是讓更多的IT和非IT人員熟悉流程以及這種方法的優勢，這絕非是推廣一些ITSM產品所替代的。另外，由於我工作的關係，我也負責一些ITIL的課程，所以我建議在“推銷”ITIL的時候，遇到的一個挑戰就是要說服那些過去認爲ITIL只是一個時髦概念的人。逐漸地，你身邊越來越多的人將認識到ITIL的好處，但這的確是需要時間的考驗。
ITSM的四大關鍵因素
首先，我們將IT服務中的各個對象關聯起來，如下圖所示：
ITSM中四大重要的因素就是人員、流程、技術、信息（其中技術也特指爲：工具），而這四個因素和IT服務項目成功與否息息相關，如何對這四個關鍵因素進行最好的管理呢？
人腦和電腦的難題
實施了ITSM後，理清了流程，經驗文檔化，流程程序化，服務可度量，工作可監督。不再是“人”說了算，不再完全依賴某人的經驗，而是制度流程說了算，如果某人再要說了算，那也要等改了文檔後。因此，所有的管理都有據可依，那麼會不會有人再發出“以前是怎麼管”的感慨呢？人的價值在ITSM中是否減弱了呢？
回答是否定的。ITIL的應用過程中，人員相關的因素應該是首要考慮的因素。因爲ITIL的應用實際上是一個管理變革活動，特別依靠人的積極參與來完成。在變革過程中，由於可能涉及到人員的職能、利益、思維模式、工作方式等的轉換，產生的誤解、消極和阻力不容忽視。我們需要在對ITSM有清楚認識前提下，逐步建立ITSM流程化管理標準體系的過程中，充分讓ITSM更好的爲人服務，而不是讓人來爲ITSM服務。ITSM項目一旦完成，一切都將變得“死板”（很多人至今無法相信 ITSM項目成功就取決於這種“死板”的機制），需要所有人員做出配合流程變化的承諾，這也是人腦爲什麼先要統一原因。即使員工做出了承諾，但人腦在實施ITSM之後必然會出現不統一的狀況，這一結果必然是ITSM(電腦)系統中定義的流程偏離了人腦的預期。”
“殺雞用牛刀”的流程會遭遇頑強抵抗
ITSM是一種以流程爲導向，以客戶爲中心的方法，流程管理上基本包括流程層級、流程規則、角色權限級別等。舉例來說，某集團的產品銷售部的一臺終端出現無法上網的問題，調查後發現因爲主機原來進行過網卡更換處理，而原有在交換機上有配置了MAC地址綁定的功能。如果使用原來的ITSM系統流程，首先銷售人員會登錄ITSM系統的服務檯告知故障現象，然後走故障管理流程。隨着這個故障上升成爲了一個事件，觸發了事件管理流程，然後問題就出現了：原有的ITSM系統中無法定義緊急變更流程的輸入、輸出功能，因此這個事件也就停在了這裏。
ITSM流程帶來了規範的操作、可控制的運營過程，也帶來了官僚和僵化的危險，流程的繁瑣會成爲人們抵制ITSM的另一個理由。但很多企業在實施前的準備不足卻使得流程更加拖沓，因此量化管理流程前，應以最大限度地消除由於ITSM失配所導致的運營風險爲前提。勢必要將更換鼠標和鍵盤等事件的流程數量縮減至較少，避免“小馬拉大車、殺雞用牛刀”的管理模式出現。
信息混亂 會導致錯誤指揮
本文記敘到這裏，我們還有一個非常重要的概念沒有提，這就是：CMDB（配置管理數據庫）。爲了達到動態IT運維服務所追求的目標，我們必須將ITIL指導真正落實爲明顯的、可衡量的，變成可以整合的實體，而這承載這些實體的容器就是CMDB。
CMDB信息模型有兩種不同的方式。一種是自上而下，即先有一個宏觀的企業視圖，在CMDB中爲該視圖部署一個元數據模型，然後確保所有管理應用程序符合元數據模型。另一種方式是自下而上，即把低層的數據集進行標準化，依此開發模型。由自下而上產生的CMDB模型與具體的管理功能和應用無關，因而比實際上的低層次數據集更易操控，它更易被接受，因爲它無需破壞企業的組織架構和文化。
作爲ITIL實施成功的關鍵與保障，CMDB相當於整個“網絡列車”前行的動力源泉。由於它可以代替了以往手工存儲和管理企業IT架構中設備的各種配置信息，因此更多地企業開始考慮採用自動獲取的方式存儲IT基礎設備的各種配置項信息，然後將其與ITIL的所有流程都緊密相連，提供有效數據支持ITIL其他流程的運轉， CMDB配置庫可以是比喻成企業網絡中的“眼睛和大腦”。
這個特殊的動態數據庫作爲ITIL標準流程裏一個核心的組成部分，記錄了ITIL流程運轉的過程，從開始啓動、發現事件、問題處理、變更管理、版本發佈，到最後的關閉，中間的所有的過程都會被自動的記錄到CMDB中。試想如果CMDB對故障設備的關鍵性指標提供了錯誤描述，事件能夠得到及時解決嗎？如果沒有配置管理的同類故障統計分析支持，如何實現主動的問題管理？如果沒有配置管理提供CI（配置項）之間的關係作爲依據，如何針對將要進行變更的CI以作風險評估？
巧婦也需要有米下鍋
很多人都知道，工具在ITSM中的地位要排在流程和人的後面，但是這並不說明工具就不夠重要，如果在上百臺服務器和幾十個業務系統面前，你依然讓我用手工的方式去運維，必然導致我 “發飆”。如今，各家廠商ITSM的工具所包含的廣度越來越大，但在同時，單個工具的亮度也越來越被弱化。具體來講，IT服務管理工具廠商包括BMC、IBM、HP和CA、神州泰嶽、廣通、游龍、北塔、摩卡、泰信等等。
但有了工具就不會失敗嗎？在執行ITSM策略時面臨的最大挑戰就是流程必須根據每個企業客戶的實際需求而進行調整，但很多ITSM項目要麼停頓不前，或是完全失敗。就如我們理解的一樣，ITSM只是一套方法論，其最終的實施還是要依靠相應的工具和經驗。有些時候，ITSM工具之所以無法量化，因爲這個工具本身就不能適合企業的需求，死板的ITSM工具，必然結果就是項目失敗。以上這些廠商的產品各有千秋，我們也仁者見仁，智者見智吧。不過如果我依然站在IT管理者的身份上來講，比較關注下面兩點：
可視化功能：這可以讓我們瞭解信息環境中利用率不足的資源以及有過剩的容量、可用於支持新業務運營的資源，以優化資源分配，從而降低成本。同時，通過預測資源過度利用，以及針對可能無法根據業務需求繼續擴展和增長的資源生成前瞻性事件和報告，以降低風險。
自動化功能：可以幫助我們精簡事件和問題管理流程，改善整體服務質量和快速恢復服務。通過前一個功能（實時可視性），第一時間瞭解問題、事件和服務請求的優先級、緊急程度和影響，並利用這些知識和功能查看其需求是何時、何地和如何解決的。
向着IT服務管理的目標前行
隨着雲計算、虛擬化、SOA等新技術的不斷涌現，目前IT的運行環境正在發生劇烈變化。越來越多的應用、更復雜的數據、異構的系統平臺、跨系統和跨組織的業務流程優化等，這都使得ITSM的規劃要比幾年之前艱難了很多。
ITSM作爲“管理學”中的新興學科，其實施的重點是IT的運營和管理，而不是IT的技術本身。我們拿一個生活中的例子來說，如果把組織的業務過程比作安排一輛汽車去完成一趟運輸任務，那麼ITSM規劃的任務相當於爲這次旅行選定正確的路線、合適的汽車和司機。而ITSM的任務則是確保汽車行駛過程中司機遵循操作規程和交通規則，對汽車進行必要的維修和保養，儘量避免其出現故障；一旦出現故障也能很快修復；並且當汽車到達目的地時，整個行駛過程中的所有費用都可以準確地計算出來，這便是成本管理。而這些細節組成起來，就是 “智能”的交通,如果我們把這個例子套用到IT運維上,這就是“智能”的IT服務管理。
在獲取更多層面的支持者之後，你便可以開始制訂ITSM實施路線圖，當然之前你最好完成的參加一次ITIL或者ISO 20000的培訓，以便有章可循。總之，我們都希望通過可視化，可控化和自動化， 實現企業IT設施，人員與流程的互通互聯，進而達到業務與IT系統的全面融合，在這個目標上不要偏離軌道。