AdvancedITIL: 服務支援指標

服務支援指標

組態管理

第 9 章

「組態」通常被視為「ITIL 服務管理」的核心，因為每個其他程序都需要利用「組態管理資料庫」(CMDB)。因此，保持 CMDB 的正確性並及時加以更新是非常重要的。只要考量到 CMDB 的重要性，便不會對「組態管理」同時具有管理報告和 KPI 一事感到意外。在探究建議的指標前，應該提醒自己「組態項目」(CI) 是 CMDB 中的項目。我們先從管理資訊開始：

  • 組態稽核的結果。
  • 偵測到的任何未登錄或錯誤登錄的 CI 及修正動作相關資訊。
  • 已登錄的 CI 和 CI 版本數目，並依 CI 類別、類型和狀態細分 (可能的話也依位置或其他 CI 屬性細分) 等資訊。
  • 成長與容量資訊。
  • 關於 CI/CMDB 變更率及 DSL (限定軟體程式庫) 的資訊。
  • 「組態管理」工作的任何積存或「組態管理」活動所導致的任何延遲，以及提議的補救措施等細節。
  • 「組態管理」人員配置。
  • 由其他 IT 服務人員於下班時間完成的已授權工作量。
  • 「組態管理」系統的效率/有效性檢閱、成長檢閱和稽核的結果，以及處理實際或潛在「問題」的提案。
  • 依類型 (如服務、伺服器、路由器、集線器、軟體授權、桌上型電腦等) 劃分 CI 數目的資料與分析。
  • CI (或資產) 的價值。
  • 依事業單位、支援小組或服務劃分的 CI 位置。

如您所見，管理資訊主要與下列三個領域相關：CMDB 的正確性、CMDB 的內容分析，以及維護 CMDB 的人力。讓我們個別查看每個指標：

組態稽核的結果。ITIL 建議時常對 CMDB 進行稽核，以驗證其內容符合事實。例如，若某個部門有 50 台工作站，則 CMDB 中也應該有 50 台工作站，且每台工作站的所有細節都應該正確。ITIL 建議下列時候必須執行稽核：

  • 剛完成建置新的「組態管理」系統時。
  • 對 IT 基礎架構進行重大變更之前和之後。
  • 軟體「版本發佈」或安裝之前，以確認環境如同預期。
  • 從災難中復原並「返回正常」後 (此項稽核應包含在偶發事件計劃中)。
  • 以隨機時間間隔。
  • 因應偵測到任何未經授權的 CI 時。
  • 以定期時間間隔。

許多組織採用滾動式稽核計劃來執行「快照」稽核，也就是按照預定排程執行 CMDB 的「部份」稽核，例如，在一月稽核伺服器、二月稽核電信設備、三月稽核桌上型軟體等。若您採用自動化稽核工具，ITIL 也建議您每週執行 CMDB 稽核。執行這項稽核的同時，應該分析「意外資料庫」和「問題資料庫」，以找出是否有任何記錄是由於 CMDB 問題而產生。

此外，「服務中心」應立即報告由「服務中心」代理人偵測到的任何不符之處，例如，當代理人在分析錯誤時，發現工作站中實際安裝的軟體版本與 CMDB 中記錄的版本不同。稽核有助於確保 CMDB 維持在正確狀態，這是高品質「服務管理」不可或缺的要件。此外，「沙賓法案」(Sarbanes-Oxley Act) 更將正確 CMDB 的重要性提昇到了前所未有的境界。在發送此報表前，請標示稽核中所發現的任何不符之處，並將此稽核結果傳送給所有 IT 經理。

  • 商業協調指標 – 這可能是所有 ITIL 服務管理程序中最具關鍵性的商業協調重點，主要便是因為「沙賓法案」(Sarbanes-Oxley Act)。所有稽核結果都應發送給主要負責「沙賓法案」之符合性的商業經理，例如 IT 稽核小組或內部稽核小組成員。稽核結果也應發送給與稽核中找到的不符之處有關的商業經理。此外，商業經理應可針對其所擁有或控管的任何 IT 基礎架構項目，自行執行稽核檢查。若要自行執行稽核，商業經理必須可以檢視所有與其環境相關的 CI。

