系統(tǒng)重構(gòu)實(shí)戰(zhàn):多平臺電商訂單履約系統(tǒng)設(shè)計(jì)
下面這篇是筆者整理分享的關(guān)于多平臺電商訂單履約系統(tǒng)設(shè)計(jì)的文章,包括訂單履約系統(tǒng)架構(gòu)設(shè)計(jì)、訂單履約業(yè)務(wù)流程、訂單履約系統(tǒng)訂單狀態(tài)流轉(zhuǎn)等相關(guān)內(nèi)容,感興趣的同學(xué)可以來看看哦!
最近終于完成了自己所負(fù)責(zé)的SaaS產(chǎn)品的電商訂單履約系統(tǒng)模塊重構(gòu),原本以為對該模塊已沉淀了一年,吃透了競品、聊過了用戶、梳理過了舊邏輯,那么做起來應(yīng)該十分順利。結(jié)果,還是逃不過幾個(gè)通宵的寫方案和該方案。
這篇文章我們一起聊聊電商訂單履約系統(tǒng)設(shè)計(jì),以此也總結(jié)復(fù)盤一下我的第一個(gè)大項(xiàng)目。
首先,為大家簡述下這款SaaS產(chǎn)品的背景。它是一款面向中小微商家的多平臺電商及自建商城訂單履約系統(tǒng)。由于定位于中小微商家,系統(tǒng)并沒有涉及預(yù)分倉、倉庫/門店下發(fā)等功能。
但是,我仍然選擇這次重構(gòu)在系統(tǒng)架構(gòu)設(shè)計(jì)上將履約全流程納入設(shè)計(jì)范圍,只是在業(yè)務(wù)功能實(shí)現(xiàn)的時(shí)候,我們做功能的精簡、流程的跳過以及根據(jù)實(shí)際產(chǎn)品情況做改動。原因很簡單:升維設(shè)計(jì),降維打擊。這樣子設(shè)計(jì)出來的系統(tǒng)雖小可大,具備拓展性。(誰也說不準(zhǔn),明天老板就讓做一個(gè)供應(yīng)商代發(fā)的系統(tǒng))。
一、訂單履約系統(tǒng)架構(gòu)設(shè)計(jì)
何為訂單履約?訂單履約就是從訂單交易產(chǎn)生后,交付給用戶包括售后的全過程。系統(tǒng)的主要實(shí)現(xiàn)目標(biāo)是能高效、準(zhǔn)確、透明的完成訂單履約全過程。
我們的系統(tǒng)主要承接了兩部分的訂單來源:第三方電商平臺和自建商城。第三方平臺是用戶在淘寶、天貓、拼多多等平臺上開的電商店鋪。自建商城是用戶自行搭建的商城系統(tǒng),通過API的方式將訂單導(dǎo)入到的系統(tǒng)。
訂單進(jìn)入到系統(tǒng)后,用戶的業(yè)務(wù)目標(biāo)是:
- 將訂單打印成快遞單后,揀貨、打包、快遞發(fā)貨,且物流單號要回傳到平臺/商城;
- 物流的跟蹤管理,跟進(jìn)物流的攬件、運(yùn)輸、派件、簽收狀態(tài)。
那么,根據(jù)用戶的業(yè)務(wù)目標(biāo),我們可以設(shè)計(jì)以下的系統(tǒng)架構(gòu):
However,通過閱讀了《實(shí)戰(zhàn)供應(yīng)鏈》全局了解了訂單履約全流程后,發(fā)現(xiàn)“訂單打印”放在訂單履約中心并不妥當(dāng)。我們可以先從下圖看訂單履約全流程:
可以看到,在履約全流程里面訂單打印是在下發(fā)庫房后發(fā)生的,結(jié)合業(yè)務(wù)場景來看,包括快遞單在內(nèi)的各類單據(jù)打印確實(shí)是在庫房里面進(jìn)行,以及該系統(tǒng)操作背后是有揀貨、打包等作業(yè)流程。
如果將訂單打印放在訂單履約中心的話,后續(xù)若增加分倉發(fā)貨、波次生成等功能時(shí),會導(dǎo)致訂單履約中心職責(zé)不明確、訂單混亂(若按倉庫拆分訂單的話,庫房會單獨(dú)成單。放到履約系統(tǒng)的話,會影響到原本的父子結(jié)構(gòu))。因此,我們可以做以下調(diào)整:
在這個(gè)架構(gòu)中,我們將【訂單打印】抽出來成為“WMS”。
不過,此WMS非WMS,按照當(dāng)前的公司戰(zhàn)略來看,“WMS”只需要承載訂單打?。òǖ幌抻诳爝f單、發(fā)貨單、揀貨單、拿貨單)。當(dāng)然,也可以迭代一個(gè)【掃碼核對并發(fā)貨】的功能在”WMS“中,輔助用戶打包核對與回傳單號到電商平臺/自建商城。
總而言之,這樣的架構(gòu)設(shè)計(jì)無論后續(xù)用戶/業(yè)務(wù)方/老板想增加什么樣的功能,功能都會有其合適的”歸屬“了。
其次,就是【倉儲路由中心】,按照當(dāng)前的公司戰(zhàn)略和重構(gòu)目標(biāo)是可以先不實(shí)現(xiàn)的。
但是,作為SaaS產(chǎn)品經(jīng)理來說,還是要看的更長遠(yuǎn)一些,雖然當(dāng)前的產(chǎn)品定位做的是SMB,但是如果哪天轉(zhuǎn)型做電商erp或者孵化分銷代發(fā)erp且要聯(lián)動現(xiàn)有產(chǎn)品的話(大概率),該模塊必不可少。因此,在設(shè)計(jì)之初產(chǎn)品和開發(fā)大哥們需要關(guān)注它。
- 訂單轉(zhuǎn)換中心:對接各個(gè)第三方平臺和自建商城系統(tǒng)。因?yàn)楦髌脚_的訂單結(jié)構(gòu)不盡相同,為了能統(tǒng)一在履約系統(tǒng)中對訂單進(jìn)行管理,保證訂單內(nèi)部流轉(zhuǎn)的標(biāo)準(zhǔn)化。適配的信息包括商品、地址、訂單狀態(tài)、物流公司等。
- 訂單履約中心:負(fù)責(zé)處理訂單履約的全過程,對上通過訂單轉(zhuǎn)換中心與銷售平臺進(jìn)行信息同步,對下通過倉儲路由中心將訂單信息上下傳,內(nèi)部可以通過調(diào)度中央庫存、配送系統(tǒng)、規(guī)則引擎等多個(gè)外圍系統(tǒng)對訂單信息進(jìn)行層層拆解和組裝,將訂單加工為滿足履約條件的可執(zhí)行指令。
- 倉儲路由中心:用以與倉庫系統(tǒng)/代發(fā)系統(tǒng)進(jìn)行交互,將訂單路由分發(fā)至目標(biāo)庫房/目標(biāo)供應(yīng)商,同時(shí)將目標(biāo)庫房/目標(biāo)供應(yīng)商的發(fā)貨信息收集并回傳至訂單履約中心。
- “WMS”:可為倉儲管理系統(tǒng),也可為供應(yīng)商代發(fā)系統(tǒng),當(dāng)前為承接訂單打印的模塊。
- 物流中心:也是配送系統(tǒng),對接“WMS”和物流公司系統(tǒng)。接收“WMS”下發(fā)的物流單號,對其進(jìn)行物流查詢和異常監(jiān)控,并將物流信息收集并回傳至“WMS”和訂單履約系統(tǒng)。
二、訂單履約業(yè)務(wù)流程
由于我的產(chǎn)品并不涉及訂單履約全流程,所以該部分內(nèi)容主要闡述我的系統(tǒng)所承接的履約節(jié)點(diǎn),其他節(jié)點(diǎn)會有所提及但不會深入。如果想要深入了解的,強(qiáng)烈推薦閱讀羅靜老師的《實(shí)戰(zhàn)供應(yīng)鏈》~當(dāng)然,最有效的還是到現(xiàn)場多學(xué)多看多問~
對一個(gè)中小微電商商家來說,一個(gè)訂單會經(jīng)歷以下節(jié)點(diǎn),中間仍然會涉及到銷售平臺、訂單轉(zhuǎn)化中心、訂單履約中心等多個(gè)系統(tǒng)。系統(tǒng)設(shè)計(jì)目標(biāo)如上文提到的:能高效、準(zhǔn)確、透明的完成訂單履約全過程。進(jìn)而,讓供應(yīng)鏈各個(gè)節(jié)點(diǎn)通暢協(xié)同。
1. 新訂單
訂單系統(tǒng)接到新單的狀態(tài),此處根據(jù)業(yè)務(wù)分為兩塊邏輯處理:第三方平臺訂單,自建商城訂單。
第三方平臺訂單:客戶在第三方平臺上完成支付后,訂單系統(tǒng)接收第三方平臺同步的訂單。如果是預(yù)售或定制訂單的話,應(yīng)當(dāng)待用戶付完尾款后再進(jìn)入訂單系統(tǒng)。
自營平臺訂單:客戶提交訂單后,訂單系統(tǒng)便生成一張新訂單。
2. 訂單拆分
用戶在電商平臺上一次購物,通常會將多個(gè)商家的多個(gè)商品作為一個(gè)訂單支付,但是一張訂單里面會包含多個(gè)商家、多個(gè)供應(yīng)商的商品,因此需要對訂單進(jìn)行拆分。
履約流程設(shè)計(jì)圖中訂單拆分發(fā)生在新訂單后,但是在實(shí)際業(yè)務(wù)中會出現(xiàn)在訂單履約的多個(gè)環(huán)節(jié)中的,場景較多也比較靈活,圖中僅代表其首次拆分的節(jié)點(diǎn)。那么,在系統(tǒng)設(shè)計(jì)上,可以部分場景系統(tǒng)做自動拆分,部分場景提供人工拆分,看具體的業(yè)務(wù)情況。以下是訂單拆分考慮的幾個(gè)維度:
- 店鋪維度:銷售平臺、不同店鋪
- 倉庫維度:不同的發(fā)貨倉庫
- 供應(yīng)商維度:不同的供應(yīng)商
- 商品品類維度:商品屬性、商品價(jià)值、配送條件
- 訂單類型維度:預(yù)售商品、實(shí)物商品、虛擬商品
- 物流因素:根據(jù)快遞公司的價(jià)格,將訂單根據(jù)重量或體積拆分成多個(gè)包裹、代收貨款金額快遞公司上限、跨境訂單出關(guān)金額限制、根據(jù)上述的維度,我們可以將訂單的拆分分成銷售層、調(diào)度層、倉庫層3層去進(jìn)行。
- 店鋪、訂單類型可以在銷售層進(jìn)行拆分
- 商品品類、倉庫、供應(yīng)商可以在調(diào)度層進(jìn)行拆分
- 物流可以在倉庫層進(jìn)行拆分
3. 訂單合并
為降低運(yùn)費(fèi)成本和庫房作業(yè)成本,會根據(jù)自動合并條件,將多筆訂單合并為一筆訂單進(jìn)行物流發(fā)貨。
通常,訂單合并我們會設(shè)計(jì)自動合并+手動合并。新訂單進(jìn)來時(shí),系統(tǒng)先自動合并。為避免用戶操作失誤取消合并或系統(tǒng)異常沒有執(zhí)行合并,仍會保留自動合并操作按鈕。
常見的訂單合并條件:同銷售平臺、同收貨地址、同收貨人、同手機(jī)號、同出庫倉庫、同訂單類型(如普通訂單、預(yù)售訂單)、同配送方式(自提/配送)
不給過,除了根據(jù)業(yè)務(wù)劃分出來的訂單信息相同合并以外,還要考慮訂單各類狀態(tài)是否可以合并,如打印狀態(tài)的未打印和已打印是否可以合并,發(fā)貨狀態(tài)的未發(fā)貨和已發(fā)貨是否可以合并等。
4. 訂單打印
打單員按照消費(fèi)者需求/公司要求/倉庫作業(yè)流程,將每張訂單的快遞面單、紙質(zhì)發(fā)票、發(fā)貨清單等各類單據(jù)打印出來。
對于訂單數(shù)量大,倉庫分區(qū)多的商家,通常會采用波次揀選。根據(jù)波次生成分揀任務(wù),打印批揀單后揀貨員進(jìn)行揀貨。揀貨過程可以”先揀后分“或者”變揀邊分“,分完后再將【訂單打印】環(huán)節(jié)的單據(jù)對應(yīng)打包和貼單。
對于訂單量適中,但是倉庫分區(qū)簡單、動線不復(fù)雜的商家,通常直接生成揀貨單給揀貨員進(jìn)行揀貨。后續(xù)過程與上面一樣。
對于訂單小,倉庫也小【倉庫規(guī)?;旧鲜且粋€(gè)人和一個(gè)小鋪面】的商家(我的產(chǎn)品所服務(wù)的主要客群),則是直接打印快遞單進(jìn)行揀貨(最省事)。
倉庫人員按照揀貨打包要求在系統(tǒng)里面對訂單做篩選,篩選出A條件訂單后進(jìn)行批量打印快遞單,根據(jù)快遞面單自定義區(qū)的商品信息去揀貨、打包貼單。然后再用B條件篩選訂單,往復(fù)循環(huán)至當(dāng)天要發(fā)出的訂單打包完成。
5. 訂單發(fā)貨
發(fā)貨員將包裹交由快遞員攬收,并在系統(tǒng)中操作發(fā)貨。發(fā)貨以后,若實(shí)際發(fā)貨物流有變化,回傳實(shí)際的物流公司及物流單號至履約系統(tǒng),履約系統(tǒng)再通過訂單轉(zhuǎn)換中心將物流信息回傳銷售平臺。
不過現(xiàn)在的第三方電商平臺對于商家的發(fā)貨履約規(guī)則制度越來越完善,加上商家為了降低運(yùn)費(fèi)成本選擇一些快遞黃牛發(fā)貨,如果等有攬件記錄再回傳到履約系統(tǒng)和銷售平臺,可能會發(fā)貨履約超時(shí)導(dǎo)致罰款。
但是,平臺也對物流商履約做了約束,如果過早回傳單號到平臺,在一定時(shí)間內(nèi)物流沒有產(chǎn)生軌跡,那么會被判為攬收超時(shí),同樣會被罰款。因此,在設(shè)計(jì)訂單發(fā)貨功能時(shí),可以增加一些自動化規(guī)則配置/定時(shí)任務(wù)給到商家使用,商家可以結(jié)合自己的發(fā)貨安排和物流商履約承諾來選擇適當(dāng)?shù)臅r(shí)間點(diǎn)在系統(tǒng)進(jìn)行發(fā)貨。
6. 物流攬件
物流公司快遞員收到包裹后,將包裹帶回?cái)埣W(wǎng)點(diǎn)在快遞系統(tǒng)中操作攬件。攬件網(wǎng)點(diǎn)將攬收的包裹打包集中,然后通過小型運(yùn)輸車輛將攬收的包裹送到就近的攬件中心。
攬件操作信息可由配送系統(tǒng)調(diào)用物流公司提供的接口獲取,解析完后回傳到訂單系統(tǒng)中。
7. 物流運(yùn)輸
到達(dá)攬件中心(也稱分揀中心,是大規(guī)模的包裹集散中心)后,對于到達(dá)本地的包裹,攬件中心根據(jù)包裹的詳細(xì)地址,將包裹分發(fā)給對應(yīng)的派件網(wǎng)點(diǎn)。對于發(fā)往外地的包裹,攬件中心根據(jù)包裹的行政區(qū),如省、市、區(qū)/縣,將包裹分發(fā)給對應(yīng)的派件中心,從攬件中心分發(fā)到派送中心的包裹,通常通過大型運(yùn)輸車輛專程運(yùn)送。
從攬件中心發(fā)出,也代表包裹正式進(jìn)入物流運(yùn)輸。
8. 物流派件
包裹到達(dá)派送中心后,派送中心根據(jù)包裹的詳細(xì)地址,將包裹分發(fā)給對應(yīng)的派件網(wǎng)點(diǎn)。派件網(wǎng)點(diǎn)根據(jù)包裹的詳細(xì)地址,指派指定的派件員進(jìn)行派送,將包裹送到收貨人手中。
9. 物流簽收
包裹送達(dá)客戶手中,完成簽收。
三、 訂單履約系統(tǒng)訂單狀態(tài)流轉(zhuǎn)
根據(jù)羅靜老師的《實(shí)戰(zhàn)供應(yīng)鏈》一書得知,訂單履約系統(tǒng)狀態(tài)有如下:
不過,根據(jù)我的產(chǎn)品定位、目標(biāo)群體和其他客觀情況,我的電商訂單履約系統(tǒng)的訂單狀態(tài)做了一些調(diào)整。訂單狀態(tài)由三種獨(dú)立狀態(tài)共同組成:正向的發(fā)貨狀態(tài),逆向的售后狀態(tài),快遞單打印狀態(tài)。發(fā)貨后的物流攬件、運(yùn)輸、派件、簽收由訂單的獨(dú)立物流狀態(tài)承接。
發(fā)貨狀態(tài):分為待發(fā)貨、部分發(fā)貨、已發(fā)貨三種狀態(tài)。
若父訂單中的子訂單(子訂單對應(yīng)的就是一個(gè)sku)都沒有發(fā)貨,則為待發(fā)貨;若父訂單中的僅部分子訂單發(fā)貨,則為部分發(fā)貨;若父訂單中的所有子訂單發(fā)貨,則為已發(fā)貨。
發(fā)貨狀態(tài)的區(qū)分可以讓用戶知曉哪些訂單未回傳到銷售平臺,這關(guān)乎到用戶的發(fā)貨履約。
售后狀態(tài):由于系統(tǒng)主要還是以正向的發(fā)貨狀態(tài)為主,售后狀態(tài)只區(qū)分用戶申請售后(即售后開始)、售后成功、售后失敗。
當(dāng)用戶發(fā)起無論何種類型的售后時(shí),訂單會標(biāo)記為”用戶申請售后“,前端也會透出;當(dāng)售后成功時(shí),訂單會標(biāo)記為”售后成功“,前端也會透出;當(dāng)售后失敗時(shí),訂單會標(biāo)記為”售后失敗“,但是前端不透出。
售后狀態(tài)的區(qū)分可以讓用戶知曉哪些訂單可以正常發(fā)貨,輔助用戶在訂單打印流程中篩選有效發(fā)貨訂單,避免多發(fā)導(dǎo)致資損。
快遞單打印狀態(tài):分為未打印和已打印。
其主要記錄訂單是否打印了快遞單,如上述中小微商家是通過多次篩選進(jìn)行批量打印的,而非全部訂單一次性批量打印,因此記錄訂單打印狀態(tài)流轉(zhuǎn)十分有必要。如果打印狀態(tài)流轉(zhuǎn)不正確,那么就會導(dǎo)致多打一張面單,多發(fā)一個(gè)包裹導(dǎo)致資損。
那么,為什么要通過三種獨(dú)立狀態(tài)進(jìn)行組合成訂單狀態(tài)呢?
首先,通過上述三個(gè)狀態(tài)的介紹可以看出,這三個(gè)狀態(tài)無非就是告訴商家哪些訂單可以打印、哪些訂單還沒發(fā)貨回傳這兩件事情。而打印和發(fā)貨也是整個(gè)訂單履約倉庫發(fā)貨環(huán)節(jié)要實(shí)現(xiàn)的業(yè)務(wù)目標(biāo),因此是很核心的。
再結(jié)合中小微商家訂單打印、揀貨、核對打包的業(yè)務(wù)場景與流程,【訂單篩選】是個(gè)高頻核心的系統(tǒng)操作。
那么,如何將這三種獨(dú)立狀態(tài)實(shí)現(xiàn)高效的訂單篩選呢?
答案就是組合成虛擬的訂單狀態(tài)。何為虛擬的訂單狀態(tài)?即將后端的這三種獨(dú)立狀態(tài)組合成前端界面上的tab標(biāo)簽,tab標(biāo)簽名字即虛擬的訂單狀態(tài),其本質(zhì)是三種獨(dú)立狀態(tài)預(yù)置條件篩選的結(jié)果,這通過接口入?yún)⒖刂剖趾脤?shí)現(xiàn)。虛擬的訂單狀態(tài)既實(shí)現(xiàn)了核心狀態(tài)的高校篩選,也降低了用戶對系統(tǒng)的理解成本,十分適用于中小微商家了。
除此之外,還有一個(gè)原因:因?yàn)槲覀兪亲鯯aaS產(chǎn)品的,用戶或其上下游可能會使用其他產(chǎn)品對訂單進(jìn)行處理,即不一定每筆訂單的每個(gè)節(jié)點(diǎn)流轉(zhuǎn)都是由我們的系統(tǒng)發(fā)起。因此,無法像羅老師梳理出來的訂單狀態(tài)來設(shè)計(jì)該產(chǎn)品后端的訂單狀態(tài)。
因此,所謂訂單狀態(tài)是虛擬的訂單狀態(tài),具體流轉(zhuǎn)設(shè)計(jì)如下:
四、 結(jié)尾
此次項(xiàng)目讓我對訂單履約系統(tǒng)有了進(jìn)一步的深入了解,不得不感嘆前輩們留下的豐富經(jīng)驗(yàn)背后到底踩了多少坑。供應(yīng)鏈系統(tǒng)的龐大和復(fù)雜,只有沉下心、多鉆研、多思考、多總結(jié)才能成為優(yōu)秀的供應(yīng)鏈人呀!
本文由 @Kuang扶正義的匡 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,禁止轉(zhuǎn)載
題圖來自 Unsplash,基于 CC0 協(xié)議
該文觀點(diǎn)僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務(wù)。
1、前端列表上,只展示那筆合并訂單和其信息即可,被合并的訂單的基礎(chǔ)信息可以放在訂單詳情里面查看。
2、后端上,合單和原單都把物流信息存下來。因?yàn)槿绻唵巫隽瞬鸱衷俸喜⒋蛴】爝f單的話,單號是需要回到原單做后續(xù)的發(fā)貨操作的。以及如果系統(tǒng)允許合單打印后取消合并的話,在該場景下,用物流單號檢索回這兩筆取消合并的訂單會比較方便。
如果合并訂單,那么在用戶側(cè)的訂單信息中物流怎么顯示?兩個(gè)訂單都顯示同一個(gè)快遞單號嗎?
1、前端列表上,只展示那筆合并訂單和其信息即可,被合并的訂單的基礎(chǔ)信息可以放在訂單詳情里面查看。
2、后端上,合單和原單都把物流信息存下來。因?yàn)槿绻唵巫隽瞬鸱衷俸喜⒋蛴】爝f單的話,單號是需要回到原單做后續(xù)的發(fā)貨操作的。以及如果系統(tǒng)允許合單打印后取消合并的話,在該場景下,用物流單號檢索回這兩筆取消合并的訂單會比較方便。
感謝