前面两篇文章分别介绍了商品管理系统中的类目设计和属性库搭建，它们只是为商品管理起到辅助的作用，而商品管理真正的核心在于商品，所谓无商品不电商。

01 什么是商品系统

商品管理系统属于电商产品中最基础、最核心的系统，是支撑整个电商产品的核心，基本上所有的系统都离不开商品数据，商品贯穿整个电商平台。从商品的采购、到达仓库、商品上架、前台的展示、下单、物流配送、收货、售后服务等，整个流程都离不开商品。后台商品系统一般分为，类目管理、属性库、品牌管理、商品管理（发布商品、编辑商品、商品上下架、审核、价格库存设置、运费模板设置等），本篇文章主要和大家分享后台商品管理。

02 SPU和SKU

电商产品中不得不了解的两个名词，SPU和SKU。前面两篇文章虽然有提到，但没有详细的解释它们具体的含义，在这里必须要详细的解释一下。

SPU（Standard Product Unit）：标准化产品单元，是商品信息聚合的最小单位，是一组可复用、易检索的标准化信息的集合，该集合描述了一个“产品”的特性。通俗点讲，属性值、特性相同的商品就可以称为一个SPU。前面文章提到过，类目系统中的关键属性能够确定一个SPU，它可以确定某一类商品，但不能确定具体的某一个商品。例如：苹果手机+Iphone X（品牌+型号）能够确定一个SPU。

SKU（Standard Keeping Unit）：库存量单位，即库存进出计量的基本单元，也可以说SKU就是库存的最小单位（个、件、盒、托盘等）。每个SKU都拥有不同的编码。前面文章同样提到过，类目系统的销售属性能够确定一个SKU，它可以确定具体的某一个商品。例如：苹果手机+Iphone X+12G+黑色，能够确定一个SKU。简单的可以理解为，用户在商品详情页，只有选择了具体的商品规格信息，才能够显示出价格和库存量。

SPU、SKU、商品的关系

SPU与SKU的关系一般是一对多或者一对一的关系，SPU包含多个SKU，SKU是SPU的子集，而商品是SKU的具象化实物。例如：森马+工装男鞋，可以代表一个SPU；再加上颜色和尺码，森马+工装男鞋+黄色+41码，可以代表一个SKU。

有些特殊情况下，一个SKU也可能对应多个SPU，不过此种情况比较少见。例如：某家店铺中同样的一款鞋子，当作两种商品上架在商店中，起了两个名字（森马工装男鞋、森马复古休闲男鞋），此时在前台展示的是两种商品，而后台系统中对应的是一款商品（一个SKU编码对应两个SPU编码）。

为方便理解，笔者简单绘制了SPU、SKU、商品的关系。

除了以上情况之外，根据卖家实际业务场景不同，商品系统中还有一种商品类型叫做商品套装或者组合商品，此种业务场景相对比较复杂。

例如运动健身衣套装（两件套、三件套、四件套…）在前台用户购买下单的时候是一个商品，而后台的处理逻辑是将n个SKU组合关联成一个虚拟的SKU，下发到仓库后将虚拟SKU拆解，按照实际的SKU扣减库存，在发货的时候将n个SKU对应的商品打包成一个包裹送到用户手中。

03 商品管理

前面一系列的准备工作都是为了商品的管理，包括类目、属性库的设计，以及本篇文章提到的SPU和SKU，只有把这些全部搞清楚了，才能了解商品管理系统是怎么“玩”的，才能真正读懂电商平台的核心系统——商品管理。

商品管理其实说白了就是对商品的维护管理工作，包括发布（新增）商品、商品的上下架、商品修改、商品的查询、设置运费模板等。如下图是商品管理的界面；

1. 发布（新增）商品

商品的创建或者发布之前，应先选择挂靠类目，商品调用类目中挂载的属性，生成对应的属性模板，通过关键属性和销售属性（规格属性）去关联SPU和SKU，同一SPU在前台显示可共用同一商品详情，但需要通过销售属性（规格属性）映射到具体的SKU。

京东是以SKU维度进行管理的，淘宝和天猫是以SPU维度进行管理的。（京东切换商品规格时标题和商品详情改变，淘宝和天猫切换商品规格时标题及商品详情不变）

为了保证新发布的商品信息正确性，降低发布违规商品的风险，因此需要平台运营人员进行审核，才能保证平台发布商品的质量，审核通后方可正常上下架商品。一般常见的审核流程如下图（仅供参考）；

发布（新增）商品时，商品信息一般有商品基本信息、商品属性、商品图文描述、支付信息、物流信息、售后服务等部分组成。

• 商品基本信息

