销量预测设计

一、算法计算逻辑

销量预测算法建模要用到的数据：

观测变量Y：某个产品的销量数据
外部变量X：促销活动、以旧换新活动、节假日、疫情影响（可以是任何影响产品销量的变量，但是前提是可以持续被量化）

算法就是要根据这些数据，去建模建立一个模型。不管是统计学模型、机器学习模型或是人工神经网络模型。通俗来讲，建模的原理可以概括为：

历史数据去拟合一个函数式"Y = F(X)"，用历史数据输入模型去拟合找到最优参数，使得将所有数据代入到这个函数式计算出来的误差最小。

举个直观的例子

为了方便直观理解，举一个机器学习里面最简单的例子，线性回归。预测某城市的房价（不是预测房价走势），影响房价的因素有距离市中心的距离，是否学区房，周边配套情况，房子面积等等。我们只考虑最简单的情况：假设我们不考虑时间因素（房价走势）只考虑 “面积” 这一个因素。

$$房价Y=F(面积X)$$
并且假设房价与面积是线性关系，得到：
$$Y=kX+b$$
接下来我们就要用我们已有的数据：面积——房价

我们的算法模型：Y = kX + b ，但是k和b是未知的，如何确定k和b呢？

答案就是：用我们已有的所有数据去"试"，不断尝试不同的k和b的值（并不是“瞎试”，是通过一种最优化的寻找方式），使得找到的k和b代入公式，能让所有数据拟合的平均误差最小。这个过程也成为模型训练，直观来讲：就是我们把数据X与Y的关系画一个散点图，Y = kX + b是一条直线，k和b可以唯一确定一条直线。模型训练的过程就是找到一条对所有数据拟合最好的直线。

注：理解了这个过程，就能很好的理解为什么我们用的电脑被叫做“计算机”，它最初就是为了帮人类解决复杂计算的而诞生的。一些复杂的关系，靠人工写不出表达式的关系，都可以借助计算机算出来供人类直接使用。

当训练完成后，我们得到了一个确定模型Y = kX + b（k和b是已知的），我们要预测房价只需要输入：

面积——X，就可以计算出对应的房价——Y。

销量预测

刚才举的例子是算法建模中，最简单的。实际业务中要复杂得多。考虑的变量，需要拟合的参数也更为复杂，并且它也不可能是简单的线性关系。下面我们回到我们要做的产品销量预测中：

观测变量Y：某个产品的销量数据
外部变量X：促销活动、以旧换新活动、节假日、疫情影响（可以是任何影响产品销量的变量，但是前提是可以持续被量化）

对于我们的销量预测来讲，要用历史销量订单数据去拟合一个函数式"F(变量)"（找到未来销量、历史销量、外部变量之间的关系）它的函数式长这样：

$$Y(t+i)=F（Y(t-i)，X(t+i)），i=1,2,3.....$$

$$未来的销量Y(t+i)=F(历史一段时间的销量Y(t-i)，未来一段时间外部变量X(t+i))$$

同样，当我们的建立的算法模型训练完毕后，就相当于得到了一个确定的关系式。接下来计算未来的销量Y(t+i)只需要输入：

1. 历史一段时间的销量Y(t-i)
2. 未来一段时间外部变量X(t+i)

就可以计算出未来一段时间的销量。

根据不同产品的数据特点，采用了以下算法模型：

• Arima：可以拟合趋势、季节，可以输出预测区间估计
• ExponentialSmoothing：可以拟合趋势、季节，模型稳定性强
• Coston：专门用于间歇性需求预测。
• Prophet：可以拟合趋势、季节，同时还能考虑多个外部变量的影响，可以输出预测区间估计。

二、项目背景

供应链管理是所有跟实体经济相关的企业遇到最具有挑战的问题之一。公司现有供应链计划有待优化。
引入算法预测终极目标：代替业务人员预测，为业务解决库存短缺和过剩的问题。当然，这不是一蹴而就的，需要数据、算法和IT流程不断完善，以及业务人员的建议和反馈。

