需求预测：分门别类，区别对待

比如总部采购预计到一种产品价格要大涨，就要求各子公司快速集中申购，锁定价格；多次提醒，各区域采购部也有行动，但使用部门不重视。很多子公司的用户不申购，因现场无法存放、暂时需求不明等。有些子公司即使下单了，也不让供应商发货。有些子公司让供应商备货，供应商以无订单、资金压力为由拒绝。最终，大部分供应商坚持按行情定价，最终合同采购仍然按行情价签。

这看上去是个采购问题，其实是个计划问题：各内部用户提需求（这里是数以百计养殖场），预测颗粒度太小，预测准确度低，特别是申报几个月外的需求的话；看上去是使用部门不重视，其实是预测准确度太低，库存风险太高，这些内部用户就宁可牺牲价格而不愿提前建库存。那解决方案呢，就是对这样的材料集中计划，集中采购，集中存储，然后内部用户随用随取。这是利用需求的聚合效应，提高整体预测准确度，降低库存风险。

他们的问题是，几千、几万个采购对象，究竟什么可以预测，该计划；什么不能预测，不可计划？要计划的话，是在总公司层面，还是子公司或者养殖场层面？

很多人想到的就是ABC分类法，比如A类产品贡献80%的营收，B类产品贡献15%，其余贡献5%等，根据它们对业务的影响，决定是否要计划，在总部、子公司还是养殖场层面计划等。这是从业务的视角来分类产品，但从计划的角度看，价值5000元的A产品和价值5分钱的C产品单价差别很大，对业务的影响大不一样，但完全可能用同样的预测模型，采取同样的计划方式，因为他们的"计划特性"一样。

那什么是"计划特性"呢？简单地说，计划特性就是产品的需求特点，可从两个维度来描述：稳定性和频繁度。需求越频繁、越稳定，产品的可预见性越高，可计划性也越高；需求越不频繁，越不稳定的情况正好相反。当然，这里我们一般会用需求历史，假定历史需求有一定的重复性，如果有设计变更、生命周期等显著改变需求的行为，我们会另行考虑。

对于需求的频繁度，我们这里导入13周频次的概念，亦即在过去的13周里（1个季度），有多少周有需求。比如13周频次为5，表明在过去13周里，有5个星期有需求。这里的判断标准很简单：在特定的一周，如果有需求，那就是1；如果没有，那就是0；把13周的值累计起来，就得到该产品的13周频次。13周频次越高，表明需求越频繁。26周频次、12月频次的概念类似。

如图 1，这是某电商的13周频次图。其中有2500多个SKU的13周频次为零，表明这些产品在过去13周内没有一周有需求；500多个SKU的13周频次为3，表明这些产品在过去的13周里，有3周有需求。这些都是典型的长尾产品。13周频率越高，产品越可能是短尾，但并不一定是短尾，因为这里还有个需求的稳定性问题：需求虽然频繁，但不稳定的话，我们会归入"中尾"。

图 1：需求的频繁度：13周频次（示例）

对于需求的稳定性，我们导入离散度的概念。如图 2，假定产品的需求符合正态分布，我们用离散度（也叫离散系数）来描述需求的稳定性。比如过去20周，示例产品的每周平均需求是49.6个，需求的标准差为18.2，那么该产品的需求离散度就是0.37（49.6÷18.2=0.37）。在图 2中，我们也显示了Excel中计算标准差的公式。

从数理统计的角度看，标准差本身就能反映需求的稳定性。但是，产品的平均需求不同，其需求的标准差也缺乏可比性，比如需求越高的产品，其标准差一般也越大，反之亦然。离散度是对标准差的归一化，让不同产品有了可比性。

图 2：需求的稳定性：离散度（示例）

基于需求的频繁度和稳定性，我们可以把产品分为三类。第一类是需求频繁而且稳定的产品，我们这里称之为可以预测的"短尾"；第二类产品的需求相当频繁，但不稳定，这里称之为难以预测的"中尾"；第三类产品的需求既不频繁，也不稳定，是不可预测的"长尾"。

