解構(gòu)電商/O2O:訂單系統(tǒng),平臺(tái)的“生命中軸線”

11 評(píng)論 35331 瀏覽 346 收藏 16 分鐘

訂單系統(tǒng)作為電商系統(tǒng)的“中軸線”貫穿了整個(gè)電商系統(tǒng)的全部流程。所有的核心系統(tǒng)都是圍繞訂單進(jìn)行構(gòu)建的。訂單的發(fā)展也是隨著電商、O2O行業(yè)發(fā)展逐漸演變進(jìn)化的,今天跟大家來解構(gòu)下這個(gè)平臺(tái)的“生命中軸線”。

訂單基本概念

設(shè)計(jì)訂單系統(tǒng)時(shí)包含幾個(gè)大的方向需要考慮,這些內(nèi)容決定了訂單系統(tǒng)的穩(wěn)定性和可持續(xù)性。

訂單字段

訂單字段包含了訂單中需要記錄的信息,他的作用主要用于溝通其他系統(tǒng),為下游系統(tǒng)提供信息依據(jù)。

訂單信息

訂單號(hào)作為訂單識(shí)別的標(biāo)識(shí),往往由一串?dāng)?shù)字組成,根據(jù)訂單的增加進(jìn)行自增,也可以在設(shè)計(jì)訂單號(hào)的時(shí)候考慮訂單加密設(shè)置(否則別人通過訂單編號(hào)就能計(jì)算出你們家的銷售量)。訂單號(hào)后續(xù)用作訂單唯一標(biāo)示用于對(duì)接WMS和TMS時(shí)的訂單識(shí)別。

訂單狀態(tài)機(jī)在下面章節(jié)會(huì)詳細(xì)描述,這里不做展開。

用戶信息

這里指購買人的相關(guān)信息,主要包括姓名、地址、手機(jī)號(hào)。O2O還會(huì)多一種情況就是自提點(diǎn),這樣地址則會(huì)變?yōu)樽蕴狳c(diǎn)的地址。地址信息在后續(xù)會(huì)作用在WMS和TMS上用于區(qū)分區(qū)域和配送安排。

購買商品信息

這里指購買商品的基本信息和庫存,金額由于比較特殊所以我把金額獨(dú)立在商品信息以外說,不過邏輯上其實(shí)都屬于商品信息范疇。商品信息主要影響庫存更新和WMS生產(chǎn)。

金額信息

訂單產(chǎn)生的商品信息,這里面除了要記錄最終的金額,過程金額也需要記錄。比如商品分?jǐn)偟膬?yōu)惠金額、支付金額,應(yīng)付金額等。在后續(xù)的訂單結(jié)算、退換貨、財(cái)務(wù)等環(huán)節(jié)都需要使用。

時(shí)間信息

記錄訂單每個(gè)節(jié)點(diǎn)的觸發(fā)時(shí)間。

訂單流程

訂單流程是指整個(gè)訂單從產(chǎn)生到完成整個(gè)流轉(zhuǎn)過程。他包括正向流程和逆向流程。

正向流程

訂單正常生產(chǎn)到配送的過程。這里面列舉的模塊是一般電商通用的功能,部分可能根據(jù)實(shí)際業(yè)務(wù)場(chǎng)景有所增加調(diào)整。020場(chǎng)景下出庫、合包裹、發(fā)票準(zhǔn)備等工作是由商家方進(jìn)行,部分工作是屬于線下場(chǎng)景。

