电商后台管理有哪些功能（电商后台设计商品维护）

编辑导语：商品在整个电商系统中处于核心位置，因此商品维护对于电商后台设计的重要性不言而喻，本文作者以此为出发点，和我们聊一聊在电商后台设计中关于商品维护的那些事。

对于电商系统来说，商品模块的维护可以说是核心功能了，整个系统都是围绕商品来进行运营的。所以能否设计一个灵活便捷的商品模块，对于整个系统的操作都非常重要。

今天我们就来聊聊商品管理那点事，对于商品信息的维护，它的本质是对一堆属性和属性值的管理，理清其中的关联关系，就能将其玩转的游刃有余。

首先我们先来看看一个商品都有哪些属性，下图是某电商平台的商品图：

整理一下可以得到其中的属性：商品名称、品牌、品类、颜色、内存、价格、图片、商品编码、CPU型号、机身存储、商品毛重、操作系统等等。

在上一篇《电商后台设计：属性管理》中，我们将这些属性分了四类：基础属性、销售属性、搜索属性、特有属性。除了其中的搜索属性被融合在特有属性中，其它的功能在商品信息维护中都有所涉及，接下来我们一一进行讨论。

一、基础属性

对于所有商品包含的属性，都可以归类到基础属性中，如商品名称、品牌、品类、状态等。对于基础属性的维护比较简单，由于都是单一可以确定类型，通常根据数据展示形式一一维护即可。

其中有几个属性需要说明一下：

1. 品类：由于商品的特有属性和搜索属性都关联在品类上，所以商品品类是必须选择的。
2. 状态: 上架/下架，确定是否在前台展示当前商品。这是整个商品的全局控制；如果上架，则之后关联的SKU也一同上架；反之则一样。
3. 商品类型：单品/复合商品;部分平台上支持打包出售的模式，也就是一个商品实际上是包含多个关联子商品的。可以通过商品类型字段先标记出当前商品是单品还是复合商品；如果是复合商品，之后还需要关联对应子商品。

二、特有属性

在上一篇《属性管理》中，我们介绍了商品特有属性的设置以及与品类的关联绑定。在商品信息维护时，当选定品类后，我们就能获得已经设置好的配置内容，接下来根据配置将表单展示出来，并维护好其中的属性值即可。

品类绑定属性设置

规格参数维护表单

三、销售属性

在说销售属性前，我们先来了解两个基本概念：SPU和SKU。

SPU：Standard Product Unit (标准化产品单元)

SPU是商品信息聚合的最小单位，是一组可复用、易检索的标准化信息的集合，该集合描述了一个产品的特性。

SPU通俗的来讲就是一类具有相同属性、属性值的商品，这些属性和属性值通常不参与商品的销售价确定。如iphone6s就是一个SPU，无论你在那个平台或者实体店查询iphone6s，他们给出的商品属性信息都是一致的。

SKU： Stock Keeping Unit(库存量单位)

SKU即库存进出计量的单位， 可以是以件、盒、托盘等为单位。

SKU是物理上不可分割的最小存货单元，而这个不可分割是相对于储存场景的，对于相同的商品，在不同的仓储场景下，对SKU的管理是不一样的。

举个列子，我们平时去超市买早餐奶，可以买一袋，也可以买一箱。按最小单元来说，那么”袋”就是超市管理早餐奶的SKU。超市的货源是来自供应商的，供应商是按箱卖给超市的，所以”箱”是供应商管理早餐奶的SKU。

不知道大家有没有留意过，在物美、家福乐去买一箱奶，结账的时候，收银员不是扫描箱子上的条码，而是打开箱子取出一袋来进行扫码，然后再输入数量最后结账，这也就能看出这些大超市的对奶制品的管理方式。

SKU可以简单理解为：SKU = SPU 销售属性，当在SPU上添加上商家、颜色、内存等影响销售加价的属性后，这个商品就成一个SKU。

看着和上面SKU的定义有点出入，如果仔细想想，商家对商品价格的定义不就是按照商品的最小单元设置的吗？

