編輯導讀：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協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部