B2C電商解決方案
隨著“互聯網+”時代的電子商務發展, 促使著現代倉儲、物流不斷的變革和創新, 倉儲配送的格局正在發生著巨大變化.倉儲行業正集中精力創新傳統倉庫, 發展電商倉;信息處理方面, 大數據和智能化驅動著整體行業的發展[1].線上線下 (Online To Offline, o2o) 的發展是商業變化的大勢所趨, 云倉儲模式逐漸成為未來的剛性需求.
傳統倉儲各倉庫庫存、訂單、物流信息不能實時傳遞, 形成信息孤島, 需要用云計算技術解決信息不能共享的問題;在傳統倉庫中一般是沒有訂單管理系統的, 在電子商務, 質押貸款等新型模式發展下, 需要訂單管理系統作為客戶與倉庫交流的信息載體, 同時作為倉庫信息入口.設計了云倉儲系統總體架構, 以訂單管理系統為重點, 描述了訂單管理系統與其他模塊之間協作關系、結構設計及統一的第三方數據接口平臺.
云倉儲需要在重要區域中心建立分倉, 再由公司總部建立基于云計算的一體化倉儲信息系統, 用倉儲信息系統將各分倉聯網, 進而實現商品、倉庫、庫位的合理調度, 配送網絡的快速響應.在這種模式下, 商品可直接從分倉的分揀中心實現就近配送, 大大地縮短配送時間, 有效地提升客戶體驗[2].
云倉儲系統設計思想可概括為:通過云計算、大數據、物聯網等技術的緊密結合, 由系統對數據進行儲存、分析、計算, 并對服務進行模塊化、封裝式的處理, 管理人員被賦予不同的權限, 在任意終端通過門戶網站接入中心服務器, 獲取權限范圍內的、所需求的服務[3].
產業鏈扁平化是未來發展的趨勢.云倉儲管理系統在電子商務產業鏈中提供基礎性服務, 將物流、商流、信息流、資金流“四流”有機結合, 利用云計算共享分倉資源, 完善電商倉儲物流生態圈, 通過整合信息網、倉儲網、干線網, 用大數據提升效率.消費者和工廠設計方、品牌商、農業產區將實現可視化的供需鏈接, 不論是電商平臺還是傳統零售, 渠道商如果還是靠買賣賺取差價獲利, 這樣的生存空間必定是越來越小.真正能夠帶來一體化的供應鏈增值服務的, 才是未來商業的核心.
云倉儲管理系統利用“云”的概念將分散于不同區域的、與實體倉庫相關的資源整合起來, 交由企業中心建立的倉儲信息管理系統統一調度管理, 形成一個以分布式倉儲為云, 核心信息管理系統為服務器的企業內部倉儲管理平臺[4].云倉儲管理系統由訂單管理系統、倉庫管理子系統、綜合管理子系統、物流管理子系統、大數據驅動子系統構成, 并在移動客戶端上建立必要的應用支持.從接訂單、倉庫內部管理、采購、以及組織發貨, 到進行數據綜合分析以及業務綜合管理, 提供一個有效的信息化管理平臺, 為網絡倉庫的各個部門的業務開展與協同高效工作提供支持[5].
傳統的倉儲管理系統中是沒有訂單管理模塊的, 在云倉儲管理系統中需要處理普通消費者、商超、電商平臺等訂單數據.訂單管理系統是倉儲配送的初始環節, 客戶需求及內部物流、資源狀況、庫存、數據分析、任務完成情況等都是通過訂單來描述的, 云倉儲系統的配送行為表現為圍繞訂單而進行的一個協調配置過程[6].
在訂單管理系統中, 訂單是管理的對象.云倉儲管理系統中的協同訂單處理從地域上橫跨整個企業和供應鏈, 從時間上覆蓋訂單的產生一直到貨物交付給用戶的全部生命周期, 主要包括生成訂單、訂單協同處理、倉庫調配備貨、制單發貨、物流跟蹤這五個階段[6].在生成訂單階段, 訂單管理系統應該按照提供的統一接口接收訂單信息, 然后進行錄入和保存處理, 生成配貨單, 同時生成物流服務需求訂單, 并按照資源優化配置策略進行訂單在物流企業的分配.配貨單形成后, 協同倉庫管理子系統中開始按照最優路徑策略打包貨物, 形成發貨單, 在供應鏈子系統中對訂單進行確認, 若分配的物流企業接受發貨單, 則執行訂單;若物流企業拒絕訂單, 則供應鏈子系統根據資源最優調度策略對訂單進行智能處理.物流發送貨物后, 由物流平臺提供的物流信息反饋到訂單系統中, 再反饋到客戶.云倉儲系統各個環節進行協同運作, 并同客戶、訂單平臺、物流企業進行雙向信息交互, 提高倉儲環節的柔性和反應能力.
訂單處理狀態遷移如圖1所示.
在訂單協同處理階段, 主要包括以下四個基本環節:訂單錄入、訂單審批、訂單跟蹤、結單管理, 還包含兩個異常訂單處理環節:撤單管理和急單管理以及一個歷史訂單綜合查詢環節[7].在訂單協同管理四個基本環節中, 對錄入的合格訂單進行訂單分批, 資源分配及制單執行計劃, 對不合格的訂單進行調整, 給與客戶反饋.用戶、企業、創客可以對處于未審核狀態下的訂單做撤單處理, 在撤銷訂單后, 完成退款、取消配貨單、物流服務單等操作.在急單管理中, 首先獲取訂單并進行優先審核, 如果審核通過, 訂單被直接提交給倉庫管理子系統, 如果審核未通過, 向用戶提供急單作廢通知, 急單的整個業務處理過程都是通過開辟專用通道 (即提高訂單響應級別) 來實現, 同時也要求倉庫管理子系統對急單開辟專用通道并進行緊急處理[7?8].用戶、倉庫操作員可以根據業務需求利用各種查詢條件對作廢訂單和成功訂單進行實時查詢, 查看訂單目前的狀態, 進行跟蹤[8].系統對各種性質的訂單進行相應的統計, 交給大數據驅動子系統, 并依據成功、撤銷、加急訂單詳細信息做出業務分析和預測.
云倉儲管理系統中的訂單管理模塊涉及到一整套的訂單處理過程, 從提出需求到接受訂單, 訂單審核, 訂單狀況跟蹤、運輸等[9].具體管理內容包括:訂單的定制及傳送;訂單的確認接收;訂單合同管理;訂單計劃定制;訂單相關資源管理;訂單相關關系管理;訂單執行情況的跟蹤監控;訂單出錯及變動處理;訂單狀態查詢;訂單后勤管理;訂單財務管理;訂單協調管理[9,10].
由于訂單狀態是最直接的信號, 因此不合理的訂單管理所導致的信息波動、延遲甚至錯誤, 會導致訂單處理的運作效率低下, 嚴重時甚至使其陷于癱瘓.為了減小訂單信息波動性, 提高運作效率, 各子系統必須達到高度信息共享.為了保證訂單一致性, 云倉儲管理系統中的各個組成模塊間必須協調良好, 保證各方合作的順利進行.訂單管理系統結構圖如圖2所示.
訂單管理系統會接受多種平臺的訂單, 需要統一的訂單接口, 規范訂單數據, 對不同來源的訂單進行數據管理.如淘寶、京東、當當等商務平臺, 通過與電商數據交換服務程序, 獲得指定電商訂單數據, 為其準備相應的貼牌、配送服務;同時對庫存、物流等信息, 提供給電商平臺及創客, 以使其獲知商品存量;對于自有商城或者APP的商戶, 按照指定接口與訂單管理系統進行數據交互, 提供給訂單系統請求數據, 以便倉儲系統根據這些數據進一步處理[11].
以安卓平臺為例, 用java代碼實現, 圖3為第三方平臺與訂單管理系統的交互流程.實線表示消費者或電商平臺對訂單管理系統的請求, 虛線表示訂單系統與商戶系統之間的信息反饋.
第4步:調用訂單接口:這一步就是將商戶簽名后的訂單信息傳遞給接口中的OrderTask對象, 調用order方法, 此方法后續會喚起訂單檢查、庫存檢查操作, 訂單信息格式具體見表2訂單參數說明.
第5步:提交訂單請求:saveOrder對象將會按照商戶客戶端提供的請求參數發送提交訂單、保存訂單的請求, 喚起訂單分批、商品裝配等后續工作.
第8步:接口返回支付結果:商戶客戶端在第4步中調用的訂單接口, 會返回最終的訂單保存結果 (即同步數據庫完畢的通知) .
第12步:異步發送保存訂單信息通知:云倉儲管理系統會發送異步通知消息給商戶服務器端.因為是異步發送, 第12步可能在7~11步之前完成, 但是一定是在第6步訂單保存成功后發起.
訂單管理系統中提供order接口方法供外部調用, 此接口接收兩個參數String類型的orderInfo, 表示商戶的訂單信息, key=“value”格式, 以&連接;另一個參數是Boolean類型參數isShowLoading, 表示商戶提交訂單后, 是否喚起一個loading.order方法可以觸發訂單管理系統里的其他流程, 如庫存檢測、貨物調撥等.重要實體類及關鍵代碼示例見表1.
一個完整的安卓平臺調用過程與代碼是 (1) 將安卓應用的Activity實例傳遞給OrderTask構造方法, 實例化OrderTask對象:OrderTask orderTask=new OrderTask (Activity) ; (2) 將訂單數據封裝到OrderInfo實體內:OrderInfo orderInfo=orderTask.order (String, Boolean) ; (3) 檢查訂單數據規范:orderInfo.check () ; (4) 訂單管理系統保存訂單:orderTask.save (OrderInfo) .Order接口接收的String訂單信息格式見表2.
圖3 第三方平臺與訂單管理系統交互流程Fig.3 Interaction between the third party platform and the order management system
為簡化訂單接收以后在倉庫中的流轉過程, 需要對訂單做分批處理, 在系統中引入基于知識庫的訂單分批策略, 這種策略是去檢索歷史訂單明細數據, 按照式 (1) 的約定, 依據案例推理 (Case-Based Reasoning, CBR) [12]引擎產生最優分批策略.訂單在系統中的分批, 流轉的方案, 是依據歷史訂單知識庫決策的.基于知識庫的案例分批策略分為兩部分, 一部分是被處理過的訂單收集模塊, 另一部分是訂單分組生成模塊.第一部分由云計算子系統提供存儲、更新、檢索的功能, 第二部分集成到訂單管理系統中, 如圖4所示展示了此策略的循環圖.
CBR是以過去解決的類似問題的案例來尋求解決當前新問題的推論方法.CBR引擎是把每一次做出決策的一批訂單作為一個案例, 也就是所謂的“case”, 典型的CBR引擎運行過程分為四步, 依次為檢索、修正、重用、保留.具體是從訂單收集模塊檢索相似的訂單, 進一步修正, 以滿足當前訂單分批的需求, 訂單分批問題與檢索數據相似性滿足以下公式:
式中的sim (f) 是本次案例與歷史案例的相似函數, wi是本次案例與歷史每次相似屬性的權重.在訂單分批過程中, 把相似值S最高的歷史訂單分批方案作為本次的分批方案, 選中的解決方案還需要修正、核對以適應當前的需求, 最終把最新的分批方案再作為歷史方案存儲到收集模塊.
假設揀貨員都是60名, 訂單量依次增加的情況下.在前人實驗基礎上[13], 對比先到先服務、節約算法、粒子群算法, 結果如圖5所示.可以看到基于知識庫的訂單分批策略只是在訂單量較少時處理時間大于粒子群算法, 當訂單量繼續增加, 則優于其他三種訂單分批算法.
圖5 訂單分批算法對比圖Fig.5 Comparison between order batching algorithms
1) 通過分析云倉儲管理系統的特點, 設計了云倉儲管理系統架構.傳統倉庫可依靠此系統改造成服務于電子商務的云倉庫, 形成倉儲配送一體化的新物流模式, 解決了多倉庫信息無法共享和協同工作的問題.
2) 訂單管理系統工作在云倉儲管理系統之上, 提供統一的訂單接口, 接收來自不同平臺的消費者訂單, 統一了云倉儲內部訂單數據結構便于大數據分析.面對不斷變化的消費者需求和海量的訂單數量, 基于知識庫的訂單分批策略在訂單管理系統中的應用, 加快了訂單處理速度, 提高了收益率和倉庫的吞吐率.
上一篇： 云倉金融——物聯網下的供應鏈金融模式創新
下一篇： 基于云倉儲的兩階段快遞配送分析
134-7270-5338
上海市嘉定區南翔嘉美路428號（靠近滬宜公路）
