中台沒有嚴格的規範，所以對於許多組織來說，很難有標準的管理和監控機制，但儘管沒有硬性規定，組織還是可以從約定邊界開始，劃分模塊以及通過建立一些指標來管理每個模塊。我們認為數據中台的成熟度評估應該從文中的七個維度入手。

自從阿里提出了「大中台，小前台」的概念後，一場組織變革席捲了國內許多公司，這其中不僅僅包括網際網路公司，還有傳統行業，如金融、電信、零售、物流、製造業等。

從2018以來，「數據中台」成為行業頭部企業普惠至更多的中小企業，成為數據應用的「基礎設施」。未來每個企業都會標配自己的「數據中台」，為企業數據化轉型和創新奠定堅實基礎。

數據中台，是通過獲取各類數據，對數據進行分析和挖掘，產出結果和洞察，提供給業務和決策者使用，進而打造創新產品和服務，優化管理推動組織數字化轉型。「讓數據用起來」，是數據中台終極目標，也是數據中台要為處於不同數據認知成熟度階段的企業實現一個個具體的目標。企業在業務的快速發展、信息化越來越高前提下追求自身的價值，業務部門不停的提出新的需求和挑戰，給普惠數據服務提出了數據服務的按需提供、業務流程化、數據自我治理、統一數據服務、智能化數據運營等特點。

隨著近2年來數據中台在很多企業雨後春筍般的落地，很多企業不知道自己的數據中台到底建設得怎麼樣了？

最近頻繁聽到一些企業所服務的部門級負責人提出這樣的困惑：

數據中台建設一年多了，我們投入了很多資源，做了很多東西，規模也擴張了不少，也有一些產出，但這些結果到底怎樣呢？

我如何知道這些結果是好還是不好？接下來我該如何調整？

我如何根據現在數據中台建設的情況來進行下一年的規劃呢？

也就是說，現實中，他們需要一個數據中台的成熟度評估，來對中台的建設做一個全面的體檢，這既是一次結果的盤點，也是為未來的規劃提供輸入。

近期和同事一起做數據中台成熟度的研究分析，也對服務過的組織做過調研和評估，我們認為數據中台的成熟度評估應該從以下七個維度入手。

（圖1 數據中台成熟度模型）

01 數據戰略

數據中台的建設通常不是無緣無故發生的，也不是追求「時尚」的產物，在中台建設的行動之上和活動之初必然有個數據戰略，這個戰略可能是在建設過程中逐漸被清晰化的，也可能只是在小部分成員（通常是負責人）之間共享，更有可能只出現在ppt或者口頭表達里，它可能是公司級別的戰略，也可能只是部門級別的戰略，但這個戰略很重要，它就如同一家組織的願景和目標，是指導行動的燈塔，沒有它，組織的決策可能會具有隨機性，導致資源利用不集中、行動效率低、重複建設等現象發生。

有了數據戰略，還需要確認組織（或者部門團隊）對戰略的理解是否一致，如果理解不一致，數據戰略可能只存在口號或者爭論里，落地的結果不盡人意或者沒有結果產出。

如何保證有清晰明確的數據戰略，並且這個戰略能被統一認識和理解呢？答案是需要一個管理組織，這個組織可能只以虛擬的形式存在，但是管理得當的話，它可以保證戰略目標能被有效的分解，並且能在部門和團隊之間得到拉通落地。

與管理組織配套的還需要一些制度建設，比如保證戰略落地的流程，如何處理衝突、不一致，決策流程是怎樣的？戰略（和行動）的調整和優化機制是什麼？

總結一下，數據中台建設的前提是數據戰略的清晰和明確化，評估一個組織有沒有數據戰略的關注點是：數據戰略是什麼以及是否一致，管理組織的成立和運作，制度建設的配套和保障等。

02 數據治理

並不是所有的組織都會組建單獨做數據治理的團隊，但數據治理的工作卻必須有。有很多組織的原則是「先建設，後治理」，也就是說先把中台的架構搭建起來，循序漸進完善各個功能模塊，在這個過程中，絕大多數組織會選擇先建設和用戶（業務或者業務IT）強相關的功能模塊，過一段時間再回頭計劃數據治理的工作。但建設功能和數據治理的時間間隔通常不會太久，通常來講會在半年到一年以內，否則組織會發現，功能建設的工作難以為繼，治理的難度也會隨著時間的推移逐步增加。

評估數據治理的時候，也需要關注一些點：

• 比如，元數據相關的，有沒有做元數據管理和怎麼來做的元數據管理，是否有元數據分類，技術和業務元數據的管理，有沒有完善的元數據管理體系，是自動管理還是手動管理，維護機制是怎樣的？

• 比如，數據字典相關的，是否有相應的管理和維護機制，字典包括什麼內容，數據字典的變更、權限審批流程是怎樣的，是否和業務系統保持同步等？

