- 產品
- 產品解決方案
- 行業解決方案
- 案例
- 數據資產入表
- 賦能中心
- 伙伴
- 關于
時間:2022-11-03來源:戒不掉的煙瀏覽數:82次
這個話題備受爭議,今天就來聊一聊。OLAP系統和OLTP系統分別叫事務系統和分析系統,業務中臺一般屬于OLTP,數據中臺一般屬于OLAP,傳統業務中臺和數據中臺無論在組織上、系統上都是涇渭分明的,除了數據中臺需要從業務中臺采集數據,兩者甚至可以做到老死不相往來。隨著數字化轉型的深入,很多企業的數據中臺和業務中臺的界限越來越模糊了,甚至開始發生職能沖突,下面是一個例子,大家可以感受一下:
上面這張圖體現出一個重要但隱蔽的問題,就是為前臺提供推薦服務的場景,到底用哪種方案,是用③ + ① 還是 ④?
方案一:由業務中臺團隊提供相關的能力,數據中臺輔助,即走③+①的通路,這一般是業務中臺團隊希望的架構。
方案二:直接由數據中臺團隊直接對接前臺團隊,提供相關的能力,即直接走④的通路,這一般是數據中臺團隊希望的架構。那么,哪種方案更合理呢?
第一種方案的優勢主要體現為四點:
1、從業務看,業務中臺方一般承載著公司的核心業務流程,其對于業務的理解更好。
2、從組織看,前臺應用與業務中臺方一般同屬一只OLTP團隊,溝通成本相對較低。
3、從架構看,由于業務中臺和前臺應用所采用的技術棧類似,數據服務通過業務中臺可以無縫集成到前臺的業務流程中,體驗會更好。
4、從運維看,業務中臺提供數據服務的可用性,連續性會更好。
第二種方案的優勢主要體現為二點:
1、從認知看,數據中臺團隊擁有更多的數據驅動業務的思維,用數據賦能業務的驅動力更強。
2、從能力看,數據中臺更具備基于數據建模打造優質數據服務的能力。
從以上比較看,似乎第一種方案更好,即由業務中臺統一對接前臺應用。
從本質上講,無論是傳統的業務服務或者是新型的數據服務,都是為客戶提供的一種服務,它們應該通過統一的業務流程體現出其價值,不能因為技術實現上的差別就改變支撐的模式,比如業務服務就讓業務中臺團隊牽頭實現,數據服務就讓數據中臺團隊牽頭實現,長遠來講,這樣做的集約化效率肯定是偏低的。
當然選擇哪種方案還跟企業所處的行業和發展階段相關。比如很多企業業務中臺團隊對自己定位就是純粹的在線受理系統,精確營銷的實際主導者在數據中臺團隊,對于業務中臺來講,數據中臺提供的精確營銷服務就是一個外掛,或者只是提供了一個展示的窗口而已,這個時候如果強制使用方案一,那管理的代價可能會很大,因為認識很難短期改變。
在相當長的時間內,很多企業的數據中臺和業務中臺實際都采用了方案二來解決推薦服務的問題,但方案二存在先天的問題,即在規模越做越大的時候,短板會不斷暴露,包括:
1、距離業務較遠,與業務的協同難度偏高
2、數據服務過于依賴業務中臺提供的運營位,場景適配能力低
3、數據采集和效果評估依賴業務中臺,數據閉環運營挑戰大
4、數據服務的連續性和可用性保障水平偏低近
幾年情況也有了些變化,業務中臺團隊的數字化意識漸起,不再滿足于僅僅實現業務流程,更希望在業務流程中嵌入數智化服務來創造更大的價值,這個時候采用方案二的合理性就大幅增加了。
但業務中臺團隊短期內無法解決數據服務能力的問題,因此還是要通過組織優化的方式來解決,即剝離數據中臺團隊的部分職能,歸并進業務中臺團隊,那么具體怎么做呢?
1、數據中臺團隊的工作大致可以分為兩大類:決策支持類和業務響應類,決策支持類主要面向管理者,包括傳統的報表、取數、BI等等,業務響應類主要面向執行者,包括嵌入在業務流程中的推薦,預測服務等等,需要將業務響應類的工作劃轉到業務中臺團隊。
2、基于人隨事走的原則,數據中臺團隊原來負責業務響應類工作的人員劃轉到業務中臺團隊,確保其一開始就擁有基本的數據服務能力,OLTP和OLAP人員混編也是數據網格特別推崇的組織方式,因為兩者能力互補,有利于協同對外提供統一的服務能力。
3、基于數據湖建設兩個數據倉庫,前者為新業務中臺團隊服務,后者為原數據中臺團隊服務,這里并不提倡模型復用,因為兩者面向的業務場景不同,決定了其模型復用度不會很高,而且采用的數據技術棧也各有側重,比如業務中臺團隊一般會強調倉庫的實時性,而原數據中臺團隊不一定。
組織架構優化后,新的業務中臺團隊實際上包含了業務和數據兩個團隊的人員,獨立的數據中臺團隊不再存在,或者說成為了業務中臺團隊的一部分,數據中臺團隊退化回數據倉庫時代的狀態,只為決策支持提供服務。
還有一種可能是數據中臺團隊升級為企業級的數據治理團隊,當然企業級治理團隊的使命跟業務無關,它主要的工作變成了建章立制,拉通數據,提供通用的數據湖或一站式工具鏈等等。
當初數據倉庫從業務系統拆出來的時候,其目的可是僅滿足決策支持的需要,當數據倉庫逐步壯大到能直接反哺傳統業務系統的時候,數據倉庫其實早已不是當初那個數據倉庫了,這個時候也許就到了重新思考其定位的時候了,所謂合久必分,分久必合。
當然對于很多企業來講,由于連數據倉庫還沒做好,那就完全不用考慮,而對某些企業來講,或許已經是這種架構了。