淘宝sku图片尺寸(ERP系统：SPU和SKU的踩坑总结)

编辑导语: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断开连接。

黄牛后台截图

基于以上情况，我查了很多资料，问了一些朋友，发现如果单纯参照电商平台的后台处理逻辑，很难兼容各行各业商家的产品。

于是我开始寻找另一类竞品:电商ERP，主要是跨界类型的，比如店小二、大篷车、通途等等。

原来它们处理的很巧妙，你可以在创造商品的时候选择类型:

单规格产品不能转换成多规格。如果需要增加规格，需要重新创建SPU和SPU已生成。多规格产品不能转换成单一规格产品。多规格产品必须至少选择一个规格属性。有了这个分类，很多复杂的场景就被隔离了，我们只需要专注于多规格产品的管理。

在没有仔细调查跨境ERP实践的情况下，我们在内部讨论了两个关于如何为没有规格的产品创建SKU的方案。

后来调查了跨界ERP的做法，发现这两种做法都不好，具体原因同上。如果目前只有一个规范，后面还有更多规范要扩展，SKU如果在这个产品SPU的基础上扩展，还是会踩坑的。例如，如果删除了“白色”的规格，然后使用其他颜色，并且也删除了“M”的大小，则之前的“白色*M”不会挂在SPU下。

所以，我决定采用跨界ERP的方式。在创建SKU的时候，首先要选择类型，是单规格产品还是多规格产品。如果是单规格产品，那么会直接生成SKU，所谓的规格属性无法展开。如果是多规格产品，王先生成为父SPU，再通过多规格属性扩展生成特定SKU。

多规格产品不能增加和删除原规格属性，只能追加相应的属性值。

例如，初始规格属性是颜色和大小。后期编辑时，只能添加颜色或大小的属性值，不能删除颜色或添加新的其他规格属性。同时还需要限制生成的SKU(比如上面提到的BM和BS)不允许随意删除，需要判断SKU是否被使用过。

有好的背景截图。

所以最后我选择的方案是:可以直接为没有规格的产品创建单个SKU，不需要关联SPU对于有规范的产品，首先创建SPU，然后通过规范创建SKU。

当然还有更简单的方法。ERP中没有SPU的概念，所有的SKU都是直接创建的，电商平台SPU下的SKU都是通过映射的方式映射到系统中。这个逻辑最简单粗暴，利弊明显。这只是我们想要支持的业务场景，而这是不允许的...

供应商是与SPU关联还是与SKU关联，也是我之前一直纠结的问题。按理说，供应商提供具体的产品，那么自然应该与SKU联系在一起。

但是有些SKU是通过SPU的多规格属性进化而来的。如果供应商与SKU直接关联，则意味着创建SKU后，需要设置供应商关系、供应商报价等。对于具有相同SPU但不同SKU的产品。

从操作层面来说，用户要做很多次重复的工作；从设计层面来说，有很多可重用的属性没有被重用到…

在创建多规格产品(SKU)时，将供应商信息挂在SPU维度上，然后SKU继承这些信息，避免了逐个维护供应商的繁琐操作。

如果在创建单一规格产品(SKU)时，供应商信息直接挂在SKU维度上，将会维护一次SKU。

通途ERP截图

通途ERP也是这样，比较清晰。

如上所述，当我们创建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》的编辑应该遵循与创作相同的逻辑，也符合对《SKU》与《社会主义大众文化》关系的界定。有两个条目要创建，所以有两个条目要编辑。同时，不同的门户可以编辑不同的信息。

SPU维度编辑的“基本信息”要在所有SKU级别重用，即SPU的信息改变了，SKU的信息也会改变；SKU的编辑只能是一些独立的属性，比如售价、库存信息、进价等。

黄牛后台截图

最后和大家分享一些相关的参考资料。如果你对电子商务背景或者ERP背景感兴趣，可以根据以下关键词进行搜索。有一些后台账号需要申请试用。还不如找个小号来申请，可以避免很多后续的骚扰。

#专栏作家#

维生素，微信微信官方账号:皮酱唠叨。人人是产品经理专栏作家，微信官方账号运营小白，初中B端产品(一年开发经验加三年产品经验)。领先的在线教育产品，目前是跨境电商供应链仓储物流产品，欢迎勾搭一起学习。

本文由人人作为产品经理原创发布，未经作者允许，禁止转载。

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