Microsoft Fabric 採用藍圖:治理

注意

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

數據控管是一個廣泛且複雜的主題。 本文介紹重要概念和考慮。 它會識別採用 Microsoft Fabric 時要採取的重要動作,但並非數據控管的完整參考。

數據控管研究所所定義,數據控管是「資訊相關程式的決策權和責任制,根據已同意的模型來執行,這些模型描述誰可以採取哪些動作、哪些資訊,以及何時使用哪些方法」。

數據控管一詞是錯誤的。 治理的主要焦點不是數據本身。 重點是控管 使用者對數據執行的動作。 另一種方式:真正的重點是管理用戶的行為,以確保組織數據受到妥善管理。

當著重於自助數據和商業智慧時,治理的主要目標是達到適當的平衡:

  • 用戶授權: 在必要的護欄內,讓內部使用者社群更有生產力且有效率。
  • 法規合規性: 符合組織的產業、政府和合約法規。
  • 內部需求: 遵守組織的內部需求。

控制與授權之間的最佳平衡將會在組織之間有所不同。 組織內的不同業務單位也可能有所不同。 當您強調使用者授權,以釐清其在已建立護欄內的實際使用方式時,您將最成功的平臺,例如 Fabric。

提示

將治理視為一組已建立的指導方針和正規化原則。 所有治理指導方針和原則都應該與您的組織 數據文化和 採用目標保持一致。 您的系統監督(管理)活動會每天制定治理。

治理策略

考慮任何組織中的數據控管時,最好的起點是定義治理策略。 藉由先專注於數據控管的戰略目標,實作治理原則和程式時的所有詳細決策都可以透過策略來告知。 接著,治理策略將由組織 的數據文化特性定義。

治理決策是透過記載的指引、原則和程序來實作。 自助數據和 BI 平臺治理的目標,例如 Fabric,包括:

  • 讓整個組織的用戶能夠在定義的界限內使用數據並做出決策。
  • 藉由針對允許哪些動作、原因及方式提供清楚且透明的指引,以改善用戶體驗。
  • 確保數據使用量適用於企業的需求。
  • 確保內容擁有權和管理責任明確。 如需詳細資訊,請參閱 內容擁有權和管理 一文。
  • 加強跨組織界限使用數據的一致性和標準化。
  • 降低數據外泄和誤用數據的風險。 如需詳細資訊,請參閱 資訊保護和數據外泄防護系列文章一文
  • 符合適當使用數據的法規、產業和內部需求。

提示

執行良好的數據控管策略可讓更多使用者更輕鬆地使用數據。 從使用者授權的觀點來看治理時,使用者更有可能遵循記載的程式。 因此,使用者也會成為受信任的合作夥伴。

治理成功因素

當治理採用由上而下的任務制定時,其受到的接收並不十分重視控制,而不是賦予權力。 治理網狀架構最成功時:

  • 會使用最輕量型的治理模型,以達成必要目標。
  • 治理會以反覆的方式進行,而且不會大幅阻礙生產力。
  • 每當可行時,就會使用制定治理指導方針的自下而上方法。 卓越中心(COE)和/或數據治理小組會觀察業務單位內發生的成功行為。 然後,COE 會採取動作來向外延展至組織的其他區域。
  • 治理決策會與不同業務單位的輸入共同定義,再制定這些決策。 雖然有時需要特定指示詞(特別是在受管制的行業),但授權應該是例外,而不是規則。
  • 治理需求與彈性和生產力能力平衡。
  • 治理需求可以滿足為使用者的一般工作流程的一部分,讓使用者更輕鬆地以正確的方式執行正確的工作,而幾乎沒有摩擦。
  • 根據預設,對新數據要求的回答不是「否」,而是「是」,且具有清楚、簡單、透明規則,適用於數據存取、使用方式和共用的治理需求。
  • 需要存取數據的使用者有動力可透過一般通道來執行此動作,並符合治理需求,而不是規避這些需求。
  • 使用者遵循的治理決策、原則和需求符合組織數據文化目標,以及其他現有的數據控管計劃。
  • 影響使用者可及無法執行之決定,並非完全由系統管理員所做出。

向組織介紹治理

將網狀架構治理引入組織時,組織會採用三種主要計時方法。

Diagram shows the three main ways governance is introduced, which are described in the table below.

