中台实战（10）：从零开始中台商品中心搭建（下）

点击 ↑ 上方关注此公众号，从此就是我的人~

回复“3”获取《产品日常必备资料包》

第48篇原创好文，共3092字|阅读用时8分钟

在商品中心搭建的上篇我们完成了中台商品中心的需求分析后，本篇开始我们就可以进入商品中心的设计与建设过程了。

具体来说，我们商品服务中心的搭建分为如下的两步：

（1）SKU数据统一；（2）SKU各业务线个性化需求兼容

也就是需要面对并处理不同业务线的需求差异（以下仅摘取了部分差异性需求）：

（1）在商城展示中，有的业务线商品为固定包装产品如啤酒会展示净含量等单位，但是这个字段是否需要复用，如果复用了其他生鲜类业务线经常出现的生鲜品如整鸡等约5-6斤，净含量怎么填写？

（2）在供应链管理中，通常为最小存储单元进行库存管理，如瓶，但同时其他业务线也会出现按箱出入库的现实情况（越级），此时箱作为一级封装，如果再出现多箱打包为组的二级封装，此时以什么拣货单位进行拣货？

（3）每个业务线的商品类目在用户商城前台都有自己的一套分类体系，此时与后台诉求完全不一样（各业务线用户展示与运营需求）

通过调研，我们可以发现不同产品线对于商品管理的诉求，本质上来说是偏重于不同角色的需求，也就是有的业务线可能对供应链管理有特殊要求如需要按箱入库，有的业务线需要在前台增加更多运营属性，如特殊的商品的分类。

因此总结下来，一个中台中的商品服务中心的商品管理需要通盘解决上述的问题与角色可以总结为下表：

4

建设：商品数据改造

（此处的标题序号4是承接上篇的序号）

解决上述的问题与角色，首先我们需要确定商品的基本结构，也就是日常电商中商品管理功能大家都是怎么去设计的？

其实对于商品来说当我们站在一定的高度上去看，可以发现任何商品管理的基本结构就是下面三个部分：

（1）商品定位：如何快速在庞大的商品库中找到需要的商品；

（2）标识商品：很多时候仅依靠命名会存在很多相似的商品，如可乐1瓶/可乐1大瓶，此时要如何将相似商品进行区分标识出来，在后续系统中流转不会出现错误；

（3）商品特性：完整的商品就像一个海胆，每一个尖触角都像一个特性都会被有对应的需要的人捕捉，从而完成自己的业务。

那么上面这三个需求翻译成产品的语言其实就是：

明确了需要兼容的范围，如何设计中台解决方案呢？下面我们一个个来拆解：

（1）SPU/SKU体系

这个部分可以算是中台商品服务中最为简单的设计，为了统一管理全公司多业务线的商品，在中台中只需要建立起唯一的商品创建中心，也就是交由一处进行统一化管理，此时各个业务线的新增产品必须由商品创建中心创建，创建后并发布成为正式的商品。

特别的当有多个业务线创建相同商品且共同维护库存时，本质上这样的模式优势就凸显出来了，如下图：

可以看到我们实现一个实物映射了多个不同业务线的售卖物，不管业务线中可乐商品是什么叫法对于供应链来说只有一个SKU的可乐，这不仅实现了实物的归一化管理，也实现了全局实物库存的共享。

（2）类目

类目管理必须拆解为前台类目与后台类目两类，其中后台类目也被称之为商品固有分类，也就是按照全公司的标准进行分类的，用于给供应链统一维护。

也就是说不管各前台如何将可乐这个商品放在哪个类目下，在后台类目中可乐永远存在在如下类目中：

而中台维护的就是这个标准类目，提供全局最标准的类目，到这可以看到中台其实还起到全公司的标准制定的重要作用。

有了这个标准的后台类目后，各业务线在获取到该商品后可以在自己的业务中自己维护一套类目。

（3）商品属性

解决完了前两项，我们就来到了商品属性设计的部分。

如果对商品的属性下一个定义的话：商品属性本质就是描述商品特征与为对应业务触发提供标识。

例如商品温层属性：常温、冷藏、冷冻，就是提醒仓库作业人员到底应该去哪个库区存储该商品。

