【聚禄鼎】一站式企业服务平台
对于电商系统来说，维护商品模块可谓核心功能，整个体系以商品为中心运作。如果在这个方面出了问题，那么整个系统也会出现很多错误。因此，是否可以设计出灵活，方便的商品模块，对整个系统运行是至关重要的。在这个前提下，商品管理也就成了重中之重了
今天，我们谈谈商品管理那点事儿，对商品信息保持，其实质就是管理一大堆属性以及属性值，厘清其关联关系等，便可以把它玩得得心应手。在这篇文章中，我们会针对电商平台上常见的几个主要商品类别进行分析和研究，并结合这些分类特点，提出相应的解决方法
让我们先来看一下，一件商品的特性都是什么，如下图为一家电商平台商品图:
整理一下可以得到其中的属性:商品名称、品牌、品类、颜色、内存、价格、图片、商品编码、CPU型号、机身存储、商品毛重、操作系统等。这一系列的属性为商品提供了基本信息，也为企业的后台操作奠定了一定的基础
在上一篇《电商后台设计:属性管理》中，我们把这些属性分为基础，销售，搜索和特有4种。这五类属性都是独立存在于商品信息里的。将除其搜索属性整合为特有属性，其它功能在商品信息维护中均有涉及，下面就逐一加以论述。基础属性就是商品的基本属性
1、基础属性
对一切商品所含有的性质，均可归为基础属性，比如商品的名称，品牌，类别，境界等等。如果商品是通过搜索引擎获得，那么基本可以直接从搜索引擎获取相关的基础属性来查看该产品的情况。对基础属性保持相对简单，由于都是单一可以确定类型，一般按照数据展示的形式逐一进行维护就可以了
其中有几个属性需要说明一下:
- 品类:由于商品的特有属性和搜索属性都关联在品类上，因此，商品品类一定要精选。当商品进入到后台时，首先要判断它处于什么状态？
- 情况:上架/下架，判断是否将所述当前物品显示于前台。商品销售过程中，所有的操作都要以一个整体为目标进行管理。对货物进行全局控制；若没有上架或未被选中，则将商品信息与相关数据进行对比分析，找出可能出现问题的产品并对其做相应调整。若上架了，后面相关SKU一起上架；若下架，则是所有商品全部被下放到后台处理。相反，也是如此。这就相当于将所有关联商品都纳入到同一个平台进行统一管理和销售
- 商品种类:单一/复合产品；一些平台支持打包出售方式，即一件商品其实包含了若干关联子商品。可透过商品类型字段，首先标示当前的商品是否为单品或复合商品；再将该商品进行分类，然后根据类别分别打包销售。如复合商品，其后还要与相应的子商品进行关联。对于复合商品，我们会根据商品类别进行相应的处理和设置
二、特有属性
上篇《属性管理》，我们引入商品特有属性设定，并关联绑定品类。本文章则重点讲述商品特色属性的设定和应用。在商品信息的维护中，在选定类别之后，我们可以得到已配置内容，其次，按配置显示表单，并且保持其中一个属性值就可以了。这篇文章主要介绍的就是如何通过表单来进行特殊属性设置和更新的过程
品类绑定属性设置
规格参数维护表单
三、销售属性
在说销售属性之前，首先，我们要理解两个基本概念:SPU与SKU。在这里我想说一下我对标准商品的看法
SPU:StandardProductUnit（标准化产品单元）
SPU是商品信息聚合的最小单位，就是可复用的集合、易于检索标准化信息之集，这个集描述产品的性能。通过对商品进行分类后可以得到一系列不同类型的商品组合，每个类别中又包含着若干个子类别
SPU简单地说，是一种属性相同的类型、属性值物品，这些性质及属性值一般不涉及商品销售价的测定。它是以一定的标准对每一种类别的商品进行编码并存储起来。如iphone6s就是一个SPU，不管是在那一个平台上，还是实体店，都可以查到iphone6s，他们提供的商品属性信息是相同的。这类商品称为标准化产品单元
SKU:StockKeepingUnit（库存量单位）
SKU即库存进出计量的单位，可以一件，一箱、以托盘等为单元。每个商品有其特定的存放位置，这就需要通过一定的方法来记录该商品在各个存储区域内的数量情况
SKU是物理上不可分割的最小库存单位，而且这种不可分割与储存场景对应，对同一物品，在各种仓储场景中，对于SKU来说就不同了。例如，在一个超市里，有许多商品都是同一批次的产品，但在某一阶段会发生一些变化，比如货架位置发生变化等等，这些变化就需要进行盘点，以保证每个商品量准确地入库
举一个列子，我们通常会到超市购买早餐奶，可购袋或购盒。你可以选择购买袋装或者盒装早餐奶，但是如果要购买瓶装，那就要购买一个箱”了。以最小单元为单位，那么”袋”就是超市管理早餐奶的SKU。如果把”盒看作一个小单元的话，那它应该是”箱了。”超市货源由供应商提供，供应商按箱子向超市出售，因此，”箱”就是供应商对早餐奶进行管理的SKU。如果超市管理好了这些箱”，我们就能把这些早餐奶卖出去
不知你是否注意到了，物美、家福乐前去买了一盒牛奶，结帐时收银员并没有扫盒子上条码，却开箱拿出一包扫码，接着输入人数，最终结帐，也可以从中窥见这些大超市奶制品经营之道。如果你想了解一下这些大超市是如何做的？
SKU可简单地理解为:SKU=SPU+销售属性，给SPU加上商，色时、在内存和其他属性对销售加价产生影响之后，这个商品就成一个SKU。这样消费者就会发现商品是以某一特定名称出现在货架上面了，而非以前所认为的商品只有某一种”或者某类”的特点
看与上文SKU定义有出入，若细究起来，商家界定商品价格，并不是以商品最小单元来设定？商品本身没有多少属性可以单独作为变量来计算它的价格，而只能用其构成元素的大小来表示
因此，当我们想识别SKU的时候，首先，要清楚地认识到影响价格的若干性质，查找相应属性，列出各属性的属性值，所有SKU都可由属性值合并决定。这样就可以很好地进行商品信息的管理了，并且还能够帮助企业更好地进行营销活动
销售属性保持，同样由属性及属性值进行运算，但有两点特别之处要解决:
- 属性值维护完成后，需基于属性值的组合才能产生SKU:这是整个商品模块最关键的地方，由于价格在后，库存在后、图片完全取决于产生SKU
- 个性化设置属性值:就像一部手机一样红，不需要商家称呼不一，比如炫彩红等、玫瑰红在等着，还有各种色彩上传各种风格手机样式图。如果要实现商品的个性定制功能，则可以通过设置一个自定义属性的方式，将该商品属性添加到对应的属性表中
维护好销售属性和属性值后，便可以通过只有一个SKU的组合产品，此后货物的销售价格，订货情况、部分属性信息，如库存，均需直接联系SKU。因此在建立商品目录时，首先要根据销售属性来设置这些属性值
所以这里有一个特别注意，一旦构成货物的SKU销售属性被识别出来，已经无法做出销售属性的改动了；因为只有在确定了所有这些属性值以后，才能根据这个属性值来调整相应的价格和其他相关参数。如增删销售属性等，以前产生的SKU数据当然是错误的，并且增删特定销售属性时，属性值只对一部分SKU数据产生影响。这也是本文所要解决的问题
1、因此，要想提高商品库存管理的效率和准确性，就必须根据不同产品的特性来调整不同产品的价格，才能实现商品精细化库存控制。商品价格
是SKU保养过程中，有几种价格设定，需关注每一个价格使用情况:
1）采购价
采购人员向供应商采购商品时的价格，系统中若干处将采用采购价:在货物的采购入库过程中，
- 货物的采购价格与货物信息一并存入入库单；在出库或退货时，商品的价格会与出库或退货单同时被记录
- 在填写商品的日常销售价和活动销售价时，将通过比较采购价，避免销售价格过低，造成企业亏损；如果采购人对商品的质量没有要求的话，可以直接用商品信息进行统计
- 商品完成订货销售后，该系统用于销售成本及应收金额的测算。在销售过程中，如果客户对某一商品产生异议时，可以用这个价格来处理
2）吊牌价
吊牌价一般指供应商在货物出厂时的价格，对货物制定的市场销售参考价，价格一般是与货物的部分质检信息一起写入货物吊牌。当用户购买到商品时，可以根据商品吊牌价来判断该商品是否被客户订购了。吊牌价通常都是线上和线下用得多，比如商场上的衣服时候最多。在实际应用中，吊牌价也经常被用来计算客户对产品或服务的评价
线上系统的设计，吊牌价只是对销售价的制定起了一定的借鉴作用，实际价格大家通常用的是另外一种概念，销售价，销售价也分为日常销售价与活动销售价。日常销售价与日常商品价格一致，而活动销售价则不一定都是经常发生的销售活动，比如在卖场内的陈列中，经常需要设置不同的促销方案来吸引顾客，从而增加销量
3）每日销售价
当商品不参加活动时，所确定的出售价格即为每日销售价格，商品上架过程中，每天都有活动价。活动销售的价格也有可能低于或高于日常销售价
如果是个体商贩，户主本人按进货价计价，若为大型自营电商，一般是采购人员以采购价为基础，以期望利润为依据制定每日销售价。商品参与活动后，活动销售价也就产生了，但活动销售只是一种形式而已
4）活动销售价
商品参加活动时设定的销售价格为活动销售价，事件的销售价只在事件过程中生效；如果不进行活动销售，商品售价就不会被使用。事件到期后商品售价再采用每日销售价。活动结束时，商品销售数量达到一定比例，才能够自动恢复到初始值。在大型自营电商内部，一般都是采购人员负责保养。在这种情况下，如果采购员出现了失误或者错误的话，就可能造成活动无法进行或商品销量下降等问题，因此，需要对商品进行合理的定价
5）预警价
预警价的设计主要是防止商品经营者输入错误，把商品出售价格定得太低了，造成企业损失所建立起来的预警功能。如果在购买了商品后发现商品过期，或者在购买到的时候发现商品已经售出，都可以根据预警价格进行销售，避免了商品被冒用或冒售
这与采购价有些相似，通常比采购价低，可以销售。如果高于预警价则禁止出售。比如某些快要到期的商品，或者是拉新搞的事件等等，但在预警价以下，一般不允许销售。这样就能让消费者看到，如果低于预警价才允许销售的话，消费者是不会购买的，所以，如果低于预警价格，系统会给你一个警告信息，提醒商家注意商品的库存情况，以免造成经济损失
常用的两种场所:日常销售价保养及活动价保养，两价均需与预警价比较后再保存，若低于预警价，系统将发出提示信息，才能保证价格设置的准确性。如果超出预警价则不能销售，这样可以避免商品积压或缺货造成不必要的经济损失
2、一般情况下，在库存管理上都会使用库存模型”来实现。库存
对SKU销售来说，库存是理所当然地参与其中的，商品维护界面中只有一个针对库存数的维护位置，即实际可销售的库存。一般情况下，商户都会选择通过系统自动或者人工的方式进行数据输入，然后将该数据表保存下来，这样既不影响商家正常业务运营又能避免人为操作带来的风险
对入驻大平台的商家而言，一般采用人工录入方式（具备开发能力，可进行系统对接），使商家自行保持SKU销量。如果有客户需要购买某品牌的商品则会提交需求订单信息至服务器，然后通过服务器将其自动匹配到对应的库存中去，并根据该商品名称及规格进行相应的处理。究竟填多少，商家自行决定，此填入数为实际可售库存。对于中小平台的入驻商家来说，一般情况下是通过人工进行操作来管理和维护可售库存，这种方式效率低，而且容易出错，同时也无法做到及时更新库存数据
但对平台自营而言，企业一般会拥有属于自己的仓储系统，每一个SKU均具有清晰的存储记录，并且部分SKU参与内部任务（例如调拨，拍照和战略储存）使得当前时间不可售。在此情况下，一般是平台自行根据商品的库存量来计算可售货量，再进行订单处理，并将订单信息和库存信息发送到客户端，从而实现批量化配送
因此，实际的SKU库存可能并不等于全部可售，特定的实际可售库存需通过仓储系统，经统计后同步至商户模块，而非买手本人的人工保养。同时由于不同的店铺对同一型号产品具有不同的需求和偏好，这就给了卖家们更大的自由来选择适合自己的商品，从而实现了个性化定制化
3、同时由于不同的店铺对同一型号产品具有不同的需求和偏好，这就给了卖家们更大的自由来选择适合自己的商品，从而实现了个性化定制化。上架/下架操作
除对货物基础属性进行上架/下架操作外，通过对特定SKU还设定了上架/下架作业，能够更细粒度地对特定SKU上，下架状态进行管理。同时为了能够更准确地反映出商品本身的特性信息和物流过程中发生的各种变化情况，还需要对不同类型的商品添加相应的代码来描述其特点
4、同时为了能够更准确地反映出商品本身的特性信息和物流过程中发生的各种变化情况，还需要对不同类型的商品添加相应的代码来描述其特点。第三方编码
平台生成SKU时，会为每个SKU也分配相应的拣货码（可能是商品身上的条码，也可能是公司内部自己定义的编码），为了便于拣货
若为自营平台，在买手购买的情况下，供应商将向购买平台提供，以输入系统；若为第三方物流公司，则由第三方物流公司负责采集数据并上传至平台，再交由平台处理。如平台商户，首先，平台无法收集到数据，其次，每个商家自己拣货所采用的法则不同，因此，只给出了可由商家自行保持的字段。为了保证商户能够准确地从商品库中找到所需的商品，需要在订单管理模块和商品库管理系统之间增加一个商品出库信息表作为接口来实现这个功能
有订单生成时，订单模块输出的拣货单上设置有保持的第三发编码，供商家执行拣货操作。另外，还需要在每个商品上都添加图片维护功能，以方便商户查看各个商品之间的关系以及其他信息
5、当出现单件商品时，将其放入缓存区后再取出来查看该产品是否为该商户所有。图片维护
展示商品各个位置的图片，图片维护一般在3个位置:列表图、SKU图组及默认图组。其中列表图可以将一个或多个商品信息按照一定顺序进行排序，并显示出各个商品的详细介绍以及相关链接
- 列表图:以搜索列表显示的画面为主；一般用来对某一商品信息中的某个或某类产品进行排序并提供一个相关的列表供用户查看
- SKU图组:将相应的一组显示图片上传到各个特定SKU中，多用于显示商品详情页
- 默认的图组:若相应SKU没有对展示图片进行设置，然后显示预设这组照片来显示。当需要对某一特定的商品信息或产品属性进行查询时，可以选择相应的图片大小来实现
小知识点:画面呈现出来的时候，才能可以提高图片的展示速度，优化页面的展示速度，商品图片上传后，一般采用缩放的方式进行，把照片保存为几种大小，以便于在不同的网页上调用。这样做虽然可以让浏览者更快速地看到商品信息，但是也增加了系统管理员维护成本，并且可能导致页面出现混乱现象
6、这样做虽然可以让浏览者更快地了解到相关信息，但是却给管理员带来麻烦。简介功能
电子商务平台上的商品成千上万，若全部由常规表单逐一进行保养，维护人员要累死（看看一款电子产品的产品规格是什么），一般情况下，系统设计有导入功能，以方便维护人员的工作。导入功能可以快速导出产品的所有基本信息和相关数据信息
商品信息导入功能中存在着两方面的局限性:
一、一次只能导入一个类别，由于没有使用品类特殊属性不同，没办法归并；二是不能批量导入所有品类的商品信息，这对于销售部门来说是非常困难的事情
第二，只能引入基础属性与特殊属性的信息，销售属性信息并不支持导入产生，由于销售属性要由属性值合并成SKU信息，系统需要生成唯一ID，内部逻辑较为复杂。针对这个问题，我们提出了一些解决方案，比如将产品分类后分别导入不同类别的商品中去实现
【#】后面为需要导入的特殊属性列表。因此本文只讨论销售属性信息在导入时如何实现简单操作，而对其它方面没有涉及
以上内容，基本上覆盖一件商品的核心信息，每个人都需要，可根据实际业务场景重新优化和修改。下面我们将对商品的各个要素和功能进行详细说明
四、商品维护流程
最后我们再来看看商品的维护流程
电子商务平台上的个人商户，由于自家SKU数量比较少，从输入商品参数，到对商品拍照、上架一人基本上就可以搞定
但对自营平台过万个SKU来说，这种做法明显行不通。因此，为了保证商品质量和安全，我们需要构建一套行之有效的商品维护系统。在大平台上维护一件物品，需要多部门通力协作才能实现，基本流程如下:
- 采购部:买手首先要保养后端品类，将关联属性绑定到各个类别中，以及设定属性的输入方式、基本配置信息，如搜索方式。在购买时只需扫描标签即可查看商品是否符合自身需求及所属品类，同时可选择不同价格进行交易，以满足不同用户需求
- 采购部:买手向供应商取得购买货物的基本资料，以及把商品的基本信息引入该系统，以及基于所述销售属性来产生SKU。系统接收到商品名称后，自动匹配对应商品名称下的购买人和相应的购买时间点，并将该商品相关属性及购买时长发送至买手模块进行保存
- 采购部:买手以购买单购买货物，以及协同仓库共同输入货物，完成货物的购买，该系统完成SKU同步库存信息的管理，买手在日常销售价格上完成保养
- 采购部:买手将商品图像采集工单提交到系统。系统接收到图像采集工单后进行分析处理，判断商品是否合格
- 图像采集部:图像采集部的同事们根据工单，申请了仓储图像采集调拨工单（把以前输入的SKU每调拨一个）
- 仓储部:以图像采集调拨单为基础，筹备调拨商品。仓库管理人员根据扫描到的条码信息对商品进行入库登记
- 图像采集部:图像采集部的同事与仓储部交接出库并取得样本，拍照修图，完了就上传系统。在整个过程中都会有员工出现差错
- 图像采集部:拍完照片把货物还给仓库。在库存的货架上摆放好商品
- 仓储部:把货物再放回仓库里。仓库管理员对库存情况进行检查
- 采购部:当买手对商品的信息进行测试完善时，即可每天上架出售。采购人员通过电脑上购买订单，然后根据客户反馈回来的商品信息来确定下一步应该要采购的商品
以上四个步骤中，除步骤3采购入库外、设定价格将是常用的，其它的三步仅在商品第一次录入系统的时候需要维护。在这第一步的过程中，如果是运营人员的话，他一般都是直接从前台的商品数据采集界面输入自己想要的数据或者通过人工方式来实现这个功能的
对以上操作流程，有些人可能会产生疑问，一般不就是经营着做产品销售么，此处如何买手？其实在电商企业中，买手只是一个普通的员工，他们所从事的是与运营相关的一些工作
电商企业买手工作领域以商品信息维护，采购为主、维护销售价格和下架情况；在传统的企业中，买手与运营人员的职能范围相同。并由运营人员负责活动，专题框架的搭建、活动及主题上的特定物品，由买手决定参加与否，最后利润是由双方平分（运营与买手薪资与销售额挂钩）。这就说明，运营和买手要共同合作才能实现盈利，但两者并非完全独立