偵測到的任何未登錄或錯誤登錄的 CI 及修正動作相關資訊。這個指標是從上一個指標中的稽核衍生而來，此處的關鍵在於這個指標並非只提供資料，它同時還指定修正動作。編譯此報表時，請記得納入遺失的「組態項目」(CI)。報表中應說明 CMDB 如何變得不正確，以及將採取哪些動作防止相同錯誤重複發生。編譯此報表時，也應分析「意外資料庫」和「問題資料庫」，以找出是否有任何記錄是由於 CMDB 問題而發生。此外，應該立即報告由「服務中心」代理人偵測到的任何不符之處，例如，接到修復某個 CI 上的「問題」之要求，而該 CI 並不在 CMDB 中。此報表的結果應發送給主要負責落實「沙賓法案」之符合性的商業經理，例如稽核小組內的成員，並且至少發送給與報表中標示的錯誤之處有關的商業經理。

  • 商業協調指標 – 這是另一個 ITIL 服務管理程序中的關鍵性商業協調重點，主要便是因為「沙賓法案」(Sarbanes-Oxley Act)。請確認負責落實「沙賓法案」之符合性的商業經理可收到這份報表，例如首席財務長。

已登錄的 CI 和 CI 版本數目，並依 CI 類別、類型和狀態細分 (可能的話也依位置或其他 CI 屬性細分) 等資訊。此資訊顯示在列出 CMDB 內容的報表中，您可採用線上或書面形式提供此報表。 如指標中所述，除了類別、類型和狀態外，還可使用符合您需求的其他類別進一步細分報表。您應該洽詢所有其他 IT 部門，確認他們是否需要 CMDB 依任何特定群組列出，以及偏好收到書面報表或在線上檢視。此外，為了規劃之目的，他們很可能比較有興趣知道總數，而非詳細資訊。因此，請徵詢其他 IT 部門的意見，瞭解他們需要詳細的分析或是總數就好。此報表應提供給所有 IT 部門，而且可供所有具適當權限的人員於線上檢視。

  • 商業協調指標 – 商業經理可能擁有其環境中的 IT 設備，或是負責這些設備。在任何情況下，商業經理應該收到這份報表，或是可在線上檢視其 CI，以便他們能夠追蹤其「組態項目」。請確認將此報表提供給所有商業經理。

成長與容量資訊。因為缺乏容量而使 CMDB 變得不正確是不可接受的，顯然地，「容量管理」應負責計算並設計 CMDB 的容量，這需要有成長與容量資訊，以瞭解 CMDB 的目前大小、CMDB 可用空間量和已知規劃的新 CI 清單等。除了確認將此資訊提供給「容量管理」小組外，也應該提供此資訊給「組態管理」小組，使他們可追蹤日常的容量，確保沒有令人不滿的意外狀況。您應該繪製指定時期內的 CMDB 大小變化，以圖解說明 CMDB 的成長率。例如，您可以建立一個圖表，顯示過去 12 個月中每個月份的資料庫大小。除了「容量管理」和「組態管理」小組外，其他 IT 經理不太可能需要此資料；不過，還是要洽詢其他 IT 經理，瞭解他們是否有興趣收到此報表。

  • 商業協調指標 – 商業經理不太可能會需要這份報表，不過，他們可以提供有助於計算 CMDB 未來成長率的資料，您應該要求每位商業經理提供任何關於未來成長或是其環境中的重大變更等資料。

關於 CI/CMDB 變更率及 DSL (限定軟體程式庫) 的資訊。您或許難以理解為何需要此資訊，因為它與環境因素如此高度相依。例如，若您要在所有工作站上安裝新版軟體，您事先已知道將有許多變更，那麼為何還需要此資訊？原因如下：關於變更的資訊 (由「變更管理」提供) 可用來和 CMDB 中的變更資訊比較，以發掘任何異常或不正確狀況。此資訊一般是由「組態管理」使用，不過也可以由「變更管理」使用。此資訊可以只提供簡單的變更率清單作為管理參考，或者也可用於標明變更問題。

  • 商業協調指標 – 除了與已經確定不正確的「變更」有關的商業經理外，其他商業經理不太可能需要此資訊。

