运输管理系统未来从软件采购转向运营模式

详细拆解

先把这件事放进系统里看，别急着放进市场里看，市场那套说法最容易把人带偏。运输管理系统本质上就是一个队列控制器。订单进来，系统给它配承运商、配价格，货开始走，异常叠在运单上一层一层冒出来，月底统一结算。到达、匹配、执行、异常、结算，这台机器就这五块。6月23日Logistics Viewpoints那份报告说的是，这台机器现在越来越常被连着人和运力一起卖出去。这个变化，比任何一份功能对比表都要大得多。

我两边都待过。我卖过这套系统，也做过那个早上七点必须把系统的输出变成真的人——那天卡车没来。每一次出问题的都不是功能，是异常队列。没人盯的那票货，接了竞价最后又悄悄没去提货的承运商，晚了一天的预约最后变成三天后的缺货。这些都是队列事件，不是软件事件。报告用很客气的市场语言，说的其实就是这一句：软件自己清不掉这个队列。

所以请把报告里那句承重的话记住。原话是：TMS能让运输管理做得更好，但它不会自动带来运输上的卓越。我会说得更狠一些。TMS是一个测量层加一个分配层，它没有手。没有手的时候，它只是把失败记录得更快、排版更好看。下面我写的所有内容，都从这一个区分里长出来。

报告的事实陈述很窄，我也想让它保持窄。它说的是：TMS、管理运输、货运经纪、数字货运平台、控制塔和第三方物流（3PL）服务之间的边界正在变得不那么清楚。它说的是：买家走进来要的是软件，真正需要的可能是一套更好的运输运营模式。它说的是：正在被组装起来的那个包裹里，装的是技术、执行能力、市场准入、分析、工作流自动化和结果承诺。这些都是报告自己的话。我不往里加东西，也不点厂商的名，因为一点名，专栏就变成广告了。

把它翻译成系统图。过去这六类各占流程里的一个格子。TMS厂商占规划、执行和结算。经纪商占运力寻源。管理运输服务商替托运人操作货物。3PL提供物流服务。可视化服务商负责追踪。控制塔负责监控网络表现。六个格子，六份合同，每两个格子之间有一道靠人工维护的接口——靠邮件、靠表格、靠记性。每一道这样的接口，都是队列会长出来的地方。

所谓融合，不是一次营销事件，是一次删接口的事件。经纪商做了一个面向托运人的平台，行为上像个轻量TMS，一道接口没了。TMS厂商加上嵌入式采购和运力准入，又一道没了。管理运输服务商把软件、人、分析和承运商管理打包进一份合同，一次没了三四道。接口变少，队列变短，队列变短是值真金白银的。这部分才是我想让你动手的地方，它跟一家供应商把自己归到哪个类目毫无关系。

把它想成一个队列，因为它本来就是。工作按某个速率到达，人或者系统按某个速率处理它。到达速率逼近处理速率的时候，等待时间不是直线上升，是弯曲上升。队列跑在50%利用率上，感觉很平静。跑到80%，还管得住。过了90%，等待时间就不再跟你认识的任何东西成比例了。你不用把数学当信仰收下。取两个点：80%利用率时，平均等待大约是处理时间的4倍；95%利用率时，大约是19倍。同一批人，同一套流程，同一个团队。变的只有一件事，就是你离满负荷有多近。

把它套到运输部门上。你的团队就是服务器，异常就是到达量。假设——这是我的假设，不是报告里的事实——你一个月走400票货，其中18%至少产生一个需要人工处理的异常。那是72个异常，一个工作日约3.3个；如果每个异常算上打电话和跟进要22分钟真实工时，那是每月26.4小时，每周6.6小时。按40小时一周算，利用率16.5%。看着挺好。现在假设承运商组合变了、某条线变紧，异常率从18%升到26%。

那就是104个异常，每月38.1小时，每周9.5小时，利用率23.8%。纸面上还是挺好。但异常不是均匀到达的。它们是成簇到达的：周一、月底、风暴之后、码头关闭的时候。在成簇的那几个小时里，你跑的不是24%，是90%以上，而这几个小时里的等待时间，正是你的服务水平死掉的地方。这就是为什么我们有产能和我们做到了承诺时效完全是两句话，谁也不该在复盘会上用前一句去回答后一句。