上圖中的方法包括:

方法 已遵循策略
Method 1. 首先推出 Fabric,然後引進治理: 網狀架構已廣泛提供給組織中的用戶作為新的自助數據和 BI 工具。 然後,在未來的某個時間,治理工作開始。 此方法會優先處理靈活度。
Method 2. 先進行完整治理規劃,然後推出 Fabric: 在允許用戶開始使用 Fabric 之前,先進行廣泛的治理規劃。 此方法會設定控件和穩定性的優先順序。
Method 3. 分階段推出 Fabric 的反覆治理規劃: 一開始會發生足夠的治理規劃。 接著,Fabric 會逐步向個別小組推出,同時進行反覆的治理增強功能。 此方法同樣會優先處理靈活度和控管。

當 Fabric 已用於自助案例時,請選擇方法 1,且您已準備好以更有效率的方式開始工作。

當您的組織已經有妥善建立的治理方法時,請選擇方法 2,以便輕鬆地擴充以包含 Fabric。

當您想要平衡控制靈活度時,請選擇方法 3。 這個平衡的方法是大多數組織和大部分案例的最佳選擇。

下列各節將說明每個方法。

方法 1:先推出 Fabric

方法 1 會設定靈活度和速度的優先順序。 它可讓使用者快速開始建立解決方案。 當網狀架構已廣泛提供給組織中的用戶作為新的自助數據和 BI 工具時,就會發生這個方法。 快速獲勝,並取得了一些成功。 未來某個時候,治理工作開始進行,通常為了使秩序達到無法接受的混亂程度,因為自助使用者人口沒有得到足夠的指導。

優點:

  • 最快速開始使用
  • 具備高度能力的使用者可以快速完成工作
  • 快速獲勝

缺點:

  • 一旦整個組織普遍使用 Fabric,建立治理的工作就會更高
  • 要求變更他們一直在做的事情的自助使用者抵抗
  • 自助使用者需要自行找出問題,這效率不佳,導致不一致
  • 自助使用者需要使用他們的最佳判斷力,這會產生技術債務來解決

請參閱下列治理挑戰一節中的其他可能缺點。

方法 2:先深入治理規劃

方法 2 會設定控制項和穩定性的優先順序。 它位於方法 1 的光譜相反端。 方法 2 涉及在推出 Fabric 之前執行廣泛的治理規劃。 當 Fabric 的實作由 IT 領導時,最有可能發生這種情況。 當組織在高管制產業中運作,或現有數據控管委員會強加重大必要條件和預先需求時,也可能會發生此情況。

優點:

  • 更完整準備以符合法規需求
  • 更完整地準備支持使用者社群

缺點:

  • 比自助更有利於企業內容開發
  • 讓使用者母體擴展開始取得價值並改善決策速度較慢
  • 當允許數據用於決策時,鼓勵不良的習慣和因應措施

方法 3:使用推出反覆治理

方法 3 會尋求靈活度與治理之間的平衡。 這是一個理想的案例,它只會 事先進行足夠的 治理規劃。 持續且頻繁的治理改善會隨著時間反覆發生,以及提供價值的網狀架構開發專案。

優點:

  • 將同等優先順序放在治理和用戶生產力上
  • 強調一個 學習,當你去 心態
  • 鼓勵分階段將反覆發行給使用者群組

缺點:

  • 需要高層級通訊才能成功採用敏捷式治理做法
  • 需要額外的專業領域,才能保持文件和訓練最新狀態
  • 引進新的治理指導方針和原則通常會導致特定層級的用戶中斷

如需預先規劃的詳細資訊,請參閱 準備移轉至 Power BI 一文。

治理挑戰

如果您的組織已實作沒有治理方法或策略方向的 Fabric(如上述方法 1 所述),可能會有許多需要注意的挑戰。 根據您採用的方法和您目前的狀態,下列一些挑戰可能適用於您的組織。

策略挑戰

  • 缺乏符合商務策略的一致數據控管策略
  • 缺乏管理數據作為策略資產的執行支援
  • 採用規劃不足,無法推進採用和 BI 和分析的成熟度層級

人員 挑戰

  • 集中式小組與業務單位之間缺乏一致的優先順序
  • 缺乏具有足夠專業知識和熱情的已識別擁護者在整個業務單位,以推進組織採用目標
  • 缺乏自助最佳做法的意識
  • 抵制遵循新引進的治理指導方針和原則
  • 跨業務單位花費的重複工作
  • 缺乏明確的責任、角色和責任

