从一场疫情响应战来看生鲜供应链数字化的威力（5000字长文）

在今年某次疫情中，为了支持保供，某生鲜电商企业的产品线做了平时需要半年时间才能完成的上百项功能迭代。这家生鲜电商企业的产品人是如何根据市场需求变化，进行产品动态调整响应的呢？一起来看一下吧。

在今年某次疫情封城中，某生鲜电商企业所在的总部恰好在该城市，在这次封城中，为了支持保供，整个企业的产品线做了平时需要半年时间才能完成的上百项功能迭代，这其中无疑不体现了数字化对商业运作的重要价值与意义。

下面我们就来看看在这场疫情中，这家生鲜电商企业的产品人是如何根据市场需求变化，进行产品动态调整响应的。

01 一组数据说明疫情的惨烈

首先我们用一组数据来看看整个生鲜电商在这期间接收到的冲击有多大？如下图。

大体上可以总结为：

1. 客户端APP流量翻番；
2. 订单量最高为平时的4倍；
3. 企业供给能力上限也只能满足全市需求的10%；

面对高涨的用户需求，但是在疫情期间我们的整个生鲜电商的供给能力出现了大规模的下降。

这里不仅仅是一家企业啊，几乎整个生鲜行业在那个时刻都存在这个问题。那么我们具体来分析一下为什么会出现这样的问题呢？

首先我们聚焦来看看生鲜电商的一般性供应链构成，如下图所示。

可以说是标准的分职能架构，由生产加工将原料生产为成品，并由中心仓（部分生产加工中心直接建在中心仓内，此处可能就只有中心仓节点）统一向城市内各前置仓进行补货，并最终由前置仓进行用户订单履约。

那我们原来引以为傲的这种分层的效率建设供应体系为什么在这个时候呢一瞬间起不了作用？

我们具体来看原来的体系里，最大的原因就是因为我们整个流程过程我们的中心仓往往由于疫情的原因整仓被封，或生产中心直接被封，导致我们出不了货。也就是我们的原料到了生产加工中心并生产完成后，送到了中心仓，这个时候却没有办法去进行发货。因为中心仓有疫情被关掉了，不能再使用。

那这个时候就没有仓去帮我们做生产加工，我们末端的前置仓他又没有生产加工的能力，就导致没有办法去进行配送。

其次就是我们在末端的这些骑手里头，他很多也被封在小区里头了，所以就导致出不了货。

所以综合来看表现就是在物流上可以看到我们买不到货，出也出不了货，然后用户更收不到货。原来引以为傲的效率的分层供应体系在疫情时间瞬间就失灵了。

那么看到这里，我想说一点，生鲜零售的数字化其实就是零售数字化体系发展的又一次进化，为什么这么说呢？因为生鲜的这次遭遇的问题，它本质上来说也是我们传统零售行业遭遇过同样的一个问题，只不过这个时候他又套到了生鲜零售上。

02 疫情暴露问题分析

那我们产品人应该怎么去解决的？首先我们先将各个问题具体分析。

1. 为什么说我们买不到货？

我们可以看到在客观因素上来说。当时在疫情中我们买不到货的原因就是因为各家生鲜企业都开始在疯狂的抢这个货源。整个市内的个个生鲜供应基地货被一扫而空。而全市封城了之后，城际主干道通道也被阻塞掉了，导致就是外省的货他没有办法送进来。

然后同时由于内部我们还存在一套复杂的加工过程体系，就是我们原来出售的都是洗好的土豆或切好土豆丝。

但是在中心仓等被疫情风控之后，我们就没有办法再次进行处理。我记得那时候我们只能看到那一框框土豆就在仓库里，而我们无能为力，这是我们的客观也买不到。

此外同时我们还有主观原因导致买不到，主观原因是什么呢？就是当时我们的这个采购同学由于他身上背负的KPI，就是要降低这个货损，也就是我们的库内损耗。

但是在疫情中一旦某仓出现疫情，此时整个仓库就要被封，但是生鲜在仓库中放上一天你就会看到菜开始发黄了，甚至部分叶子开始发臭发黑了，那么在仓库中大量菜密集堆放的情况下这种情况更为显著。

