數據治理

以企業財務管理為例，會計負責管理企業的金融資產，遵守相關制度和規定，同時接受審計員的監督；審計員負責監管金融資產的管理活動。數據治理扮演的角色與審計員類似，其作用就是確保企業的數據資產得到正確有效的管理。

由於切入視角和側重點不同，業界給出的數據治理定義已經不下幾十種，到目前為止還未形成一個統一標準的定義。 ^[1] 

ITSS WG1認為數據治理包含以下幾方面內容

（1）確保信息利益相關者的需要評估，以達成一致的企業目標，這些企業目標需要通過對信息資源的獲取和管理實現；

（2）確保有效助力業務的決策機制和方向；

（3）確保績效和合規進行監督。

數據治理過程 ^[2] 

從範圍來講，數據治理涵蓋了從前端事務處理系統、後端業務數據庫到終端的數據分析，從源頭到終端再回到源頭形成一個閉環負反饋系統（控制理論中趨穩的系統）。從目的來講，數據治理就是要對數據的獲取、處理、使用進行監管（監管就是我們在執行層面對信息系統的負反饋），而監管的職能主要通過以下五個方面的執行力來保證——發現、監督、控制、溝通、整合。

應對型數據治理是指通過客户關係管理（CRM）等“前台”應用程序和諸如 企業資源規劃（ERP）等“後台”應用程序授權主數據，例如客户、產品、供應商、員工等。然後，數據移動工具將最新的或更新的主數據移動到多領域MDM系統中。它整理、匹配和合併數據，以創建或更新“黃金記錄”，然後同步回原始系統、其它企業應用程序以及數據倉庫或商業智能分析系統。

缺點：

批量集成和應對型數據治理方法引入的時間延遲可能導致業務部門繼續操作重複、不完整且不精確的主數據。因此，這會降低多領域MDM方案實現在正確的時間向正確的人員提供正確數據這一預期業務目標的能力。在期望被設定為數據將變得乾淨、精確且及時之後，批量集成引入的時間延遲讓人感到沮喪。應對型數據治理（下游數據管理員小組負責整理、去重複、糾正和完成關鍵主數據）可能導致讓人認為“數據治理官僚化”。

應對型數據治理還會導致最終用户將數據管理團隊看作“數據質量警察”，併產生相應的官僚化和延遲以及主數據仍然不乾淨的負面認識。這還將使得MDM方案更難實現它的所有預期優勢，並可能導致更高的數據管理總成本。此方法的風險是組織可能以“兩個領域中的最差”而告終，至少部分上如此–—已在MDM方案中投資，但是隻能實現一些潛在優勢，即在整個企業內獲得乾淨、精確、及時以及一致的主數據。

改進方法：

有三個方法可超越應對型數據治理。

1. 用户將數據直接輸入到多領域MDM系統中：用户使用界面友好的前端將數據直接輸入到多領域MDM系統中，但是他們的新記錄和現有記錄的更新留在暫存區域或保留區域，直到數據管理員審核和認證為止。這之後MDM系統才接受插入或更新，以便進行完整的整理、匹配、合併，並將“最佳記錄”發佈到企業的所有其他應用程序。此方法好過將一個完全不同的應用程序（例如CRM或ERP系統）作為“錄入系統”，但是它仍然會出現延遲和效率低下。儘管存在這些缺點，使用暫存區域確實解決了大部分問題，例如不用強制執行重要屬性的錄入或在創建前不必進行徹底搜索。此外，由於我們並不受傳統應用程序或現代CRM或ERP應用程序如何處理數據錄入功能的影響，通過不對應對方法進行批量數據移動，我們還大大縮短了時間安排。

2. 用户輸入直接傳送到多領域MDM系統中的數據：在外面輸入新記錄或更新，但是會立即傳送到MDM系統，以便自動整理、匹配和合並。異常或例外傳送到數據管理員的隊列，幾個管理員便可支持更多最終用户。這是第一個主動方法的改進，因為我們利用MDM系統的業務規則、數據整理和匹配功能，只要求管理員查看作為整理、匹配和合並流程的例外而彈出的插入或更新。