程序挑戰

  • 缺乏明確定義的進程,導致混亂和不一致
  • 缺乏標準化或重複性
  • 溝通和分享所學到課程的能力不足
  • 缺乏文件和過度依賴部落知識
  • 無法符合安全性和隱私權需求

數據品質與數據管理挑戰

  • 數據和報表的蔓延
  • 不正確、不完整或過時的數據
  • 數據缺乏信任,尤其是自助內容建立者所產生的內容
  • 沒有足夠數據驗證而產生的不一致報告
  • 未使用或難以存取的寶貴數據
  • 分散、孤立和重複的數據
  • 缺少數據目錄、清查、詞彙或譜系
  • 數據擁有權和管理不明確

技能與數據識字挑戰

  • 解譯、建立及有效地與數據通訊的不同層級
  • 不同層級的技術技能集和技能差距
  • 缺乏自信地管理數據多樣性和磁碟區的能力
  • 低估 BI 解決方案開發和管理在整個生命週期中的複雜性層級
  • 持續員工轉移和營業額的短期任期
  • 處理雲端服務變更的速度

提示

識別您目前的挑戰,以及您的優勢,對於進行適當的治理規劃至關重要。 上述挑戰沒有單一直接的解決方案。 每個組織都需要找出正確的平衡和方法,以解決對他們而言最重要的挑戰。 上述挑戰將協助您識別它們如何影響您的組織,讓您開始思考適合您情況的解決方案。

治理規劃

某些組織已實作 Fabric,但沒有治理方法或明確的策略方向(如上述方法 1 所述)。 在此情況下,開始治理規劃的工作可能會令人望而生畏。

如果組織中的正式治理機構目前不存在,則治理規劃和實作工作的重點將會更廣。 不過,如果組織中有現有的數據控管委員會,則您的焦點主要是整合現有的做法,並加以自定義,以配合自助和企業數據和 BI 案例的目標。

重要

治理是一項重大事業,從未完全 完成。 無情地優先處理和反覆運算改進,將使範圍更容易管理。 如果您追蹤每周和每個月的進度和成就,將會對一段時間的影響感到驚訝。 本系列中每篇文章結尾的成熟度層級可協助您評估您目前所處的位置。

接下來會說明一些您可能會發現有價值的潛在治理規劃活動和輸出。

策略

重要活動:

  • 進行一系列研討會,以收集資訊並評估數據文化特性、採用和數據與BI實務的目前狀態。 如需如何收集資訊及定義 BI 採用目前狀態的指引,包括治理,請參閱 BI 策略規劃
  • 使用目前的狀態評量和資訊來定義所需的未來狀態,包括治理目標。 如需有關如何使用此目前狀態定義來決定您所需未來狀態的指引,請參閱 BI 戰術規劃
  • 驗證治理計劃的焦點和範圍。
  • 識別進行中的現有自下而上計劃。
  • 找出立即的痛點、問題和風險。
  • 教育高級領導關於治理,並確保 行政贊助 足以維持和拓展該計劃。
  • 釐清 Power BI 適用於組織整體 BI 和分析策略 的位置。
  • 評估內部因素,例如組織整備程度、成熟度層級和關鍵挑戰。
  • 評估外部因素,例如風險、暴露、法規和法律需求,包括區域差異。

金鑰輸出:

  • 具有成本/權益分析的商業案例
  • 已核准的治理目標、焦點和優先順序,與高階商務目標一致
  • 規劃短期目標和優先事項(快速獲勝)
  • 規劃長期和延遲的目標和優先順序
  • 成功準則和可測量的關鍵效能指標(KPI)
  • 風險降低計劃記載的已知風險
  • 規劃符合影響組織中 BI 和分析的產業、政府、合約和法規需求
  • 融資計劃

人員

重要活動:

  • 建立治理委員會並識別重要的項目關係人。
  • 決定治理委員會的重點、範圍和一組責任。
  • 建立 COE。
  • 判斷 COE 的焦點、範圍和一組責任。
  • 定義角色和責任。
  • 確認誰具有決策、核准和否決權。

