今天整理和分享下近期進(jìn)行數(shù)據(jù)中臺(tái)需求交流和售前解決方案制作過程中的一些思考總結(jié)，對(duì)于主數(shù)據(jù)平臺(tái)，數(shù)據(jù)中臺(tái)，大數(shù)據(jù)平臺(tái)等在我頭條前面的文章中都有專門的論述，因此這篇文章不會(huì)再去詳細(xì)講解這部分的內(nèi)容。
數(shù)據(jù)中臺(tái)這個(gè)概念在最近幾年相當(dāng)?shù)幕?，傳統(tǒng)的做MDM主數(shù)據(jù)，大數(shù)據(jù)，包括BI類廠商都轉(zhuǎn)向做數(shù)據(jù)中臺(tái)解決方案。特別是很多人將企業(yè)的數(shù)字化轉(zhuǎn)型簡(jiǎn)單地理解為數(shù)據(jù)化，過分夸大數(shù)據(jù)驅(qū)動(dòng)和數(shù)據(jù)的價(jià)值，這也間接導(dǎo)致了數(shù)據(jù)中臺(tái)比業(yè)務(wù)中臺(tái)得到更大的推廣和建設(shè)。
這篇文章不去談?wù)摂?shù)據(jù)中臺(tái)本身的對(duì)或錯(cuò)，而是真正從最近一段時(shí)間和客戶交流過程中，涉及到數(shù)據(jù)中臺(tái)建設(shè)的需求溝通和方案建設(shè)的一些思考和總結(jié)。
主數(shù)據(jù)平臺(tái)還是數(shù)據(jù)中臺(tái)
大家都清楚，傳統(tǒng)的IT系統(tǒng)建設(shè)模式最大的問題就是導(dǎo)致了各個(gè)業(yè)務(wù)系統(tǒng)垂直隔離，數(shù)據(jù)無法共享和協(xié)同，包括同一個(gè)基礎(chǔ)數(shù)據(jù)多個(gè)系統(tǒng)共同建設(shè)和管理引起的數(shù)據(jù)不一致等問題。
在和客戶溝通中，客戶剛開始的需求很簡(jiǎn)單，即要構(gòu)建一個(gè)統(tǒng)一的基礎(chǔ)數(shù)據(jù)，包括共享的動(dòng)態(tài)數(shù)據(jù)的統(tǒng)一數(shù)據(jù)視圖，解決當(dāng)前的數(shù)據(jù)多點(diǎn)建設(shè)，多點(diǎn)錄入，數(shù)據(jù)不一致等諸多問題。
舉個(gè)簡(jiǎn)單的例子，比如一個(gè)房地產(chǎn)類企業(yè)，下面是餐飲，文旅，物業(yè)諸多的子公司，但是當(dāng)客戶面對(duì)這些子公司的時(shí)候都需要新注冊(cè)會(huì)員和用戶，導(dǎo)致客戶重復(fù)注冊(cè)，對(duì)于子公司之間同樣這些新無法互聯(lián)互通，物業(yè)公司的會(huì)員信息也無法共享給餐飲子公司使用。
當(dāng)你面對(duì)這個(gè)問題的時(shí)候有兩個(gè)思路。
第一個(gè)思路就是各個(gè)業(yè)務(wù)系統(tǒng)都不要再管理客戶或會(huì)員信息，企業(yè)單獨(dú)建設(shè)一個(gè)統(tǒng)一的CRM或會(huì)員管理系統(tǒng)來進(jìn)行管理，然后再講會(huì)員信息開放給各個(gè)業(yè)務(wù)系統(tǒng)使用。
第二個(gè)思路是將各個(gè)業(yè)務(wù)系統(tǒng)管理的會(huì)員信息進(jìn)行采集和整合，在整合過程中進(jìn)行數(shù)據(jù)質(zhì)量檢查，包括規(guī)范性檢查和去重等，形成一個(gè)完整的客戶統(tǒng)一視圖再提供給上層業(yè)務(wù)系統(tǒng)或分析決策類系統(tǒng)使用。
不論是以上哪種思路，傳統(tǒng)的類似MDM主數(shù)據(jù)平臺(tái)建設(shè)都可以很好地解決上面的問題。第一種思路對(duì)應(yīng)到集中化建設(shè)思路，第二種對(duì)應(yīng)到共享化建設(shè)思路。
在和客戶的溝通中，發(fā)現(xiàn)客戶并不想去構(gòu)建一個(gè)獨(dú)立的MDM主數(shù)據(jù)平臺(tái)，按傳統(tǒng)IT架構(gòu)進(jìn)行集成，而是希望構(gòu)建數(shù)據(jù)中臺(tái)來解決上面這個(gè)問題。在和客戶的需求和方案討論中，逐步梳理清楚以下兩個(gè)關(guān)鍵原因。
首先整個(gè)客戶的IT系統(tǒng)都在規(guī)劃考慮逐步數(shù)字化和微服化轉(zhuǎn)型，因此不太希望還安裝建設(shè)MDM系統(tǒng)，通過ESB傳統(tǒng)集成方式來解決當(dāng)前問題。
其次是客戶期望的目標(biāo)不僅僅是底層數(shù)據(jù)整合和統(tǒng)一數(shù)據(jù)視圖提供業(yè)務(wù)使用，同時(shí)也希望整合后的數(shù)據(jù)，比如統(tǒng)一客戶視圖，能夠提供給上層大數(shù)據(jù)分析使用，比如常說的客戶行為分析，客戶大數(shù)據(jù)畫像等。
也就是說客戶也不是盲目地上數(shù)據(jù)中臺(tái)，而是有自己的考慮，前期也對(duì)數(shù)據(jù)中臺(tái)做給相關(guān)的學(xué)習(xí)和研究。
沒有業(yè)務(wù)中臺(tái)能否先上數(shù)據(jù)中臺(tái)？
在阿里最早提起數(shù)據(jù)中臺(tái)的概念的時(shí)候，整體中臺(tái)架構(gòu)里面包括了業(yè)務(wù)中臺(tái)和數(shù)據(jù)中臺(tái)，也就是常說的雙中臺(tái)架構(gòu)。
業(yè)務(wù)中臺(tái)一般來講會(huì)采用微服務(wù)架構(gòu)進(jìn)行單體拆分，形成類似用戶中心，訂單中心，庫存中心，支付中心等各個(gè)微服務(wù)能力中心。而數(shù)據(jù)中臺(tái)則是一方面采集業(yè)務(wù)數(shù)據(jù)中臺(tái)的數(shù)據(jù)進(jìn)行整合，形成數(shù)據(jù)服務(wù)后又反哺業(yè)務(wù)系統(tǒng)使用。
也就是常說的業(yè)務(wù)能力數(shù)據(jù)化，數(shù)據(jù)能力業(yè)務(wù)化。
在前面很多中臺(tái)的文章里面已經(jīng)談到，傳統(tǒng)企業(yè)IT架構(gòu)要進(jìn)行微服務(wù)化轉(zhuǎn)型，包括從傳統(tǒng)架構(gòu)轉(zhuǎn)變?yōu)轭愃茦I(yè)務(wù)中臺(tái)這種架構(gòu)，整體改造和遷移的難度都相當(dāng)大，用傷筋動(dòng)骨來形容也不過分。
那么能否在沒有形成業(yè)務(wù)中臺(tái)的情況下，或者說在企業(yè)IT仍然是傳統(tǒng)IT業(yè)務(wù)系統(tǒng)支撐的情況下來構(gòu)建數(shù)據(jù)中臺(tái)？
這個(gè)是在規(guī)劃建設(shè)數(shù)據(jù)中臺(tái)的時(shí)候必須要回答的問題。在這里先給出下結(jié)論就是：
企業(yè)完全可以在業(yè)務(wù)系統(tǒng)仍然是傳統(tǒng)IT架構(gòu)的情況下優(yōu)先構(gòu)建數(shù)據(jù)中臺(tái)，而不是等業(yè)務(wù)中臺(tái)建設(shè)完成后再構(gòu)建數(shù)據(jù)中臺(tái)。企業(yè)業(yè)務(wù)中臺(tái)的建設(shè)可以逐步演進(jìn)，但是數(shù)據(jù)中臺(tái)的建設(shè)可以一開始就按目標(biāo)架構(gòu)規(guī)劃，逐步實(shí)施。
最近幾年可以看到，將傳統(tǒng)IT架構(gòu)完全推翻，一開始就去規(guī)劃構(gòu)建大而全的業(yè)務(wù)中臺(tái)，去構(gòu)建全業(yè)務(wù)能力中心的很多項(xiàng)目大部分都是失敗的。這也導(dǎo)致很多企業(yè)認(rèn)為中臺(tái)就是一個(gè)忽悠人的概念并怨聲載道。對(duì)于其它的一些一開始沒有實(shí)施全面的中臺(tái)化，反而是業(yè)務(wù)和問題驅(qū)動(dòng)，先去規(guī)劃建設(shè)數(shù)據(jù)中臺(tái)的項(xiàng)目，反而是取得了不小的實(shí)施收益和效果。
所以企業(yè)在進(jìn)行內(nèi)部IT系統(tǒng)規(guī)劃和建設(shè)的時(shí)候，一定要考慮到遺留系統(tǒng)的資產(chǎn)如何保留，如何逐步遷移，如何分步驟實(shí)施減少推動(dòng)阻力等諸多問題。太理想化的東西帶來的一定就是落地實(shí)施困難，這個(gè)道理大家要清楚。
客戶為何不構(gòu)建一個(gè)類似業(yè)務(wù)中臺(tái)中的客戶中心微服務(wù)？
在前面已經(jīng)談到為了對(duì)客戶信息進(jìn)行統(tǒng)一，在主數(shù)據(jù)中也存在集中化建設(shè)模式，即將原來業(yè)務(wù)系統(tǒng)中管理客戶的功能全部封閉，而是將其移動(dòng)到主數(shù)據(jù)平臺(tái)統(tǒng)一管理，包括客戶的申請(qǐng)，創(chuàng)建，變更，廢棄，數(shù)據(jù)分發(fā)，對(duì)外能力開放等都集中化到MDM系統(tǒng)中進(jìn)行管理。
按照新的中臺(tái)思路，沒有一個(gè)獨(dú)立的MDM系統(tǒng)。
那么能否構(gòu)建一個(gè)客戶中心獨(dú)立的微服務(wù)，來將各個(gè)業(yè)務(wù)系統(tǒng)中對(duì)客戶管理的功能移出，全部放到客戶中心進(jìn)行管理，再對(duì)外提供服務(wù)能力？在和客戶的溝通中，客戶也想過這個(gè)方案，最終通過討論后將這個(gè)方案徹底否決，其原因主要包括以下三個(gè)點(diǎn)。
第一是集中建設(shè)客戶中心不是簡(jiǎn)單地構(gòu)建一個(gè)系統(tǒng)，而是涉及到原有的組織架構(gòu)的調(diào)整，這個(gè)組織架構(gòu)，職責(zé)調(diào)整還涉及到子公司，可想而知難度多大。
第二是集中建設(shè)不同于簡(jiǎn)單地抽取數(shù)據(jù)共享，集中建設(shè)后一定涉及到已有的各個(gè)子公司業(yè)務(wù)系統(tǒng)已有功能的變更和改造，這個(gè)推廣實(shí)施難度同樣很大。
第三是原有子公司自己構(gòu)建業(yè)務(wù)系統(tǒng)，數(shù)據(jù)都在自己掌控，現(xiàn)在集團(tuán)想構(gòu)建集中化系統(tǒng)將數(shù)據(jù)拿走，子公司僅只有數(shù)據(jù)的使用權(quán)，這個(gè)事情你認(rèn)為有無難度？簡(jiǎn)單來說，你要多給些我需要的數(shù)據(jù)給我使用，那么我愿意。但是你要把我的數(shù)據(jù)拿走，沒那么簡(jiǎn)單。
綜合以上幾點(diǎn)，可以看到任何新系統(tǒng)建設(shè)，都不是技術(shù)層面的問題，而是管理和業(yè)務(wù)層面的問題。單純從技術(shù)驅(qū)動(dòng)思維去考慮系統(tǒng)建設(shè)，一般都死得很慘。
從主數(shù)據(jù)，大數(shù)據(jù)平臺(tái)到數(shù)據(jù)中臺(tái)
在建設(shè)和實(shí)施數(shù)據(jù)中臺(tái)的時(shí)候，對(duì)于數(shù)據(jù)中臺(tái)，主數(shù)據(jù)，大數(shù)據(jù)平臺(tái)三者之間的關(guān)系必須要搞清楚。在前面已經(jīng)解釋了為何是實(shí)時(shí)數(shù)據(jù)中臺(tái)而不是建設(shè)主數(shù)據(jù)平臺(tái)。
數(shù)據(jù)中臺(tái)承擔(dān)傳統(tǒng)主數(shù)據(jù)平臺(tái)的功能
主數(shù)據(jù)平臺(tái)的建設(shè)一般包括了集中化建設(shè)和共享化建設(shè)兩種模式，對(duì)于共享化建設(shè)則是基礎(chǔ)主數(shù)據(jù)原有的創(chuàng)建，申請(qǐng)，變更等流程還是在業(yè)務(wù)系統(tǒng)里面無變化，MDM系統(tǒng)僅僅是抽取數(shù)據(jù)進(jìn)行清洗和整合，形成統(tǒng)一數(shù)據(jù)視圖再提供服務(wù)。
當(dāng)建設(shè)數(shù)據(jù)中臺(tái)的時(shí)候，完全可以完全替代主數(shù)據(jù)平臺(tái)中的共享化建設(shè)模式，即重點(diǎn)是實(shí)現(xiàn)數(shù)據(jù)的采集，集成，整合，清洗，數(shù)據(jù)服務(wù)能力開放。而對(duì)于數(shù)據(jù)創(chuàng)建變更等內(nèi)容管理仍然放在各個(gè)業(yè)務(wù)系統(tǒng)里面。
那么數(shù)據(jù)中臺(tái)在進(jìn)行數(shù)據(jù)采集整合過程中如果發(fā)現(xiàn)了數(shù)據(jù)質(zhì)量問題如何處理？
簡(jiǎn)單來說，這些數(shù)據(jù)不一致，數(shù)據(jù)不完整等問題，數(shù)據(jù)中臺(tái)僅僅是發(fā)現(xiàn)問題，而對(duì)于問題本身的修復(fù)仍然要回到源頭的業(yè)務(wù)系統(tǒng)進(jìn)行。
大數(shù)據(jù)平臺(tái)是數(shù)據(jù)中臺(tái)演進(jìn)的關(guān)鍵
大數(shù)據(jù)平臺(tái)是一個(gè)技術(shù)平臺(tái)。這個(gè)技術(shù)平臺(tái)提供了對(duì)于大數(shù)據(jù)的分布式采集，存儲(chǔ)，流處理和計(jì)算，實(shí)時(shí)分析等能力。在沒有大數(shù)據(jù)平臺(tái)前也有數(shù)據(jù)集成和管理的平臺(tái)，這種平臺(tái)可以實(shí)現(xiàn)對(duì)結(jié)構(gòu)化數(shù)據(jù)本身的采集，集成和管理。
而對(duì)于數(shù)據(jù)中臺(tái)，一般底層都需要一個(gè)提供數(shù)據(jù)存儲(chǔ)和處理能力支撐的技術(shù)平臺(tái)。這個(gè)技術(shù)平臺(tái)如果你有大數(shù)據(jù)需求，構(gòu)建出來的就是大數(shù)據(jù)平臺(tái)。但是如果你沒有大數(shù)據(jù)需求，那么用傳統(tǒng)的數(shù)據(jù)集成和管理技術(shù)平臺(tái)即可。
其次，數(shù)據(jù)中臺(tái)的范疇包括了如下幾個(gè)方面
一套底層的數(shù)據(jù)技術(shù)平臺(tái)（可以是大數(shù)據(jù)平臺(tái)，也可以是數(shù)據(jù)集成平臺(tái)）一套數(shù)據(jù)資產(chǎn)（業(yè)務(wù)層面的內(nèi)容，實(shí)際數(shù)據(jù)，數(shù)據(jù)模型，算法都裝進(jìn)來了）一套數(shù)據(jù)服務(wù)能力提供和共享一套數(shù)據(jù)管控和治理標(biāo)準(zhǔn)規(guī)范體系
因此可以看到對(duì)于數(shù)據(jù)中臺(tái)核心重要的反而是數(shù)據(jù)資產(chǎn)+數(shù)據(jù)服務(wù)能力共享這兩點(diǎn),而這兩點(diǎn)在一般的大數(shù)據(jù)平臺(tái)并不會(huì)包含。如果整個(gè)數(shù)據(jù)中臺(tái)建設(shè)有大數(shù)據(jù)平臺(tái)，那么大數(shù)據(jù)平臺(tái)也僅僅是一個(gè)底層技術(shù)平臺(tái)和技術(shù)實(shí)現(xiàn)手段。具體兩者的差異點(diǎn)我們?cè)偻ㄟ^圖來對(duì)比下。
基于客戶前面的需求，可以看到。
規(guī)劃建設(shè)數(shù)據(jù)中臺(tái)不是馬上就需要進(jìn)行大數(shù)據(jù)分析，客戶畫像等，而是優(yōu)先解決統(tǒng)一客戶數(shù)據(jù)視圖，提供數(shù)據(jù)服務(wù)能力給業(yè)務(wù)系統(tǒng)使用，即數(shù)據(jù)反哺業(yè)務(wù)。
當(dāng)數(shù)據(jù)中臺(tái)建設(shè)采用了大數(shù)據(jù)平臺(tái)這個(gè)技術(shù)底座后，那么這個(gè)技術(shù)選型具備了支撐后續(xù)大數(shù)據(jù)分析類應(yīng)用場(chǎng)景的可能。即使當(dāng)前不會(huì)用到大數(shù)據(jù)平臺(tái)中的各種技術(shù)，但是平臺(tái)建設(shè)需要考慮后續(xù)這些技術(shù)的引入沒有侵入性，也不會(huì)影響到已有的功能。
為啥不是建設(shè)大數(shù)據(jù)平臺(tái)？
前面也分析了，短期目標(biāo)實(shí)際是數(shù)據(jù)服務(wù)能力開放，為業(yè)務(wù)系統(tǒng)提供實(shí)時(shí)數(shù)據(jù)服務(wù)能力接口。數(shù)據(jù)中臺(tái)架構(gòu)里面有一個(gè)重要的數(shù)據(jù)服務(wù)能力開放層，這個(gè)在傳統(tǒng)的大數(shù)據(jù)平臺(tái)里面是沒有的，這也是構(gòu)建數(shù)據(jù)中臺(tái)的一個(gè)差異點(diǎn)。
從技術(shù)框架到內(nèi)容建設(shè)的迭代演進(jìn)
不要以為數(shù)據(jù)中臺(tái)就是幾百萬上千萬的大工程，數(shù)據(jù)中臺(tái)建設(shè)一樣需要基于垂直場(chǎng)景逐步落地實(shí)施，要有逐步演進(jìn)實(shí)施和持續(xù)迭代的規(guī)劃建設(shè)思路。
對(duì)于客戶來講想的也是先做一個(gè)小預(yù)算投入，先進(jìn)行試錯(cuò)，如果實(shí)施效果好再大面積建設(shè)和推廣，因此在規(guī)劃建設(shè)數(shù)據(jù)中臺(tái)的時(shí)候需要這個(gè)點(diǎn)也考慮進(jìn)去。
對(duì)于數(shù)據(jù)中臺(tái)的建設(shè)一般包括了三方面內(nèi)容。
底層大數(shù)據(jù)技術(shù)平臺(tái)搭建相關(guān)數(shù)據(jù)資產(chǎn)建設(shè)和內(nèi)容服務(wù)提供數(shù)據(jù)管控治理標(biāo)準(zhǔn)規(guī)范
對(duì)于技術(shù)平臺(tái)搭建，管控治理規(guī)范建設(shè)兩項(xiàng)內(nèi)容一般在第一期項(xiàng)目建設(shè)和實(shí)施中就必須完成。技術(shù)平臺(tái)建設(shè)需要考慮整個(gè)技術(shù)架構(gòu)，各種開源工具和技術(shù)的選型，本身的高可用性和可擴(kuò)展性，這個(gè)不能出現(xiàn)大的選擇錯(cuò)誤，否則后續(xù)可能導(dǎo)致整個(gè)底層技術(shù)支撐推倒重來。
對(duì)于數(shù)據(jù)治理同樣的道理，里面涉及到元數(shù)據(jù)管理，數(shù)據(jù)質(zhì)量管理，數(shù)據(jù)標(biāo)準(zhǔn)規(guī)范體系，數(shù)據(jù)安全管理，數(shù)據(jù)能力開放諸多的內(nèi)容都需要指定相應(yīng)的管理流程，標(biāo)準(zhǔn)規(guī)范體系。這個(gè)是實(shí)施各類數(shù)據(jù)主題域，數(shù)據(jù)資產(chǎn)管理的集成。
這兩部分內(nèi)容無法迭代，在第一期就需要規(guī)劃建設(shè)好。而對(duì)于數(shù)據(jù)內(nèi)容和數(shù)據(jù)資產(chǎn)管理則完成可以根據(jù)垂直業(yè)務(wù)場(chǎng)景，客戶迫切需要解決的問題來規(guī)劃建設(shè)。
比如這個(gè)客戶，前期目標(biāo)很明確，就是需要首先解決當(dāng)前客戶和用戶信息不統(tǒng)一，構(gòu)建客戶統(tǒng)一視圖的問題。那么第一期實(shí)施重點(diǎn)圍繞客戶主題域進(jìn)行即可。
從中臺(tái)技術(shù)或功能架構(gòu)到實(shí)施方法
在前面更多談的都是數(shù)據(jù)中臺(tái)整體的辦統(tǒng)招文憑功能架構(gòu)或技術(shù)架構(gòu)，但是數(shù)據(jù)中臺(tái)類項(xiàng)目不是你賣一個(gè)標(biāo)準(zhǔn)化的數(shù)據(jù)中臺(tái)產(chǎn)品，更多的反而是你如何進(jìn)行數(shù)據(jù)資產(chǎn)和數(shù)據(jù)內(nèi)容管理。
或者講搭建平臺(tái)只是第一步，更加重要的是如何進(jìn)行實(shí)施？
比如前面提到客戶一個(gè)核心目標(biāo)是構(gòu)建客戶統(tǒng)一視圖，遠(yuǎn)期目標(biāo)是構(gòu)建大數(shù)據(jù)客戶畫像和標(biāo)簽體系，那么在準(zhǔn)備售前方案的時(shí)候就需要去詳細(xì)回答這個(gè)問題。
對(duì)這個(gè)問題的回答最終應(yīng)該體現(xiàn)在整體的實(shí)施方法論上面。還是以上面這個(gè)問題出發(fā)，要構(gòu)建客戶統(tǒng)一視圖，簡(jiǎn)單來講至少應(yīng)該包括如下關(guān)鍵階段或步驟。
客戶數(shù)據(jù)管理現(xiàn)狀調(diào)研和梳理數(shù)據(jù)采集和集成=>數(shù)據(jù)貼源層數(shù)據(jù)清洗數(shù)據(jù)模型建立，數(shù)據(jù)整合數(shù)據(jù)資產(chǎn)和數(shù)據(jù)內(nèi)容管理數(shù)據(jù)服務(wù)能力開放
簡(jiǎn)單來說就是你需要詳細(xì)地說明清楚如何構(gòu)建客戶統(tǒng)一視圖，里面包括了哪些關(guān)鍵步驟，每個(gè)關(guān)鍵步驟涉及到哪些方法，哪些工具技術(shù)。不要講太多技術(shù)層面的內(nèi)容，但是整個(gè)方法流程必須要講清楚。
要講大數(shù)據(jù)用戶畫像和標(biāo)簽構(gòu)建，那么就需要將整體標(biāo)簽構(gòu)建方法涉及到的關(guān)鍵步驟說明清楚。比如上圖，標(biāo)簽體系建設(shè)包括了標(biāo)簽定義，標(biāo)簽申請(qǐng)，標(biāo)簽建立，標(biāo)簽展示，標(biāo)簽維護(hù)等多個(gè)步驟和環(huán)節(jié)，這個(gè)關(guān)鍵方法需要講清楚。
對(duì)于數(shù)據(jù)中臺(tái)建設(shè)項(xiàng)目。
技術(shù)平臺(tái)是骨，而具體構(gòu)建的內(nèi)容資產(chǎn)和服務(wù)體系才是血和肉，沒有血和肉的數(shù)據(jù)中臺(tái)是沒有靈魂的，也無法解決客戶真正的業(yè)務(wù)問題。
講述整體實(shí)施方法和內(nèi)容的核心就是要說明清楚數(shù)據(jù)中臺(tái)建設(shè)不是單純地給企業(yè)搭建一個(gè)大數(shù)據(jù)技術(shù)平臺(tái)，而是真正基于業(yè)務(wù)問題和目標(biāo)驅(qū)動(dòng)，將數(shù)據(jù)資產(chǎn)和數(shù)據(jù)內(nèi)容裝進(jìn)來，形成能夠?yàn)闃I(yè)務(wù)系統(tǒng)服務(wù)的數(shù)據(jù)服務(wù)能力，這才是數(shù)據(jù)中臺(tái)建設(shè)的價(jià)值。
業(yè)務(wù)目標(biāo)->產(chǎn)品->實(shí)施->管控治理
在我原來整理主數(shù)據(jù)平臺(tái)建設(shè)方案的時(shí)候，給出了完整的方法論，如上圖分為主數(shù)據(jù)現(xiàn)狀分析，業(yè)務(wù)解決方案，信息系統(tǒng)建設(shè)，實(shí)施方案幾個(gè)大的階段?；氐綌?shù)據(jù)中臺(tái)，基于客戶的需求和目標(biāo)如何準(zhǔn)備方案。
簡(jiǎn)單來說可以分為四個(gè)大的章節(jié)來準(zhǔn)備。
1.現(xiàn)狀分析和目標(biāo)提出
整個(gè)方案首先還是得對(duì)當(dāng)前數(shù)據(jù)管理和使用現(xiàn)狀進(jìn)行分析，基于當(dāng)前存在的一些問題給出最終的項(xiàng)目建設(shè)目標(biāo)和范圍，這個(gè)是標(biāo)準(zhǔn)套路。
基于前面的梳理，客戶對(duì)于數(shù)據(jù)中臺(tái)建設(shè)項(xiàng)目可以分為幾個(gè)關(guān)鍵的子目標(biāo)，即搭建一個(gè)技術(shù)平臺(tái)，構(gòu)建一套數(shù)據(jù)治理規(guī)范體系，同時(shí)基于客戶域進(jìn)行數(shù)據(jù)資產(chǎn)和內(nèi)容管理，這個(gè)本身又可以展開為統(tǒng)一客戶數(shù)據(jù)視圖和服務(wù)提供，客戶大數(shù)據(jù)分析和畫像兩個(gè)層面。
2.數(shù)據(jù)中臺(tái)整個(gè)架構(gòu)介紹
對(duì)于第二部分還是需要介紹清楚數(shù)據(jù)中臺(tái)整體架構(gòu)框架，注意這里不是單純的技術(shù)架構(gòu)，還需要介紹清楚技術(shù)架構(gòu)上層的數(shù)據(jù)建模，數(shù)據(jù)資產(chǎn)和內(nèi)容管理，數(shù)據(jù)服務(wù)能力開放等。
也就是說數(shù)據(jù)中臺(tái)架構(gòu)本身是分層的，需要說明清楚整體分層邏輯。
3.數(shù)據(jù)中臺(tái)實(shí)施方法論和實(shí)施策略
注意這里不是簡(jiǎn)單的講解標(biāo)準(zhǔn)的實(shí)施方法論，基于客戶的需求和目標(biāo)，最好是在這部分詳細(xì)說明清楚基于數(shù)據(jù)中臺(tái)當(dāng)前產(chǎn)品的功能架構(gòu)和組件，如何基于客戶業(yè)務(wù)系統(tǒng)和數(shù)據(jù)現(xiàn)狀，來完成統(tǒng)一的客戶統(tǒng)一視圖溝通，數(shù)據(jù)服務(wù)能力的開放，如何實(shí)現(xiàn)客戶信息的大數(shù)據(jù)畫像。
什么意思？
前面數(shù)據(jù)中臺(tái)架構(gòu)是一種靜態(tài)架構(gòu)，現(xiàn)在基于客戶提出的需求和目標(biāo)，你需要去回答如何基于你已有的功能架構(gòu)組件，工具和技術(shù)，來一步步完成最終客戶的業(yè)務(wù)目標(biāo)。
即真正回答清楚數(shù)據(jù)中臺(tái)中的內(nèi)容和資產(chǎn)是如何一步步建設(shè)出來的。
4.數(shù)據(jù)管控治理體系
這部分是必須交待的內(nèi)容，即不僅僅是幫客戶構(gòu)建一個(gè)平臺(tái)，完成了一個(gè)數(shù)據(jù)資產(chǎn)或內(nèi)容的建設(shè)，更加重要的是幫助客戶建立一天覆蓋數(shù)據(jù)全生命周期的管控治理規(guī)范體系，這才是真正的知識(shí)轉(zhuǎn)移和資產(chǎn)沉淀。
數(shù)據(jù)管控治理剛好體現(xiàn)了自身多年經(jīng)驗(yàn)積累，最佳實(shí)踐的沉淀。
5.項(xiàng)目管理范疇
當(dāng)然，還可以對(duì)項(xiàng)目管理范疇內(nèi)容進(jìn)一步細(xì)化。包括對(duì)整個(gè)項(xiàng)目工作量和費(fèi)用的預(yù)估，項(xiàng)目執(zhí)行周期的預(yù)估，是否需要分迭代版本的規(guī)劃，具體項(xiàng)目參與人員，項(xiàng)目組織架構(gòu)，項(xiàng)目交付物清單等的說明。
聯(lián)系客服
