AdvancedITIL: 服務支援指標

服務支援指標

版本上線管理

第 8 章

「版本上線管理」是 ITIL 的一項重要因子，而且已在目前發行的 ITIL 修訂版本中徹底翻修。過去，「版本發佈管理」是關於管理軟體版本發佈到 IT 環境中的程序；現在，「版本發佈管理」涵蓋更寬廣的範疇，如「服務支援」專書中「版本發佈管理」一章的摘錄說明：

許多服務提供者與供應商可能會參與分散式環境中的硬體和軟體「版本發佈」，若要成功將組合版本組合成一體並將其發佈給「客戶」，良好的資源規劃與管理是不可或缺的。「版本發佈管理」從整體角度檢視對 IT 服務的「變更」，且應確保「版本上線」的所有面向，包括技術面和非技術面，均一併納入考量。(9.1. 版本發佈管理的目標)

「版本上線」意謂集合一些經過授權的 IT 服務「變更」。「版本發佈」是由其實施的 RFC (變更要求) 所定義。「版本發佈」通常包含一些「問題」修復與服務功能強化。「版本發佈」包含必要的全新或已變更的軟體，以及任何需要的全新或已變更的硬體，以實施核准的「變更」。(9.3.1. 版本發佈)

「版本發佈管理」現在是 ITIL 的主要因子，如同其他 ITIL 程序，「版本發佈管理」具有兩種類型的指標：監控「關鍵績效指標」(KPI) 及「管理報告」。以下首先討論 ITIL 中概述的 KPI：

  • 在不超過預算資源下，按照排程建置並實作的「版本發佈」(但是應小心排除不在「版本發佈管理」的控制與責任範圍內的任何「問題」，例如應用程式開發延遲)。
  • 由於無法接受的錯誤而必須取消「版本發佈」的發生率非常低 (最好沒有) (然而，請注意軟體「版本發佈」並不需要完全零錯誤；即使存在錯誤，也可決定繼續進行「版本發佈」，但前提是錯誤本質並不嚴重，而且是在允許的容錯範圍內)。
  • 建置錯誤的低發生率。
  • 安全且正確的 DSL (限定軟體程式庫) 管理。
  • 沒有跡象顯示 DSL 中有未通過品質檢查的軟體，也沒有發現從 DSL 抽取的任何軟體有重製情形。
  • DSL 大小符合空間需求和及時且正確的 DSL 內部管理。
  • 遵守所有關於購入軟體的法律規定。
  • 將版本正確發佈到所有遠端站台。
  • 準時在所有站台上 (包括遠端站台) 建置「版本發佈」。
  • 沒有發現任何站台上有未經授權便回復至舊版的情形。
  • 沒有在任何站台上使用未經授權的軟體。
  • 對於實際上並未用於任何特定位置的軟體，沒有支付相關授權費用或浪費人力進行維護。
  • 未發現「版本發佈」建置中有無用的重複 (例如，有多個遠端站台建置，但實際上使用單一建置的副本便已足夠)。
  • 正確且及時地記錄 CMDB (組態管理資料庫) 內部的所有建置、發佈和實作活動。
  • 針對所有「版本發佈」活動進行事後剖析，並採取所有必要的修正或後續動作，以及任何程序改良。
  • 規劃的「版本發佈」組合與實際的組合相符 (證明「版本發佈」規劃良好)。
  • 「版本發佈管理」所需的 IT 和人力資源有良好的持續發展規劃。

可能如您所料，上述某些 KPI 包含的指標與「變更管理」中的指標類似，這是必然的情形，因為「版本發佈管理」原本就與「變更管理」密切相關。不過，稍後的內容中將指出幾個主要差異。

