Microsoft Fabric 採用藍圖：卓越中心

  • 發行項

注意

本文構成 Microsoft Fabric 採用藍圖系列文章的一部分。 如需系列的概觀，請參閱 Microsoft Fabric 採用藍圖。

卓越數據或分析中心（COE）是技術和商務專家的內部小組。 小組會主動協助組織內使用數據的其他人員。 COE 形成更廣泛的社群核心，以推進採用目標，其符合數據文化願景。

COE 也稱為 專長認證中心、 功能中心或 專業知識中心。 有些組織使用「小組」一詞。 許多組織在其數據、分析或商業智慧 （BI） 小組內執行 COE 責任。

注意

建議您在組織結構中正式辨識 COE 小組，但並非必要。 最重要的是，COE 角色和責任會識別、排定優先順序並指派。 集中式數據或分析小組通常會承擔許多COE責任：某些責任也可能位於IT中。 為了簡單起見，在此系列文章中，COE 表示特定 人員群組，不過您可能會以不同的方式實作。 使用範圍比網狀架構或Power BI更廣的範圍來實作COE也非常常見：例如，Power Platform COE、數據COE或分析COE。

COE 的目標

COE 的目標包括：

  • 宣傳數據驅動文化特性。
  • 促進採用分析。
  • 培養、指導、指導和教育內部使用者，以提高他們的技能和自力更生水準。
  • 協調工作，並跨組織界限傳播知識。
  • 為使用者社群建立一致性和透明度，可減少與尋找相關數據和分析內容相關的摩擦和痛點。
  • 將自助 BI 的優點最大化，同時降低風險。
  • 藉由協助使用者做出能增加一致性並降低效率不佳的良好決策，以減少技術債務。

重要

COE 最強大的層面之一是跨部門深入解析組織如何使用如 Fabric 的分析工具。 此深入解析可以揭示哪些做法運作良好，哪些做法無法運作，這可促進治理的自下而上方法。 COE 的主要目標是瞭解哪些做法運作良好、更廣泛地分享該知識，以及跨組織複寫最佳做法。

COE 責任範圍

COE 責任的範圍在組織之間可能會有很大的差異。 在某種程度上，COE 可以視為諮詢服務，因為其成員經常為內部使用者社群提供專家建議。 不同程度地，大多數 COE 也會處理實際操作工作。

常見的 COE 責任包括：

為 COE 提供人員

人員 作為 COE 成員的優秀候選人往往是那些：

  • 了解組織的分析願景。
  • 想要持續改善組織的分析做法。
  • 對 Fabric 等分析工具有著深厚的興趣和專業知識。
  • 有興趣查看在整個組織中有效且成功採用的網狀架構。
  • 主動不斷學習、適應和成長。
  • 隨時與其他人分享他們的知識。
  • 對於可重複的程式、標準化和控管有興趣，著重於用戶啟用。
  • 過度專注於與其他人的共同作業。
  • 以敏捷的方式舒適地工作。
  • 對參與和説明他人有內在的興趣。
  • 可以有效地將業務需求轉化為解決方案。
  • 與技術和商務同事溝通良好。

提示

如果您的組織中有自助內容建立者，他們不斷突破可完成的界限，他們可能是成為公認的 冠軍的優秀候選者，甚至可能是 COE 的衛星成員。

為 COE 招聘時，請務必混合互補分析技能、技術技能和商務技能。

角色和責任

COE 中非常一般化的角色如下所列。 多人通常會重疊角色，這在備份和交叉訓練的觀點中很有用。 同一個人也常提供多個角色。 例如，大多數 COE 成員也擔任教練或導師。

Role 說明
COE 領導者 管理 COE 的日常作業。 視需要與執行贊助者和其他組織小組互動，例如數據控管委員會。 如需其他角色和責任的概觀，請參閱 治理 文章。
教練 透過辦公室時間（社群參與）、最佳做法檢閱或共同開發項目，指導及教育其他人了解數據和BI技能。 監督並參與內部社區的討論管道。 與冠軍網路互動並支援。
教練機 開發、策劃及提供內部訓練教材、文件和資源。
資料分析師 領域特定主題專家。 作為 COE 與業務單位之間的聯絡人。 業務單位的內容建立者。 協助進行內容認證。 適用於共同開發專案和概念證明。
數據模型工具 建立及管理數據資產（例如先前稱為數據集的共用語意模型，以及數據流），以支援其他自助內容建立者。
報表建立者 建立及發佈報表、儀錶板和計量。
資料工程師 部署和架構的計劃，包括與其他服務和數據平臺的整合。 發佈跨組織廣泛使用的數據資產（例如 Lakehouse、數據倉儲、數據管線、數據流或語意模型）。
使用者支援 協助解決數據不一致，並呈報技術支援中心支持問題。

如先前所述，COE 的責任範圍在組織之間可能會有很大的差異。 因此，針對 COE 成員找到的角色也會有所不同。

建構 COE

