近些年自己一直負責數據變現、數據治理的相關工作，對于組織的力量有了一定的認識，最近一段時間正好在做數據團隊架構優化的事情，突然想到當初的失敗可能跟能力無關，而跟當時的分工有關，因為無論是數據挖掘、指標標準化都是非常專業的工作，讓半路出家的報表取數團隊兼職去做，不僅缺乏資源，而且存在自相矛盾的地方。康威定律說得好：“設計系統的架構受制于產生這些設計的組織的溝通結構。”通俗的講：產品必然是其（人員）組織溝通結構的縮影，凸顯組織架構的重要性，大到公司，小到數據團隊。最近幾年隨著數字化的興起，數據團隊融入了更多的職責，不僅包括了傳統的報表、取數及數據挖掘，還包括數字化支撐、數據中臺還有數據治理等等，我不僅需要去解決數據團隊分工的歷史問題，還要做好新老職責的融合，挑戰還是很大的，突出表現在以下三個方面：

1、數據治理職責和數據管理職責的沖突一般數據團隊做的工作無非就是數據采集、處理、建模、開放、應用和變現，外加數據質量管理，元數據管理等保障型工作，我們可以把這些活動統稱為數據資產管理活動。但數據治理與其性質完全不同，數據治理即對數據資產管理行使權力、控制和共享決策（規劃、監測和執行）的系列活動，涉及到頂層設計、組織優化、建章立制或者監督控制等等，數據治理相當于將監督和執行的職責分離了，一個常見的類比是將數據治理等同于審計，數據治理制定管理數據資產的規則，數據資產管理活動則執行這些規則。但我們還是擅長于去做一些生產型的數據工作，因為一直是這么過來的，真要搞數據治理，還是覺得如履薄冰，即使已經干了2年。我們會犯很多的錯誤，就比如當初報表團隊給自己定個指標標準然后自己執行這種做法，就像孫悟空給自己套個金箍然后念緊箍咒一樣滑稽。即使數據治理好不容易起步了，但如何防止數據治理和數據管理活動搞成兩張皮，如何確保在生產流程中發揮出真正的作用，都存在巨大的不確定性。

2、數據中臺沉淀和數據快速開發的矛盾數據中臺的核心在于數據資產模型能力的沉淀，講究的是共享復用，這意味著在做需求的時候必須進行靈魂三問：

第一，你現在做的模型跟以前做的那些中臺模型是什么關系？

第二，你能不能復用這些中臺模型？第三，如果不能，能不能沉淀成中臺模型？為了達成這靈魂三問，數據團隊就會面臨一個兩難抉擇：如何一方面快速滿足數據需求，另一方面又要能沉淀數據資產？如果數據團隊安排同一撥人去做需求開發和模型管理，意味著自己跟自己打架，模型復用和沉淀往往成為犧牲品。如果拆分成兩撥人去做，就會帶來職責邊界不清、溝通成本提高、模型團隊成就感不足等問題，需求開發團隊會說，我做的都是應用模型，跟你中臺無關，中臺團隊想著既然沒有需求，那就自力更生創造幾個，但產出的東西大多沒什么卵用，中臺就這樣成了皇帝的新裝。

3、數據團隊核心能力認識上的模糊不清當前業界對數據團隊核心能力的認知是不一致的，無論是算法能力、數倉建模、報表取數、平臺建設、數據產品、數據變現、數據服務等等，認知的不同導致了不同的數據團隊的組成架構。比如我們數據倉庫時期會認為報表取數重要，因此會設立報表取數組，但搞了半天會發現沒啥沉淀，成就感普遍不足；數據中臺時期會認為數據建模很重要，因此設立了數據中臺組，但會感覺模型沒價值出口；數據治理時期新增了數據治理組，然后又會發現落地很困難。

