很多電商企業(yè)做到一定規(guī)模后會把庫存外包給專業(yè)的第三方倉儲企業(yè)去管理，與自己管理倉庫不同，很多信息上的溝通如果做的不到位的話，即使第三方倉儲企業(yè)再專業(yè)，也會導致很多庫存問題。比如：

　　入庫異常：

　　商家下屬各供應商、工廠入倉質(zhì)量無法管控，導致入倉數(shù)據(jù)從源頭上就出錯。如果在入倉環(huán)節(jié)供應商和廠家沒配合好，就會增加倉庫收貨作業(yè)難度和成本，這些成本最終都會轉(zhuǎn)移到電商企業(yè)自身。作為第三方倉儲企業(yè)，能夠輔助商家搞好對供應商的管理，于雙方都是很有意義的事情。

　　超賣：

　　俗話說“天下武功，唯快不破”。電商行業(yè)和傳統(tǒng)銷售行業(yè)相比，效率高、速度快。一個爆款出現(xiàn)，瞬時會有大量的訂單出現(xiàn)。因為前后臺庫存數(shù)據(jù)不一致導致訂單超賣。而各大電商平臺為了對消費者的體驗負責，對超賣會有嚴格的控制，甚至有些懲罰措施，比如天貓對超賣訂單會要求商家賠償30%的貨值給消費者。如果前后臺的庫存沒銜接好，即使倉內(nèi)的庫存是OK的，前臺未必能上架正確的庫存數(shù)量，由此帶來給商家和買家的損失就不可避免了。

　　出庫與結算環(huán)節(jié)的糾紛：

　　電商的這種“快”往往會讓倉庫作業(yè)處于非常被動的地步——快速入倉，以便盡快發(fā)貨，快速發(fā)貨，以便客戶體驗好。賣的不好的話，快速退倉，以便盡快尋找其他銷貨渠道。因為這種“快”，讓倉內(nèi)來不及對庫存進行細致的管理和反饋，導致在退倉的時候有糾紛。這種糾紛會耗費雙方業(yè)務和結算人員大量的精力去舉證、判責，嚴重的會影響到雙方的合作。

　　滯倉費計算：

　　一般情況下，滯倉費會遵循先進先出的原則，跟進商品滯倉天數(shù)去計算滯倉費，但滯倉費的計算是基于一個準確的庫存數(shù)量的。如果庫存數(shù)量錯誤，滯倉費也就會產(chǎn)生各種糾紛。

　　上述問題的出現(xiàn)，歸根到底是“庫存管理”的問題。我相信大部分的倉儲企業(yè)對庫存管理都有一套非常完善非常專業(yè)的機制，沒有專業(yè)的倉庫管理經(jīng)驗，無意在各位倉庫管理專家面前班門弄斧。但認為，電商與倉庫的庫存管理，應該站在“聯(lián)動”的角度看，確保過程和結果都是準確的。本文不討論倉庫庫存管理的細節(jié)，重點分享下電商和第三方倉儲如何聯(lián)動管好庫存。

　　1.源頭準：規(guī)范供應商入倉，從源頭上確保庫存準確

　　和傳統(tǒng)企業(yè)一樣，很多有點規(guī)模的電商企業(yè)的貨源可能來自多個供貨商，這些供貨商的管理水平可能參差不齊。能否規(guī)范入倉要看商家對供應商的約束能力和倉庫對入倉異常的及時反饋。有些中小型電商企業(yè)對供應商（工廠）的把控能力太弱。

加上“唯快不破”，訂貨周期大大縮短，銷售周期又存在巨大的不確定性，導致工廠備貨的時間非常短。入倉時產(chǎn)生異常也就見怪不怪了。

　　這些常見的異常是：　l供應商發(fā)貨延遲，導致倉庫來不及收貨，影響電商店鋪的銷售計劃。尤其是在大促時期，如果供貨商沒及時發(fā)貨會對倉庫收貨和發(fā)貨產(chǎn)生重大影響，會嚴重影響電商平臺對店鋪的評分和消費者體驗。

