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

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

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

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

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

所以，在此通過前台還是後台拆單，分為兩大類拆單方式：不同交易主體拆單（前台拆分訂單）、單一交易主體拆單（後台拆分發貨單）。

• 前台：淘寶、京東、餓了麼、美團外賣等前台銷售平台；
• 後台：支撐前台的各種系統的統稱，核心拆單部分在倉儲相關環節。

一、不同交易主體的拆單：前台拆分訂單

消費者與不同的交易主體發生交易時，不同的交易主體生成不同的訂單，每個交易主體都有一個獨立的訂單号。此時，每個訂單都會對應一個發貨單（可以理解為物流單，但不一定是你收到快遞的物流單号），即對應關系為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協議。

,