商品子系统设计

一、前言

一个完整的电商系统,包含用户中心、商品中心、订单中心、促销系统、库存管理、物流管理等,对于平台类电商都叫中心,这样显得比较高大尚,而对垂直类电商充其量只能叫子系统,不然别人会觉得你吹牛B。正如客户是一个CRM系统的核心,一切都围绕客户搭建,商品是电商系统的核心,一切围绕着商品搭建,商品系统设计是否合理是很关键的一件事,本文就讲一下商品的基础概念以及近四年我负责三个系统商品子系统的抽象和设计。

二、商品概念

1、类目

即分类树,一般平台电商肯定是分前后台类目,而垂直电商为了简单一般不分前后台用同一套类目树,关于类目的设计可以参考 《类目体系设计总结》。

2、SPU

Standard Product Unit,即标准化产品单元,是商品聚合的最小单位,讲人话就是特性相同的商品就可以称为同一个SPU。商品的特性可以描述为由多个 “属性|属性值” ,如果“属性|属性值”完合相同的商品可以抽象为一个SPU.

3、SKU

Stock Keeping Unit,即库存量单位,是库存控制最小的单位,讲人话就是你对商品是按什么维度进行库存管理的,就根据这个来抽像。

4、属性

分为关键属性(能够唯一确定商品的属性,必填项)、销售属性(是组成SKU的属性)、非关键属性。这个对于平台电商很重要,对于垂直电商不一定要引入这个概念。

SPU和SKU的区别,最常用一个举例是用手机,比如一个品牌+型号 (IPhone+6S)就可以确定一个SPU,而SPU+颜色(金色/黑色)就组成一个SKU。如何抽象SPU和SKU这相当关键,这决定了实体之间对应关系是一对一,还是一对多,如果设计不好,系统结构将会变得很混乱。其实说白了做业务系统开发最关键还是把实体之间关系以及数据流理清楚。

三、挖机报价系统商品设计

这个系统主要包含采购、出入库管理、报价销售、售后服务(工单材料),客户线索管理、成本利润计算等,业务方的原始需求很粗略,几乎全靠我们自己去想,开发模式采用快速原型开发法,说白了就是我把产品原型构思出来,然后让前端用Vue Element把界面画出来,然后和业务方过一下(注:这是理想情况),实际上业务方是要求系统能跑通他们再体验,然后再提出修改建议,这样逐步迭代出来。然后我是如何把商品的SPU以及SKU抽象出来呢?

首先要理清在系统里进行售卖的有哪些商品,这些商品有什么特性,是按什么去定价,以及如何做库存管理,挖机系统的商品主要是包含各种主机、部件、零件、以及各种服务。(注:对于服务可以也可以抽象为一个商品,比如售后服务3年需要多少钱,5年又是多少钱),对于销售定价来讲,不管是主机还是零部件都是按 品牌+型号确定价格,但对于库存管理中的出入库和售后,主机肯定是需要按序列号去做,而对于零部件是无必要用序列号管理。

商品子系统设计_第1张图片

例:对于 品牌为三一重工 ,型号为SY16C,这可以确定一款产品,对于库存来讲,该款型号SY16C对应的序列号可能有多个比如 SY001ACA02668、SY001ACA02698、SY001ACA02688这样相应总库存是3个,而每个序列号是独一无二的,只有一个库存。

四、窗帘POS系统

窗帘POS系统和一般电商应用还是有一定的区别,都是通过商品条码进行售卖,一个条码对应一款窗帘某一具体尺寸,库存是按商品条码进行管理的,可以认为一个商品条码就是一个SKU,而SPU指的是某一款式的窗帘,比如 捏褶中SEVILLE、LARNE等花型,如果再加上尺寸(属于销量属性)就是一个库存单位即SKU,当然SPU也是需要抽象出来,因为进行促销会按类目或花型进行促销活动。

具体可以看 《类目体系设计总结》 《收银系统商品定价设计思考》

五、牛奶销售配送系统商品设计

牛奶分为 鲜奶、常温奶、成人奶粉、婴儿奶粉,这可以认为是一个SPU,如果加上规格,比如鲜奶有250ml、1000ml,成人奶粉有全脂、脱脂的这些属性不仅影响价格,也是库存管理最小单位,就可以确认为一个SKU。

你可能感兴趣的:(架构设计,大数据)