編輯導(dǎo)語：一個系統(tǒng)的運(yùn)作，是由系統(tǒng)的功能加上外部的運(yùn)營和操作等一系列功能共同組成的，那么該如何設(shè)計一個聚合物流系統(tǒng)（4PL）呢？本文作者通過這篇文章與我們分享了他的解決方案和設(shè)計思考，一起來看看吧。

一、前言

從這篇文章開始，我給大家介紹一些OMS系統(tǒng)中具體方案的設(shè)計思考。

我一直喜歡用解決方案的設(shè)計替代功能設(shè)計的說法，俞軍老師曾經(jīng)在《產(chǎn)品方法論》中說過：系統(tǒng)內(nèi)的設(shè)計是為了推動、限制系統(tǒng)外的動作，但是系統(tǒng)外的動作并不全由系統(tǒng)內(nèi)的設(shè)計進(jìn)行驅(qū)動和限制。故一個系統(tǒng)運(yùn)行時，實(shí)際是系統(tǒng)的功能 系統(tǒng)外的運(yùn)營動作、規(guī)章制度、操作規(guī)范功能共同作用的。

那么聚合物流系統(tǒng)的解決方案應(yīng)該如何設(shè)計呢，系統(tǒng)內(nèi)系統(tǒng)外各動作又是怎么影響最終的解決方案的呢。

二、自營物流、承運(yùn)商、聚合物流（4PL）的概念解析

在開始正式設(shè)計之前，需要分清物流配送系統(tǒng)是做什么的，以及幾種物流方式。在供應(yīng)鏈系統(tǒng)模型（SCOR）中，配送屬于在五大流程中的【交付】流程，一般發(fā)生在分銷商和零售商以及零售商和終端用戶之間，但OMS系統(tǒng)中僅涉及到零售商和終端用戶間的交付。

同時，我喜歡的一位作者“木筆老師”曾經(jīng)在《實(shí)戰(zhàn)供應(yīng)鏈》一書中闡述了不同的物流方式的區(qū)別：

1. 自營物流：商家自己搭建的配送提醒，使用自己的配送車輛和配送員送貨上門，如京東等大型電商；
2. 第三方物流：借助市面上已經(jīng)成熟的物流體系進(jìn)行配送，如三通一達(dá)，如美團(tuán)配送、達(dá)達(dá)配送、蜂鳥配送等；
3. 聚合物流或叫第四方物流（4PL）：將多方配送資源進(jìn)行整合，提供整體解決方案的第四方，第四方在整個供應(yīng)鏈中承擔(dān)平臺信息發(fā)布、信息匹配和撮合、物流資源繼承，物流解決方案等角色，能夠?yàn)樯碳姨峁┡渌头绞降淖顑?yōu)解，往往會按照一定的策略，呼叫價格最低或依次呼叫配置的承運(yùn)商以達(dá)到配送的目的。目前針對于O2O業(yè)務(wù)，國內(nèi)開展相關(guān)業(yè)務(wù)的公司有麥芽田、餐道等。聚合物流的實(shí)現(xiàn)，依賴于第三方物流開放接口能力，目前主流的承運(yùn)商，都開放了接口能力。

三、沒有4PL系統(tǒng)前遇到了什么問題

回歸到筆者面臨的具體業(yè)務(wù)場景上來，我們遇到了什么痛點(diǎn)，要求我們提供4PL的能力呢：

第一：平臺履約服務(wù)費(fèi)造成毛利率進(jìn)一步降低：以美團(tuán)、餓了么為例，商家可以選擇和平臺簽約配送合同，訂單由平臺呼叫對應(yīng)的美團(tuán)配送和蜂鳥配送，平臺要額外收取履約服務(wù)費(fèi)，一般2-6元不等，進(jìn)一步降低了毛利。

第二：平臺呼叫配送或自營物流在極端天氣或節(jié)假日時，均可能會出現(xiàn)長時間無騎手接單或其他無法配送的情況，造成無效訂單，進(jìn)一步影響商家經(jīng)營情況。

第三：自建物流成本較高，部分中小商家無力承擔(dān)，但是使用平臺的第三方物流時，又只能獲取標(biāo)準(zhǔn)的配送服務(wù)，對于冷鏈等特殊配送要求適配性不足。

