一、 關於訂單管理系統

訂單管理系統即處理訂單的系統,主要管理訂單的輸入,處理,輸出。其在一般電商系統中或在有交易功能的系統中,都是核心系統/功能之一,有一定的復雜度;但是雖然復雜,並不代表理解起來困難。

關於商品的文章裡面,我們已經從商品的輸入、維護、輸出的流程來介紹了商品系統,那訂單也一樣,我們本文把訂單看成一個流程即訂單流來理解。


二、 訂單管理系統與整體系統的關系

訂單系統會與購物車、商品系統,營銷系統、會員系統、支付系統、物流系統、倉庫系統、財務系統、內容系統,具體請看示例圖:

1.  購物車:個人認為是訂單的起點,商品會被加入購物車,然後會被提交

2.  商品系統:在提交訂單頁面會看到該訂單所包含的商品資訊,例如商品名稱、所購買數量、價格、售後資訊等

3.  營銷系統:會顯示商品是否優惠資訊,例如滿減、優惠券

4.  會員系統:會顯示該會員是否有基於會員等級的折扣資訊(如淘寶的88會員),或是否有可抵扣金額的會員點數(如京豆);會顯示該會員下面的收貨地址資訊、也會顯示該會員下面是否有充值卡、運費券等。

5.  倉庫系統:基於收貨地址資訊顯示發貨倉庫,自提地點等,並且訂單最終會流轉到該系統進行發貨操作。

6.  支付系統:顯示支付方式(如貨到付款、線上支付等)、並且在支付的時候計算該會員實際應付的金額,以及顯示銀行卡資訊等。

7.  物流系統:顯示配送時間、配送方式、運費等,並且在訂單發貨後會顯示實際的配送路徑。

8.  財務系統:顯示開票資訊等,在訂單完成後會生成發票。

9.  內容系統:顯示訂單留言等


三、訂單的輸入 

個人認為訂單的輸入(亦可稱之為來源)可分為內部和外部兩種方式:

1.  內部:即自建商城傳輸過來的訂單;

a.  自建商城的訂單系統涉及的其他系統比較多,基本上上圖所示的系統都涉及到了。

b.  自建商城訂單在訂單創建時有著更多的判斷邏輯,如是否需要事先拆單的、優惠資訊是否可用、商品庫存是否滿足要求、會員是否正常等

c.  內部訂單由於存在支付的動作,所以會有多出待付款,待評價這2個狀態,

d.  內部訂單由於涉及支付和營銷,所以對訂單系統的並發能力、負載能力以及支付能力有相當高的要求,每一步都不允許出錯,一旦出錯就意味著營業額的損失和用戶的流失。

e.  訂單數據計算和處理的要求更高,商品多少金額,優惠了多少金額,抵扣了多少金額,實付多少金額等都需要準確計算,在財務報表內能夠清晰展示。

2.  外部:即第三方系統傳輸過來的訂單,一般代表性的就是分銷訂單,如供應商的訂單系統會接收外部系統的訂單,

a.  第三方系統傳輸的訂單,由於訂單比較獨立,所以涉及的相關系統會少很多。

b.  第三方訂單在訂單接收時主要判斷傳輸方是否有資格,商品是否上架狀態,庫存是否滿足,收貨人資訊是否完整等。

c.  由於該類訂單相對來說不需要很高的實時性(意思是該類訂單對於消費者來說已經付款了,現在只是後端處理),所以對介面負載性能等要求相對就沒有那麼高。

d. 訂單數據處理方面,一般都是線下核對賬單,線下結算款項,所以主要在數據記錄和處理的準確性方面有很高要求。

以上就是訂單的輸入,接下來我們聊訂單的處理。


四、 訂單的處理

個人認為主要有3種處理方式:

1. 流轉處理

在訂單系統內,系統會對訂單進行各種邏輯規則判斷,判斷後就會根據業務規則分發訂單,可簡單看示例圖:

基本上訂單的流轉處理是秒級,甚至是毫秒級就能處理完畢的,不能處理的或者處理失敗的都會把訂單歸類到異常訂單。

下面是訂單各狀態的流程圖:

2. 發貨處理

訂單一般流轉到倉庫進行發貨操作,發貨後倉庫會把物流資訊回傳到訂單系統,訂單系統接收消息後會對訂單進行發貨:

a.  如果是內部訂單則訂單狀態直接改變(消費者端也會同步看到訂單狀態變化);

b.  如果是外部訂單則會通過介面告訴第三方系統該訂單的物流資訊;

3. 特殊情況處理

在特殊情況下,就需要對訂單進行人工處理,例如訂單無法流轉到下一級、訂單有備注等。人工處理的結果可能是跟消費者協商後讓其退款,也可能是手動的傳輸訂單等。


五、 訂單的完成

1. 內部訂單:

內部訂單的完成並不在發貨後就完成,一般來說在客戶接收到訂單商品後即算完成。但是對不同類型的商城有所區別:

a. 自營商城:一般客戶收貨後就完成訂單,例如京東。

b. 非自營商城:客戶需要自己點擊確認收貨或經過一段時間後系統自動確認收貨。

2. 外部訂單:

外部訂單系統訂單一般在發貨後就算完成。


六、 訂單管理系統設計想法

1.  在我們設計訂單系統的時候應該先思考下公司業務類型和邏輯,理清業務上訂單流的起止。理清後從訂單源頭開始設計訂單系統:

a. 如果是自建商城類的那麼訂單模塊會涉及到其他系統,需要與其他系統的產品經理(如多人)去討論,如何讓訂單系統與他們負責的系統進行對接;如果是供應鏈類型的訂單系統,則需要考慮如何讓訂單能夠從外部順利傳輸到系統,是我們提供統一標準的API呢還是我們去各自對接第三方系統等等。

b. 考慮輸入方式後,我們就要依據公司業務運營方式來考慮訂單的處理邏輯,訂單進入系統後如何 讓系統自動處理訂單,依據什麼規則;同時也要考慮對異常訂單的處理。

c. 在考慮好訂單處理邏輯後,就要考慮如何輸出訂單,是直接輸出給WMS還是會再輸出給其他ERP等等。由於是自動化的輸出,也就要考慮與其他系統的對接方式。

d. 最後,我們就要用把公司業務代入到系統內,看看是否能行程閉環,是否還有欠缺或者是否遺漏了細節等。

2.   訂單管理系統涉及的其他系統比較多,所以在系統設計上應該具有獨立性、拓展型和準確性,獨立性代表訂單系統的維護或者異常不會影響到其他系統;拓展型代表訂單系統在以後增加功能的時候方便快捷;準確性是指訂單數據涉及到財務方面,所以應該嚴謹和準確。

3.  後台系統訂單頁面的設計:

    a. 訂單列表頁面的設計

根據公司業務需要來設計列表頁展示的數據和布局,以及篩選查詢的關鍵欄位,具體可看示例圖:

     b. 訂單詳情頁的設計

訂單詳情頁一般來說是模塊化的展示設計,訂單基礎資訊、商品資訊、物流資訊、支付資訊等都需要有所區分,這樣設計有利於詳情快速檢視以及在系統研發的過程中讓開發小哥哥不容易搞錯哦,具體可看示例圖:

    c. 訂單規則設計

訂單規則根據業務的大小有簡單和復雜,所以具體需要看業務規模。如果公司現階段剛起步,則訂單規則可直接寫進訂單系統;如起步有一段時間了或者發展比較快,則可事先就開發好訂單規則模塊,以後有新的訂單規則直接通過運營人員設置即可,更加的方便和更快速的適應業務的發展。