關於主資料的實踐和思考

主資料方法論的文章網上很多了，今天跟大家聊一聊我在實施主資料專案中碰到的六個問題，如下所示，然後給出我的初步思考和建議。

• 主資料的業務驅動在哪裡?

• 誰應該來負責主資料建設?

• 主資料專案團隊應該如何構成?

• 主資料專案的工作機制如何?

• 如何推進主資料業務流程的梳理?

• 主資料架構如何選擇?

1、主資料的業務驅動在哪裡?

主資料是指公司的核心業務物件資料，對於公司的大多數主資料，雖然可能存在不一致，但大多時候問題並不嚴重，因為如果不一致問題已經嚴重影響到了生產，業務肯定是要強力介入並進行解決的，比如立個項，主資料的大多數問題在業務從0到1的建設過程中就已經基本解決了。

因此，資料治理要解決的主資料問題，大多是業務當前還能容忍，但長遠來講成本可能很高的問題，也就是重要而不緊急的事情，考慮到各個部門屁股決定腦袋的特點，主資料存在著天然的驅動力不足的問題。

相對來說，IT部門是有解決主資料問題的動力的，作為業務的支撐部門，IT部門有責任為了確保資料一致性臨時做大量的補償工作，讓很多主資料問題看起來不那麼嚴重，業務部門有時候能夠容忍，不是說能容忍不一致，而是能容忍不從根子上解決問題，但IT部門一般沒有能力去徹底解決問題。

那麼誰最會考慮這種重要而不緊急的事情呢，誰又會考慮這種全域性和區域性的問題呢，顯然是公司的管理者。因此，主資料的業務驅動一定首先來自公司管理者，只要管理層不覺得痛，跨領域的長期積累的主資料問題就很難實質性解決。

那麼什麼情況下公司管理者會覺得痛呢?

大多是公司管理者在處理跨領域事情的過程中感覺到的，比如發現業務和財務口徑不一致，前端和後端資料不一致等等，這些不一致必須對公司決策和生產經營產生了實際的影響，這個影響持續存在且在不停刺激著管理者的神經，比如每個月都來一次，這個時候公司管理者才會真正重視，想著如何去解決問題，畢竟跨領域協調對他來講也是件成本很高的事情。

《華為資料之道》提到過其做資料治理的起因，就是因為發現財務資料不一致已經影響到了管理層的決策判斷，華為CFO後來還成為了企業的資料責任人，因為CFO是感覺到最痛的人。

當然如果主資料問題已經嚴重影響到了某個部門的業務擴充，部門也會跳出來主動解決主資料的問題，但其獲得的支援是有限的，一方面只是他自己感覺到了痛，另一方面在落地執行的時候，部門會天然傾向只解決自己的問題，甚至跟其他部門有衝突。

別人來跟我講主資料的經驗，我一般都會問參加過幾次管理層的會議，主資料的工作保障機制如何，比如聯席會的頻次是多少，以此來評估靠譜程度，我不知道還有什麼其他更好的辦法來解決驅動力的問題。

2、誰應該來負責主資料建設?

業界一般有三種組織模式，第一種是由主資料利益最相關的業務部門主導建設，第二種是企業級資料管理組織主導建設，第三種是IT部門主導建設，正好我三種模式都碰到過。

第一種模式是以本部門的利益為核心來推動的，雖然已經獲得了公司名義上的支援，但很難平衡好全域性利益，跨部門協調難度很大，甚至會受到很大的阻力，一般很難徹底解決問題，至少週期會非常長。

第二種模式是比較推薦的模式，即透過企業級資料管理組織來牽頭建設，由於相對中立，因此更有可能把控好全域性利益，跨部門協調難度相對較小，但一般企業很難有這個條件和意識去建立這種企業級的資料治理組織，即使勉強建立了也缺乏專業人才的保障，比如對於業務和IT理解非常有限，因此存在眼高手低的問題。

第三種模式是IT部門主導，但這也是無奈之舉，也是最不推薦的，一般只能做一些主資料的修補工作，除了繼承第一種模式的弊端外，還面臨業務驅動不夠，只能解決區域性問題的挑戰，現在很多IT部門強調往業務多走一步，情況會好很多。

針對第二種模式，可以做適當的改良，即企業級資料管理組織不要搞所謂的虛擬組織或者東拼西湊成了雜牌軍，而是在IT部門的資料管理團隊上升級而成，然後補充重點業務領域的人才，當然還是會碰到主資料專業人才缺乏，專業領域業務理解不夠等問題，但至少是相對理想的模式，比如華為就建立了企業資料管理部這種實體的組織。

3、主資料專案團隊應該如何構成?

一般會設定公司領導小組，組長由管理層擔任，副組長由各部門的資料責任人擔任，領導小組負責主資料專案總體工作推進，制定總體工作思路和目標，協調各部門間專案推進過程中遇到的問題，確保專案的順利執行。

領導小組一般會下設工作小組，工作小組組長一般由企業資料管理組織的相關負責人擔任，成員包括企業資料管理組織人員及各領域的資料專員，負責主資料專案的具體實施，開展相關能力建設和運營。

