AI+BI重构餐饮供应链：从拍脑袋到算出来的数字

三个月前我在仓库翻出一整箱已经过期的冻虾仁而采购记录显示这箱货五天前刚补进来。这不是第一次了。后厨的损耗账和采购账对不上店长按经验下单供应商按固定车次送货总部靠Excel日报看库存——门店只有三五家时这种粗放管理勉强能转一旦铺开到四五十家门店问题就会集中爆发。我当时正在负责一个连锁餐饮供应链数字化项目目标很明确用AIBI重构餐饮供应链的决策链路把“拍脑袋”变成“算出来的数字”。这篇文章是这个项目的完整复盘包括技术路线、落地顺序、实施效果和踩过的坑希望能给正在做餐饮数字化或供应链优化的同行一点参考。1. 餐饮供应链的“隐形浪费”从哪里来我看到的真实瓶颈1.1 损耗和缺货同时发生钱到底漏在哪门店A和门店B营业额几乎一样A的周订货量比B高出15%可A每到晚市前还是会喊缺货。这是我在项目一开始碰到的现象。表面看很矛盾多进了货怎么还不够卖后来翻数据才发现A店的某款牛肉片账面库存有40份实际冷柜里只有12份中间28份被后厨超量使用、报损不及时根本没有体现在单据里。这就是餐饮供应链最典型的粗放状态账面有货实际没货采购继续按账面补门店继续按实际缺。损耗和缺货同时存在不是管理者的运气问题而是决策链路出了问题——下订单的人靠感觉补货的人靠报表门店和仓库的数据在我这里对不上。粗放管理带来的成本比大多数经营者想得高。生鲜食材损耗率经常能到8%到10%紧急加单一次配送成本比正常计划配送贵20%到30%库存在货架上多躺一天资金占用和过期风险都会上升。最要命的是这些问题分散在几十家门店和几百个SKU里靠人盯根本盯不过来。1.2 传统ERP和Excel为什么救不了餐饮供应链很多团队用ERP用得很重但ERP在餐饮里更多扮演记录者角色。它记录订单、出入库、盘点结果对历史事实很忠诚却不会告诉你明天应该进多少货。Excel同样如此数据表是手工更新的今天下午的门店库存要等明天晚上才能汇总完等报表出来晚市早开完了。餐饮供应链真正缺的不是数据而是处理数据的两个能力把现状看清的BI和把未来算出来的AI。BI负责回答“现在怎么样”比如哪家店快缺货、哪个仓库周转太慢、哪条配送线路成本异常AI负责回答“接下来怎么办”比如明天该备多少货、这个月该向供应商下几次订单、安全库存该定多少。我自己比较喜欢的比喻是BI是后视镜让你看清怎么开过来的AI是导航告诉你接下来走哪条路。餐饮供应链要做的是把两样都接上而且顺序不能反——先装后视镜再开导航。2. 这次改造的技术路线数据、BI、AI各干各的活2.1 数据层把门店、仓库、供应商接进同一张网项目启动第一步不是选算法而是梳理数据链路。我们接进了门店POS销售流水、库存盘点记录、订货单、收货单、供应商电子对账单另外还把外卖平台销量和天气数据拉了进来。每个门店每两个小时回传一次销售流水日终再全量同步一遍盘点数据。同步频率看起来不起眼实际上它是后面所有分析和预测的生命线。SKU主数据是另一个大坑。同一款冻虾仁后厨按“份”出菜仓库按“箱”入库财务按“公斤”对账同一个食材在不同供应商那里的编码还不一样。我们花了整整两周建立主数据表把SKU统一到最小库存单位再把销售单位、采购单位、库存单位做成量纲换算映射1箱等于24包1份等于150克1公斤做多少份全都写清楚。这件事做完BI和AI才有可靠的地基。数据层的第四个关键是数据质量规则。我们定了几条硬性校验盘点数不能为负、订货量不能超过历史峰值的三倍、缺失唯一标识的订单直接拦截。当时还有人觉得规则太多太麻烦后来事实证明这些规则帮我们挡掉了大量脏数据。2.2 BI层让问题在发生之前被看见BI看板刚上线时我们给自己定义了四个核心指标库存周转天数、缺货率、损耗率、理论库存与实际库存差异率。库存周转天数反映资金占用缺货率反映服务水平损耗率反映管理精度理论库存与实际差异率则直接暴露门店作业规范问题。具体计算不复杂库存周转天数等于当前库存量除以近7天日均销量缺货率等于触发缺货的SKU数除以在售SKU总数损耗率等于报损金额除以领用金额。这些指标在Excel里也能算但BI把它变成了自动更新的、可以下钻的看板每个仓库和门店都能看到自己对应的那一行。系统每天凌晨跑出异常清单把低库存、滞销库存、超期风险自动推送给对应负责人。供应链例会也不再是拿着打印件你猜我猜而是对着同一组数字复盘。这一步看似基础实际上对后期AI上线起了决定性作用——团队开始从数据里形成共识而不是从各自的直觉里争论。2.3 AI层预测和补货优化不是玄学AI部分我们主要解决两个问题明天或者未来几天卖多少以及该备多少货、什么时候补。需求预测采用的是时间序列模型加特征回归的组合方案。时间特征包括星期几、月初月末、节假日、天气、外卖活动力度模型输出每个SKU每天的销量预测和置信区间。考虑到门店数量多、品类杂我们按品类先做聚类再按门店单独建模。对前置期在1到2天的生鲜食材重点预测未来3天对冻品和长保质期食品预测未来7天。这个设计兼顾了生鲜的新鲜度和冻品的采购周期。补货量的算法逻辑也很直白补货量 RoundUp(预测日销量 × 补货周期 安全库存 - 当前可用库存 - 在途库存, 包装倍数)安全库存用经典公式安全库存 Z × σ × sqrt(L)。Z是服务水平对应的概率系数σ是日销量标准差L是供应商前置期天数。举例来说95%服务水平对应Z1.65某店某菜品日销量标准差是10份供应商前置期2天安全库存就是1.65×10×1.414约23份。公式不大但系统每天要对几百个SKU算一遍服务水平设高一点库存就会明显涨一截。除了补货量AI还优化了补货频率和配送计划把同一供应商邻近门店的订单合并到同一配送窗口减少小批量加急车次。这块算法不算复杂但对成本的贡献不小。3. 分三步落地先通数据、再看板、后让AI接手3.1 第一步端到端数据同步与主数据清洗落地必须分步走一开始就想直接跑AI模型大概率会失败。第一阶段我们做的全是基础功梳理全品类SKU统一编码和量纲建立门店、仓库、供应商之间的数据映射关系配置定时同步任务设定数据质量校验规则。这个阶段持续了大约三周大部分时间都耗在对不清的账上。门店的盘点表格式五花八门仓库的入库单没有统一编号供应商的对账单单位和系统不一致。我们做了一个数据映射总表把每家门店、每个供应商对应的SKU对照关系都维护进去后续无论谁换了系统只要更新这张表就能接上。我自己坚持的原则是这个阶段宁可慢一点也不能带病上线。数据基础不牢后面建出来的看板再好看也只是把错误数据摆得更整齐而已。3.2 第二步BI看板建立运营基线第二阶段做BI看板和分析。我们内部管这个阶段叫“让门店对数据服气”。看板分采购、库存、配送三块采购看订单准时率、供应商到货差异库存看周转、损耗、异常预警配送看准时发车率、门店收货时长。每周供应链晨会直接投屏看板不再用邮件和Excel附件。这个改变很微小但效果非常明显以前会上大家各说各话店长说“我这周缺了好几次货”采购说“我明明按你的订单送了”现在屏幕上直接显示哪个时间点、哪个环节出了问题责任一目了然。这个阶段持续两到四周核心目的是建立运营基线。改造前的库存周转天数、损耗率、缺货率是多少都要用这段时间记录清楚因为后面AI上线后省了多少钱全靠这份基线来对比。没有基线就无法证明AI的价值。3.3 第三步AI模型分店分批上线第三阶段才轮到AI正式参与补货。我们并没有全量切换而是选了5家门店做试点。系统生成的建议订货量推送到店长端店长可以确认、修改或者驳回我们记录每天的驳回率每周复盘原因。试点跑到第三周模型预测销量与实际销量的误差在正负10%以内的占比已经达到82%左右。店长从最开始的抵触慢慢变成习惯和信任。第六个月全量门店切换到AI辅助订货模式采购部门依然保留审批环节但单店审核时间从每人每次十几分钟压缩到一两分钟。这里特别想强调一点AI上线的节奏最好是“辅助→半自动→全自动”不要一上来就剥夺人的判断权。餐饮门店情况千差万别先让系统和人的经验互相校准磨合顺畅后再逐步放开。4. 模拟项目X六个月实测钱省在了哪里4.1 直接成本数字变化项目运行到第六个月我们做过一次全面复盘主要指标变化如下指标改造前改造后库存周转天数7.6天4.3天生鲜损耗率8.9%4.1%缺货率6.2%1.4%紧急加单次数每月约40次每月约15次月度配送总里程基线下降约18%这些数值来自模拟项目X的真实运行统计口径是可比门店在菜价和门店数不变情况下的对比。简单算一笔账假设月采购总额200万生鲜占比50%损耗率从8.9%降到4.1%等于每个月在生鲜损耗上省下100万乘以4.8个百分点约4.8万元缺货率下降带来的营业额恢复保守估计每月也有4到5万再算上配送里程下降、收货和分拣人力优化全年测算下来百万级别的成本优化是靠谱的。4.2 门店和仓库的运营方式变化门店里最直观的变化是收货时间缩短。以前店长要对着纸质订货单逐箱核对现在扫码收货系统自动匹配订单差异项自动标红一个门店平均收货时间从大约30分钟降到15分钟。仓库分拣员按照系统生成的波次任务作业不再临时翻查单据装车顺序也更合理。财务那边同样轻松了不少。供应商对账单和入库单由系统自动匹配只有当差异超过阈值时才需要人工介入。以前月末对账要三个人加三天班现在一个人半天就能处理完而且差错率更低。4.3 一次台风天气的实战检验台风那个周末外卖订单比平时多了将近一倍。AI预测模型因为把天气和外卖平台数据作为特征提前两天就把各门店的补货建议上调了20%到25%与此同时BI看板把高风险的库存门店标成了红色预警。那个原本最不信模型的店长当晚没有缺招牌菜。而旁边一家未纳入试点的门店周末连续两天卖断货第二天紧急加单了三趟车才补上来。那次之后店长们对模型的态度发生了明显转变再也没有人提议退回Excel时代。这件事给我的启发是预测模型的价值不只体现在日常的稳定运营里更体现在突发情况下的提前应对能力。模型不会像人一样被当天的情绪和直觉牵着走它看到的是历史和特征共同作用下的概率分布。5. 踩坑实录比算法更重要的三件事5.1 数据不准模型只会把错误放大上线两个月后系统对某门店连续生成偏高的补货建议仓库堆了一堆可能短时间用不完的货。排查发现这家店已经连续三天没有回传盘点数据模型不知道实际库存已经降下去了还在按销售预测推补货量结果就变成重复补货。这个坑很典型。生成的结果看着像是AI变笨了实际是数据源头断了流。后来我们在系统里加了自动告警任何一个SKU连续两次数据缺失模型输出自动挂起并推送给数据负责人同时要求门店在下一个补货周期开始前完成数据补录。这里想特别提醒同行数据质量永远比模型复杂度更重要。一个简单模型配干净数据能稳稳跑出效果一个复杂模型配脏数据只会产出一堆看似科学实则离谱的结论。5.2 店长不信任模型指标再漂亮也推不下去试点第一周的驳回率高达65%店长的理由五花八门“天气这么热没人会吃这个”“下周搞活动订单不能按平时来”“我这个店跟其他店不一样”。我们没有硬推而是把AI输出改成了纯建议模式同时后台把预测值和实际值做成逐日比对每天在晨会上播放一周的命中率。等店长亲眼看到AI预测十次对了八次而自己凭感觉下单错了三四次之后抵触情绪自然就降低了。到第三个月有些店长反而主动催我们说系统怎么还没更新明天的补货建议。组织变革往往比技术变革更难。系统上线不是把功能交付就完事而是要帮一线的人完成从“靠经验”到“靠数据”的思维转变。这个过程中让他们看到数据是对的比任何制度都管用。5.3 供应商履约不稳定预测再准也没用AI把需求算准了只是完成了链路的前半段真正的执行要靠供应商。试点期间我们发现预测备货需求提前发给了供应商但配送商还是按老路线三天送一次结果某些生鲜品类经常在到货日当天就缺货。原因很简单供应商的调度逻辑没有跟着我们的预测走。后来改成滚动预测共享每周输出未来3天的日级别需求和未来7天的周级别需求给供应商同时按配送窗口调整装车计划缺货率才真正压下来。我们还设置了供应商履约考核到货准时率、数量差异率这些指标进入月度评分表做得好的供应商增加份额做不好的当面沟通。供应链是一条链单点优化意义有限。AI再聪明也弥补不了上下游执行环节的断裂。5.4 服务水平参数不是越高越好一开始我们把所有SKU的服务水平都设成95%执行了一段时间发现生鲜品类的库存明显增加周转天数反而反弹了。原因很简单95%服务水平意味着库存要覆盖95%的销量波动对前置期长、波动大的生鲜食材来说这种超储带来的损耗损耗比缺货损失更严重。后来我们把生鲜类SKU的服务水平改成85%到90%干货和冻品保持90%到95%并且每周复盘一次结合损耗率和缺货率动态调整。这个参数不是一个定值需要结合品类特性、前置期、毛利率综合判断。现在回头看这种调参的过程才是AI系统真正值钱的地方。模型给的不是一个万能答案而是一套可解释的决策框架帮运营者把成本和风险摆到台面上来权衡。6. 场景边界不是所有餐饮企业现在都该上这套6.1 具备什么条件才值得做我这里说的经验有一个前提如果你的餐饮业务已经有二十家以上门店、SKU超过三百个、生鲜类占比高、并且已经有POS收银和基础进销存系统那么这套路线非常值得尝试。门店越多、品类越多人的经验覆盖面就越有限AI的边际价值就越明显。几十家门店的订货单靠店长个人能力来拍误差一定是常态AI和数据平台至少在一致性上能兜住下限保证每家店按同一套逻辑运行。6.2 什么情况建议先缓一缓如果内部还在用手工台账、SKU编码很不统一、门店没有标准盘点和报损流程我强烈建议先补基础功不要急着上AI。模型只会忠实反映你输入的东西你给它混乱的数据它会还你一个貌似科学的混乱结果。预算有限的情况下优先做两件事流程标准化和主数据治理。这两件功课做完哪怕暂时不建BI看板、不跑预测模型只靠一套干净的Excel账本运营效率都会提升不少。等到流程理顺了再上系统推进速度和成功率都会高很多。6.3 再谈一点后续扩展这套数据基础设施之后还能接很多方向营销活动销量预测、按门店差异化配置SKU、财务业务一体化。我自己最想继续做的是把每一道菜对食材的消耗系数纳入系统让门店的报损差异自动分摊到菜品粒度那样成本和浪费的归因会更精准。如果让我再来一遍这个项目我最先做的不是建模也不是选平台而是把每个仓库的货、每个门店的账、每个供应商编码彻底盘干净。AIBI重构餐饮供应链最终重构的是人和数据的关系数字化工具只负责把正确的数据在正确的时间推给正确的人。技术本身不难难的是所有人愿意不再拍脑袋。