當(dāng)原有系統(tǒng)過于冗雜且原有功能不再適用當(dāng)前需求時(shí)，重構(gòu)系統(tǒng)的需求油然而生。于是筆者就和我們分享了訂單管理模塊重構(gòu)的心得。

從事電商行業(yè)，是一個(gè)女裝類自營(yíng)電商平臺(tái)，結(jié)合虛擬試衣技術(shù)，和線下試穿服務(wù)，為用戶提供一種不用出門就可以享受逛店試穿的服務(wù)。

用戶首先購(gòu)買平臺(tái)會(huì)員，在會(huì)員有效期內(nèi)可以在平臺(tái)上將喜歡的衣服加入試衣盒子，盒子滿5件時(shí)可以在不付任何費(fèi)用的情況下寄給用戶，用戶拿到盒子后，試穿這些衣服，再?zèng)Q定是否購(gòu)買，然后將不買的衣服裝入盒子再寄回平臺(tái)，往返包郵。

這篇文章產(chǎn)生的背景，這篇文章是在做訂單管理模塊重構(gòu)的時(shí)候產(chǎn)生的，好像所有系統(tǒng)建立的第一個(gè)版本都是暫時(shí)符合現(xiàn)在版本的APP，然后需求越來越多，不停的往原來的系統(tǒng)上加功能。

有一天終于發(fā)現(xiàn)加不了了，老系統(tǒng)由于可擴(kuò)展性太弱，承受不了奇奇怪怪的功能。

于是開始想辦法一個(gè)模塊一個(gè)模塊地梳理，開始著手重構(gòu)的事情。

但是此時(shí)重構(gòu)已經(jīng)工作量巨大，任何一個(gè)功能都已經(jīng)在線上運(yùn)行，一個(gè)都不能砍，耗時(shí)巨長(zhǎng)。

所以我認(rèn)為，重構(gòu)的事情越早進(jìn)行越好，做不到第一個(gè)版本就規(guī)劃得很清楚的時(shí)候，功能越少，越?jīng)]有歷史遺留問題的時(shí)候，做重構(gòu)的事情越好。所以就借訂單部分重構(gòu)的檔口，來小結(jié)下訂單管理相關(guān)的問題。

重構(gòu)必要性：

1. 當(dāng)前將單一原始單拆分不同狀態(tài)的產(chǎn)品形態(tài)已經(jīng)無法覆蓋所有交易類型的訂單處理。
2. 將訂單拆分為不同類型，不同類型分別定義后臺(tái)狀態(tài)，方便不同業(yè)務(wù)部門有針對(duì)性的處理訂單。
3. 訂單拆分將可擴(kuò)展性增強(qiáng)，隨著業(yè)務(wù)形態(tài)多樣化，可以在不同類型的訂單及其狀態(tài)上優(yōu)化，如“7天無理由”需求可能涉及的“售后”類型的訂單問題。

重構(gòu)步驟：

1. 原始訂單拆分為不同類型的訂單
2. 分別梳理不同類型訂單的流程和相應(yīng)狀態(tài)
3. 類比常規(guī)電商各節(jié)點(diǎn)把控的關(guān)鍵信息，并根據(jù)業(yè)務(wù)特殊性將其移植嫁接

先來梳理下常規(guī)電商的狀態(tài)流轉(zhuǎn)：

1. 待付款：

用戶選好商品下單，但未付款的狀態(tài)。

預(yù)判到用戶下一步可能是付款行為，所以在下單同時(shí)鎖定庫(kù)存，但由于用戶未付款，我們不知道用戶是否會(huì)買下，所以倉(cāng)庫(kù)只是暫時(shí)替用戶留貨，但不會(huì)扣減，當(dāng)用戶付款后，貨才會(huì)真正成為用戶的貨。

但是由于用戶有可能下單但遲遲未付款，被占用的貨不能賣給其他用戶，造成了損失，所以待付款訂單會(huì)有實(shí)效性，只為用戶保留一小段時(shí)間。

這段時(shí)間的長(zhǎng)短根據(jù)不同平臺(tái)有不同的考量，比如外賣平臺(tái)由于時(shí)效性更高，可能只保留15分鐘的訂單；對(duì)于服裝電商對(duì)時(shí)效性要求也是很高，所以通常都會(huì)給出24小時(shí)的鎖定時(shí)間，24小時(shí)后再不付款就自動(dòng)取消訂單了。

2. 待發(fā)貨：用戶付款后，商品未發(fā)貨的狀態(tài)。付款后，庫(kù)存扣減，倉(cāng)庫(kù)備貨。