在不超過預算資源下，按照排程建置並實作的「版本發佈」(但是應小心排除不在「版本發佈管理」的控制與責任範圍內的任何「問題」，例如應用程式開發延遲)。若要使這個 KPI 可以實行，需要將此陳述擴展為：在不超過預算資源下，於最後一個曆月中按照排程建置並實作的「版本發佈」。 原始陳述並未指出 KPI 所涵蓋的時期，「曆月」只是一個說明需要指定評量期間的範例。您也必須清楚指定「不在版本發佈管理的控制與責任範圍內」的定義，以確保正確性並減少混淆。

實際上，這個 KPI 也提供一段指定時期內的成功「版本發佈」之快速檢查清單。因此，它是一個重要的 KPI，不過每個成功「版本發佈」的報告應保持在單行以內。一般來說，報表中應包含「版本發佈」的規劃日期/時間、「版本發佈」的實際日期/時間、「版本發佈」參考號碼、「版本發佈」擁有者以及超出控制的註解。為了使這份報表發揮最高價值，請與列出失敗「版本發佈」的下一個報表相比較。使用此 KPI 時，成功率越高越好。

  • 商業協調指標 – 這也是許多商業經理的「必要」報表，特別是那些在指定時期內收到「版本發佈」的商業經理。對於被視為「不在版本發佈管理的控制與責任範圍內」的「版本發佈」所引起的任何問題，準備好就此點與商業經理討論，並預期偶爾會出現關於「版本發佈」成功與否的爭論。

由於無法接受的錯誤而必須取消「版本發佈」的發生率非常低 (最好沒有)。(然而，請注意軟體「版本發佈」並不需要完全零錯誤；即使存在錯誤，也可決定繼續進行「版本發佈」，但前提是錯誤本質並不嚴重，而且是在允許的容錯範圍內)。如前文所述，此 KPI 與上一個 KPI 搭配使用。此 KPI 的值越低且上一個 KPI 的值越高，則整體效能越好。嘗試區分「已知錯誤」(您已經有暫時的替代做法並找到根本原因) 以及引起非預期「意外」的錯誤，無論錯誤的嚴重性有多低。引起非預期「意外」的錯誤應通過「問題管理」的處理程序。務必分析由於無法接受的錯誤而導致的失敗，並針對每個錯誤產生一份報表，其中說明所採取的任何措施，以確保相同錯誤不會在日後的「版本發佈」中再度發生。

  • 商業協調指標 – 雖然很有可能在此 KPI 公佈前便已知道並討論過所有失敗「版本發佈」的狀態，不過，這仍然是可與商業經理分享的重要報表，因為商業經理能提供非預期錯誤的商業影響之詳細資訊。請務必將此報表視為創造更美好未來的工具，而不是當作 歸咎責任的方法。

建置錯誤的低發生率。評量此 KPI 之前，需要先決定「低」的目標層級，例如，目標是零嗎？還是不超過百分之一？理想的 KPI 目標是零，但無論您建立的 KPI 為何，都必須完整調查所有建置錯誤。上一個 KPI 中所述的「非預期錯誤」處理準則，大部份也可套用在此處。

  • 商業協調指標 – 上一個 KPI 的「非預期錯誤」相關討論內容也適用於此處。

安全且正確的 DSL (限定軟體程式庫) 管理。此 KPI 與先前所討論的 KPI 全然不同，它無法單獨從基準資料取得，而是需要進行 DSL 的調查、檢閱和稽核。事實上，確保正確 DSL 管理的唯一方法，是對照安裝在基礎架構中設備上的軟體，來稽核、檢閱並比較 DSL 中的軟體版本發佈。

安全性的審核較為困難，然而，對 DSL 的所有存取應該以密碼來控管。因此，檢閱密碼流量是一個好的起點。安全審核最好由獨立安全分析員來執行，而非交由 IT 分析員負責。這項審核活動通常是應 IT 管理階層的要求不定期執行，如果發現任何安全問題或錯誤情形，應立即採取動作將這些缺失從「版本發佈管理」中移除，並預防日後再度發生。

  • 商業協調指標 – 這完全取決於商務社群對 DSL 的涉入程度，若商業經理「擁有」DSL 中的任何軟體，則請他們充分參與審核活動。此外，如果需要實地造訪以確認軟體版本號碼，也務必洽詢商業經理。

