随着规模的扩大，库房所需要管理的SKU数量越来越多，人脑记不住，错误率还特别高，因此引入了信息化系统管理。较为完善的货位信息化系统，包括了产品的货位、数量、状态、属性等特性，这对于库房运营极为必要。B2C业界大佬Amazon，其库房中管理的SKU超过千万种，而国内公司中，卓越的SKU都约150万个（2010年9月），而当当仅图书的SKU就超过100万（2011年2月），而其他的国内领先公司，其SKU数量一般也会超过10万种，如此大的数量，只能依靠电脑系统作管理。
 
下面介绍从简单到复杂的四种货位系统。需要说明的是，这几种货位系统并不是相互独立的，而是一步步演进而成，简单的系统往往是复杂系统的基础，复杂系统是简单系统的升级。
 

没有货位系统的情况下，库房管理大量SKU所遇到最大的问题是：找不到所需要的SKU在哪里。为了解决这个问题，最为简单的解决方法莫过于划地为牢：
A. 将库房分成多块区域，分别命名为Location 1，Location 2，……
B. 把某个SKU放到其中一个区域中，再将这一信息记录下来，形成一张表格如下，这一表格中，SKU与Location（货位）是一一对应的关系。

C. 每次在往库房中放产品时候，先查一下这张表，看哪些SKU有记录了，就放到记录中的Location去，哪些产品还没有记录，就先放下来，再把Location信息添加到表格中去。
D. 每次需要使用某一产品时，也同样查表得到这一SKU相对应的Location，然后去对应的Location上取货即可。
只要按照这一流程，一直维护该表格，所有的SKU的货位信息就在表格中就会都有记录，这样就解决了一开始提到的最为迫切的问题。
 

“一一对应”货位系统解决了货在哪儿的问题，但在使用中发现了这一架构的最明显问题：可管理SKU数量有限。
 
举个例子，1万平米的库房，除了大约4000平米用于收、发货操作以外，大约有6000平米可以用于存储。存储区域中，通道占了至少60%的面积，实打实的仓储面积，只有2400平米。假设货架有4层，每层高40cm，实际使用存储面积是9600平米。设每个Location的截面是60cm*60cm，即0.36平米，可使用的总Location是2.67万种（以上的计算中，每个货位的最大存储容积仅为0.6*0.6*0.4=0.144m3）。
 
若再考虑到产品中存在畅销品，库存量较大，体积超过0.15m3，一个Location放不下，则需要占用更多的空间，那么能够使用的Location数量也只有2万种左右。如果SKU中有大体积的货品，例如冰箱、洗衣机等，数量就更少了。
 
这一问题的解决方法也很简单，改变表格中一一对应的关系，为多对一的关系，即在同一个Location中存放多个SKU，如下表，Location 1中同时有SKU 1和SKU 2两种产品。
 

 
之所以可以这样操作，是由电子商务的长尾理论所决定的。长尾理论表明，越靠近长尾的末端，产品的销售量就越小，所需要储备的库存量就越少。只有一、两件货的产品，如果在外型上可以很容易地区分开（例如毛绒玩具和鼠标），放在同一个货位中完全没有问题。这样就实现了可管理SKU数量的增长，使用这样的方法，可管理的SKU数量较一对一货位系统，一般可以增加2倍以上，根据库房所管理的SKU种类不同而不同。
 

使用“多对一”货位系统，能够大大提升库房管理SKU的数量，但是同样存在着问题：某一SKU大量备货后，货位上无法全部放下。
 
受到存货器具（包括货架、托盘等）的限制，库房中单位区域大小是大致固定的，某一个Location最大也不会超过1个托盘的大小。但是库房所管理实物的数量是不确定的，某些特殊促销的SKU在一天内的销售有可能上千件，因此会在促销前大量备货，所备货品在一个Location中根本无法容纳。这是“多对一”的最大问题。
 
问题的解决方法也很简单，在“多对一”中，货位的表格是多对一关系，即一个SKU只能放在一个Location中，而一个Location中可以存放多个SKU；如果将这一关系作进一步的拓展，形成多对多的关系，即一个SKU能放在多个Location中，而一个Location中也可以存放多个SKU，则解决了某一SKU大量备货所遇到的问题。一个货位放不下，那就放到第二个货位，不行再加上第三个……货位数据表格示例如下：
 

 
“多对多”的局限
以上的三种货位系统实际是层层递进的关系，而“多对多”则是现在国内的大部分B2C企业所使用货位系统的基础原型。
 
这一系统有着很明显的优点：首先系统架构相对简单；其次，上架操作也相对简单；第三，系统成本低，所有的操作都可以在电脑上完成，不需要采购专门的设备。
 
但是不可避免地，这一系统也有着不小的缺点：货位信息冗余不可避免、检货效率不高、盘点困难、检货路径低效、检货出错率高。
 
以上的问题，在“多对多”货位管理的基本框架下，无法通过系统的方式根本解决，而只能通过一些操作降低影响。比如定期对所有存在两个以上货位的SKU作核实，对货架上的产品作整理，例如将本段时间的热销品挪到货位体积较大的区域；将销售比较慢的产品挪到货位体积较小的区域，或者和别的产品放到同一个区域；或者是将分散在多个货位的同一个产品并到一起。
 
以上的这几点可以降低该库存系统的缺点影响，但是无法根除。如何根除呢？
 

这一方法的主要逻辑是将库房分为检货区、存货区两大块，分别运营，这两个区块之间通过补货的方式，将库存连接在一起。
 
