編輯導(dǎo)語：在整體倉庫工作中，揀貨操作也是其重要一環(huán)。那么，我們可以如何利用WMS系統(tǒng)來進行相關(guān)倉儲管理工作？前面文章里，作者分析了倉儲管理角度的存揀分離，本篇文章作者繼續(xù)輔助WMS系統(tǒng)闡述了揀貨策略，讓我們來看一下。

一、前言

倉儲業(yè)務(wù)中，我們基本上是圍繞“收貨”、“發(fā)貨”、“存貨”這三個核心業(yè)務(wù)展開的，這三個業(yè)務(wù)內(nèi)工作的閉環(huán)，共同構(gòu)建了整個倉儲業(yè)務(wù)的閉環(huán)工作；而這三個業(yè)務(wù)之間，如果其中一個業(yè)務(wù)的閉環(huán)工作沒有處理好，就有可能給其他兩個業(yè)務(wù)帶來麻煩；我們印象中在倉庫工作的小伙伴好像都是粗糙的漢子，其實，一個正常運轉(zhuǎn)的倉儲，離不開這些“糙漢子”們的精細化管理。

我們講了倉儲業(yè)務(wù)中有三大核心業(yè)務(wù)，那么這三大核心業(yè)務(wù)都包含哪些子業(yè)務(wù)？又具體要負(fù)責(zé)哪些工作呢？我們來簡單看一下：

• “收貨”，包含了采購到貨、調(diào)撥到貨、銷售退貨等入庫作業(yè)業(yè)務(wù)，要對送貨的要求、收貨履約的流程等等進行規(guī)范以及執(zhí)行；
• “存貨”，很多業(yè)務(wù)對應(yīng)“收貨”，對各種收進來的貨進行不同方案的儲存，在儲存的同時，還要支撐“發(fā)貨”的業(yè)務(wù)需求，需要對到貨的碼放以及儲存環(huán)境進行規(guī)范，并對存貨的安全負(fù)責(zé)；
• “發(fā)貨”，就好理解了，我們平時電商購物過程中接觸最多的就是這個了，“發(fā)貨”是訂單履約環(huán)節(jié)中的一環(huán)，負(fù)責(zé)將貨從倉庫打包好（含復(fù)核、承重等環(huán)節(jié)），交由承運單位；在訂單履約環(huán)節(jié)中，“發(fā)貨”是倉儲流程工作中最后一環(huán)。

今天的前言寫的有點多，在人人都是產(chǎn)品社區(qū)看到過幾篇寫揀貨方式介紹的文章了，都已經(jīng)介紹得很全面了，今天就不給大家再科普揀貨方式了，我們結(jié)合實際倉儲業(yè)務(wù)和WMS產(chǎn)品來聊聊關(guān)于“揀貨策略”的事情。

二、何為“揀貨策略”

區(qū)別于“揀貨方式”是對揀貨業(yè)務(wù)中既有的操作方法給出的標(biāo)準(zhǔn)名稱，雖然名稱不同，但是不同揀貨方式都有共同的目的，那就是：提升作業(yè)效率與質(zhì)量；本文所講的“揀貨策略”更多的是與大家分享在不同場景下是如何選擇不同的揀貨方式，從而能夠讓作業(yè)效率和質(zhì)量能夠達到最佳。

隨著電商的蓬勃發(fā)展，各種各樣的產(chǎn)品都搬到了網(wǎng)上銷售，對應(yīng)的在現(xiàn)在的倉儲業(yè)務(wù)中，影響作業(yè)方式選擇的因素就很多了，比如產(chǎn)品尺寸、建包件數(shù)、訂單結(jié)構(gòu)等等原因，很難用一種方式就搞定全部業(yè)務(wù)了，通常是根據(jù)實際業(yè)務(wù)情況，制定不同的揀貨策略來確保整體訂單的發(fā)貨順暢。

接下來，筆者從各種業(yè)務(wù)場景切入，分享一下筆者積累的經(jīng)驗，歡迎大家指正補充！

三、從訂單結(jié)構(gòu)來講