沒有跡象顯示 DSL 中有未通過品質檢查的軟體，也沒有發現從 DSL 抽取的任何軟體有重製情形。如同上一個 KPI，此評量也無法從基準資料取得，而是必須進行 DSL 的調查、檢閱和稽核。驗證品質和完整性的唯一方法，是對照安裝在基礎架構中設備上的軟體，來稽核、檢閱並比較 DSL 中的軟體版本發佈。 稽核檢查最好由獨立分析員來執行，而非交由 DSL 的「保管者」負責。這項檢查通常是應 IT 管理階層的要求不定期執行，如果發現任何品質或完整性問題，應立即採取動作將這些缺失從「版本發佈管理」中移除，並預防日後再度發生。

  • 商業協調指標 – 同樣地，這完全取決於商務社群對 DSL 的涉入程度，若商業經理「擁有」DSL 中的任何軟體，則請他們充分參與審核活動。此外，如果需要實地造訪以確認軟體版本號碼，也務必洽詢商業經理。

DSL 大小符合空間需求和及時且正確的 DSL 內部管理。這個重要的 KPI 仰賴 ITIL「容量管理」程序進行輸入和支援。若要評量 DSL 中的空間需求，需要將目前的資料庫大小，與升級現有軟體並增加新規劃軟體所需的額外空間相加，然後，將此總數與 DSL 的可用空間量相比較。若結果顯示沒有足夠空間用於新增軟體，則必須選擇增加 DSL 中的空間，或是移除 DSL 中的舊版或多餘軟體。如果您因為空間不足無法新增軟體，便無法達成此 KPI。

及時且正確的 DSL 內部管理應該是定期執行的活動，且所有動作都必須記錄在異動日誌中。此 KPI 涵蓋 DSL 及異動日誌的稽核，若有忽略內部管理或其他錯誤的跡象，即表示未達成此 KPI。如果發現有不及時或不正確的問題，應立即採取動作將這些缺失從「版本發佈管理」中移除，並預防日後再度發生。

  • 商業協調指標 – 同樣地，這是取決於商務社群對 DSL 的涉入程度，若商業經理「擁有」DSL 中的任何軟體，則請他們充分參與審核活動。此外，如果需要實地造訪以確認軟體版本號碼，也務必洽詢商業經理。

遵守所有關於購入軟體的法律規定。這是至為重要的 KPI，如果不符要求，公司可能面臨法律訴訟。一般而言，此 KPI 與軟體授權規定、軟體更新和軟體到期日相關。您應該分項列出所有軟體合約，並落實必要檢查與規定，以確保符合所有法律要求。為現有軟體新增使用者或執行現有軟體升級時，請務必格外小心謹慎。

  • 商業協調指標 – 確認商業經理知道任何未遵守的法律規定—特別是如果商業經理便是違反規定者 (或許並非故意)。例如：商業經理同意支付 10 台工作站的軟體產品授權，但是同時使用該軟體的固定使用者超過 10 個。在此案例中，您應該通知商業經理該軟體的使用並不合法，而且可能必須知會其他非 IT 部門，例如合約管理與採購部門等。

將版本正確發佈到所有遠端站台。此 KPI 可透過稽核方式來評量，不過，較常見的作法是定期檢閱「意外」與「問題」資料庫，尋找是否有不正確的軟體發佈情形。此外，也可查看「變更管理」中的 RFC，您可能會看到某個 RFC 中要求的變更，是由於不正確的軟體版本發佈所引起。例如，使用者要求應該已經安裝的升級或功能。若有證據顯示「版本發佈」不正確，即表示未達成此 KPI。

  • 商業協調指標 – 有時候，商業經理並不清楚其部門中應該安裝的軟體 (版本/版次)，請確認在軟體版本發佈過程中充分告知商業經理。

