WMS：盤點設計

編輯導語：倉庫管理系統WMS是常見的B端產品，其中，盤點業務是WMS中常見的業務流程。盤點任務的創建，包含了盤點觸發、盤點范圍、盤點方式及盤點人員等方面。本篇文章里，作者對WMS的盤點設計做了總結分享，一起來看一下。

之前陸陸續續寫過WMS出庫、入庫、庫內管理的相關設計，并且也正對于出庫揀貨的功能做了較為詳細的闡述，今天我想聊一聊盤點。

在行業中，我們常常會用盤點準確率作為權衡倉庫管理水平的核心指標。倉庫管什么，管的就是那票貨和操作那票貨的人。而盤點，用最白話的方式來講就是，系統告訴我這個地方有多少這個貨，那我去數數看是不是真的是這個數，如果是的話那就沒毛病，不是的話，那咱得好好看看哪兒出問題了。

那么接下來我們就開始進入正題吧。

對于盤點這個業務流程來說，通常可以分成三大步驟：創建任務→執行任務→盤點生效。

本文也會從這三個環節展開對盤點進行一個完整的介紹。

一、盤點任務創建

創建一個完整的盤點任務的生成應該包含以下幾個部分：

• 盤點觸發條件——什么時候盤；
• 盤點范圍——盤哪里，盤什么；
• 盤點方式——怎么盤；
• 盤點人員——誰來盤。

1. 什么時候盤點

這里通常可以分為三大類的觸發情況，包括：周期性盤點、指定條件觸發盤點、用戶自主盤點。

1）周期性盤點

顧名思義，周期性盤點是定義一個固定的周期，由系統間隔一定周期后，創建固定的盤點任務由倉庫進行盤點執行。這個功能通常是結合盤點計劃來實現的。這也是倉庫管理中應用最多的一種方式，一般會設置月盤/雙月盤/季盤等。定期確認倉庫庫存的準確性，及時糾錯。

2）指定條件觸發盤點

這種觸發方式相對來說就比較個性化了，需要結合實際的業務訴求進行設計。

比如為了保障在頻繁操作中庫存的準確性，當某倉位當日揀貨頻次達到一定量后自動觸發盤點任務。要求在次日開始揀貨前對此庫位進行盤點。

或者為了避免商品丟失，對于一定時期沒有流水的庫位觸發盤點任務由專人進行盤點，確保無資損等。

3）用戶自主盤點

前兩種都是由系統來觸發的，而當用戶實際操作過程中發現庫存異常時，也應支持自主發起盤點任務。

如之前我們設計過在揀貨過程中員工發現指定庫位庫存異常時，即刻觸發盤點任務，由專人庫管進行異常確認和相關盤點。

2. 盤點范圍

哪些倉庫、哪些庫位、哪些貨品要盤點呢？

1）全盤

全盤很好理解，就是不管三七二十一，一股腦兒所有的可用倉庫、所有貨品都盤點一遍。雖然在庫存準確性上有所保障，但是確實是“勞民傷財”了。因此通常只有在固定較長周期的盤點任務中才會用全盤的方式。

2）部分盤點

部分盤點可以是針對于部分庫位、也可以是針對部分商品。或者對于3PL倉這種服務性質的倉庫，也可以針對特定貨主單獨發起盤點。

當然還包括上文(指定條件觸發盤點)中提到的按照指定條件觸發盤點中一些特殊的維度。

如果是用戶自主盤點的話，通常最細維度可以到針對倉庫中某一庫位的指定SKU。

以上都可以概括為部分盤點。

3. 盤點方式

1）明盤VS暗盤

針對盤點過程中，用戶的“知情權”不同，可以分為明盤和暗盤。

明盤是指用戶在操作盤點時，允許用戶知道當前庫存，其目的是為了讓用戶知道在盤點過程中知道差異，并及時核實差異，確認差異原因，確保提交的結果是準確的。

暗盤則相反，用戶盤點時，只知道當前盤點數量卻無法查看到當前實際庫存。只有最終提交結果生效后才可知道差異信息。通常這么做的目的是為了防止用戶在盤點過程中作弊，為了應付考核而弄虛作假。

兩種方式無謂對錯，只是適用的大場景有所不同，大家可以思考下什么場景適合明盤，什么場景適合暗盤？

2）靜盤VS動盤

靜態盤點是指，在盤點過程中，全部作業停止，一直到盤點任務內所有物料盤點完成。在我剛畢業還在制造行業工作時，基本上每隔半年倉庫就會大盤一次，產線會歸還所有未用完的物料并停止作業，倉庫此時禁止領還，等所有貨物都盤點完畢并提交財務審核后，重新開始作業。在此期間，倉庫內所有貨物都是“靜止”的。