「組態管理」工作的任何積存或「組態管理」活動所導致的任何延遲，以及提議的補救措施等細節。這個指標相當重要；CMDB 必須保持正確並反映 IT 基礎架構目前的狀態。這個指標包含下列兩個因子：「組態管理」工作的積存，以及「組態管理」活動對其他 IT 部門造成的延遲。

我們首先探討第一個因子：積存。造成 CMDB 更新延遲的可能原因有很多，例如，管理決策有瑕疵、「意外」延遲解決、太慢變更及財務計算錯誤，這就是為何必須立即報告「組態管理」中可能導致 CMDB 更新延遲的任何積存。

此指標的第二個因子是「組態管理」活動所造成的延遲，例如，由於其他 CMDB 活動使得 CMDB 無法或尚未更新，因而導致「變更」必須延遲。同樣地，請務必立即報告由「組態管理」活動所導致的任何延遲，且必須即刻通知可能受延遲影響的 IT 經理。此外，立即通知資深 IT 管理人員任何積存或延遲的情形也相當重要。最後一個項目是提議的補救措施，這也具有關鍵重要性。請務必針對每個回報的積存或延遲問題提出補救措施，以避免日後再度發生。

  • 商業協調指標 – 您可料到任何曾受到「組態管理」積存或活動導致的延遲所影響的商業經理，會希望看到這份報表。此外，商業經理有可能因為沒有發佈更新 CMDB 的所需資訊而導致積存；因此，請務必立即通知任何遭到延遲或造成延遲的商業經理。

「組態管理」人員配置。此處有點棘手，因為「組態管理人員配置」指標並未明確定義。在沒有任何額外資訊下，我們只好假定它是估量是否有足夠的訓練有素員工投入「組態管理」作業。若是這種情況，則會產生顯示已完成工作、已排程工作和可用員工數的定期報表，透過此報表便可瞭解人員配置狀況。此報表的適用對象是負責「組態管理」的資深 IT 經理。

  • 商業協調指標 – 只有負責「組態管理」的商業經理才會對此報表感興趣。

由其他 IT 服務人員於下班時間完成的已授權工作量。在「組態項目」生命週期管理的程序中，可能會有非 IT 服務人員的員工定期更新 CMDB。例如，採購人員可能會在下訂單時更新 CMDB、設備接收人員可能會在收取新工作站貨品時更新 CMDB、「桌上系統服務」人員可能會在安裝工作站時更新 CMDB。如稍前所述，總是會有一些例外狀況可能導致一段短時間內需要額外人力，包括：

  • 剛完成建置新的「組態管理」系統時。
  • 對 IT 基礎架構進行重大變更之前和之後。
  • 軟體「版本發佈」或安裝之前，以確認環境如同預期。
  • 從災難中復原並「返回正常」後 (此項稽核應包含在偶發事件計劃中)。

上述任一情況都可能產生對 CMDB 的大量更新，且所有更新必須在短時間內完成。因此，CMDB 的維護者可能需要在有限時間內獲得一些協助。理想上，所有工作應由 IT 服務人員或其他獲授權人員在上班時間內完成，因此，必須仔細追蹤在「下班時間」完成的額外工作，並採取適當動作以確保日後所有工作都能在上班時間內完成。您應該針對下班時間完成的工作編譯一份定期報表，並將其傳送給所有 IT 經理，特別是負責維護 CMDB 的 IT 經理。

  • 商業協調指標 – 對於任何負責更新 CMDB 的員工，其主管必定希望收到這份報表。

「組態管理」系統的效率/有效性檢閱、成長檢閱和稽核的結果，以及處理實際或潛在「問題」的提案。這是先前的許多管理資訊指標的集合，理想上，您應該建置一個集中點，例如某個內部網路位置，讓任何有興趣的人都可檢視此處所列的所有項目結果。

  • 商業協調指標 – 所有商業經理都應該具有此重要資訊來源的即時線上存取權。

