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

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

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

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

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

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

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

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

1. 自营物流：商家自己搭建的配送提醒，使用自己的配送车辆和配送员送货上门，如京东等大型电商；
2. 第三方物流：借助市面上已经成熟的物流体系进行配送，如三通一达，如美团配送、达达配送、蜂鸟配送等；
3. 聚合物流或叫第四方物流（4PL）：将多方配送资源进行整合，提供整体解决方案的第四方，第四方在整个供应链中承担平台信息发布、信息匹配和撮合、物流资源继承，物流解决方案等角色，能够为商家提供配送方式的最优解，往往会按照一定的策略，呼叫价格最低或依次呼叫配置的承运商以达到配送的目的。目前针对于O2O业务，国内开展相关业务的公司有麦芽田、餐道等。聚合物流的实现，依赖于第三方物流开放接口能力，目前主流的承运商，都开放了接口能力。

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

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

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

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

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

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

四、方案范围的确定

1. 从商业模式来看

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

2. 从当前业务场景来看

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

1. 平台配送：店员拣货后，通知外卖平台已拣货，平台会按照合同约定呼叫骑手配送；
2. 商家自送：店员拣货后，店员自行将货物配送到顾客手中；
3. 聚合物流：店员拣货后，OMS系统呼叫第三方承运商进行配送。

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

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

3. 从“三流”来看

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

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

1. 对信息流管理：通过接口调用，实现配送状态、配送位置、配送员信息等数据在多个系统间的一致性；
2. 对物流进行管理：承运商的调度、支持商家自送订单发货、签收等功能、配送范围的划定；
3. 对资金流进行管理：上文说到盈利模式，从ROI考虑，我们最终选择了使用功能直接付费的方式进行盈利，即在商家呼叫第三方物流的时候，商家直接与承运商进行结算，不通过4PL系统。

1. 在平台呼叫配送的场景下，顾客支付运费直接结算给外卖平台，同时外卖平台收取商家的履约服务费，在订单收入结算给商家时，已进行了扣除；
2. 在商家自送的场景下，顾客支付的运费通过外卖平台结算给商家；
3. 在商家呼叫第三方物流的情况下，顾客支付运费通过外卖平台结算给商家，商家再和承运商结算。

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

五、领域模型的设计

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

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

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

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

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

1. B端日志需要进行详细记录，一个状态是因为什么发生改变的，什么时候改变的，往往是后续进行问题分析的一手资料，故不能覆盖；
2. 遵循状态可逆原则。状态可逆后，造成的问题很多，在供应链领域，一个单据往往是线性发展的，而不像OA系统的单据，可能往往是需要反复确认反复调整的；
3. 各平台的收费机制不同：配送单，是OMS系统发货用例的输出物，以及TMS系统的输入物，由于tms系统中，对应输入物还存在，那么上游系统中对应的输出物就应该存在，否则进行财务对账时，则凭证不对应。

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

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

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

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

1. 骑手无义务将部分退商品送回门店；
2. 顾客不将货物送回，门店选择自行取回成本较高，导致商品取回后继续售卖获得的利润小于退货取回的成本；
3. 顾客不将货物送回，门店选择向平台申诉，申诉成本较高，且该诉求平台一般不予支持。

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

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

1. 美团配送：骑手揽件成功才收费，揽件后取消配送，不返回费用；
2. 达达：骑手揽件成功才收费，揽件后取消配送，不返回费用；
3. 顺丰同城：发单成功就收运费，骑手接单后一分钟内取消都返还，一分钟后的会扣2元配送费，剩下的返还；
4. 蜂鸟：骑手揽件成功才收费，揽件后取消配送，不返回费用。

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

1. 创建承运单时

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

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

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

2. 待下发状态时

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

3. 已创建状态时

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

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

1. 部分退申请：继续配送；
2. 整单退申请：OMS调用接口取消配送，运费损失由商家承担。大部分商户来讲，仍然期望可以由店员联系用户后，手动确定是否同意退货，出发点仍然是企业的价值取向或经营策略，避免不必要的投诉和差评，而非一味的避免直接营收损失。

4. 骑手已分配状态时

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

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

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

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

1. 推进店员交接货物时，复核一下是否有未处理的退单，将已退货的商品捡出。这种方式实际增加了店员的工作量，推行实际是比较困难的。
2. 骑手已分配，运费已确认结算给承运商了，此时退单统统自动拒绝。部分客户仍然会因为上文中的原因挑战此逻辑。
3. 承认这种场景的存在，并且承担相应损失：即时从逻辑推演来说，这是最差的方案，但是如果考虑到其他方案店员的工作成本、方案推行成本，潜在的被差评的成本，在退单量较小的情况下，反而是此方案的成本和损失是最小的。

5. 揽件成功状态时

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

七、发单时机的逻辑设计

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

八、详细产品设计

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

1. 调度逻辑说明

2. 保底机制说明

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

1. 找一个配送质量较好但是收费高的承运商作为最后一个承运商；
2. 系统会默认商家承运商为最后一个承运商，当配送流转到商家承运商时，店员可自送配送或重新呼叫承运商。

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

一般有两种方式：

1. 按照价格由低到高呼叫：4PL系统调用各承运商平台预创建订单接口，获取承运商是否可配送以及运费，4PL系统由低到高的呼叫承运商。如承运商在预设时间内，仍无骑手接单或承运商直接抛异常，则呼叫下一承运商；
2. 根据预设顺序依次呼叫：如创建订单失败、或承运商在预设时间内，仍无骑手接单或承运商直接抛异常，则呼叫下一承运商。

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

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

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

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

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

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

题图来自 Unsplash，基于 CC0 协议