本文主要講述了在傳統電商企業(yè)中，訂單系統應承載的角色，就訂單系統所包含的主要功能模塊梳理了設計思路，并對訂單系統未來(lái)的發(fā)展做了一些思考。
1. 訂單系統在企業(yè)中的角色
在搭建企業(yè)訂單系統之前，需要先梳理企業(yè)整體業(yè)務(wù)系統之間的關(guān)系和訂單系統上下游關(guān)系，只有劃分清業(yè)務(wù)系統邊界，才能確定訂單系統的職責與功能，進(jìn)而保證各系統之間高效簡(jiǎn)潔的工作。
2. 訂單系統與各業(yè)務(wù)系統的關(guān)系
(1)對外系統：
所有給企業(yè)外部用戶(hù)使用的系統都在這一層，包括官網(wǎng)、普通用戶(hù)使用的c端，還包括給商戶(hù)使用的商家后臺和在各個(gè)銷(xiāo)售渠道進(jìn)行分銷(xiāo)的系統，比如與銀行信用卡中心合作、微信合作在合作商的平臺露出本企業(yè)的產(chǎn)品。這類(lèi)系統站在與客戶(hù)接觸的最前線(xiàn)，是公司實(shí)現商業(yè)模式的橋頭堡。
(2)管理中后臺：
每個(gè)c端的業(yè)務(wù)形態(tài)都會(huì )有一個(gè)對應的系統模塊，如負責管理平臺交易的訂單系統，管理優(yōu)惠信息的促銷(xiāo)系統，管理平臺所有產(chǎn)品的產(chǎn)品系統，以及管理所有對外系統顯示內容的內容系統等。
(3)公共服務(wù)系統：
隨著(zhù)企業(yè)的發(fā)展，信息化建設到達一定程度后，企業(yè)需要將通用功能服務(wù)化、平臺化，以保證應用架構的合理性，提升服務(wù)效率。這類(lèi)系統主要給其他應用系統提供基礎服務(wù)能力支持。
3. 訂單系統上下游關(guān)系
由此可見(jiàn)，訂單系統對上接收用戶(hù)信息，將用戶(hù)信息轉化為產(chǎn)品訂單，同時(shí)管理并跟蹤訂單信息和數據，承載了公司整個(gè)交易線(xiàn)的重要對客環(huán)節。對下則銜接產(chǎn)品系統、促銷(xiāo)系統、倉儲系統、會(huì )員系統、支付系統等，對整個(gè)電商平臺起著(zhù)承上啟下的作用。
5. 訂單系統的業(yè)務(wù)架構
(1)訂單服務(wù)
該模塊的主要功能是用戶(hù)日常使用的服務(wù)和頁(yè)面，主要有訂單列表、訂單詳情、在線(xiàn)下單等，還包括為公共業(yè)務(wù)模塊提供的多維度訂單數據服務(wù)。
(2)訂單邏輯
訂單系統的核心，起著(zhù)至關(guān)重要的作用，在訂單系統負責管理訂單創(chuàng )建、訂單支付、訂單生產(chǎn)、訂單確認、訂單完成、取消訂單等訂單流程。還涉及到復雜的訂單狀態(tài)規則、訂單金額計算規則以及增減庫存規則等。在4節核心功能設計中會(huì )重點(diǎn)來(lái)說(shuō)。
(3)底層服務(wù)
信息化建設達到一定程度的企業(yè)，一般會(huì )將公司公共服務(wù)模塊化，比如：產(chǎn)品，會(huì )構建對應的產(chǎn)品系統，代碼、數據庫，接口等相對獨立。但是，這也帶來(lái)了一個(gè)問(wèn)題，比如：訂單創(chuàng )建的場(chǎng)景下需要獲取的信息分散在各個(gè)系統。
如果需要從各個(gè)公共服務(wù)系統調用：一是會(huì )花費大量時(shí)間，二是代碼的維護成本非常高。因此，訂單系統接入所需的公共服務(wù)模塊接口，在訂單系統即可完成對接公共系統的服務(wù)。
訂單系統核心功能
1. 訂單中所包含的內容信息
為了使訂單系統能夠對訂單進(jìn)行高效、精準的管理和跟蹤，訂單會(huì )儲存關(guān)于產(chǎn)品、優(yōu)惠、用戶(hù)、支付信息等一系列的訂單實(shí)時(shí)數據，來(lái)和下游系統，如：促銷(xiāo)、倉儲、物流進(jìn)行交互。
以一個(gè)通用b2c商城的訂單為例，梳理其包含的信息如下：
這里要注意的是訂單類(lèi)型，隨著(zhù)平臺業(yè)務(wù)的不斷發(fā)展，品類(lèi)豐富、交易方式豐富后，需要對訂單進(jìn)行多維度的分類(lèi)管理，同時(shí)訂單類(lèi)型利于訂單系統的擴展性。每種訂單類(lèi)型將會(huì )對應一套流程及一套狀態(tài)，便于對訂單進(jìn)行分類(lèi)管理和復用。
2. 流程引擎
流程是指從平臺角度出發(fā)，將訂單從創(chuàng )建到完成的整個(gè)流轉過(guò)程進(jìn)行抽象，從而行程了一套標準流程規則。而不同的產(chǎn)品類(lèi)型或交易類(lèi)型在系統中的流程會(huì )千差萬(wàn)別，因此為了方便對訂單流程進(jìn)行管理，會(huì )組建流程引擎模塊。
每套訂單流程中會(huì )包含正向流程及逆向流程，正向流程可以比作一次順利的網(wǎng)購體驗過(guò)程中，后臺系統之間的信息流轉。逆向流程則是修改訂單、取消訂單、退款、退貨等各種動(dòng)作引起的后臺系統流程，同時(shí)每個(gè)流程觸發(fā)的條件又可分為系統觸發(fā)和人工觸發(fā)兩種場(chǎng)景。
(1)正向流程
以一個(gè)通用b2c商城的訂單系統為例，根據其實(shí)際業(yè)務(wù)場(chǎng)景，其訂單流程可抽象為5大步驟：訂單創(chuàng )建>訂單支付>訂單生產(chǎn)>訂單確認>訂單完成。
而每個(gè)步驟的背后，訂單是如何在多系統之間交互流轉的，可概括如下圖：
訂單創(chuàng )建：
用戶(hù)下單后，系統需要生成訂單，此時(shí)需要先獲取下單中涉及的商品信息，然后獲取該商品所涉及到的優(yōu)惠信息，如果商品不參與優(yōu)惠信息，則無(wú)此環(huán)節。
接著(zhù)獲取該賬戶(hù)的會(huì )員權益，這里要注意的是：優(yōu)惠信息與會(huì )員權益的區別，比如：商品滿(mǎn)減是優(yōu)惠信息，super會(huì )員全場(chǎng)9.8折指的是會(huì )員權益，一個(gè)是針對商品，另一個(gè)是針對賬戶(hù)。其次就是優(yōu)惠活動(dòng)的疊加規則和優(yōu)先級規則等。
增減庫存規則是指訂單中的商品，何時(shí)從倉儲系統中對相應商品庫存進(jìn)行扣除，目前主流有兩種方式：
下單減庫存——即用戶(hù)下單成功時(shí)減少庫存數量
優(yōu)勢： 用戶(hù)體驗友好，系統邏輯簡(jiǎn)潔;
缺點(diǎn)： 會(huì )導致惡意下單或下單后卻不買(mǎi)，使得真正有需求的用戶(hù)無(wú)法購買(mǎi)，影響真實(shí)銷(xiāo)量;
解決辦法：
設置訂單有效時(shí)間，若訂單創(chuàng )建成功n分鐘不付款，則訂單取消，庫存回滾;
限購，用各種條件來(lái)限制買(mǎi)家的購買(mǎi)件數，比如一個(gè)賬號、一個(gè)ip，只能買(mǎi)一件;
風(fēng)控，從技術(shù)角度進(jìn)行判斷，屏蔽惡意賬號，禁止惡意賬號購買(mǎi)。
付款減庫存——即用戶(hù)支付完成并反饋給平臺后再減少庫存數量
優(yōu)勢： 減少無(wú)效訂單帶來(lái)的資源損耗;
缺點(diǎn)： 因第三方支付返回結果存在時(shí)差，同一時(shí)間多個(gè)用戶(hù)同時(shí)付款成功，會(huì )導致下單數目超過(guò)庫存，商家庫存不足容易引發(fā)斷貨和投訴，成本增加。
解決辦法：
付款前再次校驗庫存，如確認訂單要付款時(shí)再驗證一次，并友好提示用戶(hù)庫存不足;
增加提示信息：在商品詳情頁(yè)，訂單步驟頁(yè)面提示不及時(shí)付款，不能保證有庫存等。
綜上所述，兩種方式各有優(yōu)缺點(diǎn)，因此，需結合實(shí)際場(chǎng)景進(jìn)行考慮，如：秒殺、搶購、促銷(xiāo)活動(dòng)等，可使用下單減庫存的方式。而對于產(chǎn)品庫存量大，并發(fā)流量沒(méi)有那么強的產(chǎn)品使用付款減庫存的方式。
將兩種方式帶入到銷(xiāo)售場(chǎng)景中，關(guān)聯(lián)商品類(lèi)型、促銷(xiāo)類(lèi)型、供需關(guān)系等，靈活使用，以充分發(fā)揮計算機系統的優(yōu)勢。
訂單支付：
用戶(hù)支付完訂單后，需要獲取訂單的支付信息，包括支付流水號、支付時(shí)間等。支付完訂單接著(zhù)就是等商家發(fā)貨，但在發(fā)貨過(guò)程中，根據平臺業(yè)務(wù)模式的不同，可能會(huì )涉及到訂單的拆分。
訂單拆分一般分兩種：
一種是用戶(hù)挑選的商品來(lái)自于不同渠道(自營(yíng)與商家，商家與商家);
另一種是在sku層面上拆分訂單：不同倉庫，不同運輸要求的sku，包裹重量體積限制等因素需要將訂單拆分。
訂單拆分也是一個(gè)相對獨立的模塊，這里就不詳細描述了。
訂單生產(chǎn)： 訂單生產(chǎn)，是指產(chǎn)品從企業(yè)到用戶(hù)這一流程的概述。如電商平臺中，商家發(fā)貨過(guò)程已有一個(gè)標準化的流程，訂單內容會(huì )發(fā)送到倉庫，倉庫對商品進(jìn)行打單、揀貨、包裝、交接快遞進(jìn)行配送。
訂單確認： 收到貨后，訂單系統需要在快遞被簽收后提醒用戶(hù)對商品做評價(jià)。這里要注意，確認收到貨不代表交易成功，相反是售后服務(wù)的開(kāi)始。
訂單完成： 訂單完成是指在收到貨x天的狀態(tài)，此時(shí)訂單不在售后的支持時(shí)間范圍內。到此，一個(gè)訂單的正向流程就算走完了。
(2)逆向流程
上面說(shuō)到逆向流程是各種修改訂單、取消訂單、退款、退貨等操作，需要梳理清楚這些流程與正向流程的關(guān)系，才能理清訂單系統完整的訂單流程。
訂單修改： 可梳理訂單內信息，根據信息關(guān)聯(lián)程度及業(yè)務(wù)訴求，設定訂單的可修改范圍是什么，比如：客戶(hù)下單后，想修改收貨人地址及電話(huà)。此時(shí)只需對相應數據進(jìn)行更新即可。
訂單取消： 用戶(hù)提交訂單后沒(méi)有進(jìn)行支付操作，此時(shí)用戶(hù)原則上屬于取消訂單，因為還未付款，則比較簡(jiǎn)單，只需要將原本提交訂單時(shí)扣減的庫存補回，促銷(xiāo)優(yōu)惠中使用的優(yōu)惠券，權益等視平臺規則，進(jìn)行相應補回。
退款： 用戶(hù)支付成功后，客戶(hù)發(fā)出退款的訴求后，需商戶(hù)進(jìn)行退款審核，雙方達成一致后，系統應以退款單的形式完成退款，關(guān)聯(lián)原訂單數據。因商品無(wú)變化，所以不許考慮與庫存系統的交互，僅需考慮促銷(xiāo)系統及支付系統交互即可。
退貨： 用戶(hù)支付成功后，客戶(hù)發(fā)出退貨的訴求后，需商戶(hù)進(jìn)行退款審核，雙方達成一致后，需對庫存系統進(jìn)行補回，支付系統、促銷(xiāo)系統以退款單形式完成退款。最后，在退款/退貨流程中，需結合平臺業(yè)務(wù)場(chǎng)景，考慮優(yōu)惠分攤的邏輯，在發(fā)生退款/退貨時(shí)，優(yōu)惠該如何退回的處理規則和流程。
(3)狀態(tài)機
狀態(tài)機是管理訂單狀態(tài)邏輯的工具。狀態(tài)機可歸納為3個(gè)要素，即現態(tài)、動(dòng)作、次態(tài)。
現態(tài)： 是指當前所處的狀態(tài)。
動(dòng)作： 動(dòng)作執行完畢后，可以遷移到新的狀態(tài)，也可以仍舊保持原狀態(tài)。
次態(tài)： 動(dòng)作滿(mǎn)足后要遷往的新?tīng)顟B(tài)，“次態(tài)”是相對于“現態(tài)”而言的，“次態(tài)”一旦被激活，就轉變成新的“現態(tài)”了。
狀態(tài)機的設計需要結合平臺實(shí)際業(yè)務(wù)場(chǎng)景，將狀態(tài)間的切換細化成了執行了某個(gè)動(dòng)作。
以一個(gè)b2c商城的訂單系統舉例如下：
訂單系統為了高效的對訂單進(jìn)行跟蹤和管理，會(huì )對訂單流程當中的關(guān)鍵節點(diǎn)，抽象出訂單狀態(tài)。而訂單狀態(tài)從不同用戶(hù)的角度可分為，系統訂單狀態(tài)、商家訂單狀態(tài)、買(mǎi)家訂單狀態(tài)等。
對于訂單系統來(lái)說(shuō)，訂單狀態(tài)細分的顆粒度越細、越明確，訂單系統管理的精度和可靠性就越高，比如：在待付款和待發(fā)貨兩個(gè)狀態(tài)中，訂單系統后臺會(huì )細分為訂單超時(shí)取消、訂單支付失敗、訂單付款完成等。
因此，訂單狀態(tài)模塊中，通常會(huì )維護狀態(tài)映射表，以不同的用戶(hù)角色對系統訂單狀態(tài)進(jìn)行重新劃分，以滿(mǎn)足不同用戶(hù)的需求。
除此以外，隨著(zhù)電商平臺的不斷發(fā)展，不同的業(yè)務(wù)類(lèi)型，所對應的訂單狀態(tài)都會(huì )有所區別。所以，訂單系統中一般會(huì )儲存多套狀態(tài)機，以滿(mǎn)足不同的訂單類(lèi)型來(lái)使用。
訂單系統的發(fā)展
訂單系統的主體框架，和主要業(yè)務(wù)模塊已基本講完，那么隨著(zhù)企業(yè)的發(fā)展，業(yè)務(wù)量和業(yè)務(wù)形式不斷變化，企業(yè)有可能形成多個(gè)訂單系統并存以滿(mǎn)足不同的業(yè)務(wù)需要的情況。
業(yè)務(wù)系統架構如下：
這種狀況的出現，將會(huì )給平臺帶來(lái)非常大的發(fā)展瓶頸，如：
三個(gè)訂單系統，每個(gè)訂單系統處理不同類(lèi)型的訂單，沒(méi)有統一的訂單銷(xiāo)量、訂單狀態(tài)信息，網(wǎng)站前臺對訂單的狀態(tài)展示與控制不統一，只能是在網(wǎng)站前臺會(huì )員中心硬代碼維護一套面向會(huì )員的統一訂單明細與狀態(tài)數據。而無(wú)線(xiàn)側上線(xiàn)后，由于不了解前臺網(wǎng)站會(huì )員中心的訂單狀態(tài)管理邏輯，所以需要把前臺網(wǎng)站的訂單明細及狀態(tài)管理再在無(wú)線(xiàn)應用側再實(shí)現一遍。
三套后臺訂單系統與公共業(yè)務(wù)系統如會(huì )員中心、支付與財務(wù)、促銷(xiāo)工具、客戶(hù)分單等系統都需要對接一遍，公共業(yè)務(wù)處理邏輯不統一，一旦邏輯變更多個(gè)系統統一個(gè)接口都要修改一遍，接口的重復維護開(kāi)發(fā)工作量大。
訂單開(kāi)發(fā)目前分到事業(yè)部，各個(gè)事業(yè)部只會(huì )考慮自己的邏輯，不會(huì )考慮公共架構，只會(huì )越走越遠。碰到像無(wú)線(xiàn)這樣的項目，需要對接各個(gè)事業(yè)部，無(wú)線(xiàn)側應用上線(xiàn)進(jìn)展慢。
因此未來(lái)的訂單系統可拆分為訂單中心與業(yè)務(wù)訂單系統兩個(gè)模塊，以管理公司所有訂單數據，并為各個(gè)模塊提供統一服務(wù)。
業(yè)務(wù)系統架構如下：
最后
對于企業(yè)訂單系統的搭建，并不是要做的大而全、也不是要小而精。而需要結合市場(chǎng)、公司、業(yè)務(wù)的實(shí)際情況來(lái)最終制定系統設計方案和產(chǎn)品迭代計劃。
最終，和公司整體發(fā)展相互協(xié)調，相輔相成。
本文來(lái)源于羅戈網(wǎng)，不代表本站觀(guān)點(diǎn)，如有侵權可聯(lián)系刪除，文章所用圖片來(lái)源于網(wǎng)絡(luò )，文章圖片如有侵權可聯(lián)系刪除。