準時在所有站台上 (包括遠端站台) 建置「版本發佈」。此 KPI 相當容易監控，因為「版本發佈」不是準時、就是延遲。若「版本發佈」延遲，即代表未達成此 KPI，不過，應該找出「版本發佈」延遲的原因，並採取必要措施防止日後因相同原因造成「版本發佈」延遲。您應該定期 (例如每月) 發送「延遲的版本發佈」報表給所有 IT 經理。以供其檢閱及評論。

  • 商業協調指標 – 商業商理會希望收到「延遲的版本發佈」報表，而且他們也有可能會在「版本發佈」延遲時通知您，因此請將所有「版本發佈」的最新進度提供給他們。

沒有發現任何站台上有未經授權便回復至舊版的情形。此 KPI 需要稽核與檢閱動作，您可以使用「搜尋和尋找」公用程式來偵測已回復的軟體，或者，也可能在檢閱「意外」或「問題」資料庫時發現此情形。您也應該檢閱「變更管理」中的 RFC，看看是否有使用者因為回復的軟體版本而要求「變更」。例如，使用者要求應該已經安裝的升級或功能。若發現任何未經授權的軟體回復，即表示未達成此 KPI。

  • 商業協調指標 – 詢問商業經理在其權責範圍內是否有失敗情形發生，您可能也需要向安全人員或部門報告所發現的失敗。

沒有在任何站台上使用未經授權的軟體。此 KPI 也需要稽核與檢閱動作，首先，確定「未經授權軟體」的確切構成要素，以及使用或執行「未經授權軟體」將遭受的刑罰。然後，確認所有 IT 經理與商業經理充分瞭解「未經授權軟體」的定義及所牽涉的刑罰。您可以使用「搜尋和尋找」公用程式，或是透過檢閱「意外」或「問題」資料庫，來偵測未經授權的軟體。若有證據顯示使用未經授權的軟體，即表示未達成此 KPI。

  • 商業協調指標 – 若您發現商業經理的權責範圍內有未經授權的軟體使用，則必須向其洽詢。安裝其他軟體的新版本時，未經授權的軟體可能導致嚴重「問題」。更重要的是，未經授權的軟體是病毒和其他電腦軟體違規的可能入口。因此，可能有必要向安全部門或公司稽核員報告未經授權的軟體使用情形。

對於實際上並未用於任何特定位置的軟體，沒有支付相關授權費用或浪費人力進行維護。此 KPI 可視為「良好的內部管理」。規劃定期的稽核活動，以確定軟體在哪些位置使用。這並不是要確定軟體是否有在使用，而是需要多少授權數來支援其使用。

例如，您的部門可能有 40 位員工，而且所有工作站上均有相同的授權軟體，不過，由於政策中的部門變更，實際上只有 10 位員工使用該授權軟體。 您可透過減少授權數並從不再使用該軟體的工作站上將軟體移除，以降低授權和維護成本。

您可以使用「軟體使用」公用程式，或是透過檢閱「意外」或「問題」資料庫，來偵測未使用的軟體。此 KPI 與其他 KPI 有些差異，因為如範例中所述，環境可能會不斷改變。

  • 商業協調指標 – 您可以使用一些技術來協助確定軟體使用 (或未使用)，不過商業經理必須同意減少授權數。因此，每當您發現有未使用的授權時，請在減少授權數前先洽詢相關的商業經理。此外，要求商業經理每年檢閱其員工所使用的軟體授權，確認是否仍需要所有的授權。

未發現「版本發佈」建置中有無用的重複 (例如，有多個遠端站台建置，但實際上使用單一建置的副本便已足夠)。這是其中一個較難評量的 KPI，因為它需要正在進行「版本發佈」的 IT 員工找出並報告無用的重複。有時候，必須等到安裝發佈版本時，才會清楚顯示重複情形。請鼓勵員工報告任何重複情形，以便未來的版本發佈能更有效地執行。當「版本發佈」需花費較長時間或建置成本超出預期時，也可能指出有無用的重複。

