原文地址：http://blog.kantli.com/theme/5
這一系列的文章，是小團隊內的實務討論稿，放出來以便有更多的交流與討論。其中多是作為一個非專業人員的實際工作體會，必然存在許多錯誤或不當之處，請多指教！
一
出庫訂單的處理，是倉庫現場一個比較重要的環節，當然，如果下游訂單是通過系統傳輸的話，可能現場對這個過程不會非常關注，因為不需要什么操作，只需要把系統處理好的訂單打印出來就行了。
即便如此，對于訂單處理流程的討論，也還是重要的，因為訂單的處理方式，與現場的工作安排關系緊密，有時候可以互相調整適應，有時候也會有相互制約的問題。
倉庫現場對于訂單有不同的分類方法，可能是按照物料類別來分的，可能是按照配送區域來分的，而就操作上分，大體可以分為兩類：
- 一種是常規訂單，也就是不用馬上操作的，可能是一個小時集中處理一次訂單，也可能是一天集中處理一次訂單，統一操作；
- 一種是臨時訂單，需要馬上安排操作的，有可能是需求非常緊急，也有可能是之前的訂單出了差錯，需要在出庫配送前進行調整。
按操作來區分，是在操作現場比較合適的辦法，這兩種訂單優先級不同，操作方式不同，操作成本也會差很多。臨時訂單是任何倉庫都在盡力避免的，這類訂單數量增加，會對現場管理提出很大的挑戰，不論是人員安排、資源調度，還是倉庫空間規劃等，都可能打破原有計劃，那么對現場管理人員的掌控力就要求很高，而且一不小心就容易出錯。
二
就常規訂單而言，現場有幾種常見的處理方式：
- 第一個是集單：
由于訂單進入的時間并不受倉庫的掌控，集中處理，集中揀貨，可以方便現場的工作安排，避免操作團隊產生不必要的等待時間。
同時，集中操作也便于庫存的管理，有些倉庫可以把入庫過程和出庫過程分開，那么，就可以有一個時間點，庫存數據是靜止不動的，比起庫存隨時變動的倉庫來說，不論是盤點還是現場規劃的調整，都要方便很多。
- 第二個是分類，也就是不同類型的訂單分開處理：
有可能是時效不同，有些訂單是需要馬上處理的，有些訂單是需要當天處理的，有些訂單可能要統一等下周處理。事實上，對于操作現場，總是傾向于把訂單留到最后一刻來操作，這樣可以節約出庫暫存區的面積。明明是下周才出庫的貨物，現在備好，完全沒有必要，如果馬上備貨馬上出庫，甚至可以臨時占用一些過道區域，現場的面積使用就松容一些。
也有可能是操作要求不同，有些訂單有特殊的包裝要求，有些訂單的貨物需要額外的加工，有些訂單還要等待一些貨物入庫之后才能完整備貨。這些訂單當然可以集中在一起操作，具體的操作要求由一線的操作人員自己判斷——但從實際情況來看，還是分開處理的效果會好一些，這種區分不是絕對的，可能只是先操作正常訂單，后操作有特殊要求的訂單。簡單的分類，就可以避免一些錯漏的問題，一線操作人員不用時刻保持警惕。我們應當時刻謹記，團隊成員的注意力，和體力一樣，也是需要節約使用的資源。
- 第三個是分批，分批也是分類的一種，但值得我們單獨討論。
分批主要是為了滿足出庫配送順序，因為貨物離開倉庫的時間是有一定批次的。限于下游客戶的收貨時間窗口、倉庫裝卸平臺的數量、出庫暫存區的面積、車輛人員的調度以及現場操作團隊的工作安排等因素，同時裝車，同時出庫是不一定合適的。
那么，根據不同線路的出庫順序安排訂單處理順序就非常有必要了。同樣的貨量，如果銜接順暢，一條線路的貨物剛出庫，另一條線路的貨物就可以使用它的暫存區，面積使用率可以提高一倍以上；而現場工作量也可以保持持續均勻，不至于讓短時間的大工作量破壞操作節奏，給人員安排帶來困難。
另一方面，就同一條配送線路的訂單而言，也有一定的操作順序。有些現場面積緊張，出庫暫存區是沒有過道空間的，那么就是說，貨物進入出庫暫存區必須與裝車順序相反，否則裝車的時候就需要再行騰挪，帶來不必要的工作量。
排定絕對訂單順序的主要挑戰在于，訂單開始處理的時間是可控的，而訂單處理過程所需要的時間并不好計算，可能后面開始處理的訂單B，因為貨量較少的原因，反而先處理好了，這個時候，是直接進入暫存區呢？還是放在一邊等待訂單A？所以，絕對的訂單操作順序實現起來并不容易，有些倉庫可以實現，是因為一個訂單需要經過揀貨和打包兩個流程，揀貨的時間不好控制，就在打包的時候控制操作順序。
- 第四個是訂單的分拆與合并。
訂單的分拆一般是由于不同庫區操作的緣故。傳統的倉庫管理，一般是整個倉庫分為不同庫區，每個庫區有專門的負責人，無論是出入庫還是盤點，都由這個人負責，因此，訂單的分拆是很常見的。分區管理的具體原因與優劣勢我們討論過，目前來說，選擇這種現場管理方式的相對少一些，但庫存管理的要求更高了，因此往往因為貨物管理要求不同而有所分區，最為典型的就是按照不同溫度區間劃分庫區，即所謂多溫共配。
因為WMS系統的普及，訂單的拆分處理已經不再有什么困難，一般來說，訂單的拆分有兩種辦法，一種是按照貨物類型進行拆分，在系統揀貨前把一個訂單分成好幾個；一種是按照庫位分區進行拆分，在系統揀貨之后生成不同庫區的揀貨單，使用的還是同一個訂單號。具體的使用，還要看現場的實際情況進行選擇。
而訂單的合并一般是出于流程上的設計。有些倉庫會使用集中揀貨的操作方式，也就是把不同訂單的貨物需求統計起來，從庫區取出貨物后再行分配，即播種式揀貨。在揀貨區范圍比較大，行走路徑比較長的情況下，使用這種辦法可以比較明顯地提高操作效率。
集中揀貨方式往往會和訂單的分批處理相結合，其目的，一方面是在現場持續接收訂單的情況下保持操作穩定有序，不會混亂串貨，另一方面，也是將單次揀貨量控制在一定范圍內，不會因為貨量太大而導致揀貨和分配操作上的困難。同樣，使用WMS系統進行訂單的合并一般沒有什么困難，只是在如何劃分批次的問題上需要費些思量。
三
訂單操作是現場操作比較重要的一塊，對于很多現場來說，是工作量占比最大的一塊。因此，現場管理人員需要保持對訂單處理流程的掌控能力，不論是空間利用還是人員安排、設備調度，都和訂單處理流程關系緊密，我們前面所說的相互調整適應或者相互制約，主要說的就是這個方面。
對于訂單處理的掌控，一般有幾個節點：
- 一個是下單，或者說訂單的接收。
無論是集單、分類處理還是分批處理，都可以在接收訂單時進行控制，目前來說，一般還是人工的，有可能是接收訂單后，人工控制導入系統的順序，也有可能是在系統收到訂單后，根據具體情況逐個決定什么時候進行處理。
主要的原因，是系統的集成度還比較低，現場操作管理模塊與配送模塊一般不在傳統WMS的考慮范圍之內。未來的趨勢，毋庸置疑，是更高的系統集成度和更高的自動化程度，一方面節約了人力，一方面也減少了出錯的可能。
- 一個是系統揀貨過程，或者說庫存的匹配。
對訂單的拆分與合并一般是在系統揀貨過程前后實現的。
- 一個是派單，或者說揀貨工作的分配。
具體的操作順序和操作形式，可以在這個節點做比較精確的掌控。有可能現場使用的是紙質揀貨單，那么，派單的過程就只能人工控制，也有可能是電子終端揀貨，派單過程就需要在WMS進行統一管理，配送線路、裝車順序、訂單類型等都需要納入考慮。
當然，不排除有些現場還有后續的操作流程，比如把打包區分出來，那么，訂單揀貨完成等待打包的過程也是一個控制節點。
操作現場的目標，是在這些控制節點上不斷調整，找到一個合適的節奏，從而達到一個在安全和效率上比較滿意的狀態。具體來說：
- 貨物暫存區面積控制在一定范圍內，盡量縮短出庫暫存時間，提高單位面積利用率；
- 現場工作量穩定均勻，避免操作量集中在特定時段或者操作人員不必要的等待時間，通常這是主要考慮因素；
- 現場的裝卸站臺、機械設備等得到充分利用，事實上，主要是克服它們帶來的限制；
- 整體操作流程順暢有序，動線上沒有沖突，節奏上留有余地；
- 協調好配送車輛的調度、下游收貨時間窗口；
以上是我們對訂單處理流程的一些簡單討論。
四
話說回來，在現場實踐過程中，會碰到各種各樣的問題，有些是容易解決的，有些是不太好處理的，現場人員還是得根據具體情況做好區分，哪些是經常性的問題，需要制定專門的流程進行對付，哪些是偶發性的問題，主要靠臨時調整來解決。
就我們的經驗來說，一個比較頭疼的問題是訂單處理過程中的庫存管理問題，有兩種情況：
- 一種是揀貨出錯導致的。揀貨過程當然難免會有一些錯誤，比如說，本來需要SKU代碼為A的貨物，結果錯拿了SKU代碼為B的貨物。一般的操作過程，是進行更換，如果是靈活庫位制，同一種SKU在存儲在多個不同庫位上，我們就比較頭疼了，這個A貨物我們當然知道要在哪個庫位揀貨，因為有揀貨單，但這個B貨物應該放回到哪個庫位呢？
最準確的辦法是對所有庫位上的B貨物進行盤點，從而判斷應該歸還到哪里。但在緊張的現場操作過程中，這樣的盤點是極為耗時耗力的，而且在出入庫過程中，系統庫存和庫位上的實際庫存都在不斷變動，基本沒法進行盤點。
這個問題的結果，就是系統庫存與實物庫存不能準確對應，那么就會有揀貨單要求到某個庫位揀貨，結果那個庫位沒有貨物的情況。而對這個問題的處理，有不同的思路：
- 一個是不處理，直接放置在某個特定的暫存區，如果后面有庫位上找不到貨的情況，就到這個暫存區尋找，直到下一個盤點節點再把貨物放回庫位。
- 一個是隨便放到一個存儲有該SKU的庫位上并進行登記，等待下一次實物揀貨失敗再來查詢解決，一直等到下一個盤點節點完成實物數量與系統數量的重新準確對應。
當然，相對根本一點的辦法，還是在揀貨時進行庫位與貨物條碼的掃描，掃描的過程，一個是系統上的進出確認，一個是對SKU正確與否的復核，那么出錯率自然可以控制在一個非常小的區間，只是這個辦法并不是在每一個倉庫都有可操作性。
- 另一種是訂單出錯導致的。尤其在人工下單過程中，不可避免地會有出錯的時候，如果是需求100個，結果下單寫成1個，對倉庫是沒有太大影響的，無非是后期可能需要處理一個緊急訂單；如果是需求1個，結果下單寫成100個，現場就比較頭疼了，可能總體庫存不足，那么，這邊錯誤的需求滿足了，其它99個訂單的需求就無法滿足了，后果很嚴重。
同樣的問題，也可能因為供應短缺造成，比方說，某種SKU暫時供應不上，需要在不同門店間進行平均分配，待后續供應上之后再緊急補充，而這個信息只有倉庫人員掌握，下單人員是不掌握的。正常來說，系統匹配庫存的邏輯，是先匹配的訂單先滿足，這個邏輯解決不了平均分配的問題。
這個問題的處理一般有兩種辦法：
- 一種是修改訂單，那么問題來了，除非比較有經驗的操作人員，可能在整個過程中現場都不會發現有什么問題，或者說，發現問題的時候，大多數訂單都已經處理完成了，這個時候再修改訂單已經沒有意義了。
所以，有些現場會有人工審核訂單的動作，雖然低效繁瑣，但在下單操作極不規范的情況下，是滿足客戶需求一個不得不采取的辦法。當然，審核訂單的工作，逐步可以通過系統來完成，通過對歷史訂單數據的統計，判定一個需求是否在正常范圍內并不是非常困難，只是未免有殺雞用牛刀之感。
- 另一種是后期針對單個SKU進行退回和重新下單，在實際貨物出庫之前，這種操作終歸是為時未晚的，不過對于WMS的設計要求比較高。
當然，隨著系統在上下游的集成度越來越高，這個問題也就逐步得到解決了，一方面是供應商對于需求量有了更準確的把握，另一方面，下單過程也越來越自動化，下單人員只需要確定一定期間內需要維持的庫存量就可以了，訂單數據都可以自動生成。
從這兩個庫存管理問題來看，我們對于倉儲過程的信息化是充滿期望的——在一些技術細節上，我們往往能很明確地看到未來在哪里，只是還差一步步走過去。
