天宇公司的CIO李學剛已經聽到了太多贊揚ITIL的話。讓他心里癢癢的。某家大型集團公司的CIO告訴他，實施ITIL后，他們公司每年節省約30萬元的IT運維費用，而且，由于信息系統運行穩定，公司還增加了10%的收益。和很多同行一樣，李學剛一直為公司IT服務管理上的無序、IT部門四處“救火”卻飽受“夾板氣”的狀況而煩惱。顯然，ITIL是一個有效的解決之道。但是，李學剛對于公司是否實施ITIL卻仍然有些遲疑。因為，在聽說了ITIL眾多的好處同時，他也聽到一些對ITIL的質疑。

    ITIL是一種IT服務的思想，一種IT管理的流程，或者具體化為一套程序系統；建立這樣一套規范的服務流程，無論從改善IT服務水平，IT風險防范還是IT服務的量化，都是有很大幫助的。但是在具體的實施中，是否存在一個平衡度的問題呢？能否在成本與效益間找到一個平衡點呢？李學剛就聽到過這樣一個例子。

    在某家實施了ITIL的公司，有一次，業務部門要求修改一個SAP R3的報表，變更的內容是修改一下報表的標題，對于這樣一個需求，按照公司IT服務管理系統的流程：業務部門的相關人員要在系統中提交需求申請—需求轉到服務臺（service desk），分配給相關的IT人員——IT人員接受申請——報表修改完成，申請程序——IT人員在IT服務系統上結束申請，上報審批——系統通知業務人員。對于這樣一個簡單的需求，中間卻需要經過如此多繁瑣的過程，時間常會延遲得厲害，時時遭到來自業務部門和IT人員的雙重抗議。李學剛聽到這樣的例子后有點害怕，難道實施ITIL就是為了讓簡單的流程復雜化嗎？對于像硬件，網絡或者服務器這樣主要基于IT技術的IT服務，往往在業務部門提出相關需求后，IT人員在不需要與用戶進行太多的互動交流的情況下就可以解決問題。

    但是，對于像ERP這樣與業務息息相關的軟件服務，則往往需要IT和業務人員的大量交流和磋商，以準確理解用戶的需求，而僅依靠業務人員提供的業務需求文檔往往是不夠的。那么，在采用ITIL系統進行管理時，是從原始的需求就通過ITIL系統來進行交互，還是在需求確定的情況下再提交到系統？如果是前一方法，這樣的交流方式估計雙方都不會滿意，不如電話+需求文檔的方式。如果是后一種方式，則系統淪為文檔管理系統。怎樣處理才能發揮ITIL系統的最佳功效呢？

    除了以上困惑之外，李學剛聽到更多的還是，在實施ITIL中CIO碰到的企業文化和行為習慣方面的阻力。比如說，有的公司在實施ITIL之后，仍然有員工繞過幫助臺與熟識的相關技術人員直接對話。還有，由于ITIL的實施、流程的改變，解雇員工將會在所難免，因為一些IT員工無論如何也適應不了新的流程。雖然有以上種種困惑，但李學剛心里清楚，ITIL的實施勢在必行。問題是，在今后ITIL實施的過程中，如何有效地處理好以上問題呢？（述冠）

    ITIL靈不靈，看用戶爽不爽

    隋華鋒 神州泰岳軟件公司首席技術官

    ITIL靈不靈，關鍵看用戶爽不爽，而不是減輕IT人員的麻煩?？蛻舴召|量的提高是以IT人員更大的付出換取的，而不是靠什么靈丹妙藥。從案例的介紹可以看出，天宇公司IT內部管理的現實情況、CIO李學剛的苦惱、對ITIL的理解和期望都是非常典型的。

    CIO的尷尬處境

    ◎ 公司內IT服務管理無序，IT部門四處“救火”，飽受“夾板氣”。

    ◎ CIO強烈希望改變這種無序狀態，但對于具體目標的認識是模糊的。

    ◎ 看起來ITIL似乎是一攬子解決所有問題的靈丹妙藥，只要引入ITIL，各種問題就會迎刃而解。