1. 業(yè)務(wù)介紹

在數(shù)量眾多的訂單中，我們把商品規(guī)格（相同SKU）和數(shù)量（對應(yīng)的SKU數(shù)量相同）均一致的訂單稱作相同訂單結(jié)構(gòu)的訂單。

當(dāng)下直播電商的興起，給電商賣家?guī)砹舜罅坑唵蔚耐瑫r，也讓商家大量訂單中訂單結(jié)構(gòu)相同的訂單越來越多了，也有很多圍繞主爆款做套餐形式售賣的店鋪中，這種相同訂單結(jié)構(gòu)的訂單也是占很大比例的。

那么這種類型的訂單該如何發(fā)貨才能讓效率最高呢？

2. 對應(yīng)揀貨方式

這種類型的訂單，我們以類似“二次分揀”的方式，先將訂單中需要的產(chǎn)品一次性取出，因為訂單結(jié)構(gòu)相同，每個訂單中的商品和數(shù)量均一致，所以我們可以直接將貨擺放至打包臺，通過流水線生產(chǎn)的形式進行打包包裝。

1. 如果這個套餐是固定的，并且長期存在，且訂單量比較大的情況，我們可以考慮設(shè)置固定的流水線，在流水線配置足夠數(shù)量的產(chǎn)品用來對這一訂單結(jié)構(gòu)的訂單進行集中處理。
2. 而對于訂單結(jié)構(gòu)相同，但是數(shù)量比較少的訂單，則可以在預(yù)留的空置流水線作業(yè)區(qū)進行打包，預(yù)留的流水線作業(yè)區(qū)可以專門用來支撐這種訂單結(jié)構(gòu)相同，并且有一定數(shù)量的訂單的揀貨打包作業(yè)。

注意事項

1）這種訂單結(jié)構(gòu)相同的訂單的出現(xiàn)，一般是套餐居多，也會存在由不同用戶從單個或者多個鏈接中購買了多個相同的產(chǎn)品從而湊成訂單結(jié)構(gòu)相同的訂單的情況；而對于前者（套餐）來講，也有企業(yè)通過把多種產(chǎn)品組合成一個SKU，以禮包的形式進行售賣。

倉庫通過提前的預(yù)打包生產(chǎn)，將多個產(chǎn)品組合成這一個SKU（組合成單一SKU的方法筆者認(rèn)為是比較好的解決方案，其他方案有從OMS端使用組合裝代替等，雖然犧牲了調(diào)整套餐的靈活性，但是可以提升各個環(huán)節(jié)的效率，大家根據(jù)實際情況選擇就好了）。而后者因為存在一定的概率性，則需要根據(jù)實際的訂單量進行生產(chǎn)了。

2）對于此類訂單，還要考慮同一訂單結(jié)構(gòu)訂單的數(shù)量。數(shù)量太少的，哪怕是固定套餐，也是可以通過常規(guī)的“邊揀邊分”或者“二次分揀”的方式進行揀貨的。

3）需要考慮訂單中商品的種類數(shù)量，即SKU的數(shù)量，SKU數(shù)量如果過多，通過流水線生產(chǎn)的方法可能會導(dǎo)致錯誤率升高。

3. 對應(yīng)WMS功能

我們從上文的關(guān)鍵詞中提取一些所需功能。

1）相同訂單結(jié)構(gòu)

市面上常見解決方案是系統(tǒng)自動分析訂單結(jié)構(gòu)，將相同訂單結(jié)構(gòu)的訂單打上相同標(biāo)記。這個邏輯筆者認(rèn)為是正確的，因為在大量訂單中，我們?nèi)绻蝗プ隹桃夥治?，是不會得知哪些訂單結(jié)構(gòu)相同的訂單多的，但是相應(yīng)的也會失去靈活性。

可細致設(shè)計如下，由系統(tǒng)生成訂單結(jié)構(gòu)的分析結(jié)果（可配置在多長時間范圍內(nèi)，數(shù)量大于多少的才生成結(jié)果等），根據(jù)分析結(jié)果人工選擇創(chuàng)建策略，系統(tǒng)根據(jù)策略對滿足條件的訂單打上指定標(biāo)記。