所以导致采购看到这样的情况之后就不敢去大量采购。因为买了之后一旦仓被封，整个货损就全部算到这个采购的身上，他背不起这个KPI，所以他也不再怎么敢去下采购单，所以导致不仅货源本来就少，而采购也不愿意下单。

那么这是第一个问题的详细原因构成。

2. 我们的部分供应链节点的瘫痪导致链路中断

大家还记得前面有一张图告诉大家说中心仓是起的什么作用？中心仓的他起了作用其实就是去承担成品的分发功能，以及承担生鲜品的一个二次仓内加工过程。

也就是我们把一筐筐土豆和蔬菜在仓内进行一个预包装，从而分拣成一盒一盒的。

但是在疫情中我们由于中心仓被封了之后这个链路就完全断掉了。最前线的前置仓它原有的功能仅仅是分拣和配送，此时来了一筐筐的土豆，他一方面是没办法加工，同时他也处理不过来，更没有这种专业的人去进行一个分级挑选。

所以就会导致我们整个链路中一旦中心仓瘫痪，前置仓就算有货，他也不知道怎么去发，他更没有办法进行加工。

以上就是第二个问题的详细情况。

3. 我们末端没有人力配送

那我这里给了一个数据啊，就是大家可以看到在疫情的风控情况下出现的的数字有多么极端。

某生鲜电商原本一共有284个前置仓，但是疫情影响直接临时关闭了100个。此时仅剩160多个左右。

可以看到将近一半的前置仓都已经被关掉了，那这个关掉意味着什么，就是说用户打开APP就会发现自己所在的区域无法下单了。因为我们的前置仓是有覆盖区域的，他一般只覆盖5~10km左右。

这个时候一旦这个前置仓被关闭，在地图上这一块区域就变成空的了，就没有办法去覆盖这个地方，所以就导致末端没有配送。

就算这个前置仓有骑手，他能到这个前置仓，但是这个前置仓也也已经被风控了关闭了。

同时我们这个骑手由于在我们原来产品体系过程中，它是和前置仓强绑定的。因为我们要去给这个骑手去算绩效，对吧？要去算他的这个工资，所以我们会有个前置仓的绑定功能，在短时间内我们也处理不过来这个骑手的关系转移。

就导致骑手和前置仓没办法解绑，人力被彻底被锁死到这里。还有个是什么呢？就是我们当时去锁定骑手运力的方式有一个问题，我们原先是按单量计算运力饱和度的，比如一个骑手每次外出只能接30单。那这个相信大家很好理解，就是因为我要给骑手去算费用，此时肯定是从企业的这个管理成本上来考虑，我肯定是希望按订单去给你算绩效，也就是一个订单不管多少货我给你的运费是固定的。

但是这样的管理方式，造成在疫情情况下很多时候由于大家都是拼手速抢菜，很多时候用户害怕抢不到，于是刚选了一袋面包，他就立马提交了订单。此时因为这个订单就把一个骑手的运力去锁定了。

于是我们就看到很多诡异的现象，很多时候发现好不容易有个很宝贵的骑手过来了，但他身上总共装了40包面包就出去了，宝贵的运力因为订单的这种锁定方式被白白的浪费了。

所以这实际上来说就是我们的末端无配送的一个具体的表现。

可以看到在零售体系中我们原有这种高度的分工化，反而让整个链条变得极为脆弱。

那这实际上来说不仅仅是生鲜零售问题，其实就是我刚说的在整个零售体系中都会出现这样一个问题。一旦大规模的突发性用户需求爆发的情况下，我们的零售体系就变得非常的脆弱。

03 进行定向问题改造

那我们作为产品人，我们不能说无动于衷。这个时候我们就应该发挥我们的主观能动性，去思考要怎么解决这些个问题？

那我们产品人我们怎么解决这个问题？那这里我给出了一个基于中台能力的综合解决方案。

我们来看第一个问题，我们要怎么具体去解决？

这里的解决方案分为两个维度，第一个维度纯业务方案，调整进货渠道，动态调整KPI等等。

