运输管理系统（TMS）——订单系统
物流/快递/货运公司是一个非常传统的行业，其中零担行业CR10（行业集中度）仅有4%左右。同时零担物流相比快递行业而言准入门槛较低，因此产生大量小、散、弱企业，而这些企业很多处于人工记账的阶段，所以当运单出现异常的时候也很难以追踪。
在中大型物流/快递公司因为自身业务高度个性化，以及自身数据安全的安全一般会选择进行自研，比如顺丰阿修罗TCMS、德邦KOSS，百世春雷系统、京东物流赤兔TMS、菜鸟运配宝TMS等；而一些小公司从成本角度考虑一般会选择SaaS供应商，比如oTMS、快货运、唯智、科箭TMS等SaaS系统。
今天主要分享物流行业从客户下单到运单揽件的流程。
基本概念
物流业务都是从寄方客户揽件开始，然后到收方客户派件并完成签收为一个闭环。同时公司提供回单增值服务的话，还存在从收方返单到寄方或第三方的场景，但因其流程与运单运作一致，所以这里不进行特殊赘述。
因存在一个寄件客户同时对多个收件地址寄快递的场景，此时使用运单号作为订单标识就不太合适了，所以这里将客户下单到司机揽件并完成报单之前的过程划分为“订单”。
然后从司机揽件完毕到运单签收的过程划分为“运单”，即一个订单对应多个运单。
由客户下订单，再由司机对运单进行报单的场景更多存在于B端KA客户的场景，如果公司自身业务C端客户较多，可以不区分订单和运单。但无论是订单还是运单，都可能出现需要合单的场景。
订单信息
订单主要记录了客户下单的信息，以及司机到达客户处所需要地理信息。
订单号
订单号是一个订单的标识，一般根据订单的增加进行自增。如果与外部进行业务对接时会展示订单号，建议在订单号生成规则中加入一定的混淆逻辑，否则竞争对手可以根据订单号的生成规律推算公司当前的订单量，泄露公司的营运信息。
订单状态
前文我们已经对订单和运单的边界进行的厘清，所以订单的状态机有“客户下单”、“已调度”、“取货中”、“完成揽收”四个状态。
这个状态一般会在客户查单时提示客户当前订单的状态，所以文案需要尽可能简单明了，同时状态机也可以根据公司业务需求进行合理地增减。因此处的状态机通俗易懂，所以这里不赘述。
订单来源
物流公司除了自有渠道下单之外，可能直接对接电商网站，甚至还会对接菜鸟、快递100等第三方下单平台。订单来源字段可以作为后续渠道分析的依据，此处不作延展分析。
时间信息
记录订单各个状态流转的触发时间。这里需要注意订单存在正逆流程，需要结合自身业务场景评估是否覆盖原有的时间记录。
如果这里选择了覆盖操作，数据分析将取不到对应的数据；如果选择了不覆盖，那对于调度→取货→调度这种场景下的时间展示需要考虑是否会引起用户的误解。
下单客户信息、取货客户信息
这里将下单客户和取货客户信息分开主要考虑了第三方下单的场景，如果自身公司的下单和取货客户基本都是同一家公司/同一个人时，可以对这两个字段合并为一个字段。
订单流程
订单流程是从订单生成到完成订单的整个过程，因为前文已经对订单和运单划分了边界，所以本文讨论订单只有正向流程而没有逆向流程。
在司机取到货之前，如果客户希望取消订单，那么系统只需要取消司机的任务即可，不涉及实体的空间转移。
比如用户在滴滴叫车对订单取消之后，订单也就随之取消了，同时系统对被取消订单的司机进行优先派单的策略，但并没有对原订单状态产生影响。当司机揽件完毕并进行报单之后，此时订单已转变为运单。如果此时客户希望取消订单时，实际上是对运单发起退货，运单的逆向流程将在后续展开，此处不进行赘述。
订单流程从上图看来只有简单的四个环节，但在“分配司机”和“任务规划”两个模块中一般会独立规划为一个系统。同时给司机派单需要同时考虑订单的时效、司机当前的任务数、司机当前的距离等维度，这里就涉及到运筹学中非常著名的旅行商问题。有些人就会讲系统派单那么复杂，那让司机进行抢单不是更好吗？司机根据距离评估是否承运这个运单。
如果 A 司机抢到一个距离 10 Km的订单，另外一个距离 3 Km的 B 司机反而没抢到；过了一分钟之后，距离 A 司机原来的位置 1 Km出现一个新的订单，这个新订单距离 B 司机 10 Km。
现在再评估这两个订单，似乎并不是一个最优解吧。关于调度策略的问题这里不再进行赘述，后续另文展开。
物流行业也不可避免地存在薅羊毛、恶意竞争的情况，在进行系统规划时根据自身需要在向司机进行派单之前对订单加入一些风控规则，防止有心人进行恶意下单导致调度司机产生空跑的情况，进而造成公司的损失。
订单推送
在订单的状态发生变化时，可以根据将最新的状态推送给相关人员以便了解订单当前的情况，比如说向司机派单/司机抢单之后，将地址告知司机前往客户处进行揽件；比如说订单被取消时，将信息同步给到销售/客服人员确认是否异常。