今天整理和分享下近期進行數據中台需求交流和售前解決方案制作過程中的一些思考總結，對于主數據平台，數據中台，大數據平台等在我頭條前面的文章中都有專門的論述，因此這篇文章不會再去詳細講解這部分的内容。

數據中台這個概念在最近幾年相當的火，傳統的做MDM主數據，大數據，包括BI類廠商都轉向做數據中台解決方案。特别是很多人将企業的數字化轉型簡單地理解為數據化，過分誇大數據驅動和數據的價值，這也間接導緻了數據中台比業務中台得到更大的推廣和建設。

這篇文章不去談論數據中台本身的對或錯，而是真正從最近一段時間和客戶交流過程中，涉及到數據中台建設的需求溝通和方案建設的一些思考和總結。

大家都清楚，傳統的IT系統建設模式最大的問題就是導緻了各個業務系統垂直隔離，數據無法共享和協同，包括同一個基礎數據多個系統共同建設和管理引起的數據不一緻等問題。

在和客戶溝通中，客戶剛開始的需求很簡單，即要構建一個統一的基礎數據，包括共享的動态數據的統一數據視圖，解決當前的數據多點建設，多點錄入，數據不一緻等諸多問題。

舉個簡單的例子，比如一個房地産類企業，下面是餐飲，文旅，物業諸多的子公司，但是當客戶面對這些子公司的時候都需要新注冊會員和用戶，導緻客戶重複注冊，對于子公司之間同樣這些新無法互聯互通，物業公司的會員信息也無法共享給餐飲子公司使用。

當你面對這個問題的時候有兩個思路。

第一個思路就是各個業務系統都不要再管理客戶或會員信息，企業單獨建設一個統一的CRM或會員管理系統來進行管理，然後再講會員信息開放給各個業務系統使用。

第二個思路是将各個業務系統管理的會員信息進行采集和整合，在整合過程中進行數據質量檢查，包括規範性檢查和去重等，形成一個完整的客戶統一視圖再提供給上層業務系統或分析決策類系統使用。

不論是以上哪種思路，傳統的類似MDM主數據平台建設都可以很好地解決上面的問題。第一種思路對應到集中化建設思路，第二種對應到共享化建設思路。

在和客戶的溝通中，發現客戶并不想去構建一個獨立的MDM主數據平台，按傳統IT架構進行集成，而是希望構建數據中台來解決上面這個問題。在和客戶的需求和方案讨論中，逐步梳理清楚以下兩個關鍵原因。

首先整個客戶的IT系統都在規劃考慮逐步數字化和微服化轉型，因此不太希望還安裝建設MDM系統，通過ESB傳統集成方式來解決當前問題。

其次是客戶期望的目标不僅僅是底層數據整合和統一數據視圖提供業務使用，同時也希望整合後的數據，比如統一客戶視圖，能夠提供給上層大數據分析使用，比如常說的客戶行為分析，客戶大數據畫像等。

也就是說客戶也不是盲目地上數據中台，而是有自己的考慮，前期也對數據中台做給相關的學習和研究。

在阿裡最早提起數據中台的概念的時候，整體中台架構裡面包括了業務中台和數據中台，也就是常說的雙中台架構。

業務中台一般來講會采用微服務架構進行單體拆分，形成類似用戶中心，訂單中心，庫存中心，支付中心等各個微服務能力中心。而數據中台則是一方面采集業務數據中台的數據進行整合，形成數據服務後又反哺業務系統使用。

也就是常說的業務能力數據化，數據能力業務化。

在前面很多中台的文章裡面已經談到，傳統企業IT架構要進行微服務化轉型，包括從傳統架構轉變為類似業務中台這種架構，整體改造和遷移的難度都相當大，用傷筋動骨來形容也不過分。

那麼能否在沒有形成業務中台的情況下，或者說在企業IT仍然是傳統IT業務系統支撐的情況下來構建數據中台？

