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

本篇我们来谈谈公司级中台实战的一个重要服务中心——商品中心搭建，该商品中心支撑全公司1万4千多类SKU的管理。

本文为新书《中台产品经理宝典》业务中台建设路径的拓展案例篇，关于案例中所涉及到的知识点可以参看下表：

PS：新书将于6月中旬上市大家敬请期待！

（后续中台文章中用到书中知识点的部分我都会标注详细章节，方便大家查阅书中内容）。

1. 起点：中台体系结构

要想学习一个系统的设计与建设思路，那么我们必须要从这个项目的启动背景来看起，这样才能知道很多设计的原因。

这个案例当时的业务背景是这样的，当时在公司内部共分为两条产品线，各自独立拥有自己的客户端面向不同类的客户：

• C端产品线：负责向普通消费者提供一般消费品售卖服务；
• B端产品线：负责向企业提供企业级采购服务。

由于两个业务从商业模式上并无不同，都是通过售卖商品来赚去商品差价。

而在业务模式我们按照《中台实战7 绕不开的企业架构》中讲述的梳理服务节点方法，得到整个商城的节点信息流模型如下图：

（这里为了文章讲解方便我将电商履约的完整后台进行了精简，只抽象出了最核心的几个节点。如果对这里感兴趣，我后面会写一些专门的电商文章）

仔细来看初期B端与C端的模式上，本质就是每单的客单价不同，因此从下单与订单拆分上没有任何区别，而当时唯一的差距就是在下订单之后，由于每单下单商品数量的不同，其物流配送方式上有一定的差距。

具体来说是如下几点：

因此我们可以发现在这里的业务流程中有变化的部分，也有不变的部分，而不变的部分占整个信息流节点的绝大部分。

于是在我们拿出这样的分析报告后，公司高层决定在公司内部来建设中台，由中台团队进行两条业务线的高重叠节点服务统一研发。

根据这个决定在开始正式建设前，当时我们的中台架构初步准备建设这样的三层服务体系：

• 服务组件： 是中台中的最小单元，服务组件也就是由开发编写的微服务代码，具体来说承载我们想要提供的复用功能，如我们上层希望支撑的商品类目管理服务，这里的微服务可能是：类目项增加，类目项删除，类目项修改，类目项查询，类目向兄弟系统的同步。用一句话来概括： 本层定义了中台的微服务项是哪些？
• 服务中心： 这是我们从功能实现的角度去定义的，也就是我们将中台划分为提供不同功能的几个模块，这里也就是我们产品经理经常会画的功能架构所定义的内容。而在当时我们只初步定义了商品，订单等几个模块，这里后文会展开来叙述。用一句话来概括： 本层定义了中台要实现哪些功能？
• 中台接入： 再往上一层就是我们将中台所提供的服务进行封装，对前台应用的部门我们给他提供简洁的服务接口让他们能快速的接入到中台里。用一句话来概括： 本层定义了中台要如何接入？

当然这里我们提出的架构更多是技术层面的支撑架构，目的是为了将中台进行一个肢解，让我们清楚地知道中台具体要干哪几件事情：

中台的微服务项是哪些->中台要实现哪些功能->中台要如何接入

当然虽然本篇文章名称叫做商品中心的搭建，但是作为案例篇的文章，我还是会给大家以商品来串讲一个包含完整三层体系中台架构的建设路径。

此处给大家个提醒，对于没有一定技术背景的产品经理来说，我们就需要拉上自己的项目经理共同去讨论并定义这样的架构。

在探秘了当年是怎么论证启动中台后我们下面来看看这个中台是想解决那些问题？

2. 分析：中台目标

建设一个系统根本意义上就是为了达成一个目标，那么这次我们的中台建设从抽象来说核心目标是为了解决“前台+后台”的齿轮速率匹配失衡的问题。

怎么理解呢？以我之前这家公司为例，在公司成立初期由于只有一个业务线，后台几乎对于前台的需求都是实时响应的，如今天要新增个物流查询功能，那么后台就会去对接快递公司并开发前台转发的接口。

而待我们又孵化出了B端项目后，我们发现当前台B，C端业务不断变化时，后台的响应就不是那么及时了。

究其原因就是作为后台每次为了支撑前台业务，后台都必须至少完成两件事：

• 提供对应的接口；
• 进行数据持久化建设。

而在这个大背景下由此带来的矛盾就是： 以往为了支撑前台越来越多的业务，后台在建设中不断追求服务稳定性就无法达到前台要的响应速度 ，当时我们发展到极端时一个简单的库存作业状态查询接口要开发半个月。

所以我们就需要一个中台去将一些基础的数据汇总到中台，由中台进行二次加工来快速响应前台的需要。

再说回商品中心建设案例，我们搭建中台具体说来是想找到这几个问题的解决方案：

问题1：

