惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

V
Visual Studio Blog
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
G
Google Developers Blog
J
Java Code Geeks
爱范儿
爱范儿
Microsoft Azure Blog
Microsoft Azure Blog
美团技术团队
人人都是产品经理
人人都是产品经理
Martin Fowler
Martin Fowler
IT之家
IT之家
博客园_首页
B
Blog RSS Feed
Google DeepMind News
Google DeepMind News
B
Blog
U
Unit 42
Apple Machine Learning Research
Apple Machine Learning Research
L
LangChain Blog
Stack Overflow Blog
Stack Overflow Blog
罗磊的独立博客
N
Netflix TechBlog - Medium
T
Tailwind CSS Blog
博客园 - 聂微东
腾讯CDC
A
About on SuperTechFans

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
一文搞懂:商品管理系统架构设计
AI架构师汤师爷 · 2024-06-10 · via 人人都是产品经理

本文主要介绍了商品管理系统的设计原则、架构框架及其实现细节,为读者解读了如何构建一个成熟稳定的商品管理体系。

对于零售业务来说,商品系统几乎需要支撑所有业务系统,从商品采购、到仓库收货、上架、前台展示、下单、配送、用户收货、到售后服务等环节,都离不开商品系统。

为了保障业务的稳定性、可扩展性,必须要重视商品系统建设,否则,后续业务和系统将很快丧失扩展性和灵活性,甚至无法支撑业务发展,必须推倒重来,付出巨大的代价才能挽救。

一、商品系统的设计挑战

1. 行业需求差异大

不同行业对商品管理的需求差异巨大,想要构建成熟稳定的商品系统,需要对各行业的商品管理需求,进行深度分析。只有这样,才能抽象出共性的规律和特征,保障业务建模的质量。列举一些行业差异性需求:

  • 时尚服装:款式管理,配比、配码管理,商品季节性管理。
  • 3C数码:串码管理,配件管理,售后维修。
  • 美容护肤、医药保健:批号管理,生产日期与有效期管理,试用品管理。
  • 生鲜行业:生产日期与有效期管理 ,生鲜加工管理,称重商品与 PLU 码,辅助单位管理(管理重量和数量,例如:鱼,按照重量核算,以条作为辅助单位)。

2. 支撑的业务链路复杂

商品系统作为最基础、最核心的系统之一,它的重要性体现在所有的业务流程中,几乎所有业务系统都需要依赖商品系统的能力。

从业务全流程来看,商品系统需要提供强大的功能,来支撑采购、配送、销售、履约、售后、退仓、财务核算、结算、数据分析等各个业务环节。

从商品生命周期的管理来看,商品状态包括建档、新品、正常、淘汰、清理等,各个状态之间流转也异常复杂。

每个状态代表商品在市场上的阶段,不同状态也影响库存、销售和营销环节。比如,新品需要更多推广和展示位,而淘汰阶段的商品可能需要打折或特卖,来清理库存。

3. 消费者端与商家端需求叠加

零售商品系统既要满足消费者端的使用需求,也要满足商家端的运营需求。这些需求叠加在一起,会带来复杂度的挑战。

消费者端需求强调用户体验,如浏览界面友好、搜索商品便捷、购买商品便捷、个性化推荐等。

商家端需求注重运营效率,如批量操作、库存操作、营销选品、采购配送操作、数据分析等。

商品系统既要满足消费者体验,又要让商家端运营高效,在设计系统时,需要平衡这两端的需求,并提供不同的功能模块,来适应不同用户的需求。如何保证系统的易用性和扩展性,是非常大的挑战。

4. 连锁多组织管理

对于连锁零售企业,商品系统需要能够管理多个组织、多个门店的商品业务。例如,不同区域的价格策略、库存分配、销售策略和促销活动等。

系统需要支持跨区域、跨门店的商品数据同步,同时还要保持各个组织之间的数据隔离和权限管理。这在架构设计上也需要充分考虑。

二、商品业务流程

