作為一個統一管理多渠道訂單的工作臺，OMS對於全渠道商家的重要性不言而喻。那麼，什麼是訂單管理？OMS的訂單處理需要包括哪些能力呢？一起來看一下吧。

在新零售電商模式下，OMS作為一個統一管理多渠道訂單的工作臺，其之於全渠道商家的重要性不言而喻。那麼，什麼是訂單管理？OMS系統的訂單處理需要包括哪些能力？

一、什麼是訂單管理？

“訂單管理是客戶關係管理的有效延伸，能更好的把個性化、差異化服務有機的融入到客戶管理中去，能推動經濟效益和客戶滿意度的提升。”

通俗一點來講，訂單管理就是從電商平臺上獲取買家訂單，對訂單進行一些處理後，將訂單分配給倉庫發貨。電商訂單的整個鏈路大致如下圖所示，在複雜的商業模式下，商家訂單型別多樣，不同型別的訂單的處理不盡相同。本文將探討OMS系統關於B2C訂單處理的產品設計思路。

二、B2C正向訂單處理

B2C正向訂單處理包括下載訂單、訂單轉化、訂單打標、贈品計算、訂單稽核、拆合單等，處理流程大致如下圖所示：

1. 訂單下載

OMS系統對接了各銷售渠道/電商平臺，要能夠將平臺店鋪待發貨的原始訂單集中下載到本地，並提供平臺訂單列表供商家檢視管理。

通常，訂單下載有自動下載和手動下載兩種方式：

自動下載：商家設定訂單自動下載規則（比如5分鐘下載一次）並開啟訂單自動下載任務後，系統將自動下載平臺訂單。

手動下載：商家可以設定一些條件（比如訂單更新時間、平臺店鋪、平臺訂單號等），並手動觸發系統下載符合該條件的平臺訂單。

2. 訂單轉化

平臺訂單由各電商平臺生成，訂單上部分資訊的表達方式各異，比如同一個商品蘋果，在平臺A上可能叫做“紅富士”，在平臺B上可能就叫做“國產紅富士”。對於不熟悉的工作人員來說，很難知道這兩個其實對應的是同一個蘋果；更何況對於系統來說，不同的表達方式就是兩個不同的東西。

因此，若要實現對訂單的統一管理，平臺訂單首先要轉化為系統內部訂單，確保訂單資訊以相同的方式進行表達，系統可識別。

訂單轉化過程中，通常會進行以下幾方面資訊的校驗、轉化：

商品資訊轉化：校驗系統上是否存在該平臺商品對應的鋪貨關係，若存在，則平臺商品轉化為系統商品；若不存在，則提示商品異常。

地址資訊轉化：OMS系統上會維護一套地址區域資訊（分為國家/省份/市/區四級結構），用來校驗單據的地址資訊是否存在有效，銷售訂單上的地址若不符合系統區域資訊結構，需要轉化為系統上對應的區域資訊，否則提示異常。

承運商轉換：OMS系統上會維護一套承運商資訊檔案，並維護平臺承運商與系統承運商的關係，訂單上的平臺承運商資訊需要轉化為系統承運商，否則提示異常。

訂單狀態轉化：OMS系統內部訂單的狀態機與各平臺訂單的狀態機不盡相同，因此訂單狀態也應該進行相應轉化。

平臺訂單轉化為OMS系統內部訂單後，便可基於系統內部訂單進行下一步的訂單處理。

3. 訂單匯入

考慮到一些特殊場景（比如平臺暫未對接、幫助客戶下單等），OMS通常也需要支援手工建立訂單、匯入建立訂單的方式直接建立系統內部訂單。

4. 訂單打標

基於訂單的某些特徵，商家需要對這類訂單提供相應的特殊服務，為了便於快速識別或篩選出這些訂單，商家可以對訂單打上相應的標籤。

訂單上的標籤可以由系統自動設定，也可以由工作人員手動設定。自動設定標籤的能力對應的是自動打標規則，自動打標規則允許商家根據業務需要設定對應的打標條件，當訂單流入到系統後，若命中該打標規則，則自動為該訂單新增對應的標籤，減少人工識別訂單的工作量。

5. 訂單攔截

