产品经理中台实战(九)：从零开始中台商品中心搭建(上)

1、本篇我们来谈谈公司级中台实战的一个重要服务中心 商品中心搭建，该商品中心支撑全公司 1 万 4 千多类 SKU 的管理。本文为新书中台产品经理宝典业务中台建设路径的拓展案例篇，关于案例中所涉及到的知识点可以参看下表：PS:新书将于6月中旬上市大家敬请期待！（后续中台文章中用到书中知识点的部分我都会标注详细章节，方便大家查阅书中内容）。要想学习一个系统的设计与建设思路，那么我们必须要从这个项目的启动背景来看起，这样才能知道很多设计的原因。这个案例当时的业务背景是这样的，当时在公司内部共分为两条产品线，各自独立拥有自己的客户端面向不同类的客户：由于两个业务从商业模式上并无不同，都是通过售卖商品来赚

2、去商品差价。而在业务模式我们按照中台实战 7 绕不开的企业架构中讲述的梳理服务节点方法，得到整个商城的节点信息流模型如下图：（这里为了文章讲解方便我将电商履约的完整后台进行了精简，只抽象出了最核心的几个节点。如果对这里感兴趣，我后面会写一些专门的电商文章）仔细来看初期 B 端与 C 端的模式上，本质就是每单的客单价不同，因此从下单与订单拆分上没有任何区别，而当时唯一的差距就是在下订单之后，由于每单下单商品数量的不同，其物流配送方式上有一定的差距。具体来说是如下几点：因此我们可以发现在这里的业务流程中有变化的部分，也有不变的部分，而不变的部分占整个信息流节点的绝大部分。于是在我们拿出这样的分析报

3、告后，公司高层决定在公司内部来建设中台，由中台团队进行两条业务线的高重叠节点服务统一研发。根据这个决定在开始正式建设前，当时我们的中台架构初步准备建设这样的三层服务体系：当然这里我们提出的架构更多是技术层面的支撑架构，目的是为了将中台进行一个肢解，让我们清楚地知道中台具体要干哪几件事情：中台的微服务项是哪些- 中台要实现哪些功能- 中台要如何接入当然虽然本篇文章名称叫做商品中心的搭建，但是作为案例篇的文章，我还是会给大家以商品来串讲一个包含完整三层体系中台架构的建设路径。此处给大家个提醒，对于没有一定技术背景的产品经理来说，我们就需要拉上自己的项目经理共同去讨论并定义这样的架构。在探秘了当年是

4、怎么论证启动中台后我们下面来看看这个中台是想解决那些问题？建设一个系统根本意义上就是为了达成一个目标，那么这次我们的中台建设从抽象来说核心目标是为了解决 “前台 +后台 ”的齿轮速率匹配失衡的问题。怎么理解呢？以我之前这家公司为例，在公司成立初期由于只有一个业务线，后台几乎对于前台的需求都是实时响应的，如今天要新增个物流查询功能，那么后台就会去对接快递公司并开发前台转发的接口。而待我们又孵化出了 B 端项目后，我们发现当前台 B ， C 端业务不断变化时，后台的响应就不是那么及时了。究其原因就是作为后台每次为了支撑前台业务，后台都必须至少完成两件事：而在这个大背景下由此带来的矛盾就是：以往为了

5、支撑前台越来越多的业务，后台在建设中不断追求服务稳定性就无法达到前台要的响应速度，当时我们发展到极端时一个简单的库存作业状态查询接口要开发半个月。所以我们就需要一个中台去将一些基础的数据汇总到中台，由中台进行二次加工来快速响应前台的需要。再说回商品中心建设案例，我们搭建中台具体说来是想找到这几个问题的解决方案：问题 1：由于历史问题之前的供应链系统与商城并没有公用同一套完整的商品体系，也就是商城有自己的一套SKU 体系，供应链中也有自己的一套SKU 体系。造成的结果是虽然大家货物可能都是一样的，但是在两个系统中 SKU 的ID （以及部分的名称）都是不一样的，此时当我们从下采购单入库后，收到的