這個是在規劃建設數據中台的時候必須要回答的問題。在這裡先給出下結論就是：

企業完全可以在業務系統仍然是傳統IT架構的情況下優先構建數據中台，而不是等業務中台建設完成後再構建數據中台。企業業務中台的建設可以逐步演進，但是數據中台的建設可以一開始就按目标架構規劃，逐步實施。

最近幾年可以看到，将傳統IT架構完全推翻，一開始就去規劃構建大而全的業務中台，去構建全業務能力中心的很多項目大部分都是失敗的。這也導緻很多企業認為中台就是一個忽悠人的概念并怨聲載道。對于其它的一些一開始沒有實施全面的中台化，反而是業務和問題驅動，先去規劃建設數據中台的項目，反而是取得了不小的實施收益和效果。

所以企業在進行内部IT系統規劃和建設的時候，一定要考慮到遺留系統的資産如何保留，如何逐步遷移，如何分步驟實施減少推動阻力等諸多問題。太理想化的東西帶來的一定就是落地實施困難，這個道理大家要清楚。

客戶為何不構建一個類似業務中台中的客戶中心微服務？

在前面已經談到為了對客戶信息進行統一，在主數據中也存在集中化建設模式，即将原來業務系統中管理客戶的功能全部封閉，而是将其移動到主數據平台統一管理，包括客戶的申請，創建，變更，廢棄，數據分發，對外能力開放等都集中化到MDM系統中進行管理。

按照新的中台思路，沒有一個獨立的MDM系統。

那麼能否構建一個客戶中心獨立的微服務，來将各個業務系統中對客戶管理的功能移出，全部放到客戶中心進行管理，再對外提供服務能力？在和客戶的溝通中，客戶也想過這個方案，最終通過讨論後将這個方案徹底否決，其原因主要包括以下三個點。

第一是集中建設客戶中心不是簡單地構建一個系統，而是涉及到原有的組織架構的調整，這個組織架構，職責調整還涉及到子公司，可想而知難度多大。

第二是集中建設不同于簡單地抽取數據共享，集中建設後一定涉及到已有的各個子公司業務系統已有功能的變更和改造，這個推廣實施難度同樣很大。

第三是原有子公司自己構建業務系統，數據都在自己掌控，現在集團想構建集中化系統将數據拿走，子公司僅隻有數據的使用權，這個事情你認為有無難度？簡單來說，你要多給些我需要的數據給我使用，那麼我願意。但是你要把我的數據拿走，沒那麼簡單。

綜合以上幾點，可以看到任何新系統建設，都不是技術層面的問題，而是管理和業務層面的問題。單純從技術驅動思維去考慮系統建設，一般都死得很慘。

在建設和實施數據中台的時候，對于數據中台，主數據，大數據平台三者之間的關系必須要搞清楚。在前面已經解釋了為何是實時數據中台而不是建設主數據平台。

數據中台承擔傳統主數據平台的功能

主數據平台的建設一般包括了集中化建設和共享化建設兩種模式，對于共享化建設則是基礎主數據原有的創建，申請，變更等流程還是在業務系統裡面無變化，MDM系統僅僅是抽取數據進行清洗和整合，形成統一數據視圖再提供服務。

當建設數據中台的時候，完全可以完全替代主數據平台中的共享化建設模式，即重點是實現數據的采集，集成，整合，清洗，數據服務能力開放。而對于數據創建變更等内容管理仍然放在各個業務系統裡面。

那麼數據中台在進行數據采集整合過程中如果發現了數據質量問題如何處理？

簡單來說，這些數據不一緻，數據不完整等問題，數據中台僅僅是發現問題，而對于問題本身的修複仍然要回到源頭的業務系統進行。

大數據平台是數據中台演進的關鍵