库房分为检货区(Picking Location)和补货区(Storage Location)。检货区进行检货操作，面积较大，产品的密度相对较低一些，主要用于日常检货的操作；而补货区的面积相对较小，而且普通使用了立体存储方式，用于存储近期内不会发出的货品，例如某一SKU大量备货后的主要库存，处于长尾末端的产品等等。检货区应对于订单出货需求，补货区应对大量存货，互为补充，而在系统层面上，也同样分为Storage Location和Picking Location两部分。
 
货位系统除了Location、SKU外，增加Quantity项，例如补货区的库存记录表应该如下：
 

 
检货区库存系统中增加安全库存数据项，当实际库存数量低于安全库存时，触发补货逻辑，进行补货操作；检货区库存系统中增加最大库存数据项，用于判断补货数量；
 

 
在检货区中，同一个SKU，只有一个Location，这是为了检货的高效率而考虑；在补货区中，由于存在大量备货的可能，因此同一个SKU可以有多个Location。
 
收货上架时，由系统根据检货区的当前库存数量，生成上架任务。若检货区的库存数量小于安全库存，并且当前没有为这一SKU生成的补货任务，则系统会要求将一部分新收入的库存加到检货区；而如果检货区的库存大于安全库存，则收货的所有库存都统一上到补货区。
系统周期性判断相关产品的检货区库存数量、存货区库存数量、订单占用库存数量，触发补货逻辑。
 
该货位系统相当于两套库存并行运行，检货区用于满足最近一段时间的订单需求，存货区用于大量的存储和长尾商品的存储。两套库存之间，是单向传递的关系，传递的方式是补货。
 
几个关键点
补货逻辑是这一套系统运行的核心，它用于从存货区向检货区的库存转移过程。一般来说，与检货区相关的库存的数量发生变化（包括检货区库存数量、存货区库存数量、订单占用库存数量）时，系统根据这些数据作判断，是否生成补货任务。在补货逻辑中，介绍我认为比较重要的几个点：
 
A. 哪些货放在检货区
检货区是为了满足订单的快进、快出需求的，放在检货区中的产品，最大的特点就是在近期内会产生检货的需求。
 
WMS从哪里知道这些产品近期会产生检货需求呢？这就需要对于未来的销售情况作一个预先判断。首先，根据历史的销售数据，对于产品的近期销售情况作预测；其次，根据当前的促销政策对于产品的近期销售情况作预测；最后，根据已经生成的订单，判断产品的检货需求。
 
B. 有两种情况补货
一是收货上架时直接将一定的数量上到检货区，二是正常出货时，检货区的数量不够，从补货区将库存移动到检货区。
 
收货上架直接上货到检货区，只会在检货区的库存数量少于安全库存，并且当前没有相对应的补货任务的情况下才会使用，但这一情况应用较少，因为一般来说，库存系统每5～10分钟就会循环遍历一遍库存数据，并生成补货计划，所以补货计划的生成和操作都是很频繁的。我现在能够想到使用到收货后直接上架到检货区的，只有两种情况，一种是虚库存进货，即存货区也没有库存，无法生成检货计划；另外热销产品的备货不足，即检货区的消耗速度太快，这也会导致收货后直接上架到检货区。
 
从补货区移动库存，这是正常的逻辑。检货区的库存只保留一部分，应付两天（可以自由调整）的正常销售量。另外，在前面讲检货区的库存系统结构时，特别提到了两个新增加的数据项：Secure Qty和Max Qty，这两项是补货逻辑的基础。
 
C. 什么时候补货
当货位的当前库存低于Secure Qty时，触发补货逻辑。Secure Qty是至少应该达到补货操作的这一段时间内的可能销售数量，一般会高于这个数字，提高安全系数。举例子来说，补货时间是1小时，某SKU在1小时内一般售出5件，那Secure Qty就至少应该是5，我会设置为6或者7。
 
而长尾商品的销售非常少，在检货区中一般都没有库存，因此也不存在Secure Qty的概念了。
 
D. 补多少货
补货数量为“Max Qty-当前货位库存+当前订单已经占用库存”，如果补货区的库存低于这一数量，则将所有补货区的库存都补过去。Max Qty为未来两天（该公司不同情况作调整）内该产品的销售数量预测。
 
E. 补货逻辑被触发后的操作
补货逻辑被触发后，生成了某一产品的补货需求，一般是从补货区的某个货位，移动N个库存，到检货区的某个货位。
 
这与订单检货的操作其实是有相似点的。一般情况下是会将补货的需求批量化处理。
 
优点和缺点
这个系统还是相对比较先进的。但光说先进没用，我们还是说点实际的优缺点吧：
 
优点：
1. 将库存数量与货位相绑定；
2. 基本解决了冗余信息的问题（系统自动定时清理Qty数量为0的记录即可）；
3. 单独设立检货区，可以提高检货的效率，因为检货的区域变小了；
4. 单独设立存货区，可以提高库存的容积率，因为可以使用立体式货位；
5. 盘点较为方便，一个产品在检货区只有一个货位；存货区和检货区的盘点可以分开进行；
 
缺点：
1. 系统逻辑非常复杂，首先需要为检货区、存货区分别建立库存表格，其次要根据这两部分的分割，将上架逻辑、检货逻辑、补货逻辑分别设计；
2. 前面所说的补货逻辑、检货逻辑信赖于产品的Secure Qty和Max Qty这两个参数，每个产品的参数需要单独设定；Secure Qty和Max Qty都取决于对商品未来销售数量的预测，这是非常难以做到精确的，而且这两个参数还需要根据产品销售情况的变化而定期作调整，以免影响运营效率。
3. 系统的整体表现对产品参数设置的信赖程度很高，以Secure Qty为例，过小会导致补货不及时，订单处理延误，过大则会导致浪费检货区的存储空间；
4. 系统每过一段时间都需要遍历整个库存数据，并生成补货计划，这对服务器系统的负担较重。