企業架構實務（二）：如何用 Gartner IT Score 與 Priority Index 找出能力缺口？

企業開始規劃轉型之前，通常已經累積很多意見：有人覺得系統太舊，有人認為流程太慢，也有人相信換一套平台就能解決問題。

意見很多，卻沒有同一個單位可供討論。系統老舊、交付緩慢、事故頻繁與人才不足，可能同時存在，卻不代表每一項都該優先投資。如果沒有共同尺度，現況分析很容易只是把不同角色的主觀感受排進同一份簡報。

Gartner IT Score 提供的切入點，是把 IT 職能拆成功能目標與功能活動，再比較每項活動的成熟度與策略重要性。它要回答的是「哪些活動對目前策略重要，現有成熟度卻還跟不上」，而不只是找出最低分。

後續若要把能力缺口接回企業能力與轉型順序，可以參考專案管理與企業架構的協作框架；若要看這類判斷如何落到餐飲轉型情境，則可延伸閱讀好味餐飲的數位轉型情境。

IT Score 在現況分析中的位置

IT Score 是成熟度評估工具，和系統盤點、架構探索處理的是不同問題。Gartner 將 Score Diagnostic Family 定義為一組互動式成熟度評估，用來衡量、排序並改善一項職能在關鍵活動上的表現。評估結果會呈現成熟度與業務優先事項之間的落差，並提供逐步改善路徑。[1]

評估單位是功能活動（functional activity）。每個 IT 職能包含數個功能目標（objective），功能目標再拆成活動。參與者針對活動回答重要性與成熟度標記（maturity marker）問題，Gartner 再產生評估結果。

IT Score 能建立共同語言、找出需要補強的活動，但不會自動還原流程、探索系統相依關係，也不會替組織選定解法。訪談、制度文件、交付紀錄、事故資料與監控指標，仍然是判斷 maturity marker 是否成立的證據。

重要性與成熟度怎麼形成

IT Score 同時看重要性與成熟度，但兩者的取得方式不同：

重要性（Importance， $I$ ）：由參與者以 1（不重要）至 5（關鍵）評估活動對該職能達成目標的重要程度。[2]
成熟度（Maturity， $M$ ）：參與者回答各項 maturity marker。Gartner 再透過專有演算法，將答案換算成成熟度結果；公開的 Software Engineering Score 頁面以 1（低）至 5（高）呈現這個尺度。[1] [2]

Gartner 的公開方法強調，成熟度評估應以實際做法為基礎。[1] 實務上，可以把 maturity marker 當成現況查核：有監控工具、流程文件或辦過一次演練，未必足以證明做法已經穩定運作。證據不足時，保留不確定性通常比直接推定成熟度更可靠。

Gartner 在公開的 Software Engineering Score 頁面中，使用 Priority Index （PI）排序需要優先改善的活動，並公布以下公式：[2]

PI = (I - M) \times I

以這個公開公式來看，PI 越高，代表活動的重要性相對高，成熟度卻沒有跟上。公式再次乘上 $I$ ，因此在成熟度落差相近時，對目標更重要的活動會排在前面。這個公式只用來說明排序邏輯；其他 IT Score 角色或版本採用的欄位與計算方式，仍應以當次官方評估為準。

PI 可以協助討論改善順序，但不必直接等同於投資排序。急迫性、活動之間的依賴、法規期限、可用資源與執行風險，仍需要另外判斷。

一輪評估怎麼進行

以下流程同時包含 Gartner 的官方方法與本文的實作建議。參與方式、 maturity marker 與正式計算結果來自 Gartner；範圍界定、證據留存與後續蒐證，則是本文為了讓結果可追查而整理的做法。

1. 先定義角色、範圍與決策問題

先確認這次要評估哪一項 IT 職能、涵蓋哪些組織邊界，以及結果要支援什麼決策。範圍可以記錄評估日期、納入的責任單位與排除項目。若關注單一產品線或交付團隊，可以把相關資料作為職能評估的證據；是否適合視為獨立的 IT Score 範圍，則應再確認當次官方問卷與同儕基準如何設計。

2. 找了解活動現況的人參與

