严选库存中心设计实践

简介: 严选库存中心设计实践


严选技术产品团队

网易严选技术产品团队致力于分享电商业态下的技术干货。这里是网易严选技术产品团队的官方对外窗口,不定期推送技术文章、团队活动、招聘信息等内容。

69篇原创内容

公众号

严选作为一家自营品牌电商,核心竞争力之一是对供应链的把控能力。在这其中,对库存的管理更是重中之重。如何降低库转、降低缺货率,是业务同学和分析师们几年来持续研究的课题。而这些课题,都建立在库存数据管理的基础之上。本文就将介绍严选库存中心进行库存数据管理的设计实践。

1. 电商库存管理基本方法

电商业发展至今,已经迈过野蛮生长进入精耕细作的阶段;而电商企业的信息化之路,也日臻成熟和完善:从最开始粗放管理的进销存、到五脏俱全的ERP、再到后续逐渐细分的库存管理系统、订单管理系统等等,一些电商业务的基础支撑产品已经形成了比较成熟的套路和方法,库存管理系统也不例外。

1.1 电商库存管理解决的核心问题

随着几年前新零售概念的兴起,越来越多的电商公司开始拓展线下业务、也有越来越多的传统零售企业开始发力电商;而线上业务面临着流量分散、顾客时效要求越来越高等挑战。这就导致诸多企业纷纷采取:线上线下一体、多渠道售卖、多仓布货的运营策略。相应的,好的库存管理系统也需要能够解决如下问题以适应这种趋势:

满足仓库运营管理诉求

仓库是存放商品的基础设施,它的入库、出库、盘点等各种作业都能够最直接地影响到实际商品数量,好的库存管理系统需要能够实时记录这些操作对库存的影响。并且根据库内管理精细化程度的不同,除了最基础的skuid+数量之外,还可能需要在库位、效期、批次等等更细的维度关注库存信息。

为订单履约提供决策依据

多仓布货场景下,用户订单从哪个仓发货对于时效、成本都有着决定性影响。而哪些仓可以发货、哪些仓不可以发货,最基本的条件之一就是库存是否满足。因此好的库存管理系统需要能够提供仓库+skuid+数量维度的数据,作为订单履约的决策依据。

灵活支持营销端的复杂售卖模式

好的库存管理系统除了需要支撑供应端的运作之外,还需要能够支持营销端的售卖策略:是单渠道售卖还是多渠道售卖;全国售卖还是部分地区售卖;普通售卖还是活动售卖;线上售卖还是线下售卖等等……需要在“最大化销售、同时不造成超卖”的前提下满足营销端的各种复杂售卖模式。

1.2 电商库存分层体系

根据电商库存管理需要解决的核心问题,可以发现:从最底层的仓库管理、到中间的订单履约、以及前端的销售,不同业务场景对于库存管理有着清晰明确却不尽相同的诉求,它们关注的库存数据维度也各有千秋。如果仅仅用一套数据来管理不同业务场景下的库存,势必会带来可扩展性和兼容性上的问题。而这就引出电商库存管理一个很普遍的设计思路:库存分层设计体系

仓库层库存

仓库层库存,顾名思义主要是用于管理各仓库存数据的。这部分库存数据一般存在于WMS系统、或者门店管理系统中。它是最一线的生产系统的数据,最能够反映仓内、店内商品实物数量情况,因此在很多公司也被称为“实物层库存”(为避免混淆,本文的名词定义皆以严选库存中心为准;但是也会适当介绍同行的情况)。根据业务场景需要,仓库存库存可能会有货主、库位、批次等多个细分维度。仓内/店内的任何操作,包括拣货、出库、上架、盘点等等都会对仓库层库存产生影响。

实物层库存

目前很多电商卖家都是多仓发货,而各仓仓库层的库存是相互独立的,因此通常会需要有一个“调度库存”的概念来对各仓库存进行统筹管理。从“调度库存”这个名字可以想见,用户下单之后如何调度订单、如何选择从哪个仓发货等⼀系列策略,都要依赖于它。由于它是连接销售端和仓库端的枢纽、是对仓库实际货物数据的汇总,因此有时也会称调度库存为“中台库存”或“实物层库存”(注:严选库存中心就采取了“实物层库存”的称呼)。由于实物层库存关注订单履约而非库内生产,因此它虽然来源于仓库库存,但无需像仓库层库存一样管理到库位等维度,只需根据实际业务情况进行单仓(仓库+sku+数量)、区域(区域+sku+数量)、总库存(sku+数量)等维度的管理。

销售层库存

销售层库存是面向用户、决定用户购买行为是否能够成功的库存数据,对于实体商品,它来源于实物层库存,但又不完全等同于实物层库存

想象这样一种场景:某商品在仓库A和仓库B分别有2件可售卖,总共4件。用户甲下单购买了1件,此时其他用户最多只能购买3件:也即销售层可售卖库存数应为3;而从实物库存角度来看,由于用户甲的订单还未分配到仓库进行生产,因此实物层库存数依然为4.

