跨境電商海外倉(3):WMS的庫存功能設計

3 評論 16537 瀏覽 82 收藏 18 分鐘

前面兩篇我們講完了倉儲系統(tǒng)WMS最常用的兩個功能:入庫出庫。今天我們來談談第三個模塊:庫存。

庫存是WMS的基石,而且比較容易理解,所以大家會覺得這個東西很簡單,沒必要太放在心上。但是從我個人的經(jīng)歷來看,其實跨境電商的企業(yè)對庫存的看重程度遠比我們這些系統(tǒng)設計者要重視的多。

因為對我來說,系統(tǒng)的庫存設計的好與不好,無非就是數(shù)據(jù)準確與否,系統(tǒng)是否具有拓展性,是否能較好地支撐業(yè)務的快速發(fā)展。歸根結底,庫存對設計者來說,更粗暴地理解就是「一系列數(shù)字」。

但是對于跨境電商賣家(企業(yè))來說,庫存的意義就變得非凡了。庫存高,可能意味著貨物賣不出去,存在滯銷的情況;庫存低,可能意味著賣的太火爆了,可能來不及補貨了;庫存忽高忽低,可能意味著自己對選品,對市場的預估捉摸不準。簡單的理解,庫存對賣家而言,就是實打實的資金流和市場環(huán)境的晴雨表。

所以,作為產(chǎn)品經(jīng)理而言,一方面要以平常心來對待系統(tǒng)的每個迭代的需求,另外一方面有需要換位思考,去想想這些需求滿足了哪些業(yè)務,而這些業(yè)務對某些客戶來說,是多么的重要。

那么我就來拆解回顧一下,關于WMS的庫存設計,我曾踩過了哪些坑,遇到了哪些難題,又有哪些經(jīng)驗是可以分享出來的。

關于庫內(nèi)作業(yè)

一般來說,無論是國內(nèi)電商倉還是跨境電商海外倉,庫內(nèi)作業(yè)大概都涉及以下幾個操作,而這些操作的內(nèi)核其實都是一個:對庫存進行增刪改查。

庫內(nèi)操作

關于盤點,我會單獨拎出來寫一篇內(nèi)容,所以庫存這一篇就不過多提及盤點的內(nèi)容了。同時關于庫內(nèi)加工,大多數(shù)海外倉受限于管理和溝通,以及成本的問題,往往也很少做庫內(nèi)加工這些內(nèi)容,最多的就是FBA換標和一些簡單地更換包裝等,復雜一些的操作和加工基本上不會做,這一塊我也接觸的不多,所以也就不過多展開了。

1. 庫存查詢——查詢可用庫存

庫存是WMS作業(yè)的基石,倉庫的入庫和出庫,最終都會將結果反饋到庫存上。

例如,某天倉庫收貨上架了某個A客戶的一批手機,那么關于這一批手機的庫存就應該要及時的更新,變成最新的數(shù)據(jù)。然后過了幾天后,倉庫又對這一批手機做了出庫操作,所以庫存又需要扣減。出庫后有可能會有客戶退貨,那么當客戶的退件到了倉庫之后,倉庫又要及時處理再次上架,這批手機的庫存又要增加。

就這樣往往復復之后,庫存就變成了一系列復雜交錯的數(shù)據(jù)流,而我們要做的,就是想辦法整理好這些散亂的數(shù)據(jù)流。

最常用的庫存查詢就是用來查詢某個貨在系統(tǒng)中還有多少庫存,例如我們在淘寶購物的時候,商家會標注庫存剩余數(shù),如果庫存不足了,那么就限制客戶下單。這里的庫存反映的就是倉庫實物的多少,在界面上標注的庫存數(shù)也是庫存查詢的一個典型案例。

當然,很多時候,不同的系統(tǒng)設計框架會不一樣,有些時候頁面上展示的庫存可能是訂單系統(tǒng)OMS自己記錄的一套庫存,可能和倉庫系統(tǒng)WMS中記錄的會有偏差。但是如果從這個現(xiàn)象的本質來看,這其實就是一種「庫存查詢」的典型用法。

庫存查詢一般是用來查看可用庫存,有些時候也會需要查看總庫存,鎖定庫存,在途庫存或者凍結庫存等。

