零售系统架构设计(浅谈一种B端商品系统设计思路)

编辑导语:B端商品系统用于满足B端平台需求,本文作者分享了B端商品系统的设计思路,介绍了电商平台、商品简介、一般平台型商品中心分析以及B端电商平台商品中心设计思路的相关内容,一起来学习一下吧,希望对你有帮助,今天小编就来聊一聊关于零售系统架构设计?接下来我们就一起去研究一下吧!

零售系统架构设计(浅谈一种B端商品系统设计思路)

零售系统架构设计

编辑导语:B端商品系统用于满足B端平台需求,本文作者分享了B端商品系统的设计思路,介绍了电商平台、商品简介、一般平台型商品中心分析以及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类),根据商业模式。

业务类型来建立真正适合自己的商品系统才能提供产品价值。很多设计是大同小异的。

本文由 @浮云志 原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自 Unsplash,基于 CC0 协议。

免责声明:本文仅代表文章作者的个人观点,与本站无关。其原创性、真实性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容文字的真实性、完整性和原创性本站不作任何保证或承诺,请读者仅作参考,并自行核实相关内容。文章投诉邮箱:anhduc.ph@yahoo.com

    分享
    投诉
    首页