編輯導讀：WMS的移庫功能是指將貨物從一個倉位移到另一個倉位，然后兩個倉位的貨物各自增減數量。本文作者對一次移庫功能設計進行了復盤，總結了在設計過程中遇到的一些坑，以及應對方式，與大家分享。

前言

WMS的移庫功能在不同的倉庫或者不同的系統定義不一樣，有些地方把移庫當成兩個倉庫間貨物的轉移，有些地方把移庫當成不同的庫區間的貨物轉移，例如從拆零區到整箱區，或者從高貨值區轉移到低貨值區等。

但是本文所提到的移庫其實就是指貨位（庫位）間轉移，將貨物從庫位A移庫到倉位B，然后庫位A的貨品扣減數量，倉位B的貨品增加數量。

看似很簡單的功能，但是結合到實際業務中，也讓我踩了挺多坑。所以我特地花了一些時間整理出此篇文章，復盤一下我在設計該功能的時候遇到了哪些問題，收獲了哪些感悟。

那么，我們開始吧。

一、簡易版的移庫

很多海外倉沒有做效期管理，也沒有做批次管理，所以基本上對貨物的管控粒度都是在SKU層面。如果是SKU層面的移庫，只需要將源庫位的SKU扣減數量，然后轉移到目標庫位上，SKU對應的的增加數量即可。

簡易版移庫

簡易版的移庫主要是因為管理粒度在SKU，所以在移庫的時候，只需要判斷目標庫位的貨主和料區是否和源庫位一致，只要一致就可以移庫，沒有其他額外的判斷邏輯。

貨主為什么要一致？

這個各個倉庫的管理要求不一樣，我們不允許一個庫位放兩個貨主的貨物是因為兩個貨主的貨物可能會一樣（你賣iPhone，我也可以賣iPhone），為了避免這種貨物識別可能帶來的風險，所以我們是只允許一個庫位放一個貨主的貨物的。

料區是什么？為什么要一致？

這個也和倉庫的管理要求有關系，有些倉庫對貨物的品質管控只要求區分良品，殘次品或者其他粒度。而我們對品質的管控要求細一些，除了要求好壞之分的話，還會有更細的粒度。

例如退貨回來的貨物區分售后良品，售后不良品；所以一個庫位只能放一個料區的貨物，將良品放在一起，殘次品放在另外的庫位，那么移庫的時候，一個良品庫位的貨物也就只能移庫到其他良品的庫位上了。

二、業務升級，引入批次概念

批次是倉庫對貨品的管理粒度還要再細一層，要精確到批次號（批號）上。批號這個概念在醫藥WMS中很常見，大家身邊如果有藥品盒子可以查看一下，一般來說藥品上都會印有生產批號，如下圖所示：

藥品的生產批號

一般來說產品上有批號信息的商品其實還算方便管理，畢竟有個顯眼的標識讓你去查看。但是如果有些商品沒有批號展示，但是又需要進行批次管理，那么難度就顯然高了一些。

業內通用的做法有兩種：

• 第一種：在商品入庫的時候，逐個商品貼批次碼，這樣每次到貨的商品都要拆包貼碼，成本比較高；
• 第二種：入庫的時候不貼碼，而是根據入庫時間或者上架時間，系統自動對某個SKU進行批號的標記，然后記錄這個批次關聯的庫位是哪個；

而往往大多數倉庫采用的，就是第二種。

今天倉庫收到了100箱維他檸檬茶，SKU為vita100，這100箱維他檸檬茶都是一年后過期。然后在系統在生成上架單的時候，會對這些產品自動標記一個批次號，例如就叫做BN20200725001。

過了兩天倉庫又收到了50箱維他檸檬茶，SKU還是vita100，但是這50箱維他檸檬茶是半年后就過期。在系統在生成上架單的時候，還是會對這些產品自動標記一個批次號，例如就叫做BN20200727001。

所以在系統中，就會知道一共有150箱維他檸檬茶，一共有兩個批次，批次號BN20200725001的是100箱，批次號BN20200727001的是50箱。

如果倉庫不要求對批次進行管控，那么這150箱的維他檸檬茶就是可以放在同一個庫位的，到時出庫的時候也就可以隨機揀貨出庫了。

這個也就是為什么一些電商網站會說新老包裝隨機發貨的原因，因為在倉庫管理的時候新老包裝都是同一個SKU，沒有做批次管理，所以新老包裝就放在一起了，揀貨的時候就隨機拿了。

如果倉庫要求對批次進行管控，那么系統的功能設計上就要復雜一些了，因為批次管控意味著不能混批次（一個庫位上不能放不同批次的同款商品）。上面提到，一般倉庫不會采用重新貼碼的方式來管理批次，所以都是用的第二種，也就是跟蹤批次號對應的倉位的方式來管理。