整個(gè)流程涉及到的環(huán)節(jié)非常多。這里面提幾個(gè)細(xì)節(jié)上需要注意的地方:

  1. 訂單生成環(huán)節(jié)存在超時(shí)未支付自動(dòng)取消的過程。庫存的占用會(huì)在訂單取消后釋放。
  2. 如果選擇COD(貨到付款)則支付環(huán)節(jié)相應(yīng)轉(zhuǎn)移到訂單配送之后,而過程中所有與款項(xiàng)相關(guān)的邏輯變?yōu)橹徊僮鹘痤~數(shù)字,不對(duì)結(jié)算和賬戶進(jìn)行打退款操作。
  3. 金額分?jǐn)傂枰狡?,這個(gè)在之前解構(gòu)電商、O2O用戶端“背后”的邏輯中有說明,這里就不細(xì)說了。
  4. 訂單系統(tǒng)審核主要用戶對(duì)惡意用戶或者刷單情況進(jìn)行處理。系統(tǒng)可根據(jù)白名單、黑名單、消費(fèi)頻次、促銷品購買量當(dāng)方面做風(fēng)控規(guī)則。如果后續(xù)會(huì)進(jìn)入到人工審核,則規(guī)則上可以適當(dāng)從寬。當(dāng)觸發(fā)規(guī)則需要進(jìn)行訂單退訂的行為。此處設(shè)計(jì)時(shí)要小心對(duì)用戶體驗(yàn)的損害,往往前臺(tái)文案上說明當(dāng)前節(jié)點(diǎn)是審核狀態(tài)或者是等待接單。
  5. 在O2O領(lǐng)域有催單的概念,而傳統(tǒng)電商則是通過關(guān)聯(lián)第三方物流的物流信息進(jìn)行跟蹤。催單觸發(fā)考慮到實(shí)際場(chǎng)景,一般會(huì)設(shè)定一定的時(shí)間間隔,間隔時(shí)間內(nèi)只觸發(fā)一次催單的請(qǐng)求。
  6. 預(yù)售等貨和移倉需要做成SOA服務(wù),以便在交易頁面計(jì)算預(yù)計(jì)時(shí)間和預(yù)計(jì)到貨時(shí)間。移倉處理依賴倉庫的情況,也會(huì)涉及到后續(xù)拆分和合并包裹的邏輯。
  7. 訂單生產(chǎn)時(shí)先要判斷報(bào)缺情況,如果出現(xiàn)報(bào)缺問題則要考慮整單報(bào)缺、部分報(bào)缺、換貨或者換轉(zhuǎn)退的情況(庫存,倉促調(diào)撥和退款)。報(bào)缺情況分為系統(tǒng)報(bào)缺和實(shí)物報(bào)缺,這是承接但相對(duì)獨(dú)立的兩個(gè)環(huán)節(jié)。
  8. 電商系統(tǒng)要考慮7天無理由退貨的情景,即訂單狀態(tài)完成后申請(qǐng)退貨。此時(shí)主要涉及的是金額上的計(jì)算以及一些財(cái)務(wù)程序(如發(fā)票等)問題的處理。

逆向流程

逆向流程則指訂單發(fā)生取消、退貨等情況時(shí)引發(fā)的訂單流程過程。在設(shè)計(jì)逆向流程時(shí)建議和正向獨(dú)立分開,通過訂單號(hào)等信息進(jìn)行關(guān)聯(lián),避免耦合過多邏輯無法延展設(shè)計(jì)。

逆向流程的觸發(fā)主要有幾種情況

  • 用戶自主取消訂單(整單)
  • 風(fēng)控系統(tǒng)觸發(fā)取消訂單(整單)
  • 客服接到客訴仲裁后觸發(fā)取消訂單(整單)
  • 超時(shí)未支付取消訂單(整單)
  • 換貨報(bào)缺轉(zhuǎn)為退單(整單、部分報(bào)缺)

觸發(fā)條件考慮兩個(gè)方面

  • 訂單狀態(tài)機(jī)(某一節(jié)點(diǎn)后如訂單生產(chǎn)后不允許取消訂單)
  • 訂單生成時(shí)間(主要是O2O方面,考慮到配送時(shí)間和線下流程的不規(guī)范,有可能出現(xiàn)狀態(tài)機(jī)沒觸發(fā)更新但實(shí)際流程在流轉(zhuǎn)的情況)

其他要注意的一些內(nèi)容

  • 當(dāng)退單被商家拒絕后需要轉(zhuǎn)入客服仲裁的環(huán)節(jié)
  • 部分退的訂單促銷一般保持享用狀態(tài),但金額按照分?jǐn)偟慕痤~進(jìn)行退款。

訂單狀態(tài)機(jī)

關(guān)于狀態(tài)機(jī),我在百度上搜索了下定義。

