原文地址：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的设计要求比较高。
当然，随着系统在上下游的集成度越来越高，这个问题也就逐步得到解决了，一方面是供应商对于需求量有了更准确的把握，另一方面，下单过程也越来越自动化，下单人员只需要确定一定期间内需要维持的库存量就可以了，订单数据都可以自动生成。
从这两个库存管理问题来看，我们对于仓储过程的信息化是充满期望的——在一些技术细节上，我们往往能很明确地看到未来在哪里，只是还差一步步走过去。