3. 待收貨：倉(cāng)庫(kù)包好商品并交到快遞小哥手中，訂單開始更新物流信息。

4. 待評(píng)價(jià)：用戶確認(rèn)收貨后，錢款打給賣家，用戶可以評(píng)價(jià)訂單。

5. 售后：用戶付款后，不管貨有沒有發(fā)出，用戶都可以將錢款退回，此時(shí)的退款或退貨申請(qǐng)均作為售后狀態(tài)，創(chuàng)建相應(yīng)的售后工單，會(huì)有對(duì)應(yīng)的售后服務(wù)人員跟進(jìn)。

值得注意的是用戶在每個(gè)訂單狀態(tài)下的退款和退貨行為：

首先，下單未付款狀態(tài)下，用戶可以直接取消訂單，訂單終態(tài)是“已取消”，不會(huì)再流轉(zhuǎn)至后續(xù)的訂單狀態(tài)中；

在付款后，未發(fā)貨的狀態(tài)下，用戶申請(qǐng)退款可以直接退，倉(cāng)庫(kù)攔截出庫(kù)成功就可以直接退款，訂單終態(tài)也是“已取消”或者叫“已關(guān)閉”；

在發(fā)貨后，用戶再取消訂單會(huì)直接走售后流程，創(chuàng)建退換貨單，推到倉(cāng)庫(kù)，倉(cāng)庫(kù)根據(jù)退換貨單給退回的貨品審核并做入庫(kù)處理，再給用戶替換出新貨。

以上是常規(guī)電商的訂單狀態(tài)的梳理，下面來看看我們平臺(tái)的訂單中，哪些流程可以直接抄，哪些流程具有自己的特點(diǎn)。

首先，我們的盒子，是一去一來（平臺(tái) → 用戶 → 平臺(tái)）是一個(gè)正常的流程，因?yàn)槲覀兲峁┑姆?wù)是讓用戶挑選5件衣服，打包成一個(gè)盒子，然后寄回家中試穿，試好后再?zèng)Q定是否購(gòu)買，然后再把不喜歡的衣服退回來，而且往返運(yùn)費(fèi)全免。

經(jīng)過一定的調(diào)研和統(tǒng)計(jì)，最終用戶5件衣服全買的概率是很小的，留貨量在2、3件的用戶居多。

也就是說，退貨的行為是一個(gè)常規(guī)的行為，退貨發(fā)生的概率可以達(dá)到九成，盒子的一個(gè)來回也可能不涉及交易，而交易訂單也有可能不與盒子關(guān)聯(lián)（比如購(gòu)買會(huì)員服務(wù)或其他增值服務(wù)等）。

所以我暫且把盒子訂單和交易訂單分開，此文主要詳細(xì)說盒子訂單。我方的盒子訂單正向流程如下圖所示：

一、待發(fā)貨狀態(tài)

在一般電商中，用戶選貨后進(jìn)入“確認(rèn)訂單”的頁(yè)面，目的是為了讓用戶檢查所選SKU是否有誤，以及給用戶一個(gè)最終決定的過程，因?yàn)樗南乱徊绞侨ジ犊?，要?jǐn)慎為好。當(dāng)用戶確認(rèn)訂單后，生成交易單，同時(shí)鎖定庫(kù)存，用戶在一個(gè)時(shí)間段內(nèi)支付后庫(kù)存扣減，取消訂單或超時(shí)未支付則鎖定庫(kù)存釋放。

與一般電商相同的是，訂單創(chuàng)建后，要占用實(shí)際的庫(kù)存，所以看起來確認(rèn)訂單同時(shí)鎖庫(kù)存的操作是相同的。

但是，訂單創(chuàng)建后用戶不需要支付任何費(fèi)用（因?yàn)楸举|(zhì)是試穿，到貨才可能產(chǎn)生交易），不生成支付單，這是相比于一般電商不同的地方，就是我們?cè)谶@一步?jīng)]有“從支付單創(chuàng)建到支付/不支付”的過程，也就是鎖定庫(kù)存的過程。

因此，我們可以不做鎖定庫(kù)存的操作。

但是這會(huì)遇到的問題是：用戶在選貨到創(chuàng)建訂單那一步，可能會(huì)發(fā)生選到的SKU被別人選走導(dǎo)致缺貨的情況，這樣就要返回重新選擇，再重新生成新的訂單，體驗(yàn)不太友好。

