一、數據治理建設路徑

1、業務數字化的目的是打造一體化的業務流、信息流與數據流

?從企業整體經營管理的角度，戰略制定及分解—領域業務目標制定—業務方案設計—業務需求識別 & 信息系統功能及數據庫設計—數據匯聚及分析—業務目標監測及改善，這個過程會有層層信息耗散，全局數據治理的目的就是利用體系機制保障最大程度減少這個耗散或補足耗散的部分，讓數據盡可能的還原企業的業務事實。

企業在 IT 規劃過程中，首先會做業務流梳理，表現為流程架構、價值流或者能力框架；業務流中的相關信息流轉，如表、證、單、書等，稱之為信息流；信息流中識別出數據對象，梳理數據關系，可以指導數字化系統建設。

但是企業在實際開展數字化過程中，人力資源、采購、生產、研發等每個領域都會有數字化訴求。業務人員和 IT 人員通過分析應用訴求，把業務流轉和應用需求相結合，進行數據設計，進而形成新系統。因為 IT 建設是逐步開展的，業務人員的視角不同，實施人員和數據開發人員的理解各異，最終每個系統都會對數據有自己的局部理解，因此簡單的把人力資源、采購、生產、研發等存量信息系統里面的數據拼到一起，是無法構建出反映企業業務本質的數據流或者數據孿生模型的。

數字化的數據如果無法反映業務全貌，那基于這些數據進行加工也不可能得到正確的結果，因此需要通過對業務的理解進行數據治理。

數據治理是從業務流到信息流、數據流、數據庫表的流轉。業務系統中的物理表字段，哪怕短期內由于無法改變業務系統不能完成源頭治理，也要在數倉的 ODS 層完成治理，形成能還原業務本質的數據映象。

數據映象描述的是業務過程中的業務細節。企業經營中戰略分解到各業務部門的經營目標都會有相關的考核指標。如果數據映象是真實的，那基于指標體系做的業務分析就能更真實反應業務階段結果，達成企業業務流、信息流、數據流的一致性，支撐企業從戰略規劃到目標分解的監控，最終實現數據價值的呈現。

總結來說，整個數據治理的核心動作分為兩個部分，一個是業務數據的治理（形成真實數據映像），另一個是分析體系的治理（基于數據映像面向管控目標做合理性的分析結構設計及實現）。?

2、典型的企業數字平臺框架

典型企業的數字平臺框架如上圖所示。

（1）業務系統作為局部數據映象或數據源。

（2）數據中臺做全面的數據匯聚與建模，數據中臺基于貼源層、明細層、匯總層、應用層進行分層，面向分析型需求由開發人員進行數據建模。

（3）自助式數據消費是面向業務分析師或者有一定業務理解能力的開發人員，他們會自助式的基于成熟的模型進行組裝式的開發。

（4）智能決策包括駕駛艙、可視建模和智能應用等。

從業務數據系統的數據源到分層的數據建模以及數據消費的全過程，需要一系列的管理機制，包括數據標準、數據模型、數據質量以及管理流程和機制，形成了一套體系化、規范化的方法，保證整個鏈路的暢通。

3、對數據治理核心內容的理解

滴普對理解的數據治理核心內容包括三塊：數據治理體系設計，業務數據深化治理，分析數據體系設計。

（1）數據治理體系設計

數據治理體系設計主要涉及數據架構、數據標準、主數據等該如何進行治理動作管理。首先基于業務系統和分析系統現狀，梳理一套機制并把該機制固化起來，但這只是一套文檔和理想態機制，需要與業務數據及分析數據體系的實際開展動作進行結合細化；同時建立聯合團隊一起進行一些專業性的數據治理活動，如建立數據目錄、數據標準等，構建數據管理內容的同步將能力轉移并固化在甲方身上。本質上是通過體制機制、流程文件去固化企業的專項數據能力，以將數據治理作為一項持續性的工作開展下去。

