今天接《商品系統(tǒng)整合總結(jié)》之后，整理了訂單系統(tǒng)整合時的一些心得。

之前已經(jīng)說過，由于公司業(yè)務(wù)線的多樣性，訂單量的不斷增加，公司中的訂單系統(tǒng)之前只是一個訂單中轉(zhuǎn)站，所有的履單流程都是在公司之前的ERP系統(tǒng)中全部完成實現(xiàn)，但是由于ERP系統(tǒng)是好多年前的軟件，雖能夠滿足業(yè)務(wù)需要，但很多環(huán)節(jié)需要借助人為手動操作來處理訂單，效率低。故希望做一次訂單系統(tǒng)整合，能夠系統(tǒng)自動化，減少人為操作成本。

實施步驟

考慮到現(xiàn)有業(yè)務(wù)的正常運作，故訂單系統(tǒng)的整合主要分為以下幾步來實施

一?、先將ERP系統(tǒng)中開線下單的功能遷移出來（包括大客戶訂單和刷單的訂單攔截）

說明：線下單，也可理解為訂單的內(nèi)部處理，主要有以下幾種情況

1. 公司為供貨商的角色，渠道產(chǎn)生訂單后，需要人員內(nèi)部錄入系統(tǒng)后實施履單流程
2. 針對刷單的訂單做的特殊處理，這塊不做贅述
3. 針對大客戶訂單，合并開票發(fā)貨處理
4. 沖紅訂單開具線下單，是公司內(nèi)部系統(tǒng)交互的問題，不做贅述

二、三方平臺/自營式B2C訂單流程整合（不包括O2O訂單）

說明：由于之前這兩部分訂單是不同的團隊在管理，流程上本身也是存在差異的，故規(guī)劃的過程中是計劃B2C整個流程順當后再考慮

整個訂單流程如下：

整體的流程不做過多講解，處方藥部分因為也就只有醫(yī)藥電商會存在這個情況，會做特殊處理，其他的和普通的電商基本上一致；故著重說明下異常訂單攔截，拆分訂單和派單這塊的邏輯

1. 異常訂單攔截

訂單攔截主要根據(jù)業(yè)務(wù)的實際場景攔截，當然這塊也主要分2種情況

1. 數(shù)據(jù)內(nèi)容校驗（如必填字段為空，金額核對不準確，黑名單等）
2. 拆分訂單過程中攔截（如負毛訂單，超區(qū)訂單，無庫存訂單，拆單數(shù)量限制等）

2. 拆分訂單

一般會考慮從以下維度處理，當然具體的還是要看各自公司的實際情況

（1）拆單因素：商品屬性，渠道，庫房，庫存等將父單拆分成不同的子單。

（2）校驗：

• 子單商品數(shù)量，相關(guān)金額（平臺優(yōu)惠，商家優(yōu)惠，商品優(yōu)惠，訂單金額，實付金額）與父單的一致性
• 拆分訂單數(shù)量是否符合業(yè)務(wù)需求（如：拆單數(shù)量限制，貨到付款訂單拆單限制等）
• 拆分后是否需要再次拆分，如果是，則子單為異常訂單，否則拆分完成，同時取消父單，生成子單；校驗不符合的，恢復原單

3. 派單

需要考慮的因素：發(fā)貨地與倉的距離，倉的優(yōu)先級，快遞優(yōu)先級，快遞報價優(yōu)先級等；

關(guān)于派單，在具體的派單流程過程中也是需要根據(jù)公司業(yè)務(wù)的實際情況來制定規(guī)則完成派單。

三、代運營訂單提供訂單開放接口

1. 有對接接口能力的渠道，抓取訂單，發(fā)貨后需要將物流返回到訂單系統(tǒng)。
2. 無對接能力的渠道，提供查詢訂單的頁面，同時需要有導入物流單號的功能。其他的輔助功能，根據(jù)公司的實際情況來決定是否需要給渠道提供。

四、O2O訂單與B2C訂單整合

后期這塊是另外一個同事負責，整合的過程中是在拆分訂單前做了一次O2O訂單條件判斷，優(yōu)先門店來進行接單發(fā)貨，不滿足，倉庫再進行發(fā)貨處理。當然這樣提升了用戶體驗，當然也需要考慮三方平臺訂單物流回寫的問題，因為O2O訂單是不需要物流單號的，而B2C的訂單需要。這塊是另外一個項目組負責，這塊不做過多陳述。

在流程整理的過程中，由于剛開始是根據(jù)自己之前的習慣來畫的流程圖，第一次和負責研發(fā)的小組長評審時，大家給了一些建議，最終修改了2版整個項目組才達成共識；評審時使用最終版來和所有的人員進行需求評審，過程還算順利。在這里很感謝研發(fā)同事對我工作上的支持和幫助。

作者：簡之箐，微信公眾號：sunshinegirl，5年互聯(lián)網(wǎng)產(chǎn)品經(jīng)理，曾擔任醫(yī)藥產(chǎn)品經(jīng)理和電商產(chǎn)品經(jīng)理，經(jīng)歷主導過電商平臺的系統(tǒng)整合規(guī)劃。

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

題圖來自PEXELS，基于CC0協(xié)議i