共用方式為


Microsoft Fabric 採用藍圖:卓越中心

注意

本文是<Microsoft Fabric 採用藍圖>系列文章的一部分。 如需系列的概觀,請參閱 Microsoft Fabric 採用藍圖

資料或分析卓越中心 (COE) 是由技術和業務專家所組成的內部團隊。 這個團隊會積極協助組織內處理資料的其他人員。 COE 形成更廣泛社群的核心,以促進與資料文化特性願景一致的採用目標。

COE 可能也稱為「專長認證中心」、「能力中心」或「專長中心」。 有些組織會使用「小組」一詞。 許多組織會在其資料、分析或商業智慧 (BI) 團隊內履行 COE 責任。

注意

建議您 (但並非必要) 在組織圖中正式認可 COE 團隊。 最重要的是識別、排定優先順序並指派 COE 角色和責任。 集中式資料或分析團隊通常要承擔許多 COE 責任;某些責任可能也會落在 IT 身上。 為了簡單起見,在此系列文章中,COE 表示「特定的人員群組」,不過,您可能會以不同的方式實作。 使用比單獨使用 Fabric 或 Power BI 更廣泛的範圍來實作 COE 也很常見:例如,Power Platform COE、資料 COE 或分析 COE。

COE 的目標

COE 的目標包括:

  • 傳播資料驅動的文化特性。
  • 推廣採用分析。
  • 培養、指導、引導及教育內部使用者,以提高他們的技能和自立等級。
  • 跨組織界限協調工作並傳播知識。
  • 為使用者社群建立一致性和透明度,從而減少與尋找相關資料和分析內容相關的摩擦及痛點。
  • 將自助 BI 的優點最大化,同時降低風險。
  • 藉由協助使用者做出良好決策來減少技術債務,進而提高一致性並減少效率不佳的狀況。

重要

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

COE 責任範圍

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

常見的 COE 責任包括:

配置 COE 人員

成為 COE 成員的最佳候選人往往是具備下列條件的人員:

  • 了解組織的分析願景。
  • 想要持續改善組織的分析做法。
  • 對 Fabric 等分析工具有著深厚的興趣和專業知識。
  • 有興趣看到在整個組織中有效且成功採用 Fabric。
  • 主動不斷學習、適應及成長。
  • 樂意與他人分享自己的知識。
  • 對於可重複的流程、標準化及治理感興趣,並著重於使用者賦能。
  • 非常注重與他人共同作業。
  • 以敏捷的方式自在地工作。
  • 本身喜歡參與和協助他人。
  • 可以有效地將業務需求轉化為解決方案。
  • 能夠與技術和業務同事進行良好溝通。

提示

如果您的組織中有自助內容創作者,他們不斷突破可完成的工作界限,則他們可能成為公認冠軍的絕佳人選,甚至可能是 COE 的附屬成員。

招募 COE 時,具備混合的互補分析技能、技術技能及業務技能非常重要。

角色和責任

以下列出 COE 中非常通用的角色。 多人角色重疊很常見,從備份和交叉訓練的觀點來看,這非常有用。 同一個人擔任多個角色也很常見。 例如,大多數 COE 成員也會擔任教練或導師。

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

如先前所述,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 營運成本。 針對共用容量,這可能會以活躍使用者數目為基礎。 針對 Premium 容量,可根據使用容量的業務單位來配置退款。 在理想情況下,退款與獲得的商業價值直接相關。

重要

此文章有時會提及 Power BI Premium 或其容量訂用帳戶 (P SKU)。 請注意,Microsoft 目前正在整合購買選項,並按容量 SKU 淘汰 Power BI Premium。 新客戶和現有客戶應考慮改為購買 Fabric 容量訂用帳戶 (F SKU)。

如需詳細資訊,請參閱 Power BI Premium 授權的重要更新 (英文) 和 Power BI Premium 常見問題集

注意事項和關鍵措施

檢查清單 - 您可以採用來建立或改善 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 的目前狀態。

等級 卓越中心的狀態
100:初始 • 有一或多個 COE 存在,或者活動是在資料團隊、BI 團隊或 IT 內執行。 沒有明確的具體目標,也沒有明確的責任期望。

• 對 COE 提供協助的要求會以非計劃的方式處理。
200:可重複 • COE 具備指導、引導及教育自助使用者的特定章程。 COE 尋求將對資料和 BI 的自助方法優點最大化,同時降低風險。

• 為 COE 建立了目標、責任範圍、人員配置、結構及資助模型。
300:已定義 • COE 會主動參與整合或同盟模式的所有業務單位。
400:能力 • COE 的目標符合組織目標,且會定期重新評估。

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

• 靈活度和實作來自經驗傳承的持續改進 (包括擴增可行的方法) 是 COE 的首要任務。

在 Microsoft Fabric 採用藍圖系列的下一篇文章中,了解如何實作治理方針、原則及流程。