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

一、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这两个东西折磨的，还有踩过的坑分别有哪些。

二、SPU删除规格之后怎么处理？

基于电商后台的规则，SKU是通过SPU的多规格来生成的，例如在创建SPU的时候，选择不同的规格，然后不同的规格就会通过笛卡尔乘积，生成不同的SKU。在梳理这一块的逻辑的时候我就发现了一个问题：如果一个SPU的规格属性有两种「颜色」和「尺码」，然后在「颜色」中有“红色”、“蓝色”，在「尺码」中有“S”和“M”，则意味着一共是会生成四个SKU。但是如果允许后期修改规格（修改规格属性或者修改规格值）的内容的话，会重新生成SKU，同时老的SKU在这里就无法体现了（因为规格不存在或者属性不存在）。例如下图，如果将“蓝色”改成“绿色”，那么应该重新生成SKU，但是原来的“蓝色”规格的SKU就“消失”了。还有如果一些创建商品的时候没有选择规格，然后只是生成了一个SKU，后续如果要增加规格的时候，那么原来的商品也不能和后续多规格衍生的SKU形成相同的结构（规格结构不一样）。

如果SKU编码BS和BM是在库的、有库存的，那么直接删除这两个SKU显然是不合理的，但是由于电商的管理应该大多数是基于SPU层面，所以如果修改了规格属性（电商也叫销售属性），那么被更改了的那个应该不能再出现了，类似于此款停产或者不再售卖了。下图是淘宝的千牛后台，发布商品的时候先选择对应的类目后，会给出对应的销售属性，而且是都必填，所以不存在中途增加和修改销售规格的情况出现。但是ERP系统就不会有这么严谨的逻辑，而且也没有对应的类目信息。所以这一块如果限制死了，不允许客户添加规格，那么就可能会满足不了一些多规格的商品的信息维护；如果放开了限制，那么用户就可以随意调整对应的规格信息，那么生成的SKU可能就会和原SPU断开关联。

千牛后台截图基于上述的情况，我查了很多资料，也问了一些朋友之后发现，如果是单纯地参考电商平台的后台处理逻辑，那么很难兼容各行各业的商家的产品。 于是我开始找了另一类竞品：电商ERP，主要还是跨境类的，例如店小秘、马帮、通途等。 结果发现它们的处理方式很巧妙，在创建商品的时候可以选择类型：

单规格产品，也可以称为无规格产品；
多规格产品，可以自由添加规格进行变换。

单规格产品不能转为多规格，如果需要增加规格，则需要重新创建SPU再生成SKU；多规格产品也不能转为单规格产品，多规格产品一定要选择至少一项规格属性。这样一分类，就将很多复杂的场景给隔离开了，只需要重点关注多规格产品的管理即可。

三、无规格的产品怎么创建SKU？

在没有仔细地调研跨境ERP的做法的时候，关于无规格的产品怎么创建SKU的问题，我们内部讨论了两种方案。

直接创建SPU的时候，不填写规格信息，当没有规格信息的时候，默认SPU对应一个SKU，即一对一的关系；
创建SPU的时候，填写一个规格，例如衣服就只有一个型号「白色的中码」，那么就是创建一个规格「White*M」。

后来调研了跨境ERP的做法之后，我发现这两种做法都不好，具体的理由和上面的是一样的。如果当前只有一个规格，后期多了规格需要拓展的时候，在此商品SPU的基础上拓展SKU，还是会踩坑。例如删除了“白色”这个规格，然后用了其他颜色，也删除了“M”这个尺码，那么之前的「White*M」就挂不在SPU之下了。所以我决定采用跨境ERP的做法，在创建SKU的时候要先选择类型，到底是单规格产品还是多规格产品。如果是单规格产品，那么直接就生成SKU，不能拓展所谓的规格属性；如果是多规格产品，则先生成父级SPU，然后再通过多规格属性来拓展生成具体的SKU。 而且多规格的产品，不能添加&删除原来的规格属性，只能追加对应的属性值。 例如一开始的规格属性是「颜色」和「尺码」，后续编辑的时候，只能继续追加「颜色」的属性值，或者追加「尺码」的属性值，而不能再删除「颜色」或者添加新的其他规格属性。同时也要限制不允许随意删除已生成的SKU（例如上面提到的BM和BS），要先判断SKU是否已被使用。

有赞后台截图所以，最终我所选择的方案是：无规格的产品直接创建一个单品SKU，不需要和SPU关联；而有规格的产品则先创建SPU之后，再通过规格来创建SKU。 当然还有更简单的办法就是，ERP中不存在SPU的概念，直接全部创建的都是SKU，用映射的方式来将电商平台的SPU下的SKU映射到系统中。这种逻辑是最简单粗暴的，利弊都很明显，只是我们要支持的业务场景，不允许这样做……

四、供应商与SPU&SKU的关系

供应商是与SPU关联还是和SKU关联，这个也是我之前一直很纠结的一个问题。按理说，供应商提供的是具体的产品，那么自然而然应该是跟SKU关联。但是有一部分的SKU是通过SPU的多规格属性演化而来的，如果供应商直接和SKU关联，那么则意味着创建好了SKU之后，还需要分别对同SPU但是不同SKU的产品一一设置供应商关系、供应商报价等。从操作层面来说，用户要做多次重复的工作；从设计层面来说，有很多可复用的属性没有复用到……

创建多规格产品（SKU）的时候，将供应商信息挂在SPU维度上，然后SKU继承这些信息，就避免了逐个SKU维护供应商的繁琐操作。 如果是创建单规格产品（SKU）的时候，将供应商信息直接挂在SKU维度上，一个SKU就维护一次。

通途ERP截图通途ERP也是这样的做法，比较清晰明了。

五、SKU如何编辑？可以编辑哪些信息？

上面提到了，我们创建了SKU的时候有两个入口，一个是创建单规格产品，一个是创建多规格产品。所以对应的，我们编辑SKU的入口也有两个，一个是从SPU层面进入编辑，另外一个是从SKU的层面进入编辑。期初我一直觉得既然创建好了SKU，那么其实在ERP中，SPU基本上就没啥作用了，所以编辑只需要在SKU层面即可。但是随着对业务的分析，以及对SPU和SKU的关系的进一步熟悉，我发现如果只是在SKU层编辑就会出现一些很奇怪的问题。例如「iPhone 12 国行」可以算作是一个SPU，然后“iPhone 12 国行红色 64G”（简称为：红色64G）和“iPhone 12 国行白色 128G”（简称为：白色128G）则是其所对应的SKU。如果我将所有的编辑都放在SKU层面，那么我自然而然可以编辑一些“基础信息”、“非关键属性”、“销售信息”等。如果只是编辑“销售信息”那么还没什么问题，因为不同的SKU就是因为销售属性不一样而做的区分。但是如果允许编辑一些“基础信息”，例如说“名称”、“描述”、“类目”等，那么可以将“iPhone 12 国行红色 64G”改成“苹果12 中国红 64G”，也可以改成“苹果11 白色 64G”等等，这样就会乱套了。所以，SKU的编辑应该遵循和创建的逻辑相同，也要符合SPU和SKU的关系的定义。有两个入口创建，也就有两个入口编辑。同时，不同的入口可以编辑的信息是不一样的。 SPU维度编辑的“基础信息”等应该是复用在所有的SKU层面的，即改了SPU的信息则SKU的信息也要改；SKU维度的编辑，只能是一些自己独立的属性，例如“售价”、“库存信息”、“采购价格”等。