

 写点什么

一、行业背景概述

近五年，各大家电制造企业都在大力布局、发展自己的线上业务。仅 2019 年双 11 这一天，各平台的销售数据统计显示，Haier 海尔、Gree 格力、Hisense 海信等当天销售额都达到了几十亿甚至上百亿的级别。

家电制造企业都已经从传统的单一线下代理商、经销商渠道的销售模式，逐步发展成为线上电商渠道与线下渠道相结合的销售模式。

这一过程中，企业需要投入大量的人力、财力与时间成本，涉及到企业组织架构、业务流程以及系统架构的调整与建设。以下聊聊 电商中台 在家电行业销售渠道演进过程中（单一线下渠道、线上线下结合以及线上线下融合三个阶段）的诞生与发展。

（注：以下内容是笔者在对海尔、格力、海信等企业做了一定的信息调研后，进行抽象总结出来的，不等同于企业实际情况；文中涉及的家电制造企业统一简称为企业。）

二、单一线下渠道

在传统单一线下渠道阶段，还没有电商业务，更没有什么电商中台了。以下将分别从组织架构、渠道结构、业务流程与系统架构四个方面进行介绍。后续各销售渠道发展阶段内容介绍形式保持一致。

2.1、企业组织架构

企业组织架构通常是比较复杂的，这里只从生产销售家电产品的视角做示意性介绍。如下示意图所示：

图 1 企业组织架构示意

企业的产品线通常都是按事业部划分的，如空调事业部、冰箱事业部、洗衣机事业部等。一般情况下，企业同时还拥有自己的物流公司。各事业部有自己的工厂与仓库，分布在全国不同的区域。产品的仓储管理与干线物流配送业务主要由企业自有的物流公司承接。

2.2、线下渠道结构

传统的线下代理商、经销商渠道销售模式，层级结构如下示意图所示：

图 2 线下渠道层级结构示意

显而易见，企业通过传统的代理商、经销商渠道进行商品销售，存在层级多、库存积压、商品利润率低、信息不同步等问题。同时，企业难以快速有效地直接覆盖、触达 C 端消费者，无法准确、及时地获取 C 端用户的真实反馈。企业的经营决策缺乏及时、有效的数据支撑。最终影响的就是用户体验与企业效益。

2.3、业务流程简介

这一阶段的业务流程比较简单，各事业部的主要销售方式是经销方式，代销方式较少，即代理商、经销商需要先向事业部采购商品，待商品到货入库后，再面向 C 端消费者进行销售。经销就是代理商、经销商需要付款采购商品（拥有货权），而代销不用（只是帮忙卖货赚提成）。

图 3 线下渠道业务流程示意

2.4、信息系统架构

这一阶段的企业内部信息化建设经过发展，已具备一定的水平。从制造业信息化建设的常规套路，可总结抽象出四大核心系统/平台，如下示意图所示：

图 4 四大核心系统示意

销售管理系统

主要负责管理线下代理商、经销商向事业部采购商品相关的业务流程。生成采购订单后，下发仓储物流平台配货、发货。

仓储物流平台

主要负责各事业部的仓库管理以及事业部仓库至代理商、经销商仓库的干线物流业务。

财务 ERP 系统

主要是会计相关的业务，如记账、对账、核销等。

资金结算系统

主要是资金结算业务，如对公转账汇款、个人转账汇款等。

企业的这四大核心系统/平台，多数是采购的现有产品（比如财务 ERP 和结算系统采购 SAP 或者金蝶的），少数自研。起初系统间的信息流是没有打通的，系统间的业务数据输入基本都是通过手工录入或者导入处理，工作效率低、易出错、时效性差。

在企业投入了大量的人力与财力、耗费大量时间后，最终才得以完成信息系统的互联。不同系统之间的信息互联方式较常见的是通过 ESB 集成，也可以通过 HTTP 与 RPC 协议集成。

三、线上线下结合

进入线上线下结合阶段，初期各事业部各自在第三方电商平台（淘宝、天猫、京东等）开店经营，各玩各的，没有形成一个完整的电商业务体系。为此，企业一般会成立独立的电商公司，负责线上电商业务的统一运营与管理。

同时，电商中台在这一阶段完成建设并不断演进。

3.1、企业组织架构

该阶段企业的组织架构如下示意图所示：

图 5 组织架构示意

3.2、线上渠道结构

在原有线下渠道的基础上，企业构建了完整的线上电商业务体系。线上渠道整体结构如下示意图所示：

图 6 线上渠道分层结构示意

销售渠道层

即淘宝、天猫、京东、国美、苏宁等这些第三方电商平台，以及企业自建电商平台。企业自建电商平台相对而言主要是扮演品牌门面角色，核心流量还是在第三方电商平台。企业自建电商平台如下图所示：

图 7 企业自建电商平台示意

销售主体层