Gartner 提供三種參與方式：由負責人自行填答、邀請熟悉不同活動的領導者共同參與，或召集團隊討論後形成共識。多人參與可以看見主管與團隊的認知差異；共識會議有利於後續行動，卻也可能壓低不同意見。[1]

參與者不必熟悉所有活動，但要能提出判斷依據。需要的證據可能來自策略與治理文件、發版與事故紀錄、服務指標、稽核資料、團隊分工，以及可被其他資料交叉確認的訪談陳述。

3. 分開回答重要性與成熟度標記（maturity marker）

重要性可以連回這次評估要支援的職能與策略目標；maturity marker 則要回到目前可觀察的做法。活動很重要，不代表成熟度較高；成熟度偏低，也不必然代表它是目前最急迫的項目。

填答時可以保留題目答案、證據來源、評估者分歧與信心。正式的 $M$ ，以及報告提供的 PI 或其他排序結果，應以當次 Gartner 評估為準；內部另行計算時，則要清楚標示為內部判讀。

4. 從高優先項目決定下一步蒐證

報告中的高優先項目比較適合視為深入檢查的起點，不代表已經找到根因。讀取結果時，可以把可驗證的現況、對業務目標的影響，以及可能的解法分開記錄。確認缺口、影響與活動依賴後，再討論改善方案，通常會保留更多調整空間。

七種評估角色

Gartner 目前提供七種 IT Score 角色。每一種都對應不同職能，七種角色並非同一份問卷的七個章節。[3]

Gartner 角色	適合觀察的職能
CIO	IT 對業務策略的貢獻、治理、營運模式與整體效能
Data & Analytics Leaders	資料、分析與相關能力的成熟度與績效
Chief Information Security Officers	資安職能的策略優先事項與業務成果
Application Leaders	應用職能的治理、管理與改善能力
I&O Leaders	基礎設施與營運職能的成熟度與改善路徑
Software Engineering Leaders	軟體工程職能的交付、組織與架構能力
Heads of Enterprise Architecture	企業架構團隊的成熟度與演進路徑

選擇角色時，可以從這次要支援的決策出發。議題若橫跨多個職能，可以分開評估並保留各自的範圍。若要一起解讀不同問卷的結果，也適合先說明它們反映的是不同職能，而不是單一總分。

報告應留下什麼

Gartner 的公開方法顯示，Score 結果可呈現成熟度與重要性的落差、同儕基準、改善 roadmap，以及主管與團隊觀點的差異。公開的 Software Engineering Score 頁面也列出 PI。實際可見的欄位與研究資源，可能隨角色、版本與存取權限而異。 [1] [2] [3]

組織自己的評估工作底稿，則應保留範圍與日期、活動與題目、重要性依據、 maturity marker 答案與證據、官方計算結果、同儕群組、意見分歧、信心，以及下一個驗證動作。這些欄位不屬於 Gartner 報告格式；分數被挑戰時，仍可以回到當時的問題與證據。

正式評估由 Gartner 維護。公開的 Gartner IT Score 介紹頁列出可選角色與報告範例；能否進入正式評估及完整研究資源，則依 Gartner 提供的存取權限而定。

分數的用途與限制

IT Score 適合用來建立共同語言、辨識需要深入蒐證的活動。重複評估也可以提供一個觀察變化方向的參考，但不必把分數差異全都解讀成成熟度改變。題目版本、策略、評估範圍、參與者、證據品質與同儕群組，都可能影響結果。

解讀分數時，還需要帶回評估條件：

跨期結果適合看方向；比較前可以先確認題目版本、策略、評估範圍、參與者、證據品質與同儕群組是否改變。
不把低成熟度直接解讀成必須更換工具、平台或組織。
不把高成熟度當成沒有營運風險的證明。
不用 PI 取代投資決策，忽略依賴、資源、急迫性與執行條件。
不只保存平均分數，卻遺失活動、題目與判斷證據。

IT Score 的價值，在於把策略重要性、目前做法與改善順序放在同一張圖上討論。分數指出該往哪裡深挖，後續決策仍要回到證據。

參考資料

[1] Gartner，〈Gartner Score Diagnostic Family Research Methodology〉。
[2] Gartner，〈Software Engineering Score — Benchmark Your Performance〉。
[3] Gartner，〈IT Maturity Assessment〉。