在跨境電商業(yè)務(wù)場(chǎng)景下，訂單的產(chǎn)生是常見的環(huán)節(jié)之一，那么在這一場(chǎng)景下，訂單模塊該如何搭建相應(yīng)的設(shè)計(jì)策略？過程中又有哪些細(xì)節(jié)事項(xiàng)需要注意？一起來看看作者的分析和解答。

一旦發(fā)生交易，就會(huì)產(chǎn)生訂單。在所有涉及到訂單的系統(tǒng)中，訂單模塊往往是最核心的部分。本文以跨境電商為業(yè)務(wù)背景，講解一下訂單模塊的產(chǎn)品設(shè)計(jì)。

一、訂單下載

對(duì)于跨境賣家而言，對(duì)于訂單下載肯定不陌生，也就是常說的“抓單”，將第三方平臺(tái)的訂單同步到自己系統(tǒng)。抓單需要考慮2個(gè)問題。

(資料圖)

訂單有未付款、已付款、已發(fā)貨、簽收、退款等等狀態(tài)。以海運(yùn)為例，如果是直發(fā)，走海運(yùn)從國(guó)內(nèi)發(fā)貨到美國(guó)簽收，可能需要40-50天。這樣就意味著訂單狀態(tài)從發(fā)貨到簽收，也需要40-50天。假設(shè)公司每天到美國(guó)有5W單，那么到了50天后就會(huì)有250萬單，為了同步狀態(tài)，難道每天去遍歷幾百萬條數(shù)據(jù)？

所以有一種處理方式就是只會(huì)同步幾個(gè)狀態(tài)，最常見就是同步未付款、已付款、已發(fā)貨3個(gè)狀態(tài)。只要發(fā)貨，在賣家端的操作就已經(jīng)完結(jié)了。后續(xù)客戶的售后操作，就會(huì)形成新的售后訂單，按照依舊按照上述邏輯去同步狀態(tài)。

二、訂單預(yù)占

成功抓單后，訂單就預(yù)占中央庫存的庫存。

中央庫存不是一個(gè)系統(tǒng)，甚至頁面都沒有。理解理解中央庫存是一個(gè)調(diào)度模塊。抓單后，訂單通過調(diào)度系統(tǒng)指派那個(gè)倉(cāng)庫發(fā)貨出庫。

最簡(jiǎn)單的中央庫存模型就是公司有N個(gè)倉(cāng)庫，這N各倉(cāng)庫的庫存統(tǒng)一起來就是一個(gè)中央庫存。此時(shí)對(duì)中央庫存的預(yù)占只是增加了中央庫存的鎖定層，倉(cāng)庫的實(shí)物層并沒有受影響。

三、拆合單策略

合單的本質(zhì)就是為了減少履約成本，最直觀的就是體現(xiàn)在運(yùn)費(fèi)上。用戶下了3個(gè)訂單，公司一次性給用戶發(fā)了，就節(jié)省了2次的運(yùn)費(fèi)。

最常見的合單規(guī)則就是同一個(gè)客戶，在同一個(gè)店鋪，收貨地址相同的訂單合并。

按理來說不同的店鋪的訂單應(yīng)該也可以合并。因?yàn)榈谌狡脚_(tái)有防關(guān)聯(lián)政策，如果一個(gè)賣家注冊(cè)多個(gè)賬號(hào)在平臺(tái)賣貨。系統(tǒng)檢測(cè)到的話就會(huì)封號(hào)，所以合單一般都不回跨店鋪。

訂單的合并條件還有更多，如下圖所示：

合單功能比較簡(jiǎn)單，重點(diǎn)是合單后的處理。

如果2個(gè)訂單合單了，且2個(gè)訂單已經(jīng)匹配了倉(cāng)庫，合并后根據(jù)“就近就全”原則，是否需要重新匹配倉(cāng)庫？

如果2個(gè)訂單手動(dòng)合單了，且2個(gè)訂單已經(jīng)匹配了物流，合單后是否需要根據(jù)“匹配物流”策略，重新匹配物流？

上面說了合并是為了減少履約成本，拆單就是增加了履約成本，那么為什么還需要拆單呢？因?yàn)樵趯?shí)際的工作場(chǎng)景中有很多不得不拆單的情況。常見的拆單策略有：

拆分的訂單也需要考慮是否需要重新尋倉(cāng)和匹配物流。

一些人搞不懂ERP拆單和倉(cāng)庫拆包之間的關(guān)系，拆單可以理解為將銷售單拆分成N個(gè)，拆包理解為將銷售單拆分為多個(gè)包裹（包括也可以理解為運(yùn)單）。

小結(jié)：

訂單的拆單和合單需要考慮訂單的成本、銷售額、優(yōu)惠等金額的計(jì)算，還需要考慮贈(zèng)品。這一塊的計(jì)算規(guī)則稍微復(fù)雜一點(diǎn)，我放在營(yíng)銷模塊去講。

需要注意的是自動(dòng)拆單合單策略需要放在尋倉(cāng)、分配物流這些策略前面，因?yàn)椴饐魏秃蠁涡枰匦聦}(cāng)和分配物流。

四、尋倉(cāng)

尋倉(cāng)就是系統(tǒng)找到最合適的倉(cāng)庫，所以尋倉(cāng)的核心邏輯就一句話：“就近就全”原則。

找到距離用戶最近的倉(cāng)庫，且倉(cāng)庫當(dāng)前的可用庫存可以滿足訂單。這里就引申了一個(gè)問題，尋倉(cāng)，尋哪些倉(cāng)庫？比如用戶的收貨地址是美國(guó)，尋歐洲的倉(cāng)顯然就不合理，所以尋哪些倉(cāng)庫也就需要根據(jù)用戶的收貨地址做配置。