關(guān)于狀態(tài)機(jī)的一個(gè)極度確切的描述是它是一個(gè)有向圖形,由一組節(jié)點(diǎn)和一組相應(yīng)的轉(zhuǎn)移函數(shù)組成。狀態(tài)機(jī)通過響應(yīng)一系列事件而“運(yùn)行”。每個(gè)事件都在屬于“當(dāng)前” 節(jié)點(diǎn)的轉(zhuǎn)移函數(shù)的控制范圍內(nèi),其中函數(shù)的范圍是節(jié)點(diǎn)的一個(gè)子集。函數(shù)返回“下一個(gè)”(也許是同一個(gè))節(jié)點(diǎn)。這些節(jié)點(diǎn)中至少有一個(gè)必須是終態(tài)。當(dāng)?shù)竭_(dá)終態(tài), 狀態(tài)機(jī)停止。

由上述定義可以看到,狀態(tài)機(jī)的概念是用來表示按照一定的方向通過觸發(fā)不同節(jié)點(diǎn)產(chǎn)生數(shù)據(jù)流轉(zhuǎn)的過程。在訂單中通過情景觸發(fā)訂單狀態(tài)的變化來表達(dá)訂單流轉(zhuǎn)的過程就是訂單狀態(tài)機(jī)。

電商

O2O

電商和O2O的主體流程是相同的,不同的在于物流配送環(huán)節(jié)電商較O2O更為復(fù)雜,此處只表明了主要的訂單狀態(tài)機(jī),倉儲(chǔ)物流內(nèi)的物流單流轉(zhuǎn)不在此范圍內(nèi)。狀態(tài)機(jī)原則上使用結(jié)果值而不使用過程值,比如使用支付成功作為節(jié)點(diǎn)而不使用支付中作為節(jié)點(diǎn)。

訂單狀態(tài)機(jī)要融合訂單流程來設(shè)計(jì)觸發(fā)節(jié)點(diǎn),訂單流程的邏輯點(diǎn)要多于狀態(tài)機(jī),一般在當(dāng)前流程環(huán)節(jié)完成后最后更新狀態(tài)機(jī)。

訂單推送

當(dāng)狀態(tài)機(jī)發(fā)生變化時(shí),需要將對(duì)應(yīng)的變化情況告知給相關(guān)人員以便了解當(dāng)前訂單的情況。這就是訂單推送的作用。

訂單推送的觸發(fā)依賴于狀態(tài)機(jī)的變化,涉及到的信息包括

  • 推送對(duì)象(用戶、物流人員、商家)
  • 推送方式(push,短信)
  • 推送節(jié)點(diǎn)(狀態(tài)機(jī))

訂單的演變

電商平臺(tái)的搭建變遷也是訂單逐步穩(wěn)固發(fā)展的過程。我們來看下訂單的發(fā)展過程,結(jié)算環(huán)節(jié)由于是一個(gè)比較大的話題,這里面不展開說明了。

訂單第一階段:實(shí)現(xiàn)訂單流轉(zhuǎn)

平臺(tái)搭建的第一階段要實(shí)現(xiàn)基本的訂單流轉(zhuǎn),支持一些營銷活動(dòng)的購買(這里依賴附屬系統(tǒng)的搭建情況,這里默認(rèn)認(rèn)為具備基本功能)。

  1. 實(shí)現(xiàn)訂單的生成、生產(chǎn)
  2. 支持訂單審核(初期可支持人工審核即可)
  3. 支持用戶端顯示訂單相關(guān)信息
  4. 支持促銷金額的計(jì)算

這個(gè)階段搭建時(shí)核心是解決訂單的基本流轉(zhuǎn),所以原則上一些功能可以后續(xù)再逐步完善。比如催單、拆單、系統(tǒng)審核等。

另外在搭建訂單結(jié)構(gòu)的時(shí)候如果條件允許,在設(shè)計(jì)之初可以就考慮用子母單的形式,即兩層結(jié)構(gòu)

  • 母單負(fù)責(zé)訂單整體信息的記錄
  • 子單記錄單個(gè)商品的詳細(xì)信息和金額情況

訂單第二階段:平臺(tái)化搭建

隨著平臺(tái)的發(fā)展,越來越多的接入方需要訂單的支持,POP平臺(tái)的商家接入、第三方倉配的接入,更多快遞合作伙伴的接入等等。訂單的功能進(jìn)入第二階段的擴(kuò)充。

  1. 提供訂單soa服務(wù)
  2. 支持跨平臺(tái)交易單生成(即同一個(gè)大交易單內(nèi)既有商家商品又有自營商品或者是多個(gè)商家的商品)
  3. 對(duì)接多個(gè)倉庫,支持移倉模式
  4. 根據(jù)倉配情況計(jì)算預(yù)計(jì)送達(dá)時(shí)間(訂單promise服務(wù))
  5. 支持拆單、合單邏輯(配送單、支付單等)
  6. 支持快遞分單
  7. 提供更豐富的訂單推送服務(wù),完善訂單狀態(tài)機(jī)