選取的 COE 結構可能會因組織而異。 也可以讓多個結構存在於單一大型組織內。 當有子公司或發生收購時，情況尤其如此。

注意

下列詞彙可能會與您的組織所定義的詞彙不同，尤其是同盟的意義，其通常具有許多不同的IT相關意義。

集中式 COE

集中式 COE 包含單一共享服務小組。

優點：

  • 單一小組負責管理標準、最佳做法和端對端傳遞的單一小組責任。
  • COE 是組織結構觀點中的一個群組。
  • 從這種方法開始很容易，然後隨著時間演變成統一或同盟模型。

缺點：

  • 集中式小組可能會有專制傾向，偏好一套適合所有決策，這些決策不一定適用於所有業務單位。
  • 可能會有偏好 IT 技能而不是商務技能的傾向。
  • 由於集中式性質，COE 成員可能更難充分瞭解所有業務單位的需求。

整合 COE

統一 COE 是單一集中式的共用服務小組，已擴充為包含內嵌小組成員。 內嵌小組成員專門支援特定功能區域或業務單位。

優點：

  • 單一小組有單一責任，其中包含內嵌COE小組成員的跨功能參與。 內嵌 COE 小組成員會指派給企業的各個領域。
  • COE 是組織結構觀點中的一個群組。
  • COE 更深入地瞭解業務單位的需求，因為具有領域專業知識的專用成員。

缺點：

  • 專屬於特定業務單位的內嵌 COE 小組成員，其組織結構責任與直接在業務單位內服務的人員不同。 組織結構可能會導致複雜、優先順序的差異，或需要執行贊助人的參與。 最好是執行贊助者具有一個授權範圍，包括COE和所有相關業務單位，以協助解決衝突。

同盟 COE

同盟COE由共用服務小組（核心COE成員）以及來自每個功能區域或主要業務單位的衛星成員組成。 同盟小組會協調運作，即使其成員位於不同的業務單位也一樣。 一般而言，衛星成員主要著重於開發活動，以支援其業務單位，而共用服務人員則支援整個社群。

優點：

  • 衛星 COE 成員的跨功能參與代表其特定功能領域並具備領域專業知識。
  • 核心和衛星 COE 成員之間有集中式和分散式表示的平衡。
  • 當分散式數據擁有權的情況存在時，當業務單位直接負責數據管理活動時，此模型就很有效。

缺點：

  • 由於核心和衛星成員跨越組織界限，聯合 COE 方法需要強有力的領導、出色的溝通、強大的專案管理，以及超明確的期望。
  • 由於同盟結構，遇到競爭優先順序的風險較高。
  • 這種方法通常牽涉到兼職人員和/或 虛線 組織結構責任，可帶來競爭的時間壓力。

提示

某些組織使用 輪替計劃成功。 它牽涉到同盟成員加入核心 COE 一段時間，例如六個月。 這種類型的程式可讓同盟成員學習最佳做法，並深入瞭解如何及為何完成工作。 雖然每個同盟成員仍然專注於其特定業務單位，但他們對組織的挑戰有了更深入的瞭解。 這種更深入的瞭解會導致一段時間后更具生產力的合作關係。

分散式 COE

分散式 COE 是由業務單位獨立管理。

優點：

  • 特製化數據文化存在，著重於業務單位，可讓您更輕鬆地快速學習並進行調整。
  • 原則和做法是針對每個業務單位量身打造的。
  • 靈活度、彈性和優先順序著重於個別業務單位。

缺點：

  • 分散式 COE 會隔離運作有風險。 因此，他們可能不會分享其業務單位外部所學到的最佳做法和教訓。
  • 與集中式小組的共同作業可能非正式且/或不一致。
  • 系統會建立不一致的原則，並跨業務單位套用。
  • 很難調整分散式模型。
  • 可能會進行重新作業，讓一或多個分散式COE與全組織原則保持一致。
  • 擁有大量資金的大型業務單位可能會有更多資源可供他們使用，從整個組織的觀點來看，這些資源可能無法達到成本優化目標。

重要

高度集中式的 COE 往往更 專制，而高度分散的 COE 往往更 孤立。 每個組織都必須權衡適用於它們的優缺點，以判斷最佳選擇。 對大多數組織而言，最有效的方法通常是統一或同盟，以橋接組織界限。

為 COE 提供資金

COE 可能會以多種方式取得其作業預算：

  • 成本中心。
  • 具有項目預算的利潤中心。
  • 成本中心和利潤中心的組合。

當 COE 以成本中心的形式運作時，它會吸收營運成本。 一般而言，它涉及已核准的年度預算。 有時這稱為 推播 參與模型。

當COE作為利潤中心運作（至少占其預算的一部分）時，它可以根據其他業務單位的資金，全年接受專案。 有時這稱為 提取 參與模型。

資金很重要，因為它會影響 COE 與內部社群溝通和參與的方式。 由於 COE 體驗越來越成功，他們可能會從業務單位收到更多要求以取得協助。 特別是隨著整個組織的意識成長，情況尤其如此。