由于历史问题之前的供应链系统与商城并没有公用同一套完整的商品体系，也就是商城有自己的一套SKU体系，供应链中也有自己的一套SKU体系。

造成的结果是虽然大家货物可能都是一样的，但是在两个系统中SKU的ID（以及部分的名称）都是不一样的，此时当我们从下采购单入库后，收到的商品还不能直接成为前台库存，需要由仓库人员进行库存挂载，也就是将收到的货仓库由选择是前台的那个商品收到货了。

如果只是库存挂载我们还可以人工克服，但是在我们的SKU发展多了起来之后，遇到的另外一个问题就非常让人难以处理了，这就是SKU库存的转换。

对于实物商品来说我们经常会出现的一个局面是虽然都是最小库存单元的商品（也就是仓库计算库存的商品），但是却有不同的包规。

举个例子来说，作为可乐来说我们330ml的可乐它的最小库存单元都是一瓶易拉罐，也就是无论我们平时买到的是一箱可乐还是一组可乐，对于我们仓库来说这些SKU的库存都是转换为多少瓶可乐进行存储的，只不过对于这些不同的是我们有不同的包规。

还是不太明白是吧？没问题我给大家来看两张图SKU1：可乐330ml×24，SKU2：可乐330ml×6×4。

看出区别了吗？24=4*6连装与24=24装是完全不同的两个东西。但是注意这里是在实物上是两个不同的东西，但是在仓库库存系统里头这两个又是相同的东西。

具体来说在WMS（仓储管理系统）这两个SKU的存储结构是这样的：

看出点什么了吗？也就是说这两个SKU除了包规与名称外其实本质上是同一个东西：可乐330ml。

也就是这个问题导致了我们会出现一种场景，也就是当我们的商城前台售卖的时候，我们可能会出现某种包规的可乐售卖完毕了，因此我们就需要进行拆箱的动作，这个拆箱的动作就是来自于其他SKU的借调，也就是我们通过消耗一个可乐箱装库存，可以为我们的可乐单瓶装增加24个库存。

那么当采购纬度与商城的SKUid不统一的时候，我们人工去做这个动作就非常的复杂。

我们要消耗的这一箱可乐库存到底在原前台挂载在哪个SKU下？转换的目标SKU在前台又是什么？而如果在我们转换的时候又有了新的商品到货又要增加库存，这完全就让整个作业流程变得复杂，作业任务中需要核对的信息随着新的仓库动作成倍增长。

问题2：

采购对同一SKU不用进行二次分离（仓管纬度，在后面讲解供应链中台的文章中会展开详述）。

问题3：

SKU信息的标准化：基础属性+品牌+价格。

最后一个就是非常老生常谈的一个需求，我们希望借助中台将不同业务线系统里的SKU字段进行统一化管理，也就是全部交由中台进行管理。

以此我们对于SKU的信息能实现有一个地方能去查看它全量的信息，从而当其他业务线有这样的需求的时候无需再去修改数据库字段，就可以直接由中台将该字段通过接口暴露给该业务线，实现0开发使用。

故此我们就得到了中台商品中心的V1.0功能架构：

3. 分析：建设方案

中台本质是什么？这个问题我们从技术实现上来看其实就是数据沉淀与代码复用。为了达到这样的效果，我们在产品设计上必须也使用高灵活性设计方法。

那又要怎么做呢？在我的《中台产品经理宝典》一书中我为大家总结过一个5步搞定中台建设的MSS方法论（MSS方法论可以参看书第6章），而如果让我用一句话来总结这里面最核心的步骤就是： Summary与Details分离化设计模式。

• Summary ：信息对象摘要；
• Details ：信息对象详情。

举例来说我们设计一个账期功能，其包含的基础信息有商品下单扣费，配送运费扣费，商品退款额度返还等现金流，这个时候账期功能的信息架构设计时我们就应该分为如下两层体系：

这样分层的目的是为了保证我们在前台业务展示的时候，尽量在同一个位置显示一个层级的东西。

例如绝大多数信息架构设计好的产品在功能的首页通常展示的都是信息的Summary，而会在详情页承载功能的Details。

通过这样的信息架构划分，我们就可以将一个功能交由中台和前台分离了，也就是将产品的摘要信息由中台定义，具体的详情信息由各业务前台进行补充。

这就是中台建设MSS方法论里最重要的一个建设原则，而现在市面上80%的中台复用模式都可以依据这个建设原则进行实现。当然这样的设计原则对我们在产品的信息架构的抽象能力是有一定的要求。

回顾一下我们现在已经完成了如下这些工作：

到这里中台的需求分析就已经进行完毕了，我们可以看到在中台从零到一的时候与普通功能设计最大的不同就是需要增加从全公司业务维度出发的通盘思考。

那么从下篇开始我们正式进入中台商品中心的建设篇里。