這里說幾個(gè)訂單復(fù)雜化以后需要注意的細(xì)節(jié)

  • 訂單子母單結(jié)構(gòu),便于將信息進(jìn)行梳理,減少耦合
  • 拆單、合單邏輯主要是用于解決不同系統(tǒng)之間的耦合問題(如配送單主要運(yùn)用于TMS,支付單提交給支付系統(tǒng))。他們都通過交易訂單信息項(xiàng)重新組合后添加部分自有系統(tǒng)的信息項(xiàng)而組成,通過訂單編號(hào)來做關(guān)聯(lián)。交易單和支付單是1:1,交易單和物流單也叫配送單則可能是N:N的關(guān)系。
  • 移倉的邏輯和預(yù)計(jì)送達(dá)時(shí)間要依賴倉配結(jié)構(gòu)和運(yùn)輸能力的測(cè)算,當(dāng)然也可以通過拆包裹分多次發(fā)的方式減少移倉的次數(shù),不過要考慮要前臺(tái)用戶體驗(yàn)和免責(zé)說明。
  • 當(dāng)自營品和商家品或者多個(gè)商家品的時(shí)候,優(yōu)惠券的分?jǐn)傆?jì)算要注意。要區(qū)分商家券和全場(chǎng)通用券可分?jǐn)偟谋壤蛢?yōu)先級(jí)。

訂單第三階段:更多類型的訂單模式

當(dāng)平臺(tái)發(fā)展到足夠大的規(guī)模,提效、穩(wěn)定變成一個(gè)重要的話題。這里面介紹兩種情況:

預(yù)售

場(chǎng)景:無實(shí)物庫存,但是顧客可以下單預(yù)定。當(dāng)實(shí)物到貨后,按照正常訂單進(jìn)行配送。

預(yù)售單需要設(shè)置預(yù)售庫存數(shù)和預(yù)計(jì)到貨時(shí)間。用戶下單后不會(huì)直接進(jìn)入生產(chǎn),將預(yù)售訂單放入單獨(dú)的訂單庫(或增加預(yù)售品標(biāo)識(shí))。

預(yù)售商品到貨后要判斷涉及到貨庫存和預(yù)售訂單是否相等。當(dāng)實(shí)際庫存小雨預(yù)售訂單則按下單時(shí)間釋放等量訂單進(jìn)行生產(chǎn)。系統(tǒng)需要回告庫存系統(tǒng)重新計(jì)算預(yù)售占用庫存量。

JIT(準(zhǔn)時(shí)制生產(chǎn)方式 Just In Time 簡(jiǎn)稱JIT)

場(chǎng)景:銷售驅(qū)動(dòng)生產(chǎn),根據(jù)訂單進(jìn)行生產(chǎn)配送。

  • JIT模式需要設(shè)定JIT波次情況和支持JIT的倉庫
  • 相同JIT倉庫訂單按照J(rèn)IT波次時(shí)間點(diǎn)匯總訂單并驅(qū)動(dòng)產(chǎn)生ERP采購訂單;JIT和目標(biāo)倉告訴采銷系統(tǒng)
  • ERP到貨回告訂單系統(tǒng)已到貨
  • 訂單釋放進(jìn)入WMS生產(chǎn)

這里面需要說明的是JIT場(chǎng)景可以延伸為不入庫直接由供應(yīng)商提供物流配送后續(xù)工作,平臺(tái)提供訂單、發(fā)票等服務(wù)。這是流程會(huì)變?yōu)?/p>

  • 訂單告知ERP,生成采購單直接回告供應(yīng)商
  • 供應(yīng)商物流狀態(tài)對(duì)應(yīng)訂單狀態(tài)機(jī)進(jìn)行同步更新
  • 用戶收貨后通過郵寄方式提供發(fā)票
  • 該模式不支持換貨行為

結(jié)言

