引言

企業建設過數據中臺，還有必要做數據治理嗎？

企業做過領導駕駛艙，還需要做數據治理嗎？

企業做過生產管控、質量管控等，也有需要做數據治理嗎？

企業數據中臺項目中包括了數據管理，為什么還要做數據治理呢？

企業建了數據中臺，就等于企業具備數據管理及服務能力嗎？

……

【當下痛點】“慢、難、不準”

在數據要素背景下，大部分的企業數字化轉型選擇了基于數據驅動業務增長的路徑，建設了數據中臺項目。這類項目以面向業務部門的看板指標設計為主，基于平臺進行數據采集-數據倉庫加工-看板開發的工作落地。把數據中臺更多的建設成了一個數據鏈路的采集處理的技術平臺，是大部分企業的建設現狀，雖然有數據質量、數據標準、數據安全、數據目錄等諸多模塊，但是可能并沒有實質性的實施內容。往往還面臨如下痛點：

01、響應慢：業務部門提出看板需求，數據部門無法快速響應，從采集數據到看板開發完成往往需要1周~1個月，不能及時滿足業務端的“看數”需求；

02、運維難：數據管理部門/數據應用開發部門運維壓力大，工業企業主價值鏈看板往往后臺有四五千~上萬個調度運行的任務，通常在看板上出不來數據的情況下開始排查，問題難定位、影響范圍不確定，千絲萬縷，不敢動；

03、不準確：業務部門對看板應用存在兩種極端，一是不用、沒問題，月度訪問量個位數，日常業務工作的開展不使用看板；二是用的多、抱怨多，看板信息不準確，但不知道怎么不準確，無從下手。

【根本原因】“與其解析SQL，不如重寫一段”

企業數字化轉型建設初期選擇“以應用為牽引的數據管理”建設路徑開展工作，這是聚焦業務價值開展數據管理的正確路徑。在這種情況下，建設重點更對放在業務部門相關的管控場景、公司領導相關的駕駛艙場景下的指標體系設計及看板開發，以期激發業務人員對于“用數”的積極性和認同度。

該類項目的建設工作內容中，往往存在以下問題：

01、數據采集欠缺規范及復用性考慮，往往做一個指標從源頭采一次數，造成了多次采集、接口的重復開發；

02、數據加工多采用SQL，四五百行的SQL是運維工作的現實阻礙，與其解析SQL，不如重新寫一段是大部分的運維現狀；復合指標導致的調度編排關系錯綜復雜，影響范圍不可控也未知；

03、數據倉庫分層及模型規范執行不到位，規劃是“超市的貨架”，現實是“菜市場的攤位”。

【如何解決】“從數據倉庫到數據超市”

伴隨著“應用牽引式”的數據工作建設，企業逐步認識到數據工作不僅僅是建看板應用，數據標準、數據質量、元數據管理等數據治理工作同樣重要，所以這些年建了數據中臺的企業，還在做數據治理，甚至做數據治理的迫切程度更高。

數據部門如何從疲憊的數據運維工作中解脫出來，需要依賴：

01、數據標準：統一的數據標準，形成對數據的統一認識，是端到端業務流程貫通的前提，是多個業務視角打通分析報告的前提；

02、數據規范：提數據應用需求需要遵循提需求的規范、做數據采集需要遵循采集的規范、建倉庫模型需要遵循模型設計的規范、配調度編排需要遵循編排的規范、開發可視化看板需要遵循看板取數的規范，這是可追溯、能復用的前提；

03、數據服務：數據管理/數據應用開發部門如何從提供數據加工結果轉向提供數據服務，除了數據倉庫規范化的完善與重構，還要注重必要的數據角色以及數據工作分工的模式建設。

那么，作為數據管理部門應該如何統籌分析應用、數據標準、數據目錄、元數據以及數據倉庫、數據服務這些數據管理職能域的實際工作，以什么為抓手做好從“提供結果到提供服務”的轉型呢？下回見嘍 ~  ~