總庫存=可用庫存+鎖定庫存+凍結庫存(可選)。

有些倉庫會區(qū)分鎖定庫存和凍結庫存,具體要看業(yè)務的定義是什么;在途庫存一般是用來告知客戶有一些貨物正在路上,但是還沒到倉庫,所以一般不會記錄到總庫存中。

2. 庫存查詢——查詢庫存的批次

隨著跨境電商競爭愈發(fā)的白熱化,以前那種靠選品就能取勝、爆火的可能性越來越低了,很多賣家開始關注用戶體驗,其中就包括對倉儲服務的要求。所以越來越多的客戶希望倉庫能對貨品做到更加精細化的管理,最好是能精細到批次的管理。

同樣是一部256G的iPhone11,4月1號入庫的和5月1號入庫的應該是不同的批次,如果需要按先進先出來管理,那么這兩個時間點入庫的iPhone 11不能放在同一個庫位上。

所以,當倉庫采用了「先進先出FIFO」策略后,就需要開發(fā)批次查詢的功能,以便于支持倉庫人員查詢到具體的某個SKU有多少批次,同時這些批次又分別放在哪些庫位上。之前出庫篇談到,其實「先進先出FIFO」看似很完美,讓客戶體驗提升了很多。但是對倉庫管理來說,其實增加了很多難度,其中最大的一個問題就是:庫位不夠。

海外倉本來建倉成本就很高,如果倉庫不算大,庫位又不太多的情況下,對所有客戶采用「先進先出FIFO」策略,往往很容易爆倉(庫位爆滿)。

所以,為了滿足部分客戶這種精細化的要求,往往會采用折中的方式:對某些客戶采用先進先出,某些客戶做邏輯上的先進先出,也就是之前提到的“假性”先進先出??此坪芎唵蔚?,很棒的功能,但是實施起來也會受到諸多限制,所以這算是海外倉WMS設計的一個核心點。

設計某個功能不難,難的是如何把控用這個功能的人,以及這個功能帶來的一系列成本問題。

3. 庫存查詢——查詢庫存的庫齡

前面說到,客戶會對倉庫的貨品有更精細化的要求,其中關于批次的要求,一方面是為了可以支持「先進先出FIFO」的作業(yè)方式,另外一方面就是為了支持倉租的精細化計算。

摘自《跨境電商與國際物流:機遇、模式及運作》

從上圖可知,對賣家來說,海外倉庫的庫內(nèi)處理費主要是包含兩塊:倉租和訂單處理。很多海外倉服務商都會用“30天內(nèi)免倉租”,“90天內(nèi)倉租打8折”等方式來吸引客戶。

那么,倉庫又如何知道某個貨品在倉庫待了多少天呢?這也就是做貨品庫齡統(tǒng)計的一個根本原因了。

同樣是一部256G的iPhone11,4月1號入庫了100PCS,5月1號入庫了200PCS。截止到5月3號,批次0401的100PCS在倉庫內(nèi)已經(jīng)超過了30天,而0501的200PCS還沒到30天,所以0401的倉租應該免去30天,然后計算剩余的天應該收多少錢。

統(tǒng)計批次的庫齡并不難,關鍵是需要系統(tǒng)將各個環(huán)節(jié)打通,例如首先要記錄不同SKU入庫的批次,然后對不同的批次做定時任務的統(tǒng)計,接著對統(tǒng)計的數(shù)據(jù)進行歸類和整理,最后就可以展示出某個SKU不同的批次在某一天的時候分別的庫齡是多少了。

4. 庫存預警

庫存如同進餐,多了少了都無益。海外倉備貨考驗的是企業(yè)自身對于市場的判斷力和銷售經(jīng)驗,庫存量往往很難把握,無論是滯銷還是脫銷對賣家本身來說都很不利。很多出口跨境電商之前都是采取現(xiàn)買現(xiàn)賣的模式,庫存很少,也就形成了忽略庫存管理的習慣。但當企業(yè)使用海外倉,或銷售規(guī)模大起來時,會發(fā)現(xiàn)退貨、備貨、庫存不準、庫存超齡等問題,造成了大量的資金占用。