金鑰輸出:

  • 治理委員會憲章
  • COE 的憲章和優先事項
  • 人員配置計劃
  • 角色和責任
  • 責任和決策矩陣
  • 通訊計劃
  • 問題管理計劃

原則和程式

重要活動:

  • 分析立即的痛點、問題、風險和區域,以改善用戶體驗。
  • 依重要性順序排定數據原則的優先順序。
  • 識別現有的程式,以正常運作且可正式化。
  • 決定新數據原則的社交方式。
  • 決定數據原則可能有所不同或針對不同群組自定義的程度。

金鑰輸出:

  • 如何定義、核准、傳達和維護數據原則和文件的程式
  • 規劃要求有效例外狀況和偏離記載的原則

專案管理

治理計劃的實作應規劃及管理為一系列專案。

重要活動:

  • 建立具有優先順序和里程碑的時程表。
  • 識別相關的計劃與相依性。
  • 識別並協調現有的自下而上計劃。
  • 建立符合高階優先順序的反覆項目計劃。
  • 取得預算核准和資金。
  • 建立有形的方式追蹤進度。

金鑰輸出:

  • 具有反覆專案、相依性和排序的項目計劃
  • 回顧的步調,著重於持續改善

重要

上面所列的活動範圍,對組織而言會有很大的不同。 如果您的組織沒有建立這些輸出類型的現有流程和工作流程,請參閱採用藍圖結論中找到的指引,以取得一些實用的資源,以及實作規劃 BI 策略文章

治理原則

決策準則

所有治理決策都應該符合組織採用的既定目標。 一旦策略明確,需要做出更戰術性的治理決策,以影響自助使用者社群的日常活動。 這些類型的戰術決策會直接與所建立的數據原則相互關聯。

我們如何做出治理決策取決於:

  • 神秘 擁有和管理數據和 BI 內容嗎? 內容 擁有權和管理 文章介紹三種策略:企業主導的自助、受控自助和企業。 神秘 擁有和管理內容會對治理需求產生重大影響。
  • 數據傳遞和 BI 內容的範圍為何? 內容 傳遞範圍文章介紹四個內容傳遞範圍 :個人、小組、部門和企業。 傳遞範圍對治理需求有相當大的影響。
  • 什麼是數據主體區域? 數據本身,包括其敏感度層級,是一個重要因素。 某些數據域原本需要更嚴格的控制。 例如,個人標識資訊(PII)或受法規約束的數據,應受到比敏感數據更嚴格的治理需求。
  • 數據和/或 BI 解決方案是否被視為重要? 如果您無法在沒有此資料的情況下輕鬆做出明智的決策,您就會處理重要的數據元素。 某些報表和應用程式可能會被視為關鍵,因為它們符合一組預先定義的準則。 例如,內容會傳遞給主管。 重要事項的預先定義準則可協助每個人有清楚的期望。 重要數據通常受限於更嚴格的治理需求。

提示

上述四個準則的不同組合會導致網狀架構內容的不同治理需求。

Key Fabric 治理決策

當您探索您的目標和目標,並如上所述追求更多戰術性數據控管決策時,請務必判斷優先順序最高。 決定將精力放在何處可能具有挑戰性。

下列清單包含在引進 Fabric 治理時,您可能會選擇優先處理的專案。

如果您沒有做出治理決策並妥善溝通,使用者將會使用自己的判斷來判斷應該如何運作,這通常會導致一般工作的方法不一致。

雖然並非每個治理決策都需要事先做出,但請務必識別組織中風險最大的領域。 然後,以累加方式實作將帶來最大影響的治理原則和程式。

資料原則

數據原則是一份檔,可定義使用者可及無法執行的動作。 您可能會將其稱為不同專案,但目標仍維持不變:做出決策,例如上一節所討論的決策時,系統會記錄這些決策以供使用者社群使用和參考。

數據原則應盡可能短。 這樣一來,人們很容易理解他們被問到什麼。

數據原則應包括:

  • 原則名稱、用途、描述和詳細數據
  • 特定責任
  • 原則的範圍(整個組織與部門特定)
  • 原則的物件
  • 原則擁有者、核准者和聯繫人
  • 如何要求例外狀況
  • 如何稽核及強制執行原則
  • 原則符合的法規或法律需求
  • 術語定義的參考
  • 任何相關指導方針或原則的參考
  • 生效日期、上次修訂日期和變更記錄