所以在沒有支付訂單的情況下，我們是否需要在生成原始訂單前、在選款結(jié)束到訂單最終確認(rèn)前做庫(kù)存鎖定操作？

鎖的話鎖定多久？會(huì)不會(huì)讓別的想要這件SKU的用戶想選的時(shí)候可用庫(kù)存已經(jīng)沒了，而猶豫半天的用戶最終又沒要，為這部分用戶鎖定庫(kù)存造成了資源的浪費(fèi)？

考慮到我們初期的庫(kù)存很淺，每個(gè)SKU最多5件，用戶有很大的概率會(huì)在確認(rèn)訂單時(shí)，剛選的SKU被另一個(gè)用戶秒下單而缺貨，發(fā)生次數(shù)多了用戶一定會(huì)覺得我們做的是假電商（騙我進(jìn)來看看又不讓我買那種）。

對(duì)于已經(jīng)進(jìn)入確認(rèn)訂單步驟的用戶來說，我們會(huì)先檢驗(yàn)庫(kù)存，保證了他們決定下單的SKU一定有貨；對(duì)于還未進(jìn)入確認(rèn)訂單步驟的用戶來說，沒貨了盡早告訴他們，讓他們心里有數(shù)，不會(huì)進(jìn)到確認(rèn)訂單的步驟，節(jié)約時(shí)間成本，也不會(huì)有太大的負(fù)面情緒。

所以我們決定還是為用戶鎖定庫(kù)存，在選好SKU后進(jìn)入確認(rèn)訂單的頁(yè)面同時(shí)，我們就為用戶鎖定了庫(kù)存。

如果用戶最終確認(rèn)了訂單后，訂單創(chuàng)建，庫(kù)存扣減；用戶如果在確認(rèn)訂單的步驟中放棄了，訂單創(chuàng)建失敗，鎖定庫(kù)存釋放。

訂單創(chuàng)建后，推送至倉(cāng)庫(kù)ERP系統(tǒng)，倉(cāng)庫(kù)確認(rèn)，并將訂單揀貨通知下發(fā)至WMS，由相應(yīng)的揀貨人員揀貨、包裝、稱重等一系列流程后，最終出庫(kù)，交給快遞小哥手中，訂單狀態(tài)變?yōu)椤耙寻l(fā)貨”。

二、已取消狀態(tài)

在商品發(fā)貨前可以取消訂單。訂單創(chuàng)建后創(chuàng)建相應(yīng)的發(fā)貨單，并推送至倉(cāng)庫(kù)WMS，可能已直接發(fā)貨，狀態(tài)未及時(shí)更新，在一般電商中，如果直接給用戶退款，而倉(cāng)庫(kù)已經(jīng)直接發(fā)貨，有可能造成貨款兩失，所以應(yīng)該先暫停訂單出庫(kù)，在倉(cāng)庫(kù)調(diào)度中查詢訂單是否推送至倉(cāng)庫(kù)。

若尚未推送，則停止推送；若已經(jīng)推送，則應(yīng)該到WMS攔截發(fā)貨，暫停出庫(kù)流程；若攔截失敗，則應(yīng)該拒絕“取消訂單”申請(qǐng)，因?yàn)橛唵我呀?jīng)實(shí)際出庫(kù)了。

在我們電商的待發(fā)貨狀態(tài)取消訂單，由于用戶尚未支付，取消訂單也不會(huì)發(fā)生貨款兩失的情況，所以只要是在商品沒有實(shí)際出庫(kù)的情況下，我們都是可以直接暫停的，此時(shí)庫(kù)存會(huì)相應(yīng)的加回來。

以上是訂單出庫(kù)之前的狀態(tài)，接下來會(huì)涉及到的是訂單在路上和反向的過程。

三、已發(fā)貨狀態(tài)

訂單在快遞小哥手中時(shí)會(huì)顯示這個(gè)狀態(tài)，并且根據(jù)發(fā)貨物流單號(hào)獲取物流的動(dòng)態(tài)信息。

一般的電商中，這個(gè)狀態(tài)下用戶可以確認(rèn)收貨，若在物流狀態(tài)更新為“已簽收”后的一段時(shí)間內(nèi)，比如9天未確認(rèn)收貨，訂單會(huì)自動(dòng)確認(rèn)收貨。

我們平臺(tái)的訂單不會(huì)給用戶主動(dòng)確認(rèn)收貨，因?yàn)閷?duì)于用戶來說，他們只是叫了幾件衣服到家試穿，購(gòu)買行為是后置的。