因為海外倉備貨對賣家來說是一件預測市場的事情,意味著準確性是一個未知數(shù),同時倉庫作業(yè)時間一久,實物和賬面庫存難免就會出現(xiàn)不一致的情況,為了避免這種有單卻無貨可賣的情況出現(xiàn),一般會為客戶設置預警庫存。

當某個SKU的可用庫存低于某個值的時候,會觸發(fā)郵件或者消息提醒,告知客戶應該及時補貨,否則可能會面臨有單無貨發(fā)不出的難題。

這一塊的設計一般會放在前端業(yè)務層來完成,例如放在OMS或者ERP系統(tǒng)中,這樣用戶在操作的訂單的時候可以及時關注到某些SKU可能不足,需要及時補貨。

還有某些SKU是有保質期管理的,當保質期低于某個值的時候,應該對禁止這些SKU出庫,否則發(fā)出了過期產(chǎn)品導致客戶受損,在歐美可能會面臨很高額的罰款。保質期管理對預警的要求更高,可以設置多個預警檔位或者通知方式,最大化程度避免將過期產(chǎn)品發(fā)出。

為了給客戶提供更加準確的SKU庫存信息,倉庫也會及時地對庫存進行盤點調(diào)整,以便于客戶知曉最新的庫存數(shù)據(jù),關于盤點的內(nèi)容我們下期再講。

5. 移庫

移庫在WMS中也是很常見的一個操作,就我實際經(jīng)歷的項目而言,按貨品質量來分,移庫可以分成兩大類:

  1. 同品質移庫;
  2. 良次品轉換移庫。

同品質移庫: 將A庫位的iPhone11移庫到B庫位上,A和B庫位都是存放可銷售的良品的庫位。將A庫位上少量的貨物移到B庫位上匯總,可以釋放出一個庫位,減輕倉庫的周轉壓力。同時將貨物盡可能的放在一起,也可以提升揀貨的效率。

但是這里要注意,例如該貨主需要遵循「先見先出FIFO」策略,那么就不能把不同批次的貨物移到一起,因為批次管理的目的就是為了區(qū)分不同的批次。如果倉庫允許,批次管理可以采用貼批次碼的方式來處理,但是一般這樣操作之后增加的成本太高,很少有海外倉會這樣做。

良次品轉換移庫: 將C庫位的iPhone11移庫到D庫位上,C庫位是存放可銷售的良品的庫位,而D庫位是存在不可銷售的次品庫位。這種移庫雖然也算是移庫,但是不能簡單地將貨物一挪就完事了,應該要先走一個「庫內(nèi)質檢」或者是「良次品轉換」的操作,先將良品轉化為次品,然后再移庫到存放次品的庫位上。

當然,一般情況下良品=>次品居多,少有次品=>良品,但是也不是沒有可能。為了兼容這兩種情況,在程序設計的時候,要確保都可以支持。

如果是從貨架的屬性上來區(qū)分的話,可以將移庫分為:

  1. 同屬性貨架移庫;
  2. 不同屬性貨架移庫;

這里說的貨架屬性是指傳統(tǒng)貨架,AGV機器人貨架這種屬性。目前國內(nèi)很多大電商的倉儲系統(tǒng)都會考慮搭建AGV機器人系統(tǒng),但是也有些倉庫還是在使用傳統(tǒng)的固定式鐵架子的貨架。

而我實際經(jīng)歷過的業(yè)務就存在,既有AGV機器人貨架,也有傳統(tǒng)貨架的,所以這一塊的移庫就需要涉及到兩套管理系統(tǒng)間的交互了,在此不做過多解讀。

難點與踩坑點

(1)庫存的流水記錄需要特別注意,庫存是每一次入庫和出庫還有盤點的綜合結果,流水是每一條操作的記錄,所以每條記錄應該都有一個操作前庫存,操作庫存,操作后庫存。這樣后續(xù)也可以很方便的查詢到哪條流水有問題,哪條流水對應的訂單需要復查等。

