主數據的業務驅動在哪里？ 誰應該來負責主數據建設？ 主數據項目團隊應該如何構成？ 主數據項目的工作機制如何？ 如何推進主數據業務流程的梳理？ 主數據架構如何選擇？?

1、主數據的業務驅動在哪里？
主數據是指公司的核心業務對象數據，對于公司的大多數主數據，雖然可能存在不一致，但大多時候問題并不嚴重，因為如果不一致問題已經嚴重影響到了生產，業務肯定是要強力介入并進行解決的，比如立個項，主數據的大多數問題在業務從0到1的建設過程中就已經基本解決了。因此，數據治理要解決的主數據問題，大多是業務當前還能容忍，但長遠來講成本可能很高的問題，也就是重要而不緊急的事情，考慮到各個部門屁股決定腦袋的特點，主數據存在著天然的驅動力不足的問題。相對來說，IT部門是有解決主數據問題的動力的，作為業務的支撐部門，IT部門有責任為了確保數據一致性臨時做大量的補償工作，讓很多主數據問題看起來不那么嚴重，業務部門有時候能夠容忍，不是說能容忍不一致，而是能容忍不從根子上解決問題，但IT部門一般沒有能力去徹底解決問題。那么誰最會考慮這種重要而不緊急的事情呢，誰又會考慮這種全局和局部的問題呢，顯然是公司的管理者。因此，主數據的業務驅動一定首先來自公司管理者，只要管理層不覺得痛，跨領域的長期積累的主數據問題就很難實質性解決。
那么什么情況下公司管理者會覺得痛呢？
大多是公司管理者在處理跨領域事情的過程中感覺到的，比如發現業務和財務口徑不一致，前端和后端數據不一致等等，這些不一致必須對公司決策和生產經營產生了實際的影響，這個影響持續存在且在不停刺激著管理者的神經，比如每個月都來一次，這個時候公司管理者才會真正重視，想著如何去解決問題，畢竟跨領域協調對他來講也是件成本很高的事情?！度A為數據之道》提到過其做數據治理的起因，就是因為發現財務數據不一致已經影響到了管理層的決策判斷，華為CFO后來還成為了企業的數據責任人，因為CFO是感覺到最痛的人。當然如果主數據問題已經嚴重影響到了某個部門的業務拓展，部門也會跳出來主動解決主數據的問題，但其獲得的支持是有限的，一方面只是他自己感覺到了痛，另一方面在落地執行的時候，部門會天然傾向只解決自己的問題，甚至跟其他部門有沖突。別人來跟我講主數據的經驗，我一般都會問參加過幾次管理層的會議，主數據的工作保障機制如何，比如聯席會的頻次是多少，以此來評估靠譜程度，我不知道還有什么其他更好的辦法來解決驅動力的問題。
2、誰應該來負責主數據建設？
業界一般有三種組織模式，第一種是由主數據利益最相關的業務部門主導建設，第二種是企業級數據管理組織主導建設，第三種是IT部門主導建設，正好我三種模式都碰到過。第一種模式是以本部門的利益為核心來推動的，雖然已經獲得了公司名義上的支持，但很難平衡好全局利益，跨部門協調難度很大，甚至會受到很大的阻力，一般很難徹底解決問題，至少周期會非常長。第二種模式是比較推薦的模式，即通過企業級數據管理組織來牽頭建設，由于相對中立，因此更有可能把控好全局利益，跨部門協調難度相對較小，但一般企業很難有這個條件和意識去建立這種企業級的數據治理組織，即使勉強建立了也缺乏專業人才的保障，比如對于業務和IT理解非常有限，因此存在眼高手低的問題。第三種模式是IT部門主導，但這也是無奈之舉，也是最不推薦的，一般只能做一些主數據的修補工作，除了繼承第一種模式的弊端外，還面臨業務驅動不夠，只能解決局部問題的挑戰，現在很多IT部門強調往業務多走一步，情況會好很多。針對第二種模式，可以做適當的改良，即企業級數據管理組織不要搞所謂的虛擬組織或者東拼西湊成了雜牌軍，而是在IT部門的數據管理團隊上升級而成，然后補充重點業務領域的人才，當然還是會碰到主數據專業人才缺乏，專業領域業務理解不夠等問題，但至少是相對理想的模式，比如華為就建立了企業數據管理部這種實體的組織。
3、主數據項目團隊應該如何構成？
一般會設置公司領導小組，組長由管理層擔任，副組長由各部門的數據責任人擔任，領導小組負責主數據項目總體工作推進，制定總體工作思路和目標，協調各部門間項目推進過程中遇到的問題，確保項目的順利執行。領導小組一般會下設工作小組，工作小組組長一般由企業數據管理組織的相關負責人擔任，成員包括企業數據管理組織人員及各領域的數據專員，負責主數據項目的具體實施，開展相關能力建設和運營。根據自己的經驗，一般會設置幾個專業組協同推進，以下是一個示例供你參考：
業務需求組：負責主數據相關業務流程梳理和業務管理規范的制定，明確主數據需求
系統架構組：負責主數據系統整體架構的設計，確保架構合理、滿足各域生產應用需要
平臺建設組：負責推進主數據系統建設工作，實現主數據庫、對外數據服務、數據稽核等關鍵能力
數據架構組：負責推進各領域系統現有主數據的整合，形成一份統一的公司標準主數據
各領域改造組：負責本領域系統的改造工作，確保與主數據系統的順利對接
4、主數據項目的工作機制如何？
主數據項目很怕雷聲大雨點小，別看大家面上喊得很兇，但一旦要落實到具體工作上，誰都不太愿意接這燙手的山芋，因為不確定性很強。主數據涉及很多部門的利益，需要能給出權衡利弊的方案，把事情放到臺面上來擺事實、講道理說清楚，所謂的全局利益最大化很難一句話講清楚，這個就需要有相應的工作機制保障，否則可落地性存疑，以下是一些做法： 定期的管理層進度匯報 管理層專題匯報，包括業務問題分析、可行性分析、業務流程分析、主數據規范制定、建設方案、數據模型方案等等，以上所有都需要跨部門協作，分析和材料的壓力會比較大 數據責任人和領域責任人溝通機制，從決策到執行有很多理解不一致的地方，需要在推進中協商解決，不可能每個問題都升級到管理層 項目例會，IT的進度控制手段 周報通報，輕量化的工作督促
5、如何推進主數據業務流程的梳理？
主數據變動涉及多個部門，牽一發動全身，對于業務的影響是很大的，當真正要建立一個主數據系統的時候，必須清楚的知道主數據的變更（新增，讀取，刪除等）會影響哪些業務流程和角色，這些業務流程承載在哪些系統上，這些系統的哪些數據會受到影響，這些系統的上下游哪些系統和數據接口也會受到連帶影響，這樣才能大致確定主數據變更的業務影響范圍。當然確定業務影響范圍還是遠遠不夠的，還需要在業務流程梳理清楚的基礎上，分析清楚哪些業務流程的哪些環節需要進行變更，比如基于主數據的要求進行數據錄入的規范，這樣才能明確具體的系統改造需求。要進行業務流程的梳理需要各部門的積極配合，但每個業務部門對業務流程進行梳理也是存在挑戰的，一方面沒有專門管流程的人，另一方也不知道梳理的方法，這些都是需要主數據項目團隊協調資源去攻堅解決的，華為有獨立的流程和質量管理部這種組織來保障流程，但大多數企業沒有這么理想化的組織，必須臨時搭班子推進，因此能做主數據的組織還需要是個學習型的組織，能夠快速學習新的東西，因為不可能每個事情都能馬上找到外部資源。業務流程梳理完后，我們至少需要得到下面一張匯總表格，如圖一所示，然后里面的每個流程都要有詳細的說明，如圖二所示：