可以说这一部分可以算是商品服务中心中最难处理的环节，因为它和具体的业务线是强相关的，每个业务线可能都有自己的特性需求，例如有些业务线是面向大客户，因此是按大包规售卖，不零卖，而有些业务线又是大小包规都会售卖。

也就是在前文我们定义的需要通盘解决的问题与角色，本质上就是由商品的基本属性来承载不同角色需要解决的问题：

理清楚了思路，那么这一步要如何兼容这些不同业务线之间的需求呢？

这里使用的方法也就是在我的《中台产品经理宝典》一书中提到的——中台核心公式：Summary - Details设计方法，通俗来说也就是中台维护摘要信息，具体的详细属性由业务线自主赋予。

5

建设：属性项分离

要去实现Summary - Details的商品属性设计模式，我们就需要拆解下现有的SKU属性解决方式，这里先借用网上找到的一张图来描述下，通用的商品属性是怎么构成的：

可以看到在商品属性中，通常分为了属性项组->属性项->属性值三个部分，其中：

（1）属性项组是为了进行分组，方便进行同类型集中管理；

（2）属性项是具体的类型属性，最小业务类型承载单元；

（3）属性值是指具体某个业务含义的数据化承载；

明白了通用设计后，我们也可以参照这种通用的框架，对中台商品中心中的属性部分进行建设。

步骤1：定义属性项组

我们按照两个维度进行属性分组

维度1：按维护角色进行分组

SKU属性 = 中台属性（Summary） + 业务线属性（Details）

说明：

（1）中台属性解决标准问题，比如该SKU的产地，生产日期，大小，体积，各个业务线统一的打包配置等；

（2）业务线属性根据自己的需要去定义对应属性，如前台对商品的特殊描述：别名；

维度2：按属性特性进行分组

SKU属性 = 基础属性 + 业务属性

说明：

（1）基础属性：指商品的固定的物理属性，这也是中台属性的组成部分；

（2）业务属性：为了业务需要而赋予商品的相关属性；

中台的统一属性 = 商品的固定的物理属性 + 公司内部各业务线对该属性达成的共识的业务属性（沉淀的公司内部规范）

我举个例子来帮大家理解下共识类属性的含义，在生鲜行业中，一般带有仓内加工的电商中都会涉及到一个商品标品化的过程，也就是由非标品到标品过程。

比如，仓库需要将采购到货的原料土豆进行打包成一个独立的包装，此处的原料土豆我们就将其称之为非标品，而打包好的土豆称之为标品。

这里的标品非标品的定义其实就是公司内部各业务线的共识：

• 标品：按规格售卖（69码）

• 非标品：按重量售卖（无69码）

所以我们就有了一个中台属性（共识属性）：

这里我给大家一个我曾经搭建的中台商品服务中心中的共识属性示例，在共识属性上我分又细分了两个属性层级：

（1）交易属性：用于支持售卖模式的属性，eg：价格，虚拟库存，限购；

（2）供应链属性：用于作业指导，eg：生产方式，类型：原料/成品；

于是我们便得到了完整的商品属性项分组表：

最后一步在完成了中台的主体功能建设之后，我们接下来要做的就是重新将前台应用与后台的直接关联进行断开，在这两者中间插入中台，也就是让前台应用与中台建立关系，形成这样的一个系统体系：

6

最后

到这我们中台V1.0中的商品中心就建设完毕了，当然这里的商品中心仅是我们中台服务的第1个服务中心，除了要支撑我们现在的产品线之外，更重要的一个意义是为了跑通前台应用-中台-后台数据这种业务模式。

不过由于篇幅有限，本文中还牵扯到很多电商的内部传统产品设计问题没有展开来讲，如果有时间我后面会专门更新几篇完整的电商建设文章以供大家学习参考。

//三爷原创：往期精选好文推荐//

从零搭建企业级系统必备技能：业务建模

当传阿里也要拆中台后，背后的罪魁祸首“伪中台”终于浮出水面

中台实战（22）：中台MSS建设框架实战（三爷线下演讲实录）

每个在看↓，点赞↓就是对我最大的支持！