中台实战系列：商品中心，万物皆商品

一、万物皆商品

很多产品经理做产品设计时候，会把商品理解的比较狭窄，认为电商中的商品才是商品。其实按照经济学中的概念，商品是用于交换的劳动产品，用这个概念理解，其实商品的范围非常的广。举个例子，之前我在航空公司做IT系统时候，做过航空货运管理系统，就是飞机上面是坐人的，还有一块舱位是用来放货物的，这个系统做的就是这个舱位管理系统。因为这个舱位是航司与一些有货运需求的代理商进行交换的产品，所以在做舱位管理系统的时候，我就用了商品管理的思路来进行产品设计。

所以万物皆商品，如果做一个自己不熟悉的领域时，也可以将概念再抽象一层去做产品设计。

二、前提：业务梳理

不同公司一定要结合自己公司的规模以及实际发展情况等，来看如何做商品中心。

（1）回顾做中台的目标：

首先做中台的目标是为了满足多业务线的情况，形成一次建设多次使用。

（2）商品中心定义：

前面提到万物皆商品，而一般商品中心的存在主要存储商品相关信息，进行前台商品信息展示。比如我们经常看到的一些商品标题、商品备注、商品标价、商品详情展示等。

用专业一点的定义就是：商品中心是用来管理SKU（最小库存单位）、SPU（标准化产品单元）、属性（关键属性、非关键属性、销售属性）、类目品牌、价格等有关商品的数据。

（3）基于本公司情况的业务梳理：

首先需要先梳理下，对于自己公司来说商品有哪些是哪些类型。比如阿里的商品，除了我们看到的实物商品之外、还会有服务商提供的软件类虚拟商品、还有飞猪的机票、酒店商品等等。

考虑不同业务里面，需要的商品信息有什么，可以用一张表全部罗列出来，可以找出一般的共性字段和特殊的一些字段。同时可以将这些字段，按照属性进行分类。

三、思路-服务中心及管理后台

（1）服务中心与管理平台

前面提到需要结合公司情况来看每个公司的中台做到什么程度。比如针对阿里这样大的公司，各个业务线能力也比较强。商品中心只需要做到基础信息的存储即可。对于中型企业，可能某个业务线比较强，其余业务线还属于起步阶段。这个时候可能不光要提供商品中心这样的数据存储的地方，还需要一个管理后台，让各个业务线可以直接进行商品管理，避免每个业务线的重复建设。

（2）商品中心思路考虑

不同类型的商品，其需要的商品字段可能都是不一样的，对于跨业务线的情况，如果业务线差异比较大，这种情况会更加明显。比如淘宝中服务商售卖的软件类商品和实物类商品，一种SKU是1个月，一种的SKU是由运营自定义的名称，其差异都是比较大的。

基于这种情况和实际业务分析，我考虑采用一种灵活可配置字段的形式，可以快速配置商品模板。配置好的商品模板发布后，可以让运营直接在商品管理进行商品发布。

四、实操

（1）关于商品中心的基础名词

（2）商品中心架构

包含：类目管理、属性管理、商品模板、商品信息存储

（3）打造灵活可配置的商品后台

服务中心大致思路如下：

（1）属性管理：可以灵活的定义和创建属性。属性包含和属性、属性值还有属性分类、展示组件。

属性举个例子可以是比如商品标题，属性分类是基础属性，展示组件是文本框，属性值就不需要特地指定了。再比如颜色作为一个属性，属性值可能是红色、蓝色、绿色，展示组件是单选框，那么在商品管理运营发布商品后，用户只能通过单选的方式进行商品选择。

（2）创建商品模板：通过增加属性库中的属性及属性值，创建商品模板，一般商品模板可以跟着类目走。这样就可以定义每一个类目下不同的商品模板了。

商品管理后台：

商品管理后台指运营使用后台进行商品发布的平台，商品发布后则可以被消费者看到，然后进行下单购买。

由于有分层关系，为了便于理解用一张图表示如下：

写在后面

授人以鱼不如授人以渔，主要通过一步步思路的剖析，讲述在为某一个企业做中台产品时候的思路。

产品应该是要根据企业情况及现状进行设计的，所以具体还是要根据当下的情况进行考虑。不用太过于执着某些概念，概念只是为了让大家在沟通的时候，便于进行理解的统一。