即电商公司（分销）、事业部（自营）、代理商、经销商都可以在电商平台开店卖货。电商公司（分销）与事业部（自营）成为企业在电商渠道的核心销售主体，企业在电商零售方面摆脱了以往在线下渠道对代理商、经销商的依赖。

仓储物流层

仓储物流层主要有菜鸟物流和京东物流两家巨头，当然还包括顺丰、企业自有物流等。一般情况下，第三方电商平台中，淘系平台和京系平台的合计流量估计会占到 80%以上。如此一来，大部分仓储物流层的城配业务都是走的菜鸟物流和京东物流。企业自有物流，主要承接干线物流业务，城配业务量较少。

税控财务层

该层主要涉及支付与发票两方面的业务。航信和百望是比较常用的发票平台，支付宝和微信是使用最多的两个第三方支付平台。

3.3、业务流程简介

该阶段线上渠道与线下渠道基本上是相互隔离的，即线上与线下销售的是两盘货。从仓库层面划分的话，分为线下仓和线上仓（电商仓），电商仓大部分是租用的菜鸟或者京东的仓，少数是企业自有物流的仓。只有电商仓的货可以在线上渠道销售。

在业务流程上，不同的销售主体间会存在一些差异。整体流程示意图如下所示：

图 8 业务流程示意

电商公司（分销）：电商公司需要向事业部采购商品，到货入库到电商仓后，才能在电商平台上进行销售；在采购的过程中，注意还需要处理一项 关联交易 的业务（集团内部单位的资金往来记录）。
事业部（自营）：事业部需要将线下仓的商品调拨到电商仓后，才能在电商平台上进行销售。
代理商与经销商：代理商与经销商通过线下渠道采购商品后，拥有货权，可以直接在电商平台上进行销售。

3.4、信息系统架构

3.4.1、整体业务架构

随着组织架构与业务流程的调整，企业有了新的信息系统架构。整体分层业务架构如下图所示：

图 9 业务架构示意

前台

上图只画出了淘系零售、京系零售两个大平台以及企业自建电商平台，实际上还包括国美、苏宁、唯品会等平台。同时，税控财务层（如航信发票平台、支付宝）的内容也属于该层对象。前台为中台提供了信息流（比如订单）和资金流（比如支付宝流水）。

中台

这里将电商中台分为业务中台和数据中台，其中业务中台主要由商品中心、订单中心、库存中心、财务中心、店铺中心和会员中心组成。其中财务中心主要涉及电子发票、支付、会计与结算等功能模块。数据中台可以简单的划分为基础数据中心、业务数据中心和萃取数据中心。

后台

后台主要是指仓储物流平台、销售管理系统、财务 ERP、资金结算系统、CRM 与 SRM 等。

3.4.2、中台应用架构

业务中台应用架构以微服务形式进行分层划分后，主要包括应用网关层、聚合服务层、基础服务层、中间件层和云设施层（本文只聊业务中台，不涉及数据中台）。如下图所示：

图 10 业务中台应用架构示意

应用网关层

该层主要负责对接各平台 API，完成平台数据与中台数据之间的同步。比如订单同步服务从平台拉取订单至中台，在订单完成发货后再将订单状态上传至平台。店铺、商品、库存、财务与物流同步服务，机制一致。

聚合服务层

该层主要包括单据（订单、物流单据、财务单据）归集转换服务、订单履约服务和库存核心服务，依赖基础服务层。比如订单同步服务将各平台订单同步至中台后，需要经过订单归集转换服务的标准化处理（商品映射转换、地址映射转换等），再交由订单履约服务处理。订单履约的过程中，选仓、锁库存、释放扣减库存都由库存核心服务完成。物流单据、财务单据归集转换服务，机制一致。

基础服务层

该层主要包括商品基础服务、店铺基础服务、订单基础服务、物流基础服务、电子发票服务与财务基础服务，供聚合服务层调用。

基础服务层主要是抽象出了基本的公共业务单元，比如订单基础服务功能包括：新增订单、修改订单、废弃订单与查询订单。类似 CRUD，但不仅仅如此。比如废弃订单操作，在修改订单状态的同时，还需要做释放锁定库存的逻辑处理等。

中间件层

该层主要是常用的中间件，如缓存、消息队列、搜索引擎、分库分表与分布式事务中间件等。

云设施层

该层主要是云服务器、云数据库等云设施，如阿里云的 ECS、RDS，Docker 与 K8S 服务等。

微服务治理

微服务的架构对应了一个全局治理中心，包括注册中心、鉴权中心、配置中心、监控中心和调度中心等。

系统监控

这里的系统监控主要是指云设施的指标监控，与微服务应用的监控区别开来。

3.4.3、中台技术架构

在以微服务理论划分的应用架构基础上，以三个数据流（订单流、资金流和物流）为导向，得出业务中台的整体技术架构，如下图所示：

图 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 集群，做实时分析。