　　貨品包裝不規(guī)范。有些品牌商如李寧、美邦等對供貨商的管理是非常完善的，供貨商會嚴格按照指定的包裝入倉，嘜頭、包裝規(guī)范。但很多中小型電商未必能對供應商有這么強的把控能力。嘜頭貼錯、包裝不統(tǒng)一。有些甚至直接拿個大編織袋來裝貨，給倉庫收貨清點造成了很大困難。

　　條碼錯誤：個別工廠未按照倉庫和商家要求打條碼，或者張貼了錯誤的條碼。

　　這種現(xiàn)象經(jīng)常出現(xiàn)在服裝行業(yè)。貼碼和水洗標、箱外的嘜頭不一致，會導致倉庫清點錯誤。如果倉庫在入倉環(huán)節(jié)未及時發(fā)現(xiàn)，后面的發(fā)貨環(huán)節(jié)發(fā)錯貨就不可避免了。

　　分批到倉：一般情況下，一個入庫單對應一次入庫行為，有些供貨商因為準備不足或者其他問題會采用分批到貨的方式入倉。

對一些需要進行批次管理的商品來說，分批到倉會導致倉庫對批次的混淆。也會影響到銷售端對不同產(chǎn)品的批次定價和倉庫端對滯倉費的計算。

　　數(shù)量差異：供貨商未按照商家指定的數(shù)量入倉，倉庫在入倉環(huán)節(jié)要反復和商家、供貨商兩邊確認，影響入倉作業(yè)

　　貨品混裝：不同SKU的商品混裝在一個大包裝內(nèi)，導致倉庫收貨混亂，清點時間加長，收錯貨的風險也增高。

　　QC問題，有些商品需要根據(jù)電商平臺進行倉內(nèi)QC，需要倉內(nèi)配合。如果商家未協(xié)調(diào)好QC和倉庫的作業(yè)時間，會導致QC延遲和收貨延遲。

　　上述問題，總結一起就是商家缺乏對供貨商的管控。由此帶來倉庫入倉清點難度加大，出錯比例增高、收貨延遲，后續(xù)的發(fā)貨延遲和發(fā)錯貨的風險也增高。要解決上述問題，一方面要需要倉庫忠實的記錄和反饋入倉過程中的各種異常，及時的反饋給商家。

　　商家要在和供貨商的協(xié)議中明確這些問題點，對這些點進行量化和追責，讓供貨商一起來承擔由此帶來的損失。逐漸的讓供貨商提升入倉能力，規(guī)范入倉。目前所負責的倉庫是這么做的：

2.過程準：確保倉庫后臺庫存變動和前臺能實時同步，確保不超賣

　　保證過程準主要靠兩點：一個是倉內(nèi)的管理，另一個是倉庫WMS系統(tǒng)和店鋪ERP系統(tǒng)及電商平臺的商家后臺的庫存同步機制。

　　1)倉內(nèi)管理：這點不詳細展開，倉庫專業(yè)人員的專業(yè)能力是應該相信的，只是簡單說幾點：

　　a)關于庫存變動：商品入倉后，因各種原因會導致庫存變動，倉庫要忠實且及時的把這種變動記錄下來，并通過系統(tǒng)接口同步給店鋪ERP系統(tǒng)及電商平臺的商家后臺。主要有以下幾種場景：

　　正次品轉(zhuǎn)換：入倉的時候是正品的可發(fā)貨庫存，實際揀貨的時候發(fā)現(xiàn)是次品，不可發(fā)貨。這種情況下倉庫需要扣減一個正品庫存，增加一個次品庫存。

　　倉庫丟貨：倉庫盤點發(fā)現(xiàn)貨物短少，需要扣減庫存。

　　倉庫多發(fā)貨、少發(fā)貨、發(fā)錯貨：倉庫發(fā)錯貨，需要對庫存進行調(diào)整。

　　倉庫盤點錯誤：上次盤點錯誤，在本次盤點中糾正，需要對庫存進行調(diào)整。

　　錯碼調(diào)整：入倉時未發(fā)現(xiàn)編碼錯誤，在庫內(nèi)管理或者發(fā)貨環(huán)節(jié)進行調(diào)整。

　　退件入倉或者截單成功：前臺訂單取消已經(jīng)發(fā)貨的訂單，倉庫需要截單，如果快遞截單成功或者被買家拒收退回倉庫，倉庫需要對庫存進行調(diào)整。

