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

那么当采购纬度与商城的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%的中台复用模式都可以依据这个建设原则进行实现。当然这样的设计原则对我们在产品的信息架构的抽象能力是有一定的要求。
回顾一下我们现在已经完成了如下这些工作：
到这里中台的需求分析就已经进行完毕了，我们可以看到在中台从零到一的时候与普通功能设计最大的不同就是需要增加从全公司业务维度出发的通盘思考。
那么从下篇开始我们正式进入中台商品中心的建设篇里。
#相关阅读#
中台实战（0）：最近处处惹人爱的中台到底是什么
中台实战（1）：看懂企业业务演进路线
中台实战（2）：中台的建设核心原则
中台实战（3）：数据中心中台化案例
中台实战（4）：业务的抽象建模
中台实战（5）：数据指标体系创建思维
中台实战（6）：业务边界的划定
中台实战（7）：绕不开的企业架构
中台实战（8）：以传统制造业来解读中台
#专栏作家#
三爷，微信公众号：三爷茶馆，人人都是产品经理专栏作家。曾万达高级产品、MBA特约讲师、独立创业者，现某支付公司产品线负责人，拥有多款集团项目从零到一经验并带领实现商业化布局。
本文原创发布于人人都是产品经理。未经许可，禁止转载