• 比如，數據模型相關的，數據建模的方式、標準方法和流程是怎樣的，按照哪種方式來建模，模型的自適應能力怎樣，是否有統一的建模工具，維護、優化和變更流程是怎樣的？

• 比如，數據質量相關的，是否有做數據質量管理，是否有質量的評分模型、監控流程和評估流程，是否有完善的反饋、變更和處理機制，質量是否和考評指標聯繫等等？

• 比如，數據標準相關的，是否有數據標準體系，是否有源系統和目標系統的數據標準映射邏輯關係，是否有反饋、變更、處理機制等等？

• 比如，數據安全相關的，是否建立數據安全管理機制和定義安全分級分類標準，是否有適當的數據安全控制及措施，是否有數據隱私保護等相關活動及維護數據安全的工具，是否有完善的數據訪問權限和回收策略，是否有脫敏機制和策略等？

• 比如，數據生命周期相關，數據生命周期的體系規劃和落地機制是怎樣的？是否有獲取與存檔方案，是否有備份和恢復計劃以及數據銷毀方案，是否有保留與歸檔的日常活動以及歸檔數據的檢索與使用策略？

總的來說，當數據量多並且複雜到一定程度，數據治理的工作如果不能成為中台建設的重點，就極有可能成為中台建設的瓶頸。

03 數據資產管理

數據資產管理也是數據中台必須建設的功能模塊，正如其名字所詮釋的那樣，把數據當成資產，建設好了給組織帶來價值增值，建設不好則給組織帶來資產流失或貶值。

評估數據資產管理的時候，需要關注中台的這樣一些點：

• 有沒有數據資產審核能力，也就是對數據資產的註冊申請進行審批，保證數據資產能被合規註冊和發布的能力；

• 有沒有數據資產發布能力，指的是將審批通過的數據發布到數據資產地圖，供數據消費者查詢使用；

• 有沒有數據資產標籤，比如客戶的特徵標籤、關鍵業務的指標標籤等，以便使用者通過標籤組合來消費數據；

• 有沒有數據資產地圖，指的是通過地圖或者目錄的形式，提供數據資產的查詢功能，實現數據資產的「可視化」；

• 有沒有數據資產的開放能力，通過接口的方式，數據資產被開放給內外部的用戶，實現數據資產「增值」；

• 有沒有數據資產盤點能力，如同組織盤點自己的動產和不動產一樣，數據既然已經被當做資產，也需要周期定期不定期甚至實時進行盤點，盤點成果將會被導入到數據資產運營平台進行管理；

• 有沒有數據資產定價，圍繞數據的不同價值模型，比如業務價值，成本價值，市場價值等，按照不同的權重配比對數據資產的價值進行評估定價；

• 有沒有數據效益評估，根據數據資產產出的價值，來數據資產的價值進行評估。

根據現實經驗，上面的所有項可以不是同期同步發生的，許多組織的數據資產管理只是覆蓋了以上幾項，但中台仍然能「負重」運作，也正是如此，數據資產管理的成熟度評估才顯得尤為重要，因為只有認識到數據資產管理的全貌，才有利於設置正確的建設路徑。

04 數據平台和架構

數據平台和架構是在全域的數據基礎之上，設計出易用的、穩定的、可擴展的、支持多應用的平台架構，此外，進行數據分層建模和標準定義，最終呈現出一套完整的、規範的、準確的數據架構和應用的解決方案，可以方便支撐數據應用。所以數據平台和架構主要關注如下：

首先要關注的就是架構標準，有沒有架構選擇的流程，比如同業調研，選型，POC以及決策機制，是否有專門的架構組來保證流程和機制的落實，是否有部門內部和部門之間的架構評審流程和機制等等；

其次，架構方法也至關重要，比如架構規劃、整體架構、基礎架構、數據架構、功能架構和部署架構的設計原則是什麼，有沒有標準的架構實施規範，有沒有評估機制，是否有調整、優化和改進機制等等；

再次，數據是怎樣集成的，有無數據整合架構政策和標準，數據集成的流程和標準是什麼，包括內外部數據集成、離線和實時數據的集成方案等，是否有自動化的數據集成工具或平台，集成過程中是否有異常處理、回滾等操作；

整體來說，這部分既需要整體規劃又需要對細節進行考慮，不僅僅是部門內部的工作，還涉及跨部門的協作機制，是非常具有技術含量的一個模塊。

05 數據服務化

數據服務化是指數據中台以什麼樣的方式向外提供服務，而能直接使用這些服務的人通常不是業務人員，卻極有可能是業務應用的IT人員，業務通過調用配置好且已開放的服務（比如API）來為業務快速開發滿足某一需求的功能。

數據服務化的背後也通常會有一個服務平台在支撐，所以在做中台服務化評估的時候既要關注服務平台又要關注服務本身。

比如，服務標準的確立，指的是有沒有明確的服務目標，以什麼樣的方式提供服務，提供服務的流程和優先級是怎樣的，和業務IT 的協作機制是怎樣的？