依類型 (如服務、伺服器、路由器、集線器、軟體授權、桌上型電腦等) 劃分 CI 數目的資料與分析。此管理報表中的資訊似乎已在前文中探討過，不過此處的主要差異在於「分析」一字。前面我們討論的是「清單」和「總數」，而此處討論的是有關 CMDB 的分析。您應該執行兩種分析：定期排程的分析，以及因獨特狀況而要求的特別分析，例如需要「版本發佈」規劃資訊。只有您能決定如何以定期排程方式分析 CMDB，您還必須建立一個方法，讓 IT 部門可用於要求 CMDB 的特別分析。定期排程報表應發送給所有 IT 經理，而特別報表只應發送給由提交特別要求的經理所指定的 IT 經理。

  • 商業協調指標 – 所有商業經理都應收到定期排程報表，而特別報表只應發送給由提交特別要求的經理所指定的經理。

CI (或資產) 的價值。這個指標有可能由另一個稱為「財務管理」的 ITIL 程序為 IT 服務處理。若確實要在 IT 中產生此報表，必須以「組態項目」中所含的財務屬性為基礎。若您已將財務屬性納入 CI 記錄中，便可產生多種報表；不過，此需求只適用於您的 CI 和資產價值。雖然您可以產生只提供所有資產總值的報表，更實用的做法是在報表中顯示每個不同 CI 類型的總值，例如工作站的價值、膝上型電腦的價值，以及桌上型軟體的價值等等，如此可產生更具意義的報表，且包含有用的預算資料。此報表應定期發送給擁有 IT 資產的所有 IT 經理。

  • 商業協調指標 – 財務部門必定會對這份報表有興趣，某些其他部門或許也是如此，例如採購部門。若報表中顯示的資產價值是依商業領域劃分，例如部門或單位，那麼商業經理可能也會希望收到此報表。請與商業經理討論，瞭解他們偏好的報表格式以及希望在報表中涵蓋的期間。

依事業單位、支援小組或服務劃分的 CI 位置。此淺顯易懂的報表提供有關規劃與資產管理的重要資訊，它應該是一份簡單的報表，而且需要您在 CI 中納入必要的屬性，以便可以按照位置列出 CI。設計您的 CI 時需要特別小心注意，如此才能產生具有所需詳細層級的報表。此定期報表應發送給所有 IT 經理，特別是在稽核到期時。

  • 商業調整指標 – 這是另一份提供給所有商業經理的重要報表，商業經理應該收到有關他們所控管的所有資產的定期報表。

現在我們便有一組完整的「組態管理」管理報表，它們不但提供至為重要的資料給 IT 和商務部門，同時包含可協助貴組織符合法律義務的必要資訊。這些報表中的許多資料將用於識別並驗證「關鍵績效指標」：

  • 「組態」未經正確授權的情況。
  • 由錯誤執行的「變更」所導致的「意外」和「問題」。
  • 由於不良的影響評估、不正確的 CMDB 資料或不佳的版本控制以致沒有成功完成的「變更要求」(RFC)。
  • 核准及實施「變更」的週期時間。
  • 浪費或未在特定位置使用的授權。
  • 在組態稽核期間回報的例外。
  • 偵測到使用中的未經授權 IT元件。

這些是相當清楚的 KPI，若要使「組態管理資料庫」保持為用於決策過程與管理規劃的正確資源，則需要符合所有這些 KPI。讓我們個別查看每個 KPI：

「組態」未經正確授權的情況。每當找到不正確的組態時，即表示未達成此 KPI，我們先前討論的一些管理報表標明許多組態不正確的情況。

  • 商業協調指標 – 每個商業經理應該可在需要時檢視其組態，或至少可檢視其資產，若您發現其組態未經正確授權，便需要通知他們。您只需要通知具有未經授權組態的商業經理，除非您認為通知所有商業經理可提醒其他經理注意其組態是否有相同「問題」。

