聚合物流系统（4PL）解决方案该如何搭建？这是我的设计思考

编辑导语：一个系统的运作，是由系统的功能加上外部的运营和操作等一系列功能共同组成的，那么该如何设计一个聚合物流系统（4PL）呢？本文作者通过这篇文章与我们分享了他的解决方案和设计思考，一起来看看吧。

一、前言

从这篇文章开始，我给大家介绍一些OMS系统中具体方案的设计思考。

我一直喜欢用解决方案的设计替代功能设计的说法，俞军老师曾经在《产品方法论》中说过：系统内的设计是为了推动、限制系统外的动作，但是系统外的动作并不全由系统内的设计进行驱动和限制。故一个系统运行时，实际是系统的功能+系统外的运营动作、规章制度、操作规范功能共同作用的。

那么聚合物流系统的解决方案应该如何设计呢，系统内系统外各动作又是怎么影响最终的解决方案的呢。

二、自营物流、承运商、聚合物流（4PL）的概念解析

在开始正式设计之前，需要分清物流配送系统是做什么的，以及几种物流方式。在供应链系统模型（SCOR）中，配送属于在五大流程中的【交付】流程，一般发生在分销商和零售商以及零售商和终端用户之间，但OMS系统中仅涉及到零售商和终端用户间的交付。

同时，我喜欢的一位作者“木笔老师”曾经在《实战供应链》一书中阐述了不同的物流方式的区别：

三、没有4PL系统前遇到了什么问题

回归到笔者面临的具体业务场景上来，我们遇到了什么痛点，要求我们提供4PL的能力呢：

第一：平台履约服务费造成毛利率进一步降低：以美团、饿了么为例，商家可以选择和平台签约配送合同，订单由平台呼叫对应的美团配送和蜂鸟配送，平台要额外收取履约服务费，一般2-6元不等，进一步降低了毛利。

第二：平台呼叫配送或自营物流在极端天气或节假日时，均可能会出现长时间无骑手接单或其他无法配送的情况，造成无效订单，进一步影响商家经营情况。

第三：自建物流成本较高，部分中小商家无力承担，但是使用平台的第三方物流时，又只能获取标准的配送服务，对于冷链等特殊配送要求适配性不足。

那么由于单一的自营物流或第三方物流，已经无法满足部分商家的诉求了，那么此时聚合物流系统（4PL）应运而生。

四、方案范围的确定

1. 从商业模式来看

在精益创业一书中，我们在描述一个商业模式时，经常需要考虑产品的收入流以及成本结构，即通过投入和产出(ROI)，来分析可行性，同时商业模式也决定了产品的方案的范围。

2. 从当前业务场景来看

由于笔者所负责产品主要面向便利店客户，进行美团等平台的O2O业务，即要求3-5公里范围内的即时配送，不涉及商城、跨境等业务。那么在当前的业务下存在三个配送场景：

虽然有所差异，但是我们应该认识到本质都是发生在零售商和终端用户之间的交付流程，可以抽象成一个用例，如图所示：

那么方案范围中，需要统一管理这三种业务场景。

3. 从“三流”来看

在物流配送过程中，会发生了位置的移动，信息的流动和资金的流动。不同的场景下，物流、资金流、信息流的表现略有不同，如图所示:

当我们对三个流进行管理过程中，也提出了对方案范围的要求：

故：

我们可以发现，不同配送场景切换时，需要注意资金数据的变更，以免出现财务对账问题。

五、领域模型的设计

从实际业务来看，一笔订单由于拆单，可能会由多个门店发货，或者由一个门店多次发货，故订单和发货单的关系是一对多的关系。一笔发货单，可能尝试由多个承运商依次发货，故发货单和配送单的关系，也是一对多的关系。

4PL系统中，一个很重要的点，就是当其他承运商异常无法配送时，要使用其他承运商继续配送。为什么配送失败了，要重新搞一个实例，而不是用原来的呢？原因如下：

如第一个承运商长时间无骑手接单，此时4PL系统需要调用接口取消该承运商的配送，重新呼叫其他承运商。但是由于取消配送是异步交互的，需要等待承运商系统返回取消成功的消息，也有可能取消失败，需要重复取消申请，我在任务中心的设计《我对B端任务中心功能的设计思考 | 人人都是产品经理 (woshipm.com)》也说明了这个情况。

也就是说该配送单无法到已取消的状态，那么如果该配送单直接更新成其他承运商的数据，系统就不方便进行重试取消的操作了，因为没有业务单据承载这个动作了。

从普遍的设计经验来看，也有以下原因：

六、逆向订单造成的配送截停逻辑设计

一般来说，配送单的状态机设计如下：

那么在配送单创建时，待下达、已创建、已分配骑手等各个状态节点，都有可能发生顾客的退货申请。此时我们如果继续呼叫配送，就会出现以下问题。

1）顾客部分退货申请通过了，但是骑手仍然将所有的货物都配送到顾客手中。此时：

