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

本文插图

此处给大家个提醒，对于没有一定技术背景的产品经理来说，我们就需要拉上自己的项目经理共同去讨论并定义这样的架构。
在探秘了当年是怎么论证启动中台后我们下面来看看这个中台是想解决那些问题？
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个库存。