仓储 RFID 项目失败，多数是运营原因，不是射频原因。读写器正常、标签能读，库存还是错的——因为没人定义“一次读取”对业务到底意味着什么，或者箱与托盘之间的聚合靠手工录入。
这篇以一个中型第三方物流仓为原型，做了匿名化与数字取整。写作目的是让你能复用设计决策，而不是复用具体数字。
起点
场景：一家 3PL 的区域配送中心，约 2 万 m²，月处理 8–12 万箱、4000 个 SKU，原流程是条码 + WMS。
改造前实测：
- 卸车与收货：每车 3–4 小时，含人工点数和差异处理。
- 库存记录准确率：按 SKU-库位计 87–92%，每月盲盘仍能发现无法解释的差异。
- 卸车到上架（dock-to-stock）：6–9 小时，导致当日发货订单经常延迟释放。
- 拣货错误：订单行的 1.2–1.8%，多数是数量错而不是商品错。
业务问题不是“我们需要 RFID”，而是“我们没法在一个班次内回答：楼里有什么、在哪里”。
读取点设计
一期只自动化五个读取点。这是刻意的：每多一个读取点，就多一组故障模式和一轮变革管理。
- 入库月台门：两道门各一个通道，卸车时读取托盘与箱标。通道只证明“进来了什么”，不证明“去了哪”。
- 收货暂存：手持机在暂存位确认，把箱 EPC 与库位关联。
- 储备区通道：吸顶读写器做后台库位确认，不做精确计数。
- 出库暂存：每条发货道一个通道，确认“出去了什么、上了哪台车”。
- 退货与异常：一台桌面读写器，读取区域刻意做小，让退回的箱子是被识别出来的，而不是被假设的。
“全场持续读取”的方案在早期就被否掉了。金属货架环境里的持续读取会产生大量重复事件，最后瓶颈落在 WMS 上。
聚合才是项目本体
最难的不是读标签，而是维护父子关系：
- 托盘对箱：码垛时先读箱，再写托盘牌照。绝不允许手工录入。
- 箱对 SKU 与批次：收货时根据供应商标签或 ASN 建立。
- 库位对箱：上架时建立，箱一动就重建。
- 订单对箱：拣货时建立，出库通道复核。
每条关系都要记录是谁、在哪、何时建立的。没有这条审计链，差异只能核销，无法追查。
两条纪律起了决定性作用：
1. 先读子级，再写父级。一托盘声称 60 箱、实际只读到 58 箱，比一个没贴牌的托盘更糟。 2. 把重新码垛当成事件。每次拆盘、重组，旧关系必须关闭、新关系必须开启。3PL 的库存漂移大多来自没有记录的重新包装。
分期切换
- 一期（第 1–6 周）：只做入库。在供应商端或收货端贴箱标，两道门装通道，暂存位确认。出库继续用条码。
- 二期（第 7–12 周）：出库暂存与发货复核。拣货仍由条码驱动，但在发货道用 RFID 复核。
- 三期（第 13–20 周）：储备库位可视与循环盘点。盲盘被异常驱动的定向盘点取代。
- 四期（持续）：推动供应商源头贴标，这是最大的一笔经常性人工成本削减。
每个阶段并行跑两套系统不是浪费，而是在拆掉旧系统之前证明新系统。
结果大概是什么样
六个月后，按同一组 KPI 对照：
- 每车收货时间：3–4 小时降到约 1–1.5 小时。收益来自取消人工点数，不是“读得更快”。
- 库存记录准确率：87–92% 提升到 SKU-库位级 98.5–99.5%，差异可追溯到具体事件。
- 卸车到上架：6–9 小时降到 2–3 小时，恢复了当日发货能力。
- 拣货错误：下降约 70–80%，主要因为数量在出库通道被复核，而不是靠信任。
- 盘点人力：每月全盘改为持续定向盘点，同样的人力覆盖更多 SKU。
该场景的回本周期落在 9–18 个月，主要由人工与加急运费下降驱动。把这个区间当作规划假设，而不是承诺：缺货成本低、标签损耗高的站点回本会明显更慢。
同类项目里见过的失败模式
- 只在月台读。上架不确认，系统只知道货进来了，不知道在哪。
- 把通道读取当库位真相。门口的通道会读到隔壁道的托盘。
- 没有异常流程。RFID 暴露差异的速度快于运营消化差异的速度；没有队列和责任人，操作员就开始忽略报警。
- 贴标太晚。在发货环节才贴，而不是收货环节，库存收益基本消失。
- 跳过供应商沟通。供应商贴标是长期最大的一笔成本下降，但它需要规格书与来料检验，不是发一封邮件。
采购之前必须先写清楚的东西
- 完整的读取点清单，每点的所需区域与读取率。
- 聚合规则，包括重新码垛与尾盘。
- 异常队列：谁在多长时间内处理什么。
- 标签规格与粘贴标准，包括位置公差。
- 一份能证明 RFID 与 WMS 一致的对账报表，以及不一致时的处理路径。
仓储自动化不是一次硬件采购，而是“带着读写器的数据纪律”。做得成的站点，都把前六个月当成流程项目，把硬件当成最容易的部分。