现阶段，算法预测作为只能作为辅助，为业务人员提供数据参考。并且需要业务人员的反馈和建议反过来去完善算法。

现阶段引入算法预测的目的是为人工决策提供一个参考，并不是直接立马取代人工预测，并不是直接按照算法预测值做生产计划。

现阶段做供应链计划的总的思路：“从数据开始，由判断结束”。尽可能减少数据与业务之间的信息不对称。

1. 算法工程师距离数据最近，具备数据分析和挖掘能力，可提供相对客观数据分析，但是拿到的只有数据，不懂业务和市场；
2. 销售负责人距离市场近，懂业务，但是容易受到市场波动和业务（业绩指标压力）的影响，层层批报充满博弈，容易加剧“牛鞭效应”。
3. 简而言之就是：公司大了，有数据的没判断，有判断的没数据。
4. 目前算法预测的数据，是根据历史销量（历史需求量）预测的，输出的预测数是未来的需求量，不能直接用于生产计划参考。需要减去现有库存加上安全库存才是理论上生产的数量，最后还需要参考最小生产批量才能最终确定生产多少。
5. 需求预测的完整流程：算法根据历史数据建模得到一个预测数，给到销售负责人，然后销售负责人根据自己多年业务和市场经验，给出自己的判断，即在算法给出的预测数的基础上进行一定的调整。

打个比方，算法预测某个产品下个月的需求量大概是1000台，但是销售的负责人知道上个月这个产品只卖几天就卖断货了，没库存了导致上个月卖得少，还有好几个客户想买，在等库存。所以上个月的销量并不能真实的反应市场实际需求。，预计下个月销量会有50%的提升，所以最后调整下个月的需求量为1500。现有库存是0，安全库存是500，所以理论上需要生产1000（1+50%）- 0 +500 = 2000台。但是这个产品的最小生产批量是2200，所以最终确定生产2200台。

三、算法与业务的关系

算法永远是为公司业务服务的。现有“从数据开始，由判断结束”思路，是为了减少数据与业务之间的信息不对称。
关于算法预测值为2000，人工预测为3000，这是很正常的。算法预测的目的并不是要往人工预测方向靠拢，毕竟人工预测如果足够准确，那么公司也不会增加算法预测。衡量算法预测值是否准确的，并不是人工预测值，而是实际需求值。这并不意味着算法与业务是对立关系，恰恰相反，在“需求预测”不断完善的过程中，二者是相互合作，相互依赖的关系，最终还是服务于业务，优化公司供应链计划。

四、关于业务人员对未来外部变量“打标签”：

只需要打未来人工已知（可以确定）的变量。比如促销活动这种，对应的业务人员是知道未来一段时间内是否有促销计划。对于节假日这种标签是不需要打标签的，算法建模前可以直接从万年历获取。
需要主要的是：外部变量并不是却多越好，这可能听起来跟人的常识相违背。原因如下：

1. 建模用到的外部变量要准确对应历史数据，并且是对历史事件的客观反应。
2. 数据量不够大的情况下，过多的外部变量。反而会降低模型的泛化能力，导致模型“过拟合”
3. 考虑的外部变量要能持续被量化。

比如疫情这个外部变量，对经济影响很大，对产品销量同样很大。但是，如何量化一个销售区域的疫情严重程度。人工可能觉得很简单，觉得网络信息这么发达网上一查就知道。但是实际上，人能看得到的文字视频计算机并不认识。说到这里你可能会觉得，那也简单，现在网上可以查到，每个省份每天的新增、治愈、死亡病例。用这些数据计算机不就能看懂了吗？其实不然，一个销售区域包含多个省份，每个省份人口基数，人口密度，经济实力，医疗条件都不一样，每个省份对我司产品的贡献值也是不一样的，并且疫情从爆发到现在我国防疫能力，防疫政策都是一个动态变化的过程，像国外的疫情已经是躺平政策，官方已经不在统计疫情相关数据。

