供应链系统设计-供应链中台系统设计（七）- 商品中心设计篇

概述

上篇文章我们大致讲了一些商品中心相关的概念，例如：SPU、SKU、Item等等，在这里我们来简单的回顾一下：

商品概念的分层与定义：

SPU（Standard Product Unit）：代表产品系列或产品组，具有相似特征的产品集合。它定义了一类商品的关键属性和绑定属性，但不包含销售信息。
CSPU（Child Standard Product Unit）：作为SPU的补充，增加了销售属性，可以完全确定一款商品。它是SPU加上销售属性，如容量、颜色、存储容量等。
ITEM：商家发布的产品实例，包含SPU信息和商家信息。它是SPU的一个实例，可以被搜索到，并且受到SPU规范的限制。
SKU（Stock Keeping Unit）：库存管理中的最小单元，代表具体可销售的商品变体，如不同颜色、尺寸的同一产品。SKU由CSPU加上商家、价格和库存信息构成。

类目管理的重要性：

类目管理帮助用户快速找到目标商品，提高用户体验。
它为运营维护商品信息提供方便，为其他功能如品牌关联、仓库管理和数据分析提供基础支撑。
类目管理在电商运营中是基础，提升整体运营效率。

前端与后端类目管理的差异：

后端类目：面向商家和运营人员，需要客观、统一的分类标准，以便于日常操作和团队协作。后端类目相对固定，不轻易变更和删除。
前端类目：面向消费者，需要通俗易懂的命名，减少类目数量和层级，以简化购物流程。前端类目灵活多变，以适应市场变化和运营策略。

什么是一个好的商品中心

好都是相对的，在我们需要知道什么是一个好的商品中心，我们需要了解商品中心需要服务的具体业务场景是什么。

我们之前在供应链系统设计-供应链中台系统设计（六）- 商品中心概念篇中提到了阿里的业务场景，如下图所示：

阿里有淘宝、天猫、健康业务等，这些业务都会有维护商品、发布商品等诉求，因此，我们需要从业务流程来看，对于商品维护和发布的商品流程大致是怎么样的。因为所有系统首先需要满足业务流程的诉求。

从商品的角度来看，无论是淘宝、天猫和健康业务，还是其他的公司的业务，对于供应链业务而言，主要就是针对商品进行“进销存”活动，因此，我们把商品的在业务过程中整个生命周期细化为如下图所示：

商品生命周期图（极简版）

由上图，我们其实可以看出所有从SPU/CSPU/SKU/ITEM都是围绕着供应链业务的进销存来开展的。其实在实际的业务中，例如：SKU对于供应商来说，会存在起发量和最小订货倍数，对于SKU也会存在生成状态，SKU与SKU之间也会存在新老号的关系，主子商品等等，这里里面有非常多的细节就没有展开了，我们主要是先了解商品在整个进销存的过程的大致的生命周期。

因此，基于对于商品生命周期的理解，商品中心作为中台的一个核心的主数据，我们来想想可能会存在的问题：

首先，如果淘宝、天猫针对统一个商品，是两个不同的SKU，会怎么样？会出现SKU泛滥，导致对于同一样SKU，因此，对于平台来说商品就泛滥了，无法识别销售或购买的是那个商品，对于后续商品数据统计与分析就无从下手。因此，商品中心核心就是构建商品标准，防止商品标准泛滥。

其次，作为商品中心，作为通用中台的一部分，需要最大程度的给前台业务提供可复用的能力，让前台业务可以快速服务客户的产品创新和精细化运营，而不是把时间花在系统通用能力的构建上。

在这里我们再来回顾一下前中后台的定义：

前台：指离客户最近，最理解和洞察客户需求和行为，最终实现和提升客户价值的职能。其核心能力是对市场和客户行为深刻洞察，服务客户的产品创新和精细化运营；主要围绕C端和B端客户建立灵活、创新和快速响应的机制。

中台：指为前台业务运营和创新提供专业能力的共享平台职能。其核心能力是专业化、系统化、组件化、开放化；主要通过沉淀、迭代和组件化地输出可以服务于前端不同场景的通用能力，不断适配前台。

后台：指为整个商城提供基础设施建设、服务支持与风险管控的职能。其核心能力是专业化、服务意识与能力。

如果大家对于前中后台不是很熟悉，可以参考：供应链系统设计-何为“前”“中”“后”台系统的文章，里面有详细的描述。

基于以上中台的定位就决定商品中心其实非常大的程度上，前台商品信息标准的制定者。

最后，对于前后台业务来说，从商品生命周期来看，供应链的主要是针对商品进行进销存的业务活动，一个商品从采购到最后销售，会涉及到非常的业务活动和规则，这个里面需要协调各个非常多的部门。

如何让商品信息进行更好的协同，什么可以采购、什么是可售等，如何控制已不销售，但是采购部还在不停的进行采购，无法解决采销不一致问题呢等等。

这个就会涉及到商品的生命周期管理，一个商品从采购到最后的下架，都会经历非常多的业务环节，进销存的每个业务环节中如何能够基于商品去进行协同一致就非常重要了。

因此，我们基于上面讨论的大致思路，我们从业务的视角，暂且将一个好的商品中心的标准定义为以下三点：

1、需要构建商品标准体系，防止商品应用数据泛滥；

2、商品中心作为中台的一部分，应该抽象前台业务的共性需求，让中台商品能力复用最大化，以此来提高前端业务的效率；

3、商品生命周期需要保证围绕供应链进销存协同一致；

以上是从业务角度去思考何为一个好的商品中心的三个标准，好的标准针对不同的行业、不同的公司、不同的业务场景都是不同的，我只是站在当前的业务场景下去进行思考，这个大家一定要注意，好的标准一定是根据具体的业务场景来确定的。

上面是基于业务诉求，其实我们做架构的时候，还需要考虑到非业务诉求，也就是系统的质量诉求。针对商品中心的需要服务的业务场景和特性，质量诉求如下4点：

1、数据正确性。商品作为主数据，数据的正确性的重要是不言而喻，因此，需要有纠错的机制和能力；

2、海量的商品数据。根据SPU/CSPU/SKU/ITEM的概念，商品数据会随着业务的发展会不断的成倍增长；

3、高并发读请求。商品数据是典型的读多写少的访问场景，需要支撑前台业务高并发的读请求；

4、模型和系统稳定性要求高。商品中心作为最底层的主数据服务，几乎前台业务所有的应用都会依赖它，因此，领域模型的稳定性和系统的稳定性就非常重要。如果商品模型经常变化，经常性修改势必会影响到前台业务的稳定性。

以上就是针对什么是一个好的商品中心的标准的定义。

商品设计落地

一个好的商品中心标准定义分为了业务诉求和质量诉求两部分，我们设计现在就围绕好的标准去进行展开设计。

基于业务诉求的好标准设计

首先，我来第一个好的标准。

1、需要构建商品标准体系，防止商品应用数据泛滥；

数据泛滥问题，首先需要从商品标准来进行限制。前文讲过了SPU/CSPU/SKU/ITEM的模型，如下图所示：

对于SPU/CSPU/SKU的标准都统一收口到一个组织进行维护，而不是让业务前台来定义标准。不同的前台业务对于商品的诉求都是不一样的，前台业务和后台业务都可以发起SPU/CSPU/SKU，但是对于SPU/CSPU/SKU的维护，则需要收口到一个商品管理中心的组织。商品管理中心就是来进行商品的管理以及治理，避免出现相同商品数据的标准不一，出现重复的数据。