大數據平台是一個技術平台。這個技術平台提供了對于大數據的分布式采集，存儲，流處理和計算，實時分析等能力。在沒有大數據平台前也有數據集成和管理的平台，這種平台可以實現對結構化數據本身的采集，集成和管理。

而對于數據中台，一般底層都需要一個提供數據存儲和處理能力支撐的技術平台。這個技術平台如果你有大數據需求，構建出來的就是大數據平台。但是如果你沒有大數據需求，那麼用傳統的數據集成和管理技術平台即可。

其次，數據中台的範疇包括了如下幾個方面

• 一套底層的數據技術平台（可以是大數據平台，也可以是數據集成平台）
• 一套數據資産（業務層面的内容，實際數據，數據模型，算法都裝進來了）
• 一套數據服務能力提供和共享
• 一套數據管控和治理标準規範體系

因此可以看到對于數據中台核心重要的反而是數據資産 數據服務能力共享這兩點,而這兩點在一般的大數據平台并不會包含。如果整個數據中台建設有大數據平台，那麼大數據平台也僅僅是一個底層技術平台和技術實現手段。具體兩者的差異點我們再通過圖來對比下。

基于客戶前面的需求，可以看到。

規劃建設數據中台不是馬上就需要進行大數據分析，客戶畫像等，而是優先解決統一客戶數據視圖，提供數據服務能力給業務系統使用，即數據反哺業務。

當數據中台建設采用了大數據平台這個技術底座後，那麼這個技術選型具備了支撐後續大數據分析類應用場景的可能。即使當前不會用到大數據平台中的各種技術，但是平台建設需要考慮後續這些技術的引入沒有侵入性，也不會影響到已有的功能。

為啥不是建設大數據平台？

前面也分析了，短期目标實際是數據服務能力開放，為業務系統提供實時數據服務能力接口。數據中台架構裡面有一個重要的數據服務能力開放層，這個在傳統的大數據平台裡面是沒有的，這也是構建數據中台的一個差異點。

不要以為數據中台就是幾百萬上千萬的大工程，數據中台建設一樣需要基于垂直場景逐步落地實施，要有逐步演進實施和持續叠代的規劃建設思路。

對于客戶來講想的也是先做一個小預算投入，先進行試錯，如果實施效果好再大面積建設和推廣，因此在規劃建設數據中台的時候需要這個點也考慮進去。

對于數據中台的建設一般包括了三方面内容。

• 底層大數據技術平台搭建
• 相關數據資産建設和内容服務提供
• 數據管控治理标準規範

對于技術平台搭建，管控治理規範建設兩項内容一般在第一期項目建設和實施中就必須完成。技術平台建設需要考慮整個技術架構，各種開源工具和技術的選型，本身的高可用性和可擴展性，這個不能出現大的選擇錯誤，否則後續可能導緻整個底層技術支撐推倒重來。

對于數據治理同樣的道理，裡面涉及到元數據管理，數據質量管理，數據标準規範體系，數據安全管理，數據能力開放諸多的内容都需要指定相應的管理流程，标準規範體系。這個是實施各類數據主題域，數據資産管理的集成。

這兩部分内容無法叠代，在第一期就需要規劃建設好。而對于數據内容和數據資産管理則完成可以根據垂直業務場景，客戶迫切需要解決的問題來規劃建設。

比如這個客戶，前期目标很明确，就是需要首先解決當前客戶和用戶信息不統一，構建客戶統一視圖的問題。那麼第一期實施重點圍繞客戶主題域進行即可。

在前面更多談的都是數據中台整體的功能架構或技術架構，但是數據中台類項目不是你賣一個标準化的數據中台産品，更多的反而是你如何進行數據資産和數據内容管理。

或者講搭建平台隻是第一步，更加重要的是如何進行實施？

比如前面提到客戶一個核心目标是構建客戶統一視圖，遠期目标是構建大數據客戶畫像和标簽體系，那麼在準備售前方案的時候就需要去詳細回答這個問題。