这里的瓶颈在哪儿？所有人都以为是计划引擎，因为演示的时候放的就是计划引擎。几乎从来不是。现代系统几秒钟就能把装载计划做出来。真正的瓶颈在“系统发现了”和“一个有权限的人动手了”之间那个环。这个环里有四个卡点。发现：到底有没有人看见这个异常，还是只有客户打电话来才发现。分诊：今天标出来的四十件事里，哪四件真的要紧。权限：看着这件事的人能不能真的重新订舱，还是必须往上汇报。闭环：这个修复有没有回写进去，让同一个异常下周不再触发。把这四个卡点打通，你从一套平庸系统里拿到的东西，会比从一套优秀系统里、四个卡点全敞着拿到的更多。

先量化，再谈优化。这句话我在每篇专栏里都说，还会继续说。在你看下一场演示之前，先花四周测四件事。异常率，按每百票的异常数记，按线路和承运商分开。发现滞后，从物理事件发生到系统里打上标记之间的小时数。恢复周期，从打标记到确认修复的小时数。人工触碰率，需要人去做系统本该自己做的事的票数占比。这四个就是你的基线。没有基线，你听到的每一句承诺都无法证伪，最后你只会在一场演示的说服力上掏钱，而那是所有购买理由里最糟的一个。

如果你想要可以吵架用的阈值，这是我的。异常率：每百票8个以下算健康，8到15还能管，15以上说明出问题的是承运商组合或者主数据，不是软件。发现滞后：涉及客户承诺的30分钟以内，纯内部事件的4小时以内。恢复周期：当日达的2小时以内，其余8小时以内。竞价接受率：合同线路上90%以上是正常，低于80%说明你的路由指南是虚构的，再多的自动化也救不回来。人工触碰率：超过20%，真正的项目就是主数据。ETA准确度：拿预测的到港时间和实际进闸时间比，国内段平均绝对误差压在12小时以内，海运段36小时以内。比这更差，你下游所有库存决策都是在噪声上跑的。

现在算一笔账，所有假设都摆在台面上。假设每月400票，异常率18%，也就是72个异常。假设每个异常耗22分钟人工，也就是每月26.4小时。假设含管理费用的工时成本是每小时60美元，那么直接处理成本是每月1,584美元。再假设这72个里有12个是发现晚了，恢复时要付加急、现货溢价补舱或者错过预约，假设每次420美元。那是5,040美元。合计每月6,624美元，一年大约79,500美元，光是处理异常。

再看另一边。假设报告里描述的那种打包模式把你的异常率从18%压到12%——不是靠什么魔法，是因为别人接走了承运商准入、路由指南维护和非工作时间的异常值班。400的12%是48个异常，每月17.6小时，1,056美元处理成本。假设发现晚的从12个降到5个，那就是2,100美元。合计每月3,156美元，一年大约37,900美元。差额大约是每年41,600美元，每月3,468美元。这个差额到底比你为打包模式付的服务费大还是小，是唯一真正要紧的问题，而这个问题你用一个下午、拿自己的数字就能回答。我的数字只是脚手架，换掉它。

这就是完整的采购判据，也是功能清单让我提不起劲的原因。一个功能改变一个任务，一套运营模式改变一个比率。比率会复利，功能不会。如果一家供应商说不出它打算改变你的哪个比率、改变多少，那你买的不是运营模式，你买的是一份授权。

报告里关于经纪商和TMS厂商为什么朝对方走过去的那段，是全文最有用的一段，值得用系统语言重说一遍。经纪商过去的利润来自寻源和处理交易。数字货运模式成熟之后，他们需要能让托运人询价、投标、追踪、分析而不用拿起电话的接口，因为电话不具规模效应。而TMS厂商那边也想明白了：执行决策取决于运力可得性和市场价格；一个能推荐承运商、却帮不上运力问题本身的系统，恰好在最要命的地方受限。双方都不是想变成对方，都是想删掉推荐和覆盖之间那道接口。对托运人来说这是好消息，因为推荐和覆盖之间那段空隙，正是你大部分加急费用的产地。

报告还列了买家真正缺的东西，我把它压成三个系统问题。缺运输人手，区域运营碎片化，承运商表现难管，缺货运采购分析，缺精细系统需要的数据质量，需要的是流程重做而不只是把流程数字化。压完之后就是三个：产能、数据、流程。这三个都会出现在你那四个基线指标里。人手不够表现为发现滞后。区域碎片表现为人工触碰率。承运商表现差表现为异常率。数据质量差则是四个指标同时变差，而且它会悄悄让前三个失去意义——主数据错了，你的异常率量的就不是你的运营，是你的录入。