當然也會涉及到數據管理組織的設計，組織設計是相對可大可小的事情，因為會涉及到數據資產權限，業務部門，IT 部門等平臺部門。

（2）業務數據深化治理

這部分包括幾個比較核心的工作：

第一、 數據資產目錄

梳理方法上有自上而下、自下而上兩個方向。

自上而下：基于業務鏈條去識別每一個業務領域，比如制造、研發、生產、采購等的關鍵信息，這些信息有可能已經在 IT 系統有留存，也有可能是一個線下紙質的表單。數據資產目錄構建要描述企業全部數據要素，但是系統的建設一定是落后于企業的管理訴求的，所以不能只是梳理企業既有的 IT 平臺里的數據要素，需要基于整個業務鏈條去梳理企業的數據要素，構建數據資產目錄、進行分級分類。

自下而上：因為單純基于業務鏈條有些業務細節可能會被忽略，所以需要基于存量的 IT 系統的數據庫表進行盤點和映射作為補充。

通過自上而下從業務出發，自下而上從數據庫表出發，可以得到相對近似于企業數據資產全貌的數據資產目錄。數據資產目錄厘清了企業的業務數據資產，它有兩個用途：

① 構建業務友好的數據地圖。數據資產結構劃分是基于業務線構建的，會形成對業務非常友好的可視結構。不論是當前 IT 系統的庫表結構，還是識別出的數據對象實體以及未來的指標標簽都可以和它進行關聯。可以給業務人員提供友好的數據資產入口，同時支撐高階的數據分析人員及數據開發人員找數。

② 劃分責任田。如果企業是自上而下進行業務梳理的，會有從業務域到業務子域到整個業務對象的目錄映射，可以很容易的找到每一個數據的責任人，當出現一些數據標準、跨領域的數據爭議的時候，可以起到劃分責任田的作用。

第二、數據模型

通過數據目錄可以知道有多少數據資產，通過數據模型可以知道數據對象之間的關系。

數據模型包括概念模型、邏輯模型和物理模型。治理項目初始完成概念模型，只有對象和對象之間的關系，后續需持續進行邏輯模型的建設（加入主外鍵、關鍵屬性）。在做專題的主數據治理需要實現數據清潔干凈，提升質量，其中深化的邏輯模型設計是其重要支撐。

第三、數據標準設計

數據標準應該是面向未來的業務需求去設計的，其不只是存量的字段長度、表結構，還包括業務規則、業務含義、業務的管理角色等相關標準。有的數據標準是面向增量數據結構的，比如可以用數據標準去約束數倉內的增量的數據變更或者新增的 IT 系統的數據結構。但是對于存量系統來說，其數據結構可能和數據標準存在差異，如果強制存量 IT 系統修改，短時間是不可行的，通?？梢酝ㄟ^建立映射關系解決，以兼顧業務連續性需求及面向未來業務的合理性。

第四、數據分布定義

盤點數據標準在存量的業務系統包括數倉內的分布情況。有些分布會極其復雜，如有的制造業企業有七八十個系統，每個系統各管一個業務段，數據分布相當繁雜，可能單一屬性分布在十幾個系統和幾十張表中。

識別完數據分布以后，還要識別可信數據源。比如從 20 個數據源里面定義 TOP5 的可信數據源，TOP5 的可信數據源里面，可能建立交集、并集、篩除等關系。

第五、數據質量改善

開展專項數據治理，一方面是標準比對；另一方面，對主數據和主數據相關的重要交易數據做關鍵屬性洞察。

通過業務資產梳理，可以收集業務人員以及 IT 人員遇到的問題和困難，并對其進行根因分析，制定數據探查的規則以識別數據問題。再進一步分析這些問題到底是業務問題、數據流轉的問題、系統應用功能問題，還是數據結構和數據標準本身執行不到位的問題，并給出改善建議。如短期內通過映射關系解決，長期內希望通過業務及數據管理動作進行改善，因為業務及數據管理動作才是數據質量產生的源頭。