所以当我们想要确定一个SKU时，首先需要明确有几个属性在影响价格，找到对应的属性，列出每个属性的属性值，通过属性值的组合就能确定所有的SKU。

对于销售属性的维护，也是通过属性和属性值来操作的，但是有两个特殊的地方需要处理:

1. 在完成属性值的维护后，需要根据属性值组合来生成SKU：这个是整个商品模块最关键的地方，因为后面的价格、库存、图片都依赖于生成的SKU。
2. 属性值的个性化设置：如同一款手机中的相同红色，不用商户的叫法各不相同，如炫彩红、玫瑰红等待，以及不同的颜色上会上传不同的款式的手机样式图。

维护好销售属性和属性值后，就能通过组合产品唯一的SKU，之后商品的销售价格、订单、库存等一些属性信息，都需要与SKU直接挂钩。

所以这里有一个特别需要注意的地方，一旦确定了组成商品的SKU销售属性后，就不能再做对销售属性进行修改；如果添加或删除销售属性，之前生成的SKU数据肯定就不对了，而添加或删除某个具体销售属性的属性值仅会影响部分SKU的数据。

1. 商品价格

在SKU维护时，有多个价格的设置，需要注意每个价格的用途：

1）采购价

采购人员从供应商那里采购商品时的价格，系统中有几个处会使用采购价的地方：

1. 商品采购入库时，商品的采购价格会同商品信息一起保存在入库单中；
2. 在填写商品的日常销售价和活动销售价时，会通过对比采购价，防止销售价格过低而使企业受损失；
3. 商品完成订单销售后，系统计算销售成本和应收金额时使用。

2）吊牌价

吊牌价通常是供应商在商品出厂时，为商品所设置的一个市场销售参考价，价格通常会和商品的一些质检信息一同写在商品的吊牌上。吊牌价一般在线下使用的比较多，如商场里的服装时最为常见。

在线上系统设计时，吊牌价仅仅为销售价设定起到一个参考作用，实际价格我们一般采用另一个概念——销售价，销售价又分日常销售价和活动销售价。

3）日常销售价

商品在没有参与活动时所设置的出售价格就是日常销售价格，商品在上架期间日常活动价会一直存在的。

如果是个体商户，户主自己根据进货价设定价格，如果是大的自营电商，通常由采购人员根据采购价和期望利润来确定日常销售价。

4）活动销售价

商品参与活动时所设置的销售价格就是活动销售价，活动销售价只有在活动期间有效；活动过期，商品售价又会使用日常销售价。大的自营电商里面，通常由采购人员来维护。

5）预警价

预警价格的设计主要是为了防止商品运营人员录入失误，将商品出售价格设置的过低，导致企业损失而设置的预警功能。

这个和采购价有部分类似，一般低于采购价是允许出售的。如一些即将过期的产品或拉新做的活动，但是低于预警价通常是不让出售的。

常用的两个地方：日常销售价维护和活动价维护，这两个价格在保存前都需要和预警价进行比对，如果低于预警价，系统会给出提示，以确保价格设置正确。

2. 库存

对于SKU的出售自然就涉及到了库存，在商品维护界面仅有一个对库存数维护的地方，也就是实际可售库存。

对于大平台的入驻商户来说，通常采用手动录入方式(有开发能力的可以做系统对接)，让商户自己维护SKU的销售数量。具体填写多少由商户自己决定，这个填写的数字就是实际可售库存。

而对于平台自营来说，公司通常都有自己的仓储系统，每个SKU都有明确的存储记录，并且部分SKU参与内部任务(如调拨、拍照、战略储存等)使得当前时间不可售。

因此实际的SKU库存可能并不等于全部可售，具体实际可售库存需要通过仓储系统经过统计同步到商户模块中，而不是由买手自己手动维护。

3. 上架/下架

除了在商品的基础属性上设置有商品的上架/下架操作，通过在具体的SKU上也设置一个上架/下架操作，可以更加细粒度的管理到具体的SKU上下架状态。

4. 第三方编码

