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

20 评论 31645 浏览 215 收藏 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协议。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 前前后后一共看了5遍,收获很大,谢谢作者分享

    回复
  2. 你好,请教个问题。我们的商品模型设计比较灵活,把SPU的基础属性和sku的销售属性都设计成可配置。这样就造成一个问题,比如类目下设置的基础属性改成销售属性,那么这个类目下已有spu就有可能重复,需要合并SPU,迁移sku 和spu 的关系。这样做会有什么问题?或者有没有更好的解决方案?还是确定了类目下的基础属性就不能再修改?

    回复
  3. 估值核算

    回复
  4. SPU就是商品基本数据,SKU应该是销售层的产品分类,比如毛衣+颜色+尺寸是SPU,毛衣、红色、小号,价格+销售策略(如返利、买赠)这属于一种SKU。SPU就是元数据,SKU是销售数据,前者来自供货商,后者来自平台二次编辑,因为很多电商货源是采用了第三方供应链API接口选品供货,不是自己寻找厂家或者实体供货商模式,供应链合作的对象可能就是京东、苏宁、国美这些,自己只是三道贩子

    来自上海 回复
  5. 在建spu时,默认选一个版本规格呢?但是版本规则及其属性在前台不展示,这样关联sku是否合理

    来自北京 回复
  6. 通过简单粗暴的 sku映射到spu里面不同规格这种方式有什么弊端吗?我倒觉得挺灵活的,在为spu新增多个规格的时候,只要有sku关联,就显示可以售卖,没有关联的,置灰不可买;然后对于供应链端来说,以sku为维度感觉更合适,就以手机来举例,不同内存的价格不一样,关联的采购订单可能也是多行,如果以spu为维度的话,可能没有这么细致

    来自浙江 回复
    1. 用SKU是很灵活,但是要考虑平台设计的问题,平台需要SPU,供应链可以用SKU

      来自广东 回复
  7. 讨教一下,不同的规格通过笛卡尔乘积,生成SKU列表;那这种方式,我怎么给商品添加新的SKU?选择新的属性,通过笛卡尔积会生成重复的SKU,怎么办?

    来自福建 回复
    1. 对的,这个就是很尴尬的问题,如果你增加了属性,那么之前的历史SKU也会增加属性,如果你不想改动原来的SKU,那么就只能让新增加的属性无效。
      例如之前只有 尺码+颜色,现在增加了要一个产地,那么必然之前的组合都要加上产地这个属性,如果是一些空的或者没用的SKU则设置 不使用或者库存变成0

      来自广东 回复
    2. 不赞同这种观点。通过合理的界面交互设计 完全不存在你说的这种情况。我们可以把商品设计成多属性规格的SPU,在创建sku时对于规格属性的选择设计成可配置的即可,

      来自福建 回复
  8. 你好,可以推荐本erp的书籍吗

    来自天津 回复
    1. 如果是产品的话,好像没什么ERP相关的书籍很吻合;如果是想要看供应链相关的知识,可以看看刘宝红的一些书籍。

      来自广东 回复
    2. 好的,谢谢

      来自天津 回复
    3. 也可以看我的公众号,里面我有推荐过一些书单。

      来自广东 回复
  9. 你好,我现在也在设计一个ERP系统,看到你的文章,解决了我的一些疑惑,但是有一点疑问 。
    “直接创建SPU的时候,不填写规格信息,当没有规格信息的时候,默认SPU对应一个SKU,即一对一的关系”这是你们否定得一个方案,但是我目前是按这种方式去设计的,即创建无规格商品,同时生产一个SPU和SKU信息,创建之后(或有订单记录后)就不能再添加规格项。
    我认为这种方式和文章里说的创建无规格商品,是一样的效果。麻烦您解答一下。

    回复
    1. 嗯,你的方案是对的。当时我在写这篇文章的时候,我一直认为SPU没有规格,不创建SKU,那么单独存在一个SPU是很奇怪的,不合理的。

      但是最近我在研究电商平台的商品同步接口的时候发现,其实没有规格的产品还是会有SPU但是没有SKU的情况,所以ERP为了兼容这种场景,其实应该做到:没有规格的SPU也可以创建SKU,SKU编码和SPU编码一致。

      然后你说的那种方式,其实和创建普通产品和多规格产品是一样的,不过我感觉分成两个入口可以让用户感知更加清晰一点,避免出现创建了SPU无规格又想要改成又规格的情况。

      来自广东 回复
    2. 如果还有疑问的话可以加WX联系一下:vitamin_mpp

      来自广东 回复
    3. 贩卖虚拟物品的时候,这种情况确实很多。包括现在像千牛的后台,当你的商品只有spu的时候,也是可以上架的。比如我们自己的,全面家庭套餐999,它直接在描述上体现了,不需要任何sku。千牛它后台的存储应该就是spu。包括有赞的后台,甚至sku的创建直接开放给了商家。

      回复
  10. 嗨,勤劳的皮酱~
    建议:供应商和商品的关联在实际应用中还是挺高频的,可以单独拎出来做一个管理界面的哈,方便维护采购量、价、生产周期等信息。

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

      来自广东 回复