（3）分析數據體系設計

分析數據體系分為兩個部分。

第一、厘清分析數據資產

包括兩部分：

① 指標管理體系。首先做存量分析建設，存量就是各個業務部門已經在使用的系統、報表、指標，同一個指標可能有多個部門在用。將這些指標收集起來，做結構化、標準化，包括指標的聚合、收斂、規則定義，叫做指標存量標準化設計。

② 運營績效指標設計。如果企業本身處于管理變革階段，單個領域業務方向的變化會牽引出新的考核體系?？梢曰谇罢靶缘目己梭w系設計一套指標體系，牽引管理變革落地的方向。另外，一些行業實踐的成套體系的指標可以借鑒（例如 IPD、MTL），進行企業內部管理的優化，這些內容屬于運營績效指標設計。

第二、數據能力供給設計

分析數據體系除去指標，還有比如標簽、算法模型，如制造業的庫存優化分析等算法模型、車聯網的充電模型等高階數據應用的設計，定義為數據能力供給設計。

4、數據治理開展路徑

數據治理開展路徑，有如下的兩部分組成：

第一部分，治理活動。

首先以數據盤點為切入點，形成覆蓋企業業務全域的數據資產地圖。數倉一般是按照 FSLDM 模型的理念構建，雖然對于開發人員非常友好但是對業務的可讀性相對較低，必須基于業務友好的視角做數據盤點和建立高可讀性的資產地圖。

資產地圖首先需要做資產的價值排序和痛點排序以確定哪些資產優先治理。排序有兩種視角，一種是按主題，比如客戶主數據，供應商主數據以及和它相關的重要的數據；還有一種是按業務域，比如采購域、生產域、財務域。

資產地圖的進一步的治理是做標準化、質檢改善。以采購域為例，做采購域的數據標準的設計，做存量和增量的映射和規則的執行。完成后，單域的數據質量和清潔度都得到提升，然后基于數據標準約束信息系統的改造。從分析側來說，前端數據整合規則的高質量定義可以極大的減輕定位數據、ETL 清洗、ODS 層到明細層的設計工作。

最后一步是數據的共享分發和數據分析場景的建設。共享分發可以是基于原生的業務形態、業務系統數據的分發，也可以是指標、報表、標簽的分發。

第二部分，外部賦能。

首先搭建數據治理體系框架。第一步建立組織，比如先找到資產管理員、數據平臺管理員、業務分析師這樣三個角色，就可以啟動一些核心的活動，把相關的制度模板，如數據共享、數據權屬設計、增量數據的標準約束和審批流程等體系框架搭建起來。

數據治理體系框架搭建后，進行數據資產的盤點，完全域數據資產盤點是迭代更新的過程。數據資產是為了反映業務的數字映像，因為業務會發生變化，所以需要沉淀能力形成一套方法和模板。后面每隔一定時間迭代一次，根據業務環節產生的業務變化刷新資產目錄。

有了體系框架、數據架構和方法賦能，就可以開展重點專題的治理，比如從 L3 業務對象（概念實體）的識別，到邏輯側及物理側的映射，最后在價值呈現上做指標算法、數據共享機制構建（需要數據管理平臺和數據應用平臺支撐）。

5、業務數據治理工作的起點-數據資產盤點

數據治理工作的核心抓手是數據資產，所有的標準、質量、安全都是構建在數據資產上面的。

以某制造業數據資產盤點為例，它的生產過程，從新產品導入、生產計劃、制造過程，工藝管理、物流倉儲交付到產品退貨，構成了生產域。通過生產運營的業務活動識別出關鍵的信息對象，稱為業務對象。

L1 可以復制企業的自然職能領域，如果企業的流程 IT 部門有業務架構或者是流程架構，可以直接參考其結構，便于業務人員的感知；L2 基于每個業務過程識別出來對象進行偏向于數據本身的聚合，既考慮業務可識別性，又考慮數據本身的聚合性。

