關于訂單管理系統(OMS),你需要知道這些
編輯導讀:訂單管理系統,是整個電商系統的核心系統之一,有一定的復雜性。本文將從六個方面,圍繞訂單管理系統展開分析,希望對你有幫助。
一、 關于訂單管理系統
訂單管理系統即處理訂單的系統,主要管理訂單的輸入,處理,輸出。其在一般電商系統中或在有交易功能的系統中,都是核心系統/功能之一,有一定的復雜度;但是雖然復雜,并不代表理解起來困難。
關于商品的文章里面,我們已經從商品的輸入、維護、輸出的流程來介紹了商品系統,那訂單也一樣,我們本文把訂單看成一個流程即訂單流來理解。
二、 訂單管理系統與整體系統的關系
訂單系統會與購物車、商品系統,營銷系統、會員系統、支付系統、物流系統、倉庫系統、財務系統、內容系統,具體請看示例圖:
-
- 購物車:個人認為是訂單的起點,商品會被加入購物車,然后會被提交。
- 商品系統:在提交訂單頁面會看到該訂單所包含的商品信息,例如商品名稱、所購買數量、價格、售后信息等。
- 營銷系統:會顯示商品是否優惠信息,例如滿減、優惠券。
- 會員系統:會顯示該會員是否有基于會員等級的折扣信息(如淘寶的88會員),或是否有可抵扣金額的會員點數(如京豆);會顯示該會員下面的收貨地址信息、也會顯示該會員下面是否有充值卡、運費券等。
- 倉庫系統:基于收貨地址信息顯示發貨倉庫,自提地點等,并且訂單最終會流轉到該系統進行發貨操作。
- 支付系統:顯示支付方式(如貨到付款、在線支付等)、并且在支付的時候計算該會員實際應付的金額,以及顯示銀行卡信息等。
- 物流系統:顯示配送時間、配送方式、運費等,并且在訂單發貨后會顯示實際的配送路徑。
- 財務系統:顯示開票信息等,在訂單完成后會生成發票。
- 內容系統:顯示訂單留言等。
三、訂單的輸入
個人認為訂單的輸入(亦可稱之為來源)可分為內部和外部兩種方式:
1. 內部:即自建商城傳輸過來的訂單
- 自建商城的訂單系統涉及的其他系統比較多,基本上上圖所示的系統都涉及到了。
- 自建商城訂單在訂單創建時有著更多的判斷邏輯,如是否需要事先拆單的、優惠信息是否可用、商品庫存是否滿足要求、會員是否正常等。
- 內部訂單由于存在支付的動作,所以會有多出待付款,待評價這2個狀態。
- 內部訂單由于涉及支付和營銷,所以對訂單系統的并發能力、負載能力以及支付能力有相當高的要求,每一步都不允許出錯,一旦出錯就意味著營業額的損失和用戶的流失。
- 訂單數據計算和處理的要求更高,商品多少金額,優惠了多少金額,抵扣了多少金額,實付多少金額等都需要準確計算,在財務報表內能夠清晰展示。
2. 外部:即第三方系統傳輸過來的訂單
一般代表性的就是分銷訂單,如供應商的訂單系統會接收外部系統的訂單。
- 第三方系統傳輸的訂單,由于訂單比較獨立,所以涉及的相關系統會少很多。
- 第三方訂單在訂單接收時主要判斷傳輸方是否有資格,商品是否上架狀態,庫存是否滿足,收貨人信息是否完整等。
- 由于該類訂單相對來說不需要很高的實時性(意思是該類訂單對于消費者來說已經付款了,現在只是后端處理),所以對接口負載性能等要求相對就沒有那么高。
- 訂單數據處理方面,一般都是線下核對賬單,線下結算款項,所以主要在數據記錄和處理的準確性方面有很高要求。
以上就是訂單的輸入,接下來我們聊訂單的處理。
四、 訂單的處理
個人認為主要有3種處理方式:
1. 流轉處理
在訂單系統內,系統會對訂單進行各種邏輯規則判斷,判斷后就會根據業務規則分發訂單,可簡單看示例圖:
基本上訂單的流轉處理是秒級,甚至是毫秒級就能處理完畢的,不能處理的或者處理失敗的都會把訂單歸類到異常訂單。
下面是訂單各狀態的流程圖:
2. 發貨處理
訂單一般流轉到倉庫進行發貨操作,發貨后倉庫會把物流信息回傳到訂單系統,訂單系統接收消息后會對訂單進行發貨:
- 如果是內部訂單則訂單狀態直接改變(消費者端也會同步看到訂單狀態變化);
- 如果是外部訂單則會通過接口告訴第三方系統該訂單的物流信息;
3. 特殊情況處理
在特殊情況下,就需要對訂單進行人工處理,例如訂單無法流轉到下一級、訂單有備注等。人工處理的結果可能是跟消費者協商后讓其退款,也可能是手動的傳輸訂單等。
五、 訂單的完成
1. 內部訂單
內部訂單的完成并不在發貨后就完成,一般來說在客戶接收到訂單商品后即算完成。
但是對不同類型的商城有所區別:
- 自營商城:一般客戶收貨后就完成訂單,例如京東。
- 非自營商城:客戶需要自己點擊確認收貨或經過一段時間后系統自動確認收貨。
2. 外部訂單
外部訂單系統訂單一般在發貨后就算完成。
六、 訂單管理系統設計想法
在我們設計訂單系統的時候,應該先思考下公司業務類型和邏輯,理清業務上訂單流的起止。
理清后從訂單源頭開始設計訂單系統:
- 如果是自建商城類的那么訂單模塊會涉及到其他系統,需要與其他系統的產品經理(如多人)去討論,如何讓訂單系統與他們負責的系統進行對接;如果是供應鏈類型的訂單系統,則需要考慮如何讓訂單能夠從外部順利傳輸到系統,是我們提供統一標準的API呢還是我們去各自對接第三方系統等等。
- 考慮輸入方式后,我們就要依據公司業務運營方式來考慮訂單的處理邏輯,訂單進入系統后如何 讓系統自動處理訂單,依據什么規則;同時也要考慮對異常訂單的處理。
- 在考慮好訂單處理邏輯后,就要考慮如何輸出訂單,是直接輸出給WMS還是會再輸出給其他ERP等等。由于是自動化的輸出,也就要考慮與其他系統的對接方式。
- 最后,我們就要用把公司業務代入到系統內,看看是否能行程閉環,是否還有欠缺或者是否遺漏了細節等。
訂單管理系統涉及的其他系統比較多,所以在系統設計上應該具有獨立性、拓展型和準確性,獨立性代表訂單系統的維護或者異常不會影響到其他系統;拓展型代表訂單系統在以后增加功能的時候方便快捷;準確性是指訂單數據涉及到財務方面,所以應該嚴謹和準確。
后臺系統訂單頁面的設計:
1)訂單列表頁面的設計
根據公司業務需要來設計列表頁展示的數據和布局,以及篩選查詢的關鍵字段,具體可看示例圖:
2)訂單詳情頁的設計
訂單詳情頁一般來說是模塊化的展示設計,訂單基礎信息、商品信息、物流信息、支付信息等都需要有所區分,這樣設計有利于詳情快速查看以及在系統研發的過程中讓開發小哥哥不容易搞錯哦,具體可看示例圖:
3)訂單規則設計
訂單規則根據業務的大小有簡單和復雜,所以具體需要看業務規模。
如果公司現階段剛起步,則訂單規則可直接寫進訂單系統;如起步有一段時間了或者發展比較快,則可事先就開發好訂單規則模塊,以后有新的訂單規則直接通過運營人員設置即可,更加的方便和更快速地適應業務的發展。
本文由 @Milomasson 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自 Unsplash,基于 CC0 協議
關于商品的文章里面,我們已經從商品的輸入、維護、輸出的流程來介紹了商品系統,那訂單也一樣,我們本文把訂單看成一個流程即訂單流來理解。
——商品的文章在哪?希望能拜讀
最近在看管家婆的云ERP設計的還是不錯的,相對標準化。給你推薦一下
銷售訂單與WMS之間不應該有個調度層嗎??
是的,調度層可以是ERP(里面含訂單模塊),可以是單獨的OMS,也可以是在WMS集成的OMS系統。這篇文章是單獨的OMS。