物流行业的数据分析，主要分析什么？

编辑导语：在做物流规划设计时，数据分析是个很重要的步骤，如果不做这些准备，可能会在做方案时手脚慌乱；注重数据分析，认真分析，找出规律，与用户充分的沟通。本文作者分析了物流行业的数据分析主要分析什么。

做物流规划设计时，人们往往对设计指标感到茫然，对新员工尤其如此；有些设计人员比较急躁，一上来就急于做方案、画图，结果画来画去，就不知道自己到底要做什么了；耽误了不少时间不说，设计方案要么不知所云，要么离题万里，对用户是一个很大的伤害。

一个良好的设计习惯，往往是应该首先明确设计目标，了解清楚设计要求之后，再去动笔。

就比如写文章，总应该先确定写什么主题、目的是什么、给谁看；然后才开始写提纲、反复推敲提纲、找好素材和参考资料，再动笔写；然后再反复推敲、修改润色。不然，就很难写成一篇有质量的文章。

画图虽然很重要，但到底只是一种比较简单的劳动，而画什么、表现什么主题、达到什么目标才是设计的关键。

设计是如此，对一个设计方案的评价也是如此；我遇到很多客户要求评价一个总体的方案，其实这是很难的；其中关键的一点就是：方案是设计需求的响应，对方案进行评估，首先要对设计目标进行分析和评估，这才是根本。

数据分析是一件很严肃和需要专业知识的工作，并非仅仅对数据进行简单的加减排列组合就可以了。

我特别反对那些不注重数据分析的客户，一项设计，设计指标是基础；基础出现问题，你选用的设备再好，系统再先进，也是于事无补的。

其实物流仓储系统的规划设计也没有那么难，关键一点是需求要清楚明确；而需求是可以用数据来描述和定义的，一个项目，其关键数据也就那么几个而已，如收货量、发货量、库存量、拆零量、SKU等，并不难掌握。

本文就讲一讲这些最基本的需求，为了便于理解，主要从物流仓储的几个环节进行描述。

一、基础数据

在进行系统性描述之前，一定要清楚物流的作业当量最后是以小时来计算的（当然还可以细化到半小时，甚至更小单位）。

所以，我们所有的物流量，最终要以小时当量来计算；然而，从用户那里得到的实际的设计指标，很可能是年度的作业纲领，如年配送100亿——这个数据非常重要，却也是非常不确定的；因为从这个指标推导下来，就会看到，每年的作业天数、每天的作业时间、货物的价值、仓库库存周转次数等，对最终设计都有很大的影响；所以，这些关联数据应该是要首先明确的。

假设设计纲领是G(年配送目标，亿元)，单箱价格是p，则年度总配送箱数是：

Q = G/p

假设每年作业天数是N（天），每天工作时间是t，则每小时的作业量是：

q = Q/N/t

如果库存周转天数为D，则库存量的计算公式如下：

W = q*t*D

以上的数据关系都很容易推导，但在实际中要注意的是：不同的作业，其作业时间可能是变化的；如高峰时期每天作业时间要大于平常作业，发货时间有时也与收货时间不同等，会增加计算和分析的难度。

在进行具体数据分析时，还要明确箱与托盘的对应关系。

托盘一般选择标准托盘（1200*1000），假设平均的满盘量为n，则库存托盘数应为：

P = W/n

当然，在描述具体数据时，要区分收货、发货还是退货，每一个作业也许是不一样的。

很多时候，用户是不清楚这些差异的，或者表述不清楚，那么我们就应该将自己的经验或理解进行分享，以便双方达到认识的一致。

二、收货有关的数据

与收货有关的数据，包括到货量（箱）、订单数、车辆的装载量、收货区域大小、收货作业时间、每天收货SKU数等。

车辆的装载量和卸载时间主要对于站台设计有影响，包括车辆大小、载重量等；一般情况下，还要分析卸货的方式、速度，以便详细规划站台的数量。

收货一般是比较简单的，但也有比较复杂的情形，比如新华书店图书的收货即是如此；因为每天到货的品种很多，还有大量混包的情形，因此收货要进行专门的处理；有些电商的收货也比较复杂，包括要进行QC等动作，对收货区的要求就不一样。

很多人对高点平均值和算术平均值对于设计的影响不甚了解；简单来说，将一年（或一定时间）的收货量除以一年（或一定时间）的实际工作天数，即得到平均每天收货量，一年中最大收货量的一天，即最大收货量。

在实际上设计中，如果按照平均值设计，则使得加班的天数会很多；如果按照最大值进行设计，则会出现工作很不饱满，设备闲置的现象。

因此，一般取平均值和最大值之间的某个值进行设计，具体要根据实际需要确定，发货也有这种情况。

三、储存有关的数据

库存能力对系统的设计非常重要，但如何确定库存却是非常有讲究的。

除了库存总量W以外，还要考虑SKU数，以及各种存储方式下的库存要求等；很多情况下，仓库的设计并非是单一的，所以，设计的时候就要清楚库存的方式是什么、有什么要求。

一般的储存形式分为2种主要方式：

• 以托盘为单位储存（分为立体库和平面库两种最基本形式）；
• 以箱为单位储存。