　　上述庫存調(diào)整場景，有些是需要商家承擔責任的，比如正次品轉(zhuǎn)換，有些是需要倉庫承擔責任的，比如丟貨、發(fā)錯貨。不管是誰的責任，倉庫都要忠實記錄，及時反饋，時刻保持前后臺庫存數(shù)據(jù)一致。

　　b)關于倉內(nèi)盤點：作為倉內(nèi)的日常作業(yè)行為，每個倉庫都會有各種盤點規(guī)則，如月度的、季度的大盤點、循環(huán)盤點、動碰盤點等等。但我們在實踐中發(fā)現(xiàn)，倉內(nèi)的盤點規(guī)則未必就是適合電商行業(yè)應用的。為此我們經(jīng)過一段時間的摸索，探索出以下幾個盤點原則：

　　月初庫存低于20個的商品全量盤點：庫存低于20個的時候，我們認為就有超賣的風險。請倉庫在月初對低于20個的SKU進行全盤，盤點結果反饋給商家ERP系統(tǒng)和店鋪后臺。如果有差異的話，店鋪后臺自動更新上架數(shù)量。

　　當天庫存低于20個的商品當天盤點：同上，確保當天低于20個的商品不產(chǎn)生超賣。

　　庫存有差異實時盤點：利用系統(tǒng)功能，每天自動比對店鋪上架數(shù)量、ERP庫存數(shù)量和倉庫庫存數(shù)量，對有差異的數(shù)據(jù)自動生成盤點請求，請倉庫納入到自己的盤點計劃中去，并把盤點結果同步給ERP和商家的店鋪后臺。

　　活動后盤點：電商企業(yè)和傳統(tǒng)企業(yè)不同的一點，如果有大流量灌入或者預計的大型促銷活動，會在短時間內(nèi)產(chǎn)生大量訂單。這些訂單一般集中于有限的幾個或者幾十個SKU。當活動過后，需要倉庫倉庫對這些SKU進行盤點，以保證庫存的準確。

　　退倉前盤點：為了確保退倉時的數(shù)量是準確的，有必要在退倉前對庫存進行盤點，以便按照正確的數(shù)量退倉。

2)發(fā)貨：確保發(fā)貨過程中不錯發(fā)、漏發(fā)、多發(fā)。倉內(nèi)一般都有非常規(guī)范的流程，在幾個關鍵節(jié)點把控好就好了：

　　揀貨環(huán)節(jié)：確保揀貨SKU和數(shù)量和訂單一致。

　　包裝環(huán)節(jié)：包裝臺最好兩道符合環(huán)節(jié)，一道系統(tǒng)（把槍掃描），一道人工。

　　交付快遞環(huán)節(jié)：特別關注退款訂單和訂單內(nèi)容有修改的訂單。

　　3.結果準：所謂結果準，指的是在退倉和結算的時候，能夠有非常清晰的進銷存數(shù)據(jù)。

　　即使有庫存差異，也能找到具體的原因，能夠?qū)ω熑畏竭M行追責，確保商家和倉庫、供應商在退倉和結算環(huán)節(jié)沒有糾紛。

　　剛剛接手倉庫時，一直為出庫環(huán)節(jié)頭疼：商家說倉庫丟貨了，倉庫說是商家入倉的時候少裝了。商家說你不給我賠我就不退倉，倉庫說你不退倉我就收你滯倉費！商家說我就不給！一筆糊涂賬，讓人好生頭疼！

　　經(jīng)過一段時間的磨合，我們總結出來退倉5大原則：

　　退倉前商品下架原則：退倉前商家要將商品從店鋪下架，以免退倉單生成后店鋪還有訂單流入，對倉庫的退倉工作造成干擾。這個最好通過系統(tǒng)實現(xiàn)，人工干預會有遺漏的可能。

　　退倉前盤點原則：退倉前倉庫必須對要退倉的商品進行盤點，盤點結果及時通報給商家，并在系統(tǒng)中進行同步更新。這樣做兩個好處：一個是商家可以盡快確認是否對退倉數(shù)量有疑問，另外一個是系統(tǒng)中同步更新后，可以按照盤點的結果生成準確的退倉單。

