干线、支线、城配，为什么不能用同一套调度规则

很多企业上了 TMS 之后，第一反应是把所有运输都拉进系统，再用一套统一规则派车。 听起来很标准，实际最容易把系统做废。 因为干线、支线、城配看起来都是“运输”，但它们面对的约束、成本结构、时效目标和异常类型根本不是一回事。 用同一套调度规则去管，最后往往不是更统一，而是更混乱。

一、干线、支线、城配，表面上都是送货，本质上却不是同一类业务

先把这三类场景分清。

1. 干线

重点是跨区域、大批量、长距离。 核心关注的是：

• 装载率
• 发车计划
• 线路时效
• 返程资源
• 成本摊薄 干线调度更像“先做计划，再派资源”。

2. 支线

重点是区域间中转衔接，把主干网络和末端节点连起来。 核心关注的是：

• 中转时点衔接
• 干支协同
• 多网点的波次和班次配合
• 节点到达窗口 支线更像网络协同，不只是派车问题。

3. 城配

重点是高频、多点、短链路、时窗密集。 核心关注的是：

• 到店 / 到仓 / 到户时窗
• 多点路径优化
• 订单拆并逻辑
• 司机区域熟悉度
• 临时改单与异常反馈 城配更像实时调度，而不是纯计划执行。 所以这三类运输，虽然都叫“调度”，但干的根本不是同一种活。

二、为什么很多 TMS 项目一开始就做错

最常见的错法是：

• 一个订单模型管全部场景
• 一套派车逻辑适配全部线路
• 一个考核口径同时压干线、支线、城配 结果会出现什么？ 干线想要高装载率，就会倾向于等单、拼单。 城配想要准时到达，就不能总等单。 支线要保证网络接驳，又不能完全按干线那种满载逻辑来跑。 三种目标本来就互相打架。 如果系统不区分场景，调度员最后还是会绕开系统，回到微信群、电话和 Excel。

三、真正该分开的，不只是线路，而是规则模型

干线、支线、城配不能用同一套调度规则，关键不是名字不同，而是下面这些模型必须拆开。

1. 订单模型要拆开

干线订单更关注批量、线路、发车批次。 支线订单更关注节点衔接和接驳关系。 城配订单更关注地址颗粒度、时窗、终端服务要求。 如果三种订单都塞成一张“运输单”，后面所有规则都会变形。

2. 计划逻辑要拆开

干线适合按发车计划、装载率、成本优先来规划。 支线适合按节点节拍和主干配合来规划。 城配适合按区域、时窗、路径、司机资源实时优化。

3. 异常处理要拆开

干线异常更多是晚点、甩挂、返程不稳、线路堵塞。 支线异常更多是中转衔接错位、网点交接断点。 城配异常则更多是收货人不在、拒收、地址变更、临时催单。 如果异常分类不拆开，TMS 最后只会有一堆“其他异常”。

4. KPI 口径要拆开

干线看单位运输成本、装载率、发车准点率。 支线看节点到达率、接驳成功率、干支协同效率。 城配看签收时效率、单均配送成本、异常闭环时长。 KPI 不拆开，团队一定会为了一个指标牺牲另一个真正重要的目标。

四、三类场景分别该怎么配规则

干线：先计划，再派车

干线的核心不是“派车快”，而是“计划准”。 建议先把这些规则固化：

• 哪些线路固定班次发车
• 哪些线路允许等单拼载
• 哪些线路必须保时效
• 回程资源怎么匹配
• 干线成本怎么核算

支线：先定节点，再定资源

支线调度最大的价值，是把主干网络和落地节点接顺。 建议先把这些规则固化：

• 干支切换节点怎么定义
• 到达 / 离开时间窗怎么卡
• 哪些节点允许缓冲，哪些节点必须刚性衔接
• 中转责任怎么划分

城配：先定服务规则，再做路径优化

城配看起来最灵活，反而最不能靠拍脑袋。 建议先把这些规则固化：

• 客户时窗怎么分级
• 多点订单如何拆分与合并
• 区域和司机如何绑定
• 超时、拒收、改址怎么实时回传
• 到店和到户是否走同一套路径规则

五、如果真想把系统做顺，建议按这个顺序落地

第一步：先按场景拆业务，不要先谈功能模块

先把哪些属于干线、哪些属于支线、哪些属于城配拆清，再去映射 TMS 功能。

第二步：分别建立三套核心规则集

至少把订单模型、调度规则、异常分类、KPI 口径分开。

第三步：再决定哪些能力共用，哪些能力独立

比如主数据可以共用，但派车逻辑、时窗规则、节点约束最好独立。

第四步：最后才做算法和自动化

规则没拆清，算法只会把混乱算得更快。

六、结论

干线、支线、城配不能用同一套调度规则，不是因为系统做不到，而是因为业务本来就不该混成一套。 真正成熟的 TMS，不是把所有运输统一成一个派车按钮。 而是能先识别场景，再匹配不同规则，最后把计划、调度、执行和异常闭环成一个清晰体系。 规则拆对了，系统才会越用越顺。 规则没拆对，系统只会把原来靠经验撑着跑的混乱，放大成更昂贵的混乱。