供应链库存优化

业务背景

制造业库存管理贯穿整条供应链：原材料采购 → 在制品 → 成品仓 → 区域配送中心 → 销售终端。每个节点都需要在缺货断供和积压占用资金之间寻找平衡。

随着全球供应链复杂度的提升——多仓布局、多 SKU 管理、需求季节性波动、供应商交期不稳定——传统依赖 ERP/MRP 系统的静态安全库存模型已无法应对现实挑战。

核心数据来源：

WMS（仓库管理系统） → supply_chain_inventory 每日库存快照、安全库存阈值 OMS（订单管理系统） → supply_chain_demand 历史销量、每日出货量 ERP/MRP → supply_chain_inventory 字段 补货周期、BOM 用料（静态参数） 供应商系统 → supply_chain_supplier_lead_time 实时交期、延期通知

这些数据分散在多个系统，难以实时汇聚分析。采购和供应链团队依赖人工汇报和周报，无法在库存告急的第一时间做出响应。

行业痛点

1. 静态安全库存，无法适应需求波动

传统 MRP 系统的安全库存是一次性设定的静态值，不随季节、促销、市场变化自动调整。库存周转天数行业均值达 6090 天，滞销品资金占用率约 1520%。

2. 补货决策滞后，依赖人工判断

采购员面对数百个 SKU，靠经验和 Excel 做补货判断。需求突然上涨时，等报表出来、会议讨论、审批下单，往往已经缺货数天，还要额外支付加急运费。

3. 多仓库存不均衡，调拨决策困难

同一 SKU 北京仓积压、上海仓缺货的情况频繁出现，但跨仓调拨涉及物流成本、库龄优先级、在途追踪，人工决策效率低，往往宁可重新补货也不调拨。

4. 需求预测精度低，无法感知异常

传统移动平均法无法识别节假日效应、竞品上市、促销拉动等外部因素，需求异常只能事后复盘。

5. 供应商交期波动未纳入补货决策

ERP 中

lead_time_days

数据来源详解

WMS — 库存快照（→

supply_chain_inventory

supply_chain_inventory

）

COPY INTO

ERP 中的补货参数（

lead_time_days

reorder_point

OMS — 历史需求（→

supply_chain_demand

supply_chain_demand

）

需求数据天数不足 7 天时，

urgency

供应商系统 — 实时交期（→

supply_chain_supplier_lead_time

supply_chain_supplier_lead_time

）

AI_EXTRACT

-- 用 AI_EXTRACT 从供应商通知中自动提取新交期 SELECT AI_EXTRACT( 'cz_bailian:qwen3.5-plus', supplier_notice_text, JSON '{"product_id": "物料编号", "new_lead_time_days": "新的预计交货天数（整数）", "reason": "延期原因"}' ) AS extracted_info FROM supplier_notices WHERE notice_date >= CURRENT_DATE - INTERVAL 7 DAY;

supply_chain_replenishment_plan

lead_time_source

基于 ClickZetta Lakehouse 的解决方案

多系统数据汇入 Lakehouse 后，通过 Dynamic Table 增量计算 + 窗口函数多时间窗口分析 + 供应商实时交期联动，构建一套自动刷新的补货决策系统。

整体架构

预览

[WMS 库存快照] [OMS 历史需求] [供应商实时交期] │ │ │ ▼ ▼ ▼ supply_chain_inventory supply_chain_demand supply_chain_supplier_lead_time （含ERP静态参数） change_tracking=true source: SRM/EDI/AI_EXTRACT │ │ │ └──────────┬──────────┘ │ ▼ │ supply_chain_daily_demand_avg（DT，1h） │ 近30天/近7天日均需求 · 波动异常标记 │ │ │ ▼ │ supply_chain_replenishment_plan（DT，1h）───────┘ 动态 lead_time · urgency · suggested_order 数据不足保护 · 补货成本估算 │ ├──► MERGE INTO supply_chain_replenishment（幂等存档） ├──► 紧急告警（Studio Task → 钉钉/企微） ├──► 采购系统对接（自动生成 PO） └──► 库存健康度报表

核心计算逻辑