当然还有其它形式，如包裹、麻袋、散料等，也有条状物（如钢材）、异形物品（如服装的挂装等）等，不再详述；在设计中，这两种方式都要考虑，有时以托盘为主，有时以箱储存为主，有时两者比较均衡。

计算库存能力当然与箱规有关，也与平均库存天数有关，这是基础。

SKU对库存分配的要求有很大的制约作用，往往与作业面设计有关；此外，发货量对于库存设计也有非常大的影响，如拆零量，就要求对拆零区有一定限制。

库存ABC分析也是非常重要的，对于仓库设计起到重要作用。

一般情况下，库存ABC分析结果决定了储存形式，ABC的定义将随着不同业务有所不同，要因地制宜；实际操作中，往往要对够托盘，够1/2托盘的SKU及这些SKU所占库存比例进行分析，以便正确决策。

随着电子商务的兴起，SKU不断扩大，ABC分析尤其重要；此外要注意的一个趋势是，箱式存储方式越来越受到重视，其占比越来越高，也影响库存的分析。

再计算储存能力时，人们普遍对库存充满率感到困惑。

一般情况下，我们知道，托盘或货箱并不能完全被充满，而为了满足作业的顺利进行，货位也不能完全被充满；因此，要留有余地，这两个系数在不同的案例中会有差异，但都不应该忽视。

四、拣选有关的数据

拣选的订单数、订单行数、发货量是比较重要的设计数据。

发货ABC分析同样重要，要注意的是——发货ABC分布与库存ABC往往是不相同的，分析时要注意加以区分。

拣选环节设计关注的主要是拣选、包装和输送问题，因此，有关拣选的细节问题就非常重要；如：整盘出库量、整件出库量和拆零出库量，这三个参数对于设计也是非常重要的。

一些基础信息也是要清楚的，如拣选效率、播种效率和包装效率等，有些可以通过其它项目经验获得，有些应进行实际测量；需要指出的是，测量结果与作业流程、工位设计以及测量方法有关，有时很难确定一个准确的结果。

不同的拣选方法其效率差异很大，这是设计要特别考虑的地方；事实上，采用什么样的技术手段，对设计结果影响甚大；这一些问题，在数据分析时，就应该有所考虑。

五、发货有关的数据

发货路向、数量、车辆形式、作业时间、暂存时间等数据是发货设计阶段的基础。

众所周知，分拣机的格口不可能无限增加；因此，设计中应考虑波次问题，以便控制格口数量；有些物流中心的发货区设计很小，站台停车位很少，给发货造成很大困难。

集货区的大小与发货波次有关——很多小的物流中心，每天只安排一次发货，其发货区就要大一些；对一个大型的物流中心来说，一般要按照多个大波次组织发货，每个大波次还有若干小波次，由此可以大幅度降低对集货区的需求；这在设计中是要注意的。

随着大家对物流认识越来越深刻，发货装车环节越来越受到重视；因此，设计中也要与时俱进，考虑自动化系统对发货区的影响。

六、退货有关的数据

退货很重要也很困难，但容易受到忽视。

在通常的数据分析中，退货分析也是不充分的；事实上，退货与收货的过程是不一样的，这主要是因为退货收货需要处理的数据量远远大于普通收货。

退货作业不是均衡的，有很大的波动性；因此，在数据分析中（实际作业也是如此），要将退货收货与退货处理分开来，其作业时间和作业量都不会一样。

对退货来说，其作业流程对于设计会产生影响；一般数据分析仅仅提供退货量即可，包括订单数、订单行、SKU、数量等。

要注意的是，退货有两种形式：

1. 终端退回到物流中心；
2. 物流中心退回供应商或者报废处理。

两者差异是很大的，在数据分析时，要分别对待。

七、其它

数据分析很重要，也有一定难度，这是需要指出的，经验和专业知识对于数据分析很重要；此外，数据分析结果必须得到用户确认才能用于设计。

对一个数据样本的预处理，是分析数据的第一步；什么数据是有效的，什么是无效的，要有明确的规则。

剔除无效数据对于数据分析是很关键的一步，当然，要做到这一点，除了认真调研和分析外，经验和常识也很重要。

数据要有典型性，因此，数据量不能太少；比如，一年四季的数据是变化的，一个季度之中的数据也是变化的；每月、每周、每天，甚至每个小时的变化如何，要有系统的分析。

一个静止的和孤立的数据是没有意义的，必须与系统环境相关联，这一点也很重要。

有时，数据分析与方案设计不是一个人，这时就需要注意沟通；数据分析不可能完全独立进行，它需要与设计方案相匹配，正因为如此，每个项目的数据分析的重点也是不一样的。

数据分析人员至少要对设计需求有所了解，才能知道如何分析数据，如何从成千上万的数据中找到规律并抽出有用的东西。

最后要说明一点的是：数据分析的结果并不是直接应用于设计，而是要据此提出设计指标；其中有些数据的变化是比较缓慢的，如产品特点、订单结构、品项数、作业方式等，有些却会变化剧烈，如设计指标等。

这些除了经验、行业情况能够提供帮助外，关键的是要认真分析，找出规律；在这个过程中，充分的调研，与用户充分的沟通尤其重要。

 

作者：李启方，公众号：数据分析不是个事儿

本文由 @李启方 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议