注意

集中式入口網站找出或連結至數據原則。

以下是三個您可能會選擇設定優先順序的一般數據原則範例。

原則 說明
數據擁有權原則 指定數據資產需要擁有者,以及數據擁有者的責任包括的時機,例如:支援檢視內容的同事、維護適當的機密性和安全性,以及確保合規性。
數據認證 (簽署) 原則 指定認證內容所遵循的程式。 需求可能包括:數據精確度驗證、數據源和歷程檢閱、數據模型技術檢閱、安全性檢閱和檔檢閱等活動。
數據分類和保護原則 指定每個分類允許和不允許的活動(敏感度層級)。 它應該指定活動,例如:允許與外部用戶共用、有或沒有保密協定 (NDA)、加密需求,以及下載數據的能力。 有時候,也稱為 數據處理原則數據使用原則。 如需詳細資訊,請參閱 Power BI 的資訊保護一文。

警告

有很多檔可能會導致錯誤的感覺,即一切都處於控制之中,這可能會導致自滿。 COE 與使用者社群的參與程度,是改善治理指導方針和原則持續遵循的機會的一種方式。 稽核和監視活動也很重要。

原則範圍

治理決策很少會是整個組織的一刀切。 實際時,最好從標準化原則開始,然後視需要實作例外狀況。 為集中式和分散式小組處理原則的方式明確定義策略,將更容易判斷如何處理例外狀況。

全組織原則的專業人員:

  • 更容易管理和維護
  • 更高的一致性
  • 包含更多使用案例
  • 整體原則較少

全組織原則的缺點:

  • 僵化
  • 較少的自主性和授權

部門範圍原則的專業人員:

  • 針對特定群組量身打造時,預期會更清楚
  • 可自定義且有彈性

部門範圍原則的缺點:

  • 要管理的工作更多
  • 更多被尋址的原則
  • 可能發生衝突的資訊
  • 難以在整個組織中更廣泛地調整規模

提示

找出標準化和自定義的正確平衡,以支援整個組織的自助數據和 BI 可能具有挑戰性。 不過,從組織原則開始並注意例外狀況,您可以快速取得有意義的進度。

人員配置和責任

數據控管的組織結構在組織之間有很大的差異。 在較大的組織中,可能有一個具有專用員工的數據控管辦公室。 某些組織具有數據控管委員會、理事會或指導委員會,其中包含來自不同業務單位的指派成員。 根據組織內數據控管主體的範圍,可能會有一個與功能小組不同的執行小組。

重要

無論治理主體的結構如何,對於數據控管決策而言,有一個對數據控管決策具有足夠影響力的人員或群組是很重要的。 此人應該有權跨組織界限強制執行這些決策。

檢查和餘額

治理責任是關於檢查和餘額。

Diagram shows the four types of operational, tactical, and strategic involvement, which are described in the table below.

從底部開始,上圖中的層級包括:

等級 說明
Level 1. 營運 - 業務單位: 層級 1 是妥善管理系統的基礎,其中包含執行其工作之業務單位內的使用者。 自助數據和 BI 建立者有許多與撰寫、發佈、共用、安全性和數據品質相關的責任。 自助數據和 BI 取用者也有責任適當地使用數據。
Level 2. 戰術 - 支援小組: 層級 2 包含數個群組,可支援業務單位中的使用者努力。 支援小組包括 COE、企業數據和 BI、數據控管辦公室,以及其他輔助小組。 輔助小組可以包含IT、安全性、HR和法律。 這裡也包含變更控制板。
Level 3. 戰術 - 稽核與合規性: 層級 3 包含內部稽核、風險管理和合規性小組。 這些小組提供層級 1 和 2 的指引。 它們也會在必要時提供強制執行。
Level 4. 戰略 - 執行贊助者和指導委員會: 最高層級包括對策略和優先事項的行政層級監督。 此層級會處理無法在較低層級解決的任何呈報問題。 因此,務必讓具有足夠權威的領導小組在必要時做出決策。

重要

每個人都有責任遵守原則,以確保組織數據安全、保護及妥善管理為組織資產。 有時候,這被引用為 每個人都是數據管理人。 為了讓這成為現實,請從業務單位的使用者(上述第 1 級)作為基礎開始。