那么，數據團隊到底哪些能力是最為核心的呢？哪些能力需要為其單獨設立小組？哪些能力又是適合放在一起的呢？我們需要找到答案。為了解決以上三個核心問題，我這里給出了一種數據團隊架構的方案，即分為三個組，分別為數據治理和變革項目組、數據中臺組及數據服務組，它們相對獨立，但又相互促進，也會相關牽制，力求達到"數出一孔"的目標，各個組的具體職能如下：

1、數據治理和變革項目組（1）負責數據規范標準制定（2）負責數據生產的檢測、評估和執法（3）負責企業級數據平臺的建設和運營（4）負責變革項目

2、數據中臺組（1）負責數據中臺的數據采集（2）負責基礎模型和融合模型的建設運營（3）負責數據中臺的運維

3、數據服務組（1）負責內外部的數據需求管理，包括報表、取數、標簽、接口、應用模型等（2）負責前臺類應用和產品建設運營下面我具體講講這么設置的原因。

首先講數據治理和變革項目組，以下簡稱數據治理組，有三個驅動力讓我決定成立這個小組：

1、第一驅動力：三權分立當前數據已經成為重要的生產要素，是企業數字化轉型的基礎，而大多企業都還存在數據架構落后、數據盤點不足、數據貫通不暢、數據開放不夠等問題，這些問題只有通過企業數據治理才能解決，包括組織架構的調整，制度規范的建立，流程的優化重構等等，考慮到數據治理無法一蹴而就，因此成立獨立的數據治理組來解決是必要的。數據團隊雖然規模不大，但到了一定階段還是要像政府治理一樣，走向三權分立的架構，即司法權，立法權和行政權的相對獨立，數據治理組負責相關規范標準的制定，數據中臺組、數據服務組等執行這些規范標準，數據治理組還需要對執行情況進行監督考核，從而確保規范標準的落地。數據治理是非常專業的工作，難度很大，但價值巨大，因此不要搞什么兼職，即使是個技術規范，也要專人專職，如果你不希望把規范扔抽屜里的話。我以前一直以為定個規范啥的是小事，這在認知上就已經錯了。很多數據團隊沒有企業級數據治理的職能，但即使從數據團隊本身發展的角度來講，也需要建立獨立的數據治理組。數據團隊特別需要一個能貫通前后端（從數據需求、開發、測試再到數據運維）的治理組織來統籌推進一些事情，如果說企業的數據治理是大循環，那么數據團隊通過數據治理讓自己運作的更高效就是小循環，在治理別人之前，我們先得治理好自己，這就是孔子的“己所不欲，勿施于人”，也是塔勒布“非對稱風險”的精髓。

2、第二驅動力：變革驅動但規范標準從制定到執行是個復雜的過程，需要人們改變行為和互動方式，甚至改變原有的生產關系，因此受到的阻力會很大，只有依托變革項目才能把這個事情真正做起來，就拿ETL的治理來講，必須有變革項目組牽頭，打穿所有的數據專業，說服所有的利益方，輔以系統化的培訓，對ETL的相關規范、流程和IT上進行大幅的變更才能落地。

3、第三驅動力：工具護航但這里還有兩個問題需要解決：一是規范標準很容易和實際生產脫節，造成兩張皮現象。二是變革項目組的不穩定性也使得項目所取得的成果很容易功虧一簣，我們以前搞元數據管理就深受其害。因此我做了一個改變，就是將企業級平臺和工具的建設職能放到了數據治理和變革項目組，這樣就比較容易把規范標準的要求嵌入到平臺工具中，從而確保執行到位，也能具備一定的可持續性。以前我想當然的把平臺工具建設的職能放到了數據中臺組，但后來發現效果不好，數據中臺組雖然可以提出很好的需求，但不代表具備建設能力，無論是專注力，全局性都差了很多。我希望數據治理和變革項目組既能站得高看得遠，又能不脫離實際，這個組對人員的綜合素質要求很高，大多應來自項目經理和數據管理者，自己最犯愁的也是這個。

其次講數據中臺組。數據中臺這個詞近幾年越吵越邪乎，但沒有人能給出一個確切的定義，我對數據中臺組的定位有兩個，一個是數據能力中心，另一個是數據運營中心。

