电商o2o分析：解构电商O2O探秘电商财产的迁移
电商o2o分析：解构电商O2O探秘电商财产的迁移履约的环节主要是对用户订单进行仓配作业，具体的仓配作业流程在之前的章节已经讲解过这里就不做累述了。履约的环节其实主要是仓库的库存进行分拣、出库的操作以及物流配送环节完成履约配送。除了常规操作外仓配操作还会产生两种作业会引起库存的变化：一个是用户退货、一个是换转退。占用的核心关注点就是尽量避免库存被占用过度导致其他用户无法购买营销销量和体验，而购物车环节占用会出现这样的问题，所以电商平台设计占用时都会放在订单生成环节。流程如图：库存的处理流程主要是将销售、履约、采购三部分的所有操作行为进行合理的串联，从而实现不同类型库存之间的转化。我们按照发起方来划分可以分为由销售发生的库存处理和非销售发生的库存处理。销售发起的库存处理指以销售行为而产生的库存的变化，销售流程消耗库存，履约流程完成库存的实际消耗配送。这部分的库存变化从供需关系来看包括以销定采和以采定销。一般意义上的售卖都是以采购入库的数量作
编辑导语：常规做法会在购物车环节设置数量阈值，库存小于阈值显示用户库存紧张。然后在下单环节完成扣减库存的情况。如果是秒杀或者是类似唯品会的抢购模式，则可以在购物车扣减库存，增加倒计时（如15分钟）提示提高用户抢购感。本文就来为大家聊一聊电商中的库存系统体系。
无论是电商也好零售也好所有的销售都是按照SKU为基准进行售卖的，为什么是SKU呢？因为SKU是最小库存单位，所以电商销售本质就是库存的流转。我们将商品库存从供应商手中采购后放入我们的仓库中，在通过电商的在线平台售卖给我们的用户，这个流转的过程就是库存的“迁徙”。
库存的整个迁徙过程非常漫长，库存的流转其实就是商品物权的流转。我们先来看下库存“迁徙”的路线，也就是库存流转的流程。在说流程前我们先说下电商平台对于库存的划分。从整体用途来看大致分为三个部分：销售、履约、采购。如图：
- 销售：实现用户下单购买的所有库存操作。
- 履约：完成对销售行为承诺的库存数量的履约操作。
- 采购：为履约需要的库存数量进行预先准备，同时也可以通过销售数据进行预估采购数量。
从业务关系上来说，销售行为作为最顶端的业务层直接决定采购和履约的变化情况。而采购作为履约的下游依据履约情况来判断采购的需求量。由此衍生出多种类型的库存，不同类型的库存之间通过约定的处理流程进行相互的转化，而库存的所有转化都源自于线下的库存实际操作行为。
一、库存处理流程库存的处理流程主要是将销售、履约、采购三部分的所有操作行为进行合理的串联，从而实现不同类型库存之间的转化。我们按照发起方来划分可以分为由销售发生的库存处理和非销售发生的库存处理。
销售发起的库存处理指以销售行为而产生的库存的变化，销售流程消耗库存，履约流程完成库存的实际消耗配送。这部分的库存变化从供需关系来看包括以销定采和以采定销。一般意义上的售卖都是以采购入库的数量作为销售的可售卖库存，而电商平台也有一种是以销定采的模式即预售模式。下面我们分别说下两种流程的库存变化情况。
销售售卖流程对于库存系统主要是进行扣减、占用库存和释放库存的操作。通过下单行为产生库存扣减和占用，当出现支付超时时要对已经占用的库存进行释放操作。关于库存占用的环节一般是在订单生成而不是购物车环节。
占用的核心关注点就是尽量避免库存被占用过度导致其他用户无法购买营销销量和体验，而购物车环节占用会出现这样的问题，所以电商平台设计占用时都会放在订单生成环节。流程如图：
履约的环节主要是对用户订单进行仓配作业，具体的仓配作业流程在之前的章节已经讲解过这里就不做累述了。履约的环节其实主要是仓库的库存进行分拣、出库的操作以及物流配送环节完成履约配送。除了常规操作外仓配操作还会产生两种作业会引起库存的变化：一个是用户退货、一个是换转退。
退货是用户对订单进行取消、拒收等行为产生商品需要返回仓库。商品在返回仓库前会生成消退入库单，仓库管理人员根据入库单的情况进行核对归整，完成后将商品在仓库内完成重新上架的操作，上架后仓库内当前商品在仓库存增加。
而换转退则是用户需要调整货物时发现仓库内已经没有当前的商品库存，这时候就需要将用户的换货需求调整为退货需求。仓库需要将换回的商品进行质检，如果质检通过则重新上架，未能通过则不需要增加商品在仓库存。
除了正常售卖以外预售也是一种在电商平台十分常用的模式。预售模式按照交付金额的时间点和比例也划分成若干的模式，不同的模式下对于库存的处理也是有些不太一样的。
整个预售周期内有几个相对清晰的阶段：预约期，订购期，交付期、履约期。预约期用户可以进行预约行为，预约行为不需要进行任何的支付行为同时不会产生订单。需要说明的是预约期不是所有类型的预售都需要的，只有无需缴纳定金时才需要该阶段进行资格确认。
订购期代表用户可以进行预售商品下单行为，这里下单会记录用户的履约信息如地址、收货人等，部分情况订购期同样会缴纳一部分商品的费用作为定金，不过不是真正意义上的商品定价价格。而交付期则是要完成订单价格的全部支付，交付期是判断订单是否继续进行的主要阶段，只有完成交付的用户订单才会被提交到供应商进行统一备货。我们按照周期的不同将预售分为无定金预售、部分定金预售和全额预售三种。
- 无定金预售：一般为预约通知后根据情况判断是否成单，比如Iphone的线上预约就属于此类模式。在预定成功后需要在规定时间内下单、支付方可完成全部过程。
- 部分定金预售：在预售订购期内支付部分定金，订购期完成后交付尾款。这种模式在预售里面占比最多，一般会配合阶梯价设置，务求达到人越多越便宜的效果。该模式下可以没有预约期的阶段，所有商品上架售卖后则可以开始订购。
- 全额预售：全额预售顾名思义需要用户提前支付货款，根据约定的周期（比如一周、一天等）来进行履约。这种模式同传统的售卖模式比较类似，订购期和交付期基本是在一起进行的。
我们来看下三种模式的变化情况。无定金的模式初始人较多，但由于违约成本低所以整体成单会下降较多。而订单最稳定的是全额预售，由于先付款违约成本高所以基本不会发生变化。部分定金预售的变化介于两者之间。
接下来我们看下三种模式在库存的处理流程上有什么不同。无定金预售需要用户进行预约，根据预约情况生成预约单，在预约截止日期后激活产生预订单，如图。在生成订单时进行扣减库存的操作，注意这里面是预售库存，对于预售库存的扣减不需要考虑仓储的情况。而当订单超出支付截止日期后不需要将库存释放。
说完了销售行为引起的库存变化，我们来看下除了销售以外还会有哪些库存情况。日常工作中出了销售出库以外，仓内也会出现很多种情况导致库存的数量发生变化。包括移仓调拨、仓内盘点、采购商退货以及商品报废几种情况。这些流程都属于仓库WMS系统和采购系统的功能范畴，这里就不在做详细描述。
二、库存系统数据流转如果我们把仓库的库存看作是一笔账目的话，那采购进货就是我们的进项，而上述说的几种情况则涵盖了我们除正常销售以外的出项（当然这几种也有进项的情况）。这几种情况代表仓库内的库存“账目”变化，电商平台前端的库存则是随着仓库变化而变化。我们把线上的库存看作商品的逻辑库存，用户可以根据库存情况选择购买。而仓内的为实物库存，表示实实在在存在的货品数量。通过库存系统我们将两者关联起来，用一张大图我们来看下库存之间行为的变化关系。
首先我们先聊一下关于库存的范围，什么样的商品叫做库存。一般来说我们认为所有已经获得物权或者即将获得物权的商品作为库存的范围，称为现货。现货不仅仅包括在库存储的商品，还包括采购在途、调拨中、预占等等类型的库存情况。
当采购侧完成下单配货的操作后，我们及认为采购清单内的商品已经属于仓库的所属，而完成仓库出库后则认为物权即将由配送员交接给用户。在这个区间内的所有商品数量都算作库存的范畴及现货的数量。除去一些使用、预占、不可售等状态以外，其余的叫做可售库存，也就是我们前端看到的可售卖的库存数量。他们的关系如下图：
刚才我们提到了仓间调拨，理论上支援仓的库存也可以被认为是可售卖的。所以当我们判断库存是否有货时优先判断本地仓的可售库存，其次根据仓间结构判断对应的支援仓是否具备可售能力，如果本地仓没有而支援仓有货则需要对订单Promise的预计送达时间计算影响，延长到货时间显示。仓库的可售库存是根据现货和其他状态下的库存数量计算得出的，并非一个相对固定的数字。
单仓可售库存的数量=现货 预售数量 调拨在途（待入库） 采购在途（待入库-预占-调拨出-不可售）
前端可售库存=当前区域仓库可售数量 支援仓可售数量
原则上不是每个仓库都必须有支援仓，支援仓的目的是通过高频次线路实现品类区域补足，但如果无法通过高频次来降低成本就会显得有些得不偿失。
仓库本身会出现库存增减的变化，而这些变化会通过库存系统的调用更新可售库存的数量。可售库存的数量更新后也会同步给前端进行显示。相反库存的占用包括销售、调拨、下架等行为也会统一通过库存系统进行管理并实时更新可售库存的值。WMS中根据业务情况也会将已经占用的库存进行释放，释放后可售库存会增加相应数量。所有的逻辑库存流转最终都会输入到库存系统进行统一的管理记录，库存系统会链接前后台的库存数据信息并与相关业务系统进行交互。
每个业务系统内部的库存管理更多是在自身业务体系下维护的数据，比如WMS的库存更多是对于仓库实物的管理。而库存系统则属于全局调度的逻辑数据，平台级别的库存数据管理需要以库存系统为主，比如商品系统、前端用户端、促销系统等都需要使用库存系统作为基础数据的来源，而不是其他业务系统。下面我们来看下各个系统对于库存数据流转时的情况，如下图：
我们可以看到库存的增减是通过其他系统来触发实现的，而库存系统就像是所有行为的账本，记录着每一个变化情况。管理好库存有助于我们对于整体运作的把握，也进一步避免出现超买超卖的情况。库存系统虽然不是一个真正意义上的业务系统，但在精细化运营的管理思路上他是一个不可或缺的助力工具。
#专栏作家#
高晖，微信号公众号：产品老高，人人都是产品经理专栏作家。10余年IT经验，互联网老兵。多年电商公司经历，曾参与过B2B/B2C/O2O等多个方向的电商项目，熟悉电商全流程产品线情况。
本文原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自 Unsplash，基于CC0协议