那么之前的批次號為BN20200725001的100箱維他檸檬茶就應該放在一個庫位，而BN20200727001的50箱應該放在另外一個庫位，兩者不能重疊。所以上架的時候應該要對批次號做限制，某個倉位有該產品的批次了，那么其他批次就不能放上去了。

此時如果我們加大業務量，一天同時入庫10個貨主，100款SKU，大概有400多個批次，而且這些產品中，有些需要效期管理，有些需求批次管理，有些只需要SKU管理，這個時候如果沒有一套完善的批次管理機制就容易出問題了。

三、業務繼續升級，效期，批次和普貨同時管理

效期管理，就是針對商品的有效期（保質期）進行管理，倉庫不能把一些過期了或者臨近過期的產品發出去，否則會造成比較嚴重的損失。

批次管理，就是針對商品的出廠批次或者入庫先后的批次做管理，一般會用來做先進先出，提升產品的周轉率，同時也能盡量把老款賣出去，也方便來算庫齡和倉租。

普貨管理，就是普通的產品，不需要做批次管理，也不需要做效期管理，可以直接在SKU的粒度上進行管理，無論是先到的還是后到的，都可以直接疊放在同一個庫位上。

針對這三類的產品，其實是有共性可以作為突破口的，那就是批次號。無論你是什么類型的產品，我都給你加上一個批次，這個批次可以理解為SKU的策略。因為批次號需要與庫位進行關聯，即某個SKU的某個批次號的貨物放在了某個庫位上。所以我們需要對庫位也做一個策略的管理，就是商品是否混放與批次是否混放。

將SKU的策略和庫位的策略結合在一起，來切割我們不同的產品的管理要求和粒度。

對于SKU的策略來說，可以分為需要批次管理和不需要批次管理，需要批次管理的是批次產品和效期產品，而不需要批次管理的則是普貨。效期產品雖然重點關注的是失效日期，但是本質上來說還是屬于批次的管理，不同的失效日期的可以理解成不同的批次號。

對于庫位的策略來說，就是分為商品混放且批次混放，商品混放且批次不混放，商品不混放且批次混放，商品不混放且批次不混放，一共四種情況。一般來說海外倉用的最多的就是商品不混放且批次混放，就是一個SKU都放在一個庫位上；而對于一些生鮮產品或者效期產品來說，用的比較多的就是商品混放且批次不混放。

所以一個SKU的上架，大概來說可能會有8種判斷條件，如果把效期產品的單獨算作一種策略，那么就會有12種判斷條件。

四、說回移庫

踩坑一：說移庫只想到了移庫

本文的主題是講移庫，但是我在梳理流程的時候發現我之前踩了一個很大的坑，那就是我在設計移庫的功能的時候，只想到了移庫，我重點在關注移庫的一些操作和策略上。

但是回顧一下，其實移庫的本質依然是上架，只是包裝了一層外衣。難點其實依然是在上架的時候對SKU和庫位策略的判斷，如果只盯著移庫去設計，很容易走進死胡同，發現怎么設計都會有欠缺，都是只見樹木不見森林。

策略不全

踩坑二：上架的方式與邏輯判斷的方式

除了一開始踩進了移庫這一個牛角尖的坑之外，還有一個很重要的坑，那就是關于上架的方式和邏輯判斷的方式也碰壁了。

按常規來講，移庫應該是會涉及到同時移庫多個產品的，這也意味著上架的時候會上架多個產品，現實的上架確實也會如此。

然后我在考慮SKU策略和倉位策略的時候就犯難了，例如一個庫位的策略是商品不混放且批次混放，那么我在上架的時候得要先考慮我待上架的產品首先有沒有混放（意思是自身有沒有混）。如果沒有混，那么放上去的時候又要考慮已有的產品和要放上去的產品是否混放。如果這個也沒有混，最后再判斷批次是否混放，直到都滿足才可以上架。

這樣一來，如果一次性上架很多個SKU，那么商品不混放的庫位壓根就上不了。如果在移庫的時候，倉庫發現這個庫位上去了，那個也上不了，很容易就崩潰，效率也不高。

然后我就在開始思考，是不是要先考慮移庫的時候源庫位和目標庫位的庫位屬性是否一致，是否要區分普通貨物移庫和批次貨物移庫。順著這個思路，我就踩了第三個坑。

只考慮普貨移庫

踩坑三：思考的方向變成了源庫位和SKU

因為考慮到不同的產品和倉位策略上架的邏輯判斷太多，我本能的覺得這樣肯定不對，所以我決定把思路放在源庫位和SKU上試試。

