企業數據分析部門組織架構形式探討

數據時代的到來使企業越來越意識到數據的價值,企業紛紛建立自己的數據分析團隊.花重金招攬的數據人才怎麼融入到本企業組織中才能發揮他們的才能呢？本文試圖分析數據分析部門組織架構形式的優劣及影響。

從數據分析部門與傳統IT部門的關係來看,分析部門有兩種形式：設立獨立的分析部門或設在IT部門下，由一個CIO管轄。

從數據分析人員是否集中來看也分兩種情況：數據分析人員集中在大數據分析軟體中心或者數據分析人員分散在各個業務部門。或者混合情況：兩者都有數據分析人員，但職能分工不同。

下面具體分析三種典型組合情況：

第一種形式為傳統式，

如下圖：大數據中心設立在IT部門下，數據分析師集中在大數據中心。



這是一種大信息中心的形式。這種形式的特點是大數據中心與IT合并在一起，貼近數據源，業務部門向大數據中心提需求，大數據中心根據需求統一排期開發、分析。這時一般傳統的報表、臨時需求分析等也可能會與業務系統分開，由大數據中心管理。大數據中心對接各業務系統數據源在部門內部即可解決。各業務部門只需要跟大信息中心一次提需求即可。業務部門沒有自己的分析挖掘團隊，但一般會有傳統的報告分析。



這種形式大多由傳統BI系統部門演變而來。傳統的經營分析中心或商業智慧部演變為大數據中心，在數據倉庫基礎上增建大數據平台，增加大數據及數據挖掘人才，在原來的報表製作的基礎上建設更深入的數據分析應用。

優點：數據中心與IT在一個部門，離數據近，數據整合便利，保障數據質量高。集中的需求管理也使內部溝通有效，避免重複開發，也可以使分析師內部總結提高。

缺點：離業務較遠，尤其是分析團隊與業務部門的工作地點不同時，容易與業務部門溝通不暢，閉門造車。如果業務變化快，無法跟上業務的步伐，對數據的思考不夠深入，與業務部門溝通成本加大。

針對分析師集中後離業務較遠的弊端有一種方法為：分析師仍然集中在大數據中心，但分析資源的使用、請求在各個業務部門，企業各業務部門自己根據項目需求請求所需的分析師。這種情況下分析師需要同時向本部門和業務部門彙報工作。

第二種形式為集中式。



這種形式與第一種的主要區別在於大數據中心是否獨立。

這種形式的特點是公司所有與數據相關的平台建設、數據應用、數據分析挖掘都歸屬到一個部門，此部門是數據管理的唯一出口，業務部門不設立自己的分析團隊，IT部門也不負責相應平台開發維護。

優點：部門職責明確單一。指標由一個部門計算，口徑統一，且與業務部門獨立，所以立場獨立，分析結果更中立。

缺點：同時具有第一種形式的缺點，並且離業務部門及業務系統都較遠，無論是數據理解還是業務理解都可能不夠深入，同時如果大數據平台開發維護能力不強，會有技術困難難以推進。

數據分析，報表實例，專業的人都在這裡！加入FineReport臉書粉絲團！

第三種形式為混合式



此圖與之前的主要區別在於業務部門是否有分析師。這裡不再分析大數據中心是否獨立的問題。主要分析大數據中心下分析師與業務部門分析師的職能及定位。

大數據中心分析團隊職責主要集中在整個企業級的數據產品、數據應用、數據分析。服務的對象也主要是公司級的部門和領導。他們技術能力和業務能力更強，能利用最新技術解決業務問題，同時必要時對業務部門分析團隊給予指導。

而各業務部門自己的分析團隊主要服務於自己部門內部，技術能力不等，以前主要根據報表做統計或分析報告，但他們本身在業務部門對業務理解深入，主要是利用數據解決業務問題。有些強勢部門可直連倉庫自己寫SQL提數，定製開發簡易報表，技術強的業務部門甚至要求建設自己的數據集市，搭建自己的挖掘團隊。

這種形式下的主要缺點是兩者職責有時劃分不清，造成部門利益為重、爭搶項目、職責推諉、重複開發、口徑不一致等問題。各業務部門的分析團隊之間交流不暢，技能提升有限。有一種變通的方法為打破各部門利益障礙，建立橫向的虛擬分析團隊，加強虛擬團隊內部溝通交流，甚至團隊內部成員作為共享資源可根據項目周期流動。



通過以上分析可以發現為發揮分析優勢，是在集中分析部門便於內部交流與靠近業務便於理解業務的矛盾的平衡。

每個形式都有各自的優點與缺點，沒有對錯之分。沒有最好的只有最合適的，每個企業都要根據自己的實際情況進行調整。

文 | 岳瑞
文章源自：數據陽光

這個應該是很龐大的企業才有需要小公司 規模太小也請不起

這要請幾個工程師來寫數據阿....

這樣的架構要多大的公司才能負擔阿........

不只大公司才可以
要有效整合才有用  很多現在所謂的大數據都還是EXCEL.............