聚合物流体系(4PL)处理方案该怎样搭建?这是我的计划思索
编纂导语:一个体系的运作,是由体系的功效加上外部的运营和利用等一系列功效协同构成的,那么该怎样计划一个聚合物流体系(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.com)》也分析白这个情况。
也就是说该配送单无法到已取消的形态,那么假如该配送单直接更新成其他承运商的数据,体系就不便利举行重试取消的利用了,由于没有业务单子承载这个举措了。
从广泛的计划履历来看,也有以下缘故:
- B端日志必要举行具体纪录,一个形态是由于什么产生改动的,什么时分改动的,屡屡是后续举行成绩分析的一手材料,故不克不及掩盖;
- 依照形态可逆准则。形态可逆后,形成的成绩很多,在需求链范畴,一个单子屡屡是线性提高的,而不像OA体系的单子,约莫屡屡是必要反复确认反复调停的;
- 各平台的收钱机制不同:配送单,是OMS体系发货用例的输入物,以及TMS体系的输入物,由于tms体系中,对应输入物还存在,那么高明体系中对应的输入物就应该存在,不然举行财务对账时,则凭据不合错误应。
六、逆向订单形成的配送截停逻辑计划
寻常来说,配送单的形态机计划如下:
那么在配送单创建时,待下达、已创建、已分派骑手等各个形态节点,都有约莫产生主顾的退货哀求。此时我们假如持续召唤配送,就会显现以下成绩。
1)主顾局部退货哀求经过了,但是骑手仍旧将一切的货品都配送到主顾手中。此时:
- 骑手无职责将局部退商品送回门店;
- 主顾不将货品送回,门店选择自行取回本钱较高,招致商品取回后持续售卖取得的利润小于退货取回的本钱;
- 主顾不将货品送回,门店选择向平台申说,申说本钱较高,且该诉求平台寻常不予支持。
那么,伙计只能将货品报损,形成商家丧失。
2)主顾全部退货哀求经过了,但是配送费以前结算给承运商了,形成这笔订单无收入,但是产生了配送用度。如:
- 美团配送:骑手揽件告捷才收钱,揽件后取消配送,不前往用度;
- 达达:骑手揽件告捷才收钱,揽件后取消配送,不前往用度;
- 顺丰同城:发单告捷就收运费,骑手接单后一分钟内取消都返还,一分钟后的会扣2元配送费,剩下的返还;
- 蜂鸟:骑手揽件告捷才收钱,揽件后取消配送,不前往用度。
那么从企业应收的角度来看,我们必需确保货品不超发,同时根绝没效配送费付出,以变小对企业营收的影响。但是在实践计划历程中,我们必要权衡的要素很多。那么我们分场景看一下,不同形态节点截停逻辑的计划权衡。
1. 创建承运单时
反省对否有未处理退单,假如有,则不天生配送单,并经过欺压关照功效关照干系职员处理,见文章《我对B端关照提示功效的计划思索 | 各位都是产物司理 (woshipm.com)》。处理完成后,正常召唤创建承运单。
固然,这个逻辑遭到了业务方很大的挑唆,O2O业务与电商业务不同,履约时效性十分强。那么即时经过欺压关照等强提示的伎俩,要求干系职员及时处理退单,仍旧约莫显现拉长履约时间进而招致客诉的场景显现。
那么有客户就以为:履约时效性高是客户渴望给主顾展现的企业代价取向,这个的代价大于由此带来的丧失。那么关于SaaS来讲,也应该敬重客户的选择,并可以经过设置的办法来完成不同客户的代价诉求,可参考文章《我对B端体系设置功效的计划思索 | 各位都是产物司理 (woshipm.com)》举行设置的计划;
2. 待下发形态时
此时OMS正在实验召唤承运商,主顾哀求退货,此时应将配送取消,等候退单稽核完成后,依据对否必要持续配送,来决定对否对否重新召唤配送。此逻辑仍旧与创建承运单时截停的逻辑一样,被客户以相反的办法挑唆。故也必要举行设置;
3. 已创建形态时
此时在承运商侧下单告捷,主顾哀求退货,但必要区分不同的承运商的政策:
顺丰同城:由于发单告捷就扣减运费,故体系主动回绝主顾退货哀求,或发起伙计手动回绝主顾退货哀求,此时不主动取消配送。假如伙计赞同退货,那么会有两种情况:
- 局部退哀求:持续配送;
- 整单退哀求:OMS调用接口取消配送,运费丧失由商家承当。大局部商户来讲,仍旧希冀可以由伙计接洽用户后,手动确定对否赞同退货,动身点仍旧是企业的代价取向或策划战略,制止不必要的举报和差评,而非一味的制止直接营收丧失。
4. 骑手已分派形态时
此时承运商以前分派骑手,骑手到店取货,主顾哀求退货。
骑手取货的历程,实践是物权移交的历程,OMS体系要在这个机会,实践在ERP体系中扣减库存,增长收入。
这个机会也是最初一次伙计天然会制止货品超发的机会,由于在承运单天生前后产生的退货哀求,伙计都有约莫由于种种缘故,没有处理,假如在骑手取货交代货品这一流程中,假如不查察对否有未处理的退单,就会形成货品的超发大概没效的配送。
电商业务由于履约时效性没有O2O业务时效性这么强,货仓发货作业也愈加严谨,以是通常在出库时是必要货仓职员手工复核的,但是O2O业务,门店发货的场景下,我们有几种办法来应对:
- 推进伙计交代货品时,复核一下对否有未处理的退单,将已退货的商品捡出。这种办法实践增长了伙计的事情量,推行实践是比力困难的。
- 骑手已分派,运费已确认结算给承运商了,此时退单统统主动回绝。局部客户仍旧会由于上文中的缘故挑唆此逻辑。
- 供认这种场景的存在,并且承当相应丧失:即时从逻辑推演来说,这是最差的方案,但是假如思索到其他方案伙计的事情本钱、方案推行本钱,潜伏的被差评的本钱,在退单量较小的情况下,反而是此方案的本钱和丧失是最小的。
5. 揽件告捷形态时
骑手以前正在配送了,体系主动回绝主顾退货哀求,或发起伙计手动回绝主顾退货哀求。与上文一样,要支持不同的客户不同的设置。
七、发单机会的逻辑计划
那么接下去要理清晰的一个成绩,就是在各个配送场景下,什么机会发单给承运商。
八、具体产物计划
接下去我们举行具体的产物计划:
1. 调治逻辑分析
2. 保底机制分析
商家在召唤第三方物流时,总会显现预设的承运商都无法配送的场景,那么就必要一个保底机制,寻常有两种办法:
- 找一个配送质量较好但是收钱高的承运商作为最初一个承运商;
- 体系会默许商家承运商为最初一个承运商,当配送流转到商家承运商时,伙计可自送配送或重新召唤承运商。
3. 第三方承运商召唤机制分析
寻常有两种办法:
- 依照价格由低到高召唤:4PL体系调用各承运商平台预创建订单接口,获取承运商对否可配送以及运费,4PL体系由低到高的召唤承运商。如承运商在预设时间内,仍无骑手接单或承运商直接抛特别,则召唤下一承运商;
- 依据预设排序依次召唤:如创建订单失败、或承运商在预设时间内,仍无骑手接单或承运商直接抛特别,则召唤下一承运商。
4. 最初,我们就可以了解页面上的种种设置功效的作用了
九、结语
繁复及处理方案的计划历程,就是权衡的历程,不存在完善的选择,必要在【第三方——用户可用性易用性——不同客户的代价选择——SaaS的商业选择——SaaS本身的武艺才能】之间坚持均衡,必需多方面的思索ROI,做出逻辑上的权衡。不成制止的,要有很多设置,请看文章《我对B端体系设置功效的计划思索 | 各位都是产物司理 (woshipm.com)》。
别的请读者思索,假如最开头,我们没有将三个不同的配送场景笼同一致同来,而是当作三个不同的用例计划,那么我们会将体系计划成什么样子,我们约莫会增长三个设置页面:当平台配送特别时,我们怎样怎样处理,商家本人配送特别时,体系怎样怎样处理,然后用配送办法字段来区分,平台配送无配送单,其他的有配送单……
但是,我们在体系计划历程中,总是渴望将共同特性的逻辑提炼出来,如此将大大减小用户的认知本钱,同时也利于提高体系的可复用性,假如我们为每一个场景都计划一套逻辑,一套界面,那么用户使用体验是分裂的,界面计划将是冗余的,渴望读者可以了解内里的渺小差别。
本篇文章想表达的很多,但是受限于一局部的才能,以是有些必要具体的场合但是表达的很大略,有些必要简便说说的,又显得长篇大论,渴望各位给出意见和发起,我一定会吸取采取。后续会更新OMS体系的中心逻辑的计划,敬请渴望。
本文由 @kathic 原创公布于各位都是产物司理,未经允许,克制转载
题图来自 Unsplash,基于 CC0 协议

















