面向 IT 决策者的落地笔记，只谈工程约束，不谈厂商。

短保品的特殊约束

乳品渠道的核心矛盾是"短保"：货架生命以天计，过期即报废，断货即丢客。这决定了管理目标与常温品类完全不同——不是"卖出去"，而是"天天刚刚好"：库存压到贴着保质期走，配送跟上每日波动的需求，冰柜资产不空转。库存、配送、资产三件事必须一起算，任何一件单独优化都会挤坏另外两件。

对 IT 规划者来说，这意味着系统选型时不能只看"有没有经销商管理功能"，而要看三个模块是否共用同一套实时数据底座。DMS 在这里的角色是协同底座：经销商的进销存、终端的销售、车辆的载货，全部落在一套数据里，后面的预测和调度才有输入。

需求预测的数据流

库存高、报损多的根子在预测靠经验。业务员的"明天多送点"凭的是手感，换成系统后要老老实实回答：预测的输入是什么、多久迭代一次。

工程要件：

• DMS 汇总真实销售：按终端、按品项、按天，这是预测的原料。注意是"卖掉的"不是"送到的"，两者差异就是渠道压货
• 预测输入维度：历史销量、气温、节假日与开学季、促销日历、周边竞品动作
• 输出三件套：每终端每品的安全库存线、补货阈值、临期品跨店调剂建议

典型的失败案例：预测模型只吃"上周销量"一个变量，忽略气温——升温那一周低温奶全线断货，降温那一周报损翻倍。喂错数据，模型比人还轴。所以预测上线后的迭代机制比算法本身重要：每周对照预测与实际，偏差超阈值的终端自动进入人工复核清单，同时把偏差原因回流成新的特征。

DSD 车销一体化

鲜奶日配天然适配 DSD 模式：车辆带着库存到终端，现场下单、交货、收款，一天跑一轮甚至两轮。对应三个系统模块：

• 路线优化：按终端位置、补货量、时间窗约束排线，目标是减少空驶和迟到。这里要接受"足够好"而非"全局最优"——终端下单在送前一两小时还在变，算法要在几分钟内给出可行解
• 车载进销存：车上每个品项实时扣减，解决"以为有货实际没"的尴尬。工程难点在弱网：郊区路段离线时要本地记账、回网后按时间戳合并，冲突以车辆实盘为准
• 车销账款：现场收款自动核销应收，日结时现金、电子收款与系统账三方对平

DSD 与仓库补货两种模式并存是常态，系统里要允许同一终端两种履约方式切换，切换点就是库存与在途数据的实时可见性。

冰柜费用闭环

冰柜是乳品的重要资产，但投放常常"只出不看"：投出去之后没人回答这台冰柜还在不在、亮不亮、卖多少。费用黑洞就在这里。

TPM 的做法是把每台冰柜当项目管理：投放登记（编号、门店、责任人）→ 陈列核验（业务员拍照，图像识别判排面占比、有没有断货格、是不是只放竞品）→ 产出计算（每台冰柜的本品周动销、排面占比、单柜产出）→ 到期续投决策有数据依据。

费用治理靠"产出可量化"堵住：一台冰柜连续数周动销趋零，要么换位置要么回收，这笔账过去算不了，现在逐台可算。

主数据与落地要点

统一主数据（经销商、终端、产品、车辆、冰柜）是全程前提——DMS 真实销售是预测的输入，DSD 与 TPM 共用库存与资产主数据，才能做到"货剩多少、车跑哪、冰柜值不值"一盘棋。

落地节奏上，中小乳企先打通 DMS 加日配协同，把真实销售数据攒三个月以上，再叠冰柜 TPM 与 AI 补货；预测模型从简单规则起步并不丢人，数据地基打牢后升级模型是顺路的事，反过来则每一步都在沙地上盖楼。