新零售SaaS架构:中央库存系统架构设计

简介: 新零售SaaS架构:中央库存系统架构设计


近年来,越来越多的零售企业大力发展全渠道业务。在销售额增长上,通过线上的小程序、直播、平台渠道等方式,拓展流量变现渠道。在会员增长方面,通过多样的互动方式,全渠道触达消费者,扩大会员规模。而全渠道的库存管理,逐渐变成零售商在渠道运营方面的核心活动,也是提高库存周转率,保证利润的关键所在。

在全渠道模式下,各渠道必须有足量的商品来满足客户需求,同时需有效管理总库存,平衡各渠道库存,以减少缺货或者滞销的情况发生。

全渠道模式下,库存管理面临的挑战

在线上线下渠道融合的大背景下,零售企业如果没有管理好全渠道库存,会带来诸多问题:

  • 各渠道库存割裂,进行线上线下促销活动时,商品超卖,引起客诉。
  • 各渠道库存分配不合理,要么缺货,要么库存积压。
  • 各渠道库存数据更新不及时,有货却不能下单,销售机会大量流失。
  • 各地库存数据分散在各系统中,数据不通,无法知晓库存分布情况,无法统一采购/调拨。
  • 无法根据用户的下单信息,进行智能分仓、就近发货。

中央库存系统的定位

向下对接各地仓库/门店库存,将各地库存放在“一盘货”里,进行管理、统一调配。

向上打通所有销售渠道平台,实现全渠道库存共享、自动化运营。

中央库存系统的关键概念

中央库存整体业务框架

中央库存体系将库存管理分为三层,销售层、调度层、仓库层,实现库存利用最大化,支持多仓多渠道模式下的各种业务场景。

仓库层

仓库层的定位是管理仓库库存,一般使用仓库WMS、门店系统或ERP系统来管理仓库的进销存,通过出入库单据变更仓库库存数量。

仓库库存的关键属性包括:货主、仓库/门店、SKU、批号、生产日期、库存状态、库位等。

  • 货主:货物所有权的拥有者。
  • 仓库/门店:存储货物的逻辑单元,这里需要与物理世界的仓库区分开,可能一个物理仓库包含多个逻辑仓库单元。
  • 批号:用于区分每一批投料生产出来的产品,为了事后能追踪这批产品的责任,每一批产品都有相应的批号。
  • 生产日期:生产线包装出可销售的成品的日期与时间。
  • 库存状态:描述库存在不同业务场景下的不同状态,例如,可用、冻结、在途、不良品、废品等。
  • 库位:一般是指在工厂仓库中实际存在的库位,比如一个个的货架。同时也是SKU库存的最小粒度。

调度层

调度层的定位是汇总各仓库/门店的所有库存状态的库存总量,但不同于仓库库存,调度层的实物库存无需管理批号、库位等细粒度的库存维度,只需要管理每个库存状态下的实物库存总数即可,这是一种解耦的设计方式。

实物库存的关键属性包括:仓库/门店、SKU、库存状态等。关键概念包括:

  • 在途库存:指供应商发货但还未入库的库存,有时为了扩大销售机会,在途库存也会用于扩大销售库存数量。
  • 可用实物库存:仓库实际可用于销售的库存。
  • 不可用实物库存:即对应仓库中的不可用库存。
  • 销售预占库存:订单提交并分仓成功后,会预占对应仓库的库存,订单取消或发货后,会扣减预占库存。
  • 销售可用库存:销售可用库存=可用实物库存-销售预占库存。

销售层

销售层的定位是管理各个销售渠道的渠道库存,为销售平台提供库存计算与库存同步的服务,并通过各种渠道库存分配策略进行库存分配,防止超卖,保障利润最优。

销售库存的关键属性包括:

  • 销售渠道:包括自营的网店、门店线下渠道,天猫,京东,美团,饿了么等三方平台等。
  • 销售店铺:销售的店铺或门店。
  • 发货方式:快递、同城配送、自提。
  • 配送区域:由于各个仓库覆盖的配送区域不一样,所以SKU能支持的配送范围也不同。