定期稽核與檢閱在此並不需要，不過應該在「版本發佈」完成後的評估過程中，識別是否有無用的重複。找到無用的重複時，應採取必要動作改善「版本發佈管理」程序，以預防再度發生。若有任何無用的重複，即表示未達成此 KPI。

  • 商業協調指標 – 一般使用者在「版本發佈」期間的參與程度越高，便越有可能注意到重複情形。一般使用者和商業經理可協助找出並報告任何無用的重複，例如，一般使用者和商業經理可能注意到必須執行好幾次相同動作。在任何情況下，將「版本發佈」建置中的任何重複情形通知商業經理。

正確且及時地記錄 CMDB (組態管理資料庫) 內部的所有建置、發佈和實作活動。首先，您必須明確定義並記錄「正確性」和「及時性」，否則便無法評量此 KPI。然後，決定要如何識別錯誤。關於「正確性」的部份，「組態管理」小組應負責稽核 CMDB，並報告由於「版本發佈管理」的錯誤所導致的任何不正確情形。評量「及時性」較為困難，「及時性」是關於更新已經由「版本發佈」變更的 CMDB 項目所需的時間。您可以在進行 CMDB 稽核時找到一些及時性錯誤，也可透過檢閱「問題」和「意外」資料庫或是從「服務中心」發現其他及時性錯誤。例如，「服務中心」正在處理一個「意外」，但是 CMDB 確實符合客戶位置的實際組態，這是因為「版本發佈管理」並未及時更新 CMDB。

ITIL 中指出正確的 CMDB 是 IT 服務管理的關鍵因子，未達成此 KPI 是嚴重的問題，必須採取必要動作維持正確的 CMDB。

  • 商業協調指標 – 請通知商業經理 CMDB 中的不正確情形，特別是需要用到 CMDB 者，例如財務、合約管理和採購部門的商業經理。您可能也需要通知並未使用不正確 CMDB 的商業經理，因為不正確或過時的 CMDB 造成的服務不佳也可能使他們受到影響，例如將錯誤的優先順序指派給「意外」。請洽詢商業經理，確定誰需要獲得與 CMDB 不正確有關的意見回饋。

針對所有「版本發佈」活動進行事後剖析，並採取所有必要的修正或後續動作，以及任何程序改良。此 KPI 並不是非常明確，它是表示要執行事後剖析嗎？還是所有事後剖析結果均未顯示「版本發佈問題」？當然最好是對每個「版本發佈」執行事後剖析，如果不可能這樣做，至少也要針對所有發生「問題」或失敗的「版本發佈」執行事後剖析。沒有事後剖析報表即代表未達成 KPI。此外，請執行相關檢查，確認已採取所有必要的修正或後續動作，以及任何程序改良。沒有執行檢查即代表未達成 KPI。事後剖析也可提供資料給本節中所述的許多其他 KPI。

  • 商業協調指標 – 商業經理不需要看到所有事後剖析結果，不過，如果事後剖析顯示其商業領域中安裝的版本有「問題」，則應該將它傳送給商業經理。

規劃的「版本發佈」組合與實際的組合相符 (證明「版本發佈」規劃良好)。理想上，規劃應該十分完善，以確保規劃的「版本發佈」組合與實際的組合相符。不過，預料外的狀況時常發生，而我們便是從這些異常情況中學習如何改善規劃，這就是為何此 KPI 相當重要，即使它並未提及如何建置改善規劃的策略。在完成每個「版本發佈」時，請確認規劃的組合是否與實際的「版本發佈」組合相符，此調查可當作事後剖析的一部份來進行。如果任何規劃的「版本發佈」組合與實際的組合不符，則代表未達成此 KPI。

  • 商業協調指標 – 如果商業經理是「變更諮詢委員會」(CAB) 的委員，他們會有興趣瞭解此 KPI，尤其是報告指出有不符情況時。若任何商業經理在其領域中遇到實際與規劃組合不同的情況，也會對此 KPI 感興趣。