對這個問題的回答最終應該體現在整體的實施方法論上面。還是以上面這個問題出發，要構建客戶統一視圖，簡單來講至少應該包括如下關鍵階段或步驟。

• 客戶數據管理現狀調研和梳理
• 數據采集和集成=>數據貼源層
• 數據清洗
• 數據模型建立，數據整合
• 數據資産和數據内容管理
• 數據服務能力開放

簡單來說就是你需要詳細地說明清楚如何構建客戶統一視圖，裡面包括了哪些關鍵步驟，每個關鍵步驟涉及到哪些方法，哪些工具技術。不要講太多技術層面的内容，但是整個方法流程必須要講清楚。

要講大數據用戶畫像和标簽構建，那麼就需要将整體标簽構建方法涉及到的關鍵步驟說明清楚。比如上圖，标簽體系建設包括了标簽定義，标簽申請，标簽建立，标簽展示，标簽維護等多個步驟和環節，這個關鍵方法需要講清楚。

對于數據中台建設項目。

技術平台是骨，而具體構建的内容資産和服務體系才是血和肉，沒有血和肉的數據中台是沒有靈魂的，也無法解決客戶真正的業務問題。

講述整體實施方法和内容的核心就是要說明清楚數據中台建設不是單純地給企業搭建一個大數據技術平台，而是真正基于業務問題和目标驅動，将數據資産和數據内容裝進來，形成能夠為業務系統服務的數據服務能力，這才是數據中台建設的價值。

在我原來整理主數據平台建設方案的時候，給出了完整的方法論，如上圖分為主數據現狀分析，業務解決方案，信息系統建設，實施方案幾個大的階段。回到數據中台，基于客戶的需求和目标如何準備方案。

簡單來說可以分為四個大的章節來準備。

1.現狀分析和目标提出

整個方案首先還是得對當前數據管理和使用現狀進行分析，基于當前存在的一些問題給出最終的項目建設目标和範圍，這個是标準套路。

基于前面的梳理，客戶對于數據中台建設項目可以分為幾個關鍵的子目标，即搭建一個技術平台，構建一套數據治理規範體系，同時基于客戶域進行數據資産和内容管理，這個本身又可以展開為統一客戶數據視圖和服務提供，客戶大數據分析和畫像兩個層面。

2.數據中台整個架構介紹

對于第二部分還是需要介紹清楚數據中台整體架構框架，注意這裡不是單純的技術架構，還需要介紹清楚技術架構上層的數據建模，數據資産和内容管理，數據服務能力開放等。

也就是說數據中台架構本身是分層的，需要說明清楚整體分層邏輯。

3.數據中台實施方法論和實施策略

注意這裡不是簡單的講解标準的實施方法論，基于客戶的需求和目标，最好是在這部分詳細說明清楚基于數據中台當前産品的功能架構和組件，如何基于客戶業務系統和數據現狀，來完成統一的客戶統一視圖溝通，數據服務能力的開放，如何實現客戶信息的大數據畫像。

什麼意思？

前面數據中台架構是一種靜态架構，現在基于客戶提出的需求和目标，你需要去回答如何基于你已有的功能架構組件，工具和技術，來一步步完成最終客戶的業務目标。

即真正回答清楚數據中台中的内容和資産是如何一步步建設出來的。

4.數據管控治理體系

這部分是必須交待的内容，即不僅僅是幫客戶構建一個平台，完成了一個數據資産或内容的建設，更加重要的是幫助客戶建立一天覆蓋數據全生命周期的管控治理規範體系，這才是真正的知識轉移和資産沉澱。

數據管控治理剛好體現了自身多年經驗積累，最佳實踐的沉澱。

5.項目管理範疇

當然，還可以對項目管理範疇内容進一步細化。包括對整個項目工作量和費用的預估，項目執行周期的預估，是否需要分叠代版本的規劃，具體項目參與人員，項目組織架構，項目交付物清單等的說明。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!