续前篇，讲完基于积单做预测的逻辑后，下面我们继续深入，重点讨论基于积单的预测提报，也就是预测本身。
预测提报重点包括需求收集、计划生成、决策审批。
首先，是需求收集，它是基于积单池，下达预测任务，即基于积单池中要货计划的节奏明确。在计划流暴问过程中，后端有要求销售明确积单下单节奏的需求，就在此处。之前不理解，以为明确积单的要货节奏，是一件很简单的事情啊，不就在积单中维护一个预计下单和预计要货时间吗？实则不然。
市场对于预测上报的随意性大，甚至不太重视，觉得是无用之功。所以，它的有效性和准确性很大。应该怎么做呢？
我们要用工具解决预测有效性和准确性的问题，要在此处建立规则，对市场收集的需求要点检。
比如预测任务线上推动，之前每月15日上报，为了确保末端的灵活，可以规定每周1-15日为预测区间，允许业务多次上报。其次设定指标牵引，比如预测准确率，饱和度等，对于预测准确的业务予以奖励。在此基础上，细化预测维度（系统植入），将预测细化至型号、规格。
怎么对业务上报的需求进行点检呢？点检的目的主要是确保预测的准确性，比如要求预测到产品型号、要货数量，明确下单时间、要货时间，是否满足标交。
再次就预测的成熟度进行评估，比如是否签订合同，是否有标机发布，长线料是否有，客供料是否有。总而言之，就是对需求来源、客户性质、需求方案几个维度建立预测准入机制。
这是标准流程，业务总是复杂、灵活多变的。理论上是有积单才允许预测。当客户要货紧急，且没有入积单池时，应该建立特殊、紧急流程，增加无积单预测审批流程。
其次，是预测计划生成。计划的生成，不单单是创建预测计划，不单单是明确预计下单时间和要货时间，还应对后端产能，订单方案进行评估，这块工作，特别容易被忽略。
1、客户方案评估：预测的价值不在于预测本身，而在于其创造的价值，可以驱动后端前置动作。预测需求收集只是第一步，下一步是要结合预测进行不同的管理动作。常见的比如生成备料方案，特别注意，不是所有预测都要生成备料方案。
因此，预测后是否生成备料方案，也需要一套成熟的模型进行评估。除了对时间的评估外，重点还体现在对数量、方案、可靠性进行评估：
①数量评估：识别预测数量的可靠性。首先对预测来源进行评估（来自合同、配送单，还是客户书面通知，还是中心自我评估）；其次是预测数量与中标未下数的占比评估（可分为几个档次，比例越小则数量准确度越高，越不易造成呆滞），最后是对要货周期的评估，要货周期越短则得分越高。
在此基础上，对三者得分进行求和，当得分大于XX分以上备料（比如70%），同样，可以设置几维度，当得分处于某一阶段可以备对应比例的料（例得分80-90之间，备60%；得分90以上，备70%）。
②方案评估：预测方案成熟度评估。核心包括技术协议（标机方案、投标方案还是新方案）；样机测试结果（未送测、测试中还是通过）；历史供货（有还是无）；通用性（区域通用、省内通用还是专用）。通过以上几维度建立评价规则，同上，当得分处于某一阶段，确定不同比例的备货量。
③可靠性评估：主要包括物料采购周期、需求紧急度，模具瓶颈、资金保障度等维度。
二、产能评估：对客户需求评估后，还要确认后方是否有产能可以容纳客户订单。满足客户要求是LTC的终极追求。
因此，要求后端要将产能开放给前端市场，怎么做呢？这里可以参考芯片流建立一张管控表。按产品大类，将产量、预测量、在制单、缺口等信息集于一张表可视。当预测+在制单＜月产量，则还可以继续预测；当预测+在制单＞月产量时，新增预测计划需均衡，后移。确保需求不大于产能（可设置规则，不超过最大产能的20%）。我想，这应该也是18年表交期流程产能占坑的核心思想。
最后，是决策审批，即对评估后的预测进行系统报批，入预测池，这里不再赘述。
由此可见，一个预测计划的发布，是非同小可的事情，销售总是讲预测做不准，之前觉得很对。但是深挖下来，预测做不准只是一个伪命题。我们没有从根本上去着手解决这个问题。对于LTC来说，预测是源头，好的预测是前端防杂的基础。
网友评论