当前位置: 首页 > news >正文

SupChains团队:订单生产型供应链销量预测建模案例分享(六)

Make-to-Order (MTO) / 按订单生产:指的是企业在收到客户订单后才开始生产产品。
“Make-to-Stock (MTS)” 模式:企业根据对未来市场需求的预测,提前生产产品并将其放入库存。

我容易讲上述名词跟D2C混淆:

  • Direct-to-Consumer (D2C) / 直接面向消费者:这是一种销售模式或商业模式。它指的是品牌或制造商直接向最终消费者销售产品,而不通过零售商、批发商等中间渠道。

SupChains技术团队的相关文章还有:

  • SupChains技术团队零售产品销量预测建模方案解析(一)
  • SupChains技术团队回答:模型准确率提高 10%,业务可以节省多少钱?(二)
  • SupChains团队: 衡量Forecast模型结果在供应链团队内的传递质量(三)
  • SupChains团队:供应链数据的异常特征管理指南(四)
  • SupChains技术团队:需求预测中减少使用分层次预测(五)

文章目录

  • 1 前言
    • 1.1 案例项目介绍
    • 1.2 数据收集与清洗
    • 1.3 主数据
    • 1.4 预购订单的处理方式
    • 1.5 业务驱动因素与模型特征
  • 2 特征处理
    • 2.1 预购订单的问题
    • 2.2 SupChains 处理预购订单
    • 2.3 季节性
  • 3 我们未做的工作
    • 3.1 异常值
    • 3.2 分层次
    • 3.3 外部驱动因素
    • 3.4 库存、促销、价格、销售量
  • 4 概念验证的交付
    • 4.1 交付周期
    • 4.2 修复周预测汇总到月预测出现的问题
    • 4.3 学习曲线:S&OP与预测质量
  • 5. 结果
    • 5.1 对比统计基准
    • 5.2 包含未来订单的附加价值
  • 6 结论与学习要点


1 前言

SupChains 为一家德国制造商提供了一个预测模型,该模型将未来订单作为关键需求驱动因素。与统计基准相比,SupChains 将预测误差降低了 20%。

本案例研究详细介绍了机器学习 (ML) 预测模型的端到端交付过程。我们首先设定了项目的范围和背景,然后解释了数据是如何收集、清洗和结构化的,包括对已确认未来订单的处理。我们还指出了模型设计中的关键排除项。最后,我们描述了概念验证的执行方式,并比较了统计基线模型和机器学习模型的结果。

我们的客户业务遍及欧洲、亚洲和美洲,拥有 1,800 多名员工,2024 年营收超过 4.5 亿欧元。该公司为各种工业应用(包括汽车、工业制造、医疗和家用电器)制造和供应定制产品。大多数产品都是按订单生产的,重点关注客户特定的解决方案

预测准确性不仅仅是一个技术指标,它直接影响供应链绩效。在按库存生产 (MTS) 环境中,更好的预测支持更好的供应链决策,减少库存和报废品,同时提高服务水平和整体销售额。
对于按订单生产 (MTO) 环境,更准确的预测增强了产能规划,从而缩短了客户的交货时间并提供了更可靠的可用承诺日期。

在 MTO 和 MTS 设置中,改进的预测还能促进与供应商的更好协作以及更有效的原材料库存管理。虽然确切的收益各不相同,但准确预测与供应链效率之间的联系已得到充分证实。

供应链效率

1.1 案例项目介绍

尽管我们的客户业务遍及全球,但本项目专注于欧洲区域市场,涉及约 500 家客户和 5,000 种独特产品(总计约 10,000 种产品-客户组合,因为大多数产品都是客户特定的)。本项目的目标不是优化成品库存,因为大多数产品都是按订单生产的。
相反,我们旨在利用长达 12 个月的预测来改进中期产能规划。尽管产能规划只需要产品级别预测(甚至家族级别预测),但客户要求提供产品-客户预测,以方便预测审查和丰富过程。由于大多数产品都是客户特定的,因此按产品-客户预测销售额与仅按产品预测粒度相比,并没有太大偏差。