由錯誤執行的「變更」所導致的「意外」和「問題」。如以上陳述，此 KPI 似乎屬於「變更管理」的一部份，不過此處我們討論的是「組態管理」，如果在此陳述中加入「由於組態管理問題」等字，就比較能清楚瞭解其意思。此 KPI 的目標是零「意外」或零「問題」，如果並非兩者都是零，則必須進一步調查原因，並採取適當動作防止再度發生。

  • 商業協調指標 – 如果錯誤執行的變更所導致的「意外」和「問題」已對商業經理造成不便，那麼他們很有可能早已知道此事。不過，為了確定起見，您還是應該通知受影響的商業經理，並詳細敘述「問題」和「意外」的本質，更重要的是說明為防日後再度發生所採取的動作。

由於不良的影響評估、不正確的 CMDB 資料或不佳的版本控制以致沒有成功完成的「變更要求」(RFC)。如果有任何 RFC 因為「組態管理」問題而未成功完成，這大概會是當時最重要的問題，必須對其進行詳細的分析，並採行建議的解決作法。這是具有關鍵重要性的 KPI，無法達成此 KPI 將被資深 IT 管理人員視為重大的「組態管理」失敗。此指標的目標必須是沒有任何一個 RFC 因為「組態管理」問題而未成功完成。

  • 商業協調指標 – 如果商業經理的 RFC 因為「組態管理」問題而沒有完成，那麼他們當然已得知此問題。不過，為了確定起見，您還是應該通知遇到不便的商業經理，並詳細敘述其 RFC 無法成功完成的原因，更重要的是說明為防日後再度發生所採取的動作。

核准及實施變更的週期時間。此 KPI 的確切需求並不容易確定，每個「變更」都是唯一的，因此，每個「變更」的週期時間都具有獨特性。不過，每個「變更」生命週期中的不同階段應該有其排程時間，必須符合的便是這些週期時間。為了使這個 KPI 的意義更明確，可將它改為「因組態管理問題而對核准及實施變更的週期時間造成的延遲」，如此便能得到一個可評量的 KPI，且其成功標準為零延遲。您應該擬定一套計劃和行動，以排除任何導致「變更」生命週期延遲的「組態管理」根本問題。請注意，除了因為「組態管理」內部的缺失外，也可能由於規劃不佳而造成延遲，例如對 CMDB 進行大量更新，或是工作負載計算錯誤等情形。「組態管理」小組應充分參與所有變更的規劃過程，以確保預測的時間和工作負載均切合實際。

  • 商業協調指標 – 在此情況下，商業經理可能同時扮演「被害者」和「加害者」的角色。如果商業經理的變更遭到延遲，他們可說是「被害者」；如果他們負責某些「組態管理」活動，例如更新 CMDB，但是並未達成其應盡義務，他們就變成「加害者」了。有趣的是，某一商業經理有可能延遲另一商業經理的變更，例如，財務部門提交的「變更」遭到延遲，因為採購部門沒有及時輸入為此「變更」而採購的新設備之 CMDB 資料。通知所有受延遲影響的商業經理。

浪費或未在特定位置使用的授權。這是另一個似乎不屬於此處的 KPI，因為授權管理是「版本發佈管理」的一環，那麼這個 KPI 為何放在這裡？這是因為「組態管理」錯誤可能是導致浪費或無用授權的原因。例如，「版本發佈管理」可能在稽核時發現某些授權不在使用中，因為「組態管理」並未正確更新 CMDB。另一個例子是，「組態管理」小組已新增工作站，但是並未通知「版本發佈管理」小組，於是導致不符授權規定。同樣地，我們可在此陳述中加入「由於組態管理中的錯誤」等字，以使這個 KPI 更具相關性。此 KPI 的目標應該是零，若未達成目標，必須採取適當動作防止問題再度發生。

  • 商業協調指標 – 此情況也可能使商業經理同時扮演「被害者」和「加害者」的角色，如果商業經理並未使用所有已付費的授權，他們就算是「被害者」，如果他們負責某些「組態管理」活動，例如更新 CMDB，但是並未達成其應盡義務，他們就變成「加害者」了。同樣地，某一商業經理的行為有可能對另一商業經理造成負面影響。請通知所有受到未充分利用授權所影響的商業經理，並與他們共同合作，確定是否能終止無用的授權以節省寶貴預算。