那么由于單一的自營物流或第三方物流，已經(jīng)無法滿足部分商家的訴求了，那么此時聚合物流系統(tǒng)（4PL）應(yīng)運(yùn)而生。

四、方案范圍的確定

1. 從商業(yè)模式來看

在精益創(chuàng)業(yè)一書中，我們在描述一個商業(yè)模式時，經(jīng)常需要考慮產(chǎn)品的收入流以及成本結(jié)構(gòu)，即通過投入和產(chǎn)出(ROI)，來分析可行性，同時商業(yè)模式也決定了產(chǎn)品的方案的范圍。

2. 從當(dāng)前業(yè)務(wù)場景來看

由于筆者所負(fù)責(zé)產(chǎn)品主要面向便利店客戶，進(jìn)行美團(tuán)等平臺的O2O業(yè)務(wù)，即要求3-5公里范圍內(nèi)的即時配送，不涉及商城、跨境等業(yè)務(wù)。那么在當(dāng)前的業(yè)務(wù)下存在三個配送場景：

1. 平臺配送：店員揀貨后，通知外賣平臺已揀貨，平臺會按照合同約定呼叫騎手配送；
2. 商家自送：店員揀貨后，店員自行將貨物配送到顧客手中；
3. 聚合物流：店員揀貨后，OMS系統(tǒng)呼叫第三方承運(yùn)商進(jìn)行配送。

雖然有所差異，但是我們應(yīng)該認(rèn)識到本質(zhì)都是發(fā)生在零售商和終端用戶之間的交付流程，可以抽象成一個用例，如圖所示：

那么方案范圍中，需要統(tǒng)一管理這三種業(yè)務(wù)場景。

3. 從“三流”來看

在物流配送過程中，會發(fā)生了位置的移動，信息的流動和資金的流動。不同的場景下，物流、資金流、信息流的表現(xiàn)略有不同，如圖所示:

當(dāng)我們對三個流進(jìn)行管理過程中，也提出了對方案范圍的要求：

1. 對信息流管理：通過接口調(diào)用，實(shí)現(xiàn)配送狀態(tài)、配送位置、配送員信息等數(shù)據(jù)在多個系統(tǒng)間的一致性；
2. 對物流進(jìn)行管理：承運(yùn)商的調(diào)度、支持商家自送訂單發(fā)貨、簽收等功能、配送范圍的劃定；
3. 對資金流進(jìn)行管理：上文說到盈利模式，從ROI考慮，我們最終選擇了使用功能直接付費(fèi)的方式進(jìn)行盈利，即在商家呼叫第三方物流的時候，商家直接與承運(yùn)商進(jìn)行結(jié)算，不通過4PL系統(tǒng)。

故：

1. 在平臺呼叫配送的場景下，顧客支付運(yùn)費(fèi)直接結(jié)算給外賣平臺，同時外賣平臺收取商家的履約服務(wù)費(fèi)，在訂單收入結(jié)算給商家時，已進(jìn)行了扣除；
2. 在商家自送的場景下，顧客支付的運(yùn)費(fèi)通過外賣平臺結(jié)算給商家；
3. 在商家呼叫第三方物流的情況下，顧客支付運(yùn)費(fèi)通過外賣平臺結(jié)算給商家，商家再和承運(yùn)商結(jié)算。

我們可以發(fā)現(xiàn)，不同配送場景切換時，需要注意資金數(shù)據(jù)的變更，以免出現(xiàn)財務(wù)對賬問題。

五、領(lǐng)域模型的設(shè)計

從實(shí)際業(yè)務(wù)來看，一筆訂單由于拆單，可能會由多個門店發(fā)貨，或者由一個門店多次發(fā)貨，故訂單和發(fā)貨單的關(guān)系是一對多的關(guān)系。一筆發(fā)貨單，可能嘗試由多個承運(yùn)商依次發(fā)貨，故發(fā)貨單和配送單的關(guān)系，也是一對多的關(guān)系。

4PL系統(tǒng)中，一個很重要的點(diǎn)，就是當(dāng)其他承運(yùn)商異常無法配送時，要使用其他承運(yùn)商繼續(xù)配送。為什么配送失敗了，要重新搞一個實(shí)例，而不是用原來的呢？原因如下：