一个具有挑战性的项目。 在项目启动时,由于最近实施了 ERP 系统,只有两年半的历史数据可用。有限的历史数据给训练预测模型带来了挑战,尤其是在捕捉季节性模式方面,这通常需要多个周期才能可靠地检测到。更复杂的是,预测任务异常复杂:我们旨在为 80% 客户特定的产品(平均每年仅销售 2.5 次)生成中长期预测。

1.2 数据收集与清洗

供应链经理有许多 KPI 来跟踪预测准确性,但很少(如果有的话)用来衡量输入数据质量。

收集、清洗和结构化数据是预测成功的基石。除了“垃圾进,垃圾出”的基本原则外,高质量的数据(包括需求和业务驱动因素)使模型能够更好地理解需求信号,最终生成更准确的预测。在 SupChains,我们将数据视为机器学习模型的洞察力来源。为了充分发挥其潜力,我们需要以正确的格式向它们提供正确的数据。这既需要业务知识,也需要数据工程专业知识。

此外,我们与客户的经验表明,大多数不稳定的预测都是由于输入不一致造成的
这就是为什么我们强调数据准备阶段:严格验证输入数据并整合关键业务驱动因素,确保我们的模型平稳可靠地运行。

1.3 主数据

收集连续的主数据和层次数据至关重要,主要原因有二:

  • 我们的机器学习预测引擎使用产品的层次信息(如品牌和产品线)作为输入来生成预测。
  • 正确的主数据允许标记产品状态(旧产品 -> 新产品)和发布日期。没有这些,预测引擎可能会被每个新产品搞糊涂。跟踪产品过渡是一项低投入、高回报的任务:在数据收集中,它是最容易实现的目标

1.4 预购订单的处理方式

在大多数按订单生产 (MTO) 业务中,客户会提前下订单,通常基于合同约定的交货时间。本项目也不例外:如下图所示,40% 的订单量至少提前 42 天下单。这些已确认的未来订单提供了对未来需求最有价值的洞察
在以下部分中,我们将讨论我们的模型如何利用这些订单来改进预测(以及我们的模型与常规方法有何不同)。

未来订单

1.5 业务驱动因素与模型特征

在构建机器学习模型时,我们的目标是使用尽可能少的特征,只选择那些真正能提高准确性的特征——少即是多。
在这个项目中,一个关键的重点是充分利用预购订单提供的信息,或缺乏这些信息的情况。


2 特征处理

2.1 预购订单的问题

本项目中最有价值的业务驱动因素是预购订单。与依赖固定规则的传统统计模型或 ERP 规划引擎不同,我们的方法将预购订单视为未来预期订单的预测信号。

为了说明在没有机器学习的系统中通常如何处理预测,请考虑规划引擎中使用的常见规则:

最终预测 = max(统计预测, 预购订单)

这是一个虚拟示例:

虚拟示例

这条规则确保已确认订单始终包含在预测中,但未能利用预购订单对未来预期需求的预测能力(例如,如果客户刚刚下了一个大订单,您可能希望提高您的长期预测)。

一些系统引入了预测消耗逻辑,将已确认订单重新分配到相邻的时期:

预测消耗逻辑

尽管这些方法代表了进步,但在以下几种关键情况下它们仍显不足:

  • 边缘情况:当已确认订单略低于统计预测时会发生什么?
  • 沉默即信号:如果没有下订单,我们是否应该降低预测,特别是当客户通常提前几周下订单时?
  • 远期信号:如果一个已确认订单在 10 周后出现,是否应该减少所有先前几周的预测以反映预期的客户不活跃?

此外,正如您将在“结果”部分看到的那样,仅向上调整预测(以反映已确认需求)而从未在预期订单缺失时降低预测,往往会导致正向偏差的预测。

2.2 SupChains 处理预购订单