角色和責任

一旦您對治理策略有意義,應該定義角色和責任,以建立明確的期望。

治理小組結構、角色(包括術語)和責任在組織之間有很大的差異。 下表描述非常一般化的角色。 在某些情況下,同一個人可以擔任多個角色。 例如,首席數據官(CDO)也可以是執行贊助者。

角色 說明
首席數據官或首席分析官 定義數據作為企業資產使用的策略。 監督整個企業的治理指導方針和原則。
數據控管面板 指導委員會與每個業務單位的成員,身為網域擁有者,有權做出企業治理決策。 他們會代表業務單位 組織的最佳利益做出決策。 提供企業數據控管小組和工作委員會的核准、決策、優先順序和方向。
數據控管小組 建立治理原則、標準和程式。 提供全企業的數據完整性、信任性、隱私權和可用性的監督和優化。 與 COE 共同作業,為數據擁有者和內容建立者提供治理教育、支持和指導。
數據控管工作委員會 著重於個別治理主題的暫時或永久小組,例如安全性或數據品質。
變更管理面板 協調發行管理程式的需求、程式、核准和排程,以降低風險,並將變更對重要應用程式的影響降至最低。
專案管理辦公室 管理個別治理項目和進行中的數據控管計劃。
網狀架構執行贊助者 促進採用和成功使用 Fabric。 主動確保網狀架構決策一致地符合跨組織界限的商業目標、指導原則和原則。 如需詳細資訊,請參閱 執行贊助 文章。
卓越中心 指導創作者和消費者社群,以促進網狀架構的有效決策使用。 提供網狀架構活動的跨部門協調,以改善做法、提高一致性,並減少效率不佳。 如需詳細資訊,請參閱 卓越 中心一文。
網狀架構冠軍 在業務單位中找到的內容建立者子集,可協助推進 Fabric 的採用。 他們提倡使用最佳做法並積極協助同事,來促進數據文化成長。 如需詳細資訊,請參閱 練習 社群一文。
網狀架構系統管理員 日常系統監督責任,以支持內部程式、工具和人員。 處理監視、稽核和管理。 如需詳細資訊,請參閱 系統監督 一文。
資訊科技 針對與 Fabric 相關的服務,提供 Fabric 系統管理員的偶爾協助,例如 Microsoft Entra ID(先前稱為 Azure Active Directory)、Microsoft 365、Teams、SharePoint 或 OneDrive。
風險管理 檢閱及評估數據共享和安全性風險。 定義道德數據原則和標準。 傳達法規和法律需求。
內部稽核 稽核法規和內部需求的合規性。
數據管理人 與治理委員會和/或 COE 共同作業,以確保組織數據具有可接受的數據品質層級。
所有 BI 建立者和取用者 遵循原則,以確保數據安全、受保護且妥善管理,做為組織資產。

提示

為關鍵角色中的每個人員命名備份,例如數據控管面板的成員。 在他們缺席的情況下,備份人員可以出席會議,並在必要時做出時間敏感的決策。

注意事項和關鍵措施

檢查清單 - 您可以採取的考慮事項和重要動作,以建立或強化治理計劃。

  • 對齊目標和指導原則: 確認數據文化目標的高階目標和指導原則已清楚記載並傳達。 請確定任何新的治理指導方針或原則都存在對齊。
  • 瞭解目前發生的情況: 請確定您已深入瞭解 Fabric 目前如何用於自助和企業數據和 BI 案例。 記錄改善的機會。 此外,文件優勢和良好做法有助於更廣泛地相應放大。
  • 設定新治理指導方針和原則的優先順序: 若要將要建立的新指導方針或原則設為優先順序,請選取重要的痛點、高優先順序需求,或數據網域的已知風險。 它應該具有顯著的好處,而且可以通過可行的努力水平來實現。 當您實作您的第一個治理指導方針時,請選擇使用者可能支援的內容,因為變更的影響很低,或因為他們有足夠的動機進行變更。
  • 建立排程以檢閱原則: 判斷重新評估數據原則的頻率。 在需要變更時重新評估並調整。
  • 決定如何處理例外狀況: 決定如何處理已記載原則的例外狀況衝突、問題和要求。
  • 瞭解現有的數據資產: 確認您瞭解哪些重要的數據資產存在。 視需要建立擁有權和譜系的清查。 請記住,您無法控管您不知道的內容。
  • 確認主管贊助:確認您有執行贊助者和業務單位領導者的支持和足夠的關注
  • 準備行動計劃: 包含下列重要專案:
    • 初始優先順序: 一次選取一個數據域或業務單位。
    • 時間軸: 在反覆專案中工作的時間夠長,足以完成有意義的進度,但足夠短,可以定期調整。
    • 快速獲勝: 專注於有形、戰術和漸進式的進步。
    • 成功計量: 建立可測量的計量來評估進度。

