浅谈一种B端商品系统设计思路
本文主要从电商平台商品介绍，再到详细的设计思路，讲述了我自己设计满足B端平台需求的商品中心过程。
一、电商平台介绍
Platform在英文中的意思是平台（主体——主体）。
用科技链接不同的人、链接不同的组织、资源来完成交换，如微信平台。
重新分配，有了新型的中间人。例如，音乐行业的高管们过去主要依靠经纪人来寻找新的人才。现在，他们一样会在YouTube上寻找好的歌手，开发同学去Github寻找开发，去抖音上寻找视频博主一样。
市场聚合，将分散的市场聚合成为集中化的市场。例如，阿里巴巴为全世界的批发商打造了一个单一的平台。
将资产与价值分离。你不必购买一辆汽车来作为每天代步的工具，而可以随时叫一辆滴滴专车来送你上班。
平台天然能提供垄断与税收，也就是平台的各种服务费，不直接产生产品，但能获取最多的利润。
为了能够提高利润，降低成本，我们需要增加售卖渠道和产品种类，同时增加供应链的复用率，降低供应链成本，如果能够将产品和供应链的成本转嫁到其他人身上那就更好了。
这就解释了为什么电商公司都逐渐发展成了平台（发展得好的话），而当前，我们公司也发展到了这一步，所以需要新的商品管理方式。
二、商品简介
在超市，他是有价格和表面有一系列说明的可购买的最小单位在电商平台，他是有价格有库存有规格参数及一系列说明的最小单位。
从商品的信息来推敲后台该如何设计，才能让后台设计更好地满足用户需求。大致来说有以下商品信息有以下几部分：
- 商品的基本信息：包括标题，型号，说明与相关参数等；
- 商品的规格参数的信息；
- 商品价格，从哪发货，还剩多少的信息；
- 商品标签等运营信息。
我们设计商品中台，就是为了去更好地管理好这些商品信息。
三、一般平台型商品中心分析
一般来说，平台电商商品中心包括了以下几个子模块：
例如下方的商品后台示例：
上述的电商平台商品中心的路径大同小异，存在的交互路径可能有所不同，但底层的E-R结构和产品架构是比较类型的，都可以大致看做是以下结构。
发布商品大致的流程是：
这是一些电商平台商品中心的设计思路，这种设计有以下的一些特点：
- 同一商品可能有多种参数信息与补充信息；
- 商品需要维护信息较多，需要商户投入精力较多；
- 商品信息的自定义程度高、商品的信息需要平台进行审核；
- 能够自定义商品各种信息，以保证自身商品的竞争力，适合一个商品很多卖家竞争的场景；
- 店铺类型决定了能够售卖的商品品类等，管理较为细致；
- 系统设计相对复杂，牵扯到例如删除了规格参数相关已存在SKU如何处理，删除了SPU类目如何处理SKU，修改了又如何处理等系统行为。
四、B端电商平台商品中心设计思路
1. 业务模式分析
首先分析一下B端产品交易平台的需求特点：
- B2B交易，交易相对平常购物的网站频次更低；B端客户更为理性，对营销信息更慎重；
- 用户需要的元器件商品的参数信息需要严格且准确，不能提供错误的参数信息；
- 商品是高度标准化的，并且商品一般只有一个供应商生产此商品；
- 一个品牌的商品进行售卖的商家不会很多，不是淘宝/天猫那样的大市集；
- 一个商品可能在一段时间进行持续供货（一段时间生产周期内），商品信息的稳定性较高；
- 平台商家普遍不止一个渠道进行管理与销售;
- 对于自营店，商品量大，种类众多，管理难度相对较大。
所以有以下的几点简单推论可以得到：
- 对平台：核心需求是通过多店铺的商品管理，加强平台的供应链能力，并在此基础上仍能保障商品的参数正确性，并不是一个商品几百家商家；
- 对用户：商品信息严格准确，并尽量使商品有货可售-前台呈现模块；
- 对商家：维护商品的难度很低，不需要耗费很多时间，核心是把货放在平台上卖，而不是考虑货长什么样，怎么更能吸引消费者（这是原厂产品性能考虑的东西）。
2. 商品术语定义
- ON：商品的完整参数信息，除商品的价格和库存等销售信息外的所有信息；
- 商品：最小的可售单元；
- 商家：平台上的服务商；
- 店铺：商家在平台上开的店铺，平台进行服务费管理、店铺管理的最小单位；
- 商品属性：商品的基础属性，表达商品信息的内容，主要用于展示；
- 售卖属性：用于售卖时计算使用，主要用于与订单相关的内容。
3. 商品中心模型
平台化场景：即多个商家销售多个商品时；自营店或其他店铺都可以新建商品，但新建的商品都公用一套平台审核通过后的商品的信息内容（但框架上保留自定义内容空间）；保证平台商品参数的正确性，若商家认为商品参数有误，可以进行编辑并提交商品参数的审核，商家直接引用平台通过审核后的商品参数则不再需要审核了。
这时候就能看到我们和某淘/某东的商品管理基本结构上的相似点。
- 同一个SPU：该规格下的所有SKU都分享同一份商品图片和商品描述等信息
- 同一个ON：该ON下所有商品都分享同一份ON的信息内容
思想其实是类似的先聚合，再细分，最后把价格和库存管理在最小的可售卖单元上。
- 聚合的是什么，是SPU、类目、规格等可以复用的信息
- 细分的是什么，每个商品都有细分的不同的商品参数、价格与库存
4. 商品中心特点
商家引用平台审核通过商品参数再形成商品的策略，就显得十分均衡；
- 元器件电商的规格参数需要很强的严谨度，保证了规格参数的严谨程度；
- 对于平台的商家，自行维护这一部分参数信息门槛很高，并很难做到准确；
- 平台非一个商品几百个商家售卖的“大卖场”，不一定需要同样商品（对用户）建立多样化的商品信息；
- 降低了维护难度，也满足了敏捷开发的目标，没有那么复杂的规格、品类之间互相关联的关系；
- 多店铺多平台的结构，商品中心的业务中台能够同时支撑英文独立站和中文站的商品体系；
- 基于商品机构，可以直接再迭代多语言化的商品信息场景，来满足多语言平台站点的不同需求，通过店铺所属站点，发布地址来判断，直接将商品的多语言版本上架前台；
即：商家将平台提供的商品参数提供进行引用，商家自行管理商品的上下架、价格、库存等信息，同时平台能够有对商品总体的控制，避免风险。
五、总结
本文主要介绍商品管理的设计思路而非具体设计方案，在B端设计中，先搭建好设计的框架才能进行具体的功能设计，商品管理系统在电商系统中是常见的核心系统，有非常多的设计案例和思路（电商类、ERP类），根据商业模式。
业务类型来建立真正适合自己的商品系统才能提供产品价值。很多设计是大同小异的。
本文作者 @浮云志 。
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