SupChains的机器学习引擎将预购订单视为任何其他业务驱动因素:作为未来需求的预测信号。
模型从客户-产品级别的历史订购模式中学习,以确定基于预测范围可以合理预期的情况。

  • 当客户下了一个高于平常的订单时,模型可能会将其解释为积极趋势,并增加后期预测,同时可能减少附近几周的预测以避免重复计算。
  • 当未来订单量低于预期时,模型可能会降低预测,将其解释为需求可能疲软。

这种方法消除了硬编码规则,并允许预测根据真实的业务信号动态调整,无论是向上还是向下。

2.3 季节性

在模型开发时(2024 年第二季度),我们只能访问 30 个月的历史销售数据,其中几个月保留用于测试,这使得季节性估计本身就很困难。为了解决这个问题,我们专注于设计能够检测和预测相关季节性模式的模型输入(特征)。

季节性模式

尽管历史数据有限,但模型成功识别了捕捉季节性的特征。Y 轴值已匿名化。

3 我们未做的工作

3.1 异常值

在 SupChains,我们不使用 ML 或基于统计的技术来检测异常值。相反,我们根据业务规则(例如价格不一致或清仓)识别并排除错误交易,并解释由业务驱动因素(包括促销或价格变化)引起的大部分偏差。

分析按订单生产产品的需求可变性意义不大:每年只有几次销售,大多数观测值都会被统计学上标记为异常值。

3.2 分层次

此外,我们不使用分段或聚类技术。正如本文所解释的,我们不认为它们能为需求预测模型增加价值。我们最近的预测竞赛 VN1 也表明,很少有顶尖竞争者使用分段或异常值检测技术,证实了这些做法的价值有限(如果有的话)。

3.3 外部驱动因素

对于本项目,我们没有使用任何外部驱动因素(例如经济指标),因为据我们所知,我们不了解有任何项目成功地使用外部驱动因素来丰富预测。通常,内部驱动因素(例如促销、已确认的未来订单、定价和销售量)比外部经济指标更能洞察未来需求。

3.4 库存、促销、价格、销售量

鉴于按订单生产 (MTO) 的背景,本项目不需要库存数据。我们使用客户最初要求的发货日期来识别无约束需求。促销也被排除在外,因为客户不进行促销活动。由于大多数产品都是为单个客户量身定制的,因此价格敏感性分析在很大程度上也是无关紧要的。

对于 MTS 产品,捕捉无约束需求通常是任何需求预测项目中最具挑战性的部分。这就是为什么我们投入时间收集和清洗库存数据,以审查库存短缺的时期。

4 概念验证的交付

4.1 交付周期

时间线

概念验证 (POC) 始于为期三个月的数据清洗阶段,由 SupChains 和客户之间的每周研讨会提供支持。我们专注于数据质量、业务背景和预测范围(即要包含哪些客户-产品组合)。

在此之后,我们对预测引擎进行了几次试运行,以验证预测范围并确认产品-客户对的纳入标准。

随后是为期六个月的 POC 阶段,在此期间 SupChains 每月提供预测,并与客户举行联合审查会议。这些审查侧重于评估准确性、解释模型行为以及完善模型输入和输出。具体来说,我们完善了项目范围(包括或排除特定产品或产品家族),讨论了明显的预测误差,并就预测周期和粒度达成了一致。

4.2 修复周预测汇总到月预测出现的问题

我们最初创建了一个生成每周预测的预测模型。
在测试阶段,我们意识到客户的规划系统使用周一作为截止日期将周聚合到月份。这意味着,例如,一个从 2025 年 3 月 31 日星期一开始的预测将完全分配给 3 月——尽管该周的大部分时间都在 4 月。这与我们这边已确认订单的结构不符,导致分配错位并降低了准确性。

我们调整了每周结构以与客户的聚合逻辑保持一致。然而,由于设置仍然复杂且难以管理,我们还测试了一个更简单的月度模型。令人惊讶的是,这不仅降低了数据复杂性,还将准确性提高了 5%。

4.3 学习曲线:S&OP与预测质量