另外就是服務監控和維護，在平台之上以什麼樣的方式監控數據服務，有無量化的標準來評估數據服務，數據服務維護的流程和機制是啥？

還有服務結果分析，有沒有對服務結果進行分析的機制，結果的讀取和分析是否同步，分析結果是否發布、發布給誰、以怎樣的方式發布？

最後還要關注數據服務的評估和優化，中台提供數據服務是否被評估，按照什麼維度進行評估，評估的流程和機制是怎樣的，評估的結果是否會用來指導數據服務化的優化和改進？

在對數據服務化這一維度進行評估的時候，通常既需要關注功能（技術）實現，又需要關注治理，因為規範成熟的治理機制是中台持續不斷對外提供「優質」服務的保障。

06 數據產品化

有的組織會把產品化和服務化放在一起，因為這兩部分都是比較靠近前端數據消費者的，因為無論是產品化還是服務化，對整個中台來講，它們都是數據產品。

略微不同的是，數據產品化的結果，有相當一部分是可以直接被業務使用的，比如報表的分析服務（產品），業務人員可以直接通過托拉拽的方式在平台配置自己所需的報表以及展示方式。

這一維度所要關注的目標就和戰略方向特別靠近，比如：

• 業務支撐能力：數據產品化（或者數據產品平台）支撐什麼樣的業務功能，有無功能選擇的標準，所能支撐的業務是否能反映戰略的方向或戰略的執行情況，功能支撐能力是不是能被周期性評估和優化；

• 業務分析響應能力：響應機制是啥，業務功能使用的響應能否做到實時（T+N），產品平台功能開發的響應機制是啥（如果提出一個功能開發需求，多久可以上線），有無對底層數據整合平台的依賴；

• 數據可視化能力：是否支持業務友好的使用方式，比如指標和數據維度的托拉拽，是否支持數據挖掘和分析結果的呈現，是否有自定義圖表的呈現，是否集成第三方分析呈現工具；

• 統一服務的能力：是否能將業務需求沉澱成統一服務的能力從而能夠服務於更多業務團隊，沉澱的原則是什麼，是否實現跨集市引用的沉澱，等等。

數據產品化是比較靠近業務，也比較容易被業務感知到的一個模塊，這塊的設計和開發應該借鑑產品開發的思路，既需要考慮功能、業務反饋，還需要關注運營指標。

07 中台運營

指的是將整個數據中台作為一個產品來看，是否有運營的指標和控制機制。

• 比如，是否有中台管理平台，類似於整個中台管理的入口，所有通用文檔、規範、標準、流程的管理，都能夠列出來並且能被方便的查找，對各個平台運營指標的監控和分析進行區別性的展示；

• 比如，存儲成本、計算成本和研發成本的管理和分析，有沒有這些成本的投入計劃，估算原則和成本分析；

• 比如，是否有中台內部各模塊之間的整合與協作機制，架構的設計、職責和工作內容是否清晰，互相調用和協作機制是否完善，功能模塊間的資源分配是否均衡

• 比如，在價值層面是否具有良好的用戶體驗和較高的用戶滿意度；

• 比如，在資產的管理方面，是否能反映數據或服務被調用的頻率或次數，等等。

總之，中台運營評估的是中台作為一款「產品」，它是否能為組織提效降本，是否能為業務帶來價值增值。

以上便是對數據中台進行成熟度評估所建議採用的維度，但鑒於業界沒有一個對數據中台的標準定義，在實際操作過程中，還需要根據組織和部門的特點以及結構組成、業務的場景、落地執行的情況來做調整，還有一個情況是，並不是所有的組織裡面都能找到劃分清晰的 7 塊，這個時候需要做的就是對維度進行合併或者拆分，總的來說，數據中台成熟度的評估既可以反映組織結構（主要指數據部門或者中台部門）是否合理，又不能完全脫離現有的結構進行設計和評估。

有了對數據中台各個維度的定義，接下里要做的就是對於每個維度下每個評估項進行打分，最後的產出會是量化的一些維度評估數字，有了這個評估結果，組織可以設置一些改進目標，同樣，改進目標也是可以通過這個模型進行量化展示的，所以最後可以得出類似以下這樣一個評估結果和改進結果的展示：

（圖2 數據中台成熟度評估示例）

總結

中台沒有嚴格的規範，所以對於許多組織來說，很難有標準的管理和監控機制，但儘管沒有硬性規定，組織還是可以從約定邊界開始，劃分模塊以及通過建立一些指標來管理每個模塊。

此外，中台也是跟著組織變化的，組織不一樣，最終的架構設計也會不一樣，但是中台建設的關鍵是服務化和標準化，如果能夠做到內部服務足夠敏捷，加上配套的機制，比如規範、運營指標和考核機制，中台的建設會自己疊代和發展。

• 基於 Apache Flink 的實時監控告警系統

• 日誌收集Agent，陰暗潮濕的地底世界

• 2020 繼續踏踏實實的做好自己

你點的每個贊，我都認真當成了喜歡