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

概述

上篇文章我们大致讲了一些商品中心相关的概念，例如：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的维护，则需要收口到一个商品管理中心的组织。商品管理中心就是来进行商品的管理以及治理，避免出现相同商品数据的标准不一，出现重复的数据。

我们再来看看第二个标准，如下：

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

由于我们知道不同的业务对于商品维护、发布都会有不同的诉求，这个会随着业务的发展业务流程的差异回来越大。我们在供应链系统设计-中台系统设计系列（二）- 好中台的标准之复用原则的文章聊到了不同业务可能存在不同的商品新增、发布等业务流程，如下图所示：

在业务流程层，其实对应的都是不同的业务的流程，不同的业务差异是非常大的。因此，从最小复用的角度来看，在这一层是不太可能复用的，这一层需要前台业务自己去进行定义。因此，中台在业务业务流程的层面，其实在业务初期是很难提供流程级别的复用能力。具体可以如下图所示

在这里，我和大家再次回顾一下，前台开发和中台开发的核心区别：

业务前台技术：基于中台提供的能力，进行能力集成、编排、扩展，实现个性化的业务逻辑，及展现层 。衡量指标：业务支撑的效率、行业解决方案的沉淀

业务中台技术：面向业务能力的开发，以最小复用原则。衡量指标：能力的稳定性和复用性

因此，我们需要看每个流程中的节点，对于每个流程节点能力是否可以复用。因此，我们可以想到如下的设计：

我们将类目、属性、SPU/CSPU/SKU/ITEM等增删改查的最小粒度操作，定义成为能力。这样不管是哪类业务都是需要复用的，都可以复用，这样业满足最小复用原则，做到复用的最大化。

大家一定的记住，在业务发展阶段，我个人建议对于中台能力最好是以原子能力沉淀为主，就是能力的最小化，做到能力职责的最小，一个能力只做一件事情，例如：SKU创建、ITEM创建。对于创建就是单纯创建业务，不要包含创建之外的逻辑，否则复用能力会非常差。

这个我在之前的中台建设的经验中，非常有感触，也踩过雷，因此也别提出来。

我们再来看看第三个指标：

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

如果从供应链进销存的视角来看，商品大致可以分为以下四个阶段：商品主数据维护、进、存、销四个业务阶段。如下图所示：

大家可以想想一下，可能会存在的问题：

1、采购状态与销售状态不统一，禁止销售的商品，还在不断的进行采购

2、在采购的时候，由于没有维护SKU信息，导致无法进行采购

3、销售进行售卖，发现商品过期了，仓库没有维护商品有效期信息

4、由于主数据没有维护销售渠道，一线业务无法新增ITEM，导致不能在一线业务进行销售

....

以上问题，可以总结为业务组织协同以及流程问题。我们可以通过对于商品生命周期的定义来进行解决。商品生命周期具体流程其实已经在文章开头的流程图图中已经展示了，在这里就不再进行赘述了。

主要是让大家明白，商品生命周期的管理对于业务的重要性以及对于商品中心本身的意义。

写在最后话

今天主要和大家讨论了关于一个好的商品中心的标准的是什么，因为没有好的标准，我们的设计其实是没有目标的。因此，这个是一个非常重要的问题。一个好的商品中心标准，可以分为业务诉求和质量诉求两个部分，具体如下：

业务诉求

• 统一标准：制定统一的商品数据标准（如SPU、SKU等），避免数据重复和不一致，确保数据准确性和一致性.
• 流程支持与复用：在流程节点层面提供最小粒度的能力复用，如类目、属性等的增删改查操作，满足不同业务需求，实现能力的最大化复用.
• 生命周期管理：有效管理商品从采购到销售再到下架的生命周期，协调各部门协同工作，解决采销不一致等问题，确保商品信息在各业务环节的一致性.

质量诉求

• 性能：具备高性能处理能力，快速响应大规模商品数据处理和高并发业务请求.
• 可靠性：保障数据可靠性和系统稳定性，通过数据备份、容灾机制等措施，确保系统在异常情况下快速恢复.
• 可扩展性：架构设计支持模块化和组件化，便于灵活扩展功能和适应业务变化.
• 安全性：采取严格的安全措施，如数据加密、访问控制等，防止数据泄露和非法访问，确保系统安全.

我们针对业务诉求部分进行展开讨论，并且说明了在具体实施过程中需要注意的设计点。由于商业保密原因，在这里不能详细进行说明，希望大家可以谅解。

关于质量诉求，其实涉及到业务知识不多，更多是偏纯技术架构层面的东西，我会在下篇文章的中和大家继续探讨。

今天就和大家聊到这样，希望能够给大家带来一些收获和启发，下篇文章见哟。