报告说没有唯一正确的答案，我同意，但我想把这句话从外交辞令变成可操作的东西。在市场层面确实没有唯一正确答案。在你自己那四个数字的层面，通常恰好有一个正确答案，而且你能算出来。异常率高、发现滞后长，答案就是运营模式。两个都低、但人工触碰率高，答案就是在现有系统里做自动化。竞价接受率低于80%，上面两个都不是答案，因为你的路由指南根本没被执行，先把这个修好再谈花钱。先把数字跑出来，关于类目的争论就会变得很无聊，而那是这件事能有的最好结局。

控制塔是这件事真正变乱的地方，报告自己也很诚实。企业想要一个整合视图，同时看到运输表现、异常、对库存的影响、客户风险和网络中断。这个需求装不进任何旧类目，于是它可能由软件厂商交付，也可能由3PL、管理运输服务商交付，或者由内部团队拿四个工具拼出来。我在这件事上的规矩一点都不漂亮：指定一个系统作为货在哪里的唯一事实来源，其他所有东西都从它读。两个系统对同一个柜子说法不一致，那不是冗余，那是你的运营团队每天早上都得裁定的一场争论，而他们会用最后看到的那个屏幕来裁定。

说说现在该干什么，从报告出来那一周开始算。6月29日那一周，让你的运输负责人开始记四周的异常台账。一个异常一行，五列：线路、承运商、事件类型、发现时间、关闭时间。先别自动化，也先别买东西，就把台账记起来。到7月10日你会有两周数据，到7月24日有四周。从里面算出那四个基线数字，然后过一道闸：如果异常率高于每百票15个，或者涉及客户的事件发现滞后超过4小时，你就没有软件问题，也不该在跑软件选型。

你有的运营问题，你该去买的是运营模式。如果你的数字都在这两条线以下，那单买软件是完全正当的答案，正常选型就行。但给它加一个条件：演示必须跑在你自己的线路上、用你自己的历史货量，评分按实际达成的竞价接受率算，不按展示了多少屏。

打包模式最难的部分不是技术，是度量条款。你要买的是结果承诺，就得把结果定义成双方在同一天、用同一份数据都能算出来的东西，而且要在签字之前做完。有四件事必须写进纸面：哪些事件算异常，从谁的时钟开始计时，什么算一次恢复，谁负责回写。我见过这类合作在这条款上翻车的，比在任何技术问题上翻车的都多。一家供应商如果讲不清自己的服务水平是怎么算出来的，那它不是有服务水平，它是有个故事，而差额最后由你付。

替代方案有三种真的，一种假的。假的那一种是等类目重新变清楚。不会的，而等下去的代价，是你本可以存下来的一年份的可量化改善。第一种真的，是自己运营的同类最优软件。报告说得很明白：如果你已经有运输人手、采购纪律和流程成熟度去用好它，这就是对的。一旦异常率涨过你的团队在成簇时段能吸收的量，它就不再是对的。第二种真的，是配强技术的管理运输服务，当问题本身就是队列、而你又不想为它招人时，这是对的。第三种真的，是嵌入式经纪和采购，当真正卡住你的是运力准入而不是流程时，这是对的。按哪个变量真的在卡你来选，别按哪份宣传册先到你桌上选。

坑也点一下，因为它们都很便宜就能避开，发现的时候却都很贵。买了软件，而真正的问题是运营能力——报告把这条列成两个错误答案之一，也是我见得最多的一个。把执行外包出去，而你真正需要的是更好的内部流程控制——这是第二个错误答案，被低估了。签了基于结果的合同，而结果本身没有定义。承运商准入的速度快过你清理主数据的速度——建立在过期运力数据上的路由指南，失败的样子和软件失败一模一样。最后一条：以为算法会替你扛。不会。它只会告诉你队列在哪儿。清掉队列的是人、流程和运力。

这些话里没有一句把模型当成英雄，我想说得直白一点，因为这个市场最不需要的，就是再来一轮软件会把活干了的信心。6月23日那份报告让我在意的地方，不在于它预测了一个新品类，而在于它悄悄承认了每一个管过运输台的人都懂的事：软件从来不是难的部分。把异常队列一周一周、一个季度一个季度地压下去，并且给它挂上一个你们能吵架的数字，那才是难的部分。周一开始测。

↑ 返回核心要点

— 作者 拉维