訂單是電商、020的生命中軸線,他主導(dǎo)、串聯(lián)了整個(gè)全部鏈路的系統(tǒng)。所有的系統(tǒng)都是圍繞訂單進(jìn)行改建和擴(kuò)張的。訂單系統(tǒng)的強(qiáng)壯決定了平臺(tái)的穩(wěn)定性。

相關(guān)閱讀

解讀產(chǎn)品背后的知識(shí):還原消費(fèi)行為的“運(yùn)行”原理(一)

解構(gòu)電商、O2O:營銷渠道的“快捷方式”——CRM

解構(gòu)電商、O2O:查閱商品的“檔案柜”

解構(gòu)電商、O2O:探索搜索系統(tǒng)的“簡(jiǎn)歷”

 

作者:高暉,微信號(hào)公眾號(hào)@產(chǎn)品老高,10余年IT經(jīng)驗(yàn),互聯(lián)網(wǎng)老兵。

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

題圖由作者提供

更多精彩內(nèi)容,請(qǐng)關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號(hào)或下載App
評(píng)論
評(píng)論請(qǐng)登錄
  1. 高暉老師也在人人都是產(chǎn)品經(jīng)理旗下起點(diǎn)課堂開設(shè)了《訂單產(chǎn)品全流程設(shè)計(jì)與實(shí)戰(zhàn)》課程,系統(tǒng)講解了訂單產(chǎn)品的底層邏輯,教你學(xué)會(huì)從0到1搭建訂單產(chǎn)品以及現(xiàn)有產(chǎn)品的優(yōu)化升級(jí)方法。感興趣的同學(xué)可以添加蘑菇老師(ID:qdxymg)咨詢,或者戳右側(cè)鏈接了解>>https://996.pm/76PEA

    來自廣東 回復(fù)
  2. 狀態(tài)機(jī)好像不對(duì)。。。

    來自江蘇 回復(fù)
  3. 電商的流程圖好像有點(diǎn)缺失,邏輯不嚴(yán)謹(jǐn)~

    回復(fù)
  4. 滿滿的干活

    回復(fù)
  5. 好多內(nèi)容??

    回復(fù)
  6. 您好,訂單生成和訂單生產(chǎn)有什么區(qū)別嗎?訂單生成我的理解是用戶購買商品的過程中,提交商品至結(jié)算,此時(shí)系統(tǒng)根據(jù)商品所屬的店鋪來生成訂單。不知道這樣理解是否有誤,那訂單生產(chǎn)呢?

    回復(fù)
    1. 如果我沒理解錯(cuò)的話:這里說的訂單生產(chǎn),是完成訂單內(nèi)容的生產(chǎn);訂單生成是系統(tǒng)生成具體的訂單

      來自江蘇 回復(fù)
    2. 不好意思,一直在忙沒注意看。我簡(jiǎn)單解釋下。訂單生成應(yīng)該比較容易理解,就是交易系統(tǒng)提交給訂單系統(tǒng)相關(guān)交易信息,訂單系統(tǒng)生成一條或多條訂單數(shù)據(jù)。這里面會(huì)記錄訂單的基本信息包括商品、金額、訂單號(hào)等。訂單系統(tǒng)拿到后會(huì)為了生產(chǎn)做一系列準(zhǔn)備,比如拆單、調(diào)撥、分配倉庫等。然后按照倉庫提交給WMS。WMS會(huì)收到訂單信息進(jìn)行生產(chǎn)。當(dāng)然實(shí)際業(yè)務(wù)上可能會(huì)更復(fù)雜,但基本邏輯是這樣的。

      來自北京 回復(fù)
    3. 我看系統(tǒng)關(guān)系圖內(nèi)沒有交易系統(tǒng)相關(guān)的,向請(qǐng)教下,交易系統(tǒng)和各個(gè)系統(tǒng)之間的關(guān)系是什么,以及交易系統(tǒng)內(nèi)都有哪些功能

      來自廣東 回復(fù)
    4. 交易系統(tǒng)的可以去我的公眾號(hào):產(chǎn)品老高上看下。那里面有一篇交易系統(tǒng)的文章,大概講解了交易系統(tǒng)的基本架構(gòu)和情況

      來自北京 回復(fù)
  7. 學(xué)習(xí)了 ??

    來自上海 回復(fù)