货架上方会亮的那块标签，看起来只是个小便利。实际上它改变了「下一步拣什么」这个决定归谁做，而回报正是从这个决定里长出来的。
电子价签能做什么、不能做什么
标签标识的是一个位置，不是一个物件。
- 它告诉操作员去哪里，但不知道被拿走了什么。
- 它省掉寻找时间，走路时间一分不少。
- 确认要靠扫码、传感器或按钮，这个选择直接决定准确率。
- 拣货面分散、SKU 周转慢的场景，收益最大。
- 在高密度、快周转的库区，一份好的纸质清单往往并不吃亏。
灯亮之前，先在 Odoo 里合批
合批逻辑决定了这套硬件的价值。
- 按库区和拣货密度分组，否则操作员会在仓库里走出随机路径。
- 尊重订单优先级；紧急行不该排在满满一批常规行后面。
- 批次上限按拣货车容量定，而不是按软件默认值。
- 只有库存占用已提交之后，才把批次下发给货架系统。
- 批次键要保持稳定，重新排序的批次不能让标签控制器混乱。
把拣货面映射到标签
映射衰减得比硬件还快。
- 一个拣货面一张标签，一个库位一个拣货面，否则几周内映射就会漂。
- 在 Odoo 里把标签标识挂在库位上，绝不挂在物料上。
- 一个库位放多个物料时，用多行标签或把拣货面拆开。
- 库位规划变动时，把重映射当成计划任务，并记录是谁改的。
- 留一份可打印的「标签—库位」对照表，给维护货架的技师用。
播种墙与拣货指示灯是两种问题
宣传册上看起来很像，实际行为完全不同。
- 拣货指示灯把操作员引向来源库位，逻辑是以物料为中心。
- 播种墙把商品分发到订单容器，逻辑是以订单为中心。
- 电商里大部分工时在合并与分播，这正是播种墙的回报所在。
- 两种模式的失败方式不同，确认设备也不同。
- 不要指望买一套架构就能同时跑两种模式，除非你愿意改流程。
确认这一步：谁来说东西拿了
确认是系统唯一产出的真实数据。
- 灯亮之后扫物料码，否则这条事件只是声明，不是事实。
- 在货架边确认，不要在打包台确认，否则错误暴露得太晚、修起来太贵。
- 记录是谁在什么时候确认的，争议处理两样都要。
- 标签上要显示所需数量，并显式确认整行完成。
- 允许在货架边「拒绝」；逼操作员错确认，就是准确率死掉的方式。
异常：短拣、替代与拆行
异常是常态，流程必须在一步之内消化它。
- 短拣应当能在货架边直接处理，不必叫主管。
- 由 Odoo 按属性匹配度给出替代候选，而不是谁嗓门大听谁的。
- 拆行不能让标签一直亮着，等一个永远不会到的数量。
- 在行上记录原因码，一个季度之后分析才有得用。
- 反复短拣的库位要升级给库位规划与补货，而不是压给拣货员。
补货与空掉的拣货面
最常见的异常，其实就是货架上没货了。
- 空拣货面通常是由拣货员发现的，距离订单到期只剩几分钟。
- 若货架系统知道这个面已经不够，它可以在拣货员走到之前就发起补货。
- 补货由 Odoo 的库存阈值触发，绝不要由标签自己触发。
- 补货与拣货不能在同一时刻挤进同一条窄货道。
- 统计因空面造成的短拣占比；那是库位规划指标，不是拣货指标。
同步模型：任务、标签、确认回流
要建模的是工作，不是指令。
- 把拣货任务当成带状态机的 ERP 记录，标签只是执行器。
- 每条标签指令都有标识，确认回流才能可靠匹配。
- 接口必须幂等；重发的指令绝不能把一行确认两次。
- 指令在边缘侧缓冲，短暂断网不该让整条货道停摆。
- 每个班次结束时把标签状态与 ERP 任务对账，出现漂移就报警。
产能计算：电子价签到底改善了什么
买东西之前，先把三段耗时拆开。
- 在现有流程上，按库区分别测寻找时间、走路时间与确认时间。
- 标签大幅压缩寻找时间；走路时间只有在合批顺序合理时才会缩短。
- 确认时间通常先升后降，随着操作员熟练而回落。
- 用「每小时行数」算盈亏平衡点，不要用百分比改善。
- 还要建模标签网络掉线、拣货回到纸面时的情形。
失效模式与降级拣货
假定网络一定会坏，并把货道设计成能扛住。
- 标签失步、电池耗尽、控制器重启，这三件事都是日常。
- 每个批次保留一份在释放时重新生成的纸质清单，作为降级方案。
- 过期标签要有明显标识，操作员才不会相信一盏旧灯。
- 电池与无线健康度纳入计划维护，而不是出事再响应。
- 培训班组长自己把货道切回纸面，不必等 IT。
试点设计与指标
试点要跑完整一个需求周期，包括一次高峰。
- 选一个库位规划稳定、订单结构中等的库区。
- 与同一库区的纸面流程比：每小时行数、拣货准确率、寻找时间与异常率。
- 把标签的维护工时算进对比，那也是真实人力。
- 事先定好「什么结果才值得铺满全场」，因为这套硬件是多年投入。
- 如果试点只在寻找时间上赢，先修库位规划，别急着多买标签。
