中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

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

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

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

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

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

于是開始想辦法一個模塊一個模塊地梳理，開始著手重構的事情。

但是此時重構已經(jīng)工作量巨大，任何一個功能都已經(jīng)在線上運行，一個都不能砍，耗時巨長。

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

重構必要性：

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

重構步驟：

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

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

1. 待付款：

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

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

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

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

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

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

4. 待評價：用戶確認收貨后，錢款打給賣家，用戶可以評價訂單。

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

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

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

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

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

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

首先，我們的盒子，是一去一來（平臺 → 用戶 → 平臺）是一個正常的流程，因為我們提供的服務是讓用戶挑選5件衣服，打包成一個盒子，然后寄回家中試穿，試好后再決定是否購買，然后再把不喜歡的衣服退回來，而且往返運費全免。

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

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

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

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

在一般電商中，用戶選貨后進入“確認訂單”的頁面，目的是為了讓用戶檢查所選SKU是否有誤，以及給用戶一個最終決定的過程，因為他的下一步是去付款，要謹慎為好。當用戶確認訂單后，生成交易單，同時鎖定庫存，用戶在一個時間段內(nèi)支付后庫存扣減，取消訂單或超時未支付則鎖定庫存釋放。

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

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

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

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

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

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

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

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

所以我們決定還是為用戶鎖定庫存，在選好SKU后進入確認訂單的頁面同時，我們就為用戶鎖定了庫存。

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

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

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

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

若尚未推送，則停止推送；若已經(jīng)推送，則應該到WMS攔截發(fā)貨，暫停出庫流程；若攔截失敗，則應該拒絕“取消訂單”申請，因為訂單已經(jīng)實際出庫了。

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

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

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

訂單在快遞小哥手中時會顯示這個狀態(tài)，并且根據(jù)發(fā)貨物流單號獲取物流的動態(tài)信息。

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

我們平臺的訂單不會給用戶主動確認收貨，因為對于用戶來說，他們只是叫了幾件衣服到家試穿，購買行為是后置的。

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

所以我們會給用戶一個比較短的時間試穿，并且這個時間以物流信息“已簽收”為準。

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

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

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

從本質(zhì)上來說，一般電商的“確認收貨”基本等于我們的“購買”，因為同樣是確認把錢款付給賣家，一般電商是支付平臺把錢打給賣家，我們是實際收到用戶的款項。

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

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

我們原來是不想做“交易訂單”這件事的，因為當時希望的是用戶盡快地進入付款的流程，多一步操作搞不好就不買了，這是老板提出的論調(diào)，我很理解老板的擔心，但這一步存在一定有它的理由：

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

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

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

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

五、待寄回

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

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

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

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

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

六、寄回中

快遞小哥取件后，到快遞被倉庫簽收的過程為“寄回中”。

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

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

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

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

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

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

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

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

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