动笔写这篇随笔的动机，来自于实际工作中对于库存及配送管理及运作的一些体会。我始终认为，实践上升为体会，体会总结为经验，经验提炼为理论。到目前为止，我想我在这篇及以后的随笔里面所提到的诸多内容，只能称为体会，顶多到达经验这个层面。至于理论，需要理论化的操作方法，诸如立论、破题、承题等等，乃至参考文献、模型设计、对比测试、抽样分析等等，皆非我所擅长。且我常常觉得，过多地陷入到理论化的操作中，就成了形而上学的“格物致知”，也许就阻碍了真正活泼生动的理论的生成。
因此，我谨在此声明，以下言论代表个人观点，如有雷同实属巧合（因为我也来不及看其他文献），或者说是英雄所见略同矣。
需要说明的是，虽然以下的内容属随笔性质，但我一贯遵循一个原则，即：概念要清晰，逻辑要严密，条理要分明。我的结论可以错误，但是我敢保证我的结论都是按照以上原则仔细推敲过的，如果有错误，必然是我的认识局限短浅，以及方法论错误所致。所以，当别人指出我的错误时，我会特别高兴和感谢，因为第一，你帮我看到了我看不到的东西；第二，只要是我犯的错误，我都有办法改正，还就怕它不是我的错误呢！
仓库是干什么的？
首先，我在这里把“配送中心”和“仓库”都称为仓库，不仅是为了方便，更重要的是，我觉得二者本来就是一回事，只是在实际工作中的侧重点不同。
仓库能干点什么呢？其实，抛开复杂的实际操作，仓库本质上就两件事：存东西、发东西。这二者是一对哲学意义上的矛盾的两个方面，不存则无所谓发，无发则没必要存。一个好的仓库，必须要处理好存和发之间的关系，必须在明确运作根本目标的前提下，协调好存和发的交互。比如，生产企业的仓库，存是主导，而3PL的仓库，发是主导。也就是说，必须从一开始就定义好这个仓库以存还是以发为主，两者绝对兼顾是做不到的，只能以某一方面为重点。对于仓库的定义，从仓库的规划，到仓库的建设，搬送设备的选型，信息系统的配备，乃至规章制度的建立，运营团队的建设，必须一以贯之。虽然因为商业环境的变化以及业务的调整可能做一些微调，但绝不能偏离太远，否则就会无论怎样努力，也达不到期望的效果。
特别地，系统工程的概念和感觉在仓库运作中体现得特别显著，往往看似很小的细节，实际却关联到整个运作能否顺畅。因此，即使是一个小的决策，也不能只从局部出发考虑，尤其是不能侥幸地试图靠局部的调整来解决整体的问题。我见过一些仓库运作得不好，究其根本原因，都是这个。
如何存和发呢？
东西-Unit Load
先别管如何存如何发，我们先来讨论一下“东西”。这里要提前说明一个重要的事实：在仓库的运作中，处理实际和处理虚拟一样重要，这一点我会在以后不断提到并详细说明。这里先说说实际的“东西”。既然要存又要发，这个被存或被发的东西，或者说货物，会以怎样的方式出现在仓库里呢？
撇开一些表象，我们很容易就会发现，仓库里的货物，只要是可以被存或者被发，就可以称为一个货物单元，也就是Unit Load，这是仓库运作的物理和数学的基础。这个Unit Load，可以是一个托盘上的，可以是一个包装箱里面的，可以一个Unit Load里面还有N多个Unit Load的。只要能被操作，并且可被识别，就是一个Unit Load。
这里要说明的是，这个概念看似简单，实则丰富。它涵盖了很多可能，包括：可混载的、不可混载的，混载的Unit Load里面又可以按照树型结构无限分解下去。Unit Load的基本属性其实只有两个，那就是ID，通常情况下称为LPN（License Plate Number），以及数量（数量其实是可选项，可以为空值，因为可能还有混载的呢），其它属性都是从别的对象中关联过来的。当然，在实际操作中为了简化方便，一般都会把一个托盘、一个箱子或一个车里的货物设置为Unit Load，而且尽量不混载。
现在回到前面关于“虚拟”的概念。其实，所谓的虚拟只是对实际事物进行了抽象，特别是数学意义上的抽象。比如说，一个箱子里面装了好多不同货物，可以认为这个箱子是一个实际的Unit Load，里面又好多个虚拟的Unit Load，而每个虚拟的Unit load都是单独一种货物。可以看到，从数学意义上看，这个箱子与里面虚拟的Unit Load实际上是一回事。这一来，就可以把复杂的混载简化为Unit Load与Unit Load之间的关联，包括可能含有递归的关联，而这在数学上，特别是信息化技术上不难处理。所以，在仓库里，虚拟的和实际的可能同等重要，甚至有时更重要！
前面说到，Unit Load的基本属性有两个，其它属性都是从别的对象中关联过来的，那其它属性从哪里来呢？
一个Unit Load里的货物，必然是属于某种货物的集合。这里用“集合”这个词，是因为它比较中性化，而且实际上非常精确。我们来看：
某个名称的货物，我们可以认为是一个集合，某个名称的某个规格的货物，我们可以认为是一个集合，某个名称的某个规格的某个批号的货物，我们可以认为是一个集合，某个名称的某个规格的某个批号的某个什么什么的，我们当然也可以认为是一个集合，甚至于某个实际的加上某个虚拟的什么什么属性，只要能够集合，它也是一个集合。一句话，集合时按照属性集合的，而前面说到的Unit Load的其它属性，实际上是说这个Unit Load上的货物，可以属于哪个集合，就继承了这个集合的属性。
为什么要说集合呢？因为仓库无论是存还是发都是按照Unit Load的属性来进行的。为什么存在这里而不是那里，为什么发这个不发那个，都要靠属性来作为判据。一句话，仓库管东西，东西要属性。既然要属性，那就得有集合啦。
我个人觉得，只要可以建立一个集合，无论怎样建立，就可以把这个集合识别出来。实际在仓库操作中，往往是把名称和规格组合起来成为一个集合，叫做SKU（Storage Keeping Unit）。为什么这样呢，因为这两个属性在大多数情况下，可以满足存和发的需求了。
可是对于现代专业化的仓储，还有很多重要的属性呢，如批号，生产日期，保质期，存储要求，etc。那该怎么办呢？一般的做法是，一个Unit Load，关联一个SKU，再关联这些其他属性。也就是说，从Unit Load能找到许多属性，从某个属性能找到一堆Unit Load，这就是仓库运作的最基本能力。没这两下，咱就关门吧。
有了Unit Load关联SKU，再关联这些其他属性，接下来怎么做呢？
库存与库位：Inventory & Location
这里先从存说起。库存库存，存到哪里呢？当然要存到货位上。这就是说，Unit Load和Location（库位）的关联就构成了Inventory（库存）。沿用我们以前的思考方式，库位的一些属性也会被自动关联到库存的属性里。那么库位会有哪些属性呢？除了物理属性外，最重要的就是：是否可用。如果库位不可用，与之相关联的库存也不可用。库存是有生命周期的，构成库存的两个要素当中的任何一个不存在了，这个库存就不存在了。也可以说，既然有单元货物，就可以有单元库存（Unit Inventory）。
要注意的是，除了货架之外，其实搬送设备的某个站台，出入库整理区，甚至叉车等，都可以看成是库位。相应地，也就可能存在与之相关联的库存。这种库存大多只有很短的生命周期，却往往是最需要被关注的库存。
仓库内习惯将实际库位分类为存储位和拣选位。其实这二者的区别就在于，库存在存储位上存在的时间较长，而在拣选位上存在的时间较短。实际操作中，拣选位主要为了方便操作人员拣货，往往会将某一片拣选库位都分配给某种SKU。必须注意，这只是为了方便，不是必需的。
后面会谈到集货操作，这里先谈谈集货位。集货位其实就是特殊的拣选位，目的只是为了方便装车。库存在集货位上存在的时间更短。
库位是仓库最重要的资源，合理组织好、控制好库位是仓库正常运作的保障。从某种意义上说，货物少了都不可怕，库位不足了真是会让仓库的主管们心惊肉跳。控制好库位，最重要的就是控制库存在库位上存在的时间。特别是对于集货位和拣选位更是如此。
按照我们的习惯，自然要讨论到虚拟库存了，这可是仓库运作中一个十分重要的概念。一个有趣的事实是，很多时候虚拟库存比实际库存还有用，因为虚拟库存可以表达，或者被赋予一些特别的意义，例如所谓的“在途库存”。既然虚拟的Unit Load比较少用到，那么只要将实际的Unit Load与虚拟的Location关联起来就成为了虚拟库存了。所以，虚拟的Location会特别有用。
库存可以干什么用呢？
库内外操作
前面说了，存是为了发，库存的存在就是为了搬送。在库存的生命周期内，所有仓库的实际操作都可以抽象为库存的搬送。也就是说，库存的不断更新，以及该更新所代表的业务逻辑，就构成了仓库运作的全部，所有的仓库操作，包括收、存、盘、补、拣、发、包等等，都可以通过库存的更新来实现，而每一次更新，都实现了一个业务逻辑，或者流程。我们把这些库内和库外的操作一一罗列一下。这里要说明的是，我们是从数学意义上来看待这些操作的，这里暂时不涉及具体工作是怎么干出来的。
收货：生成新的Unit Load，并关联到入库整理区库位，或虚拟库位。此时就表示该货物已经属于仓库管理范畴。这很重要，因为这可以作为仓库与其它往来单位之间的“分界点”，尤其是可能涉及财务的操作。
上架：将收货完成的库存移动到合适的存储位，或者拣选位，或者干脆集货位，这就实现了cross docking（交叉转运），这个后面再说。
盘点：将库位上的库存检查一遍。
补货，或者说库存移动：由于某种原因，特别是为了满足拣选位的某个SKU的数量足够，将库存从存储位移动到拣选位。在此过程中，可能会将Unit Load拆分。
拣货：将库存从拣选位移动到集货位，或者干脆直接装车出库。
发货：将集货位或拣选位上的库存分解为发货车辆的库存。
包装或拆分：将Unit Load组合或拆分，然后关联到某个库位，大多数是拣选位或集货位。
最后，虚拟库存移动，此处不做解释。
实际中怎样进行库内外操作呢？
波次：consolidate & wave
为了使库内操作能效率最大化，可以将多个有关的操作组合起来，这就形成了所谓波次。这么说来，其实收货也可以波次、补货也可以波次，拣货也可以波次，发货更可以波次。但是实际上最常见的是补-拣-包-发组合波次。具体地说，是要在一个波次里，完成补货、拣货、包装到发货，或者其中主要的操作。从这个意义上说，波次就是一组库存移动。
波次的道理好比开汽车，发动机在某个速度时效率是最好的，太快太慢都不行。波次运行得好，库内操作就可以有条不紊。因此，如何组织一个波次并监控它的运行，实在是主管们的硬功夫。选择将哪些操作组合成一个波次，主要就是取决于资源的限制。实际操作中，往往是为了装车而选择了波次，这只是因为月台或集货位实在是太珍贵了。波次的时间也有讲究，太长太短都不合适。总之，波次的组织没有一定之规，唯一要旨，就是在操作和库内的资源间要有个相对的、统筹的平衡。
那么可不可以没有波次呢？坦率地说，实际操作中这是常有的现象。没有波次就意味着操作都是ad-hoc，就是随时生成随时进行。这就难免造成资源的浪费或者资源不足。
波次怎样实现呢？
任务：Task & Ticket
波次既然是一组库存移动，就可以按照实际的移动操作分解为具体的Task（任务），无论是实际的库存移动，还是虚拟的库存移动。这就是说，可能有实际的task，更可能有虚拟的Task。
其实严格来说，任务是操作的分解，不是波次的分解。可我更希望在实际工作中把任务作为波次的分解。前面说了，波次是操作的集合，每形成一个波次，必有要形成这个波次的原因，而我希望每个任务都能够追溯到这个原因。
讲到这里要插入一个观点，大家可以注意到，库内各项操作实际上都是从查询这个动作开始，经过一番数据维护和处理，最后的结果是---还是查询，因为这有这样，主管们才能知道这个操作是否真的完成了，以及完成的绩效。所以，信息系统强大与否，查询能力是基础。而查询能力的强大，也要依靠信息本身的丰富全面，这就是为什么我希望任务关联到波次，因为我希望通过查询，能编织起一张信息网，可以恢恢，不要疏漏。哪怕很小的细节，也要设法可以查到，这才能真正提高仓库的信息化运作水平。
回到任务，这回就可以谈一谈具体的工作是怎么干出来的了。既然是任务，就要有两个要素：干什么，谁来干。显然，干什么，就是前面所说的操作，具体地，就是某种类型的库存移动。谁来干，这个有点需要琢磨的了。如果是由自动设备完成搬送或分拣（其实还是搬送），那么只要将这个任务以某种方式下发给设备，并且能有效跟踪该任务就行了。如果是人工完成，特别是人工拣货，可能就要制作pick ticket（拣货单）。
为什么呢？大家可以注意到，要想让工作有效率，想多加人手，就要尽可能使具体工序并行进行，每道工序尽量不要受到前后道工序的影响，而且每道工序的错误尽量有办法在下道工序解决。可是仓库的操作对于每个具体的Unit Load来说，都是串行的操作，怎样把串行的操作分解为可以并行的任务，这可实在是个大大的本事。我始终以为，自动搬送设备最大的好处，不是能力效率比人高，而是天生就擅长串行的操作，而人就不同。你让一个人先补货再拣货再包装再集货再装车，就不可能有效率了。对于人来说，只有并行工序，才有效率。实现这点，就只能靠pick ticket。
要考虑到，即使操作人员手里的pick ticket没有时间先后顺序，或者没有波次先后顺序时，也能完成操作。但最好有位置先后顺序，以便实际工作。实际工作中有很多方法，例如，只有包装的箱子被拿来时，才开始拣货，而箱子可以排序。这都属于具体技巧，不是pick ticket的必要条件，主管们必须明白这一点。
好了，仓库运作起来了，通过充分的磨合，以及信息系统查询水平的提高，可以达到很好的效果了。
|
