一幅圖幫你搞懂訂單的拆分與合并

7 評論 15910 瀏覽 80 收藏 13 分鐘

編輯導語:產品設計往往需要考慮到各個場景,那么如何進行設計才能盡可能的做到“面面俱到”呢?本文作者以訂單的拆分和合并為例,總結了一張圖,為我們談了談他的思考,看看訂單如何實際才能盡可能的做好合理方便。

很多產品方案在落地過程中會更多的結合實際情況考慮,不太可能面面俱到,如果把相關的各個場景都考慮進去的話應該如何設計?如何給產品帶來更強的通用和擴展能力?

下面結合訂單履約過程的拆分與合并談一談個人對其全場景的思考:一方面我發現很多人在考慮這方面時還是不夠全面,另一方面還有很多人在錯誤的理解“訂單拆分”和“訂單合并”。

本文的目的就是通過一幅簡單圖講清楚訂單的拆分與合并。

這里的交易主體指平臺上各個商家,他們都會與消費者發生各種交易行為。

所以,在此通過前臺還是后臺拆單,分為兩大類拆單方式:不同交易主體拆單(前臺拆分訂單)、單一交易主體拆單(后臺拆分發貨單)。

  • 前臺:淘寶、京東、餓了么、美團外賣等前臺銷售平臺;
  • 后臺:支撐前臺的各種系統的統稱,核心拆單部分在倉儲相關環節。

一、不同交易主體的拆單:前臺拆分訂單

消費者與不同的交易主體發生交易時,不同的交易主體生成不同的訂單,每個交易主體都有一個獨立的訂單號。此時,每個訂單都會對應一個發貨單(可以理解為物流單,但不一定是你收到快遞的物流單號),即對應關系為1:1。

不同交易主體拆單時,直接體現在了前臺展現不同的訂單,所以這里稱之為“前臺拆分訂單”;而前臺拆單又分了兩種拆分方式:購物車拆分、提交訂單拆分,本來我用紅色字體寫了“配送方式不一樣,拆分的方式也不一樣”。

但是截止到發稿前,又去體驗了一下美團外賣,發現美團也可以像淘寶一樣提交訂單了,狠狠地打了我的臉,我就把這幾個字置灰了。

1. 購物車拆分

很多人在用餓了么、美團外賣時可能沒有注意過有類似于淘寶、京東多個商家商品列表的購物車,原因就不解釋了。

如果你能找到餓了么、美團外賣的購物車,尤其是餓了么的購物車,會發現每個店都有一個單獨的【去結算】按鈕,而不是像淘寶一樣可以多家店同時結算,那么餓了么這種在購物車就將不同交易主體的商品進行拆分的方式就是“購物車拆分”。

如下圖,左側為餓了么,右側為美團外賣:

2. 提交訂單拆分

以淘寶、京東為代表的電商產品,則可以在購物車里將不同商家的商品同時勾選進行【結算】,在確定訂單頁可以同時【提交訂單】,當提交訂單后,你會發現不同商家的商品會生成不同的訂單,所以在這里稱之為“提交訂單拆分”。

當然,“提交訂單拆分”的拆單方式實際也是經過后臺處理進行拆分的,但是因為對消費者有明顯的不同訂單的感知,所以還是歸在前臺拆分訂單里了。

這里還是要提一下上面提到的美團外賣的更新,大家可以想一下我原來為什么會那樣想,美團為什么會做這樣的更新?為什么餓了么沒有變,以后會不會變?

二、單一交易主體的拆單:后臺拆分發貨單

上面說的是在前臺拆分訂單,現在這里說的是后臺拆分發貨單,也就是消費者在單一商家下單后(或經過前臺拆單后變成了每個獨立交易主體的訂單),拆單實際拆的是發貨單,而不是消費者的實際訂單。

這里有一個誤區,就是好多人在提到拆單和合單時,經常說要把消費者的原單拆開多個,或者多個合并成一個。不得不說,這種方式既麻煩,又容易出錯,而且最關鍵的問題是,你居然會改消費者訂單,對消費者感知如何?

當然你可以說,這是在后臺拆的單,不影響消費者查看,如果你不嫌麻煩,這樣做也是可以的,畢竟條條大路通羅馬,雖然我很不認可這種方式…

咱們先回歸一下這個問題的本質,訂單拆分和合并是要解決什么問題?

是要提升發貨效率和體驗,節約發貨成本,解決的是訂單分開發貨和合并發貨的問題,不是說“訂單拆分”就是要把消費者訂單直接拆了。

如果真的拆了那簡直是一場災難,你還需要考慮各種優惠的拆分,在退貨時要保證所有金額不出錯,簡直太難。

在需要拆單的情況下,一定不要修改消費者訂單,而是根據一定的規則將消費者訂單生成多個發貨單,這樣就有了訂單和發貨單關系為1:N。

啥是1:N?看一張圖你就懂了,下面為我之前下的一個訂單,商家分了多個倉給我發的貨,有多個物流單號(已隱藏):

后臺拆分發貨單規則:

1. 是否多倉發貨

當一個訂單里的商品不能在一個倉庫里發貨時,就要考慮多倉發貨,也就會出現一個訂單有多個發貨單的情況。在拆分時也要按一定的業務規則進行,以下原則僅供參考:

  • 最少包裹原則:能單倉發貨的,盡量不拆;若不能單倉發貨,找拆包裹最少的倉庫組合;
  • 距離最近原則:選擇離收貨地址距離最近的倉庫發貨,若多個倉庫發貨,選擇送達用戶總時長最短的倉庫組合;
  • 成本最優原則:先從采購成本最低的倉庫發貨,再考慮從物流費用最低的倉庫發貨。