如第一個承運(yùn)商長時間無騎手接單，此時4PL系統(tǒng)需要調(diào)用接口取消該承運(yùn)商的配送，重新呼叫其他承運(yùn)商。但是由于取消配送是異步交互的，需要等待承運(yùn)商系統(tǒng)返回取消成功的消息，也有可能取消失敗，需要重復(fù)取消申請，我在任務(wù)中心的設(shè)計《我對B端任務(wù)中心功能的設(shè)計思考 | 人人都是產(chǎn)品經(jīng)理 (woshipm.com)》也說明了這個情況。

也就是說該配送單無法到已取消的狀態(tài)，那么如果該配送單直接更新成其他承運(yùn)商的數(shù)據(jù)，系統(tǒng)就不方便進(jìn)行重試取消的操作了，因?yàn)闆]有業(yè)務(wù)單據(jù)承載這個動作了。

從普遍的設(shè)計經(jīng)驗(yàn)來看，也有以下原因：

1. B端日志需要進(jìn)行詳細(xì)記錄，一個狀態(tài)是因?yàn)槭裁窗l(fā)生改變的，什么時候改變的，往往是后續(xù)進(jìn)行問題分析的一手資料，故不能覆蓋；
2. 遵循狀態(tài)可逆原則。狀態(tài)可逆后，造成的問題很多，在供應(yīng)鏈領(lǐng)域，一個單據(jù)往往是線性發(fā)展的，而不像OA系統(tǒng)的單據(jù)，可能往往是需要反復(fù)確認(rèn)反復(fù)調(diào)整的；
3. 各平臺的收費(fèi)機(jī)制不同：配送單，是OMS系統(tǒng)發(fā)貨用例的輸出物，以及TMS系統(tǒng)的輸入物，由于tms系統(tǒng)中，對應(yīng)輸入物還存在，那么上游系統(tǒng)中對應(yīng)的輸出物就應(yīng)該存在，否則進(jìn)行財務(wù)對賬時，則憑證不對應(yīng)。

六、逆向訂單造成的配送截停邏輯設(shè)計

一般來說，配送單的狀態(tài)機(jī)設(shè)計如下：

那么在配送單創(chuàng)建時，待下達(dá)、已創(chuàng)建、已分配騎手等各個狀態(tài)節(jié)點(diǎn)，都有可能發(fā)生顧客的退貨申請。此時我們?nèi)绻^續(xù)呼叫配送，就會出現(xiàn)以下問題。

1）顧客部分退貨申請通過了，但是騎手仍然將所有的貨物都配送到顧客手中。此時：

1. 騎手無義務(wù)將部分退商品送回門店；
2. 顧客不將貨物送回，門店選擇自行取回成本較高，導(dǎo)致商品取回后繼續(xù)售賣獲得的利潤小于退貨取回的成本；
3. 顧客不將貨物送回，門店選擇向平臺申訴，申訴成本較高，且該訴求平臺一般不予支持。

那么，店員只能將貨物報損，造成商家損失。

2）顧客全部退貨申請通過了，但是配送費(fèi)已經(jīng)結(jié)算給承運(yùn)商了，造成這筆訂單無收入，但是產(chǎn)生了配送費(fèi)用。如：

1. 美團(tuán)配送：騎手?jǐn)埣晒Σ攀召M(fèi)，攬件后取消配送，不返回費(fèi)用；
2. 達(dá)達(dá)：騎手?jǐn)埣晒Σ攀召M(fèi)，攬件后取消配送，不返回費(fèi)用；
3. 順豐同城：發(fā)單成功就收運(yùn)費(fèi)，騎手接單后一分鐘內(nèi)取消都返還，一分鐘后的會扣2元配送費(fèi)，剩下的返還；
4. 蜂鳥：騎手?jǐn)埣晒Σ攀召M(fèi)，攬件后取消配送，不返回費(fèi)用。

那么從企業(yè)應(yīng)收的角度來看，我們必須保證貨物不超發(fā)，同時杜絕無效配送費(fèi)支出，以減少對企業(yè)營收的影響。但是在實(shí)際設(shè)計過程中，我們需要權(quán)衡的因素很多。那么我們分場景看一下，不同狀態(tài)節(jié)點(diǎn)截停邏輯的設(shè)計權(quán)衡。

1. 創(chuàng)建承運(yùn)單時

檢查是否有未處理退單，如果有，則不生成配送單，并通過強(qiáng)制通知功能通知相關(guān)人員處理，見文章《我對B端通知提醒功能的設(shè)計思考 | 人人都是產(chǎn)品經(jīng)理 (woshipm.com)》。處理完成后，正常呼叫創(chuàng)建承運(yùn)單。