在梳理資產目錄過程中，根據對象和業務的關系可以比較粗顆粒的畫出對象之間的關系，稱為概念模型，它僅有 1：1、N：N、 1：N 的三種關系，不承載實體和屬性?；诟拍钅Ｐ?，我們可以衍生出細分領域的邏輯模型和物理模型設計。

存量信息系統中，有了數據資產目錄和數據之間的關系后，還需要統計數據在信息系統之間的分布以及數據在整個業務域的流向圖。

數據資產盤點是整個數據工作的核心抓手和起點。

6、針對重點領域-分階段開展數據資產深化定義

數據資產目錄到 L3 層是業務分類結構，如上圖從銷售、零售管理到客戶，是業務人員一看就明晰的結構。

但 L3 層是一個偏概念性的東西，需要填充更多的屬性形成邏輯實體。也就是將概念實體切割成邏輯實體和邏輯屬性。

再往下就是物理表的映射。邏輯實體和存量的物理表的區別在于，邏輯實體在業務側承載更多的業務細節，但是系統表的數據結構設計還有性能上的考慮，數據庫的性能、讀寫的性能、以及冗余字段。

7、基于數據資產目錄的數據認責

不論是數據平臺還是數據資產的目錄結構，都會關心數據資產認責，數據的所有者是誰，數據的變更需要找誰，需要進行相應角色的定義，比如業務數據的定義責任人，系統管理責任人，數據錄入責任人，并形成類似這樣一個矩陣表。

責任人的認定，在業務數據，到屬性級別是比較理想的顆粒度。但是屬性級別設置責任人可能設置工作比較繁重，所以實際在開展的時候，一般會在 L3 層設置它的管理權責。如果短時間內涉及到一些比較復雜、跨領域的數據，或者權責難以厘清的數據，我們可以再往上推到 L2 層去定義，后續看情況再細化。

8、數據治理的落地平臺支撐

以上是數據治理的開展路徑以及核心的數據資產工作部分。數據資產目錄設計、數據模型、數據標準，這些數據管理動作需要有一個 IT 平臺去落地，滴普提供一站式的數據智能服務的平臺，包括從數據集成到數據治理（數據標準、數據質量、數據安全等），數據資源的開放和共享。

二、數據治理實踐

下面是一些案例的介紹。

1、某食品加工企業報表應用驅動的數據治理咨詢交付路徑

客戶的 CIO 本身有多年頭部咨詢公司的 IT 咨詢規劃經歷，對企業信息化及數據管理有比較深的理解，為了兼顧企業長期的數據治理能力構建及中短期的業務價值體驗，所以這個項目就分成了兩個部分。

（1）數據治理體系設計。包括現狀診斷及體制機制設計，以及前面講到的數據目錄構建、標準設計，屬于業務數據治理。

（2）指標體系的設計。指標體系對比較核心的管理部門，做全量指標體系的盤點和結構化、標準化的設計。針對某一個比較強勢有價值承接的業務板塊，做指標的定義和拆解，在物理表上做面向大屏的主題專題庫的設計。

這里可以理解為兩塊，一塊用來在業務側呈現價值，另一塊是通過數據定義和設計去支撐指標的高質量實現。這樣既實現了業務部門可感知的價值，又實現了 IT 部門基于長遠考慮的夯實數據治理基礎目的。

2、某制造企業數據治理的起點-數據盤點 & 治理體系設計

該制造企業是一個整車制造商，這些年做了很多數據治理的項目，這個體系設計&數據盤點項目是他們整個體系的起點。

在項目之前，客戶做過主數據項目一期，但是他們比較關心的客戶主數據，主數據下面是有數據標準、數據模型，包括全鏈路的數據關系。兩三年后，企業的系統變了，業務也發生一些變化，以前做的主數據就有了很大的偏差。需要一套數據治理體系進行持續數據治理運營，所以就啟動了這個數據規范化的項目。

