编辑导语：一个系统的运作，是由系统的功能加上外部的运营和操作等一系列功能共同组成的，那么该如何设计一个聚合物流系统（4PL）呢？本文作者通过这篇文章与我们分享了他的解决方案和设计思考，一起来看看吧。
一、前言
从这篇文章开始，我给大家介绍一些OMS系统中具体方案的设计思考。
我一直喜欢用解决方案的设计替代功能设计的说法，俞*老师曾经在《产品方法论》中说过：系统内的设计是为了推动、限制系统外的动作，但是系统外的动作并不全由系统内的设计进行驱动和限制。故一个系统运行时，实际是系统的功能+系统外的运营动作、规章制度、操作规范功能共同作用的。
那么聚合物流系统的解决方案应该如何设计呢，系统内系统外各动作又是怎么影响最终的解决方案的呢。
二、自营物流、承运商、聚合物流（4PL）的概念解析
在开始正式设计之前，需要分清物流配送系统是做什么的，以及几种物流方式。在供应链系统模型（SCOR）中，配送属于在五大流程中的流程，一般发生在分销商和零售商以及零售商和终端用户之间，但OMS系统中仅涉及到零售商和终端用户间的交付。
同时，我喜欢的一位作者“木笔老师”曾经在《实战供应链》一书中阐述了不同的物流方式的区别：
自营物流：商家自己搭建的配送提醒，使用自己的配送车辆和配送员送货上门，如京东等大型电商；第三方物流：借助市面上已经成熟的物流体系进行配送，如三通一达，如美团配送、达达配送、蜂鸟配送等；聚合物流或叫第四方物流（4PL）：将多方配送资源进行整合，提供整体解决方案的第四方，第四方在整个供应链中承担平台信息发布、信息匹配和撮合、物流资源继承，物流解决方案等角色，能够为商家提供配送方式的最优解，往往会按照一定的策略，呼叫价格最低或依次呼叫配置的承运商以达到配送的目的。目前针对于O2O业务，国内开展相关业务的公司有麦芽田、餐道等。聚合物流的实现，依赖于第三方物流开放接口能力，目前主流的承运商，都开放了接口能力。
三、没有4PL系统前遇到了什么问题
回归到笔者面临的具体业务场景上来，我们遇到了什么痛点，要求我们提供4PL的能力呢：
第一：平台履约服务费造成毛利率进一步降低：以美团、饿了么为例，商家可以选择和平台签约配送合同，订单由平台呼叫对应的美团配送和蜂鸟配送，平台要额外收取履约服务费，一般2-6元不等，进一步降低了毛利。
第二：平台呼叫配送或自营物流在极端天气或节假日时，均可能会出现长时间无骑手接单或其他无法配送的情况，造成无效订单，进一步影响商家经营情况。
第三：自建物流成本较高，部分中小商家无力承担，但是使用平台的第三方物流时，又只能获取标准的配送服务，对于冷链等特殊配送要求适配性不足。
那么由于单一的自营物流或第三方物流，已经无法满足部分商家的诉求了，那么此时聚合物流系统（4PL）应运而生。
四、方案范围的确定
1.从商业模式来看
在精益创业一书中，我们在描述一个商业模式时，经常需要考虑产品的收入流以及成本结构，即通过投入和产出(ROI)，来分析可行性，同时商业模式也决定了产品的方案的范围。
2.从当前业务场景来看
由于笔者所负责产品主要面向便利店客户，进行美团等平台的O2O业务，即要求3-5公里范围内的即时配送，不涉及商城、跨境等业务。那么在当前的业务下存在三个配送场景：
平台配送：店员拣货后，通知外卖平台已拣货，平台会按照合同约定呼叫骑手配送；商家自送：店员拣货后，店员自行将货物配送到顾客手中；聚合物流：店员拣货后，OMS系统呼叫第三方承运商进行配送。虽然有所差异，但是我们应该认识到本质都是发生在零售商和终端用户之间的交付流程，可以抽象成一个用例，如图所示：
那么方案范围中，需要统一管理这三种业务场景。
3.从“三流”来看
在物流配送过程中，会发生了位置的移动，信息的流动和资金的流动。不同的场景下，物流、资金流、信息流的表现略有不同，如图所示:
当我们对三个流进行管理过程中，也提出了对方案范围的要求：
对信息流管理：通过接口调用，实现配送状态、配送位置、配送员信息等数据在多个系统间的一致性；对物流进行管理：承运商的调度、支持商家自送订单发货、签收等功能、配送范围的划定；对资金流进行管理：上文说到盈利模式，从ROI考虑，我们最终选择了使用功能直接付费的方式进行盈利，即在商家呼叫第三方物流的时候，商家直接与承运商进行结算，不通过4PL系统。故：
在平台呼叫配送的场景下，顾客支付运费直接结算给外卖平台，同时外卖平台收取商家的履约服务费，在订单收入结算给商家时，已进行了扣除；在商家自送的场景下，顾客支付的运费通过外卖平台结算给商家；在商家呼叫第三方物流的情况下，顾客支付运费通过外卖平台结算给商家，商家再和承运商结算。我们可以发现，不同配送场景切换时，需要注意资金数据的变更，以免出现财务对账问题。
五、领域模型的设计
从实际业务来看，一笔订单由于拆单，可能会由多个门店发货，或者由一个门店多次发货，故订单和发货单的关系是一对多的关系。一笔发货单，可能尝试由多个承运商依次发货，故发货单和配送单的关系，也是一对多的关系。
4PL系统中，一个很重要的点，就是当其他承运商异常无法配送时，要使用其他承运商继续配送。为什么配送失败了，要重新搞一个实例，而不是用原来的呢？原因如下：
如第一个承运商长时间无骑手接单，此时4PL系统需要调用接口取消该承运商的配送，重新呼叫其他承运商。但是由于取消配送是异步交互的，需要等待承运商系统返回取消成功的消息，也有可能取消失败，需要重复取消申请，我在任务中心的设计《我对B端任务中心功能的设计思考
人人都是产品经理(woshipm.