1、數據能力中心對于傳統企業來講，很多數據工作是外包的，我不否認外包可以為企業打造核心能力，比如平臺和工具，但其范圍是有限的，而且往往是暫時的，沒法形成競爭性優勢，因為其它企業完全可以COPY。多年的實踐告訴我們，數據團隊的核心競爭力就是業務+數據+技術的結合能力，那么這個能力具體指什么呢？《未來十年，數據團隊最核心的能力到底是什么？by 大魚先生? ??》對此做了詳細的闡述："數據團隊真正需要的是一只數據模型產品經理隊伍，能夠以業務對象為核心（不局限于領域）來進行數據模型產品的構建，能夠為業務提供端到端的數據服務支撐，能夠解決跨領域數據模型構建過程中出現的數據標準、數據質量、數據整合等問題，他們是公司數據資產的真正代言人，能力要求遠遠超越了傳統的數據建模師。""數據團隊要圍繞業務對象進行組織的變革，也業務對象為核心進行人員職責的重新劃分，如果公司有100個核心業務對象，那么也許數據團隊需要50個產品經理，每個產品經理負責2個，這些產品經理為公司的數據資產整體負責，他們代表了數據團隊的核心競爭力，獨一無二。"我在10年前曾經喊出"數據建模核心能力自我掌控"的口號，當時針對的是大數據對外合作期間數據字典竟然成了某合作伙伴的私有資產的不合理現象，然后希望所有的數倉建模工作都由自己搞定，當然這種做法現在看來是片面的。我們現在需要做的，就是梳理出公司最為核心的業務對象，然后逐步攻關，考慮到人力資源的限制，先期會挑選地址、家客、資源等部分核心業務對象進行自我掌控的嘗試，然后慢慢拓展范圍。

那么，何謂自我掌控？假如你是公司“物資”這個業務對象的產品經理，那么圍繞“物資”你要建立一套貫通上下游的模型體系和數據標準，所有涉及物資的數據需求都應該由你端到端負責實現，任何涉及物資的業務流程變動，系統變動，數據變動，你都要能與時俱進的進行模型的同步變更，你是公司里最懂物資的人，無論是在業務上，系統上還是數據上。

2、數據運營中心數據的采集、運維和建模到底要分開還是合并已經吵了很多年了，我現在的傾向是合并，原因有三個：第一、與OLTP團隊不同，對于數據團隊來講，數據質量在運維體系中舉足輕重，但數據質量的核查和提升大多需要建模人員的介入，而連續性要求則相對較低，在數據團隊大發展時期，為了減少溝通成本，運維和建模合并有合理之處，當然運維失去獨立性可能不利于暴露問題，但總體上利大于弊。第二、在數據建模中往往需要去采集數據，特別是業務對象建模往往需要理解源端的各類數據，這使得數據采集和數據建模耦合度很高，我們的數據模型產品經理在建模的時候，一定是要自己去理解源端系統的數據然后推動采集并完善元數據，這個不能假手于人，因此，采集和建模的人員進行整合也是合適的。第三、隨著數據編織技術等的興起，數據采集現在越來越自動化了，比如我們90%的數據可以實現一鍵采集入湖，未來采集、建模和運維的邊界會越來越模糊，那么相關職能放在一起就可以減少扯皮。但數據中臺組還有個老問題就是數據模型沉淀缺乏足夠的業務驅動力，因為前端的數據服務組完全可以繞過"中臺三問"另起爐灶，他們會說迫于業務的需求壓力只能這么做，即使這些壓力不總是存在，我這里有三個策略：第一、數據采集需求由于要通過統一的ETL工具進行，因此很容易進行剛性管控，數據服務組的需求如果涉及數據采集，必然會流轉過來，數據中臺組可以基于新采集的數據來提供更好的模型。第二、數據運維中會暴露大量的數據問題，由于與建模人員同屬一個組織，這些數據問題很容易傳遞到中臺模型人員那里去優化解決，我認為，一個數據團隊至少要有30%的需求是自己提給自己的，否則技術負債會越來越多，但傳統的數據團隊架構很難做到這一點，大家都習慣圍著業務轉以致失衡，但站在公司全局利益角度出發，砍掉業務部門30%的需求來換取長遠能力的提升，這個買賣應該做。第三、數據治理組作為頂層設計者，有權力去規范和監督數據服務組"中臺三問"的執行情況，這對數據服務組就是個約束。解決了數據中臺組的業務驅動力問題，理解清楚了核心能力的本質，我們才能真正的沉淀有用的數據能力，而不要讓數據中臺成了皇帝的新裝，華而不實。