销售库存的关键概念:

  • 销售可用库存:按照仓库/门店的供货关系、渠道库存分配策略进行计算汇总的可销售的库存数量。订单提交成功扣减销售可用库存,当调度层的实物库存更新,需要触发销售层重新计算销售可用库存。
  • 预售库存:如果商品未到货,可以开启预售模式,提前售卖。实物库存与预售库存是隔离开的,当实物到货后,预售库存统一推到实物库存进行履约。
  • 预占库存: 订单已提交但未支付之前,为给顾客预留商品,会先预占商品库存,待支付以后再删除预占库存、扣减可销售库存。若长时间未支付,则会取消订单,释放预占库存。
  • 活动库存:针对某些SKU做促销活动时,例如特价、秒杀活动,需要设置活动库存,可以从正常库存中预留部分库存,活动开始后释放预留库存。如果活动商品的下单数量等于活动计划的库存总数量,则活动终止。活动订单与普通订单,在库存处理逻辑上是一模一样的。如果没有特殊要求,没必要单独把活动库存单独分出来,作为独立的业务处理,这样会多出两套库存逻辑,三层库存架构需要都独立分开处理,极大地增加了复杂度。
  • 预留库存:若需要提前为某些促销活动预留库存,以免活动开始以后库存不足,可设置预留库存。
  • 可售库存 = 预售库存+销售可用库存 – 预占库存 - 预留库存。

销售渠道层

销售渠道层代表各个销售渠道平台,包括自营的网店、门店渠道,天猫,京东,美团,饿了么等三方平台等。

逻辑模型设计

image.png

库存的核心场景

调度层同步逻辑

调度层的实物库存来自各个仓库的库存,一般有两种同步模式:

  • 流水同步模式:适用于内部系统打通,能够获取仓库/门店的库存流水,通过回传流水,变更调度层的实物库存数量。这样做的好处是,有很清晰的实物库存流水变更记录,便于追查到每次库存变化的明细,需要注意做好幂等处理,避免重复同步导致库存数量变更出错。
  • 数量同步模式:适用于外部系统对接,一般获取不到详细的库存流水,通过商家后台或系统对接的方式同步库存实时数量。

image.png

销售库存计算逻辑

在新零售的多仓多渠道模式下,为了实现全渠道库存共享,库存汇总为“一盘货”管理,要充分考虑各个仓库/门店的特性,包括支持的发货方式,配送范围等,为了合理分配库存,需要考虑各个销售店铺的库存占比。下面针对几种常见的场景,说明销售库存的计算逻辑。

多仓供货场景

image.png

门店A、门店B为两个线下门店,门店A有100件iphone14,门店B有50件iphone14。

假设商家有1个天猫旗舰店,门店A、门店B均给天猫店供货。

天猫旗舰店仅支持快递发货方式,为了防止超卖,设置快递的最大分配比例为80%。

如图例所示,最终天猫渠道的iphone14的库存数量为120,并定期将数量同步到天猫平台。

单仓给多店供货场景

image.png

 

 

商家有1个电商仓,为商家的各个电商平台店铺提供仓储服务与发货服务,电商仓有100件iphone14。

电商仓同时为京东旗舰店、天猫旗舰店供货,两个店铺仅支持快递发货方式,最大分配比例分别为80%、60%。

如图例所示,最终京东渠道的iphone14的库存数量为80,天猫渠道的iphone14的库存数量为60。

门店全渠道库存共享场景

image.png

随着新零售线上线下渠道加速融合,门店线上线下全渠道销售,已经成为大部分零售商家的标配。

受益于微信生态和小程序电商的高速发展,越来越多的门店开启了云店模式,云店实际上就是门店的线上化交易渠道,或者称为门店的“线上货架”。

