演示时很好用,上线就翻车:WMS 选型 POC 的正确姿势

演示那天,销售的鼠标飞快。订单进来、波次释放、拣选路径规划、面单一打,行云流水。屏幕左上角还实时跳着"准确率 99.8%"。老板在后面看得频频点头,当场就说"这钱花得值"。

上线第一周,仓库乱成了一锅粥。

这不是段子。2019 年我帮一家兰乔库卡蒙加的 3PL 做选型,最后就是这个剧本。签约前一切都很美,上线第一个周一,退货区的姑娘打电话来说:系统里没有地方录"客户退回一半、箱子破了"这种单。她只能先记纸上。下午三点,波次释放了 400 单,其中 60 多单库位是空的——旧系统里有这批货的库存,迁移过来的时候丢了。新系统跑得再顺,面对的也是个烂摊子。那一单项目,光返工就多烧了快 9 万美金。

这么多年我看明白一件事:演示从来不是用来发现问题的,它是用来签单的。 厂商的销售团队一年做上百场演示,happy path 他们闭着眼睛都能走完。你想看到的,他们演给你看;你没想到的,他们提都不会提。真正能照出妖镜的,只有 POC。

样板间里当然没有灰尘

先说说演示为什么看着都好。

第一,演示数据是洗过的。SKU 编码整齐,库位逻辑清楚,一个重复都没有。现实呢?我见过 SKU 编码里带空格、带中文括号的老系统,一条 SKU 三个别名,哪个是主数据得靠老员工拍脑袋。厂商演示用的 demo 数据库,从来没有你家这种"陈年老垢"。

第二,演示走的是 happy path。收货、质检、上架、拣选、复核、发运,一气呵成。拣货永远不缺货,波次永远整齐,打印机永远有纸。可仓库里哪天不是在处理例外?短拣、破损、串货、退货、越库、补货跟不上——这些在演示里一律不会出现,因为销售的鼠标根本不会点过去。

第三,操作的人太熟了。销售工程师演示的系统是他天天点的,哪个按钮在哪、哪个弹窗先出来、哪个地方要等两秒,他都门儿清。你家仓库的小伙子第一次摸这系统,学习曲线是什么样,演示里看不到。

所以我的 verdict 是:演示只能看界面顺不顺眼,别的什么都决定不了。 把它当成相亲的第一眼,有眼缘再继续,没眼缘直接过。真正要不要结婚,得靠 POC。

POC 该这么打

POC 这三个字母,很多人理解错了。它不是"免费试用",而是"婚前同居"——把真家伙搬进去,住两到四个星期,看看合不合适。具体怎么打,我这几年总结了几条硬规矩。

用你自己的脏数据,不用厂商的样板数据。 把你最真实的 SKU 主数据导进去——带空格的、别名重复的、条码扫不出来的,全都要。历史订单也要真实的:把去年黑五那周的订单导进去跑波次,看看系统的波次算法在你的订单结构下还灵不灵。用干净数据测出来的性能,跟你的仓库半毛钱关系没有。

验收指标要写在纸上,而且要盯异常分支。 很多公司的 POC 验收标准就一句话:"流程能跑通"。这等于没标准。我的做法是列出关键流程的正常+异常两套分支:上架(正常上架、混托上架、异常滞留)、拣选(整托、拆零、短拣怎么处理)、盘点(循环盘点差异怎么调)、退货(良品、次品、待检)。每一分支都必须有明确的通过标准,比如短拣处理必须在 2 分钟内在手持终端上完成闭环。写不出来的标准,测了也白测。

限时 2~4 周,到点就判。 POC 拖得越长,厂商的实施顾问投入越深,你的沉没成本越高,最后变成"都做到这份上了,不签说不过去"。两周测核心流程,四周加集成和压测,足够了。时间一到,按纸上的标准打勾,不及格就换人,别心软。

把集成接口写进 POC 范围。 WMS 从来不是孤岛,ERP 的采购单、销售单怎么进来,快递面单怎么打、怎么回传跟踪号,这些全是翻车重灾区。我见过 WMS 本体跑得好好的,面单接口一到旺季就超时,最后打包台排起长龙的。要求厂商在 POC 期间把至少一个真实的上下游接口调通,别信"上线前肯定能调通"这种话。

让厂商把底裤露出来:API 文档和报错日志。 这条很多人不敢提,怕得罪人。但你想想,上线后半夜两点系统报错,你的 IT 连日志在哪都不知道,那是什么滋味?POC 期间就要看到完整的 API 文档、错误码列表、日志怎么查。连文档都拿不出来的厂商,上线后的支持响应你能指望吗?

POC 验收时主管带着团队在货架通道旁围着手持终端讨论

翻车的三口深坑

说了这么多正确的,再说说我见过最多的三种死法。

第一口,异常流程没测。 几乎所有的翻车都栽在这。正常流程谁家系统都跑得通,真正决定上线后日子好不好过的,是异常。退货的逆向流程、盘点差异的调整审批、波次释放到一半发现缺货怎么回滚——这些在 POC 里一个都没走,上线后全变成救火现场。记住一句话:仓库里 20% 的时间在走正常流程,80% 的精力都耗在异常上。POC 只测那 20%,等于闭眼签字。

第二口,数据迁移的量级没压测。 很多 POC 就导了几百条 SKU 做做样子。上线时要迁的是几十万条 SKU、几年的库存流水、几千个库位。我见过最惨的一家,迁移脚本在测试环境跑得飞快,一到生产环境,300 万条库存记录跑了 11 个小时还没完,最后上线窗口直接错过。POC 里至少要做一次全量级的数据迁移演练,计时、记录、看有没有丢数。丢数这件事,演示永远测不出来。

第三口,参考客户的电话没打。 厂商给的参考客户名单,99% 是关系好的。但你得打,而且得会问。别问"用得好不好"这种傻问题,要问具体的:"你们上线花了几个月?""实施团队几个人驻场?""第一年实际花的钱比合同多了多少?""现在还有哪些功能是你们当初以为有、其实没有的?"我打过一个电话,对方叹了口气说"合同里写了支持多货主计费,上线才发现要定制开发,又加了 4 万美金"。这一个电话,值 4 万美金。

一份能用的 POC 验收清单

把上面这些落成一张纸,POC 结束那天逐项打勾:

  • 真实 SKU 主数据(含脏数据)已导入,条码扫描通过率达标
  • 历史高峰订单已导入并完成波次释放演练
  • 上架、拣选、盘点、退货的正常+异常分支全部走通,有截图和日志为证
  • ERP/快递面单至少一个真实接口已调通并跑过完整单据
  • 全量数据迁移演练完成,耗时和丢数率记录在案
  • API 文档、错误码、日志查询方式已交付给 IT
  • 参考客户电话已打,关键问题有书面记录
  • 实施团队的真实人力投入和上线后支持 SLA 已书面确认

有一项是红灯,就别签字。POC 的意义就是让你有底气说"不"。

最后给个明天就能用的建议:如果你已经在跟某家厂商谈 POC,今晚就把你们去年最难搞的那 50 个订单导出来——退货的、短拣的、拆零混托的、客户改地址的,全挑上。 明天开会就跟厂商说,POC 就用这 50 单验收。敢接的,继续谈;找借口推的,你省下了一次翻车。