最后講數據服務組。數據服務組是面向最終用戶的，我有三個管理原則：

第一、按照垂直業務條線進行專業服務的支持，每個業務條線只有唯一的一個角色進行需求對接，類似銷售的職責，比如市場人員提了一個數據開放需求，即使這個開放需求涉及到數據采集，那么也需要由數據服務組的需求人員統一進行對接，然后由他去協調數據中臺團隊進行支持，這樣做，一方面管理簡單，確保業務能找到對的人，另一方面也有利于提升數據服務組自身的業務能力。

第二、每個需求人員要負責所有類型的數據需求，包括報表、取數、模型、標簽、開放、應用等等，因為各種類型的數據需求往往是有關聯性的，比如業務人員取了幾次數，就有可能要做一張報表，也可能希望固化成一個模型，如果分開支持，那么效率就下降了。

第三、數據服務組要背負相關的業務指標，無論是需求及時率，準確率等等，但數據服務組不能越界對數據中臺的模型進行任何的變更，數據服務組對數據中臺組依賴度的增加有利于各專業的協同和能力的沉淀，當然，數據服務組要對數據中臺組、數據治理組具有考核權，這樣大家就成了一個利益共同體。很多偏前端的應用，比如自助取數、手機經分、財務分析平臺、滿意度分析平臺等等，考慮到業務相關性比較大，因此會把這些應用的建設權放在數據服務組，但會碰到與數據中臺組、數據治理和規劃組如何協同的問題，比如自助取數用到的模型很多都是數據中臺組提供的。

華為公司提出了服務化的解決方案，即中臺能力團隊把數據封裝并且開放出來，前端團隊進行編排以靈活的滿足業務需要，這個方案看似很完美，但現實中要落地還是挺有挑戰，一方面業務規模不夠大，封裝的收益不高，另一方面數據能力的封裝難度很高，靈活度是大問題，OLTP衍生出來的API理念其實很難直接套用到OLAP領域，因為數據的維度是無限的，而OLTP領域抽象的API卻是非常有限的，量變引起了質變，不能一概而論。

最后，我希望三個小組是個有機的整體，相互之間的關系總結為三點：

第一、數據治理和規劃組負責建章立制，其他組按照要求執行，考慮到"兩張皮"問題，數據治理和規劃組一方面要承擔平臺工具的建設職責來強化執行，另一方面需對執行情況進行監督考核；

第二、數據中臺組基于數據治理和規劃組的要求（自上而下）、數據服務組的需求（自下而上）及自身運維暴露的問題三驅動來進行核心能力的沉淀和運營；

第三、數據服務組承擔考核的指標，基于垂直業務線進行需求管理，并且依托于其它兩個組提供的平臺和數據能力來提升效率，并對其它組進行支撐能力的考核。

當我剛設計完這個架構時，還是挺激動的，因為能回答自己前面的三個問題，當然這個架構對其它數據團隊來說，可能并不適用，因為大家要回答的問題不一樣，但我還是要把自己的思考過程寫下來，這個可能對大家更加有用。如果你讀到了這里，一定理解了其中的精妙之處，請分享給有需要的人吧，因為當初自己網上到處找數據團隊分工的文章而不可得，現在想來也有很多同仁跟我有一樣的訴求吧。