但這是真的嗎？會不會又是廠商的炒作？會不會又被忽悠？雖然李學剛認為“ITIL實施是勢在必行”，我仍然建議把如下幾個問題考慮清楚，再考慮如何“必行”。目前公司內IT服務管理的主要矛盾是什么？是秩序問題還是效率問題？是要提高服務水平還是降低服務成本？“四處救火”是因為忙不過來還是人浮于事？“受夾板氣”主要是因為技術人員的工作態度還是工作能力？仔細思考一下這些問題是非常必要的，看似忙不過來、實際上人浮于事的情況還是挺多的。主要想解決哪個問題？具體目標是是什么？既規范又高效，既提高服務水平又降低服務成本似乎是可能的，聽上去很美。但現實情況下，魚與熊掌往往是不能兼得的，想要兼得、往往會賠了夫人又折兵。這是有許多血的教訓的。

    ITIL不是靈丹妙藥

    ITIL能夠幫助我們做什么，不能做什么？或者說ITIL主要能夠幫我們做什么？必須認識到，ITIL不是包治百病的靈丹妙藥。要分析目標和主要矛盾是否是引入ITIL可以解決的。緣木求魚的故事告訴我們，爬到樹上是抓不到魚的。其實，ITIL既不神秘、有不復雜。ITIL的核心是客戶和服務，您的IT部門是否真的是把用戶當作客戶？是“服務”于用戶還是“管理”用戶？進行ITIL建設的目的是IT部門多干活、提供更優質服務，還是盡量少干活？只有確立了客戶和服務的理念，統一了為保服務質量可以多干活的認識，ITIL建設才會順理成章。比如：ITIL首先強調的是規范和記錄，也就是說IT支持人員必須把事件、問題、變更等過程記錄在案。如果進行ITIL建設之前，運維人員沒有記錄的行為習慣，推行ITIL當然會增加這些人的工作量。又如，ITIL強調一二線/前后臺分離，前臺人員專注于客戶和服務、后臺人員專注于設備和技術。無疑這會改善客戶感受、提高用戶滿意度，但同時也會增加IT部門的負擔。當然無法達到減少IT人員工作量，或者減少IT人員數量的目標。

    ITIL的主要作用是規范

    從短期來看，IT服務管理的核心是讓客戶更方便，更舒服，IT人員會更累。事情更多。對IT部門和人員的好處會在長期逐漸顯現出來。我們認為，我們目前各單位實施ITIL的主要作用應該是規范而不是效率，是方便客戶而不是方便IT人員，是提高服務水平而不是降低服務成本，是管理IT人員而不是服務于IT人員。如果企業的文化和氛圍不是以服務為中心，ITIL建設往往會流于形式，這也是有相當多的先例的。按照上述原則，分析CIO李學剛的擔心就比較清楚了。比如：SAP R3的報表需求變更通過服務臺申請對客戶并沒有什么不方便的，關鍵是IT部門的拖延。換種思路完全可以是如下的場景：客戶電話向服務臺提出變更要求，后臺技術人員迅速電話/上門核實具體要求并迅速實現，然后請客戶提意見。這樣客戶會不滿意嗎？當然IT部門要多做很多評估、審批等工作，但這是為了防止該變更影響系統的穩定運行，客戶不會希望系統經常宕機吧？再如，所謂的企業文化和行為習慣問題，IT人員服務的意識、規范和記錄的習慣是一定要養成的?？蛻衾@過幫助臺與熟識的相關技術人員直接對話的問題在ITIL建設初期是經常遇到的，這里客戶完全沒有責任，只能說明服務臺的服務還不到位，宣傳力度還不夠。試想，如果撥打服務臺電話，服務態度好、問題解決更為迅速，客戶還會一直找技術人員嗎？所以，實施ITIL的原則是使用戶盡量簡單，IT人員不怕麻煩?？蛻舴召|量的提高是以IT人員的更大付出換取的，而不是靠什么靈丹妙藥。

    明確和認可了上述原則后，后續如何進行ITIL建設就容易理順了。無非就是流程如何梳理，系統如何建設，如何推廣和落實的事情。有關ITIL實施的方法、經驗和最佳實踐的討論已經很多了，在此就不再贅述了。
    吃透流程，化繁為簡

    陳仲億 賽迪顧問公司高級咨詢顧問

    ITIL只是一種全面的IT服務管理的框架標準和方法論，IT服務管理也沒有固定的范式可以照搬硬套，國內企業在IT服務管理的具體實施中，首先要根據實際情況，吃透流程。初看到這個案例，讓我想起了國內企業在剛開始學習和借鑒發達國家先進管理經驗的一些例子。這些例子與案例中CIO李學剛遇到的情況有幾分類似。在中國剛開始貫徹實施ISO9000標準時，標準要求必須對采購過程進行控制，包括對供應商的評價，建立供應商名錄。因此，有些企業在建立ISO9001質量管理體系時，不區分采購物資對生產影響的重要程度，對所有的供應商都建立了名錄，甚至連采購辦公用鉛筆和拖把的商家也列進供應商目錄里，進行評價，這大大增加了許多不必要的工作量。

    還有，ISO9000標準要求，最高管理者應提供向員工傳達以客戶為關注焦點的證據，不少企業理解為證據就是要留下書面的記錄，于是上級向下屬員工傳達文件精神時，都要求員工必須簽字，作為傳達文件的證據保存。于是得出結論，ISO9000標準將簡單問題復雜化了，不適用。這些都是典型對標準沒有充分理解或片面理解造成的后果。本案例中CIO李學剛的困惑，也是屬于這種情況。

    實施ITIL因地制宜

    ITIL來自國外的最佳實踐，它的出現，在時間上并不是很長，它確立了以流程為中心的IT服務管理方法，通過實施ITIL，可以給企業的IT管理帶來諸多好處，如可以減少重復和冗余工作；可規范工作流程等。正因為ITIL能夠給企業的IT服務管理帶來有益的幫助，引起了IT業界眾多相關人士的關注。然而，在ITIL具體實施過程中，有些企業未能充分理解ITIL的真正本質，照搬標準，或者完全按照其他企業的做法來實施企業的ITIL建設，而不管自身企業的實際情況，最后出現了案例中CIO李學剛遇到的困惑。

    ITIL本質上是一種方法論，它列出了各個服務管理流程的“最佳”的目標、活動、輸入和輸出以及各個流程之間的關系。但并沒有說明具體的日常運營活動。其重點是保證流程實現應有的功能并與其他流程相協調。至于具體怎樣實現這些功能，組織應根據實際需要采取不同的方式?；蛟S正因為沒有給出具體的操作步驟和方法，不少企業在實施ITIL流程管理時，便將流程片面理解為任何事情，不管其大小、重要程度、緊急與否，都按照一個流程模式執行，這樣，肯定造成為了“流程”而“流程”，最終失去了流程的意義和價值。

    正如案例中談到的業務部門要求修改SAP R3報表標題，對于這樣一個簡單的需求，中間卻需要經過這么多繁瑣的過程，往往會遭到來自業務部門和IT部門的雙重抗議。這里有兩個問題需要關注，第一，是否所有的變更都必須經過變更管理流程進行控制；其次，如果是，是否所有的變更都遵循一個程序和一樣的活動環節。對于前一個問題，我們說，應該屬于變更管理范圍確定的過程。在確定變更管理的范圍時，我們要避免出現變更管理過度的情況。在實際運營中，有許多變更是常規性的，單個的常規變更發生時，無須送至變更經理處進行審批，直接進行變更的執行。常規性變更其程序和步驟也預先規定好了，比如修改報表標題、創建一個用戶ID等這類常規性的變更，是否需要將它列在變更管理的范圍，如果過多地在變更管理流程中管理這些任務，只會導致變更管理的繁瑣和效率低下。我們可將這些活動看作是服務請求而不是變更請求并由事故管理流程處理。當然，決定哪些變更活動是常規性的，需要全面評價和審查，如果一定要在變更管理流程中處理這些常規性變更，可將其定為“批準前變更”，即在變更數據庫對它們進行注冊，但不需要啟動變更管理程序。對于后一種情況，屬于變更管理類型的問題。變更管理流程中，可以將變更請求分為常規變更、標準變更、緊急變更和項目變更等類型，不同的變更類型應該制定不同的變更管理程序和相應的授權審批規定。如果案例中的報表標題修改必須經過變更管理流程處理，那么可以考慮這個過程中的授權審批，授權審批到IT人員即可，不必等到IT人員修改完成后，再上報變更經理審批，此外，對不同類型變更，在各環節的處理時間，需要有一個量化的考核指標，在規定的時間內必須完成。因此，對于CIO李學剛在實施ITIL,通過流程管理IT時，應該充分理解ITIL的本質，具體運用時還需要企業結合自身實際。