在組態稽核期間回報的例外 – 此 KPI 並未說明應尋找的例外狀況為何，不過，由於 CMDB 應該始終保持正確，因此我們可大膽假設任何例外都應加以注意。此 KPI 的目標應該是零，且應採取適當動作防止再度回報任何例外狀況。

  • 商業協調指標 – 您應該在發現例外狀況時通知任何受到影響的商業經理，也就是說這個指標並不需要牽涉到所有商業經理；不過，您應該知會負責「組態管理」以及造成例外狀況的商業經理，並要求這些商業經理達成此 KPI 目標。

偵測到使用中的未經授權 IT元件。任何使用中的未經授權 IT 元件，應該會在本節前面所探討的稽核程序中標示出來，因此，您不需要在此執行分析，只要報告偵測到的任何使用中的未經授權 IT 元件即可。此 KPI 應該是零。

  • 商業協調指標 – 只有受影響的商業經理才需要關於此 KPI 的意見回饋，除非他們須對允許使用未經授權 IT 元件這件事負責。這是必須嚴肅看待的事情，因為將未經授權的元件引進基礎架構和組態中，可能會導致嚴重的「問題」和延遲。此外，某些元件 (例如從網際網路下載的元件) 可能會引發諸如病毒或駭客路徑等安全問題，因此，必須立即通知允許在「組態」中使用未經授權 IT 元件的商業經理。

在「組態管理」一章的末尾處，ITIL 也建議了其他可能相關的 KPI：

  • 在每個月接到的「服務中心」來電中，可於使用者仍在電話上時解決而不需進一步上報的來電比例之變更。
  • 「意外」和「問題」的數目與嚴重性之變更。
  • 診斷與解決無法立即解決的「服務中心」來電之平均時間與成本的變更。
  • 「服務層級協議」遭違反情況的數目與嚴重性之變更，且「問題」可歸因於「變更管理」、「組態管理」、「版本發佈管理」、「問題管理」或「服務中心」等功能所造成的錯誤。
  • 每月由於 CMDB 中找出的錯誤而對 CMDB 進行變更的次數。

如您所見，這些 KPI 比先前所討論的 KPI 更具一般性，不過它們仍然相關。若您初期只能處理少數幾個 KPI，則應該以先前所述的 KPI 作為建置起點。

現在，讓我們看看這些額外的「組態管理」KPI：

在每個月接到的「服務中心」來電中，可於使用者仍在電話上時解決而不需進一步上報的來電比例之變更。此 KPI 的成功標準是「服務中心」可於使用者仍在電話上時解決、而不需進一步上報的來電持續增加。這表示此 KPI 應該逐月成長。理論上，CMDB 的正確性和完整性越高，「服務中心」可於解決「問題」時隨手取得的資訊便會越多，這有助於提高第一層解決比例。如果解決比例下降，則應該展開調查。

有趣的是，解決比例下降不一定代表出現「問題」。例如，假設在某個狀況中已將導致大量「意外」的「問題」排除，原本服務中心員工可在第一次來電時解決這些「意外」，因為他們具備暫時性的替代做法，不過，排除「問題」後也同時消除了這些「意外」，使得在第一次來電時解決的「意外」數減少。因此，第一層解決比例會下降，不過遇到「問題」的客戶之滿意度卻會提高。

  • 商業協調指標 – 如先前所述，「服務中心」和商務社群通常已在 SLA 中列入議定的「第一次來電解決」服務層級，若是如此，則商業經理應該會收到關於此 KPI 的報表。如果沒有收到，則應該定期將此報表發送給他們。

