隨著客戶對“個性化”的需求越來越強，許多公司都要求根據自身公司的情況定制自己的IT服務管理解決方案，尤其是自己的配置管理數據庫CMDB。雖然這些公司的背景大都不同，但在決策時，他們總是在“是否購買一個現成的IT服務管理解決方案，還是自己設計一個解決方案”這樣的決策上猶豫不決。為什么如此重視這個決策呢？當然首要原因是成本。雖然購買、實施并對一個商業產品進行參數調試等行為的價格都明碼實價的標在標簽上，除了無法預測進行ITIL/MOF實施時所要花費的咨詢費用外，其它費用合計即使對一個小型的公司來說也不會少于15萬美元！如此大的支出，當然會使決策者在制定決策時慎之又慎。那么，你的公司是否需要自建一個個性化配置管理數據庫呢？

     現在，我們可以假象一些情景，來考慮這個問題。
 
    情景一：“我們需要自建CMDB，因為我們需要對流程進行重新設計”——WNPD公司的尷尬

    WNPD公司是一家很大的公司，他們對自己的IT服務管理流程有很多特殊的需求。但由于當前的經濟問題，使他們購買一個現成的IT服務管理工具可能性不大。于是，他們的IT管理層決定自己實施MOF/ITIL，并已開始著手研究IT服務管理解決方案的實施問題，但他們的研究重點很明確的放在對文檔的管理和各種配置項的選擇上，而并非是工具的使用！這家公司已經安裝了一個大型的軟件包，包括有限的工作流能力管理軟件如微軟的Project軟件，Exchange服務器，以及Note軟件等，公司還建設了內部網，上了許多內網應用軟件。IT經理很擔心如果在安裝各種軟件時花的精力太大，可能會影響到流程設計和ITIL實施時的文檔標準設計與文檔管理工作，浪費大量的寶貴時間；但同時，組織還是很需要實施這些流程的，于是問題轉換為如何使用最簡單的工具，如Excel，Access以及Exchange等來創建自己的配置管理數據庫。

    關于是否自己設計并實施適合自己的CMDB，實現個性化的IT服務管理流程的意見很多，這里各列舉幾個反對和贊同意見。

    贊同意見

    ·        實施速度很快，節約時間

    ·        實施的起步階段費用較低

    ·        可以建立起與當前組織數據庫的個性化連接。硬件和軟件庫存清單可以很快地被查詢到，就像存儲在系統管理解決方案中的數據那樣。

    ·        在為真正的解決方案做出巨額消費前，提前掌握到IT服務管理各功能模塊的需求，同時可以使用案例來支持綜合IT服務管理解決方案的制定。

    反對意見

    ·        只能提供有限的功能

    ·        用戶接口的質量較低

    ·        無法與系統管理工具進行集成

    ·        不充分的解決方案可能會降低管理者和用戶對該項目的熱情和支持

    ·        一些看似容易但卻很難實現的能和特點可能會提高整個解決方案的成本

    情景二：“我們的服務太需要一個更好的配置管理數據庫”NeedCMDB公司的困境

    NeedCMDB公司的幫助臺軟件可以存儲大量的突發事件信息，而不需過多地考慮配置管理數據庫中各配置項的內部聯系。該公司的IT運營經理希望安裝一個變更管理軟件，因為他們公司大部分的問題出在基礎設施變更時所引發的問題，以及軟件在各種應用程序分發過程中的版本問題，這當然也包括所有軟件對其支持的服務目錄所帶來的問題。公司內部也會產生大量重復發生的突發事件，這更使我們的IT經理堅信：只有通過有效的問題管理才能更好的解決問題。而所有這些的解決途徑源于一個更好的，更適合自己的配置管理數據庫！

    關于是否在該公司實施適合自己的IT服務管理解決方案的贊同意見和反對意見包括：

    贊同觀點

    ·        根據記錄的服務和突發事件，可以更容易的設計配置管理數據庫粒度級別，這對組織是非常重要的

    ·        通過實施一個簡單的軟件基線庫（Definite Software Library, DSL），可以更好的支持變更管理和版本管理，使我們在安裝軟件時更容易

    反對意見

    ·        記錄所有軟件應用的服務目錄將會使配置管理數據庫變得格外復雜，因為這種情況下，CMDB中大都包括了這些應用的所有軟件組成部分

    ·        這將使變更管理以及創建一個標準變更管理數據庫變得異常復雜，需要更長的時間來完成。而我們完全可以通過快速原型法來降低時間，提高速度。

     情景三：“我們的業務由我們的服務級別協議來定義”——某應用服務提供商（ASP）公司的心聲

    ASP公司希望控制他們的服務級別協議SLA，以此來提高服務級別和服務質量。他們也很關注自動化軟件的分發和測試。當ASP公司的管理層得到風險投資家的投資后，盡管這些錢還僅僅是一紙銀行支票，他們就已迫不及待地實施一個基于運營中心且達到級別5的完整MOF模型框架。

    對于該應用服務提供商來說，反對意見和贊同意見也各占一半：

    贊同意見

    ·        他們可以將各種解決方案按照他們所希望的方式進行精確集成，集成任務可以完全使用系統管理工具來完成

    ·        他們可以產生出客戶需要的用戶接口，進行突發事件報告，變更請求，甚至實現在線變更等。

    ·        他們所提供的某些服務特點可以使他們的服務級別協議具有較高的可配置性，并為該公司提供了一條領先于其他應用服務提供商的途徑，使該公司在眾多ASP公司中脫穎而出。

     反對意見

    ·        開發一個完整的IT服務管理解決方案的過程可能是非常漫長的。這樣長的時間對于一個ASP公司來說未必能夠始終保持自己的領先地位，除非所付出的努力是巨大的且效果是非常顯著的時，才可能保持住IT服務管理為其帶來的優勢。但這樣往往會使組織消耗過多的資源，甚至無精力去顧及其他的項目。

    ·        對IT資源來說，在一個相當長的時間內支持同一個產品將是一項非常重的負擔，最終的結果也一定是非常昂貴的代價

 
    情景四：“我們的公司雖小，但仍需要一個非常有效的工具和流程以實現公司的領先優勢。自制配置管理數據庫是一個不錯的選擇！”——小公司的觀點

    小公司同樣需要IT服務管理，他們同樣需要信息系統來實現一個小的幫助臺和突發事件管理。因為公司規模小，所以在選擇IT服務管理解決方案時，就要針對小公司的特點有所側重。對該公司來說，他們也需要IT服務管理得主要管理模塊和功能（如幫助臺和突發事件管理），但無需擁有大型系統管理工具。他們也在考慮變更管理和配置管理模塊，以便實現對其基礎設施的完全控制。

    關于小公司情況的觀點包括：

 
    贊同觀點

    ·        自制并實施一套方案的時間很快，因為在幾周內用關鍵的幾張表建一個Access數據庫是很可能的

    ·        可以自己根據需要快速產生出適合自己情況的功能。因為組織不大，所以將發生的變化在整個組織內溝通將是很順利的。

    反對意見

    ·        組織必須對高一級的MOF/ITIL有深入的了解，或者向一個資深的MOF/ITIL咨詢顧問尋求幫助

    ·        與系統管理工具進行集成的任務將是非常困難的，這也暗示著我們集成后的CMDB數據庫將仍保存著手工管理那些最長使用的重要資產的功能

    那么，現實到底有多復雜？

    作為一條總體原則來說，根據組織自身情況，自制一個ITSM/CMDB解決方案是完全可能的。但切記，在設計階段所付出的艱辛與推廣這個方案時所付出的努力將是同樣多的。因為在推廣一個配置管理數據庫時所需的工作同樣復雜，在各種繁雜工作中還包括從多維數據源中獲取數據。僅這兩項（創建一個CMDB數據庫并收集數據信息）就需要組織付出特別多的努力。這樣組織就不會有太多的精力從事MOF/ITIL的實施。因此，我們在考慮是自建還是購買一個現成的CMDB解決方案時，除考慮時間成本、資金成本外，還要考慮自制過程中將遇到的問題和困難，做好心理準備。在綜合考慮各種自建的優缺點后，再作決定。（3030字）