如果用戶遲遲未購(gòu)買也未寄回，會(huì)造成資源大大的浪費(fèi)，而且服裝容易過季，超過半個(gè)月再返架，返架前還需要運(yùn)送、審核、清洗等一系列流程，此時(shí)的服裝不一定在售了。

所以我們會(huì)給用戶一個(gè)比較短的時(shí)間試穿，并且這個(gè)時(shí)間以物流信息“已簽收”為準(zhǔn)。

但是由于我們接了第三方物流查詢接口，獲取的物流動(dòng)態(tài)做不到實(shí)時(shí)更新，而且非常有可能是快遞小哥送到了但是用戶沒時(shí)間取貨，那如果直接按照物流“已簽收”狀態(tài)開始倒計(jì)時(shí)，用戶也不太能接受。

所以我們定的時(shí)間是“從物流更新為“已簽收”的次日凌晨0點(diǎn)開始的72小時(shí)”為用戶可以試穿的時(shí)間，超過這個(gè)時(shí)間若未將衣服買下或退回，則訂單逾期，要有相應(yīng)的記錄，給我們做用戶分層和風(fēng)控中心做參考信息。

因此，逾期的訂單只要一旦逾期了，就會(huì)一直跟著這筆訂單，未必對(duì)用戶可見，一方面對(duì)那些真的有特殊原因不小心逾期了（比如說，工作日家里沒人，只能預(yù)約到周末，但是到了周末就超時(shí)了），此時(shí)如果用戶看到自己的逾期不良記錄可能會(huì)產(chǎn)生消極的情緒；另一方面對(duì)于那些惡意買家，給他看到逾期也不會(huì)改變什么，所以逾期的記錄只要內(nèi)部工作人員可見即可。

從本質(zhì)上來說，一般電商的“確認(rèn)收貨”基本等于我們的“購(gòu)買”，因?yàn)橥瑯邮谴_認(rèn)把錢款付給賣家，一般電商是支付平臺(tái)把錢打給賣家，我們是實(shí)際收到用戶的款項(xiàng)。

四、已付款狀態(tài)

如上所說，我們的購(gòu)買行為是后置的，用戶只有自己實(shí)際拿到貨時(shí)才決定是否購(gòu)買，所以此時(shí)交易訂單創(chuàng)建同時(shí)不需要鎖定庫(kù)存，這是跟一般電商不太一樣的地方。

我們?cè)瓉硎遣幌胱觥敖灰子唵巍边@件事的，因?yàn)楫?dāng)時(shí)希望的是用戶盡快地進(jìn)入付款的流程，多一步操作搞不好就不買了，這是老板提出的論調(diào)，我很理解老板的擔(dān)心，但這一步存在一定有它的理由：

一般電商需要這一步除了要鎖定庫(kù)存外，還要鎖定商品價(jià)格、優(yōu)惠信息，這兩個(gè)信息時(shí)效性很高，即便我們這步不用鎖庫(kù)存，但也要鎖定價(jià)格、優(yōu)惠信息，很有可能用戶下單寄出時(shí)是這個(gè)價(jià)格，到手后要付款了是一個(gè)價(jià)，實(shí)際支付的時(shí)候又是另一個(gè)價(jià)，支付系統(tǒng)也不知道收哪個(gè)。

而且我們有些優(yōu)惠信息時(shí)效性更高，可能1分鐘后不真的付款，不創(chuàng)建交易單來鎖定的話，萬一由于網(wǎng)絡(luò)原因支付失敗了，返回再重新進(jìn)入交易流程，優(yōu)惠信息沒了，豈不是很不開心，后臺(tái)開發(fā)人員在系統(tǒng)設(shè)計(jì)時(shí)也會(huì)創(chuàng)建交易訂單，只是是否對(duì)用戶可見。

而且，一般電商都有創(chuàng)建交易單的操作，用戶也已經(jīng)被市場(chǎng)教育得很認(rèn)可了，沒有必要再做改變。

接下來，就進(jìn)入了訂單的反向的流程。如前文提到的，這樣區(qū)分是向倉(cāng)庫(kù)方面靠攏，倉(cāng)庫(kù)的各方面業(yè)務(wù)都比較完善，比如反向流程可能不僅僅是退貨，后續(xù)還會(huì)有換貨，所有的套路都很完善，所以就撿成熟的方案用起來。下圖是反向訂單流程：

五、待寄回

