电子商务管理全面解读和认知电商系统：库存管理

发布时间 : 2024-11-24

作者 : 小编

访问数量 : 23

扫码分享至微信

全面解读和认知电商系统：库存管理

编辑导语：随着时代的发展，电商也随着时间的推移而不断发展壮大，本篇文章作者从四个部分来讲解电商系统中的库存管理，干货满满，一起来学习一下。

本文主要从四个部分来讲解电商系统中的库存管理，一起来文中看看。

一、库存的概念

库存，狭义上来讲是仓库中实际储存的货物。

除了服务提供商和服务信息提供商外，基本上各家电子商务公司都会面临实物库存管理的需求。

库存管理是完成前台商品售卖交易闭环的重要组成部分，库存管理与仓库密不可分，而仓库又与销售、采购有关系。

如图1-1所示，库存变动的影响因素主要包括销售订单、售后退货、商品预售、盘赢盘亏、仓库调拨、采购入库等。

图1-1 库存变动的影响因素

1. 库存分层：销售层、调度层、仓库层

根据职能不同，驱动库存发生变化的单据不同，可以将电商库存管理体系分为三层：销售层、调度层、仓库层，如图1-2所示。

图1-2 库存分层

下面，逐一讲下各层需要重点注意的内容。

1）销售层

这一层主要面向的是前台用户，一般需要使前端库存与实际库存保持一致，也就是不能超卖。

在做预售的时候，使用的是虚拟库存，此时的下单只牵扯到销售层的库存，等待商品备货后，才会推到调度层。

销售层的库存决定了是否可以售卖，下单是否可以成功。

秒杀活动时决定是否可以秒杀成功，预售活动时决定是否可以下定金预售。

可销售库存： 指的是客户端前台显示的库存数，用户根据这一指标进行下单购买，当可销售库存大于0时，显示可销售，当可销售库存等于0时，显示商品已售罄。锁定库存： 一般存在于客户提交订单后，为客户锁定一个库存位置，当客户超过规定时间没有付款时，取消库存锁定，可销售库存加一；当客户付款成功后扣减库存，锁定库存取消，已销售库存加一，目的是为了保证客户下单后可以正常发货。已销售库存： 指的是商品已经销售的数量，当客户支付成功后，已销售库存增加，当客户取消订单或申请售后时，库存变动流程做出相应变化。活动库存： 主要出现在促销活动中，如秒杀等，此时的活动库存为独立库存，从总库存中拨一部分做为活动库存，这部分库存也是走相应的锁定、扣减逻辑。预售库存： 这部分库存为虚拟库存，一般出现在双十一等需要拉动需求的的活动中，虽然也是走正常的锁定、扣减逻辑，但是此时的库存仅停留在销售层，只有订单需要备货之后才会走到调度层。

2）调度层

调度层可以理解为订单的分配中心，决定了哪些商品由哪些仓库发货。

账面库存： 指的是仓库中的实际库存，只要是未出库的都算在账面库存内。可用库存： 可以发货的库存，也就是可供调度的库存。在途库存： 发起了采购单，但是还没有到达仓库的库存，一般许多企业会将三天内的在途库存算在可用库存内。不可销售库存： 指的是损坏，质量有误的库存，通常退货入库的商品首先会经历一道审核，验证质量没有问题后才会上架，当有损坏时，算在不可销售库存内，会另作处理。已用库存： 指的是已经经历了调度分配的库存。

3）仓库层

仓库层对应的是实物库存，入库、出库、盘点等都会带来库存变动。

可用库存： 当发货单流转至库存时，可以进行正常发货的库存，不包括锁定库存。锁定库存： 当调度层分配仓库后，发货单流转至库存时，仓库需要锁定库存库位，以便进行后续的打单、分拣，已出库库存： 已经包装完成了，交接给对应的物流公司进行发货，确认出库的库存。不可用库存： 盘点时发现的质量有问题的库存，经报损后需要从可用库存变为不可用库存。

2. 库存同步

由于触发库存变动的点不一样，库存的变动分为两个流向。

其一是自上而下，也就是从销售层到调度层，再到仓库层。

其二是自下而上，从仓库层到调度层，再到销售层。