连锁企业把线下门店嫁接到微信生态中,将门店所有商品上架到云店小程序。借助云店,消费者无需到店,即可享受到门店的服务,同时,门店的导购可以向自己的会员推荐所有云店商品。

如图例所示,门店A有100份的草莓蛋糕,门店A为自己供货,并共享草莓蛋糕的库存到多个销售渠道(美团外卖、云店、门店线下渠道),实现门店“一盘货”全渠道销售。

渠道库存同步

销售库存计算完后,需要将渠道库存同步到各个平台渠道,这样,消费者才能完成交易流程。根据渠道类型不同,渠道库存同步有两种处理逻辑:

  • 自营系统:如果自营渠道与库存系统是一体的,即一套系统,那么不需要过于复杂的库存同步逻辑,自营渠道直接读取中央库存系统的渠道库存即可。
  • 三方平台系统:像天猫,京东,美团,饿了么等,这些三方平台系统属于外部系统,商家自身无法管控,就需要通过开发API,向三方平台同步渠道库存。一般而言不会实时同步渠道库存,即只要有库存变动,就计算渠道库存,同步至三方平台。这种方式对系统压力较大,而且三方平台的API大多会按调用量收费,因此,会设定好时间间隔,定期同步渠道库存,例如5分钟一次。

组合商品库存计算

image.png

组合商品一般指人为将几个单独售卖的商品组合在一起,进行合并售卖的商品,例如:下午茶套餐、七夕美妆组合等。

组合商品会先在调度层,根据组合比例计算好虚拟库存,不影响子商品的供货逻辑,下单时,会根据组合商品标识,进行子商品的实物库存预占、扣减。

如图所示,电商仓中,商品A有150件,商品B有200件,根据组合关系,可以算出组合商品C有100件。当下一单商品C时,会预占1件商品A+2件商品B的实物库存。

中央库存系统的应用架构设计

image.png

小结

本文介绍了在全渠道模式下,库存管理面临的挑战。针对挑战,详细介绍了中央库存系统的整体业务框架,涉及的关键概念,以及库存核心业务场景的处理逻辑,最后简单介绍了中央库存系统的应用架构设计。期望对读者有所帮助,也欢迎随时沟通或者关注公众号“汤师爷说”。

