top of page

數據化營運困境

Updated: Apr 28

筆者是其中一位最早提倡數據「中台概念」的人,這緣於一段很特別的經歷。當時我在支付寶的數據產品建設略有成績,老闆再三考慮下,把我調到淘寶解決數據體系支離破碎的問題。在淘寶上任後,我觀察到3件事:一、各個部門的數據分析團隊水準參差;二、數據平台疲於奔命地接收重複的數據需求;三、業務部覺得數據分析出來的結果品質低,幫助不大;同時,數據分析師認為業務部不重視分析,紛紛離職。

最讓我頭痛的是,當時各部門互相指摘,不滿對方,導致士氣低落。今天你或難以想像,5年前淘寶也曾經有過這樣的狼狽經歷。當然對於一些還未開始使用數據化運營的企業來說,這可能是個happy problem。

深入研究之下,數據化營運的困境可用「堵、獨、慢、漏」4個字來形容。

堵:日常數據訊息量大,難以捕捉有效資訊。 獨:資訊分散在不同部門,缺少有效整合。 慢:發現業務異動時已嚴重滯後。 漏:分析各師各法,缺乏沉澱。

我們認為,公司內應有人要為解決這些問題負責任,並且以系統化和技術化的方式實現改變,由於這個平台面對的是業務部,但背靠着多個數據及技術資源單位,所以順理成章被叫作中台。然而,這不代表中台要負責解決所有問題,當中有幾個環節極需要協同處理,例如數據收集時的標準、跨部門的數據資源分享、共用前後的數據安全風險保護、數據品質保證等,較少人關注的是思想的轉變,要讓大家明白並接受「共創共用」此一互聯網精神精粹,並不是一件容易的事情。

數據中台的核心是如何讓數據從生產到被使用的過程中提升效率。對於數據滙聚,傳統上有個假設,認為數據放在一起更有利找出價值;隨着社會對個人私隱及數據洩漏事件的關注,中台的核心功能出現重大變化,我們再不能假設數據必須要放在同一個平台上,而是讓數據資源聯網按需使用,同時利用加密及區塊鏈等技術作監督。新一代的數據中台有更大責任,讓數據合規合理地被使用,物聯網的發展也在賦予中台不一樣的要求,更零散的數據、更即時的需求正在不斷改寫中台的定義。

Recent Posts

See All
AI預算黑洞 根源在架構設計

過去兩年。美國眾企業不約而同墮入一個速成陷阱: 認為購買了一個模型、聘請幾位演算法工程師、便能成功實現人工智能 (AI) 落地。然而,即使模型選擇正確數據卻 難以整合;數據成功整合,系統卻無法運行;系統成功運行,但業務部門不會操作;即使學會操作,3個月後模型又變得過時。 問題根源其實不在模型,而在架構。猶如建造大樓,若設計圖存在缺陷,再昂貴的材料也難以支撐。許多企業投入巨資購買「鋼筋水泥」(模型和

 
 
智能代理編程戰 懂人機協作致勝

上周把兩個消息放在一起看,很有意思。 第一個,Anthropic宣布Claude Code推出Artifacts,讓軟件工程師在寫程式的過程中,業務主管能同時打開網頁儀表板,就能看到軟件即時更新及開發的狀態。 第二個,中國人民大學和微軟亞洲研究院聯合推出一個叫Arbor開源自主人工智能體的新框架,系統能自動提出假設、修改代碼,運行真實實驗並從結果中學習,自動優化解決問題。 過去一年大家比併的是模型

 
 
集結舊手機算力 媲美當今伺服器

你可曾想過,你抽屜裏那部4年前的舊手機,可能很有價值? 這個星期,Google Research聯同加州大學聖地牙哥分校(UCSD)公布一項創新計劃:運用2000部退役的Pixel手機,構建一個真實可用的雲端計算平台。這不僅是概念驗證,更是一個供數百名學者與研究人員實際操作的生產級環境。處理方式十分直接,將舊手機的熒幕、電池、外殼全部移除,僅保留主機板,透過Kubernetes技術組成叢集,直接轉

 
 
bottom of page