「有層次、可發展」的門店數字化管理，是通往新零售的必經之路

02-26

文 | 帆軟數據應用研究院王立鑫

過去幾年，傳統零售行業與「互聯網+」的結合幾經周折，線下門店遇冷，不斷加碼電商卻發現這並不是救命稻草。隨著阿里、騰訊紛紛牽手線下零售巨頭，零售的重心再次回到門店，圍繞門店的「新零售」概念儼然成為新的風口。

那麼，如何讓「新零售」不會成為一句口號？筆者通過對某大型連鎖商超的深入調研發現，實現「有層次、可發展」的門店數字化管理，是通往「新零售」的必經之路。

一、門店數據現狀：層次不清、上下不通

「新零售」的核心目的是通過信息化工具不遺餘力地挖掘門店價值。那麼傳統零售門店的信息化建設水平如何呢？

筆者選取了大型連鎖商超——傳統零售行業中最為複雜的運營系統，進行深入調研後發現，大部分商超集團受困於目前的數據應用現狀，在經營效率提升方面止步不前，更不用提實現「新零售」這樣目標了。

在調研中，筆者總結了商超集團的數據應用現狀，總結為以下三個難點：

難點1：「數據展示層次不清」

數據最終是要能跟蹤實際的經營行動的，然而現有的數據報表欠缺結構性和邏輯性，層次不清，很難為業務人員提供及時的經營指導。例如筆者收集到了這些反饋：

「銷售額、毛利等實時數據只能在辦公室的電腦系統查看，店長大部分時間是在超市現場的，僅憑經驗，很難準確把握銷售動態；」

「同樣的，生鮮部對於斷銷單品，也要求做實時監控。」

「電腦上看到的是大表，什麼層面的數據都有，為了獲取某一指標，店長需要通過excel導出再加工計算，這樣大而全的數據展示導致分析效率低下。」

總的來說，一方面，門店實時數據獲取不方便，另一方面，門店報表為了滿足多方的需求，設計的指標大而全，缺乏層次感。因此，在交互使用上缺乏友好、高效的互動。

難點2：「數據上報受阻」

現在的商超集團大多採用專用PDA終端進行現場的數據採集和上報，那麼關於PDA的使用情況如何呢？來自超過20位一線門店業務人員的調研反饋如下：

「一台PDA投入成本太大，舊有手持終端PDA逐年折舊損耗，新終端機數量也有限；遇上大盤點，需要向其他門店外借PDA錄入數據；」

「請貨的時候，PDA屏幕小，無法做批量填報；」

「在巡店的當場想錄入一些問題，只能寫在微信裡面，散亂的筆記無法整理歸納；」

「倉庫進出貨品的時候，總有一些特殊情況需要及時備註，電腦偏偏不在手邊；」

總的來說，門店僅僅依靠PDA來進行數據採集有很大的局限性，數據源對象單一、採集通道也單一，在數據的維護和處理方面也缺乏靈活性。

難點3：「數據下透無力」

信息化時代，門店店員的日常作業不能僅僅依靠經驗，數據的指導作用被日益重視。但是調研發現，即使是門店的一線管理人員，數據的獲取都困難重重：

「批量查商品的庫存，價格的時候，要跑到信息辦公室，只有兩台電腦，運氣好的時候不用排隊「；

「每天早上11點請貨，系統自動跳單請貨經常不符合實際，需要到信息部排隊做手工調整」；

「做人事評定的時候，除了POS業務數據，還想看財務數據，得換系統查詢，比對起來不方便」；

「天氣信息，節假日信息，交通信息，政策法規等外部數據，我得上百度單獨查」。

總的來說，一線的業務人員和管理團隊與敏捷、多維的數據支撐完全絕緣，根本無法獲取有價值的數據從而提升業務效率。

二、布局門店數據：移動端應用+數倉匯流排

從上面的分析中我們可以看到，目前零售門店的數據應用普遍存在「層次不清、上下不通」的問題。帆軟零售門店移動端解決方案，則為破解門店的數據應用困局提供了解決思路：應用層面，通過移動端為業務人員提供基於事務深度加工的數據服務；數據層面，採用數倉匯流排結構，最大化數倉容積，通過靈活統一的中控平台提高數據採集和分發效率。

1.移動端：零售門店的數據應用武器