由于主要面向销售,所以销售层库存一般不再关注仓库信息,会根据业务需求管理到区域+sku+数量维度、或者sku+数量维度。同时根据售卖形式的不同,销售层库存还可能会分为活动库存、渠道库存等维度。

2. 严选库存中心设计实践

“分层设计”是电商库存管理的一个基本思想,在这个基本思想指引下,不同的电商公司也会根据实际情况对各层做不同的设计来适配自身的业务模式。

2.1 严选电商业务特点

区别于淘宝的平台模式、京东的区域仓模式,严选的电商业务有着自身的一些独有特点:

线上线下多渠道+多场景售卖

严选电商业务的特点之一是线上线下多渠道+多场景售卖:我们有独立研发的网易严选APP、网易严选企业购作为主要的流量入口,同时我们也在淘宝、天猫、京东等多个平台开设了官方旗舰店,国内的很多城市还开设有严选线下店。这些售卖渠道基本无差别地售卖着严选的大多数商品,一般情况下库存也是由这些渠道共享。除此以外,网易严选APP上有十余种活动形式,每种活动形式又有着自身特有的库存使用诉求。

多仓布货+一仓发全国

严选电商业务的另一特点是多仓布货、但不划分区域仓。虽然我们在华北、华南、华东、西南地区均有仓库,但这些仓库的发货范围不限:也即在不考虑其他限制条件的影响下,任一仓的商品均可发往全国各地的用户。这就决定了在实物层、销售层,我们没有区域库存的概念,所有仓库的库存均由全国用户共享。

仓储服务外包

在严选现有业务情况下,我们采取了最合适当下的仓储服务外包模式,并未自建仓、也暂未搭建自有的WMS系统:引入顺丰、京东等第三方仓储服务商管理我们的仓库,库内作业也采用这些仓储服务商自研的WMS系统。而这也就意味着我们拿不到最直接的仓库库存数据。

2.2 严选库存分层设计

基于前述严选电商业务的特点,严选库存中心的分层设计思路如下:

重点关注销售层和实物层库存

由于没有自研的WMS,因此仓库层库存数据不在我们的管辖范围内。但是前端销售、中间环节的订单履约均由严选自行掌控,因此严选库存中心分为销售层库存、实物层库存进行设计。

销售层、实物层一轻一重

如前所述,严选采取一仓发全国业务的策略,因此无需像京东的区域仓模式一样管理sku+区域维度的销售库存,我们的销售库存只需管理到sku维度即可。

而考虑到无法直接拿到仓库层库存,而严选内部诸多业务场景均依赖效期、库龄、批次等数据,因此严选库存中心的实物层库存比一般电商公司的实物层库存做得更重:我们除了管理sku+仓库/全网维度的实物库存用于订单调度等场景,还拓展了物理位置(在库、在途)、批次等维度的实物层库存。其中批次是由采购入库单号、生产日期、失效日期唯一决定的属性值,根据批次库存我们可以计算效期、库龄等信息,可以对库存做更精细化的管理。

销售层库存建立在实物层库存的基础之上,它们通过库存公式相连接,确保了仓内实物数量发生变更时、营销端的销售层库存也相应变更。

2.3 严选锁定库存设计

大的方向上严选库存中心采取了业界通用的分层设计思想,并在细节上结合自身业务特性做了一些取舍。除此以外,它还有一个较为独到的设计之处:灵活运用锁定库存逻辑支撑各种复杂的业务场景

业务背景

五花八门的促销活动是电商运营的重要组成部分,而这些促销活动比如秒杀、限时购、定金购等都对于参与活动的商品库存数量有着特殊要求:为保证活动效果需要一定的库存量保障;为避免过度拉低毛利控制活动成本,活动可购买库存量又不可能设为无限大。因此,一些库存管理系统采取的方法是单独开辟一份“活动库存”数据来进行库存管理:增加单独的活动表管理活动库存、活动冻结库存。

而在严选实际业务场景中,同一时间可能存在很多个促销活动,且促销活动以外,还会有很多其他场景对库存有特殊诉求:

  • 某些第三方平台比如天猫具有自身的管理规则(尤其是双十一等大促期间),严选在该渠道进行销售时需确保相对充足的库存数量
  • 部分渠道单独备货,这部分库存无法与其他销售渠道共享
  • 部分未完全线上化的to b业务需要在达成合同意向之后、订单下发之前预留库存以确保后续能够正常履约
  • 一些特殊的非线上销售业务场景(比如线下店补货、京东自营业务补货等),需从特定仓库预留库存并发货以减少运输成本

锁定库存设计

通过前述业务背景介绍可以发现,促销活动只是对库存有特殊诉求的场景之一,除此之外还有很多其他业务场景也都有着预留一定数量库存用于特定用途的诉求。

基于此,严选库存中心引入锁定库存池概念:

将原始的共享库存认为是一个大的池子,这里存储着所有库存。而在共享库存池之内,可以开辟很多个相互独立的锁定库存池:也即锁定库存池是总库存池的子集。

同时我们规定每个锁定库存池均有一个唯一的“秘钥”:也即锁定键,又称lockkey.