要注意的是，这里的短中长尾定义，跟我们平常看到的有联系，但也有不同。平日看到的"短尾"，更多地是从业务的角度来阐述，需求相当频繁，营收占比也较大，其实也包括"中尾"（有些企业叫"头部"产品）。从计划的角度出发，我把需求频繁，但变动性也大的"短尾"单列出来，这就是"中尾"。在这三类产品中，长尾难对付，但相对来说是小灾小难，因为业务占比较小；"中尾"在业务中占比更大，更容易导致大错特错，其实是最难对付的。

对于短中长尾产品，我们用更形象的方式来描述，如图 3。根据不同类型的产品，我们有不同的计划方式，由不同的职能来主导：

· 对于短尾产品，历史数据有相当大的可参考性，主导职能是计划。

· 对于长尾产品，要么由订单驱动，要么由销售提需求，主导职能是销售（除非是在更大的颗粒度做预测，那时计划成为主导）。出于服务水平考量，不得不备的长尾产品，计划也可根据有限的需求历史，或者产品管理、设计、销售等的建议，设置一定的安全库存。

· 中尾产品介于短尾和长尾之间，可由计划来主导，根据历史数据，采用预测模型得到基准预测；销售、产品、市场等职能辅助，预判可能显著改变需求的事件，由判断结束。

要特别注明的是，这里讲的"计划"泛指做数据分析的人，并不一定在供应链下的计划职能；"销售"泛指有判断的人，也可能是市场、产品、品牌、设计、高管、内部用户等。

图 3：不同的产品，不同的职能来主导，采取差异化的预测方式

我们再回到前面的养殖企业。要决定哪些产品可计划，在什么地方计划，需要分析每一个采购对象的需求频繁度和稳定性，来量化其可计划性。比如有些产品需求相当稳定，也很频繁，那我们可以在养殖场层面做计划，建库存；另一些产品在养殖场层面是典型的长尾，但在子公司层面呈现更好的可计划性，那我们就在子公司层面建库存。还有些产品在养殖场、子公司、总公司层面都是长尾，那我们要么承担一定的风险，在总公司做计划，建一定库存（比如关键的进口备件）；要么订单驱动，依靠供应商的库存（假定供应商的需求有一定的聚合效应，可计划性高）。

对于这个养殖企业来说，基层用户申报需求的做法，其实是把计划的风险向两头转移：一头是几百个内部用户，预测颗粒度太小，预测准确度太低；一头是供应商，需求的不确定性高，市场价格波动大。这两头面临的不确定性都相当高，特别是对中长期需求，都不愿意承担高风险，就博弈；博弈的结果就是随行就市，以支付更高的采购价为代价。

总部的集中采购呢，则是典型的"空手套白狼"做法，要么让内部用户提前申报需求，承担预测风险；要么跟供应商谈定"一揽子"价，但没法保证需求量，让供应商承担市场价格波动的风险。风险太高，两者都不愿承担，集中采购就没法做。基于采购对象的计划特性，在总部或子公司层面做预测，适当承担可控制的库存风险，其实是整体风险和成本更低的做法。集中计划、集中储存，有助于真正实现集中采购。

对于该养殖企业来说，采取基层用户申报需求的做法，主要是因为担心库存风险和资金积压。他们的顾虑是，现在改为计划，库存金额会不会更高？答案是不一定。现在是申报需求，并不意味着没库存：基层用户深知，一旦需求落地了才申报需求，按时交付就可能成问题。那么，他们就适度提前申报，这其实是在做预测；因为预测颗粒度小，预测的准确度低，库存积压就是自然而然的了。不然，仓库里塞得满满的东西都是怎么来的？

在合适的层面做计划，提前备库，其实降低了整体的库存风险。同样，由于集中存储，整体库存的周转效率更高----一线申报需求，伴随的是分散存储，有些库存在信息系统里甚至都看不到，不同养殖场的库存很难调用，"货到地头死"，结果都是库存高企。计划得当，提高库存的齐套率，都有助于降低整体库存（想想看，一边在短缺，一边在爆仓，整体原材料的库存反倒更高，因为别的物料都来了）。至于建立计划机制后，用户体验更好，运营成本更低，则是库存以外的好处了。