根據自己的經驗，一般會設定幾個專業組協同推進，以下是一個示例供你參考：

• 業務需求組：負責主資料相關業務流程梳理和業務管理規範的制定，明確主資料需求

• 系統架構組：負責主資料系統整體架構的設計，確保架構合理、滿足各域生產應用需要

• 平臺建設組：負責推進主資料系統建設工作，實現主資料庫、對外資料服務、資料稽核等關鍵能力

• 資料架構組：負責推進各領域系統現有主資料的整合，形成一份統一的公司標準主資料

• 各領域改造組：負責本領域系統的改造工作，確保與主資料系統的順利對接

4、主資料專案的工作機制如何?

主資料專案很怕雷聲大雨點小，別看大家面上喊得很兇，但一旦要落實到具體工作上，誰都不太願意接這燙手的山芋，因為不確定性很強。

主資料涉及很多部門的利益，需要能給出權衡利弊的方案，把事情放到檯面上來擺事實、講道理說清楚，所謂的全域性利益最大化很難一句話講清楚，這個就需要有相應的工作機制保障，否則可落地性存疑，以下是一些做法：

• 定期的管理層進度彙報

• 管理層專題彙報，包括業務問題分析、可行性分析、業務流程分析、主資料規範制定、建設方案、資料模型方案等等，以上所有都需要跨部門協作，分析和材料的壓力會比較大

• 資料責任人和領域責任人溝通機制，從決策到執行有很多理解不一致的地方，需要在推進中協商解決，不可能每個問題都升級到管理層

• 專案例會，IT的進度控制手段

• 週報通報，輕量化的工作督促

5、如何推進主資料業務流程的梳理?

主資料變動涉及多個部門，牽一髮動全身，對於業務的影響是很大的，當真正要建立一個主資料系統的時候，必須清楚的知道主資料的變更(新增，讀取，刪除等)會影響哪些業務流程和角色，這些業務流程承載在哪些系統上，這些系統的哪些資料會受到影響，這些系統的上下游哪些系統和資料介面也會受到連帶影響，這樣才能大致確定主資料變更的業務影響範圍。

當然確定業務影響範圍還是遠遠不夠的，還需要在業務流程梳理清楚的基礎上，分析清楚哪些業務流程的哪些環節需要進行變更，比如基於主資料的要求進行資料錄入的規範，這樣才能明確具體的系統改造需求。

要進行業務流程的梳理需要各部門的積極配合，但每個業務部門對業務流程進行梳理也是存在挑戰的，一方面沒有專門管流程的人，另一方也不知道梳理的方法，這些都是需要主資料專案團隊協調資源去攻堅解決的，華為有獨立的流程和質量管理部這種組織來保障流程，但大多數企業沒有這麼理想化的組織，必須臨時搭班子推進，因此能做主資料的組織還需要是個學習型的組織，能夠快速學習新的東西，因為不可能每個事情都能馬上找到外部資源。

業務流程梳理完後，我們至少需要得到下面一張彙總表格，如圖一所示，然後裡面的每個流程都要有詳細的說明，如圖二所示：

6、主資料架構如何選擇?

主資料架構有兩種主要型別，一種是強管控，即中央集權型，主資料的編碼、更新、分發等所有流程全部強管控，這樣主資料系統的話語權最大，業務價值最大，具備長久的生命力，但是這種方式涉及面非常廣，侵入生產系統，實施難度最高，我們採用的就是這種，如下圖所示：

國內很多企業的主資料工作落在OLAP團隊，由OLAP團隊來實施這種強管控的主資料架構挑戰會比較大，因為這類主資料系統本質上是OLTP系統或者是橫跨OLAP和OLTP的，對於一致性、實時性、可用性和連續性要求非常高，這些卻不是傳統OLAP團隊所擅長的，但資料治理只有從源頭抓起才能徹底解決問題，因此也是機遇和挑戰並存。

主資料架構還有弱管控的型別，即用資訊分發型的建設方式，這樣入侵性比較小，我只管釋出命令就行了，其他的你們看著辦，如下圖所示：

這種方案我其實不太推薦，因為即使開始的時候資料一致效能勉強保證，但可持續性很差，還不如平時打打補丁，做個轉換器來得靈活。

現在很多企業由於有集團和子公司的二級組織架構，集團在集中化過程中需要先做一個主資料系統，但一開始又不可能一捅到底，因此採取了這種折中的方案，但我覺得這種主資料只是集團層面的主資料系統，子公司很難享受到多少主資料的福利，究其根本，還是由於組織架構割裂造成的，畢竟集團和子公司是兩個法人實體，除非系統全部集中化建設。

可以看到，最終其實還是組織架構決定系統架構，組織的存在形式就限制了你主資料能達到的高度，這也是沒有辦法的事情，因此企業資料治理一定要優先解決組織的問題。

由於主資料專案還沒完成，因此我們也是走一步看一步，臨時寫下這點感想，但隨著工作的推進，相信會越來越清晰。