包括手機、平板電腦在內的消費級移動終端，從網路基礎、硬體基礎、技術能力各方面來看已足夠成熟，在人機交互、高效瀏覽上也具備得天獨厚的優勢。帆軟零售門店移動端解決方案，基於業務側的應用場景，為零售門店提供了多樣化的應用模塊，已經為多家連鎖商超集團解決了門店數據應用難題。

1.1便攜查詢，口袋報表

方案結合了傳統模式下PDA的查詢類場景，將優秀店長對數據使用的經驗進行了總結提煉，固化成手機端的報表查詢功能，為所有店長提供全面、及時的經營報表。通過筆者對試點門店的觀察，昨日經營報告、庫存跟蹤是最受店長青睞的經典表樣。

昨日經營報告，為店長提供了多種角度的數據對比和分析視角。內部，可以看到各個科組的業績情況、同期對比，外部則可以看到同區域其他門店的單品、品類銷售情況。

庫存跟蹤，則可以幫助管理貨品的課長跟蹤缺貨單品，在崗位上完成請貨、監控、調整、檢視的整個業務過程。

1.2移動辦公，實時數據

實時數據展示，首先要在數倉設立實時分區，基於移動端數據平台，把需要做實時報表的數據篩選出來，在GP資料庫中建立實時中間表，這個暫且不談，下文會介紹到。實時分區完成後，移動端數據展現也有很多功課要做。

梳理優秀店長思維邏輯，發現門店的實時數據展示邏輯如下：

1.第一順位是我整體KPI的達成，即銷售數據：銷售額、目標、達成率。

2.第二順位是我門店客流情況，即顧客數據：來客數、客單價。

3.第三順位是發現哪個部門的問題，即細分數據：各課組數據、同期時段、同期全天。這些數據都要求做到實時，並且倉庫保存歷史快照，這個後面會說到，只是為了說明，這張實時數據表思維清晰，看起來簡單，背後的工程是巨大的。

1.3異常分析，斷供監控

除了實時數據被動展示，還需要關注異常狀態的主動管理，尤其是生鮮水產類快銷品的異常，是很多同行業商超重點關注的模塊。對於這些異常，單個業務系統很難做到，往往需要多個業務系統綜合取數，沿用大數據平台，實現多系統業務單表分析，按照預設的異常類別，進行篩選排序，在移動端展示。

在試用過程中，異常狀態往往得不到業務人員的認可，原因在於：不同的業務人員，對不同的商品，在不同的時間段，有著不一樣的異常判斷。在通用異常的基礎上，如何做到異常狀態的因地制宜，就顯得尤為重要。為此，信息部通過手機端開放了提意見板塊，在留言板社區廣泛收集業務人員意見，預設了9種異常狀態，形成簡單自助式的異常分析工具。

生鮮部門一直有一個問題，由於商品動銷快，常常會出現有些貨賣空了，連庫存都沒了，這就提了一個需求，要求對斷銷單品進行監控，做到實時數據表中，如右上。

1.4聚焦單品，掃碼巡場

「隨時隨地、敏捷上傳、高效下達」，以商品管理為例：門店業務人員長時間在現場，開發了對於單品的掃碼巡場工具，強化商品生命周期管理意識。各課課長，通過移動端，掃描單品條形碼或者手輸單品編碼，即可查詢單品的最新價格、最後一次調價、庫存SKU數量、最近一次請貨、請貨狀態等等，滿足商品生命周期的管理。有如下兩個應用：

應用一：各課課長每天的工作中，有一項是檢查排麵價簽，有的商品沒有價簽，課長自己也忘了價格是多少，以往需要跑到信息部查看，然後打標籤，半天后拿到。有了巡場工具，課長通過巡場掃碼，用手機編輯商品信息，發送給信息專員列印價簽。實現真正的移動辦公，高效溝通。

應用二：在大盤點的時候，「查庫存，PDA不足，手機APP來湊」，各課課長通過手機先做各自區域的預盤點，提前校對庫存、高架、排面的數量，減少20%漏盤單品，降低50%錯盤單品，大大提升盤點效率。

盤點掃碼查詢單品庫存、售價、最近一次進貨日期&數量等數據：

2.數倉匯流排：以不變應萬變