所以战争因素、政治因素、疫情因素它本质上是通过影响经济因素去产品销量的。这个东西是很难被量化的。退一步来讲，即便我们找到了最客观最合理的手段去量化它，也很难提升预测的准确率，甚至有可能降低准确率。因为，我们是预测未来的销量，我们用考虑这个外部变量就要知道未来几个月这个变量的值。如果我们强行考虑这个外部变量，那就需要自己去预测这个外部变量它在未来几个月的值是多少，这就意味着又回到了人工预测未来了。

五、关于预测颗粒度：

现有的颗粒度如下：

• 产品颗粒度：同一个A箱。
• 区域颗粒度：所有区域总量，不单独预测渠道。
• 时间颗粒度：按照月份聚合数据。

算法在销量预测开始前首先需要考虑的就是：在合适的颗粒度上做预测。通常要考虑的颗粒度有，时间颗粒度，产品颗粒度，区域颗粒度……

一般来说，会优先考虑在颗粒度大的地方做预测，其背后逻辑是颗粒度越大，需求聚合效应越明显，从数理统计来讲，可预见性就越强，数据模型就越可靠。公司销量数据特点表现为：类似与“长尾商品”销售数据的特点，即为间歇性需求，大多数商品一年当中有需求的月份不到6个月。之前区域颗粒度细分到销售小区每月需求量为0的比例高达70%以上：

对于区域A、B、C、D这种需求过于稀疏序列是几乎不具备可预测性的。必须进一步加大预测的颗粒度，聚合数据。

当然，这并不是越大越好。具体在哪个颗粒度上面做预测是由业务决定的，一般来讲是业务能接受的最大颗粒度。对于一个实际项目来讲，颗粒度不是越大好的原因如下：

1. 不同性质的产品是不能聚合在一起的。
2. 如果一个产品在不同渠道的销售策略，促销活动，相差很大是不能聚合在一起的做预测的。否则外部变量量化难度大。
3. 颗粒度越大，对于业务人员来讲参考性越弱。对于某一个销售大区区域的负责人，如果给到所有销售区域的预测总数，那么这个总数对这个销售大区区域的负责人的参考意义是不大的。
4. 时间颗粒度越大，数据量越小。如果按照季度或者每年的数据去聚合，那么得到的数据量会大大减小。

六、关于预测准确率和影响准确率的因素：

所有算法从业者都知道，算法行业里有一句很经典的话：数据和特征决定了机器学习的上限，而模型和算法只是逼近这个上限。

如果把数据建模的过程比作烧饭做菜的过程。那么，算法工程师扮演的就是厨师，算法服务的业务扮演的角色就是订餐的顾客。产品经理则是负责登记顾客需求和传达需求的中间人相当于店小二，提供相关数据的数仓人员就相当于提供食材的采购。一个完整的项目大概需要经历以下过程:

1. 首先第一步要做的就是要确定做什么菜，店小二拿登记顾客需求后。登记顾客要吃哪些菜，每个菜在口味上有什么要求，整理成需求清单后然后给到厨师。（产品经理将需求文档给到算法）
2. 厨师根据店小二的需求清单，确定需要哪些食材，列一个清单给到采购。（算法根据需求文档输出一个设计文档，其中包括了需要获取哪些数据，给到数据组）
3. 采购将食材给到厨师，厨师开始烧饭做菜。（算法拿到数据后，开始建模）
4. 烹饪完毕后店小二将做好的饭菜给到顾客。（开发完毕后给到业务，验收）

单从预测准确率上来讲：

1. 首先，是要有数据，不然“巧妇难为无米之炊”。
2. 其次，是拿到的数据质量要高。如果ERP系统中存在大量的错误记录、对应关系、脏数据以及业务人员不规范操作。数据建模注定是“垃圾进，垃圾出”。
3. 最后，是算法工程师的专业能力和对业务的了解程度。