楊哲軒:結合實際案例說說,如何在零售行業實施主資料治理?
責編 | 韓楠
約 5753 字 | 12 分鐘閱讀
以下,Enjoy~
你好,今天我想跟你聊聊如何選擇主資料管理方案。過往我分享過 一篇文章 , 裡面我介紹了資料孤島形成的原因,簡單地介紹了主資料管理的概念和主資料管理為何能幫到。
當然, 理念的東西 畢竟 是抽象的,從實用角度而言 可能 是無用的。這一篇文章將會從一個具體的案例 , 來談一 談 主資料管理在一個企業是如何落地 , 並幫助企業更好 地 把資料當作生產要素來支撐業務發展的案例。
資料孤島的形成是有其必然性的。 企業的歷史也是業務系統 資訊化/數字化的歷史。 當年 任正非 力排眾議, 邀請 IBM 為華為內部 做流程化改造。 一舉奠定了現在仍在發揮重要作用的 IPD 流程,這也是華為引以為傲的競爭力。 企業的成長,和孩子的成長是一樣的。 原本合身的上衣和褲子,也會發展過程中,慢慢變得不 合 適 ,不再適用當前的發展狀態。
但 也 有不太一樣的地方,業務系統跟衣服不一樣,它們無法丟棄。
這些業 務系統或者 IT 系統,可能還在企業的關鍵業務系統中,扮演或關鍵或重要的角色。 需要在飛馳的過程中,將這些歷史系統逐步現代化,甚至有一些系統還不得不持續維護。
我們今天介紹的這家,在 大陸以及 港澳臺皆有珠寶零售業務的頭部企業 , 也是沿著這個發展模式和脈絡 , 逐漸 地 在自己企業內部形成了資料孤島,從而導致了在應對移動網際網路上的吃力 ,還 持續 性地對業務 造成了傷害。
作為國內珠寶零售行業的領頭羊,其在 大陸以及 港 澳 臺累計門店數接近 1000 家,其中大陸門店數佔 70% 左右,8 個旗艦系列、7 個 國際品牌,累積系列品牌總數為 27 個。
提起珠寶,大家可能腦子裡浮現的第一個詞是“貴”。這一特點,也將珠寶零售行業區別於其他以快銷為特點的日用品零售行業。珠 寶零售行業從生產製造到最終的交易發生,大致可以分為:
• 研發設計
• 生產製造
• 供應鏈/庫存管理
• 銷售管理
• 售後管理
相較於快消品而言,珠寶零售行業的庫存週轉相對較慢,所以每一次銷售機會都顯 得格 外珍貴。使用者在門店開始選購珠寶時,考慮主要是三個方面,分別是價格 、 款式 、 尺寸,這些主要是 跟 庫存管理有關係。
這就要求門店的營業員能夠直接檢視本區域 、 跨區域的珠寶庫存情況,在顧客已經選擇某個特定的款式,預算充分的情況下,透過“調貨”的方式 , 來完成本門店沒有庫存情況下的銷售過程。
今天我們探討的珠寶零售公司,在 它 的發展歷史過程中分別在中國大陸、台灣、中國香港、中國澳門等地 , 建設了 多 套不 同 的供應鏈 管理、庫存管理和銷售管理的系統。
多 套不同的系統,聽起來 是不是 有點多 , 且不必要 ? 但在這家公司漫長的資訊化 和 數字化旅程中,這些系統都是為了回應在不同區域更快速 地 開展業務的需求而建設完成 的 。 或許一個事物的 發展 多半總 是在荊棘中前進 的 , 很少 一帆風順, 更 不會按照腦海中 所預想的 完美路線圖 推進 ,一切都是權衡的結果。
01 ⎪ 煙囪式開發,資料分散,取數難
由於企業 IT 發展了幾十年,陸陸續續採購了不少的獨立 IT 系統,例如:ERP、CRM、SCM 等,往往一件貨品資訊散落在不同的資料庫中,想要一份完整的資料,對研發團隊來說可能需要 花 大量時間去了解、溝通資料結構,再做資料清洗、加工。整個研發週期就會被拉 得 很長,對於想要快速獲取一些資料 , 就會顯得非常困難。
同時,多套異構資料庫對運維團隊的技術能力,也是一個不小的考驗。
• 二次開發難。
有那麼多套不同產商的業務系統,能夠弄明白系統之間關係的人越來越少了,更別說在已有系統上做一些二次開發,這對技術人員的業務要求相當高。
• 跨部門協作,組織協調難。
業務越來越多,自然就會成立不同的部門去維護,而一旦需要跨部門協作開發時,組織架構的複雜性,直接延長了開發週期和專案上線時間。
02 ⎪ 割裂的商品中心,難以形成合力
不同的地域都部署了相同的組合“服務和資料庫”的組合模式,這也為後續的資料孤島埋下伏筆。隨著數字化程式的深入,這些割裂的系統讓不同區域的商品資料是無法流轉和查詢 的 ,同時還會造成冗餘的庫存資訊, 最大的問題實際上是在業務側 : 不同的業務條線有不同的業務人員,他們作為資料消費者,在現有的架構下是沒法及時消 費到資料的,換句話說 訂單的狀態抵達相關業務人員的時間,會被大幅度延長。
這種難以消費資料的原因是, 資料割裂。資料割裂這一概念本身可能過於抽象。
我們從資料割裂造成的實際問題來談一談。
作為一家頭部的珠寶零售公司, 它 的商品 sku 大概有 100 多萬,分別散落在不同的資料庫表和資料庫中,且字典表難以理解 , 業務對映表關係複雜,業務研發不得不花費大量時間在內部的溝通上。
即使溝通也不一定能解決全部問題,還需要透過資料庫的跨例項查詢(dblink)解決資料割裂的問題。因為超過 1.5 億庫存訂單存放在 多 個 Oracle 和分佈在 20 張表中的 10 萬商品資訊,整個運維團隊和業務團隊 , 需要花費很多的精力解決:
• 訂單狀態跨地域維護。
• 資料在多個資料庫之間的同步導致的延時。
• 訂單邏輯複雜,不易擴充套件。
當一位中國香港門店店員想要在香港查一件貨,透過系統查詢得知這件貨不在香港,在澳門。一般而言 , 店員可以透過系統去做“調貨”動作,最後完成交易。
但因為一些 IT 歷史原因,這家珠寶零售公司的門店店員 , 必須透過系統將澳門的貨轉到香港後,才可以查詢該貨明細,而這個轉貨的過程需要花費數小時 來 等待。客戶的購買時間 , 往往也就在關鍵的幾個小時以內。 如果 這樣的 等待經常發生 , 這 對營業額會產生 較大 的 衝擊。
03 ⎪ 促銷活動難以按時按需開展
移動網際網路對於零售業改造是全方位的,珠寶行業也不例外。
傳統的“人貨場”概念被拓寬到了線上,一些交易活動也不再侷限線上下零售店內。為了適應消費者購買習慣發生的變化,珠寶零售行業一方面需要融入到淘寶、京東等這些線上零售平臺已有的活動中,同時也需要根據節假日及時開展適當的營銷活動,增加銷售收入。
這裡就出現了供給側和需求側的矛盾:“業務以為的研發週期” 和 “工程師能提供的研發週期” , 可能是存在不匹配情況的。
在雙十一來臨之際,業務團隊根據當前市場情況及政策規定,提出了一系列促銷活動方案,工程師團隊在收到十幾個需求時,開始拒絕,因為 不 可能在短時間內全都滿足。
當然 現實 情況 會更加複雜, 工程師團隊透過加班加點的工作滿足了 業務的需求,但這種衝刺式的努力不可持續, 需要組織中的關鍵角色 , 對現有的 IT 藍圖進行復盤和盤點,制定出合適的升級路線。
04 ⎪ 網際網路+,重造數字化中的自己
雖然是一家傳統的零售企業,但企業文化使得他們不斷精益求精,希望透過結合網際網路電商、社交、媒體等線上平臺,為企業帶來新一輪的增長。
在過去的 3 年中,全國數百家門店,年均舉辦了超過上萬場線上線下活動,更是在某年雙十一珠寶銷售榜中 取得了位居第二的好成績。
但問題也越來越明顯,落後的歷史系統已經嚴重 地 掣肘了業務的發展。此時對於這家傳統企業來說,已經無法透過“頭痛醫頭,腳痛醫腳”的方式來打補丁 進行區域性的調整。
“新一代資料架構”的訴求應運而生, 企業需要透過這樣的資料平臺 , 來幫助他們解決由來已久的問題,從根本上解決因“資料孤島”問題引發的一系列技術和業務問題:
• 資料模型線性增長,關係型資料結構越來越複雜,修改欄位時,就像在電源插座上找唯一能用的插位。
• 20年前的 IT 架構結構複雜,大量儲存過程,學習週期慢,改動困難。
• 研發速度跟不上需求變化 。
• 需要一個高效的資料開發服務平臺,支撐企業內部敏捷開發和 DevOps。
• 重複建設使用者資料、訂單資料,統一資料困難。
經過層層篩選,公司決策,最終形成: “連線資料孤島,融合資料,形成主資料” 的決策,用主資料管理和資料治理 , 來解決資料孤島的問題, 更好地支撐業務,提升業務執行效率。
05 ⎪ 工欲善其事,必先利其器
Gartnter 在《 成功實施主資料管理的 7 個步驟 》 [ 1 ] 中指出,在企業中實現一個主資料管理(MDM)策略大致需要 7 步:
• 確定願景、戰略和利益相關者
• 發展過程
• 選擇衡量標準
• 建立一個績效基線
• 商討目標改進
• 將目標改進轉化為財務結果
• 建立所有權總成本模型
• 計算投資回報率
這 7 步背後的本質邏輯是 什麼呢? 較大的組織會選出一組人(當然這些人是組織裡有深厚影響力的),建立和執行資料質量標準,並以此 為基礎建立持續迭代並形成最佳 實踐。 資料孤島的打通 和資料治 理的實施,貫穿整個組織,伴隨組織權力的調整,或者是根據已有的權力結構 進行本地化的改造。
換句話說,透過務虛會、頭腦風暴會、問題分析會,在利益相關者中形成對於資料治理的共識,確定里程碑和衡量成功的標準,最後透過財務數字證明“資料治理”這項行動是有效的,切實地提升了公司運營效率。
為 了 使主資料管理發揮作用,它必須是 一個團體的努力且是一個持續的努力 。
一般對於資料治理專案的理解都是一種變革管理,需要引導組織透過調研、整理、歸納等工作,對現有流程進行梳理和分析。 當然還會有創造性的活動,制定新的流程。
主資料管理和資料治理一直以來飽受詬病的,便是落地難。 選擇一個趁手的主資料開發平臺,也是專案成功的關鍵。
把資料治理或主資料管理等圍繞資料的方法論,落實到企業的生產、執行和支撐的全過程中。 對於這樣的一把兵器,它是有一些畫像的:
資料發現和連線 。 發現和連線功能利用演算法,即時識別資料的重複,並幫助解決多個條目成為一個單一和準確的記錄。主資料管理軟體有助於消除資料重複,將正確的資訊輸入所有的系統,監測資料來源的完整性,並將一些本來被認為是額外需要資源的任務自動化。
這 是 保障來自於孤島的資料和主資料完整性的重要能力 。 缺少了 該項能力 ,主資料便失去了 其本身的 意義,不能 夠再 成為企業的共享資料 ,更關鍵的是不再能支援一個關鍵、完整的業務流程 。
資料整合能力 。 在一個集中的資料來源中建立、維護和分發主資料,並在企業的各種不同業務中延伸。它確保資料的一致性,隨時隨地,標準化的定義和業務規則,強制執行驗證值,並監測完整的審計跟蹤的變化。這是對資料按需進行修改的關鍵能力,能對資料進行合理變形,達成業務部門所需要的資料樣式。
這一能力從最終使用者的角度而言,還意味著極致易用性。透過前端頁面和拖拉拽操作掩蓋掉資料整合操作的複雜度,將操作面和管控面進行分離,使得企業內部使用者 在 資料 整合過程視覺化,如拖放、顯示變化、最佳記錄審查和匹配審查。
大批次資料處理能力 。 主資料管理軟體的大規模處理功能 , 可執行有益的大規模更改過程,使主資料使用者能夠對業務夥伴、客戶、供應商和產品資料範圍 , 進行批次更改和修改。它使一個有效的過程來執行屬性的大規模變化。
流式資料處理能力 。 和資料整合能力一道,幫助企業實時的獲取、過濾、加工資料,儘可能 地 保障主資料的完整和一致。
資料共享能力 。 主資料管理軟體使業務規則 , 可以在不同的使用情況下共享。一些從業者會將資料共享性稱為資料虛擬化或者資料及服務,這並不衝突。
例如,在進行資料匯入或審批過程中,業務規則可以在不同的使用案例中共享。這些控制必須是集中式的,只需改變一次就能在所有地方生效。業務規則必須在使用者介面上實現,而不需要等待後臺開發。
這五個基本關鍵能力 是評分表中的五個象限,可依據評分的大小繪製雷達圖,在 選擇兵器時需要重點考察 , 根據企業當前的現狀 , 合理選擇主資料管理的軟體產品 。 如果 進一步提煉, 主資料管理的過程 以抽象為: 連線、融合、釋出 這 3 個階段,透過廣泛的連線性,將業務資料庫資料以 低程式碼拖拉拽 的方式構建資料鏈路,形成 資料映象層 。
接著,在平臺中完成 建模開發 形成主資料模型層(MDM),主資料模型層(MDM)將會成為之後各業務系統所需資料的核心資料層。
為此我們和客戶一道,結合珠寶零售行業的實際情況,打造了“商品模型主資料”“庫存模型主資料”“組織架構主資料”,構建了能夠支撐珠寶零售業銷售這一關鍵業務流程的主資料模型。
最後,在主資料模型層之上,可以快速擴充出滿足各業務需求的應用資料模型層(ADM)。
最終將應用資料模型層(ADM)中的資料,以 API 的方式對外提供統一的資料服務,業務作為資料消費者可直接實時讀取資料,這種能力是 資料釋出 能力,同時也需要整個主資料平臺,能提供資料虛擬化或者說資料中央化儲存的能力。
06 ⎪ 珠寶零售行業,如何實現主資料管理完成敏捷化轉型
▶︎ 集團戰略規劃
和集團利益相關者一起合作, 結合實際業務發展情況和 IT 基礎設施情況,制定了 3 年 IT 規劃。
透過調研和訪談的形式,摸清資料孤島的情況,為頂層戰略規劃做好奠基性工作。與此同時,和客戶業務部門一道為後續的應用場景規劃進行需求調研,同時形成資料質量規範和資料流程規範。在明確組織架構和資料治理原則的前提下,協助客戶開始技術平臺的搭建,最後一步就是在完成了主資料治理之後,實現業務價值。
▶︎ 資料資產盤點,形成統一商品中心
前面提到,這家珠寶零售公司有多個 ERP 系統,圍繞珠寶的生產製 造、物流供應鏈和最終的銷售都散落在不同的地方。
這裡我們和公司的業務方一起,以擁有主資料較多的部分為核心,將歷史和實時庫存資料、商品資訊和鑽石、黃金和玉器等各類證書都進行打通 、 合併 。 並在這基礎上 , 按照組織架構進行合理的資料釋出和資料授權,讓門店店員和中高層 , 都具備了在需要時消費適當資料的能力。
最重要的是, 在統一庫存模型、統一商品模型和統一資料訪問服務的前提下, 開發 能夠跟得上 市場變化 , 資料 模型複雜但易用 , 可 快速開發新應用 。
07 ⎪ 實施主資料管理之後的效果
在連通資料孤島之後,融合資料,生成主資料,在這樣的資料治理的基礎上,集團很快就上線了基於 主資料的 “全渠道商品中心”, 大陸以及 港 澳 臺門店店員 使用同一套後臺,即可查詢全國商品。
相較於之前的多次 查詢 API 方式,現在前端只需查詢一次,即可獲取商品所有資訊。 查詢次數從 5 次縮減為 1 次, 查詢響應時間從累計 10 秒縮減 到 3 秒內。
技術研發可透過平臺快速查到想要的資料,無需追問相關同事,減少 DBA 日常 70% 查詢工作,有效提升研發 90% 開發效率,這極大地降低了跨部門帶來的 溝通效率問題 。
研發週期 從 2~3 個月縮減為 1 周。 透過『資料即服務』的新架構將資料變成了真正的生產要素,為集團真正實現了“增效降本”的務實的業務價值。
支 撐業務流程的主資料得到沉澱與複用,能在組織間高效共享有價值的資訊,讓不同業務部門都可輕鬆複用歷史資料,快速發現資料價值。
採用的主資料平臺是一體化平臺,服務化程度提高,透過靈活的互動式服務,顯著縮短了開發週期,提升集團市場競爭力。此外,較其他主資料治理平臺,集團選擇的主資料平臺能持續根據業務發展迭代主資料模型,適應企業的動態發展。
08 ⎪ 寫在最後的話
按照 Gartner 對於主資料管理(MDM)的定義,它不僅是一門技術驅動的學科,更是一門管理的學科,需要 IT 部門和業務部門共同合作,確保企業正式共享的主資料資產的統一性、準確性、管理性、語義一致性和責任性。
主資料 , 是描述企業核心實體的一致和統一的識別符號和擴充套件屬性集 的 ,包括客戶、潛在客戶、公民、供應商、網站、層次結構和賬戶圖表。從這個定義出發, 主資料管理就註定不完全是一個技術問題,更多的是一個對於公司所處環境(行業屬性 、 技術儲備 、 人才畫像)的理解後,特殊化出來的一套變革管理的諮詢方案。
隨著數字化在各行各業的乘風破浪, 主資料管理作為一種資料治理的方法論 , 一定能幫助這些企業提升對於資料這一新的生產要素的使用度,釋放更多價值。
雖然再怎麼強調主資料管理諮詢的屬性也不為過,但是平臺本身的能力也不能忽視。基於我們在技術人才儲備較為薄弱行業實踐的經驗而言,一個好用的主資料管理平臺,也是至關重要的。關於如何選好一個主資料管理平臺,前文已頗用了些筆墨,此處不再贅述,感興趣的朋友可以往前檢視。
最後,祝福各位在數字化/數智化的程式中,破局資料孤島 ,掃除 攔路虎, 助 主資料管理藥到病除。
參考資料:
[1] 7 Steps to Build a Successful Business Case for MDM Programs《成功實施主資料管理的 7 個步驟》: https://www.gartner.com/document/3983094
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70016482/viewspace-2909572/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 美創科技四個行業資料安全治理實踐案例行業
- 資料治理 - [03] 專業術語及其說明
- 從技術方面來說,資料治理怎麼進行?
- 差點跪了!阿里3面真題:CAP和BASE理論瞭解麼?可以結合實際案例說下不?阿里
- 鋼鐵行業資料治理架構建設實踐!行業架構
- 說說 C# 9 新特性的實際運用C#
- 說說如何在登入頁實現生成驗證碼功能
- 說說如何在 Vue.js 中實現標籤頁元件Vue.js元件
- 說說如何在 Spring Boot 中使用 JdbcTemplate 讀寫資料Spring BootJDBC
- 一文說清資料管理、資料治理和資料資產管理
- DFL資料恢復實際操作案例資料恢復
- 說說敏捷大資料敏捷大資料
- CSS實際案例,佈局結構CSS
- 說說實時流式計算
- 說說資料分析中的資料建模
- 銀行資料安全治理案例(一)——美創科技
- 說說資料庫事務資料庫
- 什麼是銀行資料治理?如何進行有效的銀行領域的實際應用?
- 資料庫克隆實驗系列-環境說明資料庫
- 如何理解CDN?說說實現原理?
- 說說你對資料結構的理解?有哪些?區別?資料結構
- 資料安全治理及審計合規的最佳實踐XX
- 美團配送資料治理實踐
- 數字化時代,零售業資料治理怎麼做?
- [js] 請使用js實現商品的自由組合,並說說你的思路JS
- 為什麼說資料治理是資料管理的關鍵?_光點科技
- 我們常說的“資料治理”主要有什麼用?
- 傳說中的資料結構_JAVA資料結構Java
- 例說資料結構&STL(十三)——pair資料結構AI
- 例說資料結構&STL(一)——vector資料結構
- 例說資料結構&STL(二)——list資料結構
- 例說資料結構&STL(三)——deque資料結構
- 例說資料結構&STL(四)——queue資料結構
- 例說資料結構&STL(五)——stack資料結構
- 例說資料結構&STL(六)——heap資料結構
- 例說資料結構&STL(八)——set資料結構
- 例說資料結構&STL(九)——map資料結構
- 例說資料結構&STL(十二)——iterator資料結構