编辑导语：SPU和SKU是电商后台和ERP后台的重要单元。SPU即标准化产品单元，SKU即最小库存单元。而电商后台系统设计与ERP系统设计有所不同，单纯地借助电商后台管理系统设计，将导致ERP设计上有所误差。本文作者结合其工作经验对ERP系统设计中的SPU和SKU设置进行阐述，一起来看一下。

关于SPU和SKU的基础概念的了解，建议大家还是看看一些关于电商的书籍介绍，在此我就不做过多的整理，直接从《电商产品经理兵法：基于SaaS的电商系统设计与实践》此书中搬运一些基础概念过来。

1. 什么是SPU？

SPU即标准化产品单元，是一组可复用、易检索的标准化信息的集合。该集合描述了一个“产品”的特性。

通俗来说，属性值、特性相同的商品就可以称为一个SPU。也可以说，SPU是一个抽象出来的模板。

一般来说，类目系统中的关键属性（品牌、货号等）能够确定一个SPU，例如，iPhone 6就是一个SPU，诺基亚N97也是一个SPU，这与商家无关，与颜色、款式、套餐也无关。

SPU的属性是分类属性的子集。只要用户在SPU中定义了属性，那么用户在录入商品时，就不需要再次录入，也不可以更改。

摘自《电商产品经理兵法：基于SaaS的电商系统设计与实践》

2. 什么是SKU？

SKU即单品/最小库存单元。目前，SKU在各种零售商品中应用得非常普遍。例如，某款衣服是一件商品，不同颜色、不同尺码的该款衣服，对应不同的SKU。SKU比较简单，就是把销售的值组合存放，再加上库存、价格。例如，该款衣服的黑色大号共有5件，每件20元；红色小号共有3件，每件21元。

摘自《电商产品经理兵法：基于SaaS的电商系统设计与实践》

3. 电商后台与ERP的商品管理差别

电商后台往往不会直接有SKU层面的管理，都是在「商品管理」中处理，也就是在SPU层面来管理。主要涉及的操作有商品发布、编辑/修改、商品上/下架、提交商品审核等。

而ERP中，往往是在SKU层面进行管理的，例如发起采购、创建订单、查看库存、出入库单据等，都是关联的SPU。

所以在设计ERP的商品管理功能的时候，如果只是单纯地参考电商后台的管理，很容易踩坑，也很不太能理解背后是怎么运作、怎么管理的。

前段时间我刚好在调研这一块的业务，既调研了电商后台商品管理的一些逻辑，也上手试用了好几款ERP的商品管理，有一些疑惑已经解开，同时也有一些踩下的坑让我记忆犹新。

所以此文就来谈谈前段时间我是怎么被SPU和SKU这两个东西折磨的，还有踩过的坑分别有哪些。

基于电商后台的规则，SKU是通过SPU的多规格来生成的，例如在创建SPU的时候，选择不同的规格，然后不同的规格就会通过笛卡尔乘积，生成不同的SKU。

在梳理这一块的逻辑的时候我就发现了一个问题：如果一个SPU的规格属性有两种「颜色」和「尺码」，然后在「颜色」中有“红色”、“蓝色”，在「尺码」中有“S”和“M”，则意味着一共是会生成四个SKU。

但是如果允许后期修改规格（修改规格属性或者修改规格值）的内容的话，会重新生成SKU，同时老的SKU在这里就无法体现了（因为规格不存在或者属性不存在）。

例如下图，如果将“蓝色”改成“绿色”，那么应该重新生成SKU，但是原来的“蓝色”规格的SKU就“消失”了。还有如果一些创建商品的时候没有选择规格，然后只是生成了一个SKU，后续如果要增加规格的时候，那么原来的商品也不能和后续多规格衍生的SKU形成相同的结构（规格结构不一样）。

如果SKU编码BS和BM是在库的、有库存的，那么直接删除这两个SKU显然是不合理的，但是由于电商的管理应该大多数是基于SPU层面，所以如果修改了规格属性（电商也叫销售属性），那么被更改了的那个应该不能再出现了，类似于此款停产或者不再售卖了。

下图是淘宝的千牛后台，发布商品的时候先选择对应的类目后，会给出对应的销售属性，而且是都必填，所以不存在中途增加和修改销售规格的情况出现。

但是ERP系统就不会有这么严谨的逻辑，而且也没有对应的类目信息。

所以这一块如果限制死了，不允许客户添加规格，那么就可能会满足不了一些多规格的商品的信息维护；如果放开了限制，那么用户就可以随意调整对应的规格信息，那么生成的SKU可能就会和原SPU断开关联。