「意外」和「問題」的數目與嚴重性之變更。此 KPI 並未指出變更應增加或減少，增加需要進一步調查，但是減少通常不需理會，除非減少幅度異常的大。請分析「意外」和「問題」資料庫，以識別「意外」和「問題」的數目與嚴重性之變更。若在「意外」或「問題」資料庫中發現變更情形，則應立即展開調查，並採取適當動作以期返回原狀。在執行分析時，請記得其目的是「組態管理」，因此，發現任何不屬於「組態管理」的數目或嚴重性增加情形時，應報請適當的程序擁有者執行進一步的調查與行動。若此增加情形確實屬於「組態管理」的一部份，則需要確定成因並採取適當動作將其排除。您應該定期監控此 KPI – 最低限度為每週一次。當然，發現任何變更即代表不符合此 KPI 目標。

  • 商業協調指標 – 多數商業經理不需要看到此分析結果，除非他們遇到「意外」和「問題」數目增加或嚴重性改變的情形。您應該將此 KPI 的報表發送給受影響的商業經理，並與其洽談。

診斷與解決無法立即解決的「服務中心」來電之平均時間與成本的變更。這個 KPI 也沒有指出變更應增加或減少，增加需要進一步調查，但是減少通常不需理會，除非減少幅度異常的大。IT 服務支援的飽受批評之處，在於「意外」如果未在第一次來電時解決，便會花很久時間才能解決，這就是為什麼此 KPI 相當重要。

「意外資料庫」或「服務中心資料」中通常會提供此資訊，因此您應該每日監控適當的資料庫。在執行分析時，請記得其目的是「組態管理」，因此，發現任何不屬於「組態管理」的數目或嚴重性增加情形時，應報請適當的程序擁有者執行進一步的調查與行動。然而，若增加情形確實屬於「組態管理」的一部份，則需要調查成因並採取適當動作將其排除。若此處發現任何變更，即代表不符合此 KPI 目標。

  • 商業協調指標 – 多數商業經理不需要看到此分析結果，除非他們直接受到診斷與解決無法立即解決的「服務中心」來電之平均時間與成本的變更之影響。請將此 KPI 的報表傳送給受影響的商業經理，並與其洽談。

「服務層級協議」遭違反情況的數目與嚴重性之變更，且「問題」可歸因於「變更管理」、「組態管理」、「版本發佈管理」、「問題管理」或「服務中心」等功能所造成的錯誤。這是適用於多數「服務支援」程序的一般性 KPI，請立即調查每個違反 SLA 的情形，並盡可能採取任何預防再度發生的行動。不過，此 KPI 要求評量的是數目與嚴重性之變更，這是不盡相同之處，因為違反情況應該已經調查完成。此 KPI 要求定期比較數目與嚴重性，而且最好結合未來趨勢分析。若您發現趨勢存在，請立即加以調查。若有任何數目或嚴重性之變更，即代表未達成此 KPI 目標。

  • 商業協調指標 – 無疑地，任何導致違反 SLA 的變更必須回報給受影響的商業經理，並詳細說明原因及所採取的任何預防再度發生的行動。

每月由於 CMDB 中找出的錯誤而對 CMDB 進行變更的次數。許多 IT 和商業人員使用 CMDB 作為參考來源和決策工具，因此，務必要使 CMDB 保持正確。確認每月由於 CMDB 中找出的錯誤而對 CMDB 進行變更的次數保持在最小值，並立即調查任何增加情形。此 KPI 至少應該每週追蹤一次，而且最好每天追蹤。若您已採取定期檢查及適當動作來防止導致變更增加的錯誤再度發生，則變更次數應該隨時間的進展而減少。若此數目增加，即表示未達成此 KPI 目標。如果該數目減少，則表示已達成此 KPI。若此數目維持相同，您必須決定這是代表達到成功或遭遇失敗。

  • 商業協調指標 – 如果 IT 負責執行所有對 CMDB 的更新與變更，則大部份的商業經理不會對此 KPI 有太大興趣。不過，若有某些商業經理實際上會去更新或使用 CMDB，則他們一定會需要這份 KPI 報表。

如「組態管理」一節的開頭所述，管理此程序時需要多組管理資訊和 KPI，其中一些或許看來有點多餘，不過基於技術和商業理由，正確的 CMDB 是不可或缺的。在技術領域中，正確的 CMDB 可為 IT 提供重要的決策工具；在商業領域中，不正確的 CMDB 可能導致嚴重的財務損失和法律刑責，這就是為何務必要快速找出並矯正錯誤的原因。