6、主數據架構如何選擇？主數據架構有兩種主要類型，一種是強管控，即中央集權型，主數據的編碼、更新、分發等所有流程全部強管控，這樣主數據系統的話語權最大，業務價值最大，具備長久的生命力，但是這種方式涉及面非常廣，侵入生產系統，實施難度最高，我們采用的就是這種，如下圖所示：
國內很多企業的主數據工作落在OLAP團隊，由OLAP團隊來實施這種強管控的主數據架構挑戰會比較大，因為這類主數據系統本質上是OLTP系統或者是橫跨OLAP和OLTP的，對于一致性、實時性、可用性和連續性要求非常高，這些卻不是傳統OLAP團隊所擅長的，但數據治理只有從源頭抓起才能徹底解決問題，因此也是機遇和挑戰并存。主數據架構還有弱管控的類型，即用信息分發型的建設方式，這樣入侵性比較小，我只管發布命令就行了，其他的你們看著辦，如下圖所示：
這種方案我其實不太推薦，因為即使開始的時候數據一致性能勉強保證，但可持續性很差，還不如平時打打補丁，做個轉換器來得靈活。現在很多企業由于有集團和子公司的二級組織架構，集團在集中化過程中需要先做一個主數據系統，但一開始又不可能一捅到底，因此采取了這種折中的方案，但我覺得這種主數據只是集團層面的主數據系統，子公司很難享受到多少主數據的福利，究其根本，還是由于組織架構割裂造成的，畢竟集團和子公司是兩個法人實體，除非系統全部集中化建設。可以看到，最終其實還是組織架構決定系統架構，組織的存在形式就限制了你主數據能達到的高度，這也是沒有辦法的事情，因此企業數據治理一定要優先解決組織的問題。由于主數據項目還沒完成，因此我們也是走一步看一步，臨時寫下這點感想，但隨著工作的推進，相信會越來越清晰。
?