當(dāng)然，這個邏輯受到了業(yè)務(wù)方很大的挑戰(zhàn)，O2O業(yè)務(wù)與電商業(yè)務(wù)不同，履約時效性非常強(qiáng)。那么即時通過強(qiáng)制通知等強(qiáng)提醒的手段，要求相關(guān)人員及時處理退單，仍然可能出現(xiàn)拉長履約時間進(jìn)而導(dǎo)致客訴的場景出現(xiàn)。

那么有客戶就認(rèn)為：履約時效性高是客戶希望給顧客展示的企業(yè)價值取向，這個的價值大于由此帶來的損失。那么對于SaaS來講，也應(yīng)該尊重客戶的選擇，并可以通過配置的方法來實(shí)現(xiàn)不同客戶的價值訴求，可參考文章《我對B端系統(tǒng)配置功能的設(shè)計思考 | 人人都是產(chǎn)品經(jīng)理 (woshipm.com)》進(jìn)行配置的設(shè)計；

2. 待下發(fā)狀態(tài)時

此時OMS正在嘗試呼叫承運(yùn)商，顧客申請退貨，此時應(yīng)將配送取消，等待退單審核完成后，根據(jù)是否需要繼續(xù)配送，來決定是否是否重新呼叫配送。此邏輯仍然與創(chuàng)建承運(yùn)單時截停的邏輯一樣，被客戶以相同的方式挑戰(zhàn)。故也需要進(jìn)行配置；

3. 已創(chuàng)建狀態(tài)時

此時在承運(yùn)商側(cè)下單成功，顧客申請退貨，但需要區(qū)分不同的承運(yùn)商的政策：

順豐同城：由于發(fā)單成功就扣減運(yùn)費(fèi)，故系統(tǒng)自動拒絕顧客退貨申請，或建議店員手動拒絕顧客退貨申請，此時不自動取消配送。如果店員同意退貨，那么會有兩種情況：

1. 部分退申請：繼續(xù)配送；
2. 整單退申請：OMS調(diào)用接口取消配送，運(yùn)費(fèi)損失由商家承擔(dān)。大部分商戶來講，仍然期望可以由店員聯(lián)系用戶后，手動確定是否同意退貨，出發(fā)點(diǎn)仍然是企業(yè)的價值取向或經(jīng)營策略，避免不必要的投訴和差評，而非一味的避免直接營收損失。

4. 騎手已分配狀態(tài)時

此時承運(yùn)商已經(jīng)分配騎手，騎手到店取貨，顧客申請退貨。

騎手取貨的過程，實(shí)際是物權(quán)移交的過程，OMS系統(tǒng)要在這個時機(jī)，實(shí)際在ERP系統(tǒng)中扣減庫存，增加收入。

這個時機(jī)也是最后一次店員有機(jī)會避免貨物超發(fā)的時機(jī)，因?yàn)樵诔羞\(yùn)單生成前后發(fā)生的退貨申請，店員都有可能由于種種原因，沒有處理，如果在騎手取貨交接貨物這一流程中，如果不查看是否有未處理的退單，就會造成貨物的超發(fā)或者無效的配送。

電商業(yè)務(wù)由于履約時效性沒有O2O業(yè)務(wù)時效性這么強(qiáng)，倉庫發(fā)貨作業(yè)也更加嚴(yán)謹(jǐn)，所以通常在出庫時是需要倉庫人員手工復(fù)核的，但是O2O業(yè)務(wù)，門店發(fā)貨的場景下，我們有幾種方式來應(yīng)對：

1. 推進(jìn)店員交接貨物時，復(fù)核一下是否有未處理的退單，將已退貨的商品撿出。這種方式實(shí)際增加了店員的工作量，推行實(shí)際是比較困難的。
2. 騎手已分配，運(yùn)費(fèi)已確認(rèn)結(jié)算給承運(yùn)商了，此時退單統(tǒng)統(tǒng)自動拒絕。部分客戶仍然會因?yàn)樯衔闹械脑蛱魬?zhàn)此邏輯。
3. 承認(rèn)這種場景的存在，并且承擔(dān)相應(yīng)損失：即時從邏輯推演來說，這是最差的方案，但是如果考慮到其他方案店員的工作成本、方案推行成本，潛在的被差評的成本，在退單量較小的情況下，反而是此方案的成本和損失是最小的。

