电商管理系统是为了能够让用户快速的找到商品，为同类型产品提供标准的属性、属性值，便于统一产品，使用户得到决策必须的消息，为运营童鞋方便管理商品的上下架。
最近正在做商品管理的需求，分享自己过程中的所得。
商品管理的目的：
能够让用户快速的找到商品（主要是通过关键词搜索与类目搜索，商品管理为其提供了基础）；为同类型产品提供标准的属性，属性值，便于统一产品，使用户得到决策必须的消息；为运营童鞋方便管理商品的上下架。类目树： 定义商品的分类，是T恤，还是笔记本，还是相机，类似于生物学的门纲科目属；
属性项： 不同的基础类目之间是描述属性不同，描述T恤是用领型、型号，而描述笔记本则用屏幕、分辨率、CPU主频；
属性项分组： 由于一个产品的分类属性有很多，我们将形容某一类特征的属性项归为一组，如：上图的屏幕；
属性值： 特定的特征或参数，电脑屏幕尺寸一般有13.3英寸、15.6英寸等属性值。
由于平台涉及的产品数量级不是很大，所以后台类目树使用了三级，我们一般称类目树的最后一级类目称为叶子类目。类目管理主要分成了后台类目管理、前台类目管理。
主要用于基础目录的增删改查，以及同一目录下的排序。
如上图所示五金建材为一级类目、建筑材料为二级目录、电梯为三级目录，由于设置最多为三级目录，因此电梯也称为叶子类目，后台类目树中最重要的是叶子类目，也就是类目树上不能再往下分的类目,任何商品都必须挂载到后台叶子类目上。
后台类目相对稳定，不能随便删除，叶子类目不能重复。每个类目下都可以添加新的类目、修改以及对相应类目进行排序。
前台类目是给广大用户看的，因此会随着营销政策发生变化，所以前台类目灵需是可重叠，可删除的。
前台类目与后台类目为多对多的关系，一个前台类目可以关联多个后台类目，同样一个后台类目也可以关联多个前台类目。
属性管理的目的在于，在商家添加商品时，只能在已有的属性项和属性值下进行选择，避免数字格式不对，单位不统一等所导致顾客购买的障碍，甚至会引起投诉。就比如：我们要描述一张桌子的长宽高，有的人单位用米，而有的人则用厘米。
主要流程为添加属性值-添加属性项-完成属性项与值的绑定-添加分组-完成属性组、属性项、叶子目录的绑定。
属性项管理一般主要满足属性的查询、增删改的功能，以下为属性新增和修改的原型，当输入方式为单选或者多选时，只能在当前属性项所填的值中选择。
目的是完成类目树叶子目录与属性建立关联关系，完成之后，运营童鞋或商家发布商品时，选择好后台类目就可以根据绑定的属性，补充必填的商品属性信息，方可成功上传商品。
属性继承： 由于所做的商城涉及叶子目录所包含的属性比较独立，均不予其他叶子目录属性重复，不像电脑类目下的笔记本电脑、台式电脑、超级本，都具备屏幕尺寸、CPU型号、内存等共有属性，因此在设计时就没有考虑属性继承的功能，直接选择将属性挂靠在叶子目录下。
同时将属性值挂靠在属性项下，在做此版本中，并没有单独的页面用于将属性项挂靠在属性项分类下，而是在绑定属性项中完成分类与属性项的绑定，如下图所示。
主要是考虑到，属性项分组对于大多数产品具有通用性，不需每一个属性项先挂靠在属性分组下，然后属性分组在挂靠在叶子目录下，这样会造成运营童鞋的工作量增加。
品牌管理的意义在于：维护一个平台共有的品牌库，商品新增和编辑的时候，只能从品牌库勾选已有可用的品牌，从而避免前台一个品牌多个名称的出现。
新建品牌时，需将品牌关联到类目下，可以是一对一，一对多、多对一的关系，这样添加产品时更加的快捷。
当我们建立好类目树、品牌、完成参数项的绑定之后，就可以新建一个产品了，上图为新增一个产品的流程，主要的产品状态分为：“待提交”、“待审核”、“待上架”、“已上架”，而相对应的工作为产品的新增、产品的审核、产品的上下架管理。
大多数的产品都具有不同的型号大小，系列产品的新增，目前有两种方式：
将系列产品维护成一个SPU，SKU是附着在SPU下，类似于淘宝，一款产品只对应着一个链接，选择不同产品型号时，页面不会跳转；产品的每一个型号都维护成一个单独的SKU，然后在前台展示进行聚合，将多个SKU绑定在一起形成一个SPU，类似于京东，绑定之后，在前台选择不同的型号都时页面会发生跳转。目前还没有做SKU的绑定，后期做完需求在做补充。
以上为一期商品管理的整理，希望给大家帮助，能少踩坑就少踩，坑队友是容易被打的。
本文由 @Demohour 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自 Pexels，基于 CC0 协议
商品是电商平台的关键，那么怎么通过商品管理系统将商品呈现到用户面前呢？
作者近期正在研究电商后台系统之商品管理系统，收获颇多，故在此总结亦分享下，与各位一起成长。
商品管理系统主要可以分为三部分：类目管理、属性管理、商品管理。
类目包括后台类目树、前台类目树、前台类目与后台类目的映射。
后台类目与创建商品相关，每个商品在后台添加时均需选择相应的后台类目。后台类目树一般分为三，过多可能导致冗杂，管理起来也不方便。类目树的最后一级类目称为叶子类目。如下所示的类目管理页面，食品为一级类目，饮料为二级类目，纯牛奶则是三级类目，也即叶子类目。
叶子类目可设置类目属性，后台添加商品时，根据商品选择的类目，可按照类目属性进行相关的商品描述。当类目&属性少时，无需采用属性池管理，每个叶子类目可单独设置类目描述属性、规格属性、品牌属性等：
当类目&属性很多时，可以创建一个属性管理池，叶子类目可从属性池选择相应的属性挂靠（这样做的好处之一是，当类目很多时，有些可以通用的属性，无需反复创建）：
前台类目是在客户端展示，面向用户的。 主要应用在分类、筛选、搜索等等中。
相对而言，后台类目是真实存在的，而前台类目是虚拟的。创建前台类目时，最后一级类目通过与后台类目进行关联映射，因此用户在客户端查看对应的前台类目时，可以显示它关联的后台类目中包含的所有商品。
将前后台类目分开处理，而不是在前端直接显示后台类目的原因是，后台类目复杂而稳定，而前台类目一般会随着活动、季节等原因不断调整，因此前后台分开可以只根据需求，将前台类目与相应的后台类目关联挂钩，而不需要对后台类目做改动。
属性管理可分为描述属性、规格属性、品牌属性。描述属性一般是管理商品的参数信息。规格属性一般是管理商品的所有规格。品牌属性一般指商品所属品牌。
当后台类目较多时，采用属性池方式，可以有效减少类目属性的管理复杂度。后台类目的叶子类目创建时从属性池选择相应属性进行挂靠。
商品是电商平台的核心资源。商品一般在后台创建，在前台（客户端）展示。后台创建商品时，首先需要选择该商品所属类目（便于在前端展示、搜索、筛选等）。
商品选择所属类目的下一步是录入商品信息。商品信息一般在客户端的商品详情中展示。商品信息主要包括spuid、skuid、商品名称、售价、商品属性、详情描述等。
spuid和skuid可用于区分商品，同时sku/spu在商品采购-入库-出库等系列流程中也承担着关键的标志作用。先简单介绍一下spu和sku的概念。spu是标准化产品单元，可认作某种商品，sku是最小库存单位，某种商品的某个规格均是一个sku。以手机为例，iphone6s是一个spu，而土豪金/64g的iphone6s是一个sku，玫瑰金/64g的iphone6s是一个sku。具体可见下方栗子。
需要填写的商品属性字段取该商品所属类目挂靠的描述属性、规格属性等。
后台创建的商品信息会展示前台商品详情中，以淘宝为例，后台输入的描述属性值，一般可在前台产品参数中呈现；后台输入的规格属性值，则是在购买或者加入购物车时的选择规格弹窗中呈现。
上述讲述了电商后台中仅商品管理系统一般包含的元素，但电商后台不仅包含商品管理系统，还有采购系统、仓储系统、物流系统、订单系统等等，这些系统之间都是相互关联的，商品管理系统也需要和各个系统进行数据对接等，因此内里需要学习的东西非常多，作者后续会继续与大家分享，共勉。
本文由 @已知未知 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自PEXELS，基于CC0协议
前面介绍了根据商品流转所涉及的系统模块，供应商与合同的管理已经总结过，所以本篇继续写一下商品管理模块。
关于商品管理系统的总结介绍在网能够搜索出好多，这里也结合了接触过的系统，借鉴了一些资料，根据个人的理解整理出来，希望能够按计划形成一个完整的供应链系列文章，目的是通过梳理总结让自己原来懵懂的内容清晰，希望有缘看到此篇文章的人给出建议，共同学习进步。
我心自有光明月，千古团圆永无缺。山河大地拥清辉，赏心何必中秋节。
这个属于老生常谈，但还是温习一下这两个概念。
SPU ：标准化产品单元(Standard Product Unit),是商品信息聚合的最小单位，是一组可复用标准化信息的集合，我的理解它主要也是为了前端显示为目的；SKU ：最小的库存单位(StockKeeping Unit),可以以件，盒，箱，千克等为单位存储，商品的进货、销售、售价、库存等最终都是以SKU为准的。一个SPU可以包含多个SKU，SKU是一般是根据SPU的销售属性组合（笛卡尔乘积）；
如华为Mate30手机是一个产品，但是它有白色、金色、黑色三种颜色可选，根据规格属性又有64G、128G、256G存储，这时就共会产生9个SKU（3种颜色*3种内存规格）。
有的电商系统中是不设置SPU的，仅有SKU，这样做的目的是增加商品的曝光率，让用户更直接的看到其商品，缺点就是像服装、鞋类等商品不同尺码的也显示，让用户看起来不舒服（感觉满屏都是同样的商品）；
具体如何启用SPU可以根据实际场景进行设计，下图是一个简单的spu、sku、分类及属性的关联。
商品系统一般要包含以上几部分信息，通过商品状态的变化完成在整个供应链系统中的周转；电商系统中所有的操作都是围绕商品进行的或是为商品服务的，这样理解也不为过。
商品搜索和商品紧密关联，但是一般是通过商品信息、商品属性设置关键词单独建立和部署的且与前端系统关联更为密切，这里就不过多介绍了。
商品分类是系统中非常重要的部分，它分为前端分类与后端分类。
后端分类是基础，进销存业务都是和分类紧密关联的，从商品进货到商品库存，再到商品销售，最后到财务核算很多都是以后端分类为维度进行的；同时商品的很多属性信息也是建立在商品分类上的。
前端分类是为了前端销售而建立的，它是以后端分类为基础，是为了在前端有效展示商品、用户快的搜索，查找商品而建立的一套分类。
有的系统只有一套分类，虽然业务也能正常的进行，但这样作对于网站运营同事来说可能极不方便，现在的电商网站都是前后端分类分离，前端分类负责商品展示用户体验的，后端分类用于内部ERP系统而建立的。
前端分类与后端分类层级，目前最常见的都是建立三级，分类内容：分类ID、分类名称及分类编码。
前后端分类关联约束：
一个前台品类可关联多个后台的一级、二级和三级品类；后台品类仅可以关联在前台的三级品类；一个后台品类仅可以关联一个前台品类。对于分类的维护等功能，可以采用树状的层级式，也可以采用三级联系的方式（原型就略了大家都明白）。
此部分工作是先建后端分类，再建前端分类，然后设置分类映射关系(具体可以按实际业务进行规则设置)
前端分类涉及到商品的展示、搜索，主要是应对频繁的变化的，所以会经常有些调整，以达到更好的用户体验，同时也是为了减少因为前端而影响到后端系统分类。
后端分类从供应链、财务方面考虑不建议调整，但是由于公司的组织调整、国家相关税法调整等，不可避免的会进行分类的调整，调整的内容分为两部分：
（1）分类的归属调整，原来属于“酒水->白酒”下的三级分类“浓香型”调整到“酒水－>黄酒”下。
这种调整对于SKU 与SPU 无影响，但是对于相关的统计报表（历史数据如果没有记录冗余分类信息）等会有显示的影响。
（2）分类上的重要信息变化，如税率变化；旧分类体系不适合新建立分类，这时所有的商品都要采用新的分类结构，同时前端分类也要进行调整。这部分对于系统影响是非常大的，涉及历史数据、当前系统（前后端）。
应对办法：
在系统设计时增加必要的冗余字段，以应对分类调整对历史数据的影响（业务单据、统计报表）；增加快照信息，即每月都有分类数据的快照表，在相关业务单据、报表等都关联自己所属的快照表，这样程序逻辑要复杂些，不建议这样做。商品属性也是基础信息，一般分为基本属性、关键属性和销售属性。
每个商品属性又对应有不同的属性值，辟如属性“尺码”，它就有“S、M、L、XL、XXL”等属性值。
对于这部分我也找了一些资料，个人感觉在系统设计上来讲，属性可以建立两个表，即“商品属性 ”和“属性项 ”字典表（如果画ER图它们的关系是1对多）。
我们还要明确商品属性是建立在SPU上，还是SKU上，还是在分类上？在上图中我列出的关系中，分类、产品与商品都有属性，这容易误导，这里解释一下。
“商品属性”与“属性项”是字典信息即基础信息，这个信息创建时不是孤立的，它是要选中后台分类的“三级分类”后才能创建的；SPU创建时也是要选择商品分类的（后台分类），所以这时就确定了SPU所有的商品属性；每个商品属性都有属性项，需要进行选择其属性项（值）；SKU也可以通过商品分类来确定它拥有的商品属性，每个SKU都有对应的属性项。注：上面的ER图上在产品上没有增加“SPU的属性项关系”
品牌是用以识别某个产品或服务，并使之与竞争对手的产品或服务区别的商业名称或标识；它在系统中也是一种基础信息与属性类似，但因为属性可以自定义灵活度比较高，所以品自牌与之区分，单独管理。
它主要包括品牌名称、英文名称、品牌Logo以及品牌网站、品牌说明等信息；SPU在建立时确定其品牌，同时在搜索系统建立引及关键词，方便用户进行搜索。
产地作为一个重要的属性，单独进行管理可能更好的补充完善商品信息，在目前电子商务发展的今天，大家在购买商品时更加关注于品牌与产地（国内、国外及国内各省市）；如秋季上市的大闸蟹，大家首先要判断是不是江苏阳澄湖的。
同时产地同样也属于搜索的关键字段，在前端销售的网站、APP或小程序上可以产地频道或搜索入口。产地的主要字段如编号，中文名称，英文名称，国家编码，洲/国家，是否显示等，在创建SPU时进行设置。
商品的分类、属性基础信息（关键属性、销售属性）已经确定了，下面可以建立SPU与SKU了。
前端已经介绍了SPU与SKU的相关定义及关系，下面主要说一下商品除了分类、属性、品牌与产地外的其它相关信息。
由于SKU是根据SPU的销售属性不同而生成的，所以SKU的很多信息都是继承于SPU（除库存、价格等）；
SPU与SKU编码规则：产品SPU可以采用8位码（6位分类码+2位随机码），商品SKU可以采用SPU码+2位递增码。
（1）下图是SPU与SKU的基本信息供参考：
（2）如果商品是称重销售的，还应该增加称重编码字段
编码规则：商品条码+称重编码+重量（具体的可以根据对接的电子秤进行设计）
（3）商品归属供应商
是否存在一品多商的情况，即一个商品可以从多家供应商进货（国条码相同，如矿泉水）。
对于只有一个供应商供货的商品，对于采购进货、补货或先销后采的模式都非常容易，但现实的场景中一个商品肯定会存在多个供应商供货的情况，这时无论在供应链的进销存管理中，还是在财务结算中都需要确定每一笔出入库的商品归属供应商。
在商品管理系统中需要先维护其所属的供应商（商家商品一般不会存在一品多商），如果有多个供应商需要设置主供应商。
（4）父子商品
父子商品与供应商中的父子账号、框架合同与子合同的关系类似，即一个父商品可以衍生出多个子商品，每个子商品中包括2个或2个以上父商品。
举个例子：燕京啤酒每一罐是一个父商品(规格330ml,国条码60033022),但在超市中既可以按罐买，也可以按提（6个为一提）或按箱买。
如果有人购买，你可能想，输入数量就可以了嘛，没有什么难的。没错这是一种解决方式，而且多数时我们都这样购买。
但有另一种场景即商家为了促销（9.9元/提，单个买2.5元/罐）如何处理？仍然可以采用设置促销活动，也可以采用建立子商品方式进行。
这个其实就是一个商品组合，生成一个新的商品编码（仓库要根据物料单进行作业）。对于父子商品我一直也是有些异议，但是从系统的全流程上考虑，它不仅涉及销售还涉及到仓库的作业，所以大家可以权衡确定是否采用这种方式。
（5）其它辅助信息
角标的设置：商品的标签信息（适用人群、养生等），用于搜索；这部分同样也可以通过属性来实现。商品质检信息：检验方式、检验严格度、检验规则、检验方案、抽检数量、抽检比例商品进出口信息：英文名称、英文规格、进口关税税率、进口消费税税率、进口增值税科率图片是商品管理系统中的重要部分，在APP、网站上浏览一件商品时，我们最直接的判断商品的好坏是通过商品图片来辨识的。
商品分为列表页（进入商城主页或频道页或通过搜索后显示的商品列表显示的多个商品）与详情页（点击某一个商品后进入到详细介绍的页面）。
列表页中的商品图片一般显示主图，详情页中的图片分为商品主图与其它图片（也可以设置为主图）。
对于图片，需要限制大小，同时要要求上传的图片质量；图片服务器的存储容量要进行监控，同时图片要保存在CDN上，以保证商品图片的加载速度；商品维护完基本信息后，需要进行商品图片维护，没有图片的商品是不允许上架的；图片状态：商品需要设置一个图片状态字段，新品时为“待上传”，如果已经上传图片后状态为“待审核”，审核的状态有“审核通过、审核不通过”。在供应商管理部分介绍过资质管理的部分，同样对于有些商品的销售也需要提供必要的资质证书才可以进货或销售。
对于库存成本部分，可以看一下《FMS第十一篇：财务存货管理 关注公众号：倔强的大萝卜》。
与商品相关的服务需要统一管理，商品库存查询服务是最关键的，要进行压力测试以达到高可用（缓存、负载、必要时服务降级等技术这些我都不懂惭愧，只能说说）；
对于库存数据的更新需要记录详细的关键日志，以便出问题能够分析并跟踪处理。
前面描述了商品涉及的相关信息，新建一个商品具体需要哪些操作，下图是一个简单的过程仅供参考。
可以根据描述的设计系统功能和一个个操作界面，商品管理部分涉及到商品部与运营、质检部共同协作。
审批的流程也会贯穿整个过程，个人觉得在系统操作功能上尽可能提供详细的明确的信息提示－“说人话”，以便用户更容易上手操作。
针对上图再补充一下：
新建商品/导入新品时，只是商品的基本信息，不涉及图片、资质等，所以此时还没有生成产品编码（如果有SPU）或商品编码；如果有SPU，我们需要新建SPU与SKU，审核后在设置SPU的销售属性时，会根据销售属性进行SKU的生成，有些共用的属性是继承自SPU的，当生成了SKU后，维护SKU的价格、供应商等信息；对于实际设计商品系统时，要综合考虑区分SPU与SKU,简单的流程达到生产效果即可，太复杂了不仅我们乱，使用都也会乱。本篇可能与网上关于商品管理介绍有很多重叠的，看过之后可能也会觉得又是罗列了大的框框，个人觉得每个公司的业务场景是不同的，需要根据主要模块进行详细设计，需要借助业务、产品、运营、研发等所有人的智慧，有了整体的框架与概念后，再去细化相信能够设计出一个通用的商品系统，共同努力，最后感谢大家的阅读！
作者：倔强的大萝卜；公众号：倔强的大萝卜
本文由 @倔强的大萝卜 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议
发表评论