經過多年的數據治理實踐，業界已經充分認識到，僅僅依靠技術部門來推動和開展數據治理工作是無法取得成果的，原因在于數據治理涉及企業各部門的業務和資源，只有來自更高層管理者的驅動力，建立自上而下的跨部門跨條線的組織體系，才能保證企業內部的高效協作。

下圖是一張通用的企業數據治理組織框架，大多現實中的企業數據治理組織都可以與其映射，我看了華為數據之道的組織，也看了很多央企的，都不出其右，如果你的企業需要建立企業數據治理組織，可以參考這張圖，然后結合實際進行裁剪。

如上圖所示，很多公司也建立了企業級的數據歸口管理部門，理論上，這個歸口管理部門是不干“實事”的，主要負責制度、流程、規范、標準、考核等工作，其一般職責包括：

（1）貫徹落實決策層各項決策部署，行使日常數據治理工作管理職責。

（2）負責基于戰略制定數據治理規劃，并報決策層批準、發布。

（3）負責制定數據治理年度投資計劃和工作計劃。

（4）負責制定、修訂和發布數據治理相關管理辦法、實施細則和業務指導書，構建公司數據治理制度體系。

（5）負責制定數據標準并進行監督，規劃、構建和管控企業的數據架構，識別并建立主數據應用管理機制，制定數據質量管理要求并進行問題指導和協調。

（6）負責組織制定數據安全基礎策略，構建企業級數據安全管控體系，配合監督和審計。

（7）負責受理跨部門、跨機構或重要的數據需求，組織開展數據需求的評審、實施和成果交付工作。

實踐證明，完全不干“實事”的數據管理部門生存空間比較小，危機感挺強，除非有一把手的鼎力支持，大致有三個原因：

第一、數據治理本質上是為了保障數據管理活動的順利進行，理論上不直接產生業務價值，這讓數據治理團隊有顯性化成績的壓力

第一、數據治理在大多企業里算是新鮮事物，大家對其價值的認可需要時間，光是理解數據治理這個概念就挺費解

第三、數據治理團隊建的章立的制落地挑戰很大，因為制度規范的執行需要流程的保障，但要改變流程又是何其艱難，容易形成“兩張皮”現象

很自然的，這些被賦予使命的企業級數據管理組織除了干建章立制的工作，也希望增加數據管理活動的職能，比如搭平臺，匯數據，做模型，搞服務，甚至還希望做些數據應用創新，這個時候，如果沒有找準自己的定位，就容易跟領域級的數據管理組織產生職責上的沖突，也就是“與民爭利”。

關于這一點，我們可以從華為公司數據管理部的發展困境看到些端倪：

華為數據管理組織體系由兩層構成：企業級的公司數據管理部，以及各個功能部門下的領域數據管理部，公司數據管理部代表公司制定數據管理相關的政策、流程、方法和支撐系統，制定公司數據管理的戰略規劃和年度計劃并監控落實。建立并維護企業信息架構，監控數據質量，披露重大數據問題，建立專業任職資格管理體系，提升企業數據管理能力，推動企業數據文化的建立和傳播。

公司數據管理部掛在公司流程IT部門之下，在過去十幾年中，先后歸屬不同的二級部門，包括IT架構與規劃部、信息技術部、企業架構部等。從中可以看出，數據管理部跟周邊如何有效協同的問題，一直沒有找到最佳答案。

數據管理部要擴大數據工作的“勢力范圍”，有兩個方向。一方面是向業務延申，另一方面就是向IT延申，許多領域數據管理部之所以能夠存活下來，被迫向非數據管理專業工作延申，例如管管部門KPI等，但公司數據管理部這條出路行不通，即使是指標本身也有業務行管部門負責，沒有機會介入。

那么向IT部門延伸如何呢？華為數據管理部門成立以來，跟IT部門之間的分工與協作也一直并不順暢。數據看不上IT部門的”臟活累活“，IT部門看不上數據人員的能力。

空降的企業數據管理組織如果只做建章立制的工作，容易脫離業務，而一個脫離業務很久的組織，其建的章立的制能否接地氣存疑。因此，企業級數據管理組織的職能最佳構成形式應是虛實結合的，要有機會負責具體的數據管理活動，企業數據治理組織人才的培養也需要實踐的土壤。

那么，企業級數據管理組織的實體職能跟領域級數據管理組織的實體職能邊界能夠區分清晰嗎？

理論上我們可以說，讓企業級數據管理組織去干企業級的數據管理工作，領域級數據管理組織去干領域級的數據管理工作，但這個領域級和企業級的區別到底在哪里呢？

有人馬上會想到，數據中臺總應該歸屬企業級數據管理組織負責建設吧，但如果數據中臺僅指狹義的數據模型能力，那么這句話并不完全正確，因為領域級數據管理組織也可以作為數據中臺模型的建設一份子，數據中臺并不是企業級數據管理組織的專屬物，甚至可以這么說，領域級數據管理組織甚至比企業級數據管理組織更適合建設數據中臺，因為它們更貼近業務，只是共享模型的驅動力少了點而已。