　　庫存差異數(shù)據(jù)當場追償原則：如果庫存有差異，當場追責。追責的依據(jù)就是倉庫WMS和店鋪ERP兩邊的進銷存數(shù)據(jù)。所有的庫存變動必須基于單據(jù)，入庫單、發(fā)貨訂單、庫內(nèi)調(diào)整單、退倉單。這樣在庫存產(chǎn)生差異時，能夠直接找到對應的單據(jù)：是倉庫沒上傳發(fā)貨數(shù)據(jù)還是倉內(nèi)庫存丟失一目了然。所有的單據(jù)尤其是庫存調(diào)整單必須有明確的調(diào)整原因。這樣在退倉和結算時可以立即確認誰來承擔責任。

　　追責和退倉兩條線原則：有了上面的盤點原則和追償原則，商家和倉庫不能再以任何借口不退倉，追責和退倉兩條線分開走。這樣不會因?qū)ν藗}數(shù)量有爭議而延遲退倉，也就解決了上文中提到的各種糾紛。

　　月臺交接原則：這個主要是為了避免雙方對已經(jīng)交接的退倉數(shù)量有爭議。實際操作過程中，以月臺交接為界，雙方對退倉數(shù)據(jù)進行簽字確認，事后不得反悔。該原則在具體執(zhí)行的時候，有些商家是采用第三方物流送貨和退倉，第三方物流對交接數(shù)據(jù)可能不太負責。這點還有待商榷。

　　4.系統(tǒng)功能：

　　上述文字主要總結了庫存管理過程中商家、倉庫、供應商具體操作層面的內(nèi)容。除了這些，系統(tǒng)功能要能夠跟得上去。所在公司的系統(tǒng)和倉庫經(jīng)過一段時間的努力，通過以下功能確保庫存管理的準確。

　　1)ERP系統(tǒng)要有完善的鋪貨功能：很多大商家都是多平臺、多店鋪、多渠道銷售。不同的渠道對上架數(shù)量的邏輯也不同。比如淘寶支持拍下減庫存和付款減庫存。為了不產(chǎn)生超賣，ERP系統(tǒng)需要由完善的鋪貨系統(tǒng)，能夠?qū)崿F(xiàn)多渠道共享庫存和按渠道鎖定庫存。

　　2)庫存調(diào)整實時同步：倉內(nèi)庫存調(diào)整時，能實時同步給店鋪ERP系統(tǒng)，從而觸發(fā)電商后臺的上架數(shù)量進行調(diào)整。這個調(diào)整都是有具體的調(diào)整原因的，以便在后續(xù)對相關方追責。

　　3)每日定時生成庫存比對報告：店鋪ERP系統(tǒng)和倉庫WMS系統(tǒng)每日凌晨2點在庫存作業(yè)停止時進行自動的庫存比對，把兩邊的庫存比對差異生成報告，提交給雙方。倉庫會根據(jù)差異報告主動查找差異原因，確認需要調(diào)整庫存的，就對庫存進行調(diào)整，然后同步給前臺。

　　4)進銷存功能：這個是幾乎所有的ERP和WMS都有的功能，但怎樣能更方便的讓倉庫和商家發(fā)現(xiàn)庫存差異的原因，是需要負責系統(tǒng)的產(chǎn)品經(jīng)理們努力的。的公司把該功能做成工具，讓商家和倉庫在很多場景下能夠快速調(diào)用該功能，快速定位庫存差異原因。

　　5)庫存盤點打通：這點在前面已經(jīng)有所涉及，倉庫的盤點規(guī)則和商家所希望的盤點規(guī)則是不一樣的，通過庫存盤點打通，ERP自動把商家希望盤點的SKU發(fā)送給WMS，WMS在盤點后反饋數(shù)據(jù)給ERP。

　　6)0庫存同步機制：盡管上面做了那么多運營和系統(tǒng)上的工作，為了絕對避免超賣，我們還需要個“保險”。這個“保險”就是0庫存同步：當庫存可揀貨數(shù)量為0時，實時同步給ERP，ERP強制觸發(fā)商家店鋪后臺下架。

　　總結一下：電商的本質(zhì)是商務，零售是商務的具體表現(xiàn)形態(tài)。玩零售往大了說是玩供應鏈，往小了說就是玩庫存。庫存準不準不僅僅是倉庫的事情，是需要供應鏈上下游各方共同參與才能搞定的！