-- 实际使用交期（优先供应商实时，无则回退ERP静态） effective_lead_time = COALESCE(supplier.lead_time_days, erp.lead_time_days) -- 库存可用天数 days_of_supply = stock_qty / avg_daily_demand（近30天） -- urgency 判断（含数据质量保护） demand_data_days < 7 → 数据不足（不触发补货） days_of_supply < effective_lead_time → 紧急 days_of_supply < effective_lead_time × 1.5 → 正常 否则 → 充足 -- 建议补货量（目标：覆盖补货周期 + 7 天缓冲） suggested_order = MAX((effective_lead_time + 7) × avg_daily_demand − stock_qty, 0) -- 需求异常检测（近7天 vs 近30天偏差 > 30%） demand_anomaly_flag = |avg_7d - avg_30d| / avg_30d > 0.3

方案技术优势

1. 供应商实时交期动态覆盖 ERP 静态值

这是本方案区别于传统 MRP 的核心：

supply_chain_supplier_lead_time

supply_chain_replenishment_plan

effective_lead_time

2. 多时间窗口检测需求趋势，AI 解读异常原因

avg_daily_demand -- 近30天均值（基准） avg_7d_demand -- 近7天均值（短期趋势） demand_anomaly_flag = TRUE 时，触发 AI_COMPLETE 分析原因：促销/节假日/竞品/季节

3. 数据不足保护，避免以极少天数均值驱动大额补货

当

demand_data_days < 7

4. MERGE INTO 幂等存档，历史补货计划可追溯

每小时自动归档一次计算结果，支持 Time Travel 回溯任意时间点的补货建议，辅助采购决策复盘和责任追溯。

5. 纯 SQL，与现有 ERP/WMS 低耦合

只需各系统定期推送数据到 Lakehouse，不改造现有系统。补货建议通过 Studio Task 推送给采购系统，上线周期以天计而不是以月计。

客户价值

供应链/采购团队：补货优先级实时可见，紧急 SKU 自动告警，不再依赖每周报表才发现缺货。

库存管理团队：

days_of_supply

财务团队：

est_replenishment_cost

IT/数字化团队：无需额外搭建 Python 预测服务或专项库存系统，Lakehouse 一站整合，统一运维。

方案文件

setup.sql

test_data.sql

pipeline.sql

teardown.sql

uat 验证结果

全量补货计划输出

关键验证点

• 供应商实时交期生效 ✅：WH_SH 显示器

  lead_time_days

  lead_time_days
  由 AI_EXTRACT 从供应商通知中提取为 18 天（ERP 静态值 14 天），延期 4 天直接导致 urgency 标记为"紧急"，建议补货量 37 件 · ¥35,150
• COALESCE 回退逻辑正确 ✅：有供应商实时交期的用实时值，无记录的回退 ERP 静态值，

  lead_time_source

  lead_time_source
  完整记录来源（SRM/EDI/AI_EXTRACT/ERP静态值）
• WH_BJ 键盘延期但不紧急 ✅：供应商延期 3 天（EDI，10 天），但库存可用 24 天，

  urgency=充足

  urgency=充足
  ，说明

  COALESCE

  COALESCE
  + urgency 计算正确区分了"延期但不危险"和"延期且危险"
• MERGE INTO 幂等存档 ✅：6 条记录成功写入

  supply_chain_replenishment

  supply_chain_replenishment
• 数据不足保护未触发 ✅：所有 SKU 需求天数 ≥ 7 天，无"数据不足"误触发
• 需求异常检测未触发 ✅：14 天测试数据的 7d/30d 波动均未超过 30%（符合设计）

供应商交期影响分析

# 1. 建表 run setup.sql # 2. 写入测试数据 run test_data.sql # 3. 创建 Dynamic Table 链路 run pipeline.sql # 4. 验证 -- 紧急补货清单 SELECT warehouse_id, product_name, days_of_supply, effective_lead_time, lead_time_source, suggested_order, est_replenishment_cost FROM supply_chain_replenishment_plan WHERE urgency = '紧急' ORDER BY days_of_supply; -- 需求异常 SKU SELECT warehouse_id, product_name, avg_daily_demand, avg_7d_demand FROM supply_chain_replenishment_plan WHERE demand_anomaly_flag = TRUE; # 5. 清理（可选） run teardown.sql

核心查询