2）將多個產(chǎn)品組合成這一個SKU

生產(chǎn)組裝功能，當(dāng)這個SKU不是最小采購單元的時候，就需要在庫內(nèi)組裝了，生產(chǎn)組裝流程雖然是一個商品出庫再入庫的流程，但是仍然需要生產(chǎn)組裝的功能將出入庫的類型單獨標(biāo)記出來，以方便后期對賬。

四、從建包件數(shù)來講

1. 業(yè)務(wù)介紹

這里講的“建包件數(shù)”是指包裹內(nèi)商品的總數(shù)量，也有“客單件數(shù)”的叫法，因為考慮到合單和拆單的情況，我們下面還是稱呼“建包件數(shù)”較為準(zhǔn)確。

在不同類目中，建包件數(shù)會存在很大的差別，例如服裝類目，雖然夏季和冬季會有少許差距，但基本上是維持在2-5件左右的水平，而食品類目尤其是休閑食品類目就大不相同了，動輒10件以上，20件以上的情況很常見。

那么針對這種“建包件數(shù)”差異如此大的情況，我們應(yīng)該如何選擇揀貨方式呢？

2. 對應(yīng)揀貨方式

直接上結(jié)論吧。

1. 建包件數(shù)——多：建議使用“邊揀邊分”的方法；
2. 建包件數(shù)——少：建議使用“二次分揀”的方法。

簡單分析一下，建包件數(shù)多的波次，無非是兩種情況，要么是因為SKU數(shù)量多，要么是SKU數(shù)量沒有那么多，但是總件數(shù)多。

• SKU數(shù)量多，會讓揀貨的小伙伴停留的庫位多（默認(rèn)一位一貨），行走的距離多，那么這種情況花費在揀貨區(qū)的時間就已經(jīng)夠長了，如果使用“二次分揀”的方法還要再回去分揀一邊，這樣就會很浪費時間了；
• SKU數(shù)量沒有那么多，但是總數(shù)多，就會讓揀貨的小伙伴停留在某一個庫位的時間長。在不造成擁堵的情況下，大家想一下，一個揀貨波次中很多訂單都需要這個SKU，那揀貨的小伙伴在這個庫位揀貨的時候像不像一個“二次分揀”的動作？

建包件數(shù)少的波次，就比較容易理解了，揀貨速度是相對比建包件數(shù)多的波次要快一些的，使用“二次分揀”的揀貨方式可以讓揀這些波次的小伙伴快速進出揀貨區(qū)，并且揀貨和分揀的分工，也可以讓揀貨區(qū)的使用效率更高一些，讓更多的人投入到揀貨作業(yè)中。

注意事項

雖然這一節(jié)主要是講的建包件數(shù)，但是同樣要考慮很多因素，例如產(chǎn)品體積了，倉庫的面積等等一些客觀因素，在上面講到的結(jié)論中，遇到不同情況也未必適用。

大家有可能會有疑問，波次中商品總數(shù)量多，但是SKU數(shù)少，我也可以先揀回來再分揀呀，只需要手持終端直接掃一件商品就展示這個商品在整個波次中的分配情況就可以了。

是的，這樣也是可以的，業(yè)務(wù)場景不同，各種客觀因素不同，實現(xiàn)方式就沒有絕對。

那什么時候不能二次分揀呢？如果這個波次中混合了大量的商品，且商品之間不易區(qū)分的時候，就不太適合做二次分揀，像這樣的例子還有很多很多，大家一定要在業(yè)務(wù)中注意觀察每一個可能影響方式選擇的因素。

這一章節(jié)結(jié)論是有些絕對的，需要大家根據(jù)實際情況辨別來看，僅供參考，歡迎補充。

3. 對應(yīng)WMS功能

這一節(jié)中需要的WMS功能就很清晰了，我們?nèi)匀粡年P(guān)鍵詞中來分析：