商品的基本信息是对商品的基本描述，一般是指用户浏览商品时第一眼看到的信息，根据平台的业务不同该部分会有略微的区别，但一般都主要是商品的所属类目信息、商品标题（商品名称）、品牌信息、商品编码（也叫69码）、商品属性、广告语等信息。

• 商品属性

商品属性通常包括关键属性、销售属性、商品属性、普通属性这四种，根据自己公司的实际业务，还可以进行其他属性的分类，例如特殊属性、绑定属性等。

笔者在属性库搭建一篇文章中有详细讲解关于商品的属性，如何从零到一搭建属性库，属性又是如何与商品类目关联的。感兴趣的同学可前去阅读，商品管理系统设计（二）：属性库搭建

• 商品图文描述

包括商品图和商品描述，商品图片一般包括，商品主图、商品轮播图，以及商品活动图；商品描述是针对图片附加的文字说明，可填可不填。

• 库存设置

库存设置是针对商品的销售属性（规格属性），即商品的SKU，设置对应价格和库存，不同规格的商品对应不同的价格和库存，当商品库存销售为0时会自动下架。一般SKU库存同步WMS系统中库存，即实物库存，或者人工设置活动库存。商品库存数量与库存系统、WMS系统之间进行数据交互，在前台显示。关于库存系统，后面更新文章笔者会专门分享。

• 支付信息

一般是指用户在拍下商品时的付款方式和拍下商品时的库存计数方式。

付款方式分为一口价（普通交易模式）、预售模式、货到付款等。一口价是指提交订单时一次付清；预售模式是指先付一部分定金，等到商品开始售卖时，将尾款付清。货到付款比较容易理解，就是用户确认收货后再支付。

库存计数分为拍下减库存和付款减库存。拍下减库存会存在用户恶意拍单，而不买的风险；付款减库存会存在平台或商家超卖的风险。两种方式各有利弊。

如下图是淘宝发布商品页中的支付信息。

• 物流信息

主要是根据商品具体情况选择提前设置好的运费模板，若没有符合要求的运费模板，可前往物流系统进行设置后再使用。

• 售后服务

一般是商品售后对用户的承诺，例如，退换货承诺（7天无理由退换货等）、假一赔十…根据商品不同售后服务不同。如下图是淘宝发布商品页中售后服务。

2. 商品上下架

商品管理中的商品分为在售商品（上架中的商品）和待售商品（下架中的商品），发布商品时也可以设置自动下架或者定时上架规则。

将商品分为在售商品和代售商品两个模块，只要便于平台运营人员或者商家管理商品。在日上运营过程中，商品下架的原因有很多，对应的处理方式也不同，例如系统自动下架、商家自主下架等。

系统下架的场景一般有违规、品牌到期、店铺迁移等，对应常见的原因有风控系统管控下架、店铺迁移或者关闭、类目变更、平台运营操作等。在设计产品时要尽可能罗列出有关系统下架的场景和原因，以供运营人员通过下架原因告知商家进行整改。

3. 商品编辑

商品编辑同发布商品（新增商品）的功能一样，是对已经发布的商品的信息进行修改，修改过后系统会判定是否新增的商品，若是新增的商品上架时要走审核流。

4. 商品删除

商品删除是对不在进行销售的商品删除，上架状态的商品不可删除。

5. 设置运费模板

在商品管理模块中有设置运费的入口，直接进入到物流系统设置运费模板，设置好运费模板之后，在发布（新增）商品时直接使用。订单处理会根据物流信息计算运费，计价方式一般分为按件计算、按重量计算、按体积计算，如图运费模板是按件数计价。关于物流系统，后面更新文章笔者会专门分享。

6. 商品状态流转

商品状态分为新增、待审核、审核通过、审核未通过、已上架、已下架、失效、有效待审核共8个状态，笔者为大家梳理了一张商品在整个流程中的状态流转图（仅供参考）。

平台运营或者商家在发布（新增）商品时，若无对应的商品需要走审核流，若有对应的商品无需审核，发布（新增）商品成功后，方可直接操作商品的上下架。

04 总结

商品管理系统是电商平台的基础，是其他系统所依赖的基础数据系统，在建立电商平台初期就要规划好系统的每个模块，需要考虑每个模块的可扩展性，减少耦合性。避免后期产品扩展时遇到瓶颈，后期若再进行系统规划调整，会产生巨大的成本。因此打好基础，对电商平台后续业务规模的发展起到至关重要的作用。

#相关阅读#

商品管理系统设计（一）：类目设计怎么做？

商品管理系统设计（二）：属性库搭建

作者：Rocky；公众号：超悦产品

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

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