ITSM系統的建設

這是我一直想寫的内容，苦于沒有時間與精力，本來是希望把這個項目從立項到規劃，到設計開發，到最後的實施應用的全部過程寫成一個筆記，但工程浩大，有些力不從心，正好國慶節有一些時間，就先寫一部份吧。

以下的内容會一些雜，我把我們規劃這款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（針對某一個系統或項目）的接口。