-- 紧急补货清单（含实时交期来源和补货成本） SELECT warehouse_id, product_name, region, current_stock, avg_daily_demand, days_of_supply, effective_lead_time, lead_time_source, suggested_order, est_replenishment_cost FROM supply_chain_replenishment_plan WHERE urgency = '紧急' ORDER BY days_of_supply ASC; -- 各仓库存健康度大盘 SELECT warehouse_id, region, COUNT(*) AS sku_count, SUM(CASE WHEN urgency = '紧急' THEN 1 ELSE 0 END) AS urgent_count, SUM(CASE WHEN urgency = '正常' THEN 1 ELSE 0 END) AS normal_count, SUM(CASE WHEN urgency = '充足' THEN 1 ELSE 0 END) AS healthy_count, SUM(CASE WHEN urgency = '数据不足' THEN 1 ELSE 0 END) AS data_insufficient, ROUND(AVG(days_of_supply), 1) AS avg_days_of_supply FROM supply_chain_replenishment_plan GROUP BY warehouse_id, region ORDER BY urgent_count DESC; -- 供应商延期影响分析（对比实时交期 vs ERP静态值） SELECT p.product_name, p.warehouse_id, i.lead_time_days AS erp_lead_time, p.effective_lead_time AS actual_lead_time, p.effective_lead_time - i.lead_time_days AS delay_days, p.lead_time_source, p.urgency FROM supply_chain_replenishment_plan p JOIN supply_chain_inventory i ON p.warehouse_id = i.warehouse_id AND p.product_id = i.product_id AND i.snapshot_date = (SELECT MAX(snapshot_date) FROM supply_chain_inventory) WHERE p.lead_time_source != 'ERP静态值' ORDER BY delay_days DESC;

注意事项

补货参数

• effective_lead_time

  effective_lead_time
  优先使用

  supply_chain_supplier_lead_time

  supply_chain_supplier_lead_time
  最新记录，无记录时回退 ERP 静态值，

  lead_time_source

  lead_time_source
  字段标注来源，方便审计
• 安全库存缓冲天数（+7 天）当前为硬编码，生产环境建议提取为参数表，按 ABC 分类差异化配置

数据质量

• 需求数据天数不足 7 天时 urgency 标记为"数据不足"，不触发补货建议
• 库存快照每日写入一次，

  WHERE snapshot_date = MAX(snapshot_date)

  WHERE snapshot_date = MAX(snapshot_date)
  确保只用最新快照；同一天多次写入时需注意时间戳精度

• demand_anomaly_flag

  demand_anomaly_flag
  需同时有 7 天和 30 天数据且均非 NULL 才触发（已做保护），新上架 SKU 数据不足 30 天时不会误报异常

供应商交期（uat 验证确认）

• supply_chain_supplier_lead_time

  supply_chain_supplier_lead_time
  按

  (warehouse_id, product_id)

  (warehouse_id, product_id)
  取最新

  effective_date

  effective_date
  一条记录，多次更新只用最新值
• AI_EXTRACT 解析供应商通知后，需将结果写入

  supply_chain_supplier_lead_time

  supply_chain_supplier_lead_time
  表才能生效；写入后 Dynamic Table 下次 REFRESH 自动使用新交期
• 供应商延期"库存充足"和"库存危险"会正确区分：WH_BJ 键盘延期 3 天但库存可用 24 天，仍为"充足"（uat 验证确认）

Dynamic Table

• 分区表 PRIMARY KEY 必须包含分区键（

  snapshot_date

  snapshot_date
  、

  demand_date

  demand_date
  、

  effective_date

  effective_date
  ）
• Dynamic Table 不支持 DML，历史数据修正只能在源表操作
• teardown 顺序：先 DROP Dynamic Table，再 DROP 普通表，否则报依赖错误

AI 函数（扩展层）

• Lakehouse 目前无原生时序预测函数（

  SHOW FUNCTIONS LIKE '%FORECAST%'

  SHOW FUNCTIONS LIKE '%FORECAST%'
  返回 0 行，uat 实测确认）

• AI_COMPLETE

  AI_COMPLETE
  适合需求异常原因解读，精确数值预测可通过 External Function 部署 Prophet/ARIMA

扩展方向

• 需求异常 AI 解读：

  demand_anomaly_flag=TRUE

  demand_anomaly_flag=TRUE
  时触发

  AI_COMPLETE

  AI_COMPLETE
  分析原因（促销/节假日/竞品）
• ABC 库存分类：用

  AI_CLASSIFY

  AI_CLASSIFY
  对 SKU 自动分类，A 类设更严的缓冲天数，C 类可放宽
• 多仓调拨优化：同 SKU "充足仓 → 紧急仓" 调拨建议，降低重复补货成本
• 与缺陷检测联动（02-defect-detection-ai）：高缺陷率批次触发原材料缺货风险预警
• SPC 统计过程控制：用 Dynamic Table 计算缺货率控制限，产线断供自动预警

相关文档

AI 函数

Dynamic Table

change_tracking

窗口函数

MERGE INTO

Time Travel

Studio 任务