那么，店员只能将货物报损，造成商家损失。

2）顾客全部退货申请通过了，但是配送费已经结算给承运商了，造成这笔订单无收入，但是产生了配送费用。如：

那么从企业应收的角度来看，我们必须保证货物不超发，同时杜绝无效配送费支出，以减少对企业营收的影响。但是在实际设计过程中，我们需要权衡的因素很多。那么我们分场景看一下，不同状态节点截停逻辑的设计权衡。

1. 创建承运单时

检查是否有未处理退单，如果有，则不生成配送单，并通过强制通知功能通知相关人员处理，见文章《我对B端通知提醒功能的设计思考 | 人人都是产品经理 (woshipm.com)》。处理完成后，正常呼叫创建承运单。

当然，这个逻辑受到了业务方很大的挑战，O2O业务与电商业务不同，履约时效性非常强。那么即时通过强制通知等强提醒的手段，要求相关人员及时处理退单，仍然可能出现拉长履约时间进而导致客诉的场景出现。

那么有客户就认为：履约时效性高是客户希望给顾客展示的企业价值取向，这个的价值大于由此带来的损失。那么对于SaaS来讲，也应该尊重客户的选择，并可以通过配置的方法来实现不同客户的价值诉求，可参考文章《我对B端系统配置功能的设计思考 | 人人都是产品经理 (woshipm.com)》进行配置的设计；

2. 待下发状态时

此时OMS正在尝试呼叫承运商，顾客申请退货，此时应将配送取消，等待退单审核完成后，根据是否需要继续配送，来决定是否是否重新呼叫配送。此逻辑仍然与创建承运单时截停的逻辑一样，被客户以相同的方式挑战。故也需要进行配置；

3. 已创建状态时

此时在承运商侧下单成功，顾客申请退货，但需要区分不同的承运商的政策：

顺丰同城：由于发单成功就扣减运费，故系统自动拒绝顾客退货申请，或建议店员手动拒绝顾客退货申请，此时不自动取消配送。如果店员同意退货，那么会有两种情况：

4. 骑手已分配状态时

此时承运商已经分配骑手，骑手到店取货，顾客申请退货。

骑手取货的过程，实际是物权移交的过程，OMS系统要在这个时机，实际在ERP系统中扣减库存，增加收入。

这个时机也是最后一次店员有机会避免货物超发的时机，因为在承运单生成前后发生的退货申请，店员都有可能由于种种原因，没有处理，如果在骑手取货交接货物这一流程中，如果不查看是否有未处理的退单，就会造成货物的超发或者无效的配送。

电商业务由于履约时效性没有O2O业务时效性这么强，仓库发货作业也更加严谨，所以通常在出库时是需要仓库人员手工复核的，但是O2O业务，门店发货的场景下，我们有几种方式来应对：

5. 揽件成功状态时

骑手已经正在配送了，系统自动拒绝顾客退货申请，或建议店员手动拒绝顾客退货申请。与上文一样，要支持不同的客户不同的配置。

七、发单时机的逻辑设计

那么接下来要理清楚的一个问题，就是在各个配送场景下，什么时机发单给承运商。

八、详细产品设计

接下来我们进行详细的产品设计：

1. 调度逻辑说明

2. 保底机制说明

商家在呼叫第三方物流时，总会出现预设的承运商都无法配送的场景，那么就需要一个保底机制，一般有两种方法：

3. 第三方承运商呼叫机制说明

一般有两种方式：

4. 最后，我们就可以理解页面上的各种设置功能的作用了

九、结语

复杂及解决方案的设计过程，就是权衡的过程，不存在完美的选择，需要在【第三方——用户可用性易用性——不同客户的价值选择——SaaS的商业选择——SaaS本身的技术能力】之间保持平衡，必须多方面的考虑ROI，做出逻辑上的取舍。不可避免的，要有很多配置，请看文章《我对B端系统配置功能的设计思考 | 人人都是产品经理 (woshipm.com)》。

另外请读者思考，如果最开始，我们没有将三个不同的配送场景抽象统一起来，而是当作三个不同的用例设计，那么我们会将系统设计成什么样子，我们可能会增加三个配置页面：当平台配送异常时，我们如何如何处理，商家自己配送异常时，系统如何如何处理，然后用配送方式字段来区分，平台配送无配送单，其他的有配送单……

但是，我们在系统设计过程中，总是希望将共性的逻辑提炼出来，这样将大大减轻用户的认知成本，同时也利于提高系统的可复用性，如果我们为每一个场景都设计一套逻辑，一套界面，那么用户使用体验是割裂的，界面设计将是冗余的，希望读者可以理解里面的细微差异。

本篇文章想表达的很多，但是受限于个人的能力，所以有些需要详细的地方但是表达的很粗略，有些需要简单说说的，又显得长篇大论，希望大家给出意见和建议，我一定会吸取采纳。后续会更新OMS系统的核心逻辑的设计，敬请期待。

本文由 @kathic 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议