最初,我们客户的 S&OP 流程主要关注 6 到 18 个月内的总销量预测。他们使用整体偏差来评估预测质量。当我们开始项目的评估阶段时,我们也借此机会改进了他们监控预测质量的方式,从只关注偏差转变为同时考虑偏差和绝对误差。

跟踪绝对误差告诉我们预测误差的_大小_——预测与实际需求之间的偏差有多大——无论方向如何。另一方面,偏差揭示了误差的_方向_,帮助我们了解我们是否持续高估或低估需求。同时跟踪两者使我们能够更清晰地评估绩效。

5. 结果

5.1 对比统计基准

在我们评估预测的方法核心中,是 预测附加值 (FVA) 框架:我们不孤立地衡量模型的准确性,而是将其与各种基准进行比较。我们提倡将跟踪 FVA 作为供应链领导者应该实施的第一实践

为了评估我们的预测模型,我们创建了从 2024 年 12 月到 2025 年 3 月的样本外预测,并使用 2025 年 1 月到 4 月的实际订单对其进行评估。我们比较了六种不同的方法:

  • 12 个月移动平均 (MA12),以及一个在进行预测时已确认订单的增强版本。
  • 主要依赖指数平滑模型的统计引擎 (Statistical),以及一个使用已确认订单的增强版本。
  • 我们最初的每周 ML 模型 (Weekly ML)
  • 我们最终的每月 ML 模型 (Monthly ML)
    在这里插入图片描述

为了衡量预测质量,我们不建议仅衡量准确性(使用 MAPE、MAE 或 WMAPE 等指标)。相反,我们同时跟踪准确性(使用 MAE)和偏差。为此,我们使用分数(MAE + |偏差|) 。

通过将分数从 83.1%(基准:MA12*)降低到 65.2%,SupChains 实现了 22% 的附加值。

正如 数据科学在供应链预测中的应用 中所解释的,单独跟踪准确性将机械地促进低估预测。
我们将附加值计算为模型相对于另一个模型的百分比分数降低。在这种情况下,我们有 21.5% = 1 – 65.2%/83.1%。

我们还测量了模型的可变性
也就是说,预测(来自同一模型)从一个月到下一个月变化了多少。较低的值表示从一次迭代到下一次迭代的稳定输出。
一如既往,简单的 12 个月移动平均值具有最高的稳定性,其次是我们的月度模型(“Monthly ML”),它比任何其他模型提供更准确、偏差更小、更稳定的预测。

从技术上讲,为了计算可变性,我们取两个连续预测集的重叠周期,并计算通常的分数指标(分数 = MAE + |偏差|),将一个预测视为实际值,另一个视为预测。然后我们通过两个预测的平均值(仅保留重叠周期)来缩放该指标。

模型可变性

我们使用 LightGBM 作为模型的核心算法。根据我们的经验和国际预测竞赛,它仍然是供应链预测中最有效的工具之一。然而,成功并非仅来自算法本身。关键的区别在于数据如何进行预处理、转换和选择。在 SupChains,我们强烈强调_特征工程_(即,将原始数据转换为机器学习模型的有意义输入),利用领域知识为我们的模型构建有意义的输入。

5.2 包含未来订单的附加价值

为了评估将已确认的未来订单嵌入到我们模型中的价值,我们运行了另一个版本的月度模型,其中不包含任何与未来订单相关的输入(参见下面的 ML (无订单))。
至于其他模型,我们创建了一个在预测生成之后用预购订单丰富增强版本。我们的主模型(使用预购订单相关特征)比后处理的无未来订单版本的分数低 25%。
在这里插入图片描述

用未来订单增强的 12 个月移动平均和统计引擎导致误差分数下降 25% 到 30%,但代价是预测过高。

总而言之,使用简单的后处理规则来包含未来订单将分数降低了 25% 到 30%,而将未来订单直接输入到我们的机器学习模型中则带来了额外的 25% 降低。

笔者来大概总结一下,这段话提到了三个不同的改进模型及其效果,具体区别和效果如下:

模型名称/类型特点效果(误差分数降低)备注
无未来订单输入的月度模型 (ML No Orders)不使用任何未来订单信息,仅基于历史数据进行预测作为基准模型误差较高
后处理版本( 版本)*先生成预测,再用简单的后处理规则将已确认的未来订单信息加入预测结果误差分数降低25%到30%通过后处理改善预测准确性,但仍有局限
主模型(直接输入未来订单特征)在机器学习模型中直接使用与已确认订单相关的特征进行训练和预测误差分数比后处理版本再降低25%效果最好,误差最低
统计引擎+12个月移动平均+未来订单信息将未来订单信息加入统计模型和12个月移动平均计算中误差分数降低25%到30%提高准确性,但出现过度预测问题
  • 不使用未来订单信息的模型效果最差。
  • 简单后处理未来订单信息能显著降低误差(25%-30%)。
  • 直接将未来订单特征输入机器学习模型,误差进一步降低了25%,效果最佳。
  • 统计模型结合未来订单也能降低误差,但会带来过度预测风险。

6 结论与学习要点

本项目展示了在按订单生产 (MTO) 环境中使用机器学习 (ML) 的价值。与所有机器学习模型一样,收益并非仅来自算法(简单地使用机器学习模型不会带来太多价值)。关键的成功因素在于数据如何结构化、清洗并输入到 ML 引擎中,尤其是_已确认的未来订单_,事实证明,当引擎正确使用时,它能带来额外的 25% 附加值。
使用后处理规则将已确认的未来订单输入到预测中有帮助,但将未来订单直接作为特征嵌入到模型中会带来显著更好的结果。

整个概念验证耗时不到一年(包括 3 个月的数据清洗、1 个月的模型创建和 6 个月的实时测试)。在实时测试阶段,我们不得不两次改进我们的方法,首先意识到从每周到每月预测的转换不起作用,然后发现每月预测比每周预测提供更准确和稳定的结果。

本项目的一个关键成功因素是能够为中长期规划提供无偏预测。包含已确认未来订单的简单后处理规则往往会推高预测,机械地导致系统性高估。相比之下,我们的模型利用这些输入向上和向下调整预测,从而产生更准确、稳定和偏差更小的预测。

http://www.lryc.cn/news/613519.html

相关文章:

  • 容器之王--Docker的部署及基本操作演练
  • vLLM:彻底改变大型语言模型推理延迟和吞吐量
  • Aurora MySQL 8.0 性能分析账号创建完整指南
  • 神经网络入门指南:从零理解 PyTorch 的核心思想
  • 跨境电商增长突围:多维变局下的战略重构与技术赋能
  • 从“数字网格”到“空中交警” :星图低空云如何重构低空管理?
  • 鸿蒙 - 分享功能
  • MySql MVCC的原理总结
  • 软件加密工具-DSProtector使用说明
  • 2025年华数杯C题超详细解题思路
  • 旅游mcp配置(1)
  • 多场景两阶段分布式鲁棒优化模型、数据驱动的综合能源系统
  • pybind11 的应用
  • C语言feof函数详解:文件末尾检测的实用工具
  • 【华为机试】113. 路径总和 II
  • 计算机网络1-5:计算机网络的性能指标
  • CSS--:root指定变量,其他元素引用
  • [安卓按键精灵开发工具]本地数据库的初步学习
  • 剑指offer第2版——面试题1:赋值运算符函数
  • CPTS Remote 复现
  • react-router/react-router-dom
  • 深度学习中主要库的使用:(一)pandas,读取 excel 文件,支持主流的 .xlsx/.xls 格式
  • 房产证识别在房产行业的技术实现及应用原理
  • 超高车辆如何影响城市立交隧道安全?预警系统如何应对?
  • 网络基础概念
  • 基于Qt的Live2D模型显示以及控制
  • ora-01658 无法为表空间 users中的段创建initial区
  • RocketMQ架构解析
  • 遥感卫星领域的AI应用
  • Day03 学习git