3. 用户使用特定於數據治理的前端輸入數據：第三個方法是允許最終用户直接錄入到多領域MDM系統中，但是應使用專為主動數據治理方法而設計的前端。可專門為最終用户數據錄入設定屏幕，您可利用功能齊全的MDM系統允許的自動化、數據整理、業務規則、搜索和匹配等所有功能。因此，不必首先將數據輸入到MDM系統的暫存區域中，並且您不需要系統外的單獨工作流應用程序。

主動數據治理的第一個優勢是可在源頭獲得主數據。具有嚴格的“搜索後再創建”功能和強大的業務規則，確保關鍵字段填充經過批准的值列表或依據第三方數據驗證過，新記錄的初始質量級別將非常高。

主數據管理工作通常着重於數據質量的“使它乾淨”或“保持它乾淨”方面。

如果MDM系統中的數據質量初始級別非常高，並且如果您不會通過從CRM或ERP源系統中傳入不精確、不完整或不一致的數據來連續污染系統，則主數據管理的“保持它乾淨”方面非常容易。

主動數據治理還可有效消除新主記錄的初始錄入和其認證以及通過中間件發佈到企業其餘領域之間的所有時間延遲。由用户友好的前端支持的主動數據治理可將數據直接錄入到多領域 MDM 系統中，可應用所有典型的業務規則，以整理、匹配和合並數據。當初始數據錄入經過整理、匹配和合並流程後，此方法還允許數據管理員通過企業總線將更新發布到組織的其它領域。

主動數據治理方法消除了“數據治理官僚化”這一認識，因為主數據的授權已推給上游的業務用户，使數據管理員處於很少被打擾的角色，他們將不會成為諸如訂單管理或出具發票等關鍵業務流程的瓶頸。

銷售和營銷均受益，因為可更迅速且經濟有效地完成營銷活動，在啓動活動之前無需前期數據糾正。財務上也受益，因為將一次性捕獲新客户需要的所有數據元素，添加新客户的流程包括提取第三方內容並計算信貸限額，然後將該信息傳回ERP系統。

沒有直接訪問MDM系統權限的客户服務代表通常必須搜索幾個系統，找到他們需要的信息，從而採取措施。當通話中的客户沒有耐心時，很難提供高級別的服務。當所有信息存儲在MDM系統中並可通過有效、用户友好的前端進行訪問時，客户服務代表將能夠訪問每個客户交互需要的所有數據，並能夠在需要時授權新數據。

通過使MDM成為錄入系統及記錄系統，您能從本質上將數據維持在“零延遲”狀態，它在這種狀態下適合企業中的任何預期使用場景，同步到CRM和ERP系統的數據的清潔性、精確性、時效性以及一致性應當處於最高級別。

MDM應當成為不僅是主數據而且是主數據間的關係的記錄系統。它成為全方位瞭解不同系統的數據如何互相關聯的中心位置。例如，多領域MDM系統將來自訂單管理系統的銷售訂單和應收賬款中的發票關聯在一起。這些關係或層次結構顯示在與MDM系統數據直接交互的用户界面中。用户界面還可用於查看主數據間的關係並在MDM系統中直接編輯它們。因此，MDM還成為關係的錄入系統。

當您從諸如CRM系統等外部系統中接受新記錄或更新後的記錄時，可能會限制您跟蹤該記錄的歷史記錄，因為外部應用程序作出了一些限制。當MDM為錄入系統和記錄系統時，審計歷史記錄的複雜跟蹤和數據的沿襲成為可能。隨着時間的推移，它甚至可顯示核心主記錄的更改，按照各種用户和流程在動態時間視圖中顯示插入和更新，可跟蹤和顯示每個屬性中的每個更改。工作流使用可配置的前端可設計和執行基本工作流功能，因此最終用户可輸入新主記錄。但是，這些新記錄可能需要數據管理員的批准步驟，然後才能將它們完全接受到多領域MDM系統中併發布到企業的其它領域。另外一個工作流應用程序在數據管理員的任務隊列中。匹配或自動合併重複記錄遇到的例外傳送到相應的數據管理員。高級功能允許將問題提交給相應的人員，當用户在休假時可自動重新傳送給後備人員。通過直接查看特定工作流步驟和這些流程的經過時間，減少了花費在查詢新記錄或更改後的記錄狀態的時間。