6、商品还不能直接成为前台库存，需要由仓库人员进行库存挂载，也就是将收到的货仓库由选择是前台的那个商品收到货了。如果只是库存挂载我们还可以人工克服，但是在我们的 SKU 发展多了起来之后，遇到的另外一个问题就非常让人难以处理了，这就是SKU 库存的转换。对于实物商品来说我们经常会出现的一个局面是虽然都是最小库存单元的商品（也就是仓库计算库存的商品），但是却有不同的包规。举个例子来说，作为可乐来说我们330ml 的可乐它的最小库存单元都是一瓶易拉罐，也就是无论我们平时买到的是一箱可乐还是一组可乐，对于我们仓库来说这些SKU 的库存都是转换为多少瓶可乐进行存储的，只不过对于这些不同的是我们有不同的包规

7、。还是不太明白是吧？没问题我给大家来看两张图SKU1:可乐330m1X24,SKU2:可乐 330ml 6 4。看出区别了吗？ 24=4*6 连装与24=24 装是完全不同的两个东西。但是注意这里是在实物上是两个不同的东西，但是在仓库库存系统里头这两个又是相同的东西。具体来说在 WMS （仓储管理系统）这两个SKU 的存储结构是这样的：看出点什么了吗？也就是说这两个SKU 除了包规与名称外其实本质上是同一个东西：可乐 330ml。也就是这个问题导致了我们会出现一种场景，也就是当我们的商城前台售卖的时候，我们可能会出现某种包规的可乐售卖完毕了，因此我们就需要进行拆箱的动作，这个拆箱的动作就是来自

8、于其他SKU 的借调，也就是我们通过消耗一个可乐箱装库存，可以为我们的可乐单瓶装增加 24 个库存。那么当采购纬度与商城的 SKUid 不统一的时候，我们人工去做这个动作就非常的复杂。我们要消耗的这一箱可乐库存到底在原前台挂载在哪个SKU 下？转换的目标 SKU 在前台又是什么？而如果在我们转换的时候又有了新的商品到货又要增加库存，这完全就让整个作业流程变得复杂，作业任务中需要核对的信息随着新的仓库动作成倍增长。问题 2：采购对同一SKU 不用进行二次分离（仓管纬度，在后面讲解供应链中台的文章中会展开详述）。问题 3：SKU 信息的标准化：基础属性 + 品牌+价格。最后一个就是非常老生常谈的一

9、个需求，我们希望借助中台将不同业务线系统里的 SKU 字段进行统一化管理，也就是全部交由中台进行管理。以此我们对于SKU 的信息能实现有一个地方能去查看它全量的信息，从而当其他业务线有这样的需求的时候无需再去修改数据库字段，就可以直接由中台将该字段通过接口暴露给该业务线，实现0 开发使用。故此我们就得到了中台商品中心的 V1.0 功能架构：中台本质是什么？这个问题我们从技术实现上来看其实就是数据沉淀与代码复用。为了达到这样的效果，我们在产品设计上必须也使用高灵活性设计方法。那又要怎么做呢？在我的中台产品经理宝典一书中我为大家总结过一个 5步搞定中台建设的 MSS 方法论（ MSS 方法论可以参

10、看书第 6章），而如果让我用一句话来总结这里面最核心的步骤就是：Summary与Details分离化设计模式。举例来说我们设计一个账期功能，其包含的基础信息有商品下单扣费，配送运费扣费，商品退款额度返还等现金流，这个时候账期功能的信息架构设计时我们就应该分为如下两层体系：这样分层的目的是为了保证我们在前台业务展示的时候，尽量在同一个位置显示一个层级的东西。例如绝大多数信息架构设计好的产品在功能的首页通常展示的都是信息的Summary,而会在详情页承载功能的Details。通过这样的信息架构划分，我们就可以将一个功能交由中台和前台分离了，也就是将产品的摘要信息由中台定义，具体的详情信息由各业务前台进行 补充。这就是中台建设MSS 方法论里最重要的一个建