如果公司有成品倉(cāng)庫和半成品倉(cāng)庫，用戶下單購(gòu)買了半成品，那么尋成品倉(cāng)顯然不合理，所以尋倉(cāng)也需要根據(jù)用戶中商品的屬性進(jìn)行配置。

結(jié)合以上的描述，那么我們可以把尋倉(cāng)功能做成策略，進(jìn)行配置，如下圖所示（僅供參考）：

看到一個(gè)友商的產(chǎn)品設(shè)計(jì)，非常類似，就截圖過來了。從上圖可以看出，首先配置一些“滿足條件”，這些條件有收獲地址，貨品分類等等，滿足條件后去執(zhí)行指定的倉(cāng)庫，倉(cāng)庫可以配置多個(gè)。

“就全”怎么理解呢？就是一個(gè)訂單盡量由一個(gè)倉(cāng)庫發(fā)貨，避免多個(gè)倉(cāng)庫發(fā)貨吧訂單拆分成多個(gè)包裹。試想一下用戶下單，結(jié)果一個(gè)訂單收到了5-8個(gè)包裹，體驗(yàn)非常不好，而且公司要付出的運(yùn)費(fèi)也高。

但是這里有一種特殊情況，舉個(gè)栗子說明。如：用戶下單，收貨地址為深圳，系統(tǒng)檢索了整個(gè)華南地區(qū)的倉(cāng)庫，沒有一個(gè)倉(cāng)庫可以完全滿足。但是在西藏的一個(gè)倉(cāng)庫可以滿足訂單，那么此時(shí)應(yīng)該是華南地區(qū)的多個(gè)倉(cāng)庫

那么是在華南地區(qū)拆分成多個(gè)包裹發(fā)貨，還是在西藏發(fā)貨，這個(gè)就要看公司策略了。

五、倉(cāng)庫預(yù)占

當(dāng)尋倉(cāng)完成之后，就預(yù)占倉(cāng)庫的庫存，將中央庫存預(yù)占的庫存下推給倉(cāng)庫，邏輯如下圖所示：

六、分配物流

分配物流就是給訂單匹配一個(gè)發(fā)貨方式用于發(fā)貨，分配物流的核心邏輯與尋倉(cāng)一致，也是一個(gè)句話：“選擇滿足發(fā)貨方式中最便宜的物流”。

作為跨境賣家，通常會(huì)對(duì)接很多物流公司。作為賣家出于節(jié)省成本的考慮，肯定會(huì)選擇滿足訂單履約，且最便宜的物流。

具體的物流模塊的產(chǎn)品設(shè)計(jì)我就不贅述了，內(nèi)容太多。感興趣可以去看我之前寫的文章《ERP-物流模塊設(shè)計(jì)》。

七、訂單審核

訂單審核的頁面如下（僅供參考）：

審單就是人工在對(duì)訂單進(jìn)行確認(rèn)，因?yàn)樵趯?shí)際的工作情況中有非常多的特殊情況，如：用戶修改地址，用戶的一些特殊備注等等。

在審核頁面也可以手動(dòng)對(duì)訂單進(jìn)行拆分、合單、改物流、改備注等操作。

在審核通過之后，訂單就會(huì)下推到WMS系統(tǒng)，倉(cāng)庫進(jìn)行揀貨出庫。但是在根據(jù)不同的業(yè)務(wù)發(fā)貨方式也不同，常見的有3種發(fā)貨方式，如下：

竟然有審核操作，那么也有審單策略。如果每天5W單，審單就2個(gè)人，那么每天的工作怎么做都做不完。所以就需要做一個(gè)自動(dòng)審單的策略，將一些常規(guī)的訂單自動(dòng)審核通過，一些不常規(guī)的訂單攔截由人工審核。

自動(dòng)審單策略的界面如下（僅供參考）：

八、自動(dòng)攔截策略

設(shè)置一些規(guī)則，將滿足規(guī)則的訂單標(biāo)記為異常訂單，這里先說一下WMS的異常單，因?yàn)閃MS的異常單與ERP的異常單會(huì)有關(guān)聯(lián)。

在WMS常見的異常原因有：缺貨、收貨地址變更、退款、部分退款、物流方式變更、取消發(fā)貨、備注變更、發(fā)貨超時(shí)、打包時(shí)錯(cuò)貨/少貨/次品等等

不同的異常原因后續(xù)的處理流程不同。

訂單退款和取消發(fā)貨，訂單就已經(jīng)結(jié)束了發(fā)貨流程。

部分取消發(fā)貨，通常是將訂單打回上游系統(tǒng)，上游系統(tǒng)拆單后重新下推到倉(cāng)庫。

其它的異常原因，本質(zhì)就是訂單進(jìn)行掛起，訂單不會(huì)進(jìn)入下一個(gè)環(huán)節(jié)。

那么在ERP的異常訂單也是同理，設(shè)置一些策略，訂單滿足策略就標(biāo)記異常。異常策略如下（僅供參考）：

這里只需要主要一個(gè)點(diǎn)，如果ERP的訂單下推到了WMS，在ERP標(biāo)記異常的訂單，相應(yīng)WMS的訂單是否也需要標(biāo)記異常？在WMS標(biāo)記異常，相應(yīng)ERP的訂單是否需要標(biāo)記異常？

如果在WMS標(biāo)記的異常訂單，相應(yīng)ERP的訂單也標(biāo)記異常，那么在ERP是否可以手動(dòng)解除異常？

以上就是整篇文章的內(nèi)容，希望能夠?qū)δ阌兴鶐椭?/p>

本文由@koi 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

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

該文觀點(diǎn)僅代表作者本人，人人都是產(chǎn)品經(jīng)理平臺(tái)僅提供信息存儲(chǔ)空間服務(wù)。

標(biāo)簽：