ERP 系统：SPU 和 SKU 的踩坑总结
vitamin 
关注作者
编辑导语：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 维度的编辑，只能是一些自己独立的属性，例如 “售价”、“库存信息”、“采购价格” 等。
千牛后台截图
六、一些参考资料
最后分享一些相关参考资料给大家，如果大家对电商后台或者 ERP 后台感兴趣的，可以根据下面的关键词进行搜索。有一些后台账号是需要申请试用的，找个小号去申请比较好，能避免后续很多的骚扰。
- 电商后台的竞品： 千牛（淘宝商家后台）、刘志远——电商后台产品设计课程、相关图书（京东）、有赞。
- ERP 的竞品： 店小秘、马帮、金蝶星辰、聚水潭。
#专栏作家
vitamin，微信公众号：皮酱叨逼叨。人人都是产品经理专栏作家，公众号运营小白，初中级 B 端产品一枚（一年开发经验 + 三年产品经验）。主导过在线教育类产品，目前是跨境电商供应链仓储物流产品一枚，欢迎勾搭，一同学习。
本文原创发布于人人都是产品经理，未经作者许可，禁止转载
题图来自 Unsplash，基于 CC0 协议。
若有收获，就点个赞吧
0 人点赞