而在产品维度上我们要实现货找人，也就是说由我的货去找仓，这个仓库有货，但是这个仓库没有订单，我们就在疫情期间在我们的供应链中台中，将原有给仓库绑定的限制属性全部下掉，将所有仓库视为一个原子仓库，允许进行互将调拨，我们不仅仅让大仓可以往前仓补货，我们还允许前置仓之间互相调拨，这个前置仓被封了，但是他有一堆货，我们赶紧调拨到另外一个前置仓，那么这样的话就让这个货去找到真正有需求的人。

第二个问题的解决方案就是我们需要去建立一个具有柔性的供应链体系。

所谓的柔性供链其实就是我们要去建立一个缓冲能力，那我们刚才已经讨论了我们遇到的问题是什么？

就说是我们原来是在进行一个分级加工的一个执行体系。这个时候我们通过上线节点属性配载功能，建立一个冗余体系，我们可以在系统中将任意一个仓库设置为一个额外加工中心。

比如说我原来的这个前置仓，他原来没有这种分级挑选的属性，此时我们在系统中计算路径时就不会计算该节点，但是当我们通过这个动态配分级属性功能，随时让某个临时抽调人员组成的仓配上这些属性后，后续所有的加工路径，原料配送路径都可以识别了。

此外这里我们做的一个改造就是去将生产和转运这些功能属性与具体仓库进行解耦。也就是针对一些具有多重属性功能的仓库，一旦中心仓瘫痪，那它所覆盖的所照顾的这一群前置仓就没有办法去执行一个补货。

此时我不需要说一定由中心仓向某个前置仓补货，我可以随时让某个前置仓也变成一个中心仓，只要在中台体系中配置转运属性，然后由这个前置仓瞬间变成了一个集散地。他可向这个城市进行货物集散分发，此时我们就解决了这个问题，也就是将转运功能进行动态的可变化。

第三个问题就是我们末端的前置仓配送问题。

首先我们分析一下用户无法下单的原因是什么呢？其实原因就是因为我们前置仓原来的服务范围是一个固定的网格。这个网格一旦被划定了之后，它就没有办法去进行一个修改。就像我刚才说的，我们在地图上原先通过284个前置仓，在地图上分割成了284个小块，那一旦这个前置仓崩溃了，这个时候我们这块就空出了一块空白之地。

那这个时候其仓因为这个网格是固定的，他也没办法覆盖，那现在我们的处理方式就是动态网格，一旦某个前置仓崩溃了，我们就将其他周边的两个节点或者说其他的三四个节点去进行一个动态调整，从而实现我们这个地图上没有空白的区域，实现动态地去支撑。

此外原来我们的骑手他是必须要绑定某个前置仓才能去领任务，而且整个调整链路要一周以上，那这个时候我们做的调整就是可以根据订单的密度去动态管理我们的整个骑手。

让在一个城市的整个骑手资源可以通盘去看，然后去实现动态调整。今天这个前置仓因为他的单量多，我们把这些骑手调度到这个前置仓。明天这个前置仓的单量下来了，我们再把多余的骑手去调度出去。那么就实现了骑手的一个动态运力的调整。

然后再往下就是将原来锁定骑手运力按订单量方式去进行一个解除，那这里的解除，不是说简单的就是说干脆按这个骑手上的这个商品的件数去进行一个计费。那这样的话其实我们付给骑手的这个成本就会飙升，所以我们的解决方案是通过增加了一个补单的功能，我们当一个订单锁定了骑手之后，如果这个订单还没有出仓，那我们有货用户可以随时去二次追加，从而去提升我们每个客单的商品数量。

可以看到我们在设计解决这个问题的方案时，一方面考虑了公司的成本需要。同时尽可能的让骑手运力效率实现了最大化，给出了一个平衡的方案。

我们可以看到这里的解决方案本质思想就是两个：

1. 解耦：将仓库的不同能力属性抽象出来，如生产，转运等，从而实现动态配载；
2. 全局：将所有资源节点（仓库，线路，加工路径，人员）线上化，从而实现全局的资源调度与管理。

而这二者也就构成了供应链柔性化的内核，看到这大家感觉与中台的设计思想有无相同之处？

没错，这里的思想本质也就是我之前多次强调的MSS中台建设模型：先抽象出企业能力，随后将整个资源全局管理，实现动态调配。

最后对于零售企业来说，建立柔性体系是一家企业走向强大的必备基础，而这背后一定需要有一个强大的资源管控能力平台进行调度。