1. 建包件數(shù)——多/少：這個和配貨訂單的篩選條件有關(guān)，要支持SKU數(shù)以及訂單商品總數(shù)范圍的篩選；
2. 邊揀邊分/二次分揀：支持邊揀邊分、二次分揀功能，功能細節(jié)就不詳細描述了，大家百度關(guān)鍵詞即可；
3. 二次分揀——批量分揀：在二次分揀過程中，要注意是否支持顯示商品在整個波次的分配情況。

五、從產(chǎn)品尺寸來講

1. 業(yè)務(wù)介紹

為什么這里要把“產(chǎn)品尺寸”單獨拿出來講呢，相信大家都想到了，還有家具家電這個大類目呢；那么這類業(yè)務(wù)該如何揀貨呢？

2. 對應(yīng)揀貨方式

受限于商品的尺寸和重量，這類產(chǎn)品一般有兩種常見的揀貨方式。

1）按單揀貨

即揀貨的小伙伴按照訂單中的商品，一單一單進行揀貨作業(yè)，揀不完這一單貨，是不會進行下一單操作的，也叫“摘果式”。

2）邊揀邊分

其實在家具家電行業(yè)中，邊揀邊分這種操作方式用到的也是比較多的，常見以下幾種場景：

• 很多家具或者家電都會有贈品，有的時候會拆分訂單發(fā)貨，有的時候會和主產(chǎn)品一起發(fā)貨；
• 家具是有多個部件組成，需要從多個庫位揀貨并使用快遞子母單發(fā)出；
• 不僅訂單中存在多個SKU的時候邊揀邊分會帶來方便，其實如果條件允許，單件產(chǎn)品的訂單也是可以使用邊揀邊分的方法的，這時候主要是靠系統(tǒng)來優(yōu)化揀貨路徑。

注意事項

操作大件，安全永遠高于效率！

3. 對應(yīng)WMS功能

關(guān)于大件的倉儲業(yè)務(wù)筆者接觸不多，憑感覺寫幾點，拋磚引玉一下：

1. 在很多大件商品的包裝中，很多都是帶著外箱的，不需要額外的包裝發(fā)貨，在邊揀邊分的同時，需要可以支持實時打印快遞/物流面單的功能；
2. ……

六、結(jié)語，一點總結(jié)和思考

關(guān)于標(biāo)準(zhǔn)化的問題，大家都清楚，對于系統(tǒng)來講，自動化的集成程度越高，對外部條件要求越苛刻，換句話說要想實現(xiàn)高度的自動化，需要對很多東西制定嚴(yán)格的標(biāo)準(zhǔn)。

在這一點上，實際業(yè)務(wù)中分歧還是很大的，標(biāo)準(zhǔn)化和靈活性總是難以兼顧。個人認(rèn)為，業(yè)務(wù)在發(fā)展過程中，要以靈活性為輔助，標(biāo)準(zhǔn)化為目標(biāo)，如果是用來輔助當(dāng)作過渡用的靈活方法變成了正式的標(biāo)準(zhǔn)流程，阻礙了真正有利于長遠發(fā)展的標(biāo)準(zhǔn)化建設(shè)，那就得不償失了。

關(guān)于智能倉儲，越來越多的智能產(chǎn)品走進我們的現(xiàn)實，智能工廠、智能倉儲等等，筆者也相信，未來的工廠一定是無人的。

但現(xiàn)階段WMS WCS 智能設(shè)備的方案只是在部分項目中應(yīng)用，現(xiàn)在應(yīng)用最多的還是傳統(tǒng)的機械替代人工，并且隨著科技的發(fā)展，機械替代人工的進程正在加快，當(dāng)機械替代人工達到一定程度的時候，如果某個領(lǐng)域還沒有實現(xiàn)高度的智能化，我想，那一定是卡在“標(biāo)準(zhǔn)化”上了！

自圓其說了一下，最后還是希望這篇文章能夠?qū)Υ蠹矣兴鶐椭?，如此，便是我的快樂?/p>

本文由 @橙子哥哥 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議