下午两点，产线发来消息。

产线：这批比较急，先送一下。

仓库：哪一批？

产线：刚发的那批。

仓库：我这里刚发了三批。

调度系统没有参加对话，但它即将承担对话结果。

工厂里的“急”，很像办公室里的“尽快”。大家都懂，又不完全懂。二号线说再不来就要停，三号线说客户在催，包装区说今天必须出货，最后系统里一排红色任务，仿佛七位皇帝同时登基。

如果没有明确规则，急单只能靠人盯。操作员手动暂停普通任务，找一台离得近的车插进去；做完以后再想办法把原来的任务接回来。一次两次能处理，天天这样，调度系统就会慢慢退化成电子看板，真正的调度还在群里。

比较清楚的做法，是先给“急”分层。

会导致停线的物料，和只是希望早点到的物料，不应该使用同一优先级。插单权限也要有限制，谁能提、谁确认、出现多少次，更好能查。

产线：那我真的快断料了怎么办？

系统应该能把紧急任务往前提，但不能假装其他任务不存在。已经取到货的车要不要中断？普通任务会不会饿死在队列里？急单做完以后，原任务从哪里继续？

这些都得提前设计。

仓库：还有一个问题，你叫得急，货备好了吗？

这句特别重要。

如果任务被提到更高优先级，机器人一路赶到取货点，发现物料还没装箱，它就只能站在那里，用宝贵的紧急时间等一件还没准备好的急事。

所以急单不只是调度问题，还要连着备料状态、目标工位状态一起看。

产线沉默了一会儿。

产线：箱子正在找。

这场对话到这里，已经很接近真实工厂了。

调度系统如果会说话，大概会补一句：先把货准备好，再讨论谁插队。

紧急任务真正要做清楚的，至少有四件事：什么情况算急，谁有权确认，已经执行到一半的普通任务怎么处理，急单结束后队列怎么恢复。

已经取到货的车一般不能像出租车一样半路甩客；普通任务也不能因为一条急单，从此在队列里安度晚年。系统需要的是规则，不是每次临场发挥。

还有一个数据很值得看：到底有多少“急单”。如果每天几十条任务都要人工插队，那问题可能不是调度不够灵活，而是补料计划、库存设置或任务触发本身就一直在救火。

偶尔救一次火，叫应急。

每天按时着火，就该换个问题问了。