「春江水暖鴨先知」，門店單元作為零售企業的神經末梢，在「新零售」的顛覆下，未來會衍生出無限可能的數據形態，要應對新數據量質齊下的衝擊，這對整個系統平台的架構提出了挑戰。傳統的數據建設思路是圍繞業務為中心，先處理數據上傳，補齊資料庫，通過業務把後台數據整齊後，再考慮數據下達，去優化數據傳送和展示。

這種逆向建倉的過程，投資收益快、實現難度小，但是應對需求多變的門店業務缺乏靈活性、擴展性，業務端稍有變動就涉及整個數據結構的變動。這裡，筆者建議通過建立統一中控平台的方式實現門店業務側的數據採集和下發，保證數據結構的穩健與靈活性。

1.中控——即中央控制，即實現數據池效果，未來的目標是數入一池，數出一孔。建立中控平台，就需要數倉搭建，這裡簡潔描述成四步：

第一步，維度設計：

1.選取建模的業務處理過程。這裡選商品、門店、類別、供應商、品牌等事務。

2.定義業務處理的粒度。選取到單品的粒度。

3.選定用於每個事實錶行的維度。例：畫出單品—庫存—貨架的ER圖，描述關係

4.確定用於形成每個事實錶行的數字型事實。部分事實是IT能決定的，部分需要和業務部門溝通。形成維度表。

第二步，值鏈引入：

1.值鏈選取。這裡的引入了商品銷售、供給、訂單管理三個值鏈。

2.值鏈集成。將值鏈的數據，利用數倉匯流排，規範化引入ODS表中。

第三步，創建模型：

基礎表只是數倉底層，後面還需要依據不同類型的數據特點建立模型，例如：庫存模型，訂單模型，採購模型，顧客購物籃模型等等。

第四步，ETL過程：

業務系統的數據經過清洗，切片，去重後，通過ETL抽取到GP資料庫中，維度表和事實表做交疊查詢，以單品粒度展示在整合表中。整個數據處理的過程耗時不到15分鐘。

如下圖，就是GP資料庫的ETL流程圖（前端展現可忽略）。

三、讓移動端成為業務寵兒

在移動端應用探索的最後，想和已經在使用移動端應用的玩家對話，如何讓移動端成為業務人員的寵兒？

移動端先天的優勢，就不多說了，站在信息人員的角度，筆者建議遵從以下：

1.一個中心：數據為經驗」服務「

我相信IT人員都清楚地知道什麼是數據，但很少IT人員具備業務經驗；所以說，經驗（業務人員）是不會被取代的，這是很自然的職責分工，希望各位玩家客觀看待。

開發移動端就是要「服務業務」，是永恆的主題，「微信」張小龍2018年公開課提到了兩點：

「用完即走」——指的是工具不應該佔用額外時間，做移動端的初衷就是提升效率，業務人員每天已經很忙了，如果打開頁面卡頓，數據載入緩慢，甚至需要費時費力去查找數據，這就不利於增效。「用完即走」總結來說，就是使用移動端，0進入成本，0離開成本。
「去中心化」——移動端開發避免自以為是，應該充分發揮業務人員的各自需求。舉個例子：很多移動端都會設置一個統一的入口，統一的頁面，業務人員打開後還需要點開路徑才能看到自己想看的，為什麼不直接進入收藏夾么？「去中心化」總結來說，就是把選擇的權利還給業務人員。

2.兩個基本點：增大碰撞面積、移動端做減法

「增大碰撞面積」——站在業務人員的角度，拿到數據——產生決策的過程，中間是數據與經驗產生的碰撞。對於業務人員來說，數據和經驗碰撞才有價值，由於業務人員的經驗來自平日點點滴滴的積累，經驗的深度、廣度千差萬別，所以應當增加數據重量：辨識度、含義、關聯度。讓每一個數據成為沉重的榴彈炮，擊中業務人員的經驗區。
「移動端做減法」——越複雜的平台，使用體驗越差；越開放的平台，互動感知越差；在移動端設計伊始，有20多張複雜報表，涉及複雜的查詢參數，可用性可讀性很差，在門店試點的2個月中，深受詬病，最後只剩下：實時銷售表、生鮮斷銷監控、生鮮負毛利監控。

仔細的讀者已經發現，這兩個基本點是相互制約的，要增也要減，要碰撞也要精準。這就引出了另一個話題，移動端應用一定是一個不斷完善不斷發展的過程，隨著業務人員的數據分析能力提高，門店數據的種類和數量不斷增長，未來的門店移動端將有廣闊的應用場景。