Categories
程式開發

泛談家電行業電商中台架構演進


一、行業背景概述

近五年,各大家電製造企業都在大力佈局、發展自己的線上業務。僅2019年雙11這一天,各平台的銷售數據統計顯示,Haier海爾、Gree格力、Hisense海信等當天銷售額都達到了幾十億甚至上百億的級別。

家電製造企業都已經從傳統的單一線下代理商、經銷商渠道的銷售模式,逐步發展成為線上電商渠道與線下渠道相結合的銷售模式。

這一過程中,企業需要投入大量的人力、財力與時間成本,涉及到企業組織架構、業務流程以及系統架構的調整與建設。以下聊聊 電商中台 在家電行業銷售渠道演進過程中(單一線下渠道、線上線下結合以及線上線下融合三個階段)的誕生與發展。

(注:以下內容是筆者在對海爾、格力、海信等企業做了一定的信息調研後,進行抽象總結出來的,不等同於企業實際情況;文中涉及的家電製造企業統一簡稱為企業。)

二、單一線下渠道

在傳統單一線下渠道階段,還沒有電商業務,更沒有什麼電商中台了。以下將分別從組織架構、渠道結構、業務流程與系統架構四個方面進行介紹。後續各銷售渠道發展階段內容介紹形式保持一致。

2.1、企業組織架構

企業組織架構通常是比較複雜的,這裡只從生產銷售家電產品的視角做示意性介紹。如下示意圖所示:

泛談家電行業電商中台架構演進 1

圖1 企業組織架構示意

企業的產品線通常都是按事業部劃分的,如空調事業部、冰箱事業部、洗衣機事業部等。一般情況下,企業同時還擁有自己的物流公司。各事業部有自己的工廠與倉庫,分佈在全國不同的區域。產品的倉儲管理與乾線物流配送業務主要由企業自有的物流公司承接。

2.2、線下渠道結構

傳統的線下代理商、經銷商渠道銷售模式,層級結構如下示意圖所示:

泛談家電行業電商中台架構演進 2

圖2 線下渠道層級結構示意

顯而易見,企業通過傳統的代理商、經銷商渠道進行商品銷售,存在層級多、庫存積壓、商品利潤率低、信息不同步等問題。同時,企業難以快速有效地直接覆蓋、觸達C端消費者,無法準確、及時地獲取C端用戶的真實反饋。企業的經營決策缺乏及時、有效的數據支撐。最終影響的就是用戶體驗與企業效益。

2.3、業務流程簡介

這一階段的業務流程比較簡單,各事業部的主要銷售方式是經銷方式,代銷方式較少,即代理商、經銷商需要先向事業部採購商品,待商品到貨入庫後,再面向C端消費者進行銷售。經銷就是代理商、經銷商需要付款採購商品(擁有貨權),而代銷不用(只是幫忙賣貨賺提成)。

泛談家電行業電商中台架構演進 3

圖3 線下渠道業務流程示意

2.4、信息系統架構

這一階段的企業內部信息化建設經過發展,已具備一定的水平。從製造業信息化建設的常規套路,可總結抽像出四大核心系統/平台,如下示意圖所示:

泛談家電行業電商中台架構演進 4

圖4 四大核心系統示意

  • 銷售管理系統

主要負責管理線下代理商、經銷商向事業部採購商品相關的業務流程。生成採購訂單後,下發倉儲物流平台配貨、發貨。

  • 倉儲物流平台

主要負責各事業部的倉庫管理以及事業部倉庫至代理商、經銷商倉庫的干線物流業務。

  • 財務ERP系統

主要是會計相關的業務,如記賬、對賬、核銷等。

  • 資金結算系統

主要是資金結算業務,如對公轉賬匯款、個人轉賬匯款等。

企業的這四大核心系統/平台,多數是採購的現有產品(比如財務ERP和結算系統採購SAP或者金蝶的),少數自研。起初系統間的信息流是沒有打通的,系統間的業務數據輸入基本都是通過手工錄入或者導入處理,工作效率低、易出錯、時效性差。

在企業投入了大量的人力與財力、耗費大量時間後,最終才得以完成信息系統的互聯。不同系統之間的信息互聯方式較常見的是通過ESB集成,也可以通過HTTP與RPC協議集成。

三、線上線下結合

進入線上線下結合階段,初期各事業部各自在第三方電商平台(淘寶、天貓、京東等)開店經營,各玩各的,沒有形成一個完整的電商業務體系。為此,企業一般會成立獨立的電商公司,負責線上電商業務的統一運營與管理。

同時,電商中台在這一階段完成建設並不斷演進。

3.1、企業組織架構

該階段企業的組織架構如下示意圖所示:

泛談家電行業電商中台架構演進 5

圖5 組織架構示意

3.2、線上渠道結構

在原有線下渠道的基礎上,企業構建了完整的線上電商業務體系。線上渠道整體結構如下示意圖所示:

