供應鏈：OMS系統訂單管理

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

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

一、什麼是訂單管理？

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

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

二、B2C正向訂單處理

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

1. 訂單下載

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

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

1. 自動下載：商家設置訂單自動下載規則（比如5分鐘下載一次）並開啟訂單自動下載任務後，系統將自動下載平台訂單。
2. 手動下載：商家可以設置一些條件（比如訂單更新時間、平台店鋪、平台訂單號等），並手動觸發系統下載符合該條件的平台訂單。

2. 訂單轉化

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

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

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

1. 商品信息轉化：校驗系統上是否存在該平台商品對應的鋪貨關係，若存在，則平台商品轉化為系統商品；若不存在，則提示商品異常。
2. 地址信息轉化：OMS系統上會維護一套地址區域信息（分為國家/省份/市/區四級結構），用來校驗單據的地址信息是否存在有效，銷售訂單上的地址若不符合系統區域信息結構，需要轉化為系統上對應的區域信息，否則提示異常。
3. 承運商轉換：OMS系統上會維護一套承運商信息檔案，並維護平台承運商與系統承運商的關係，訂單上的平台承運商信息需要轉化為系統承運商，否則提示異常。
4. 訂單狀態轉化：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 協議。

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