相关文章
|
3月前
|
Ubuntu Linux
查看Linux系统架构的命令,查看linux系统是哪种架构:AMD、ARM、x86、x86_64、pcc 或 查看Ubuntu的版本号
查看Linux系统架构的命令,查看linux系统是哪种架构:AMD、ARM、x86、x86_64、pcc 或 查看Ubuntu的版本号
854 3
|
5月前
|
存储 边缘计算 Cloud Native
“论模型驱动架构设计方法及其应用”写作框架,软考高级,系统架构设计师
模型驱动架构设计是一种用于应用系统开发的软件设计方法,以模型构造、模型转换和精化为核心,提供了一套软件设计的指导规范。在模型驱动架构环境下,通过创建出机器可读和高度抽象的模型实现对不同问题域的描述,这些模型独立于实现技术,以标准化的方式储存,利用模型转换策略来驱动包括分析、设计和实现等在内的整个软件开发过程。
331 3
|
2月前
|
存储 监控 安全
SaaS业务架构:业务能力分析
【9月更文挑战第20天】在数字化时代,软件即服务(SaaS)模式逐渐成为企业软件解决方案的首选。SaaS 业务架构设计对于提供高效、可靠的服务至关重要。其核心业务能力包括:用户管理(注册登录、角色权限)、数据管理(存储备份、安全共享)、业务流程管理(设计定制、工作流自动化)、应用集成(第三方应用、移动应用)及客户服务(支持培训、反馈改进)。通过优化这些能力,可为企业提供更高效、可靠的 SaaS 服务。
57 11
|
30天前
|
存储 前端开发 数据库
一文搞懂SaaS应用架构:应用服务、应用结构、应用交互设计
【10月更文挑战第21天】本文介绍了 SaaS 应用服务的多租户服务、安全服务和更新与维护服务,以及 SaaS 应用的前后端结构和交互设计。多租户服务涉及数据隔离和资源分配;安全服务包括身份认证与授权及数据安全;更新与维护服务涵盖版本管理和技术支持。前端结构关注用户界面设计和前端技术选型;后端结构则涉及微服务架构和数据库管理。交互设计强调租户与应用的交互和应用内部模块间的交互。
129 0
|
2月前
|
监控 Android开发 iOS开发
深入探索安卓与iOS的系统架构差异:理解两大移动平台的技术根基在移动技术日新月异的今天,安卓和iOS作为市场上最为流行的两个操作系统,各自拥有独特的技术特性和庞大的用户基础。本文将深入探讨这两个平台的系统架构差异,揭示它们如何支撑起各自的生态系统,并影响着全球数亿用户的使用体验。
本文通过对比分析安卓和iOS的系统架构,揭示了这两个平台在设计理念、安全性、用户体验和技术生态上的根本区别。不同于常规的技术综述,本文以深入浅出的方式,带领读者理解这些差异是如何影响应用开发、用户选择和市场趋势的。通过梳理历史脉络和未来展望,本文旨在为开发者、用户以及行业分析师提供有价值的见解,帮助大家更好地把握移动技术发展的脉络。
92 6
|
5月前
|
存储 消息中间件 API
“论微服务架构及其应用”写作框架,软考高级,系统架构设计师
论微服务架构及其应用近年来,随着互联网行业的迅猛发展,公司或组织业务的不断扩张,需求的快速变化以及用户量的不断增加,传统的单块(Monolithic)软件架构面临着越来越多的挑战,已逐渐无法适应互联网时代对软件的要求。在这一背景下,微服务架构模式(MicroserviceArchitecturePattern)逐渐流行,它强调将单一业务功能开发成微服务的形式,每个微服务运行在一个进程中;采用HTTP等通用协议和轻量级API实现微服务之间的协作与通信。这些微服务可以使用不同的开发语言以及不同数据存储技术,能够通过自动化部署工具独立发布,并保持最低限制的集中式管理。
343 4
|
4月前
|
存储 搜索推荐 API
业务系统架构实践问题之单系统内架构形态中,起步时的domain设计问题如何解决
业务系统架构实践问题之单系统内架构形态中,起步时的domain设计问题如何解决
|
4月前
|
存储 搜索推荐 API
业务系统架构实践问题之分层架构中的四层定位是什么
业务系统架构实践问题之分层架构中的四层定位是什么
121 0
|
5月前
|
边缘计算 Cloud Native IDE
“论SOA在企业集成架构设计中的应用”写作框架,系统架构设计师
企业应用集成(Enterprise Application Integration, EAI)是每个企业都必须要面对的实际问题。面向服务的企业应用集成是一种基于面向服务体系结构(Service-OrientedArchitecture,SOA)的新型企业应用集成技术,强调将企业和组织内部的资源和业务功能暴露为服务,实现资源共享和系统之间的互操作性,并支持快速地将新的应用以服务的形式加入到已有的集成环境中,增强企业IT环境的灵活性。
117 0
|
5月前
|
运维 监控 Cloud Native
“论云原生架构及其应用”写作框架,系统架构设计师
近年来,随着数字化转型不断深入,科技创新与业务发展不断融合,各行各业正在从大工业时代的固化范式进化成面向创新型组织与灵活型业务的崭新模式。在这一背景下,以容器和微服务架构为代表的云原生技术作为云计算服务的新模式,已经逐渐成为企业持续发展的主流选择。云原生架构是基于云原生技术的一组架构原则和设计模式的集合,旨在将云应用中的非业务代码部分进行最大化剥离,从而让云设施接管应用中原有的大量非功能特性(如弹性、韧性、安全、可观测性、灰度等),使业务不再有非功能性业务中断困扰的同时,具备轻量、敏捷、高度自动化的特点。云原生架构有利于各组织在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用
441 0

热门文章

最新文章