「版本發佈管理」所需的 IT 和人力資源有良好的持續發展規劃。這是另一個「規劃」KPI，目的是要確保「版本發佈管理」期間的所有必要資源都已備妥。由於難以根據「良好」的目標來評量 KPI，因此最好建立一個客觀的目標，例如由於資源短缺而延遲的「版本發佈」不超過 5%。無論您建立的指標為何，未符合該指標即表示未達成 KPI。

請記得在規劃階段中預估資源時，高估和低估一樣有害。例如，若您預估某項工作需要 100 小時的工時，但實際上只花費 25 小時，可能會導致不必要地排擠其他人員工作負載要求。您應該在每個「版本發佈」的整個生命週期內仔細加以監控，並盡快將任何資源問題回報給 IT 經理。在每個「版本發佈」結束時評估規劃，以比較規劃的資源和實際使用的資源。這是相當重要的 KPI，因為「版本發佈」延遲的一個常見原因便是資源規劃錯誤。您必須完整說明任何資源短缺情形，以及採取的任何動作，以確保可於日後改善「版本發佈」規劃。

  • 商業協調指標 – 商業經理通常有興趣瞭解因資源規劃不當造成「版本發佈」建置延遲的情況，但是沒有興趣知道加速「版本發佈」建置的規劃。多數商業經理對資源規劃有非常充分的瞭解，因此請準備好回答大量問題。此外，也預備因應對專案提前結束的懷疑聲浪。比喻來說，如果道路標誌指出新的高速公路比預定日期提前九個月開放，您的第一個反應會是「規劃得很好」或是「政府被道路建築承包商給騙了」？無論情況為何，您都必須將所有資源不符的詳細分析提供給商業經理。

這些 KPI 呈現出兩個主題：稽核和事後剖析，這兩個都是可確保「版本發佈管理」不斷循環改善的重要活動。不過，在使用上請務必小心，若您使用稽核或事後剖析來批評員工或其行為，這些工具會馬上失去效用。最後一點—此情況中的「稽核」代表的是檢查正確性與及時性，而非執行商業或法律稽核。(授權管理可能是這段陳述的例外情況。)

現在讓我們繼續探討「管理」資訊指標，這些指標主要是與「版本發佈管理」的整體效能相關，ITIL 建議的管理資訊指標如下：

  • 每一報告期間的主要和次要「版本發佈」數目。
  • 真實環境中可歸因於新「版本發佈」的「問題」數目，這只需要在新「版本發佈」生命週期的前幾個月內評量，並依根本原因分類 (例如，「檔案版本錯誤」或「遺失檔案」)。
  • 由新「版本發佈」帶來的新增、已變更和已刪除物件 - 例如，有多少模組和程式。
  • 在議定時間範圍內完成的「版本發佈」數目，這需要使用集中式「版本發佈管理」功能，以發佈軟體散佈和其他共用工作的預先定義目標 (服務層級或 SLA)。

檢視過為數眾多的 KPI 後，發現只有幾個指標適用於管理報告並不足為奇：

每一報告期間的主要和次要「版本發佈」數目。遺憾的是，這個指標並未提供太多有關到底應該報告什麼的資訊。它是說在某期間內完成的「版本發佈」嗎？還是在某期間內開始的「版本發佈」？又或者是建置中的「版本發佈」？還是以上皆是呢？理想上，定期報表中呈現的應該是上述全部。報表可依狀態劃分為三個區段：已完成、已開始和目前 (建置中)。每個區段可進一步劃分為兩個子區段：主要和次要。此報表應發送給所有 IT 經理，使其能追蹤由他們或其員工所參與的所有「版本發佈」。

  • 商業協調指標 – 這是對所有商業經理都很重要的報表，可讓他們追蹤影響其商業領域的「版本發佈」。若發佈此報表，將可減少商業經理對其「版本發佈」狀態的問題。若有任何商業經理遇到「版本上線」延遲情況，可預期他們會提出問題。