動態盤點則是相對于靜態盤點而言。在盤點過程中，倉庫整體還是可以正常作業，針對于未盤點的區域進行“靜止”處理，某區域一旦盤點完成，即可開始投入正常使用，不必等整個倉庫盤點完畢。

4. 盤點人員

盤點任務的執行可以實現為指定式、認領式。

1）指定式

系統按照用戶設定的規則制定某個或某群用戶。如特殊/貴重商品只能由部分權限用戶才可進行盤點。通常需要用戶在系統中預設指定規則。

2）認領式

則是指任務生成后盤點責任人為空，有相關倉庫/區域權限的用戶均可查看到此任務。用戶按實際情況進行任務的認領。

此外，對于一個盤點任務來說，當盤點范圍不同時，在人員的約束上也會有所不同。當把倉庫/多貨品作為一個盤點任務時，那么必然是要允許多人盤點的。但是對于針對庫位庫存異常生成的庫位盤點任務，通常會限制一個用戶認領后，其他用戶是不允許再操作此盤點了。避免同時盤點同一庫位造成的數據差異。

5. 小結

針對不同的場景，通常需要對這幾個維度進行不同的組合，創建不同類型的盤點任務。大家可以自行思考下不同場景下對盤點任務的不同訴求。

二、盤點任務實操

盤點的實操部分反而是比較簡單并且通用的部分了。

通常可以分為：領取任務（如果需要領取的話）、針對盤點任務中的明細開始盤點兩個步驟。領取任務相對來說是個比較通用的功能，這邊就不展開說了。

1. 盤點任務的展開和操作

在盤點任務詳情的呈現上面，可以分成兩大類：按商品維度和按庫位維度呈現。

以下圖例僅為簡例，只為說明概念，實際產品設計相對會更加復雜。

此外，在盤點實操過程中，為了確保用戶確實是在指定庫位盤點指定商品，在產品中需要增加庫位、商品掃碼邏輯。

2. 初盤VS復盤

盤點過程可以分為初盤和復盤，初盤即針對盤點對象的首次盤點，復盤通常是針對有初盤有差異的部分，要求用戶重新核實盤點，增加盤點數據的準確性。

對于盤點有差異的部分，在提交時，要求用戶錄入可能造成差異的原因。

三、庫存調整

1. 盤點審核

盤點完成后，用戶對盤點結果進行提交，通常對于盤點結果是要求經過幾輪業務包括財務的審核后，才可以生效的，畢竟直接影響的就是錢了。

并且增加審批流也可以對實操業務有一定警示作用，明白盤點的嚴肅性。

2. 庫存調整

盤點結果審批通過后，則需要針對盤點結果對當前庫存進行相應的調整。

庫存調整可以分為覆蓋調整（不推薦）和差異調整生效。

覆蓋調整是指，原庫存10，盤點后庫存8，那么在盤點生效后直接將庫存改為8。大家仔細想下這里是否會有問題？我在此處先不講，等我講完差異調整后，相信大家自己就明白了。

差異調整則是指，按照盤點結果中的庫存差異對當前庫存進行調整。按時按照上面的例子來說，盤點差異為-2，雖然盤點結束后庫存是8，但是在提交審批后，審批過程中，倉庫有出入庫操作，實際審批通過時，庫存為6。那么當按差異值-2調整后，庫存應該為4。

回過頭讓我們再看下覆蓋調整的問題，在上面的例子中，如果直接覆蓋，則會將庫存6直接更新為8，反而是盤盈了2，與實際盤點結果是不一致的。除非在審批通過之前，倉庫庫存仍然凍結并禁止操作，這顯然對業務有較大影響，因此個人并不推薦這種做法。

四、總結

在盤點的過程中還有很多細節的設計點，比如：

• 倉庫里沒有的貨品是否允許從無盤到有呢？
• 盤點結果什么時候需要審批，什么時候不需要審批，需要誰審批？
• 審批過程中庫存異動造成的盤點結果無法執行如何處理？
• 盤點提交后是否允許撤回呢？

很多問題都需要結合實際的業務場景來設計，我這篇文章算是拋磚引玉了，大家有興趣的話，可以一起聊一聊，你們的盤點是怎么做的呢？

#專欄作家#

麋鹿產品，公眾號：麋鹿產品手冊，人人都是產品經理專欄作家。專注供應鏈挖掘提升，熱愛生活，熱愛產品。

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

題圖來自Unsplash，基于CCO協議。