在我們的平臺(tái)中，用戶付好款后（或一件都看不上的），可以直接在APP中預(yù)約快遞，只需要填寫上門取件地址和時(shí)間，就會(huì)有快遞小哥上門取件，取件后，用戶可以繼續(xù)叫盒子，保證用戶一次只能叫一個(gè)盒子，但是再會(huì)員有效期內(nèi)可以叫多次。

在預(yù)約快遞，到快遞小哥實(shí)際攬件的狀態(tài)為“待寄回”狀態(tài)。從這里開始，訂單開始走反向流程，即一般電商中的退換貨/售后流程。

用戶將不需要買的商品勾選好后，預(yù)約快遞，選擇取件時(shí)間和地址，退貨單創(chuàng)建，同時(shí)創(chuàng)建物流單。退貨單創(chuàng)建同時(shí)推送至倉(cāng)庫(kù)ERP系統(tǒng)，倉(cāng)庫(kù)操作員根據(jù)退貨單號(hào)、物流單號(hào)、應(yīng)退商品等信息進(jìn)行驗(yàn)貨、清洗以及入庫(kù)操作，平臺(tái)根據(jù)ERP對(duì)商品的審核狀態(tài)將訂單置為“已完成”。

在退貨單創(chuàng)建前，也就是成功預(yù)約快遞之前，都是可以購(gòu)買商品的，并且可以分多次購(gòu)買，因?yàn)榘l(fā)現(xiàn)女生的購(gòu)物習(xí)慣很不確定，5件衣服中經(jīng)常會(huì)有個(gè)一兩件衣服想買但是又不太舍得買，但是放了幾天后想想還是買下吧，有點(diǎn)像淘寶退貨，申請(qǐng)退貨后還是支持用戶取消申請(qǐng)的。

此時(shí)一個(gè)盒子訂單就可能與多個(gè)交易相關(guān)聯(lián)，這也是把盒子訂單和交易訂單分開的原因，業(yè)務(wù)的可擴(kuò)展性增強(qiáng)。

六、寄回中

快遞小哥取件后，到快遞被倉(cāng)庫(kù)簽收的過程為“寄回中”。

七、待審核/異常/已完成

倉(cāng)庫(kù)簽收退回貨品，到驗(yàn)貨完成之前，訂單狀態(tài)為“待審核”。

商品從用戶手中退回的時(shí)候不一定全為完好無損的，可能是奇形怪狀的，有的可能沾有口紅印子，有的起球嚴(yán)重。

完好無損的貨品是經(jīng)過清洗、熨燙以及再次包裝的操作后可以直接入庫(kù)變?yōu)榭射N售庫(kù)存；奇形怪狀的貨品經(jīng)過審核后確定無法還原后，不能入庫(kù)變?yōu)榭射N售狀態(tài)，只能進(jìn)入次品倉(cāng)。

當(dāng)然相信大部分用戶都是正常用戶，退回的商品基本都是良品，少數(shù)用戶會(huì)退回次品，也很少有平臺(tái)會(huì)跟消費(fèi)者扯皮，通常都是自認(rèn)倒霉，只是完善的電商平臺(tái)會(huì)有自己的風(fēng)控系統(tǒng)，某個(gè)用戶退回的次品過多，協(xié)商未果，就認(rèn)為這個(gè)用戶信用不好，或是拉黑等等，他們以后的購(gòu)物也會(huì)受到影響。

當(dāng)然不管是良品還是次品，我們都需要得到一個(gè)統(tǒng)計(jì)的結(jié)果，退貨單中每一件商品都是良品時(shí)，訂單自動(dòng)完成；有次品出現(xiàn)時(shí)，訂單會(huì)先到“異常”狀態(tài)，由客服去協(xié)商了解情況后，手動(dòng)將訂單完成，并填寫備注。

訂單的各個(gè)狀態(tài)間的流轉(zhuǎn)就是以上了，總的來說自己摸索著做還是有些難度，但是工作了這兩年現(xiàn)在才算是有了點(diǎn)步入專業(yè)的感覺，不是說做出來的系統(tǒng)有多么專業(yè)，而是說在摸chao索xi的過程中做到了仔細(xì)思考，為什么別人這么設(shè)計(jì)，這一步為什么不能直接移植過來？要做出哪些改變？這樣設(shè)計(jì)是最優(yōu)解決方案嗎？是否還有更完善的方案等等？這才是產(chǎn)品經(jīng)理應(yīng)該做到的工作吧。希望以后多做出這些總結(jié)，然后跟大家一起成bao長(zhǎng)fu！

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

題圖來自Unsplash，基于CC0協(xié)議。