客戶在這個項目做兩件事，一個是數據治理標準化體系構建，包括標準設計、模型構建、數據質量管理、流程和組織設計等。還有一個是數據目錄設計，做全公司范圍的數據資產盤點到 L3 級的業務對象，作為后續數據治理持續開展的路徑和索引。

還有一塊比較核心內容，不屬于數據治理范疇。因為這家企業是沒有流程 IT 部門的，IT 負責人之前對業務全貌和整體流向一直不是很清楚。我們幫助企業基于對現有業務的理解做了一個業務全景圖。但是這個項目到最后，CIO 非常關心這個業務全景圖，以此看到從業務全景圖到數據的映射，也可以指導每年的 IT 規劃。

三、問答環節

Q1：主數據在數據治理的方法，或者是數據標準的價值？

A1：為什么有主數據？因為有些企業的業務鏈路特別長，特別像制造業的產品主數據，客戶主數據。10 年前，大部分企業做數據治理就是做主數據治理，進行跨業務域跨系統的數據的整合和取用，形成對主數據的單一真實映象并進行分發。

現在的數據平臺在慢慢地弱化主數據的概念，因為數據平臺里面內置的功能和方法，可以支撐主數據需要的核心能力。主數據是跨業務域、跨系統的數據的整合分發，現在企業數據管理的范圍已經不僅僅局限于主數據了（也包括很多重要的交易數據），越來越偏向更廣泛的數據治理，不需要特別去考慮主數據專項的方法論，滴普前面講到的一些方法，其實就可以覆蓋原有主數據的核心過程。

數據標準最大的作用就是幫助系統里面的數據更真實地反映業務。數據標準來源于業務人員、IT 人員達成的一致性對數據的理解，并約束增量的業務。讓企業的數據源頭慢慢地往越來越貼合真實業務的方向走，就是數據標準最大的價值。

Q2：從不同業務系統做完數據治理后，要再形成一個新的數據庫嗎？或者是要做一層知識圖譜的結構？

A2：做完數據治理工作短時間內很難得到一個全新的數據庫，短時間內它可能就是一個標準。從制定標準到約束源頭的數據庫去改造，需要一個漸進的過程。當然未來方向上，還是需要重新形成一層選定的數據層，承載治理后的清潔數據。但是最終，如果源頭業務系統已經按照數據標準逐漸地替換（通過系統的功能演進或生命周期更換掉），已經比如過四五年以后全部都符合數據標準了，也就完成了數據治理。

Q3：數據標準制定后在原業務系統無法落地怎么辦？

A3：不能用短期的時效性去看數據標準落地，一定要看長期性的效果。數據標準解決的是兩件事情。對于存量的，特別是很多生產制造企業，業務系統對于生產過程非常重要，建議還是采取映射的結構，幫助企業更清晰地獲取現有的數據結構，不能一下子要求業務系統按標準馬上去改造。對于增量的數據結構，并通過數據平臺的校核功能，在業務系統功能變更或新增的時候進行數據表的比對，哪幾條不符合必須按標準改造。存量的不建議強行去改造（除非有高層的強力支持），會受到業務的極大反彈。

Q4：數據治理工作的價值或者 KPI 怎么量化？

A4：一種是通過企業的數字化或信息化場景切入，比如企業正在做業財一體化的項目、在做大型軟件包的更替，要和周邊的數據做交互。那么數據治理的價值就是幫助軟件包更好地和周邊數據的交互，或者獲取更清晰的其他周邊系統的數據結構。這是一種支撐大型軟件包的落地效果的價值。

還有一種是大部分企業在做的中臺可視化涉及的指標、標簽算法。比如財務部門以前出分析結果很慢，幫它做準做快，這就是價值的體現。

再有一種，如果數據治理后期，資產形成相關的服務以后，可以通過資產服務的調用，包括復用性、資產價值本身的評估，通過前端的調用性和對業務應用的貢獻去計算價值。