仓储治理（四）：出库拣货

订单发货是仓库事情量最大的一项事情， 紧张步骤有拣货、复核、打包、称重、交卸等。

这中间拣货最为繁重，拣货员须要按照打算机指令找到订单商品所在的库位，然后从库位上拣出订单须要的商品，末了送到发货区完成订单的打包发货，下面我们来详细说一下拣货这件事。

我们假设场景，某仓库，每天有几万订单须要发货，我们剖析了一下这些订单，创造有这几种类型的订单：

单品单件：每个订单只要一种商品，且数量只要1件 ；单品多件：每个订单只要一种商品，但数量须要多件，可能是2件，也可能是3件、4件、5件……多品单件/多品多件： 订单须要多种商品， 数量任意 ；

针对不同类型的订单， 一样平常会采纳不同的办法处理，我们分别来看看是如何处理的。

单品单件：

单品单件的订单一样平常是最随意马虎处理的。

我们从订单池中挑出这类订单，然后按商品汇总后批量拣货。
比如我们将单品单件订单汇总后，商品A须要300件、商品B须要200件……由于订单都是单品单件，同一批订单数量都是1，我们从仓库一次性提出商品A 300件，商品B 200件放在打包区，剩下就只要打包就好了。
为了更快，很多仓库乃至会提前预包好，订单来了往后，只须要打印并粘贴快递面单就可以发货了。

一样平常大匆匆前，商家都会提前制订大匆匆发卖操持，会关照仓库将大匆匆商品提前准备好。
仓库会设置专门的大匆匆区，批量有规律的订单都可以在大匆匆区快速处理。

由于大匆匆的商品已经提前在大匆匆区准备好，和以往拿着订单“人找货”不同，这个时候货已经准备好了，可以说这个时候是“货找人”。
我们只须要通过打算机系统，为准备好的商品匹配对应的订单，打印出对应的快递面单，批量打包好后，贴上面单就可以发货了。

单品多件：

和单品单件不同，单品多件订单可能订单要的还是那些商品，但数量不一定是1件，这个时候须要区分订单对待。

处理完单品单件，操作员会连续挑单品2件、单品3件、单品4件……依次处理，并且分好货往后，还会做一次复核检讨，末了再打包称重。
扫描快递面单称重的时候，除了记录重量为了后面的结算，通过重量也能做到二次考验，通过订单的逻辑重量和实际称重重量比拟，偏差超过绝对值，给出预警提示。

前面我们说大匆匆的时候我们根据发卖操持，会提前备货到大匆匆区，目的是为了降落拣货的压力。
非大匆匆的时候，我们也可以通过日常订单数据剖析，优化货位方案。

例如将脱销品放在仓库拣货区入口附近，脱销品专门区域备货等，实时上都是为了提高拣货效率。
对付脱销商品，提前作准备，提前备好货可以节约拣货韶光，但是非单品单件还是须要按常规的拣货流程处理。

多品单件/多品多件：

多品单件和多品多件订单包含多种商品，消费者可能买了商品A又买了商品C，或者买了商品A又买了商品D, 这种订单商品的组合是随机的。

纵然在大匆匆区提前备好货，也是要多处拣货再合并到订单。
商品多的时候找货和合并仍旧不随意马虎，一样平常仓库将单品的订单批量处理完后，剩余的订单会在拣选区拣货。
其余非大匆匆期间，也会直接在拣选区拣货，不须要作额外的准备，适用性更强。

常见的拣货办法有边拣边分和先拣后分两种，从利用的设备来分又分为纸质拣货、PDA拣货、 RFID拣货、语音拣货、VR眼镜拣货等。
赞助设备暂不细说，无非都是将打算机指令见告人，拣货人按指令拣货，我们说一下边拣边分和先拣后分两种拣货办法。

边拣边分和先拣后分都是多个订单合并拣货，边拣边分是拣完某个商品后直接分到对应的订单篮子里，先拣后分则是全部商品拣完后末了再统一分到各自的订单，下面我们详细来看一下。

边拣边分：

拣货开始，拣货员会推着分栏的拣货车拣货，每一个拣货篮对应一张订单，拣货员按照拣货指令到指定的货位上拿到货，然后按订单数量哀求， 分别放到对应的拣货篮，即拣货同时完身分拣。

当这一批订单须要的所有商品都拣完的时候，商品和订单也已经对应好，订单拣货完成了，拣货指令中除了见告从什么库位拣什么商品多少个，还会见告操作职员拣完后分别放到哪几个篮子。

先拣后分：

拣货开始，拣货员推着普通拣货车（没有分栏），按拣货指令，到指定的货位拣取对应数量的商品放到小车。
此时不须要考虑分拣的事情，商品全部拣完后，然后送到分拣区域去做二次分拣，将拣到的货分到对应的订单。

先拣后分将拣货环节和分拣环节分开，多人分工， 各司其职， 一定程度上也提高了整体出库效率。

我们总结一下， 这节紧张讲了订单出库拣货。
对付大匆匆和日常发货，根据订单形态不同，会有不同的处理办法。

多品订单库内拣货又可以分为边拣边分和先拣后分两种拣选办法，实时上，除了拣选过程，拣选前什么样的订单一起拣，分成几个波次拣等也很主要。

这些我们在后面的话题中连续谈论，本日的话题就到这里，希望本节对你有用，感激！

本文由 @嘉叶 原创发布于大家都是产品经理。
未经容许，禁止转载

题图来自Unsplash，基于CC0协议