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

一、前言

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

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

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

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

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

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

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

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

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

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

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

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

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

四、方案范圍的確定

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

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

2. 從當前業(yè)務場景來看

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

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

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

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

3. 從“三流”來看

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

當我們對三個流進行管理過程中，也提出了對方案范圍的要求：

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

故：

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

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

五、領域模型的設計

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

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

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

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

從普遍的設計經驗來看，也有以下原因：

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

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

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

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

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

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

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

2）顧客全部退貨申請通過了，但是配送費已經結算給承運商了，造成這筆訂單無收入，但是產生了配送費用。如：

1. 美團配送：騎手攬件成功才收費，攬件后取消配送，不返回費用；
2. 達達：騎手攬件成功才收費，攬件后取消配送，不返回費用；
3. 順豐同城：發(fā)單成功就收運費，騎手接單后一分鐘內取消都返還，一分鐘后的會扣2元配送費，剩下的返還；
4. 蜂鳥：騎手攬件成功才收費，攬件后取消配送，不返回費用。

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

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

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

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

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

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

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

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

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

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

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

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

此時承運商已經分配騎手，騎手到店取貨，顧客申請退貨。

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

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

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

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

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

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

七、發(fā)單時機的邏輯設計

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

八、詳細產品設計

接下來我們進行詳細的產品設計：

1. 調度邏輯說明

2. 保底機制說明

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

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

3. 第三方承運商呼叫機制說明

一般有兩種方式：

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

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

九、結語

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

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

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

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

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

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