2. 是否分批發貨

分批發貨涉及的場景比較多,跟具體的業務場景息息相關,主要涉及以下幾類:

  • 商品庫存:當前部分商品庫存不足,為保證消費者體驗,先部分發貨;
  • 商品品類:某些不能一起發貨的商品,比如實物商品和虛擬商品一起下單,但是虛擬商品無需發貨和簽收;
  • 物流因素:某些商品因為物流方面的限制原因,如商品體積、重量、數量等因素,導致只能分開不同的物流進行發貨;
  • 其他因素:其他導致不能一個發貨單完成發貨的因素,如果這個因素是明確的規則,則可以把該規則做成系統自動拆單的邏輯,如果這個因素不明確,則可以考慮人工拆單。

下圖為盒馬鮮生的確認訂單頁,因商品不同(包裹1和包裹2的拆分可能是由于庫存問題,包裹1和包裹3拆分的原因應該是品類的原因,包裹1需要更精準的配送時間,包裹3則不需要),在下單時直接告知消費者會分多單配送:

3. 是否需要人工拆單

當系統自動拆單規則不完善時,一般都需保留人工拆單的方式,在訂單審核時將一部分商品先發貨。

三、拆單發貨總結

通過前臺拆單和后臺拆單的規則可以發現,前臺拆單規則明確,表現形式只有兩種:購物車拆分、提交訂單拆分。而在后臺拆單時,更多的結合實際場景,各種規則并不明確,可見后臺拆單邏輯更復雜。

一般來說,單一商家的發貨場景比較單一,一般不需要考慮設計的太復雜,可能不需要后臺拆單就能解決問題(即使只有一個交易主體,也可通過前臺拆單方式解決)。

而作為能夠提供倉儲物流服務的平臺方,則需要考慮更多,成本、時效、體驗都需要考慮。

四、訂單合并發貨

訂單合并發貨相對來說就簡單的多,但是也要強調一下,訂單合并并不是將兩個消費者訂單合并,而是將兩個訂單的商品合并到一個發貨單里發貨。

合并發貨原理:將滿足條件的訂單(買家ID、收貨人姓名、電話、地址信息都一樣)合并到一個發貨單里發貨,訂單與發貨單對應關系N:1。

下圖為我雙11在一家店里先后下的兩個單,查看物流信息時,都是同一個物流單號:

不能為了節省成本隨便合并發貨,要確保消費者及其收貨信息完全一致才能合并發貨(不同的業務場景可能要求也不一樣),而且訂單要滿足一定的條件。

比如我雙11下了兩單,一單下的比較早都要裝車發貨了,另一單才下,這種情況下肯定不能合并發貨。

所以在合并發貨時,可以控制某個時間段內下的單,在滿足合并發貨條件時,自動將其生成一個發貨單,也可以手工合并訂單進行發貨。

五、訂單拆分與合并的核心邏輯

訂單都有對應的發貨單,訂單是用來給消費者查看、交易結算的,發貨單是處理庫存、發貨用的,拆分與合并的關鍵邏輯是這兩個實體對應關系的變化:

  • 不同交易主體拆單:訂單與發貨單關系1:1(一個訂單有一個發貨單,這里說的只是前臺拆,到了后臺如果再拆單的話,也會變成1:N)
  • 單一交易主體拆單:訂單與發貨單關系1:N(一個訂單有多個發貨單)
  • 訂單合并發貨:訂單與發貨單關系N:1(多個訂單使用一個發貨單)

作為產品經理千萬不可望文生義,而要追本溯源,“訂單拆分與合并”并不是把消費者訂單拆了或者合并了,就好像“中臺”說的并不是放在前后臺之間。

 

本文由 @Zurl 原創發布于人人都是產品經理,未經允許,禁止轉載

題圖來自Unsplash,基于CC0協議。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 一個客戶的訂單(A物料2個,B物料50個),可能因為發貨倉庫(A-a,B-b)、數量的原因,被拆分為3個子單(A-2,B-20,B-30),生成了3個運單。
    在發貨時間前,這個客戶又下了一個訂單(A物料18個),由于時間地址范圍合理,于是合單
    最終運單對應的訂單信息為:運單1對應訂單1-P1+訂單2,運單2對應訂單1-P2,運單3對應訂單1-P3

    來自浙江 回復
  2. 可以講一下拆單的多種場景嗎

    來自廣東 回復
  3. 棒棒,拆單的部分講的很清楚,確實應該分場景說明拆單。

    來自浙江 回復
  4. 根據一定的規則將消費者訂單生成多個發貨單,這樣就有了訂單和發貨單關系為1:N。
    這樣只會導致系統更復雜,部分包裹簽收、部分拒簽

    來自浙江 回復
    1. 棒棒,拆單的部分講的很清楚,確實應該分場景說明拆單。

      來自浙江 回復
  5. 有個問題請教。多單合并時訂單和發貨單是N:1,如果多單生成多個包裹,但是只有一張發貨單,那如何確認單個包裹的具體商品呢

    來自浙江 回復
    1. 已經把多個訂單的商品打包到一個包裹里了,這個包裹里的發貨清單就是包含多個訂單的商品列表

      來自廣東 回復