用户界面應當是可配置的，並且不同的工作角色具有不同的訪問和許可級別。幫助數據管理員解決差異的一些數據元素可能不適合企業中的每個人查看。此外，即使在一個工作角色內，例如數據管理員，您可能需要不同的安全性級別，同時更高級別的人員能夠對更廣泛的記錄集執行更多操作。而且，您可能需要分離訪問權限，例如德國的數據管理員不能查看法國客户記錄。

使用MDM外部的CRM或ERP系統作為錄入系統時，該應用程序的安全模型可能會在誰有權對哪些記錄進行哪些操作方面強加一些限制。將主記錄的錄入和維護直接移到多領域MDM系統之後，您可更加詳細地控制數據的安全性，可具體到每個屬性或字段級別。

什麼因素阻止公司採用主動數據治理方法？總的來説，問題在於它們在數據治理成熟度等級中處於什麼位置。一家公司很難從成熟度模型的最左側——它們在其中沒有中央多領域MDM系統並且沒有數據治理組織或流程——直接跳到該等級的最右側，它們在其中擁有強大的數據治理流程外加最新MDM系統和集成架構。通常，隨着時間的推移，組織會改進它們的數據治理方法。例如，當初始MDM系統開啓並運行之後，一些預期的優勢需要較長時間才能實現，或應對方法的侷限性變得顯而易見，您可計劃以便在原始源系統中取消授權記錄的功能，並將該功能直接遷移到MDM系統中。

升級公司的集成或中間件功能（例如，添加一個能處理實時更新的集成工具）之後，可切換到主動數據治理方法，或作為現有CRM或ERP系統重大升級的一部分，因為這可能是引進需要的業務流程變更的最佳時機。

何時從“應對型”遷移為“主動型”？

度量標準將推動業務案例從應對型數據治理遷移到主動數據治理。

問您自己以下問題，並嘗試量化時間、精力和費用投資方面的答案：

· 吸納一個新客户需要多長時間？

· 涉及多少個不同步驟？

· 在普通新記錄被接受到多領域MDM系統之前會接觸它多少次？

· 由於這些源系統的侷限性，仍在源系統中創建多少個重複記錄（然後在MDM系統中合併）？

· 需要多少個數據管理員支持該企業？

· 主記錄是否進入了“更改，改回”循環，因為兩個不同的用户組試圖強制執行兩個不同的業務規則集？

· 主記錄的重要方面是否因源系統和MDM系統之間的“裂縫而失敗”？

· 維護各個源系統和MDM系統之間的集成的流程是否成為一種負擔？

· 在CRM系統中輸入新記錄後，必須等待才能在ERP系統中變得可用，用户是否有所抱怨？

· 是否存在數據治理的資金問題，因為它被看做是管理費用或一種官僚作風？

回答這些問題之後，應當明顯看出您是否將能夠遷移到更主動的數據治理方法。您可詳細計劃遷移流程，將它設立為一個獨立的項目或將它集成到另一個相關項目中。

一些情況要求立即開始主動數據治理，例如當您獲得多個CRM系統和ERP系統，它們要求與多領域MDM系統集成，以便讓它們繼續充當錄入系統，或當您的當前源系統非常脆弱或很難維護或修改。

在這些情況下，要忍受困難並從一開始便為主動數據治理作出計劃。一些組織擁有成千上萬個直接在MDM系統中授權主數據的最終用户，並且有一個數據管理員團隊支持他們、發現異常、解決低質量匹配、在需要時手動合併重複記錄等等。另一種應用情況是當您發現自己最終會選擇主動數據治理方法 — 何必再為建立源系統到多領域MDM系統的雙向集成而爭論？您或許不妨直接授權最終用户來編寫主數據。