自上而下： 客户在前台下单，生成订单，相应的销售层库存扣减；然后流转至调度层，调度层分配调度仓库后，生成发货通知单，调度层库存变化；最后流转至仓库层，WMS系统同步响应，库存数据发生相应变化。自下而上： 当库存实物增加时发生，通常出现在采购入库、退货入库、调拨入库时，当实际库存增加时，仓库层库存变化，通过调度层将数据同步给前台显示的销售层，连锁引起仓库层、调度层、销售层的可用库存逐步增加。

二、销售库存管理

一般情况下，销售层的库存要和调度层的库存保持一致，但是在特殊情况下，如允许超卖时、做预售时、不同活动独占库存时，就会出现预售层库存和调度层库存不一致的情况。

而销售总库存也会存在和现货库存数量不一致的情况，这种情况主要出现在允许超卖时，销售总库存可以和现货库存脱离不同步。

可销售库存、锁定库存与销售总库存的关系公式如下所示：

可销售库存 = 销售总库存－ 锁定库存

用户前台看到的显示库存数、下单时判断是否有货的库存数都是可销售库存数，只有可销售库存数大于购买总数时才能下单成功。

下面我们来看下单时库存的扣减和返还逻辑，如图2-1所示，以下单选择商品A，数量2件为例。

图2-1 下单时库存动作

三、库存调度逻辑

在许多电商企业或大公司，库存结构比较复杂，拥有多个仓库，仓库类型包括主仓、区域仓、供应商协同仓等，如图3-1所示。

在调度发货仓时也要考虑许多因素，包括成本、物流、商业等等，仓库调度实际也是在各种规则限制下对仓库进行调度。

图3-1 仓库组成结构

1. 库存调度影响因素

在调度仓库时，需要考虑的因素以下几点。

1）物流时效

为了迅速响应用户的需求，很多企业会在多地建立货仓，以便能从最近的区域发货，在最短的时间送到用户手上。

如生鲜业务类的企业对于仓库的需求就很大，根据公司业务规模在多地建立仓库，如在北京、上海、广州、武汉、沈阳、西安、成都等地各有一个仓库，当长春的用户下单时，会优先判断最近的沈阳仓是否有货，没有货则会选择北京仓发货。

2）仓库等级

有些企业在业务量较大时，会在同一区域内除了建立中心仓，还会建立多个区域仓。

例如华东区包括上海、浙江、江苏，其中心仓在上海，在杭州、宁波、苏州、南京等订单量较大的城市建立区域仓。

这些区域仓库存量较小，存放一些消费频次高的商品，只供应当地城市，在区域仓没货的时候，才会从中心仓发货。

另外在仓库多了以后，在前端商品判断有没有货及物流时效时，如果按照优先级顺序一遍遍去遍历判断，会影响效率，按照区域仓库进行调度，能最大程度优化判断。

3）业务需要

在业务发展时，会有部分货源从供应商直接发出，或者为了保证物流时效，在某些区域由供应商直发，这种仓库定义为供应商协同仓，再对这些商品进行调度时，就需要由调度层直接下发给供货商系统。

2. 库存调度规则

仓库类型越少，库存结构越简单，在库存调度的时候逻辑就越简单。

当然产品要跟着业务走，调度逻辑随着业务复杂度、销售渠道、仓库数量等因素的变化而增加难度。

特别是很多有线下零售店及仓库的商家，要将线下各个零售店当成区域仓来调度，这个情况的复杂度还要增加，图3-2为库存调度逻辑。

图3-2 仓库调度逻辑

四、库存控制策略

要做好库存控制，首先要思考以下几个问题。

如何优化库存成本？怎样避免浪费，避免不必要的库存？怎样避免缺货损失和利润损失？

而要解决这些问题，主要把注意力集中在以下三点。

1. 需求预测

需求有五个方面的因素需要考虑，也就是数量、时间、频率、范围以及可预测性。

数量可以是精确的数字，也可以是一个范围。时间指的是时间跨度，包括短期预测、中期预测和长期预测，短期预测的时间跨度一般在3个月-1年之间，中期预测的时间跨度通常为2年，长期预测的时间跨度通常为2年及2年以上。频率为特定时间内满足需求的次数。范围也就是数量的变化范围。可预测性包括稳定性需求、趋势需求、季节需求、周期性变化需求、随机需求以及自相关需求等。

