原文地址：http://blog.kantli.com/theme/5
這一系列的文章坊罢，是小團隊內的實務討論稿歉铝，放出來以便有更多的交流與討論。其中多是作為一個非專業(yè)人員的實際工作體會爹脾，必然存在許多錯誤或不當之處惭婿，請多指教！
一
出庫訂單的處理歌憨，是倉庫現(xiàn)場一個比較重要的環(huán)節(jié)着憨，當然，如果下游訂單是通過系統(tǒng)傳輸?shù)脑捨竦眨赡墁F(xiàn)場對這個過程不會非常關注甲抖，因為不需要什么操作，只需要把系統(tǒng)處理好的訂單打印出來就行了心铃。
即便如此准谚，對于訂單處理流程的討論，也還是重要的于个，因為訂單的處理方式，與現(xiàn)場的工作安排關系緊密暮顺，有時候可以互相調整適應厅篓，有時候也會有相互制約的問題秀存。
倉庫現(xiàn)場對于訂單有不同的分類方法，可能是按照物料類別來分的羽氮，可能是按照配送區(qū)域來分的或链，而就操作上分，大體可以分為兩類：
- 一種是常規(guī)訂單档押，也就是不用馬上操作的澳盐，可能是一個小時集中處理一次訂單，也可能是一天集中處理一次訂單令宿，統(tǒng)一操作叼耙；
- 一種是臨時訂單，需要馬上安排操作的粒没，有可能是需求非常緊急筛婉，也有可能是之前的訂單出了差錯，需要在出庫配送前進行調整癞松。
按操作來區(qū)分爽撒，是在操作現(xiàn)場比較合適的辦法，這兩種訂單優(yōu)先級不同响蓉，操作方式不同硕勿，操作成本也會差很多。臨時訂單是任何倉庫都在盡力避免的枫甲，這類訂單數(shù)量增加源武，會對現(xiàn)場管理提出很大的挑戰(zhàn)，不論是人員安排言秸、資源調度软能，還是倉庫空間規(guī)劃等，都可能打破原有計劃举畸，那么對現(xiàn)場管理人員的掌控力就要求很高查排，而且一不小心就容易出錯。
二
就常規(guī)訂單而言抄沮，現(xiàn)場有幾種常見的處理方式：
- 第一個是集單：
由于訂單進入的時間并不受倉庫的掌控跋核，集中處理，集中揀貨叛买，可以方便現(xiàn)場的工作安排砂代，避免操作團隊產生不必要的等待時間。
同時率挣，集中操作也便于庫存的管理刻伊，有些倉庫可以把入庫過程和出庫過程分開，那么，就可以有一個時間點捶箱，庫存數(shù)據(jù)是靜止不動的智什，比起庫存隨時變動的倉庫來說，不論是盤點還是現(xiàn)場規(guī)劃的調整丁屎，都要方便很多荠锭。
- 第二個是分類，也就是不同類型的訂單分開處理：
有可能是時效不同晨川，有些訂單是需要馬上處理的证九，有些訂單是需要當天處理的，有些訂單可能要統(tǒng)一等下周處理共虑。事實上愧怜，對于操作現(xiàn)場，總是傾向于把訂單留到最后一刻來操作看蚜，這樣可以節(jié)約出庫暫存區(qū)的面積叫搁。明明是下周才出庫的貨物，現(xiàn)在備好供炎，完全沒有必要渴逻，如果馬上備貨馬上出庫，甚至可以臨時占用一些過道區(qū)域音诫，現(xiàn)場的面積使用就松容一些惨奕。
也有可能是操作要求不同，有些訂單有特殊的包裝要求竭钝，有些訂單的貨物需要額外的加工梨撞，有些訂單還要等待一些貨物入庫之后才能完整備貨。這些訂單當然可以集中在一起操作香罐，具體的操作要求由一線的操作人員自己判斷——但從實際情況來看卧波，還是分開處理的效果會好一些，這種區(qū)分不是絕對的庇茫，可能只是先操作正常訂單港粱，后操作有特殊要求的訂單。簡單的分類旦签，就可以避免一些錯漏的問題查坪，一線操作人員不用時刻保持警惕。我們應當時刻謹記宁炫，團隊成員的注意力偿曙，和體力一樣，也是需要節(jié)約使用的資源羔巢。
- 第三個是分批望忆，分批也是分類的一種罩阵，但值得我們單獨討論。
分批主要是為了滿足出庫配送順序启摄，因為貨物離開倉庫的時間是有一定批次的永脓。限于下游客戶的收貨時間窗口、倉庫裝卸平臺的數(shù)量鞋仍、出庫暫存區(qū)的面積、車輛人員的調度以及現(xiàn)場操作團隊的工作安排等因素搅吁，同時裝車威创，同時出庫是不一定合適的。
那么谎懦，根據(jù)不同線路的出庫順序安排訂單處理順序就非常有必要了肚豺。同樣的貨量，如果銜接順暢界拦，一條線路的貨物剛出庫吸申，另一條線路的貨物就可以使用它的暫存區(qū)，面積使用率可以提高一倍以上享甸；而現(xiàn)場工作量也可以保持持續(xù)均勻截碴，不至于讓短時間的大工作量破壞操作節(jié)奏，給人員安排帶來困難蛉威。
另一方面日丹，就同一條配送線路的訂單而言，也有一定的操作順序蚯嫌。有些現(xiàn)場面積緊張哲虾，出庫暫存區(qū)是沒有過道空間的，那么就是說择示，貨物進入出庫暫存區(qū)必須與裝車順序相反束凑，否則裝車的時候就需要再行騰挪，帶來不必要的工作量栅盲。
排定絕對訂單順序的主要挑戰(zhàn)在于汪诉，訂單開始處理的時間是可控的，而訂單處理過程所需要的時間并不好計算剪菱，可能后面開始處理的訂單B摩瞎，因為貨量較少的原因，反而先處理好了孝常，這個時候旗们，是直接進入暫存區(qū)呢？還是放在一邊等待訂單A构灸？所以上渴，絕對的訂單操作順序實現(xiàn)起來并不容易岸梨，有些倉庫可以實現(xiàn)，是因為一個訂單需要經(jīng)過揀貨和打包兩個流程稠氮，揀貨的時間不好控制曹阔，就在打包的時候控制操作順序。
- 第四個是訂單的分拆與合并隔披。
訂單的分拆一般是由于不同庫區(qū)操作的緣故赃份。傳統(tǒng)的倉庫管理，一般是整個倉庫分為不同庫區(qū)奢米，每個庫區(qū)有專門的負責人抓韩，無論是出入庫還是盤點，都由這個人負責鬓长，因此谒拴，訂單的分拆是很常見的。分區(qū)管理的具體原因與優(yōu)劣勢我們討論過涉波，目前來說英上，選擇這種現(xiàn)場管理方式的相對少一些，但庫存管理的要求更高了啤覆，因此往往因為貨物管理要求不同而有所分區(qū)苍日，最為典型的就是按照不同溫度區(qū)間劃分庫區(qū)，即所謂多溫共配窗声。
因為WMS系統(tǒng)的普及易遣，訂單的拆分處理已經(jīng)不再有什么困難，一般來說嫌佑，訂單的拆分有兩種辦法豆茫，一種是按照貨物類型進行拆分，在系統(tǒng)揀貨前把一個訂單分成好幾個屋摇；一種是按照庫位分區(qū)進行拆分揩魂，在系統(tǒng)揀貨之后生成不同庫區(qū)的揀貨單，使用的還是同一個訂單號炮温。具體的使用火脉，還要看現(xiàn)場的實際情況進行選擇。
而訂單的合并一般是出于流程上的設計柒啤。有些倉庫會使用集中揀貨的操作方式倦挂，也就是把不同訂單的貨物需求統(tǒng)計起來，從庫區(qū)取出貨物后再行分配担巩，即播種式揀貨方援。在揀貨區(qū)范圍比較大，行走路徑比較長的情況下涛癌，使用這種辦法可以比較明顯地提高操作效率犯戏。
集中揀貨方式往往會和訂單的分批處理相結合送火，其目的，一方面是在現(xiàn)場持續(xù)接收訂單的情況下保持操作穩(wěn)定有序先匪，不會混亂串貨种吸，另一方面，也是將單次揀貨量控制在一定范圍內呀非，不會因為貨量太大而導致揀貨和分配操作上的困難坚俗。同樣，使用WMS系統(tǒng)進行訂單的合并一般沒有什么困難岸裙，只是在如何劃分批次的問題上需要費些思量坦冠。
三
訂單操作是現(xiàn)場操作比較重要的一塊，對于很多現(xiàn)場來說哥桥，是工作量占比最大的一塊。因此激涤，現(xiàn)場管理人員需要保持對訂單處理流程的掌控能力拟糕，不論是空間利用還是人員安排、設備調度倦踢，都和訂單處理流程關系緊密送滞，我們前面所說的相互調整適應或者相互制約，主要說的就是這個方面辱挥。
對于訂單處理的掌控犁嗅，一般有幾個節(jié)點：
- 一個是下單，或者說訂單的接收晤碘。
無論是集單褂微、分類處理還是分批處理，都可以在接收訂單時進行控制园爷，目前來說宠蚂，一般還是人工的，有可能是接收訂單后童社，人工控制導入系統(tǒng)的順序求厕，也有可能是在系統(tǒng)收到訂單后，根據(jù)具體情況逐個決定什么時候進行處理扰楼。
主要的原因呀癣，是系統(tǒng)的集成度還比較低，現(xiàn)場操作管理模塊與配送模塊一般不在傳統(tǒng)WMS的考慮范圍之內弦赖。未來的趨勢项栏，毋庸置疑，是更高的系統(tǒng)集成度和更高的自動化程度蹬竖，一方面節(jié)約了人力忘嫉，一方面也減少了出錯的可能荤牍。
- 一個是系統(tǒng)揀貨過程，或者說庫存的匹配庆冕。
對訂單的拆分與合并一般是在系統(tǒng)揀貨過程前后實現(xiàn)的康吵。
- 一個是派單，或者說揀貨工作的分配访递。
具體的操作順序和操作形式晦嵌，可以在這個節(jié)點做比較精確的掌控。有可能現(xiàn)場使用的是紙質揀貨單拷姿，那么惭载，派單的過程就只能人工控制，也有可能是電子終端揀貨响巢，派單過程就需要在WMS進行統(tǒng)一管理描滔，配送線路、裝車順序踪古、訂單類型等都需要納入考慮含长。
當然，不排除有些現(xiàn)場還有后續(xù)的操作流程伏穆，比如把打包區(qū)分出來拘泞，那么，訂單揀貨完成等待打包的過程也是一個控制節(jié)點枕扫。
操作現(xiàn)場的目標陪腌，是在這些控制節(jié)點上不斷調整，找到一個合適的節(jié)奏烟瞧，從而達到一個在安全和效率上比較滿意的狀態(tài)诗鸭。具體來說：
- 貨物暫存區(qū)面積控制在一定范圍內，盡量縮短出庫暫存時間参滴，提高單位面積利用率只泼；
- 現(xiàn)場工作量穩(wěn)定均勻，避免操作量集中在特定時段或者操作人員不必要的等待時間卵洗，通常這是主要考慮因素请唱；
- 現(xiàn)場的裝卸站臺、機械設備等得到充分利用过蹂，事實上十绑，主要是克服它們帶來的限制；
- 整體操作流程順暢有序酷勺，動線上沒有沖突本橙，節(jié)奏上留有余地；
- 協(xié)調好配送車輛的調度脆诉、下游收貨時間窗口甚亭；
以上是我們對訂單處理流程的一些簡單討論贷币。
四
話說回來，在現(xiàn)場實踐過程中亏狰，會碰到各種各樣的問題役纹，有些是容易解決的，有些是不太好處理的暇唾，現(xiàn)場人員還是得根據(jù)具體情況做好區(qū)分促脉，哪些是經(jīng)常性的問題，需要制定專門的流程進行對付策州，哪些是偶發(fā)性的問題瘸味，主要靠臨時調整來解決。
就我們的經(jīng)驗來說够挂，一個比較頭疼的問題是訂單處理過程中的庫存管理問題旁仿，有兩種情況：
- 一種是揀貨出錯導致的。揀貨過程當然難免會有一些錯誤孽糖，比如說枯冈，本來需要SKU代碼為A的貨物，結果錯拿了SKU代碼為B的貨物梭姓。一般的操作過程，是進行更換嫩码，如果是靈活庫位制誉尖，同一種SKU在存儲在多個不同庫位上，我們就比較頭疼了铸题，這個A貨物我們當然知道要在哪個庫位揀貨赋元，因為有揀貨單涌献，但這個B貨物應該放回到哪個庫位呢？
最準確的辦法是對所有庫位上的B貨物進行盤點，從而判斷應該歸還到哪里段直。但在緊張的現(xiàn)場操作過程中，這樣的盤點是極為耗時耗力的恳邀，而且在出入庫過程中雳锋，系統(tǒng)庫存和庫位上的實際庫存都在不斷變動，基本沒法進行盤點饮六。
這個問題的結果其垄，就是系統(tǒng)庫存與實物庫存不能準確對應，那么就會有揀貨單要求到某個庫位揀貨卤橄，結果那個庫位沒有貨物的情況绿满。而對這個問題的處理，有不同的思路：
- 一個是不處理窟扑，直接放置在某個特定的暫存區(qū)喇颁，如果后面有庫位上找不到貨的情況漏健，就到這個暫存區(qū)尋找，直到下一個盤點節(jié)點再把貨物放回庫位橘霎。
- 一個是隨便放到一個存儲有該SKU的庫位上并進行登記蔫浆，等待下一次實物揀貨失敗再來查詢解決，一直等到下一個盤點節(jié)點完成實物數(shù)量與系統(tǒng)數(shù)量的重新準確對應茎毁。
當然克懊，相對根本一點的辦法，還是在揀貨時進行庫位與貨物條碼的掃描七蜘，掃描的過程谭溉，一個是系統(tǒng)上的進出確認，一個是對SKU正確與否的復核橡卤，那么出錯率自然可以控制在一個非常小的區(qū)間扮念，只是這個辦法并不是在每一個倉庫都有可操作性。
- 另一種是訂單出錯導致的碧库。尤其在人工下單過程中柜与，不可避免地會有出錯的時候，如果是需求100個嵌灰，結果下單寫成1個弄匕，對倉庫是沒有太大影響的，無非是后期可能需要處理一個緊急訂單沽瞭；如果是需求1個迁匠，結果下單寫成100個，現(xiàn)場就比較頭疼了驹溃，可能總體庫存不足城丧，那么，這邊錯誤的需求滿足了豌鹤，其它99個訂單的需求就無法滿足了亡哄，后果很嚴重。
同樣的問題布疙，也可能因為供應短缺造成蚊惯，比方說，某種SKU暫時供應不上灵临，需要在不同門店間進行平均分配拣挪，待后續(xù)供應上之后再緊急補充，而這個信息只有倉庫人員掌握俱诸，下單人員是不掌握的菠劝。正常來說，系統(tǒng)匹配庫存的邏輯，是先匹配的訂單先滿足赶诊，這個邏輯解決不了平均分配的問題笼平。
這個問題的處理一般有兩種辦法：
- 一種是修改訂單，那么問題來了舔痪，除非比較有經(jīng)驗的操作人員寓调，可能在整個過程中現(xiàn)場都不會發(fā)現(xiàn)有什么問題，或者說锄码，發(fā)現(xiàn)問題的時候夺英，大多數(shù)訂單都已經(jīng)處理完成了，這個時候再修改訂單已經(jīng)沒有意義了滋捶。
所以痛悯，有些現(xiàn)場會有人工審核訂單的動作，雖然低效繁瑣重窟，但在下單操作極不規(guī)范的情況下载萌，是滿足客戶需求一個不得不采取的辦法。當然巡扇，審核訂單的工作扭仁，逐步可以通過系統(tǒng)來完成，通過對歷史訂單數(shù)據(jù)的統(tǒng)計厅翔，判定一個需求是否在正常范圍內并不是非常困難乖坠，只是未免有殺雞用牛刀之感。
- 另一種是后期針對單個SKU進行退回和重新下單刀闷，在實際貨物出庫之前熊泵，這種操作終歸是為時未晚的，不過對于WMS的設計要求比較高涩赢。
當然戈次，隨著系統(tǒng)在上下游的集成度越來越高轩勘，這個問題也就逐步得到解決了筒扒，一方面是供應商對于需求量有了更準確的把握，另一方面绊寻，下單過程也越來越自動化花墩，下單人員只需要確定一定期間內需要維持的庫存量就可以了，訂單數(shù)據(jù)都可以自動生成澄步。
從這兩個庫存管理問題來看冰蘑，我們對于倉儲過程的信息化是充滿期望的——在一些技術細節(jié)上，我們往往能很明確地看到未來在哪里村缸，只是還差一步步走過去祠肥。