企業級數據管理軟件提供商Informatica公司認為：數據治理成功的關鍵在於元數據管理，即賦予數據上下文和含義的參考框架。經過有效治理的元數據可提供數據流視圖、影響分析的執行能力、通用業務詞彙表以及其術語和定義的可問責性，最終提供用於滿足合規性的審計跟蹤。元數據管理成為一項重要功能，讓IT部門得以監視複雜數據集成環境中的變化，同時交付可信、安全的數據。因此，良好的元數據管理工具在全局數據治理中起到了核心作用。

作用及其管理

Informatica將數據治理定義為“在組織範圍內，對流程、政策、標準、技術和人員進行職能協調和定義來將數據作為公司資產管理，從而實現對準確、一致、安全且及時的數據的可用性管理和可控增長，以此制定更好的業務決策，降低風險並改善業務流程”。

數據治理着重於交付可信、安全的信息，為制定明智的業務決策、有效的業務流程並優化利益相關方交互提供支持。因此，數據治理本身並非是結果，而僅僅是方法：即通過數據治理來支持最關鍵的業務目標。

元數據為數據提供了一個參考框架。Forrester Research將元數據定義為“用於描述數據、內容、業務流程、服務、業務規則以及組織信息系統的支持政策或為其提供上下文的信息”。譬如，蘋果公司旗下的App Store在網上銷售軟件應用程序。在此情況下的數據是應用程序。元數據則是關於這些應用程序的信息，包括應用程序描述、價格、用户評級、評論和開發公司。

正如某家大型銀行的高管所言：“如果沒有數據治理，任何元數據管理方案註定會失敗。”元數據管理可作為一項重要功能，讓IT部門得以管理複雜數據集成環境中的變化，同時交付可信、安全的數據。當業務利益相關方參與這一進程並接受對數據參考框架的責任，其優勢將變得更有説服力。此時，企業就能將業務元數據與基層的技術元數據進行關聯，為全公司範圍內的協作提供詞彙表和背景資料。 ^[3] 

例如，當業務用户要求其在IT部門的搭檔在報告或分析中顯示“淨收入”，就無需再提問“哪種淨收入——財務、銷售還是市場營銷？”除提供其他優勢外，良好的元數據管理還可通過免除此類重要問題，促進數據治理：

· 這個業務術語的含義是什麼？

· 在（幾個相似的）業務術語中應當使用哪一個？

· 該術語的來源是什麼？

· 該數據從數據源轉移到目標時是如何進行轉換的？

· 由誰負責該術語的定義、記錄和管理？

· 誰修改過該術語？如何及何時進行修改？

· 哪些政策和規則適用於該術語？

· 修改環境中的某一特定數據對象會對其他數據對象產生哪些影響？

· 在不對可能使用相同數據對象的其他報告和分析造成影響的前提下，需要多長時間來實施環境變更？

一系列公司方案推動了數據治理的進展，也由此帶動了元數據管理。這些方案包括： ^[4] 

· 通用業務詞彙表（簡單的數據管理）。這種“小規模試水”方法着重於某一特定問題或業務部門的通用業務詞彙表。

· 全面數據治理（或數據管理策略）。這是一種更近似由上至下的方式，通常用於涉及企業內一系列業務部門的較大規模計劃，並以按多個階段（如果不是更長時間）進行管理的計劃中的多個商機為目標。

· 合規。此類方案的推動因素是為遵守國際、國家、當地或行業法規的需求。合規——通常由一個治理、風險與合規性（GRC）職能部門進行管理，顯然與數據治理唇齒相依。在發現、分析和記錄企業的多項內部數據治理要求的同時，還必須與適用外部法規的相關特定要求進行統籌協調。其中部分示例包括：

· 銀行業：Basel II、Basel III、多德弗蘭克法案（Dodd Frank）、洗錢法案

· 保險業：償付能力監管標準II（Solvency II）

· 醫療保健：HITECH Act、HIPAA

· 一般金融服務：薩班斯—奧克斯利法案