三、商品概念模型设计

1. 商品基础

平台SPU:指的是标准化产品单元,是商品信息聚合的最小单位,是一组可复用、易检索的标准化信息的集合,该集合描述了一个产品的特性,又可称为平台商品。SPU的概念来源于电商平台业务,SPU模型会提取商品的共性属性用于信息检索,这些属性通常是能够快速识别商品,并且是消费者较为关心的属性。其次,SPU的属性是全平台标准化的,这样才能有效保障消费者的检索体验与商家利益,例如,消费者搜索256G的iphone13,有填内存容量的商品能搜出来,没填内存容量的商品就搜不出,这显然不合理,因此平台需要规范所有商品的关键属性。

商品:特指商家的零售商品,一个商家可以有很多商品,若N个商家卖同一个商品,如iphone13,该场景下有1个平台SPU实例,N个商品实例。每个商品可以有多个规格,例如大小、颜色、尺码等。

SKU:SKU(Stock Keeping Unit)指的是库存量单位,又称最小存货单位。以iphone13为例,关键规格有颜色(黑色、红色、银色、金色)、容量(128G、256G、512G),可以组合出4×3=12个SKU。

2. 商品类型

  • 实物商品:以有形实体存在,不能通过网络来传递,必须依赖传统的物流运输系统来传递。例如,鸡蛋、大米、手机等。
  • 服务商品:能够实现交易的无形商品,无需物流参与,就能完成交易,例如,话费充值等。
  • 组合商品:一般指人为将几个单独售卖的商品组合在一起,进行合并售卖的商品,例如:下午茶套餐、七夕美妆组合等。
  • 多规格商品:代表一组SKU的商品,消费者只能选中其中一个SKU,例如,以iphone13为例,关键规格有颜色(黑色、红色、银色、金色)、容量(128G、256G、512G),消费者选中了黑色128G的iphone13进行下单交易。
  • 预售商品:一般来说,预售商品会提前销售,但实物还未生产,因此,预售商品不会录入实物库存,售出也不会扣减实物库存。预售商品由一组原材料加工而来,加工关系一般称作配方,因此,当预售商品扣减库存时,实际会扣减原材料的库存。

3. 商品类别

  • 前台类目:前台类目是面向消费场景和用户视角的分类,根据运营需求,灵活多变,主要用于用户快速筛选。
  • 后台类目:后台类目是前台类目搭建的基础,后台类目主要面向商家运营,相对稳定,不会经常变更。
  • 品牌:品牌是比较特殊的商品属性,需要单独进行管理。品牌是人们对一个企业及其产品、售后服务、文化价值的一种评价和认知,是一种对企业的信任背书。

4. 商品属性

商品属性,又称为产品属性、商品参数,是产品本身固有的特征。不同行业的商品,差异非常大,有很多行业差异化属性。根据使用目的、用途不同,演化出各式各样的属性,有的用于展示,有的用于分析,有的用于经营管控。

下面根据商品属性不同的分类法,逐一展开描述:

  • 描述属性:商品货号、商品名称、商品描述、规格、型号、产地、等级、生产厂商、商品图片等。
  • 统计属性:品牌、分类、系列、款式、适用人群、适用年龄等。
  • 考核属性:一般用于组织业绩考核,品牌、分类、系列等。
  • 物流属性:长、宽、高、净重、毛重、重量单位等。
  • 管控属性:是否季节商品、是否保险、是否支持配送、是否支持打折、是否保质期管控、是否串码管理等。
  • 销售渠道属性:不同的销售渠道会有一些特殊的属性,例如,美团、饿了么的最小购买数量、平台分类等。
  • 销售属性:也称为规格属性,该属性是组成SKU的特殊属性,直接影响到买家的购买和商家的库存管理,例如衣服的颜色、尺寸。

