這是我一直想寫的內容，苦於沒有時間與精力，本來是希望把這個項目從立項到規劃，到設計開發，到最後的實施應用的全部過程寫成一個筆記，但工程浩大，有些力不從心，正好國慶節有一些時間，就先寫一部份吧。
以下的內容會一些雜，我把我們規劃這款ITSM系統的一些想法寫出來，裏面會夾雜着我對這種類型系統的一些規劃考慮點，這種考慮一是基本對ITIL的理解，二是對軟件實現的理解，三是運維管理的考量。內容不會十分具體，因爲每一個部份基本都是一個模塊，如果寫得深入，基本是一個詳細的設計說明書了，這就沒有必要了。
這是第一次真正的去思考規劃與設計一個系統，這裏說的設計可能與軟件工程的設計定義有一些區別。以前都是做軟件實施，現在終於有機會把在做軟件實施時的一些想法前移到設計階段，因爲這個項目的規劃與實施都會是我負責，所以是把首尾相連了，這也相對可以保證規劃的思想可以比較徹底的貫徹下去。可能存在的問題是，後續的一些設計過程，我沒有非常深入進去了，這樣會導致一些缺失，另一方面，許多在規劃的想法是會對公司的體制與管理制度造成一定衝擊的，可能到時沒有足夠的時間與決策支持去扭轉當前的作業現狀，最後就是對開發團隊的實現能力有一些擔心，一個好的想法開發人員沒有足夠的技術能力去實現，這也是比較麻煩的。總的來說，這項目要想取得我預計中的效果，非常具有挑戰性。
不廢話了，下面將逐步展開說明。
一、系統目標
系統目標是爲了說明我們想開發一個怎樣的系統，想利用這個系統做什麼，達到怎樣的目的，最簡單的是，我們想打造一個運維平臺，把我們在各個地區分佈的運維服務團隊，無論屬於哪一個客戶羣的，無論是屬於哪一種業務領域的（桌面、網絡、系統、軟件）都統一納入到一個相同的平臺上作用，他們要基於相同的制度，基於相同的流程，基於相同的理念，用統一術語與方式去服務客戶，我們的一個優勢是規模與平臺資源，但如果我們的人員與業務無法整合到一起，這種優勢就不復存在的，反而可能成爲一個負面原因，因爲你沒有了大船的承載能力，卻也沒有小船的靈活轉身能力。運維服務業務有其特點，因爲很難標準化，同時太容易受客戶的影響而改變流程或制度了，一旦你的團隊分散，客戶多，而且地理分散後，說光依靠發佈出ISO20000的體系文件，對人員做多麼紮實的培訓，這樣就能把大家的各種作業規範統一起來，不是說不可能，極難，要花費巨大的管理資源，同時這樣做的一個問題是你的運維服務數據是極難進行分析與採集的，這時一個顯而易見的方式就是利用軟件。
我們在打造自已的平臺時，概括來說對這個平臺有這麼一些幾個方面要求：
設計要求2
要基於我們的運維服務業務特點，同時把這幾年我們做管理探索與改善的經驗置入其中，另一個方面要把ISO20000在實施過程的所得納入實現，這裏就是我們的服務體系了，但只是取部份流程的，主要是針對服務支持等部份的流程，還有一個方面就是要參考REMEDY優缺點。這三個方面是我們規劃設計這系統的主要基礎，加上我們對遠景的期望，基本上這三個方面我們都做了一些調研與整理工作。
範圍要求2
我們所有的運維服務業務，我們所有的運維服務人員，以及運維服務中的所有活動都需要可以被管理，也可以分這麼兩個層面來說，我們這個平臺要可以管理所有的運維對象（各種類型的項目），同時要管理我們的運維資源（人），這裏的運維對象與運維資源並不是抽象的概念，是非常具體的，運維對象可以具體到具體每一個CI及其備件，運維資源具體到每一個人的工時利用。其它的象服務目錄與SLA等就不用多介紹了，是必要納入管理。主線是從運維對象與運維資源這兒走出來的。
擴展要求2
運維平臺可以滿足公司當前的運模式的發展需求，以及我們現在的產品的發展，這裏涉及具體的一些公司現狀，就不多作說明了
質量要求2
在應用質量上我們要超過REMEDY，注意是應用質量，不是指功能，功能上我們無意與REMEDY去一爭長短，因爲這沒有什麼可能性與意義，但我們有信心只要一年實施時間，我們就完全可以超過REMEDY在公司的應用質量，這一點我的把握相當大。
二、系統架構
我們使用的是B/S的系統架構，這是爲了方便地理分散的員工使用，同時也是爲了考慮到日後全國的用戶可能會登錄系統進行一部份的作業，比如參與調查，或者開放論壇等，採用B/S的架構，負面的影響一是速度方面，二是界面表現力，但日後的升級維護比較方便，用戶登錄也很方便。具體是否成功，可能還要等日後大規模應用時才能進一步驗證。開發平臺是.NET2005 C#，數據庫採用ORACLE10G。另外我們在流程中（比如事件升級、派單）做了一些郵件通知與短信通知的功能，其它的在技術方面，倒好象沒有太多值得說明的地方，也可能可以說技術並沒有太多的亮點。
三、流程控制
在系統流程控制方面，當時也有過一些爭議，後面由於我的堅持，放棄了採用工作流引擎的想法，一不是希望增加項目複雜度，二是硬性的流程事實上是不現實的，因爲在運維服務活動中，單據的流轉方式很難硬性定義，加上一人擔負多個角色，去配工作流是沒有太多意義的，同時我們主要是自用，一旦運轉起來後，去調整流程的可能性較低，那樣工作流引擎存在意義就很低了。所以我們在開發過程中，一旦有硬性的流程就寫死在程序中，而單據的流轉是由人確定的，可以不做限制進行單據的轉派。這裏也是以前在軟件實施一直的想法，不能指望軟件去完全實現一切的控制，有些的控制點放在系統之外，往往會更好更省力，軟件只是一個汽車，你想它跑得更快更好，需要有一條道路去配合在一起，這條路就是你的管理制度，許多寄望軟件實現的控制點，一旦沒有考慮清楚，最後會帶來許多麻煩，所以要有先鬆後緊的策略，逐步增加控制，而且是要以制度爲先。
四、服務檯管理
事件管理與服務檯管理是不同的概念，前者是一種流程，後者是一種職能，許多人沒有搞清楚這兩者的關係，事實上事件管理的許多操作是由服務檯人員完成的，服務檯本身並不存在流程（注意這是站在ITIL流程的層面），服務檯管理本身是一個獨立的學問，這要根據每個組織的特點去考慮，在我們的情況中，有幾名獨立的熱線人員作爲服務窗口，對這些人員的話務管理是通過語音系統管理的，而這個語音系統與我們的ITSM系統是有接口的，真正的事件操作事實還是在事件管理中完成。
這裏特別提一下，在我們的ITSM系統中事實上是沒有一個服務檯管理模塊的，我相信許多人並沒有真正理解服務檯的真正含義，把熱線與服務檯劃等號是有問題的，尤其是要IT服務領域，一旦你包含比較多的軟件項目，服務檯就一定會發生變異，如果你的服務檯人員只是起到一個轉電話與派單的作用，那事實是一個語音菜單的功能，這樣的服務檯設立的意義不大，多數人以爲服務檯作用是單點受理以及快速響應，但是這更多隻是手段不是目的，服務檯並不是一定在物理上坐在一起，服務檯可以是多種多樣的，一定搞清楚服務檯的目的是什麼，它爲什麼而存在，IT服務不同於其它的行業，當用戶打電話到攜程與招商銀行的的服務檯時，跟用戶打電話到一個IT服務商是不一樣的，攜程與招行的服務是相當“大衆”與“標準”的，他們的服務檯基本可以做到你電話過去時，就能真正響應，而IT服務商的服務檯通常做不到，爲什麼？因爲你的服務更具“縱深”，所以對你的服務檯提出了更高的要求，你讓幾個完全聽不懂用戶問題與需求所在的熱線非常快的接到用戶電話真正有用嗎？響應的定義是什麼？如果僅僅是接聽了用戶的請求，而不做任何反應，這叫響應嗎？我讓一個電話錄音機當熱線，這算不算響應呢？如果你的熱線是真接轉電話給工程師，經過熱線轉一下的意義何在？工程師仍然處於隨時待命的狀態，你的服務資源沒有任何節省，而是在浪費，同時讓用戶重複問題，或者讓熱線轉述問題，造成信息缺失。當你的服務檯沒有起到真正的服務檯作用時，你會發現一個有意思的現象，用戶會繞過你的服務檯，直接打電話到工程師哪兒了，不要說這是用戶的問題，這是你的問題，你沒有把一個正確的路徑給用戶，用戶會按最有效率的路徑來走的（是不是類似我們走草坪的情形？，人們不會喜歡90度的直角小徑，會用斜線穿越草坪）
好象扯遠了，服務檯這一課題要展開講是一個獨立的篇章，IT服務業的服務檯是不同於傳統行業的，用傳統行業的callcenter的做法去設立IT服務業的服務檯的做法，一般是行不通的，尤其當你的業務領域複雜時，可能虛擬服務檯是一個不錯的選擇，沒有一定的硬性標準，要根據自已實際的業務需要來，一個真正好的服務檯，是可以節省你的服務資源，而且可以更快把客戶請求結束掉。
五、事件管理
事件管理是創建、處理事件的模塊，一個事件的生命週期全部會在此模塊內，在設計時，需要考慮以下的信息
事件的類型2
事件管理在我們規劃中，是一個非常重要的窗口模塊，事件類型我們分爲了有故障、請求、諮詢、新需求、投訴，基本上面向客戶的事務都會在此發起，這種類型也是爲了日後的統計分析。
事件的分類2
由於我們項目衆多，考慮到橫向統計的需要，我們要定義一個公用的事件分類，以便運維管理分析，我們分了硬件、軟件、網絡、數據庫、接口、業務這幾個大類，日後可能會進一步細化分類，以便做更深入的分析，但這個難度很大，需要時間的積累。
事件的等級2
最開始我們是希望引入優先級（嚴重度與緊急度），但後面發現這樣定義非常困難，對指導工程師處理意義不大，還很有可能會誤導信息，所以最後就把事件硬切爲5個等級，公司給出最粗的定義標準，然後由每個項目具體定義解釋，這樣每個工程師在作業時，就可以定義事件的等級，默認情況下，等級越高的事件，是表示越嚴重，也表示要優先處理的，雖然會相對粗放一些，但相對簡單適用業務，而且我們的SLA是與此相關的。
事件的狀態2
事件狀態是爲了表達事件單當前的處理狀況，我們爲了創建、分派中、處理中、等待中、解決、關閉。這樣可以形成看板與統計。
事件與CMDB的關聯2
一直以來說CMDB的用處，在事件的應用就相當關鍵，在事件發生時，要做一個關鍵動作，就是組件定位，需要搞清楚這個事件是發生在什麼項目（CI）的什麼地方（CI），需要事件創建者做出定位，然後在派單時，就會根據你的CI定位，帶出相關的責任工程師，與事件與CI的關聯，給你的運維分析會帶許多豐富的信息，你CMDB所有的信息與事件的信息可以交叉進行統計分析，比如上面說的事件的分類有硬件，那我想知道桌面項目的一年中硬盤發生了多少故障呢？我想知道一年中桌面項目中希捷品牌的硬盤發生了多少故障呢？我想知道去年桌面項目中，客戶對哪一款軟件的諮詢次數最多，以便我來年準備對用戶做一次操作培訓，這些信息全部依靠事件中的組件定位，這樣的信息就可以輕而易舉的告訴你。還有你想知道去年你的軟件的哪一個功能點或模塊的發生的故障次數最多嗎？你想知道去年被投訴次數最多的項目或人是誰嗎？這些全部可以出得來。
事件與其它流程的接口2
事件與變更、問題、知識庫是存在接口的，事件處理過程中可以直接發起變更申請，也可以發起問題申請與知識庫申請，需要說明的是事件與變更的接口，我們的事件是否關閉沒有硬性判斷與之關聯的變更是否終結，而是從事件單方面流出信息，並沒有把變更的處理情況與事件單關聯，讓這個流程分線程去作業處理，主要是擔心做得太死，可能導致事件單關閉受阻。
事件的時長與工作量2
在任何一個事件的處理時，對於時間而言，有二個概念，一個是事件的時長，是指一個事件的處理週期（從8：00創建到12：00解決，4小時），一個是事件的花費的資源量，即工作量（4小時的時長中，工程師可能投入了2小時來處理），時長是爲了SLA的計算，後者是爲了運維資源的分析。
統計分析2
事件報表的統計分析是非常豐富，可以從CMDB的角度出發，去統計每一個項目、每一個設備的事件情況，還可以從客戶的角度出發，統計某個客戶組織或某個客戶的事件情況，還可以運維組織的角度出發，統計我們的一個服務團隊或一個服務人員的事件情況，另外可以從事件本身的信息出發，根據事件的類型、分類、等級、狀態、來源（電話、郵件、WEB）去統計，還可以統計SLA方面的數據。
2
六、問題管理
問題管理處理邏輯其實是類似事件的，它的許多信息是繼承事件，比如等級與類型等，在規劃問題管理時，要想清楚問題的分類等級等信息跟事件是什麼關係，問題管理的大概作業界面有哪一些，在系統流程上有哪幾個步驟，如何留下問題的處理時長與工作量，如保留下問題處理的記錄信息，問題如何發起變更，如何納入知識庫。問題與事件在程序處理上的區別，比如問題的創建後需要有一個審批的動作，問題不服從SLA，問題有知名錯誤的概念，這一部份的設計如果你的事件規劃好後，問題管理是相對簡單的，它的難不在於程序，而在於日後的應用。
問題的統計報表，基本上與事件的緯度類似。
七、變更管理
在ITIL中變更與發佈是兩個獨立的流程，在我們規劃時把這個流程與合併爲一個了，發佈的控制在程序中可以實現的控制點是很少的，而且它與變更是如此緊密，在我理解中，變更的實施就是發佈流程，即發佈可以理解爲是變更的一個子流程，發佈並不僅僅是針對軟件的，硬件一樣也會有發佈的概念，比如將一臺新設備佈署到生產環境中。
對CMDB的控制，在業務層面全部是需要通過變更來實現控制的，所以CMDB精確度如何，很大程度上取決於變更的執行情況。這裏特別需要寫說明的，我們在規劃中考慮到一點，如果讓CMDB的信息更新得到真正有效的控制，當工程師在填寫變更申請時，在界面上就提列出變更前後的具體信息，在審批時，不光是審批變更的行爲，更重要的是要審批變更的內容，如果審批通過，執行後，就會根據這些信息把CMDB做更新，這樣可以相對減少沒有約束的對CMDB更新的行爲。
變更管理爲什麼而存在，在業務上起到什麼作用，這些我覺得很多人沒有想清楚，很多時候變成變更管理主要爲目的是爲了實現對CMDB的維護控制，這是對變更管理的曲解，這裏一點上我也犯過這種毛病，變更的主要目的是授權與控制對基礎架構或其它的服務的改變，注意這裏說的更新是指現實的服務或物理上的基礎架構，而不是你係統中數據的更新，100條變更請求並不是最終全部會落入到CMDB的更新中，可能有5條是對SLA的變更，所以變更與CMDB不是劃等號的，當你的工程師對具體的一些設備做維護時，事實上你已賦予他改變基礎架構的權利了，如果他把生產環境中的CI做了改變，那他再走變更管理的意義是什麼？是爲了控制他對CMDB的更新嗎，這種控制反而是起到負作用了，如果無法控制別人對生產環境的變更行爲，或者你是默認授權的，最後給予一個通道讓他直接可以維護CMDB，比如一名桌面工程師，他在修電腦的過程中，把一臺電腦的操作系統升級了，這時他要走變更管理流程嗎？我的回答是不應該，除非他不得到批准就不能對操作系統做升級，這時變更才具有意義，不然這種控制完全負面的，如果這個工程師在修電腦的過程中，發現是硬盤徹底壞掉了，這時需要更換硬盤，此時有可能超出了他的權限範圍（這也需要考慮到具體業務定義），這時他不走變更流程根本無法得到硬盤，這時變更才具有一定意義，但這種情況並不是最具代表性的，這樣的業務情形最具有變更管理的代表性：要對一段網絡做調整，但是有可能會影響到幾個系統項目，這時需要發起變更申請，由涉及到的幾個項目負責人與網絡領域的主管一同做變更的評估，如果認爲有方法對應，可以進行此次變更的話，此時需要製作一個變更的實施方案，然後安排人員進行具體的調整操作實施。實施完成，把CMDB中的信息更新。
變更管理的統計報表，可以從發起源統計，可以從CMDB的角度發起統計，也可以從變更本身的信息進行統計，比如變更的狀態、變更的分類，變更的人員等
八、配置管理
配置管理模塊，核心的就是CMDB，這一點我寫了不少這方面的文章了，就不再囉嗦多了，把配置管理的流程層面的一些點再說明一下。
CMDB的審計2
CMDB審計是需要規劃好的，應該可以根據各種條件審計，比如根據某一類的組件，某一個項目的組件，還可以確定一定的數量進行審計（隨機抽取）也可以決定一定的比率（隨機抽取），審計的目的是爲了檢查CMDB的數據正確情況，找出問題並修正。
CMDB的鎖定2
CI在某些情況需要進鎖定，比如變更時，比如審計時，爲什麼要這樣呢，如果你對一個CI變更時，不鎖定這個CI的信息，會發生同時幾個地方對這個CI做信息更新，由於時間差，很可能把錯誤的信息更新到CMDB中了，同時用戶在變更過程中調用CI信息的話，也會發生誤導，所以需要控制單線程的對CI進行維護，在同一時間只能有一個對CI維護的動作進行。審計也是一樣，如果你審計開始時，這個CI信息一直在動態的變化，不鎖定CI的話，審計無法進行，同時會審計出一個錯誤的結果。
配置管理的信息可以被許多模塊調用，需要規劃到CI查詢的畫面，然後置入到事件、問題、變更、操作等模塊中，CMDB的人機界面相當關鍵，要儘可能的方便調用、查詢、操作。
九、操作管理
操作管理爲了處理那些非事件、問題、變更等事務，比如機房巡檢，定期的機器清潔、檢修，操作管理可以創建作業，作業的來源有兩種來源，一種是直接創建的，比如臨時要對一臺設備做檢測，一種是根據週期性作業計劃產生的，比如服務器每日要檢查數據文件、表空間使用情況、JOB運行情況、操作系統日誌。操作管理與能力管理中的監視計劃是存在許多聯繫的。
說到操作管理，有一種東西需要特別，就是服務日曆，我覺得可能這是第一次有人清晰定義“服務日曆”這一概念，注意不是工作日曆，而是服務日曆，什麼是服務日曆呢，我們想想跟客戶簽訂的運維合同時，我們承諾客戶我們的服務是8*5或16*7，這種承諾表示在這個時間期內，我們週期性的任務是需要與之相配的，比如我們上面說的服務器巡檢，如果每4小時需要做一次，我們跟客戶籤的是一年的8*5的合同的話，那麼我們每週要做5*2次巡檢，這個次數是事先定義好的，每個項目的服務日曆是可能不同的，這表示我們每一個項目都可能存在一個服務日曆，根據這個服務日曆，我們在系統中製作出一個週期性的計劃，系統根據服務日曆與你的計劃內容，每天提前生成出作業指令給工程師，計劃上還定義了標準的工時要求與作業要求，工程師每天把這樣指令做完，然後把相關的作業關閉，並留下相應的實際工時，這就是操作管理的核心。
操作管理主要功能點有製作計劃、創建作業、作業處理、作業關閉、統計分析，在功能界面是相對簡單的，但這一個模塊還可以把除事件、問題、變更之外的工程剩餘的活動有效管理起來，而且可以保證你的服務作業可以得到強制執行，它最後可以針對每一個批量計劃做分析，分析執得如何，花費了多少服務資源，要注意的是操作管理與事件管理沒有做程序接口，就是說如果工程師在巡檢時發現故障，需要手工在事件管理創建事件，而不是自動去觸發事件。
十、任務管理
任務管理的本意是爲了管理我們的管理資源，這可能是針對我們公司自身的運維管理特點設計的，每年我們做許多管理改善的工作，我們做很多培訓，我們開許多的會議，我們一直想分析一下我們花在管理上的資源是多少，我們希望把這種管理工時與直接生產工時做一個比率分析，我相信許多公司很有興趣想知道一年下來我們花在會議上有多少工時，這是我們管理效率提升一個非常重要的基礎數據。
在很多時候，領導安排一個任務出來，這個任務是需要各個業務主管理去解下去的，在以前最後這個任務沒有被有效的監督與執行，同時這個任務花了多少時間也是不清楚的，比如領導要求各個領域開展員工能力提升活動，在任務管理中，只需要部長生成一個任務，然後把這個任務派給各個業務主管，任務中會標明要求完成的時間點，每個業務主管會接到這個任務，會展開作業，此時作業過程的記錄與工時會不斷的增加在這個父任務上，一直到完成審請關閉時，當這個父任務每一個子任務都關閉時，父任務可以關閉，並統計出花費的資源情況，任務可以多層分解，甚至可以分解到每一名員工身上，這相對可以加強任務的控制力度，也會某種程度控制管理人員過度的使用資源。
任務管理更多是爲了管理者的工作而設計的，這也是運維服務作業中最後一塊沒有被記錄的話動，這樣下來後，事件、問題、變更、操作、任務就構成了任何一個運維服務人員，無論他是領導還是一線員工的作業平臺，只有監視所有的活動，你的資源使用才被全部監視。
任務管理的報表會有針對任務執行情況的，還有橫向分析任務類型的，即哪一些任務的資源佔用情況，如果數據積累足夠多時，我想這種分析展開，會讓我們非常吃驚，運維服務的大量資源是被無效使用的。這樣我們運維服務管理纔有改善的方向與具體指標。
十一、 SLM管理
某種程度上，我們的ITSM系統並沒有實現真正意義的SLM管理，系統中並不關心SLA制訂出來前的過程，也沒有把UC與OLA等納入其中，我們只把制訂出來的SLA設置在系統中，以實現監控與作業。所以以下說的是SLA的管理實現方式
SLA在我們業務中我們分爲了故障解決率與Q指標，而EUS（客戶滿意度）是另一個緯度的數據，並不在此提列。故障解決率是指在規定時間內完成事件處理的百分比，Q指標是持續運行時間。
具體談一下我們的實現方式，前面說的服務日曆是很重要的一個基礎數據，沒有它SLA的計算全部都會錯誤的。我們把事件分成了5個等級（SLA只適用於事件處理），每一個項目都會針對每一個事件等級設置解決時間要求值（比如一級事件需要2小時，二級事件需要4小時，三級事件6小時，四級事件8小時，5級事件12小時），注意這裏定義的時間值是與服務日曆匹配的，比如服務日曆定義是5*8是指週一至週五的8：00-12：00，14：00-18：00，這時如果一個一級事件是發生在週五的1 7：00，即便是第二週的週一的8：30解決也是沒有違反SLA的（雖然現實中我們會馬上處理，但在硬性的SLA的計算是如此）。另外Q指標的定義是這樣的，每一個項目要定義清楚到底哪一個事件等級會納入Q指標的計算中，比如一級、二級事件的故障時間（從事件創建到事件解決）會納入計算，三、四、五級的事件故障時間就不納入計算，這樣隨時可以計算你的當前的Q指標是多少。
SLA設置完成後，就會在事件中就用，當你把事件定位在一個項目時（CI），你選擇了事件等級，此時系統會調出事件解決的時間要求，當你創建完成時，系統開始倒計時。
SLA的報表主要是針對故障解決率與Q指標的，只是統計的緯度可能是多樣的。
十二、知識庫管理
知識庫管理考慮現實情況，我們沒有做得太複雜，運維服務的知識是有比較強的時效性的，知識更新較快，這裏說的知識是指針對故障處理方面的，並不是指針對員工的技能或知識培養方面，這與通常說的KM還是有不少區別的。
考慮到運維過程中的知識是非常具有針對性的，所以沒有把那種通用的知識納入考慮，都是以項目的角度出來，知識的創建有三個來源，一是事件生成，二是問題生成，三是手工創建，爲了便於查找，我們的做法是以項目爲綱，以分類爲目，以關建字爲輔，即最根本的分類是項目，然後是根本事件問題的分類，最後是用關鍵字，用這幾個手段進行查找知識點，供工程師在處理事件時調用查看。
無論知識是從事件或問題還是手工創建，都會有一個審批的過程控制知識庫的更新，同時還可以設置知識有效期限，因爲許多知識點或能在項目的特定時間內有限（比如針對某個版本），事實上如果知識庫納入後不進行更新維護，最後可能會誤導工程師，起到負作用，所以知識庫的更新與停用也是需要考慮好的。另外知識庫的創建可以做一些統計與分析，看哪一個團隊的知識複用較多，哪一種類型的知識較多。對於知識的利用，不建議納入系統考慮，因爲在軟件中是非常難以識別知識是否被調用的，靠點擊意義不大，一個人打開知識看後，可能發現根本不是他想要的，或者他只是借鑑看一下，這時強迫按鈕操作沒有意義。
十三、調查管理
調查管理原本是希望改變以前那種手工發郵件採集滿意度調查的做法，後面在設計時，發現可以對象化，做得更靈活些。所以我們在規劃時，我們是這樣考慮的，可以設計許多問卷，這些問卷可能是針對客戶滿意度的，也可能是爲了調研我們的服務方式改進方向的，也可能是爲商業的考慮瞭解服務產品化的潛在空間的，問卷設計好後，可以生成調查任務，這時引用調研問卷，一個問卷可以被無限調用，而調查的結果是針對調查任務而不是針對問卷的。
調查可以直接髮網址到客戶郵箱（取自客戶數據），也可以直接把問卷發過去，如果是WEB採集數據，可以生成用戶名與密碼發到客戶郵箱，用戶登陸系統填寫，也可以手工回收，但WEB是省力的，因爲調研結果由系統自動生成。有一些細節地方需要考慮，比如任務的開始與結束時間來決定問卷填寫開始與停止，是不是設置必填與可選，是翻頁填寫還是整頁顯示，甚至你的問卷的答案選項與分值設置，還要注意調研對象散與客戶資料的集成（從某一個客戶組織選擇一定百分比）還有CMDB（針對某一個系統或項目）的接口。
基本上把我們大的模塊寫完了，一路寫下去，發現有些跑題了，狀態不是很好，有些大雜燴，有些地方不夠深入，也沒有真正一個ITSM系統每一個模塊應該具備的元素提煉好，象一些績效點沒有體系的寫出來。大家湊合着看吧。有一些可惜，後續我沒有時間把每一模塊深入考慮好，加上開發團隊離我的期望要求有比較大的差距，沒有足夠的時間與足夠的資源，不然我很有信心做出中國最好的一款ITSM系統，但就算目前的情況，我的許多設計仍然是國內的公司在一段時間很難企及的，這裏包含許多年來各種各樣的思考，軟件的，管理的，ITIL的，對運維業務本質的理解。不過可能只有一家從事這種系統開發的公司或個人在看到時，才能真正知道其中的價值。