· 元數據管理。這是更上一層樓的做法，將元數據管理和數據治理作為“最佳實踐”與各個新的業務方案掛鈎。該方案對業務案例和項目範圍進行定義。在多家未能成功實施較大型數據治理方案的公司中，這一方法則取得了成功。

幾乎所有企業都面臨着管理數據量、速度和種類的挑戰。Hadoop/MapReduce技術在複雜數據分析能力以及按相對低廉的成本實現最大數據擴展性方面提供了一些有趣的優勢。Hadoop在不久的將來取代關係性DBMS的可能性不大，這兩項技術更有可能並存，因為它們各有獨到之處。雖然用於管理和分析數據的技術可能不同，元數據管理和數據治理的目標應始終保持不變：為支持良好的業務決策提供可信、及時且相關的信息。不存在所謂的“大數據治理”或“大數據元數據管理”——相反，這是一個將全局企業數據治理和元數據管理活動加以擴展來包容全新數據類型和數據源的問題。

Hadoop帶來的挑戰之一就是元數據管理。如果沒有良好的元數據管理和數據治理，Hadoop將會缺乏透明度、可審計性以及數據的標準化與重複利用能力。企業仍將需要對數據相關關鍵信息的可見性，例如其來源、質量和所有權，否則就必須承受Hadoop變成環境內的又一個數據孤島的風險。在該領域湧現的HCatalog和Hive/HiveQL等新技術將使得從非結構化和半結構化數據中收集元數據變得更加簡易，從而實現Hadoop上的數據沿襲。這些功能對於將Hadoop集成入總體數據集成框架，以防止大數據在企業中遭到孤立隔絕，可如同任何其他數據源一樣進行治理至關重要。

有關數據治理的問題並不能在企業的單一部門得到解決。這需要IT與業務部門進行協作，而且必須始終如一地進行協作，以改善數據的可靠性和質量，從而為關鍵業務方案提供支持，並確保遵守法規。Informatica能夠提供企業級數據治理解決方案，該解決方案可以在本地或雲中使用，在傳統數據或大數據中均有使用案例，可以滿足業務和IT部門的需求。

Informatica可提供功能齊全而又穩健可靠的數據治理解決方案，具備交付可信、安全的數據和啓動成功的元數據管理方案所需的全部精確功能。Informatica Axon提供端到端智能數據治理解決方案，以整體、協作的方法將員工、流程和系統流暢融合，從而實現戰略業務成果。Axon Data Governance作為協作中心，為成功實施數據治理計劃提供支持。

ITSS WG1發佈的白皮書表明

數據治理模型包括三個框架：範圍、促成因素和執行及評估。他們每個方面都包含許多組件來進行展示和描述它們是如何工作的。該框架顯示數據治理內部的邏輯關係。範圍展示了我們應該關注什麼，促成因素展示了數據治理的推動因素，執行和評估展示瞭如何實現治理的方法。該DG模型可以通過三個框架幫助我們理解數據治理。

數據治理的範圍包括四個層次的內容。首先，應該 ^[5]  有一個治理要素負責管理其它管理要素，保證治理與管理的一致性。其次，下面的三個層次分別列示了需要治理的數據管理要素：

其中價值創造層列示了通過數據治理所創造的價值服務；

價值保證層描述了一個組織治理數據時重要保證服務；

基礎數據服務層描述了一個數據治理的基礎數據服務。

數據治理工作需要使用到哪些技術和工具？

引用了國內某一數據服務廠商的數據治理工具來簡述一下。

元數據管理：包括元數據採集、血緣分析、影響分析等功能

數據標準管理：包括標準定義、標準查詢、標準發佈等功能

數據質量管理：包括質量規則定義、質量檢查、質量報告等功能

數據集成管理：包括數據處理、數據加工、數據彙集等功能

數據資產管理：包括數據資產編目、數據資產服務、數據資產審批等功能

數據安全管理：包括數據權限管理、數據脱敏、數據加密等功能

數據生命週期管理：包括數據歸檔、數據銷燬等功能

主數據管理：包括主數據申請、主數據發佈、主數據分發等功能