库存使用方根据需要,带上lockkey+skuid+数量来库存中心申请一个锁定库存池,申请成功之后,使用方只需带上lockkey来请求库存中心即可使用该锁定库存池的库存。比如,严选主站做活动时,可以根据活动具体情况生成lockkey,并用lockkey+活动sku+活动所需库存数量来请求库存中心划拨锁定库存池,该锁定库存池中的库存即专款专用于该活动,一旦有活动订单产生,在带上lockkey+活动sku以及相关订单信息请求库存中心即可扣减相应的锁定库存。

可以看到,不管营销端有多少个不同类型的活动,我们都能够快速地将活动库存管理起来。与此同时,这种方式也能够很方便地支撑促销活动之外其他对库存有特殊需求的业务场景。

在严选业务迅猛发展的过程中,这样灵活简洁的设计无疑有助于我们快速攻城略地。当然它也存在:库存中心对锁定库存池管控较弱、lockkey规范难以统一、关联系统对库存理解成本较高等不足,而这就是严选库存中心接下来要重点解决的问题之一了。

结尾

电商库存管理的核心在于要对库存数据进行分层设计:根据实际业务需要针对仓库层库存、实物层库存、销售层库存分别进行不同颗粒度的管理。但在基础库存数据模型建立起来以后,能对业务带来更多价值的,还是在于怎样进行供应链管理:如何用最小的成本(低库转)以最快的速度(库存在各仓的分布合理,不缺货)将用户需要的商品送到他手上。而这就是如何做采购计划和采购执行、如何做仓与仓之间的库存平衡等更为复杂的课题了。


相关文章
|
定位技术
阿里研究员玄难:如何做电商业务中台
2016 ATF阿里技术论坛于4月15日在清华大学举办,主旨是阐述阿里对世界创新做出的贡献。会上阿里业务平台事业部&淘宝基础平台技术部负责人玄难阐释了淘宝经历13年的发展中,业务平台从零到有,同时又逐步演进为业务中台。
41949 0
|
10月前
|
存储 供应链 前端开发
如何开发仓库管理系统中的库存管理板块 ?(附架构图+流程图+代码参考)
本文介绍仓库管理系统(WMS)中库存管理模块的开发,涵盖系统简介、库存管理功能设计、业务流程分析、开发技巧与代码示例,以及实现效果和常见问题解答,帮助企业实现高效、精准的库存管理。
|
10月前
|
数据采集 SQL 搜索推荐
大数据之路:阿里巴巴大数据实践——OneData数据中台体系
OneData是阿里巴巴内部实现数据整合与管理的方法体系与工具,旨在解决指标混乱、数据孤岛等问题。通过规范定义、模型设计与工具平台三层架构,实现数据标准化与高效开发,提升数据质量与应用效率。
3246 0
大数据之路:阿里巴巴大数据实践——OneData数据中台体系
|
9月前
|
Java 测试技术 编译器
@GrpcService使用注解在 Spring Boot 中开始使用 gRPC
本文介绍了如何在Spring Boot应用中集成gRPC框架,使用`@GrpcService`注解实现高效、可扩展的服务间通信。内容涵盖gRPC与Protocol Buffers的原理、环境配置、服务定义与实现、测试方法等,帮助开发者快速构建高性能的微服务系统。
1742 0
|
机器学习/深度学习 自然语言处理 算法
人类偏好对齐训练技术解析
大型语言模型(LLMs)通过在大量文本数据集上进行无监督预训练,获得丰富的语言模式和知识,这一阶段训练后的模型被称为base model。
|
JSON 算法 API
1688拍立淘图片搜索接口全攻略
1688拍立淘图片搜索接口由阿里巴巴提供,支持通过上传图片在1688平台搜索相似商品。该接口基于图像识别技术,具备高精度匹配、丰富商品信息返回、支持多图片格式及可定制化搜索等特点,适用于电商选品、商品溯源和智能购物等场景。开发者需注册获取app_key与app_secret,并通过Python示例代码调用接口,实现图片搜索功能。
799 23
|
消息中间件 缓存 运维
|
供应链 NoSQL Redis
库存预占架构升级方案设计 - 交易库存中心
伴随物流行业的迅猛发展,一体化供应链模式的落地,对系统吞吐、系统稳定发出巨大挑战,库存作为供应链的重中之重表现更为明显。近三年数据可以看出:
592 0
|
Prometheus Cloud Native Linux
Prometheus+Grafana新手友好教程:从零开始搭建轻松掌握强大的警报系统
本文介绍了使用 Prometheus 和 Grafana 实现邮件报警的方案,包括三种主要方法:1) 使用 Prometheus 的 Alertmanager 组件;2) 使用 Grafana 的内置告警通知功能;3) 使用第三方告警组件如 OneAlert。同时,详细描述了环境准备、Grafana 安装配置及预警设置的步骤,确保用户能够成功搭建并测试邮件报警功能。通过这些配置,用户可以在系统或应用出现异常时及时收到邮件通知,保障系统的稳定运行。
2490 1
|
存储 消息中间件 JSON
DDD基础教程:一文带你读懂DDD分层架构
DDD基础教程:一文带你读懂DDD分层架构