2. 安全库存

安全库存是为了防止不确定性而准备的库存，安全库存可以预防预测与实际消耗之间的差异，以及期望运输时间与实际之间的差异所造成的损失，在补充周转库存时预防缺货。

在低于安全库存时进行预警，开始补货动作。

图4-1和图4-2为有赞的安全库存设定类型，包括固定预警值和动态预警值。

1）固定预警值

当商品实时库存 < 库存下限，系统会将其标记为低库存，当商品实时库存 > 库存上限，系统会将其标记为高库存。

图4-1 有赞固定预警值

2）动态预警值

例：商品要从省外运输过来，进货周期很长，需要7天时间，那么就需要留有大约10天以上的存货来确保正常销售。

再或者部分加工商品保质期较短，不适合囤货否则会导致库存滞压，带来损失。

图4-2 有赞动态预警值

3. 库存控制模型

库存控制要解决的问题有如下三点：

多长时间检查一次库存量（订货间隔期问题）？何时提出补充订货（订货点的问题）？每次订货是多少（订货批量问题）？

在库存控制系统中不可控的因素是： 需求、订货、提前期。

可控的因素是： 一次订多少（订货量）、何时提出订货（订货点）。库存控制的目标是：服务水平最高、总费用最低。

下面介绍两种基本的库存模型，即定量订货模型和定期订货模型。

1）定期订货模型

定期订货模型按照预先确定的时间间隔，周期性地检查库存，随后发出订货，将库存补充到目标水平。

如图4-2所示，Q是各次的订货量，库存检查周期仍为订货提前期。

定期订货没有订货点，每次按预定的周期检查库存，依据目标库存和现有库存的情况，计算出需要补充的库存量，然后按照订货提前期发出订货，使库存达到目标水平。

图4-2 定期订货控制模型

2）定量订货模型

电商一般采用的是定量订货模型。如图4-3所示，Q是每次的订货量，L为订货提前期，R为订货点。

定量订货预先设定一个再订货点（如图中的R），在管理中连续不断地监控库存水平，当库存水平降低到订货点时就发出订货，每次按相同的订货批量Q补充订货。

图4-3 定量订货控制模型

定量订货模型与定期订货模型的基本区别是： 定量订货模型是“事件驱动”，而定期订货模型是“时间驱动”。

定量订货模型在达到规定的再订货水平后，就进行订货，主要取决于对物资的需求情况，订货时间可能随时发生。定期订货模型只限于在预定时期期末进行订货，是由时间驱动。

本文由 @向阳而生原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自unsplash，基于CC0协议。

电商信息化：浅谈OMS订单管理系统

编辑导语：随着业务模式的成熟，业务所需要的支撑系统也需要不断改进。在电商管理中，会用到OMS，而随着新零售的发展，OMS需要进行升级的地方也有很多。作者总结了个人对于OMS的一些认识，与大家分享。

一、前言

随着业务模式的成熟，支撑业务的信息系统也逐渐成熟，人力资源、OA、ERP、OMS、WMS等等各个领域的软件也都有了商业产品的佼佼者，今天，笔者把个人对OMS的一点点认识与大家一起分享，欢迎大家交换不同看法！

二、什么是OMS订单管理系统

1. 释义

“接受客户订单信息，以及仓储管理系统发来的库存信息，然后按客户和紧要程度给订单归类，对不同仓储地点的库存进行配置，并确定交付日期，这样的一个系统称为订单管理系统。”

这是来自于百度词条“OMS”的描述，更多解释见百度OMS词条。

简单来说，就是商家用来管理订单，通过OMS系统对订单以及订单信息所关联的信息进行处理，从而实现库存管理、订单履约以及其他业务需求的信息系统。

2. 解决了哪些问题？

如果看上面的概述很难理解什么是OMS订单管理系统的话，那我们就从实际的电商业务角度出发来理解一下吧！

作为普通消费者，我们在电商平台的购物流程基本上是：平台挑选商品——下单支付——等待发货——查看快递——收货取货