要思考的問題

使用如下找到的問題來評估治理。

  • 概括而言,目前的治理策略為何? 對於終端使用者和中央數據和BI小組而言,此治理策略的目的和重要性為何?
  • 一般而言,目前的治理策略是否有效?
  • 組織(或特定業務單位)必須遵守的主要法規和合規性準則為何? 此準則記載在哪裡? 這項資訊是否可供使用數據和共享數據項作為其角色一部分的人員使用?
  • 目前的治理策略如何與用戶的運作方式保持一致?
  • 組織是否負責治理的特定角色或小組?
  • 神秘 有權建立和變更治理原則嗎?
  • 治理小組是否使用 Microsoft Purview 或其他工具來支援治理活動?
  • 哪些優先治理風險,例如安全性資訊保護和數據外泄防護的風險?
  • 已識別治理風險的潛在業務影響為何?
  • 重新評估治理策略的頻率? 哪些計量可用來評估它,以及商務使用者提供意見反應的機制為何?
  • 當使用者使用數據時,哪些類型的用戶行為會造成風險? 這些風險是如何減輕的?
  • 如果有的話,有哪些敏感度標籤已就緒? 數據和 BI 決策者是否知道敏感度標籤和業務的優點?
  • 如果有的話,有哪些數據外泄防護原則已就緒?
  • 如何處理「導出至 Excel」? 要防止數據外洩防護採取哪些步驟? 「導出至 Excel」的流行程度為何? 在 Excel 中擁有數據之後,人員會怎麼處理數據?
  • 是否有必須緊急解決不符合法規規範的做法或解決方案? 這些範例是否合理說明潛在的商業影響,是否不應加以解決?

提示

「導出至 Excel」通常是一個有爭議的話題。 企業使用者通常會將焦點放在 BI 解決方案中「導出至 Excel」的需求。 啟用「導出至 Excel」可能會適得其反,因為商務目標不會將數據帶入 Excel。 相反地,請定義用戶為何需要 Excel 中的數據。 在 Excel 中處理數據後,詢問他們執行哪些商務問題、他們嘗試回答哪些決策,以及他們對數據採取哪些動作。

專注於商務決策和動作有助於引導人們遠離工具和功能,並協助人們實現其商務目標。

成熟度等級

下列成熟度層級可協助您評估治理計劃目前的狀態。

等級 治理狀態
100:初始 • 由於缺乏治理規劃,所發生的良好數據管理和非正式治理做法過於依賴個人判斷和經驗層級。

• 大量依賴未經記載的部落知識。
200:可重複 • 組織的某些領域已作出有目的的努力,以標準化、改善及記錄其數據管理和治理做法。

• 初始治理方法存在。 正在進行累加式進度。
300:已定義 • 制定並廣泛傳達具有焦點、目標和優先順序的完整治理策略。

• 針對少數優先順序(痛點或機會)實作特定的治理指導方針和原則。 他們積極且一致地跟著使用者。

• 角色和責任已明確定義並記載。
400:能力 • 所有網狀架構治理優先順序都符合組織目標和商務目標。 目標會定期重新評估。

• 程式存在來自定義分散式業務單位的原則,或處理標準治理原則的有效例外狀況。

• 很明顯,Fabric 適合組織的整體數據和 BI 策略。

• 會主動分析網狀架構活動記錄和 API 數據,以監視和稽核網狀架構活動。 主動式動作是根據數據採取的。
500:高效率 • 定期檢閱 KPI 或 OKR 評估可測量的治理目標。 反覆的持續進度是優先順序。

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

• 網狀架構活動記錄和 API 數據會主動用來通知及改善採用和治理工作。

在 Microsoft Fabric 採用藍圖系列中的 下一篇文章 中,瞭解指導和用戶啟用。