5. 商品价格

  • 指导价:厂商给出的一个出售的参考价格。
  • 销售价:商家根据自己情况提高或降低指导价得到的最终销售价格。
  • 渠道价格:在分渠道售卖的时候,商品的基础销售价格。
  • 时间价格:不同的时间,可以有不同的价格。
  • 成本价:一般特指商品的单个成本,成本价会到sku维度。

6. 组织层级商品

  • 商品库:零售企业操作和管理商品的总集。
  • 管理层级商品:管理层级需要操作和管理的商品的集合,通常是由集团总部下发下来的,管理层级有多种形态,例如区域、部门、分公司、子公司、门店等。
  • 渠道商品:发布到某个销售渠道的商品集合,例如微信商城、美团外卖、饿了么外卖等渠道。

7. 商品状态

商品的生命周期状态:建档、新品、正常、预淘汰、淘汰、清理、待归档等。

商品的运营状态:商品在各个业务阶段,可以有不同的运营状态,例如,用于控制商品销售的上架、下架状态。

四、商品应用架构设计

  • 展现层:直接与用户交互的层级,负责向用户显示信息,响应用户命令。
  • 应用层:应用层的服务对应一个具有业务价值的场景用例,主要负责对核心服务进行组合和编排,负责处理场景用例内的执行顺序以及结果的组装,通过API网关向展现层提供服务。
  • 消费者端:负责向消费者展示商品信息,包括商品详情、价格、库存等。提供商品搜索、浏览、购买等功能。
  • 商品库管理:负责管理所有商品的详细信息。
  • 商品类别管理:管理商品的分类体系,如前台类目、后台类目、品牌等。
  • 属性管理:管理商品的属性定义,如颜色、尺寸、材质等。
  • 商品同步:总部向其他组织同步商品信息,例如,分店商品同步。
  • 渠道商品管理:针对不同销售渠道的商品信息管理,如线上商城、线下门店、三方平台等。
  • 开放API:提供接口供外部系统访问商品信息和服务。
  • 领域层:系统的核心层,负责表达业务概念、业务状态以及业务规则,包含了该领域(问题域)复杂的业务知识抽象和规则定义。该层难点在于分析领域模型,例如实体,值对象,聚合(聚合根),领域服务,领域事件,仓储,工厂等方面的分析,成熟的领域逻辑不会有太大变化,所以服务层的业务逻辑通常是共性的、稳定的。
  • 类别服务:提供商品分类的核心逻辑和数据操作。
  • 属性服务:管理所有商品的属性模型,提供属性添加、修改、删除等核心功能。
  • 商品服务:处理商品的核心业务逻辑,管理商品的生命周期,包括商品的创建、更新、查询和删除。
  • 商品价格:负责商品的定价策略和价格变动管理,提供价格设置、更新和查询服务。
  • 组织层级服务:提供组织层级商品的查询和管理服务。
  • 快照/日志服务:记录商品和价格的历史变更信息,提供系统操作的跟踪。
  • 主数据平台:主数据是跨部门、业务系统,能够反映核心业务实体状态的核心基础信息。对于商品系统而言,商家信息、组织机构、员工权限、商品数据模型是该系统依赖的主数据。在业务早期,主数据平台是非必须的,上层系统模块直接从DB中读取数据并应用即可,但随着系统逐步复杂后,多个团队对数据的改动会互相影响,不利于系统扩展,可用性也大大降低,因此,需要拆分出多个主数据服务,将核心数据的访问收拢在一起。

五、小结

商品管理系统是零售业务的核心,涵盖商品采购、仓库收货、上架、前台展示、下单、配送、用户收货、售后服务等环节。

设计商品系统时,需要考虑行业需求差异、业务链路复杂性、消费者端与商家端需求叠加以及连锁多组织管理等挑战。

商品系统的概念模型包括商品基础、商品类型、商品类别、商品属性、商品价格、组织层级商品和商品状态等。商品系统的应用架构设计包括展现层、应用层和领域层,以及主数据平台。

本文由人人都是产品经理作者【汤师爷】,微信公众号:【架构师汤师爷】,原创/授权 发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash,基于 CC0 协议。