2B产品中心思考

一.概述

对于产品中心的一些思考，做下沉淀。对于电商类业务产品是核心基架，是交易的起点来源。

• 定义

产品广义定义就是能满足人需求的事物。

在交易场景中就是买卖双方交易的标的物。

产品要承载交易标的物的库存及价格信息，以及其它一些产品属性。如实物电器产品，产品的表达包括电器的库存，价格，品牌，规格等信息。

总结下来产品=产品基本信息(决定产品是什么)+产品归属方(卖方信息)+产品售卖单元(聚合了价库信息)+产品状态。

无论2b还是2c基本元素都脱离不了这个范围。

产品内核图

• 2b与2c产品差异及共性

差异

2c产品更注重产品属性表达及产品导购(提升用户决策效率)。2b则更加注重可售单元信息表达。举个例子2b的商户是通过系统api来拉取产品，那么产品系统核心建设重点在于产品信息及价库能力的建设，而不会涉及到导购推荐之类`的能力。

但如果一个业务即涉及2b渠道也涉及2c渠道那么在产品架构及模型上就需要考虑。

共性

首先产品基本内核是不变的(价库，基本信息，产品归属性)。其次从产品目标上发品效率是重中之重。

二.需求背景

2b平台一般是多行业平台。需要支撑的行业可以是电器，美妆，快消品等。

整体架构及模型的挑战在于不同行业的元素是分散的，行业组成元素多样化，每个行业差异大。

但从2b平台定位又是全品类，所以实际行业特性与2b平台定位是存在矛盾的。

架构及模型设计的关键就是怎么平衡这之间的关系，即要考虑收敛统一性，也要考虑行业扩展性。

三.用例

用例这里只是列了几个参与角色核心业务能力。实际工作中还需要根据不同的行业对每个行业发品时涉及的业务元素进行分析，多行业都涉及元素进行抽象复用，不同差异体现在模型上就是扩展。

相应的需要对每个行业产品链路用例进行穷举。对用例中涉及的名词看是不是实体，是实体的再按职责单一进行归类形成聚合根，多个聚合根形成子域。

比如：供应商发布/上下架电器产品，抖音渠道用户能够看产品并能下单，看到的产品信息包含价格，库存，规格。这个用例中对应产品，价格，库存就可以抽象成实体。相应的按职责归类产品，价格，库存都可以拆成子域。

四.架构

将价格，库存单拆出来形成子域及价库模型。价格库存形成通用域能够支撑货品及产品的复用。产品审核能力单拆出来往上抽象为变更审核能力，从而能够实际对于不同业务的复用（如商户变更）。

整体架构上产品中心分为货品接入层及产品层。

货品接入层专注于上游供应商货品的接入，这里涉及行业货品模型标准定义，这样不同供应商通过标准API就能够将货品流入到资源中心，实际业务中也可能采取拉取货品资源的模式，这个涉及到双方谁更具商业优势。

货品接入后将货品转成售卖品，这里在模型上产品核心表达产品的售卖信息。这样整体在货与产品的转换效率比较高效。

五.模型

• 模型结果

行业模型侧由于隐私做了简化。

• 设计思路

整体产品分2个层次。售卖产品这层注重售卖场景业务表达。货品这层侧专注于行业货品表达。

分层逻辑：

1. 行业货品的必然性

业务上即有货权与货主一致场景也有货权与货主分离场景。从业务角度去看一个物品必须是有一个拥有者。产品的拥有者是在平台上进行售卖的主体。货品拥有者是货主，如电器的供应商。后面涉及经销场景没有货品则无法表达。

2. 模型的收敛与扩展

不同行业整体要素复杂且各自有差异，如果用同一套模型表达则会将模型不同复杂化，不同行业都往这个模型加最终导致的结果就是模型复杂到没人知道每个字段的含义。

3. 重要元素组成是什么？是否需要一个产品多sku？

结论：产品=行业货品属性+销售属性。需要支持一品多sku。

货品属性必须：货品不可能由销量平台改变，定义权在货主手中。而买家在买的时候是要知道货品信息的，所以这个是必须的。

销售属性是否必须要有：模型上要不要表达产品销售属性本质上取决于谁最终对终端买家产生售卖包装价值。如果是供应商->渠道商->ota的链路则ota实际最终负责对消费者产生包装价值，这个在标品中ota侧本身是有销售属性定义标准，此时产品是弱销售属性。而如果是供应商在平台上发布产品，买家也是在平台上，则此时产品是有销售属性的。

是否需要支撑一个产品多sku：从商家发品效率及买家决策效率视角都需要。商家对于一个电器多个规格肯定如果要让商家发布多个产品，那后续涉及到这个产品的发布维护效率就比较低。发布效率在于这个电器本身涉及的基本信息是多个不同规格电器可以共享的而此时商家要重复维护。维护效率在于商家若需要对这个电器进行下架则此时商家要同时操作n个产品。

详细模型说明:

产品的价库是基本通用要素，这部分抽离模型及子域出来。

对于卖家发品效率来讲需要支持一品多sku场景，如果没有这种结构就意味着商家需要按最小售卖单元去发布售卖商品。这个对于电器类不同规格的sku如果想要一起售卖或者说希望统一做上下架处理则是无法满足供应商诉求的。

六.总结

上述这套产品模型基本是能满足2b相关售卖场景，同时对于2c的场景也能支撑。

并且这个模型已经做了产品与货品分离，对于经销类的业务也能支撑。