如何设计通用商品管理系统？

凡是涉及到购物，必然是建立在商品的基础之上。

作为交易的基础，商品管理可以说是电商系统最中重要的部分，它是连接前端用户，平台商户，后台系统的桥梁，商品管理系统与采购系统PMS、订单管理系统OMS、仓储管理系统WMS、促销活动系统、物流配送系统TMS等有着紧密的联系。

商品管理体系的延展性，对于平台的运营维护有直接的影响，它在一定程度上决定了平台能走多远。

作为一个浸淫生鲜电商有些日子的产品人，我想整理下自己的所思所想，如有不足之处，还望各路大神多多指教。如能给入行的产品小鲜肉们带去一点点的帮助，那便是你我之幸事。

话不多说，先上图：

商品管理基础部分-图1

在参与过几套完整的自营生鲜电商供应链后台设计后，总结出一个商品管理系统必须包含的几个基础部分：类目管理、单位管理、品牌管理、属性管理以及一些基础信息的管理，其中最核心也是最重要的要属类目管理。

当然有些公司因为业务需要，会管理的更为精细，可能还会有商品包装管理、商品等级管理等等，这里就不一一叙述。

一般来说，我所列举的4个部分，足够组建起一个相对完整的商品体系框架，然后再根根据业务需求，在此框架上进行迭代。

一、类目管理

1. 商品类目存在的意义

后台类目：电商系统的产品数量大，通过类目将商品进行分类管理，增加商品运维管理的效率。

一般分为3级，不便过多，过多可能导致冗杂。商品挂靠在最后一级——叶子类目，也就是类目树上不能再往下分的类目，要注意类目名称不能重复；举个简单的例子：苹果–>富士苹果–>水晶富士。

后台商品主要是面向内部工作人员，相对来说较稳定很少变化。

后台类目-图2

前端类目：主要是建来方便前端销售，提高商品在前端对于客户的有效展示、搜索、查找，方便用户在海量的产品中快速精准的找到商品，从而提高成交率。

前台类目一般为2级，最多不要超过3级。商品挂靠在前台类目的最后一级——叶子类目，类目名称不能重复。

由于后台类目相对来说专业性比较强，显然我们不能要求用户都具备专业的分类素质，因此需要配置一套比较亲民的类目展示在前端。

再者，各大电商平台每到节假日/促销活动日，其前端展示的分类一般都会随之改动，这时候更改的就是前端类目，来达到促销引流的效果，而不需要去更改后台类目。

如上所述，前端类目十分灵活，运营童鞋们可以经常调整，但不是随意调整，要牢记前端类目是用来达到销售目的。

2. 两者之间的关联关系

• 前端类目通过跟后台类目映射间接和商品关联，因此用户在客户端查看前端类目时，可以查询到它关联的后台类目包含的所有商品；
• 前端类目必须关联一个及以上一级、二级、三级后台类目；
• 后台类目只能关联到前端类目的叶子类目，同时也可关联多个前端叶子类目。

前端展示一般是“后台叶子类目+前端叶子类目”结合的方式，一般水平导航放前端类目，垂直导航放后端类目。

比如每日优鲜的分类：

后端类目+前端类目

二、属性管理

商品属性管理的意义：当系统产品变的十分丰富的时候，光是简单分类已经无法满足对商品的管理了。

比如奇异果按箱头规可分12#，15#，26#，27#，28#，36#等；按品牌又有悠然、佳沛……类目的层级会越来越深，也会出现交叉和重复的问题。

这时就需要引入另外一个维度来管理具象的商品，那就是“属性”。

属性

在讲属性之前，先引入2个电商人常挂在嘴边的术语：

• SPU：标准化产品单元(Standard Product Unit),是商品信息聚合的最小单位，是一组可复用标准化信息的集合，也就是能区分是什么商品的最小单位；
• SKU：最小的库存单位(StockKeeping Unit),可以以件，盒，箱，千克等为单位存储，商品的进货、销售、售价、库存等最终都是以SKU为准的；也就是用户能够直接购买的商品，

1. 基础属性

基础属性就是组成SPU的属性，能够确认商品信息聚合的的唯一性，例如“黄金奇异果”就是一个SPU，就好比华为 P30 一样。

2. 规格属性

规格属性是组成SKU的属性，直接影响用户购买和系统的库存，比如：佳沛-黄金奇异果-26#；是前端用户可以直接购买的商品的属性。

3. 描述属性

描述属性是商品一些特性的描述。

同一个叶子类目下的商品，其属性往往差异很小，如果有规范的类目属性列表，可将属性组与类目关联。这样，新建商品时，只要选择商品类目，商品属性就自动带出，可有效减少商品维护人员的工作。