前面三篇我们分别讲到了海外仓WMS的入库、出库和库存功能的产品设计。其中入库和出库是WMS的核心功能，而库存管理则是WMS的基石，那么盘点功能就可以比作是WMS的「解忧杂货店」了。
海外仓WMS每天基本上都会有频繁的订单出入库，再加上海外本土化管理的问题，很多仓库的操作不太规范，导致「人肉运维」的事情时有发生。之前接触过某个客户，提出了一个看似很简单但是却令闻者伤心的需求：“我希望找一个海外仓合作商，只需要他们能完成日常的订单出入库，并且能反馈准确的库存给我就好了”。
这个需求其实乍一听感觉很奇怪，怎么这么简单的要求也需要强调呢。但是仔细问了一下客户一些细节，才发现其实他也有难言的苦衷。因为他之前接触的很多海外仓或者订单管理系统都在库存这方面做得不太好，库存要么不准确，要么反馈不够实时，要么没有系统界面查看（这里指的应该是一些海外的ERP或者小平台等）。
当然，上面的例子有点不够有说服力，或者只能代表很小众的群体。但是总体而言，从我自己接触的业务来说，库存的准确性问题有很多海外仓系统都做得不够好，或者大家都没太把精力和资源放在这里，所以才会发生上面那个故事。
库存的准确性，指的是实物和账面数据的准确性，也就是「现实」和「理想」的差距。当库存不准确了，客户对自己的实际库存捉摸不定的时候就会担忧超卖或者少买，从而产生忧虑感。
而WMS的盘点功能就是像是这类客户的「解忧杂货店」，但凡有库存的忧虑，那就盘点一下吧。
下面内容摘自网上，只要搜索“盘点”或者“仓库盘点”基本上可以找到类似的说明和介绍。
❝仓库盘点是个技术活，没有想象的那么简单。比如，仓库盘点的分类方法，就有三种。1.按盘点的时间跨度，分为定期盘点和不定期盘点;2.按盘点的内容，分为全面盘点和重点盘点;3.按盘点的作用，分为循环盘点、永续盘点（动态盘点）和低位盘点。
最早的时候我接触盘点的时候或者要做盘点这个功能的时候也是找了挺多资料和信息的，结果发现越看越迷糊，然后越看越觉得纠结，这么多功能我该怎么设计产品功能才好呢。直到最近，我复盘自己当时设计盘点的历程，然后得出了结论：
盘点的本质是：1.对实物进行清点，然后和账面数据比对；2.根据实物清点结果，对账面数据进行调整，达到账实相符。
所以新手如果要做这一块的产品功能设计的时候，一定要记得抓住本质来设计，否则很容易走歪路，然后陷入无休止的修修补补中。
核心点就是能吃饱饭，能提供能量就可以。至于选什么方式，取决于多方面的因素，所以只要能满足当前的业务即可，不必过分纠结。
例如看竞品，别人有明盘和暗盘，我要不要也这样做呢？别人有永续盘点和静态盘点，我是否也要跟着做一个呢？别人盘点的时候可以Excel导入，那我是不是也要做呢……
这就是我当时踩的最大的一个坑，一直想把盘点功能做的很全，很完善。结果发现很多功能设计完成之后，压根过不了评审。或者做用户Demo体验的时候，仓库压根就不认可这么多复杂的操作方式，于是只能被打回去重新思考到底业务的需求是什么，海外仓的特色是什么，盘点功能的边界应该怎么定义。
盘点的主线流程基本上都是大同小异，因为本质就是清点实物，然后调整系统账面数据。所以难点一般会在一些小细节和业务判断上，同时还有海外仓库的操作系统和管理方式。
创建盘点单的时候我精简了盘点的方式，最后就保留了两种方式：
按SKU+仓位盘点，系统标记出需要盘点的SKU在哪个库位分别有多少数量；
按仓位盘点，系统标记出需要盘点的仓位有几种SKU，分别有多少数量；
全部都是明盘，没有考虑暗盘这种方式（视具体业务而定），这两种方式是仓库盘点最常见的，能满足绝大多数的盘点需求。
把选择权更多地给仓库，想盘点哪个客户的，哪个SKU就盘点哪个，想盘点什么库位就盘点什么库位，一切都由仓库自己来决定。系统要做的就是精准地将位置和信息带出来，然后提供给仓库盘点人员即可。
上面说到了，盘点的本质就是将实物数据和系统的账面数据进行比对，然后去调整系统的账面数据，以达到账实相符。
如果实物比账面数据多，那么就是「盘盈」，意味着库存调整单是需要增加库存，类似于系统平白无故多「赚」了一些数量。
如果实物比账面数据少，那么就是「盘亏」，意味着库存调整单是需要扣减库存，类似于系统中平白无故「丢失」了一些数量。
而初盘的意思就是第一次盘点，初次盘点。初盘之后还有复盘，甚至还有些仓库会有三盘，就是对复盘之后再盘点。
初盘之后再复盘的原因是考虑到人为清点会有可能点错数的情况，如果一次清点就做了调整，有可能人为误差因素太大。所以会考虑初盘之后，再来一次复盘，以减少初盘一次带来的误差率。
对初盘结果再次盘点，就称为复盘，也可以叫做二次盘点或者二盘。关于复盘有一个逻辑是需要特别注意的：那就是复盘，到底盘什么？
如果我们不做过多的考虑，那么复盘肯定就是对初盘的一次重复动作，也就是说初盘盘了10个SKU，20个仓位，那么复盘也需要盘点10个SKU，20个仓位。
但是从实际的调研和仓库反馈来看，仓库有些时候并不想重复性地对已经确认了数据的内容再次盘点，这样会浪费自己的时间，同时又感觉做了很多无用功。但如果只对有差异的内容进行复盘，那么又会发现如果仓库想对一些不太确定的SKU再次盘点，系统却没有办法支持录入复盘数据了，也会挺头痛的。
所以我的解决方案是：复盘的时候可以对所有数据进行操作，额外增加了一个筛选按钮，就是「只展示有差异的内容」。 这样的话可以只对有差异的内容进行盘点，而没有差异的内容盘点数据自动默认采用初盘的数据；如果要对全部的内容盘点，系统也留了一个口子，不至于让仓库没有入口录入数据。
当复盘之后，绝大多数情况下可以确保实际清点的数量应该是准确的，所以就可以对复盘结果进行确认了。确认之后可以执行盘点差异处理，从而对进行库存调整，增加一条盘盈的流水或者盘亏的流水。
我在这里还多做了一种考量，就是仓库最后盘点之后还是对结果不太满意，或者说对盘点的数据不太有信息，然后想要废弃这个盘点单，所以我们做了一个「确认结果但是不执行」的操作。仓库这样操作之后，这个盘点单就变成了已取消的状态，意味着最终没有执行盘点结果，没有对库存进行调整。
当然这个操作我没在其他的系统上看到，并不意味着我的想法和思路就是独具匠心，也有可能是我想得太多。所以，盘点具体的功能和范围一定要自己摸索定义好，多不一定好，但是少也不见得就会出色。一定要视具体的业务而定，而不是一味地参考竞品，参考别人的经验。
最后我在这里放一个详细版的盘点流程图，其实最早期的版本应该会有更多的功能，随着对业务的把控程度越来越清晰，就做了很多删减。
前面讲到，盘点有很多种类和方式，如果一味的想要求全，满足所有的功能，那么就会导致分支线会弄的比较复杂。
例如当前我只用了两种盘点方式，但是涉及到初盘，复盘和确定执行与不执行，最后再兼容不同的盘点设备，这一套下来，工作量其实就挺多的。
而且盘点功能其实只是WMS的库存模块的一个小功能，如果一开始采用了太多种类的盘点方式，那么最后可能就会演变成比较复杂的分支。开发成本较高，仓库使用的学习成本也很高。
仓库盘点的时候，应不应该在作业？这个问题不同的人有不同的答案，但是结果肯定是：不作业的时候再做盘点会对产品设计要求更少。
当在仓库作业的时候盘点，创建盘点单获取实时数据的时候是一个值，在实际到了库位进行盘点的时候可能又变成了另外一个值；为了避免这种数据的动态增减，我们可以考虑对在作业的SKU或者库位做冻结，不允许盘点这一块的数据。那么什么时候释放数据又是一个问题，是下架了就释放还是出库了在释放。如果是下架了就释放，那么如果有订单拦截取消又要返库怎么办？如果是出库了就释放，那么这个单临时不出库，一直放在待发货区不出库，那么短期内就没办法对某些SKU盘点了。
所以盘点怎么处理锁定库存也算是一个难点，一定要考虑清楚系统对库存的锁定和释放的时机，然后结合业务来设计。
我自己的经验是倾向于让仓库盘点的时候不作业，这样的数据是最准确的。我只统计在库位的库存，而不管是否锁定还是冻结，只要不在库位我就不统计，那么前提最好是：仓库已经正常作业完，现在没有入库和出库的操作。
上面说了关于盘点的方式和种类有很多，然后盘点库存统计的时机也有很多种方式，盘点需要几次才能确认结果，盘点的时候用PDA还是纸质单还是Excel，盘点能否支持多人同时作业，多设备共同提交……这些都是产品边界的问题，一开始最好做加法，然后慢慢地发掘之后做减法。
产品边界问题不只是在盘点上会遇到，在其他的产品功能设计的时候也会遇到。而我自己就是因为在盘点的时候踩了这个坑，所以我的记忆比较深刻。盘点功能从设计到开发到最后上线，足足比我预估的时间晚了2个迭代，这里面最大的原因就是我对产品边界的把控不到位。
有些功能做到一半才感觉好像用处不太大，考虑的太多了；也有一些功能做到一半才发现没考虑周全，例如货品的料区问题，于是又要紧急规划将一些遗漏的点重新补上。
产品边界这个坑，是做盘点功能给我最大的一个教训，也算是一个最大的收获。
盘点功能是WMS库存模块的一个辅助性功能，辅助仓库调整系统账面库存，以达到账实相符的要求。海外仓的盘点和国内电商仓库的盘点应该也是大同小异，主要区别还是在仓库管理和实际业务的区别。毕竟系统是给人用的，使用的人都不同，那么使用方式自然也会有所不同了。
关于海外仓WMS的盘点功能设计的心得和感悟大概就是这么多了，最近写了这么一系列的WMS总结文章我有了些新的感受。
大家总在说B端产品应该更加注重业务，吃透业务，理清逻辑；而C端产品则需要更加关注拉新留存，商业价值，用户体验和用户价值。很多话都是说的，听的千篇一律，却难有，少有万里挑一的触动。
当我回过头去反思自己做WMS的产品设计的时候，我发现我对业务的理解还是很片面，总觉得自己看到的就是最真实的，最全面的。而背后的，冰山下的却没怎么去挖掘，花费了较多的时间和精力去对比竞品，去分析同行的设计初衷……
所以，哪怕是看起来简单的8个字：吃透业务，理清逻辑。实际做起来也是需要费一番苦心和光阴，所以B端产品还是应该侧重点在业务。理解了业务，吃透了业务，那么距离一枚优秀的B端产品，就又更近了一步。
粤公网安备 44030402005698号
[罗戈导读]盘点功能就可以比作是WMS的「解忧杂货店」