出於某些原因，業務上不允許訂單繼續往下一個處理環節流轉，需要讓訂單停留在當前處理環節，等攔截因素自動或手動解除後，訂單才可以繼續向下流轉。比如訂單超低價、收貨地物流管控等場景下，都可能需要攔截訂單。訂單攔截一般由系統根據攔截規則自動攔截，商家只需事前配置好攔截規則，事後稽核被攔截訂單。

6. 贈品計算

商家在OMS系統上設定的贈品活動正是作用在此處。訂單推送給贈品中心處理後，贈品中心將反饋該訂單的贈品計算結果，訂單中心則根據反饋結果在訂單上新增對應的贈品行，以確保贈品能夠進入履約流程。

7. 訂單稽核

訂單稽核的目的確認訂單不存在風險、資訊準確無誤、需要發貨履約。在訂單稽核的過程中，如有必要，還可以對訂單進行一些手工調整，比如修改訂單地址、修改商品資訊、新增贈品、修改發貨倉庫、修改承運商等等。 稽核透過的訂單，訂單的狀態將更新為以稽核，且訂單的一些資訊將鎖定不再允許修改。

8. 拆單/合單

OMS拆單就是將訂單拆成多個子訂單分別發貨，合單就是多個訂單合在一起發貨。拆單合單都是為了更好的對訂單進行履約，從而降低商家成本或提高使用者體驗。一方面商家可以設定自動拆單、合單的規則，以減少人工工作量，提高拆合單效率；另一方面，商家也需要能夠人工干預，手動對訂單進行拆單、合單操作。

拆單、合單必須在訂單進入倉庫尋源/發貨單推送給倉庫之前完成。有些OMS系統中，將拆合單流程放在訂單稽核之前，有些則是將拆合單流程設計在訂單稽核之後、推送給下游系統之前。不論哪種方案，只是各自的考量不一樣，都是合理的。

9. 訂單排程

訂單排程即給訂單尋找發貨倉庫（尋源派單規則便是在作用在此處），並將訂單推送給倉庫對應的WMS系統。

三、B2C訂單售後處理

售後業務包括：退款、退貨、換貨、補發，售後申請。一方面，買家可以直接在線上平臺發起售後申請，另一方面，買家也可以透過與客服溝通，由客服人員代替買家直接在商家後臺發起售後申請。

在OMS上需要提供的售後處理能力大致包括以下幾方面：

1. 線上售後申請單下載

線上售後申請單的下載、轉化與正向訂單相似。

2. 售後申請單建立

客服幫助買家建立售後申請的場景下，客服可以直接在OMS系統上建立售後申請單，並且將該售後申請單關聯對應的正向訂單。

3. 售後申請稽核

售後申請同樣包括自動稽核機制及人工稽核能力。若是僅退款型別的售後，則稽核透過之後，相應金額便可直接退回給買家；若是退貨、換貨、補發型別的售後，稽核透過之後則售後進入下一環節（比如買家寄回、倉庫發貨等）。

4. 退件處理

退件處理指的是對買家退回快遞的處理，包括退件快遞簽收、拆包裹驗貨以及無頭件處理。由於退件一般是寄回到商家倉庫，因此退件通常由倉庫透過WMS進行管理，一般SAAS OMS也會提供這部分能力以增強產品競爭力。

通常，系統會根據退件快遞上的承運商、運單號資訊將退件與售後單關聯起來，從而驗證貨品是否按要求退回，若符合要求，則售後可以進入下一環節（比如退款、補發）。但難免存在一些特殊的情況，比如買家在售後單中回填的運單資訊有誤或是漏填，則倉庫收到的退件便無法與售後單關聯起來，這就是無頭件場景。無頭件處理就是將退回快遞與售後單關聯起來。

總結

OMS承擔著訂單資訊集中處理、高效傳遞的重任，在整個業務鏈路中屬於中臺的角色。商家可以沒有WMS、TMS，但在降本增效、數字化轉型的路上絕對少不了一套OMS。

本文由 @藍晨熙 原創釋出於人人都是產品經理，未經許可，禁止轉載。

題圖來自 Unsplash，基於 CC0 協議。

該文觀點僅代表作者本人，人人都是產品經理平臺僅提供資訊儲存空間服務。