调度管理系统

标准安卓设备均可，可选择安装在叉车上的加固型平板电脑，也可选择手持终端。

根据工单紧急程度、生产排程需求和可配置规则综合确定，主管人员也可手动调整优先级。

可以。预留操作会自动生成调度任务，使从工单下达到产线配料的整个流程无需任何人工协调。

真正要覆盖的是叉车实际跑的路线，几个固定点位是不够的，因为司机在每个任务的取货端和送货端都要确认一次，卸货区、通道、线边都得有信号。在没信号的地方点的确认不会立刻传到服务器，要等设备重新连上网才上传，在这之前管理端看到的这个任务仍然是未完成状态。提前 30 分钟的预警走的是推送通知，所以在没覆盖的通道里要么延迟到达，要么干脆收不到。

可以，而且这是有意留出来的，因为司机手上已经有货或者被堵住时，总得有个办法说出来。拒绝时系统不记录原因，所以规律只能间接看出来：响应时间和工作负荷是按司机记录的，一个总是拒单的人工时照记，但完成任务数对不上。上线前就要定下来谁去看这些 KPI、谁去追问，否则拒绝按钮就成了随手一点就能不干活的开关。

光靠调度系统本身看不到。每个任务带的是源库位、目标库位和两者之间的路线，但这条路线是两个已知库位之间的固定路径，不是从叉车当前位置重新算出来的实时路线。要连续定位就得上单独的 RTLS 模块：叉车装标签、在需要追踪的区域装好并标定锚点基站、在出入口装扫描卡口。这是一个要现场勘测加施工的项目，不是在应用里点一个开关。

每一个源库位和目标库位都必须是系统里有唯一编码的库位，凡是要求确认的物料都得带一张司机在交接那一刻伸手就能扫到的标签。条码确认的可靠程度，完全取决于上游贴标签这件事做得有多规范。如果现在司机找料靠的是记住东西平时放在哪，那这部分经验必须先变成主数据，然后才谈得上派第一个任务。

技术上能，但那样每个任务都得有人手工录，通常就是物流主管，来源还是那些本来想靠系统取消掉的电话。做试点时这样是可行的，只上一个区域或者一个班次，任务量不大，重点本来也是验证司机的使用习惯和网络覆盖，吞吐量不是重点。一旦手工录任务花的时间比它替代掉的对讲机呼叫还多，这条路就走不下去了。

每个任务扫两次，取货一次送货一次，标签在司机预期的位置上时，每次也就几秒钟。真正的成本不在扫码本身，而在于标签朝着货架里面贴、或者贴错了一面，司机得爬下车绕着托盘走一圈。在推广之前就把标签位置按照司机从车上靠近的角度定好，否则这几秒就会变成几分钟。

需要。系统去掉的是对讲机喊话和司机猜下一步干什么，但优先级归谁定、异常怎么处理、两条产线同时要同一台叉车时听谁的，这些还是得有人负责。变化在于主管是看着任务队列和记录下来的响应时间来做判断，不再靠喊和靠记性。要按岗位职责改变来规划，别按减人来算账。