5. 攬件成功狀態(tài)時

騎手已經(jīng)正在配送了，系統(tǒng)自動拒絕顧客退貨申請，或建議店員手動拒絕顧客退貨申請。與上文一樣，要支持不同的客戶不同的配置。

七、發(fā)單時機(jī)的邏輯設(shè)計

那么接下來要理清楚的一個問題，就是在各個配送場景下，什么時機(jī)發(fā)單給承運(yùn)商。

八、詳細(xì)產(chǎn)品設(shè)計

接下來我們進(jìn)行詳細(xì)的產(chǎn)品設(shè)計：

1. 調(diào)度邏輯說明

2. 保底機(jī)制說明

商家在呼叫第三方物流時，總會出現(xiàn)預(yù)設(shè)的承運(yùn)商都無法配送的場景，那么就需要一個保底機(jī)制，一般有兩種方法：

1. 找一個配送質(zhì)量較好但是收費(fèi)高的承運(yùn)商作為最后一個承運(yùn)商；
2. 系統(tǒng)會默認(rèn)商家承運(yùn)商為最后一個承運(yùn)商，當(dāng)配送流轉(zhuǎn)到商家承運(yùn)商時，店員可自送配送或重新呼叫承運(yùn)商。

3. 第三方承運(yùn)商呼叫機(jī)制說明

一般有兩種方式：

1. 按照價格由低到高呼叫：4PL系統(tǒng)調(diào)用各承運(yùn)商平臺預(yù)創(chuàng)建訂單接口，獲取承運(yùn)商是否可配送以及運(yùn)費(fèi)，4PL系統(tǒng)由低到高的呼叫承運(yùn)商。如承運(yùn)商在預(yù)設(shè)時間內(nèi)，仍無騎手接單或承運(yùn)商直接拋異常，則呼叫下一承運(yùn)商；
2. 根據(jù)預(yù)設(shè)順序依次呼叫：如創(chuàng)建訂單失敗、或承運(yùn)商在預(yù)設(shè)時間內(nèi)，仍無騎手接單或承運(yùn)商直接拋異常，則呼叫下一承運(yùn)商。

4. 最后，我們就可以理解頁面上的各種設(shè)置功能的作用了

九、結(jié)語

復(fù)雜及解決方案的設(shè)計過程，就是權(quán)衡的過程，不存在完美的選擇，需要在【第三方——用戶可用性易用性——不同客戶的價值選擇——SaaS的商業(yè)選擇——SaaS本身的技術(shù)能力】之間保持平衡，必須多方面的考慮ROI，做出邏輯上的取舍。不可避免的，要有很多配置，請看文章《我對B端系統(tǒng)配置功能的設(shè)計思考 | 人人都是產(chǎn)品經(jīng)理 (woshipm.com)》。

另外請讀者思考，如果最開始，我們沒有將三個不同的配送場景抽象統(tǒng)一起來，而是當(dāng)作三個不同的用例設(shè)計，那么我們會將系統(tǒng)設(shè)計成什么樣子，我們可能會增加三個配置頁面：當(dāng)平臺配送異常時，我們?nèi)绾稳绾翁幚?，商家自己配送異常時，系統(tǒng)如何如何處理，然后用配送方式字段來區(qū)分，平臺配送無配送單，其他的有配送單……

但是，我們在系統(tǒng)設(shè)計過程中，總是希望將共性的邏輯提煉出來，這樣將大大減輕用戶的認(rèn)知成本，同時也利于提高系統(tǒng)的可復(fù)用性，如果我們?yōu)槊恳粋€場景都設(shè)計一套邏輯，一套界面，那么用戶使用體驗(yàn)是割裂的，界面設(shè)計將是冗余的，希望讀者可以理解里面的細(xì)微差異。

本篇文章想表達(dá)的很多，但是受限于個人的能力，所以有些需要詳細(xì)的地方但是表達(dá)的很粗略，有些需要簡單說說的，又顯得長篇大論，希望大家給出意見和建議，我一定會吸取采納。后續(xù)會更新OMS系統(tǒng)的核心邏輯的設(shè)計，敬請期待。

本文由 @kathic 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自 Unsplash，基于 CC0 協(xié)議