TMS -运输管理
🏦 场景与客户
某第三方物流企业，自有车辆百来台，外协车辆更多，日均运单几百票，客户以制造业与商贸企业为主。原做法：调度用 Excel 排车，司机在微信群里接单，回单靠拍照发群，财务月底对着聊天记录算运费。
卡点很具体：一票货现在到哪了没人说得清，客服被客户催只能挨个打电话；运费结算时口径对不上，月底和司机、和客户两头扯皮；回单散在群里，丢一张就要重走流程。
📅 实施节奏
- 第 1–2 周：运单与路由模型、计费口径梳理
- 第 3–5 周：调度配载与派车
- 第 6–7 周：司机端与在途节点上报
- 第 8 周：运费结算与对账
- 第 9 周：客户查询门户
- 第 10 周起：上线并迭代
🗝️ 方案要点
- 运单是主对象：下单—配载—发车—在途—签收—回单全挂在运单下，状态只追加不回改，全过程可回放
- 调度半自动：系统按车型、载重、方向、时效给出候选车，调度确认后派车，不追求全自动
- 在途以节点上报为准：装货、发车、到达、卸货四个节点由司机上报，定位只作辅助参考
- 运费走规则：按重、按方、按趟、按公里都可配，规则有优先级，不写死在代码里
- 回单电子化：签收拍照上传并与运单绑定，结算以回单为准，避免口头说「送到了」
⚖️ 选型与权衡
| 选择点 | 方案 | 权衡 |
|---|---|---|
| 在途数据来源 | 节点上报 + 定位辅助 | 上报可靠、定位有盲区；两者要交叉校验，否则会互相打架 |
| 调度 | 系统建议 + 人工确认 | 兼顾效率与老调度经验；异常场景下全自动容易翻车 |
| 计费规则 | 可配置规则引擎 | 灵活，能接不同客户的计费方式；规则多了会互相冲突，需要试算校验 |
| 结算口径 | 以回单为准 | 减少争议；回单滞后会拖慢结算，要配催收机制 |
🚧 实施难点与排查
- 司机不用系统：上了系统还是发微信。根因是上报步骤太多，砍到两步并自动带出定位后才真正用起来
- 轨迹与实际不符：定位漂移，地图上显示车在河里。改为以节点上报为准，定位只画折线不作判断
- 运费算错：同一票货两种算法结果不同。加了规则优先级与试算功能，出账前先跑一遍
- 回单丢失：纸质回单在传递中丢。改电子回单后，结算周期明显缩短
💵 成本与收益
- 成本结构：一次性开发约 3 人 × 9 周量级，另加司机培训与推广人力
- 收益侧：客户查询从打电话变成自助，客服压力下降；对账有据可依，争议明显减少
- 隐性收益：配载建议上线后，空驶与半载情况减少，这是物流企业最实在的成本项
🛡️ 风险与保障
- 数据隔离：运单与客户信息按承运方隔离，外协司机只看自己承运的部分
- 结算安全：所有金额变更留痕，人工调整需审批，不接受口头改单
- 合规：司机证件、车辆资质到期自动提醒，避免用无证运力
- 可用性：司机端支持弱网与离线暂存，恢复网络后补传
♾️ 可复用与演进
- 配载与计费模型可复用到城配、干线、零担等不同业务形态
- 演进方向：接客户系统自动下单，接定位服务商统一轨迹来源
- 再进一步：把时效数据做成准时率看板，成为投标时的实证材料