泛談家電行業電商中台架構演進 6

圖6 線上渠道分層結構示意

  • 銷售渠道層

即淘寶、天貓、京東、國美、蘇寧等這些第三方電商平台,以及企業自建電商平台。企業自建電商平台相對而言主要是扮演品牌門面角色,核心流量還是在第三方電商平台。企業自建電商平台如下圖所示:

泛談家電行業電商中台架構演進 7

圖7 企業自建電商平台示意

  • 銷售主體層

即電商公司(分銷)、事業部(自營)、代理商、經銷商都可以在電商平台開店賣貨。電商公司(分銷)與事業部(自營)成為企業在電商渠道的核心銷售主體,企業在電商零售方面擺脫了以往在線下渠道對代理商、經銷商的依賴。

  • 倉儲物流層

倉儲物流層主要有菜鳥物流和京東物流兩家巨頭,當然還包括順豐、企業自有物流等。一般情況下,第三方電商平台中,淘系平台和京系平台的合計流量估計會占到80%以上。如此一來,大部分倉儲物流層的城配業務都是走的菜鳥物流和京東物流。企業自有物流,主要承接幹線物流業務,城配業務量較少。

  • 稅控財務層

該層主要涉及支付與發票兩方面的業務。航信和百望是比較常用的發票平台,支付寶和微信是使用最多的兩個第三方支付平台。

3.3、業務流程簡介

該階段線上渠道與線下渠道基本上是相互隔離的,即線上與線下銷售的是兩盤貨。從倉庫層面劃分的話,分為線下倉和線上倉(電商倉),電商倉大部分是租用的菜鳥或者京東的倉,少數是企業自有物流的倉。只有電商倉的貨可以在線上渠道銷售。

在業務流程上,不同的銷售主體間會存在一些差異。整體流程示意圖如下所示:

泛談家電行業電商中台架構演進 8

圖8 業務流程示意

  • 電商公司(分銷):電商公司需要向事業部採購商品,到貨入庫到電商倉後,才能在電商平台上進行銷售;在採購的過程中,注意還需要處理一項 關聯交易 的業務(集團內部單位的資金往來記錄)。
  • 事業部(自營):事業部需要將線下倉的商品調撥到電商倉後,才能在電商平台上進行銷售。
  • 代理商與經銷商:代理商與經銷商通過線下渠道採購商品後,擁有貨權,可以直接在電商平台上進行銷售。

3.4、信息系統架構

3.4.1、整體業務架構

隨著組織架構與業務流程的調整,企業有了新的信息系統架構。整體分層業務架構如下圖所示:

泛談家電行業電商中台架構演進 9

圖9 業務架構示意

  • 前台

上圖只畫出了淘系零售、京系零售兩個大平台以及企業自建電商平台,實際上還包括國美、蘇寧、唯品會等平台。同時,稅控財務層(如航信發票平台、支付寶)的內容也屬於該層對象。前台為中台提供了信息流(比如訂單)和資金流(比如支付寶流水)。

  • 中台

這裡將電商中台分為業務中台和數據中台,其中業務中台主要由商品中心、訂單中心、庫存中心、財務中心、店鋪中心和會員中心組成。其中財務中心主要涉及電子發票、支付、會計與結算等功能模塊。數據中台可以簡單的劃分為基礎數據中心、業務數據中心和萃取數據中心。

  • 後台

後台主要是指倉儲物流平台、銷售管理系統、財務ERP、資金結算系統、CRM與SRM等。

3.4.2、中台應用架構

業務中台應用架構以微服務形式進行分層劃分後,主要包括應用網關層、聚合服務層、基礎服務層、中間件層和雲設施層(本文只聊業務中台,不涉及數據中台) 。如下圖所示:

泛談家電行業電商中台架構演進 10

圖10 業務中台應用架構示意

  • 應用網關層

該層主要負責對接各平台API,完成平台數據與中台數據之間的同步。比如訂單同步服務從平台拉取訂單至中台,在訂單完成發貨後再將訂單狀態上傳至平台。店鋪、商品、庫存、財務與物流同步服務,機制一致。

  • 聚合服務層

該層主要包括單據(訂單、物流單據、財務單據)歸集轉換服務、訂單履約服務和庫存核心服務,依賴基礎服務層。比如訂單同步服務將各平台訂單同步至中台後,需要經過訂單歸集轉換服務的標準化處理(商品映射轉換、地址映射轉換等),再交由訂單履約服務處理。訂單履約的過程中,選倉、鎖庫存、釋放扣減庫存都由庫存核心服務完成。物流單據、財務單據歸集轉換服務,機制一致。

  • 基礎服務層

該層主要包括商品基礎服務、店鋪基礎服務、訂單基礎服務、物流基礎服務、電子發票服務與財務基礎服務,供聚合服務層調用。