(2)庫齡報表需要統(tǒng)計準確,庫齡報表是每個SKU的每個批次每天的統(tǒng)計結果。很多時候因為一些倉庫異常操作,所以會需要人工修復數(shù)據(jù)等,往往會導致庫齡報表丟失紀錄或者數(shù)據(jù)。所以但凡對人工修復了庫存相關的數(shù)據(jù),一定要注意關注庫齡統(tǒng)計的結果是否有受到干擾。

(3)庫存數(shù)據(jù)具有實時性,一方面要及時更新數(shù)據(jù),讓業(yè)務端可以及時同步最新的數(shù)據(jù)。另一方面要定義清楚一些庫存的區(qū)別,例如可用庫存、在途庫存、鎖定庫存、凍結庫存等,要分類合計,尤其注意“可銷售庫存”的監(jiān)控。

(4)庫存周期是衡量產(chǎn)品銷售是否健康的一項重要指標,即單位庫存售出所需時間。后期倉庫業(yè)務量較大的時候,應該花時間和精力關注庫存周期是否滿足行業(yè)標準,將一些滯銷的產(chǎn)品及時清理出來,避免死占庫存,既影響客戶的資金流,又影響倉庫的庫存周轉。

總結

海外倉WMS的庫存要求有些方面比國內(nèi)電商倉庫WMS的庫存要求更高一些,例如海外倉面臨補貨時間長,銷售可預測難,倉庫精細化操作支持度不夠等問題。

所以針對這些特殊的業(yè)務要求,不一定非要遵循所謂的「行業(yè)標準」。產(chǎn)品經(jīng)理也不要過多的糾結某些功能和操作在國內(nèi)倉庫是見不到的,這種操作是否不科學,不合理。而是應該關注業(yè)務本身,以及海外倉暴露出的「持久性」痛點,怎么用國內(nèi)較為先進的倉儲系統(tǒng)設計方案移植到海外倉系統(tǒng)中。

關于庫存功能的設計,說來慚愧,因為其實我與賣家客戶接觸的場景也不是很多,而且海外倉的特殊性導致對倉庫端的用戶調(diào)研和業(yè)務觀察也不太好做。所以我更多的會從國內(nèi)電商倉庫的一些經(jīng)驗出發(fā),然后推導海外倉庫應該怎么作業(yè)。

如果你有機會做海外倉庫的WMS,記得多接觸接觸客戶,同時別忘了和海外倉操作人員多接觸接觸,很多業(yè)務就會有畫面感,產(chǎn)品設計也就不會出現(xiàn)太多「想當然」的情況。

當然,即便我這樣所了,我仍然相信:年輕人該走的彎路,一步都不會少。

#專欄作家#

vitamin,微信公眾號:皮醬叨逼叨,人人都是產(chǎn)品經(jīng)理專欄作家。中級產(chǎn)品經(jīng)理,一年開發(fā)經(jīng)驗+三年產(chǎn)品經(jīng)驗。主導過在線教育類產(chǎn)品,目前是跨境電商供應鏈倉儲物流產(chǎn)品一枚,歡迎勾搭,一同學習。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)作者許可,禁止轉載

題圖來自unsplash,基于CC0協(xié)議

更多精彩內(nèi)容,請關注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 有幾個問題咨詢下:
    1.庫存預警的邊界是根據(jù)市場判斷和銷售經(jīng)驗的一些綜合評估,這里面的極限參數(shù)值根據(jù)某個SKU的實際銷售量來評估的嗎?
    2.某一個庫位會不會同時存在先入先出和假性先入先出的情況?
    3.AGV機器人貨架和傳統(tǒng)貨架除了在效率上較大差異外,在其他方面有哪些主要區(qū)別?
    4.鎖定庫存、在途庫存、凍結庫這3個具體指哪些場景?

    來自陜西 回復
  2. 針對跨境電商調(diào)度層面的平臺倉庫存和商家倉庫存數(shù)據(jù)流是否有文檔分享。

    針對訂單在JIT模式(訂單拉取采購模式)怎么協(xié)調(diào)平臺倉和商家倉的產(chǎn)品流向,感謝

    來自浙江 回復
    1. 我沒做過這一塊的領域哦,所以不熟悉這個,給不了什么幫助,抱歉。

      來自廣東 回復