ERP系统:SPU和SKU的踩坑总结

2 评论 6321 浏览 32 收藏 16 分钟

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

一、SPU和SKU的关系

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

ERP系统:SPU和SKU的踩坑总结

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形成相同的结构(规格结构不一样)。

ERP系统:SPU和SKU的踩坑总结

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

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

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

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

ERP系统:SPU和SKU的踩坑总结

千牛后台截图

基于上述的情况,我查了很多资料,也问了一些朋友之后发现,如果是单纯地参考电商平台的后台处理逻辑,那么很难兼容各行各业的商家的产品。

于是我开始找了另一类竞品:电商ERP,主要还是跨境类的,例如店小秘、马帮、通途等。

结果发现它们的处理方式很巧妙,在创建商品的时候可以选择类型:

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

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

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

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

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

后来调研了跨境ERP的做法之后,我发现这两种做法都不好,具体的理由和上面的是一样的。如果当前只有一个规格,后期多了规格需要拓展的时候,在此商品SPU的基础上拓展SKU,还是会踩坑。例如删除了“白色”这个规格,然后用了其他颜色,也删除了“M”这个尺码,那么之前的「White*M」就挂不在SPU之下了。

所以我决定采用跨境ERP的做法,在创建SKU的时候要先选择类型,到底是单规格产品还是多规格产品。如果是单规格产品,那么直接就生成SKU,不能拓展所谓的规格属性;如果是多规格产品,则先生成父级SPU,然后再通过多规格属性来拓展生成具体的SKU。

而且多规格的产品,不能添加&删除原来的规格属性,只能追加对应的属性值。

例如一开始的规格属性是「颜色」和「尺码」,后续编辑的时候,只能继续追加「颜色」的属性值,或者追加「尺码」的属性值,而不能再删除「颜色」或者添加新的其他规格属性。同时也要限制不允许随意删除已生成的SKU(例如上面提到的BM和BS),要先判断SKU是否已被使用。

ERP系统:SPU和SKU的踩坑总结

有赞后台截图

所以,最终我所选择的方案是:无规格的产品直接创建一个单品SKU,不需要和SPU关联;而有规格的产品则先创建SPU之后,再通过规格来创建SKU。

当然还有更简单的办法就是,ERP中不存在SPU的概念,直接全部创建的都是SKU,用映射的方式来将电商平台的SPU下的SKU映射到系统中。这种逻辑是最简单粗暴的,利弊都很明显,只是我们要支持的业务场景,不允许这样做……

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

供应商是与SPU关联还是和SKU关联,这个也是我之前一直很纠结的一个问题。按理说,供应商提供的是具体的产品,那么自然而然应该是跟SKU关联。

但是有一部分的SKU是通过SPU的多规格属性演化而来的,如果供应商直接和SKU关联,那么则意味着创建好了SKU之后,还需要分别对同SPU但是不同SKU的产品一一设置供应商关系、供应商报价等。

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

ERP系统:SPU和SKU的踩坑总结

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

如果是创建单规格产品(SKU)的时候,将供应商信息直接挂在SKU维度上,一个SKU就维护一次。

ERP系统:SPU和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系统:SPU和SKU的踩坑总结

千牛后台截图

六、一些参考资料

最后分享一些相关参考资料给大家,如果大家对电商后台或者ERP后台感兴趣的,可以根据下面的关键词进行搜索。有一些后台账号是需要申请试用的,找个小号去申请比较好,能避免后续很多的骚扰。

  • 电商后台的竞品:千牛(淘宝商家后台)、刘志远——电商后台产品设计课程、相关图书(京东)、有赞。
  • ERP的竞品:店小秘、马帮、金蝶星辰、聚水潭。

#专栏作家#

vitamin,微信公众号:皮酱叨逼叨。人人都是产品经理专栏作家,公众号运营小白,初中级B端产品一枚(一年开发经验+三年产品经验)。主导过在线教育类产品,目前是跨境电商供应链仓储物流产品一枚,欢迎勾搭,一同学习。

本文原创发布于人人都是产品经理,未经作者许可,禁止转载

题图来自 Unsplash,基于CC0协议。

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 嗨,勤劳的皮酱~
    建议:供应商和商品的关联在实际应用中还是挺高频的,可以单独拎出来做一个管理界面的哈,方便维护采购量、价、生产周期等信息。

    回复
    1. 嗯 是会拎出来单独管理。我想表达的意思是就是供应商和商品的关联,到底是供应商直接和SKU还是和SPU。然后通过我的体验或者竞品试用,我建议是单规格产品直接和供应商关联;而多规格产品,则是用SPU的维度去和供应商关联,然后SPU下的SKU直接继承这个SPU的供应商即可。

      回复