YMS 和 TMS 各说各话：卡车在途位置进不了排班，问题出在哪

先说结论：大多数仓库的 YMS 月台预约，是瞎子排班。

排班员排的，是卡车"应该"几点到。卡车"真"几点到，排班表上永远看不到。晚点两小时不是意外，是日常——预约表每天被推倒重来，收货主管靠电话和微信群救火，而 YMS 里还一本正经地显示着"今日预约几十车，全部正常"。

你可能会问：卡车的位置数据不是现成的吗？TMS 里 GPS 实时位置、预计到达时间，全都有。问题在于，这些数据从来没进过 YMS。两边各说各话，断点正好卡在月台这个最要命的地方。

预约表排的是"应该几点到"，卡车活在"真几点到"

一个典型的上午：排班员八点把 TMS 导出的表格一个个敲进 YMS，门、时间窗口、预约号，整整齐齐。敲完那一刻，这张表就开始过期。

TMS 那边，卡车在高速上堵着，GPS 每几分钟更新一次位置，预计到达时间一路往后滑。YMS 这边，预约一旦录入就成了静态计划——除非有人手动改，否则雷打不动。月台工人提前一小时把人力、叉车、暂存区都备好了，车没来；两小时后车到了，预约窗口已经过了，门被别的车占着，司机在园区门口堵着，调度员一个电话一个电话地灭火。

前年去过一家安大略的 3PL 仓，收货主管跟我说，他们每天上午十点要开一个"对表会"：排班员、收货组长、运输协调员三个人，对着 TMS 的在途列表和 YMS 的预约表，人工找差异。三个人，每天一小时，干的就是两台系统之间的数据搬运工。听完我只有一个想法：这活儿就不该是人干的。

园区里排队等待进月台的卡车

数据其实都有，卡在没人认领的交界上

很多人第一反应是"接口问题"。真不是。主流 YMS 和 TMS 厂商都有开放接口，文档写得漂漂亮亮。真正的卡点有三层，一层比一层难。

第一层是数据标准。TMS 说的"预计到达"，是按运输里程碑算的：离场、在途、距目的地还有多少英里。YMS 的预约，是按"月台占用窗口"算的。两边的"到达"根本不是一回事——卡车到了园区大门口，算到了吗？还是进了月台、车轮顶上挡轮器那一刻才算？YMS 的预约窗口从哪一刻开始计时，TMS 压根不知道。

第二层是事件粒度。TMS 的 GPS 位置是连续的数据流，YMS 的排班是离散的事件。把连续的位置流变成"晚点 47 分钟，建议把 10 点的预约挪到 11 点"这个动作，中间需要一整套业务规则：晚点多少分钟才触发改约？改约是自动的，还是人工确认？改约之后，原来那辆车腾出来的门给谁？这些规则，没有一家厂商会替你写好。

第三层，也是最要命的一层，是责任划分。TMS 归运输部管，YMS 归仓储运营管。运输部的考核是准时率和运费，仓储部的考核是收货效率和人力成本。"在途位置进排班"这件事，运输部觉得那是仓库排班的事，仓储部觉得数据在你们 TMS 手里。断点正好长在两个部门的交界线上，没人认领。十个打通失败的项目，九个不是死在技术上，是死在这里。更微妙的是，两边要的数据根本不是同一个东西：运输部引进在途可视化，是为了考核承运商，数据粒度按"整票"走；仓储部要的是"这辆车几点进门、占哪个门"，粒度按"车次"走。集成会议开三次就散了——谁都不觉得这是自己的考核指标。

顺带说一句，数据本身早就不是问题。美国从 2017 年 12 月强制推行 ELD（电子行车记录仪）之后，基本上每辆在途的整车都在持续上报位置。数据不缺，缺的是有人负责把它送到排班表上。

三种打通办法，一个比一个贵

办法一：人肉打通。排班员每天定时去 TMS 或可视化平台看预计到达，晚点的手动在 YMS 里改约。代价最低，一分钱软件费不用花。代价是人：排班员变成全职盯屏员，一天几十个预约根本盯不过来，人一换班信息就断。小仓、车次少的可以这么干，车一多就是慢性自杀。

办法二：接在途可视化平台的预计到达时间进 YMS。市面上有专门做在途追踪的平台，聚合承运商 GPS 数据，输出相对靠谱的预计到达。部分 YMS 厂商已经预置了这类对接。代价是订阅费加一次 IT 集成，还有数据质量的坑要填：承运商设备掉线、信号漂移，预计到达时间跳来跳去，YMS 要不要每次都跟着改，得先定好规则。适合车次中等、有专职 IT 的仓库。不过有个隐形成本：承运商的 GPS 数据质量参差不齐，大车队自建平台数据很稳，小承运商靠手机应用上报，断线是常态。YMS 厂商的预置对接一般只覆盖头部平台，你家那几家长期合作的小车队很可能不在名单里——集成完发现覆盖率只有七成，剩下三成还得人肉。

办法三：TMS 和 YMS 统一到一家厂商，或者自研打通。数据模型天然一致，晚点事件直接触发改约流程。代价最高：换系统是伤筋动骨的事，实施周期按月算，老系统的历史数据和操作习惯全要迁移。除非你本来就要换系统，否则别为了这一个断点掀桌子。

立项之前，先老老实实回答这六个问题。答不上来，就别谈集成：