中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

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

一、前言

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

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

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

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

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

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

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

三、沒有4PL系統前遇到了什么問題

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

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

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

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

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

四、方案范圍的確定

1. 從商業模式來看

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

2. 從當前業務場景來看

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

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

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

那么方案范圍中，需要統一管理這三種業務場景。

3. 從“三流”來看

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

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

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

故：

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

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

五、領域模型的設計

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

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

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

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

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

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

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

一般來說，配送單的狀態機設計如下：

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

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

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

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

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

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

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

1. 創建承運單時

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

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

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

2. 待下發狀態時

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

3. 已創建狀態時

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

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

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

4. 騎手已分配狀態時

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

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

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

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

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

5. 攬件成功狀態時

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

七、發單時機的邏輯設計

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

八、詳細產品設計

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

1. 調度邏輯說明

2. 保底機制說明

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

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

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

一般有兩種方式：

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

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

九、結語

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

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

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

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

#專欄作家#

Kathic，人人都是產品經理專欄作家。深耕B端多年，致力于OMS\TMS\WMS等供應鏈相關產品設計。“發現、洞見、行動、反思”是我的信條。

本文由 @kathic 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議