但是这个链路中，商家从商品采购到订单处理再到仓库发货、快递运输/派送的流程是不被我们感知的，商家要想让我们购买的商品能够顺利地到达我们手中，需要做大量的工作，在这大量的工作中，就要依靠OMS订单管理系统解决商品的管理、订单从平台的获取、发货仓库的分配、发货快递的选择、平台库存的同步等等一系列复杂的工作。

例如：

商家在多个平台的店铺中上架了上百个商品，那么各个店铺中商品的库存就需要与商家仓库中的库存保持实时同步，这样才能避免卖超，并且，不仅仅是库存同步，为了避免在各个平台都不超卖，库存在各个平台的分配也需要OMS来解决。

还有收货地址的变更、订单需要拆分从多个仓库发货的处理、发货快递信息的回传等等。

三、OMS的功能模块以及与其他系统的关系

1. OMS订单管理系统的功能架构

OMS的功能架构是从订单信息流的变化中抽象出来的，怎么理解“信息流的变化”呢？

这里从“信息流”和“变化”两个维度来理解：

例如，平台上的订单从平台通过API接口进入OMS，如果这个订单不需要任何修改，那么这个过程就只是一个信息的转移，虽然只是一个信息的转移，但是对于系统来讲，仍然需要配置店铺的基础信息、商品的基础信息、仓库/快递信息等来识别这个订单是来源于哪个平台，购买的是哪个商品，需要用哪个快递去配送。

另外，订单信息流中的商品信息、库存信息、仓库信息、快递信息都需要对应的功能模块来实现配置；

但是随着业务不断的复杂化，订单的信息在转移的过程中，发生了变化，例如：

商家客服答应了买家赠送赠品，原始订单信息中并没有；买家购买了两笔收件信息一致的订单，要求合并发货；……

这些场景在实际的业务中不胜枚举，OMS产品在发展过程中，为了系统性地解决在订单信息进行流转并发生变化的需求，形成了功能模块化的架构，通过近几年电商业务模式的成熟和OMS产品的发展，OMS中的功能模块也逐渐固化下来，成为了建设一个OMS系统所必需的标准功能模块。

功能模块拆解见下一小节脑图。

2. OMS订单管理系统与其他系统的关系

仅仅有一个OMS系统是不足以完成整个订单履约流程的，也不足以支撑企业的其他业务。

例如和OMS最密切的WMS系统就是订单发货的关键系统，承载着库存管理、出入库单的执行等任务；

还有需要和OMS协同进行订单对账的财务管理系统、用以分析销售情况的数据分析系统等等，都和OMS涉及到的信息流密切相关。

四、结语：上下延伸，理解变化

在传统的电商时代，OMS只需要能够对接平台处理订单就可以了，进入新零售时代，销售的渠道越来越多，订单履约的方式也越来越多，有布局分仓的，有工厂代发的，有直播带货的，还有门店自提的。

商业模式的变化，给OMS提出了更多的要求，也带来了更多的挑战，以往的功能模块可能无法再支撑新的业务了，新设计的业务好像又与原有的功能模块有太高的耦合性，产品人被困在了系统里……

作为供应链信息化中至关重要的一个环节，OMS承载着订单信息流能否顺利流转的重任，区别于WMS的功能专业性更强一些，OMS的功能更接近商业模式，所以很多种情况下大家把OMS称为订单中台，这也彰显了在企业业务中OMS的重要性。

笔者想要表达的是，B端从业者，无论是做平台产品，还是商业产品，或者是企业信息化支撑，我们都要拥抱上下游的业务，把知识面向订单的上下游延伸，这样有助于我们更好地理解商业，更好地服务产品。

然后，更有助于向供应链全链路的产品方向发展，做一个供应链方向的复合型产品人，像全栈工程师一样做一个供应链的全栈产品，我想，这应该是大多数B端产品从业者相同的努力目标吧！

最后，感谢阅读，希望这篇文章能够对大家有所帮助，如此，便是我的快乐！

本文由 @橙子哥哥原创发布于人人都是产品经理，未经许可，禁止转载

题图来自Unsplash，基于CC0协议