提示

融資模式的選擇可以決定 COE 如何積極擴大其影響力和説明能力。 融資模式也可能對權威所在位置以及決策工作方式產生重大影響。 此外，它會影響 COE 可以提供的服務類型，例如共同開發專案和/或最佳做法檢閱。 如需詳細資訊，請參閱 指導和用戶啟用 一文。

某些組織會根據 Fabric 的使用目標，向業務單位收取退款，以涵蓋 COE 營運成本。 針對共用容量，這可能以作用中用戶數目為基礎。 針對 進階版 容量，可以根據哪些業務單位使用容量來配置退款。 在理想情況下，退款與取得的商業價值直接相關。

重要

本文有時是指 Power BI 進階版 或其容量訂用帳戶（P SKU）。 請注意，Microsoft 目前正在合併購買選項，並淘汰每個容量 SKU 的 Power BI 進階版。 新的和現有的客戶應該考慮改為購買網狀架構容量訂用帳戶（F SKU）。

如需詳細資訊，請參閱 Power BI 進階版 授權和 Power BI 進階版 常見問題的重要更新。

注意事項和關鍵措施

檢查清單 - 您可以採取的考慮事項和重要動作，以建立或改善 COE。

  • 定義 COE 的責任範圍： 確定您已清楚瞭解 COE 可支援哪些活動。 一旦知道責任範圍之後，請識別履行這些責任所需的技能和專長認證。
  • 找出執行能力方面的差距： 分析 COE 是否有所需的系統和基礎結構，以符合其目標和責任範圍。
  • 判斷最佳的 COE 結構： 識別哪一個 COE 結構最合適（集中式、統一、同盟或分散式）。 確認人員配置、角色和責任，以及適當的組織結構關聯性 （HR 報告） 已就緒。
  • 規劃未來的成長： 如果您從集中式或分散式 COE 開始，請考慮如何使用統一或同盟方法，隨著時間調整 COE。 規劃您現在可以採取的任何動作，以利未來成長。
  • 識別客戶： 識別要由 COE 提供服務的內部社群成員和任何外部客戶。 決定 COE 如何一般與這些客戶互動，無論是推送模型、提取模型還是兩種模型。
  • 確認 COE 的資金模型： 決定 COE 是否純粹是具有營運預算的成本中心、是否會部分作為利潤中心運作，以及/或是否需要向其他業務單位退款。
  • 建立通訊計劃： 建立 通訊策略 ，以教育用戶的內部社群，瞭解 COE 所提供的服務，以及如何與 COE 互動。
  • 建立目標和計量： 決定您將如何測量COE的有效性。 建立 KPI（關鍵效能指標）或 OKR（目標和關鍵結果），以驗證 COE 是否一致地為使用者社群提供價值。

要思考的問題

使用如下找到的問題來評估 COE 的有效性。

  • 是否有 COE？ 如果是，誰在 COE 和結構是什麼？
  • 如果沒有 COE，是否有執行類似功能的中央小組？ 組織中的數據決策者是否瞭解COE的功能？
  • 如果沒有 COE，組織是否渴望建立一個 COE？ 原因為何？
  • 由於企業和部門解決方案的混合，同盟或分散式COE模型是否有機會？
  • COE 是否有遺漏的角色和責任？
  • COE 與使用者社群互動的程度為何？ 他們會指導使用者嗎？ 他們會策劃集中式入口網站嗎？ 他們會維護集中式資源嗎？
  • 組織中是否可辨識 COE？ 使用者社群是否認為這些使用者是可信且有説明的？
  • 商務使用者是否將中央小組視為啟用或限制其使用數據？
  • COE 融資模式是什麼？ COE 客戶是否以某種方式向COE捐款？
  • COE 與其通訊有多一致且透明？

成熟度等級

下列成熟度層級可協助您評估COE的目前狀態。

等級 卓越中心狀態
100：初始 • 有一或多個 COE 存在，或活動是在數據小組、BI 小組或 IT 內執行。 對具體目標或責任的期望沒有明確性。

• COE 的協助要求會以非計劃的方式處理。
200：可重複 • COE 已具備指導、引導和教育自助使用者的特定憲章。 COE 會尋求將自助方法對數據和 BI 的優點最大化，同時降低風險。

• 為 COE 建立目標、責任範圍、人員配置、結構和融資模式。
300：已定義 • COE 會以統一或同盟模式主動參與所有業務單位。
400：能力 • COE 的目標符合組織目標，且會定期重新評估。

• COE 在整個組織中廣為人知，並一致地向內部使用者社群證明其價值。
500：高效率 • 定期檢閱 KPI 或 OKR，以可測量的方式評估 COE 有效性。

• 靈活度和實作從學習到的經驗持續改善（包括相應放大工作的方法）是 COE 的首要任務。

相關內容

在 Microsoft Fabric 採用藍圖系列中的 下一篇文章 中，瞭解如何實作治理指導方針、原則和程式。