真實環境中可歸因於新「版本發佈」的「問題」數目，這只需要在新「版本發佈」生命週期的前幾個月內評量，並依根本原因分類 (例如，「檔案版本錯誤」或「遺失檔案」)。這是一項清楚的指標，而且可加以擴充，納入由使用者回報且可歸因於新「版本發佈」的所有新「意外」。理想上，應該沒有任何新「問題」或「意外」，不過，實際狀況通常並非如此，即使「版本發佈」成功也一樣。要更加趨近理想的方法只有一種，就是調查所有新的「問題」和「意外」，然後採取適當動作預防在日後的「版本發佈」中再度發生。這個指標建議使用「根本原因」來分類「問題」，同樣地，「類別」也可應用於「意外」。所有「問題」和「意外」應交叉參照到與其關聯的「版本發佈」，例如藉由「版本發佈」參考號碼。最後，應該對每個列出的「問題」和「意外」採取修正動作，以防止在日後的「版本發佈」中再度發生。此報表應定期編譯並發送給所有 IT 經理。

  • 商業協調指標 – 這是所有商業經理的「必要」報表，商業經理會想要知道由「版本發佈」所引起的任何「問題」或「意外」，畢竟，商業經理很有可能是失敗結果的接收端。此外，他們也有興趣知道為了預防日後發生相同「問題」和「意外」所採取的任何修正動作。

由新「版本發佈」帶來的新增、已變更和已刪除物件 - 例如，有多少模組和程式。這個指標只是依照一系列階段性類別來細分的容量指示，新增、已變更或已刪除的物件數目沒有太大用處，因為它並未提供任何影響或工作負載資料。不過，結合 KPI 和其他管理資訊後，這個指標可提供指定期間內的活動量指示。提供物件清單時最好一併附上數目，且應將此報表發送給所有 IT 經理。

  • 商業協調指標 – 多數商業經理不會對此報表感興趣，除了具備某些專業的商業經理外，例如商業開發、合約管理和採購部門經理，或是擔任「變更諮詢委員會」(CAB).委員的商業經理。您應該確定哪些商業經理需要這份報表，並定期將報表發送給他們。

在議定時間範圍內完成的「版本發佈」數目，這需要使用集中式「版本發佈管理」功能，以發佈軟體散佈和其他共用工作的預先定義目標 (服務層級或 SLA)。此管理指標以及本節說明的第一個 KPI：「按照排程建置並實作的版本發佈」，這兩者之間的差異可能很難一眼就看出。事實上，我們從失敗的「版本發佈」中學到的經驗，似乎比從成功的「版本發佈」得到的還多。在仔細審閱後，可看出採用 SLA 能使這個指標與第一個 KPI 有所不同。例如，您可在 SLA 中加入一段陳述，指定 95% 的所有「版本發佈」將於議定時間範圍內建置。若是如此，此報表的重要性便大幅提升，因為其中顯示出「版本發佈管理」的整體效能。總結來說，您需要設定成功「版本發佈」建置的目標，接著確定報告期間，然後將此報表發送給所有 IT 經理。

  • 商業協調指標 – 如果已經有議定的成功和及時「版本發佈」建置的 SLA 目標，則必須將此報表發送給所有商業經理，或至少發送給簽署 SLA 的商業經理。

現在我們便有適用於「版本發佈管理」的一組廣泛的 KPI 和管理資訊指標。您可能會覺得在每個報告期間產生所有這些類別的報表太過困難或浪費時間，請記得，ITIL 是一個架構，您可以選擇對您組織而言最有意義的 KPI 和指標，並只產生這些報表。 最後，切記 IT 成功與否取決於有效的「變更管理」和「版本發佈管理」，因此，請不要忽視這些指標，並持續尋求改善「變更管理」和「版本發佈管理」的新方法。

> > 第 9 章 - 組態管理