多点装载模型的思考

零、引子

在入职当下这家传统企业前，一直在搞营销、销售、渠道相关的B端产品工作。阴差阳错的入职到了供应链团队，好在基建极差，让我也可以有一些利用价值，与公司共（合）同（理）成（摸）长（鱼）。

某日聊起业务的现状时，自发的提出了一个新的需求，即支持物流合单。遂有了如下思考。

一、业务现状

目前订单并非行业标准的中台服务型的订单，即与支付解耦，与履约解耦，与商城解耦。通过标准服务来响应各来源的交易请求记录，适配不同的支付服务和履约服务。

当下的订单更类似于基于产销协同模式下的干线物流订单。

在这个描述中，拆解其中的定语：

1、产销协同模式，不同于标准的2C电商订单，在F2B（工厂to企业客户）逻辑中，订单并非是客户要什么，我们就有什么，也并非是现货销售。为降低供应链成本，降低库存压力，平衡生产效率，整体的业务状态为生产团队与销售团队沟通未来一段时间内的需求数量，进入生产计划进行排产，生产完成后进行履约。

单独看这一个特点，对订单的影响相对较小，无外乎就是直接查找库存还是进入某一个计划池内将所有未来可计划的商品数量统一看做库存的问题。

2、干线物流，同样不同于标准的2C电商订单，F2B模式中，某一订单内的商品数量需要依据履约团队的物流能力来限制。如传统物流常用到的9.6米货车，13米货车等，其对应的履约能力限制了订单内的商品的数量。如9.6米的货车仅允许订单内的商品为3600箱标准箱饮料，以订单的视角就会对订单生成一刻订单内的商品数量是否合规做校验。

数量较约定值小时，车辆并非装满的，装载率低，对应的单车物流费比就会高；数量较约定值大时，车辆超载，无法运输。

二、业务预期

无论是以业务的视角看，还是以中台订单系统的视角看，均不希望出现上述情况。前者更希望系统灵活到可以有多个订单拼在一起下单，后者希望和履约系统解耦解的更彻底。

这里就谈及到了多点装载和多点卸货的物流拼合单的体系建设了。

三、一些思考

在2017年做订单建设的时候，整体的业务系统的链路是商城下发订单至OMS，OMS处理订单下发至OMC，OMC整合订单至WMS与TMS做履约服务。

所以在当前公司聊起拼合单由订单去搞的时候我是懵逼的。这尼玛压根就没听说过啊……

好在后边新入职的履约团队开发的TL是明事理的。经过一番友好磋商，确定了结论。也有一些行业内人早就懂了，而我还觉得很有意思的事情。

1、多点装卸模型

从前搞订单的时候，只考虑订单的被合单，即两个订单下发至供应链后，由供应链团队在仓储和物流阶段进行合并履约，履约完成后单独回溯订单完结。

在物流合单体的模型中，以F2B的干线物流形式举例，往往某几个客户的距离较近，可以多点卸货（先将商品配送至A客户处，后续继续配送至B客户处）；同时，受货源地影响（如M商品仅在X仓存储，N商品仅在Y仓存储），物流体系需要支持多点装载，即某一次物流服务，先至X仓装载M商品，再至Y仓装载N商品。

整体物流体系的产品设计为底层支持多点装载，上层由策略进行单据合并，合并处理完成后生成业务执行的指令/单据。

2、分段式装卸

在基于上述模型中，会发现存在这样的一个问题，示例为A与B客户均从X仓采购B商品构成一车，物流运输从X仓出发，先至A客户处卸货，卸货完成后将剩余商品装载至另一较小车型后再运输至B客户处。

出现此类业务情况的原因是车辆1由于同时装载了A客户和B客户的需求，整体装载量较大，车型较大，导致其物流成本较高，在A与B前半段路程共同的前提下，使用车辆1运载共同需求至A客户处，可更优的节省成本，但从A客户至B客户处，原有车型会使整体物流成本较高，此时更换较小车型可节约成本。

对于客户来讲，A客户的货物履约轨迹为X→A，B客户的轨迹为X→A→B，而非X→B的两点直配。