編輯導語：一個系統的運作，是由系統的功能加上外部的運營和操作等一系列功能共同組成的，那麼該如何設計一個聚合物流系統（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 協議