平台在生成SKU时，会为每个SKU也分配相应的拣货码(可能是商品身上的条码，也可能是公司内部自己定义的编码)，以方便拣货时使用。

如果是自营平台，买手采购时供应商会提供给采购平台以便录入系统；如果是平台商户，一是平台没有办法采集数据，二是各商户各自在拣货时使用的规则各不相同，所以仅给一个可以让商户自己维护的字段。

当有订单产生时，在订单模块中导出的拣货单中会带有维护的第三发编码以供商户进行拣货操作。

5. 图片维护

商品各位置的展示图片，图片维护通常有三个地方：列表图、SKU图组和默认图组。

1. 列表图：主要是搜索列表所展示的图片；
2. SKU图组：为每个具体的SKU上传对应的一组展示图片，主要用在商品详情页的展示上；
3. 默认图组：如果对应的SKU未设置展示图片，则显示默认的这组图片进行展示。

小知识点：图片在展示时，为了能够提升图片展示速度，优化页面展示速度，商品图片在上传时通常会通过缩放，将图片保存成多个不同的尺寸，以方便不同页面进行调用。

6. 导入功能

电商平台上的商品成千上万，如果都通过常规的表单一个一个维护，维护人员就得被累死了(看一下一个电子产品有多少产品规格)，通常系统都会设计导入功能供维护人员使用。

在商品信息的导入功能里有两个限制：

一是一次只能导入一个品类，因为不用品类的特殊属性不一样，没有办法合并在一起；

二是仅能导入基础属性和特殊属性信息，销售属性信息不支持通过导入生成，因为销售属性需要通过属性值组合成SKU信息，系统需要生成唯一ID， 内部逻辑比较复杂。

【#】后面为需要导入的特殊属性列表。

上面介绍的内容，基本涵盖了一个商品的核心信息，大家有需要的可以根据自己的实际业务场景再进行优化修改。

四、商品维护流程

最后我们再来看一下商品的维护流程。

在电商平台上的个体商户，由于自家SKU数量比较少，从录入商品参数到商品拍照、上架一个人基本都能解决。

但是对于自营平台过万的SKU，这样的方式显然是不行的。大平台对一个商品的维护需要多个部门协同合作来完成，基本流程如下：

1. 采购部：买手先维护好后端品类，为每个品类绑定关联属性，并设置好属性输入方式、搜索方式等基础配置信息。
2. 采购部: 买手从供应商获取采购商品基本信息，并将商品基本信息导入系统中，并根据销售属性生成SKU。
3. 采购部：买手通过采购单采购商品，并协同仓库一同将商品录入仓库完成商品采购，系统完成SKU同步库存信息，买手完成日常销售价格的维护。
4. 采购部：买手在系统提交商品图像采集工单。
5. 图像采集部：图像采集部同事根据工单申请仓储图像采集调拨工单(将之前录入的SKU每件调拨出来一件)。
6. 仓储部：根据图像采集调拨单，准备调拨商品。
7. 图像采集部：图像采集部同事和仓储部进行交接出库，拿到样品、进行拍照、修图，完成后再上传到系统中。
8. 图像采集部：拍照完成后，将商品再还回仓库中。
9. 仓储部：将商品重新放回仓库中。
10. 采购部：买手检测商品信息完善后，就可以进行日常上架销售了。

以上四个步骤中，除了第三步采购入库、设置价格会经常使用，其它的三步仅在商品第一次录入系统的时候需要维护。

对于上述操作流程有人可能有疑问，通常不是运营在做产品销售吗，这里怎么是买手呢？

在电商企业中买手的工作范畴主要是维护商品信息、采购、维护销售价格以及下上架；而运营人员主要负责构建活动、专题框架、活动和专题中的具体商品由买手来决定是否来参与，最终的利润由双方来分(运营和买手的薪资是和销售额有关的)。

这个在后期的运营篇中会给大家继续讲解！

作者：JackLiu；个人 扬帆去远航（ID:Jackai_liu)

本文由 @Jack 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自 Pexels，基于CC0协议。

,