移庫前先比對兩者的庫位策略是否一致，不一致就不允許移庫了，如果一致才可以移庫。但是這樣還是會有一個問題，那就是本來庫位的策略大家都是不允許商品混放，但是因為新的SKU移庫過來了，那么就打破了本來的庫位策略，所以判斷條件還是有那么多。

于是我繼續思考是不是還要先考慮SKU的組合的問題，例如移庫只能一次移庫一個，這樣的話判斷的時候就可以很容易的將待移庫的SKU和目標庫位的SKU進行對比，看看是否有沒有破壞目標庫位的策略。這樣的話，判斷條件確實是簡單了一些，說明這思路是對的。

但是如果普通上架或者容器上架的時候，面臨同時有多個SKU的時候怎么辦？這個辦法還是很麻煩，而且感覺不對勁，于是我將我的思考結果和疑惑點記錄下來，跟我們的開發大佬溝通了一下，這才解開了我的疑惑。

思考方向弄錯了

五、解惑時刻

當我把記錄的疑惑跟開發大佬溝通的時候，他指出了一個很重要的點，也是我一直思考碰壁的地方：移庫的本質其實也是上架的策略，而上架的策略其實就是上架一個SKU判斷一次策略！

這句話直接給了我解題的思路，瞬間打通了之前閉塞的環節，而且他還告訴我在前兩天的時候他其實都已經理出來了邏輯而且核心代碼都寫好了，只不過這個是上架的策略，而我當時沒有關注還心撲在移庫上（直接碾壓，尷尬）。

然后我們一起就著他畫出來是思維導圖進行了一波推演，發現這個方案確實是正確的，而且是通用型的，很多我沒有想通的點，其實就是因為我踩了坑。

上架的邏輯判斷

對著上方的邏輯圖再走一遍流程會發現，不論是移庫還是上架其實本質都是上架策略的判斷，這是可以通用的。

首先判斷貨主和料區是否一致，這個前面提到過，屬于常規性必做的判斷。

其次判斷商品混放策略，上面講到了每次上架都判斷一次這個邏輯，所以并不需要考慮本身待上架的產品內部是否混放的問題。商品混放策略直接拿待上架的這個SKU和已經在庫位上的SKU判斷即可，如果可以通過則進行下一個批次策略的判斷。

在判斷批次策略的時候先判斷SKU的自身的策略，是否批次管理還是普貨，如果是批次管理，那么就只能放在不允許混放批次的庫位，然后再判斷待上架的批次和已上架的批次是否相同；如果是普貨，則任意都可以放。

上面的邏輯分析圖基本上就可以覆蓋所有的與上架策略有關的場景，理清楚了核心的業務邏輯，剩下的就是一些錦上添花的輔助工作了。

總結

本來一開始的工作任務是對移庫功能進行優化和調整，但是隨著業務的演變，一些規則和要求的加入之后，移庫變得不是那么簡單就能搞定的了。本以為是一次簡單的業務邏輯調整，但是碰壁之后才發現原來是我自己對一些本質的東西沒有抓住。

通過這次小小的復盤，讓我get到了這么些感悟，分享給大家：

1. 抓住問題的核心很重要，也很難。很多表面因素看起來似乎是問題的癥結，但是隨著深入的探索和思考往往會發現，游于表面的分析和摸索其實很費時間，而且很容易走偏；
2. 方向不對，努力就會白費。移庫的設計方向應該是從庫位出發，而不是貨品。我因為從庫位出發碰壁了太多，所以調轉了方向，結果發現越跑越遠；
3. 產品設計過程中，思維碰撞和交流特別重要，尤其是遇到困難和疑惑的時候，及時記錄并及時溝通，探討解決是一個高效的方式，如果沉溺于自我世界之中，很容易低效又返工；
4. 對業務的理解往往產品的思維和開發的思維不一樣，但是產品如果過多的夾在技術思維和業務思維很容易兩者都容易受限，不如先拋開技術思維而只專注于業務層去設計，隨后再和開發討論技術思維是否能支撐業務方面的設計。這一點對我這樣的技術轉產品的人來說很致命，技術轉產品，有利有弊，而這一塊往往就是短板，需要特別注意去規避。

#專欄作家#

vitamin，微信公眾號：皮醬叨逼叨。人人都是產品經理專欄作家，公眾號運營小白，初中級B端產品一枚（一年開發經驗+三年產品經驗）。主導過在線教育類產品，目前是跨境電商供應鏈倉儲物流產品一枚，歡迎勾搭，一同學習。

本文原創發布于人人都是產品經理，未經作者許可，禁止轉載

題圖來自unsplash，基于CC0協議