而企業級數據管理組織的優勢應該是建立模型的運營規范，然后讓各領域的數據管理組織參與到這個生態中。

那么，到底哪些實體的數據管理職能應該放在企業級數據管理團隊呢？

這個問題困擾了我很久，然后華為數據管理部發展的一段歷程提醒了我。

“2011年左右，華為數據管理部提出”抓兩頭，推中間“的工作策略。“兩頭”包括主數據和數據倉庫，“中間”指業務交易系統。主數據影響范圍廣，一旦出問題，各個業務交易系統的數據質量都受影響。而且，主數據管理需要推動協調各個業務部門配合，在IT方面的”技術含量“并不高，IT部門巴不得有人接走。

數據倉庫直接支持公司各類分析報告，管理層更容易感知到數據質量的好壞。并且數據倉庫是一個輕功能重數據的IT系統，稱之為”數據密集型“系統。當時，華為數據管理部已經按照這個思路開始工作布局，同時2011年開始參與公司EDW的重構工作。”

雖然華為數據管理部因為一些意外的變故，沒有實現以上的夙愿，但他們這個”抓兩頭，推中間“的工作策略還是很有啟發意義的。

關于企業級數據管理團隊的實體職能，我覺得需要遵循三個原則，即集約原則、互補原則及孵化原則。

原則1：集約原則

就是企業級數據管理團隊統一做這個事情的價值已經超過了各領域數據管理團隊分頭做的價值（含靈活性），這個跟企業當前的數據管理發展階段有關，如果企業剛剛開始搞大數據，那么這個集約化原則估計就不太適用

原則2：互補原則

就是企業級數據管理團隊不是去跟領域數據管理團隊搶活干的，而是去做對整個企業有全局價值但領域數據管理團隊不太愿意干或者干不動的事情，因為領域一般是屁股決定腦袋的，只會圍繞著自己領域KPI轉，只會做對領域性價比高的事情，這是由它的生態位決定的，沒法改變

原則3：孵化原則

很多企業的一些領域數據管理能力很弱，甚至沒有，這個時候企業級數據管理組織可以暫時承擔起這些領域的實體數據管理職責，但還是要清楚，只有領域自己的數據管理組織起來了才是最優的解決方案，因此企業數據管理團隊要全力幫助領域數據管理組織的成長，最后如果能移交領域數據管理的職能，就算成功了

基于這三個原則，容易推測出企業級數據管理組織最適合做的五項數據管理工作：

1、打造統一的數據治理平臺，無論是元數據管理平臺、主數據管理平臺、數據標準管理平臺或者開發管理平臺等等，集約化的可能性都比較大，企業數據管理團隊的本職工作是數據治理，工欲善其事，必先利其器，如果連自己的數據治理平臺都無法集約化，那有點說不過去

2、打造統一的數據底座，也就是數據倉庫或數據湖（不含中臺模型），通過提供數據湖底層平臺、制定入湖的統一標準及實現企業各域數據的統一標準匯聚，可以最大化發揮集約的價值

3、所有涉及跨領域的數據、模型等構建工作，如果這些工作的跨領域屬性特別大，任何一個相關領域的數據管理者都已經無法有效支持企業級應用要求的時候，那么企業級數據管理組織應該去補位。

主數據就是特別好的一個例子，因為主數據一般橫跨多個領域，但各個領域其實都不太愿意去干又臟又累的主數據，比如人員主數據，這個時候企業數據管理組織需要去補位，特別是當數據的一致性已經積重難返的時候。雖然主數據可能歸屬于某個特定領域管理，但并不意味著這個領域有能力、有意愿去解決其他領域在應用主數據時碰到的問題

4、很多數據模型或數據技術研發通用性較強，但對于企業資源的消耗特別大，當這些模型和技術的業務屬性不是特別大的時候，讓企業級數據管理組織去承擔研發任務是可以的，這遵循了補位的原則

5、如果企業某個領域需要從無到有建設自身的數據管理組織，企業級數據管理團隊應該先頂上去，利用其沉淀的數據管理經驗為該領域提供支撐，這樣可以讓該領域盡快享受到企業已經達到的數據支撐水平，而不是從0到1，企業數據管理團隊也有責任、有義務為領域提供數據管理培訓服務，直到該領域能夠獨當一面，這遵循了孵化原則

企業級數據管理團隊的構建對任何企業都是一種挑戰，但這種組織很容易走向兩個極端，一種是團隊成員都是空降而來，職責是純管理型的，不那么接地氣，另一種是團隊由實體組織升級而來，虛實的職責都有，但職責定義不清，甚至與領域發生沖突，產生“與民爭利”的現象。