引子
上周见了家大件商品制造企业的物流负责人。聊到后半段，他问得很实在：你们的算法能省多少钱，能不能写进合同。
我说不能。他脸上的表情我大概读得懂，又来了一个不敢承诺的供应商。
这篇文章把当时没展开的话写完。
一、上一套系统为什么停用
这家企业几年前买过三维装箱软件，也上过 TMS，现在两套都用得不深。听起来像"功能不够"，实际比这微妙。
三维装箱软件解决的是"这一车怎么装"：货怎么摆、空间怎么用，做得很细。但它不知道这车货送哪儿、走哪条线、要不要跟别的订单拼在一起。路径不在它的模型里。
TMS 管的是订单、调度、结算这些流程，能把一票货从下单跟到签收。可一旦碰上"既满足装载的空间约束，又满足拼车串点的路径约束"这种联立决策，它通常只能靠规则配置撑一撑，剩下的交给调度员手工排。原因不复杂：这是两类约束耦合在一起的问题，求解难度比单看装载或单看路径都高一个量级，通用产品不会为某一个行业的组合去重做求解器。
而恰恰是这部分最难。比如大件物流配载，装的不是标准箱，重心平衡算法要处理偏载，重心偏了直接关系到行驶安全和货损；易碎品装箱规则又卡着叠放层数、朝向和缓冲方式，不同品类的要求还不一样。
于是系统各管一段，最难的那段落在人身上。人缝得多了，系统就退化成记录工具。
二、三层，而不是一层
后来我们把这件事拆成三层来看。
最上面是系统的全局优化。给定订单、车型、时效、成本，它算一个整体上更划算的方案：怎么装、怎么串、直发还是中转。这一层是算法的主场，人算不过来。
中间是调度员的判断。有些信息算法拿不到：某个客户必须上午到，某条路这周在修，某个司机第一次去那个园区。这些不在系统里，却直接决定方案能不能执行。
最下面是司机。装车时空间怎么利用、货怎么固定、收货方有没有卸货条件，只有到了现场才知道。
三层之间不是上下指挥的关系。调度员每次改方案、司机每次在现场调整，都该回到算法里，成为下一轮计算的输入。做不到这一点，系统就一直停在"给建议"的阶段，人该多累还是多累。
三、两个数
协同有没有真成立，我一般看两个数。
一个是线路采纳率：算法给出的方案，有多少被调度员原样用了。这里要强调"原样"，改得面目全非还计入采纳，这个数就失去意义。
另一个是调整率：人改了多少，改在哪些环节。
两个数放在一起，读出来的东西不一样。采纳率低、调整率高，说明算法不懂这门生意。这时候谈优化是空的，得先回去补约束——装载的重心、易碎品的堆叠、非标车型的装载边界，一项一项补。
采纳率高、调整率低而且稳定，才说明算法开始被信任。到这个阶段，人的精力才真正从排单转到异常处理上。
调整率还有个用处：看它集中在哪儿。集中在装载，是三维建模的问题；集中在串点，是网络和时效的问题；集中在现场，是司机的反馈没回流。
四、次序
落地上，我越来越觉得次序比功能更关键。
先要现场认同。调度员和司机得觉得这活干得比以前顺，系统才留得下来。这一步靠汇报材料没用，得拿真实订单跑一遍，让他们自己判断。
然后是组织上的调整。省下来的成本如果进不了任何人的考核，如果调度员的职责还是"手工改单"，协同就持续不了。计费结构、人员分工，这些不动，算法再准也推不动。
最后才是成本优化。它是组织调整完成之后被承认的结果，不可能是立项时的承诺。
所以 ROI 我只能做静态测算：把历史订单放进去，算一个理论空间。真正的验收还是看功能——上一套没解决的问题，这套解决了没有。先用起来，节约是后面自然发生的事。
这个说法不好卖。但签得漂亮、验收时互相为难的项目，我见过太多了。
结语
如果一定要一个承诺，我能给的是这个：拿你的真实订单跑一遍，把算法排的方案和调度员手工排的方案摆在一起，看采纳率，看调整率，看差在哪一类场景。
这个证据，比任何 ROI 数字都实在。