基礎服務層主要是抽像出了基本的公共業務單元,比如訂單基礎服務功能包括:新增訂單、修改訂單、廢棄訂單與查詢訂單。類似CRUD,但不僅僅如此。比如廢棄訂單操作,在修改訂單狀態的同時,還需要做釋放鎖定庫存的邏輯處理等。

  • 中間件層

該層主要是常用的中間件,如緩存、消息隊列、搜索引擎、分庫分錶與分佈式事務中間件等。

  • 雲設施層

該層主要是雲服務器、雲數據庫等雲設施,如阿里雲的ECS、RDS,Docker與K8S服務等。

  • 微服務治理

微服務的架構對應了一個全局治理中心,包括註冊中心、鑑權中心、配置中心、監控中心和調度中心等。

  • 系統監控

這裡的系統監控主要是指雲設施的指標監控,與微服務應用的監控區別開來。

3.4.3、中台技術架構

在以微服務理論劃分的應用架構基礎上,以三個數據流(訂單流、資金流和物流)為導向,得出業務中台的整體技術架構,如下圖所示:

泛談家電行業電商中台架構演進 11

圖11 業務中台技術架構示意

(1)三流獲取

淘系平台(京系平台類似)訂單流的獲取方式有三種:RDS訂閱、MQ訂閱和API拉取。 RDS訂閱(需要Canal配合)和MQ訂單都可以近實時監聽獲取變化的訂單數據,使用較多。 API拉取的方式,實時性差,一般用在補償的業務場景。

資金流和物流的獲取方式類似,一般是通過API接口調用拉取,也有通過FTP下載的,極端情況下有通過下載EXCEL表格的。

三流獲取,核心就是保證數據的完整性、準確性與及時性。

(2)微服務技術

微服務框架可以選擇SpringCloud,也可以選擇淘寶的Dubbo。電商技術選型方面,借鑒參考阿里基本上是不會錯的。比如異構數據同步中間件Canal,服務限流降級中間件Sentinel,分庫分錶中件DRDS、分佈式事務中間件Seata以強大的消息中間件RocketMQ。它們都已經經受過了淘系平台的考驗。當微服務數量比較大的時候,使用Docker與K8S實現微服務的容器化運維也是一個趨勢。

具體應用場景與用法有興趣請自行查閱資料。

(3)其他平台交互方式

業務中台與倉儲物流平台主要是通過HTTP(S)協議交互的,與銷售管理系統、財務ERP和資金結算系統等內部管理系統的交互一般是通過ESB(企業消息總線)集成的。

數據中台方面,根據業務中台提供只讀從庫,可以通過Sqoop抽取數據,做離線分析,也可以通過配置Canal監聽數據變更,並投遞到Kafka集群,做實時分析。

四、線上線下融合

線上線下結合階段,線上渠道快速增長,線下渠道得益於歷史佈局的沉澱,持續貢獻穩定的營收。但兩個渠道賣的不是同一盤貨,導致最明顯的問題就是線上庫存賣完了,而線下庫存積壓,此時線上卻不能使用線下的庫存。反之亦然。故線上線下融合,共賣一盤貨,成為新的發展階段。

這一階段,企業的組織架構沒有大的調整,渠道結構也基本保持不變。業務流程上的變更主要是在倉儲層面。同時系統架構上要做比較大的整合。

4.1、業務融合

該階段,首先是共賣一盤貨,即倉庫層面不再區分線下倉與線上倉,建立共享庫存中心。同時,用戶既可以在線上預訂,再到就近門店現場體驗後付尾款、提貨;也可以先在線下體驗後,再線上下單購買、現場直接提貨或等待配送。

業務流程調整描述起來比較簡單,但實際業務涉及線上線下渠道銷售主體之間的訂單分發、利潤分配等問題,比較複雜。

4.2、庫存融合

為支撐業務融合,系統架構調整的核心主要是建設共享庫存中心、共享訂單中心與共享商品中心。以共享庫存中心為例,系統架構演變如下示意圖所示:

泛談家電行業電商中台架構演進 12

圖12 線上線下庫存融合示意

共享訂單中心與共享商品中心的系統架構演變類似,不再贅述。業務中台的演進過程,業界基本都在藉鑑阿里中台的建設經驗。

五、總結

家電製造企業在整個銷售渠道的(三個階段)演進過程中,應該是具備基本共性的,都需要經歷組織架構、業務流程與系統架構的調整與建設,都必須耗費大量的人力、財力與時間,才能成功構建出企業電商中台並持續演進。

而後以電商中台為核心,打通整個電商業務體系全鏈路信息流,提升用戶體驗與企業效益,並且讓整個銷售體系逐步走向“數字化”與“智能化”。

題外話,除了家電製造企業,像華為、小米和OPPO等電子產品製造企業的銷售渠道演進過程與電商中台建設過程應該也是具有很多共性的。

泛談家電行業電商中台架構演進 13

圖13 電子製造企業自建電商平台示意