电商后台系统改造项目笔记(2)商品管理模块

电商后台系统,首先得有“商品”,才能开门做生意,对吧?所以这一篇,我想聊聊商品管理模块。

我手头这个项目,面临的现状是,没有统一的商品管理机制。什么意思呢?我们承接App商城的订单系统,本身具备一定的商品管理能力(上下架、管理前台库存);订单系统将订单同步给ERP后,ERP生成自己的销售订单,ERP本身也得管理一套商品的命名、编码、库存等信息;我们还有其他对外销售入口,这些入口也有自己的商品管理后台。

这种分散管理机制会导致什么后果呢?我就举个最简单的例子吧。只要某个系统中改了一个商品名字,与ERP之间的订单同步就会出错。有时候,这种问题挺令人哭笑不得的。

为了解决上面提到的这些问题,我们决定在新的后台系统中,用一个专门的模块来管理商品。其他模块/系统凡是需要用到商品基本信息的(如商品名称编号、规格等),都从这个模块来调用即可。

我之前也没有很深入了解过电商的运行机制,借这次项目的契机,便好好调研了一番,恶补了许多基础知识。其中,就包括SPU与SKU的区别问题。

我发现,我司的电商销售模式是没有SPU概念的,纯粹是一个个的单品。虽然我司上架的商品种类不算多,不过也有典型的适合SPU/SKU模式的商品,如服装(有很多尺码)。既然是重新做一个系统,那么,现代电商的先进经验,咱们总得借鉴一番对吧。

关于SPU/SKU的概念,我这里就不多废话了,相关知识,感兴趣的可以自行Google。SKU是靠规格/属性与SPU关联起来的。至于什么是规格,什么是属性,一开始我看了很多文章,各家有各家的说法,例如有人区分为销售和非销售属性,有人区分为基础和非基础属性,看得我头都大了。静下心来对比一番后发现,叫什么名称不重要,重要的是你得能理解SKU区别于SPU的本质所在。

一句话总结:凡是能够区分和影响商品的价格和库存的指标,就是决定SKU定义的关键指标。

怎么理解?以手机这种商品为例,通常来说,颜色、运行内存和储存内存,决定了某款手机(SPU)到底有多少种型号(SKU)。例如,iPhone 8 Plus是一种SPU,其中,银色64G版本和银色256G版本,显然价格是不一样的,可以认为是两种SKU。

所以呢,我们现在可以很容易地理解各种术语了:

  • 规格:决定SKU定义的指标
  • 属性:“规格”之外都可以称之为属性

说个题外话,由于前端研发资源的欠缺,我们在做SKU规格的创建时,挺费劲的,最后勉强实现了。在数学上,这玩意儿叫做“笛卡尔积”。当时我在网上发现很多人提及当年淘宝UED官网的一篇文章《sku组合查询算法探索》,但是官网已经消失了,还好我通过强大的Google发现了原作者的新窝,原文可以参考这里

电商系统中,有个重要的概念叫做“类目”,也就是商品的分类。大的电商公司,前后台类目是有区分的,中小电商就不一定了,有可能前后台保持一致的类目。据说,这种前后台类目的管理方式,是从实体零售行业获得的灵感。以沃尔玛为例,后台仓库的商品分类肯定是在一个时期内不会有太大变动的,但是前台(超市店面内)的商品摆放分类却会经常变动。前后台类目通过人为的映射,关联起来。

在商品管理模块,可以单独控制每个SKU的上下架,以及前台库存(人为设定的可销售库存)。就我司的实际情况来说,商品类目没有那么多,除了基本的商品描述外,也没有多少需要精细控制的内容了。

商品的统一管理是基础中的基础。做好了这个模块,我们才能做采购、销售和库存的功能。

发表评论

电子邮件地址不会被公开。 必填项已用*标注