零售业来了个新Agent：专查商品采销库存错配

现在我知道的大部分零售企业不是没有数据，ERP、门店系统、电商后台、财务系统都跑着，BI看板也搭了，销售额、库存、采购、动销率、售罄率该看的数都能看到。

但到了经营会上，反复卡住的还是那几个问题：这个月为什么掉了？到底是哪一批货出了问题？是销售不行，还是库存没承接住？

报表能告诉你“发生了什么”，但经营真正难的是：

• 为什么发生？
• 问题具体压在哪些品牌、系列、SKU上？
• 下一步到底先处理哪一类？

2026年，九数云推出了一款面向零售采销场景的AI Agent——小狄。

它不做“更漂亮的看板”，不做“更快的AI问数”，而是先帮你跑一次采销库存错配诊断，把销售、采购、库存放进同一条诊断链路里，帮你找出一批值得复核的商品问题。

一、零售采销错配

很多时候，零售企业的问题不是“看不见数”，而是“看见了，也判断错了”。

• 销售下滑了，以为是需求差，于是开始促销

但真实问题可能是畅销款早就断货，门店没货可卖。

• 库存高了，以为是采购买多了，于是全面控采

但真实问题可能是某些款该控，另一些款反而该补。

• 某个系列卖得差，以为是商品不行

但真实问题可能是货压在卖不动的渠道，卖得动的渠道没货。

最贵的不是晚一天看到报表，而是连续几周都在用错误原因解释问题：该补货时去控采，该清库时继续补货，该看库存承接时却只怪销售。

为什么天天看报表，还是发现不了真正有问题的SKU？

因为销售、采购、库存经常是分开看的，每张表都没错，但放在一起，才知道问题到底在哪里。

• 销售下降，不一定是需求下降
• 库存充足，不一定是有效库存
• 采购增加，不一定是补对了货

卖得少，不一定是卖不动，也可能是早就没货可卖。

这就是采销库存错配最麻烦的地方，它不是单个指标的问题，而是多个环节之间没对齐：

• 买进来的和卖出去的没对上
• 压着库存的和真正有需求的不是同一批
• 该补的没补、该控的没控
• 该处理的商品被一堆平均数盖住

传统BI擅长回答“发生了什么”，但它默认你已经知道该看什么。

AI问数能让你更快查数，但前提是你得先知道自己要问什么。

可经营里最难的，往往正是你不知道该问什么？

二、小狄是谁

小狄的核心逻辑，不是再做一个库存看板，而是帮老板查清三件事：

• 哪些货压着钱
• 哪些畅销货缺
• 哪些采购没有被销售承接

它不是让AI直接替生意拍板，而是先把销售、采购、库存放到同一条诊断链路里，找出值得复核的商品问题：

• 哪些SKU可能库存压力大，占着现金
• 哪些SKU可能供给不足，正在漏单
• 哪些商品看起来异常，但因为强配、代销、陈列、品牌规则等原因，不能直接处理

小狄想做的是：不是等你问，而是先按诊断剧本，把销售、采购、库存里的异常路径跑一遍，把值得关注的问题推出来，再交给人复核。

三、诊断链路

小狄不会直接读一张库存表就下判断，它先确认四个层面的数据对齐：

• 销售明细

来自POS、ERP、电商平台、门店系统，哪些商品真的卖得动，哪些销售在下滑

• 采购明细

来自ERP、采购系统、入库单，哪些采购跟销售节奏不匹配

• 库存快照

来自ERP、WMS、门店库存，哪些货压着钱，哪些货快断供

• 商品主数据

来自ERP、商品档案、品类表，品牌、系列、品类、SKU、生命周期怎么承接问题

• 成本/金额

来自财务、ERP、成本表，库存占压金额、缺口金额、超采金额

• 业务规则

来自商品、采购、运营团队，代销、自营、停补、强配、不可调拨、活动周期

先把数据和业务规则对齐，再诊断，不然库存高低只是现象，不是判断。

四、多路径诊断

现在的很多系统只会告诉客户：这个SKU库存高、这个品类销售低、这个门店周转慢。

但老板真正想知道的是：

• 它是真压货，还是新品观察期？
• 是采购过量，还是销售没承接？
• 是畅销缺货，还是仓店分布不均？

小狄按诊断剧本跑，不是一句AI建议。

核心诊断链路覆盖6类问题：

• 高库存低销售

库存是否形成压力，哪些货压着钱？

• 高销售低库存

是否存在断货/缺口风险，哪些畅销款正在漏机会？

• 高采购低销售

采购是否超前或过量，哪些采购动作做重了？

• 高库存高退货

是否存在质量/款式/渠道问题，为什么卖出去又退回来？

• 低库存高增长

是否需要补货复核，哪些货该优先补？

• 门店/仓库错配

货是否在错误的位置，为什么总仓有货，门店没货？

• 商品结构错配

品类/系列是否承接失衡，为什么大类还行，具体系列不行？

小狄会把路径展开，再收敛成Top问题，而不是把所有图表堆给老板。

五、诊断的典型应用场景

小狄的诊断能力在零售企业的多个高频场景中可以直接发挥作用。

场景一：月度经营会前的采销库存诊断

经营会上反复卡住的往往是同一个问题：到底是哪一批货出了问题？

传统模式下，各部门拿着各自的报表在会上对口径，争论半天也不一定有结论。

小狄在会前自动跑一次采销库存诊断，把销售、采购、库存放进同一条链路里跑一遍，输出诊断总览本期最重要的问题是什么、影响金额是多少、哪些品牌/系列/门店最值得看

会议时间从“对数据”变成了“做判断”。

场景二：主力系列销售异常排查

一个主力系列突然销售下滑，按常规思路很容易归因到“市场不好、需求下降”，第一反应就是促销。但真实原因可能是畅销款断货、渠道错配或采购节奏没跟上。

小狄把该系列的销售、采购、库存数据放在同一条诊断链路里排查，锁定问题类型，是真需求下降还是库存没承接住。比如剔除伪异常后锁定了8个真正值得动作的SKU，有的库存覆盖月数明显偏高，现金压在动销很慢的货上；有的还在稳定卖却快没货；有的动销基本停滞需要主动去化

每条发现都能追溯到具体SKU和库存覆盖月数，业务负责人可以直接复核。

场景三：季末库存与畅销缺货同步诊断

季末复盘时，库存高和畅销缺货往往同时存在。在传统报表里，高库存清单和缺货清单是两张独立的表，看不出来两者的关系。

小狄把“压货”和“缺货”放在同一张诊断里看——哪些货压着钱、哪些畅销货缺、哪些采购没有被销售承接，避免只盯着清库存、结果把机会也清掉了

库存问题不是库存太多，而是库存放错了地方、压在错的货上、缺在真正卖得动的货上。

场景四：新品上市后的跟踪诊断

新品上市后，很难判断是“还在观察期”还是“已经卖不动了”，传统分析只看销量，容易误判。

小狄结合库存覆盖月数、销售趋势、商品生命周期标签（新品/成熟款/衰退款）综合判断，区分“新品观察期”和“真实滞销”，避免把还在成长周期的新品当成问题库存处理

场景五：采购节奏与销售承接的对标分析

采购上去了、销售没接住，就会形成资金占压风险。

小狄把采购明细和销售明细放在同一条链路里对比，采购数量 vs 销售数量、到货节奏 vs 销售节奏，判断哪些采购动作做重了、哪些采购节奏需要调整

采购不是越早越好，也不是越多越安全；关键是采购后有没有被销售承接。

六、结果分层

诊断跑完之后，结果不能一股脑全推给老板，不同角色需要看到不同的信息颗粒度。

老板先看：

• 诊断总览：本期最重要的问题是什么
• 影响金额：大概压了多少钱、漏了多少机会
• Top对象：哪些品牌/系列/门店最值得看
• 优先动作：补货、控采、调拨、清理、观察
• 当前状态：谁在复核，哪些还缺证据

分析师再展开：

• 证据下钻：销售、采购、库存、成本、趋势
• 过程表：每一步怎么算出来
• 限制条件：哪些数据缺口影响判断
• 口径说明：日期、成本、库存快照、业务规则
• 候选行动：每个动作为什么建议、谁该复核

一句话：老板看判断，分析师看证据，一线看待办。

而九数云的分层看板能力支撑了这一设计，其中的零售门店分析解决方案正是基于组织分层逻辑，构建了一套分角色、分任务、分场景的数据运营体系。

• 老板经营驾驶舱看全公司汇总和异常预警
• 店长运营分析看板看自己店铺的趋势图和SKU排行榜
• 运营工作台看明细数据和库存预警

每个门户之间通过九数云的权限和空间做了严格隔离。

七、候选行动复核

普通报表最后常写“建议优化库存结构”“建议关注畅销缺货”，但这样太泛，业务接不住。

小狄把建议拆成可复核项：

• 补货复核

畅销低库存商品/系列 → 采购负责人 → 是否还能补、补多少、周期多长

• 控采复核

高采购低销售商品 → 采购负责人 → 是否暂停采购、是否调整节奏

• 调拨复核

仓店库存错配对象 → 门店/运营负责人 → 哪些门店缺，哪些门店压

• 清理复核

高库存低动销对象 → 商品/运营负责人 → 是否促销、降价、组合销售

• 继续观察

新品、战略款、证据不足对象 → 分析师/商品负责人 → 观察多久，看什么指标

每条候选行动都有处理对象、责任角色、触发证据、派发前确认条件和后续观测指标。

小狄不是替业务拍板，而是把“该谁看、看什么、怎么处理、处理后看什么指标”组织起来。

这里叫候选行动，不是AI自动派发正式行动。

正式行动必须走完：

诊断发现→分析师复核→业务负责人确认→进入行动收件箱→执行反馈→后验复盘

八、落地方式

小狄的落地方式非常轻量，基于九数云BI的能力，直接对接企业现有数据源，不需要改造任何系统。

对于已有ERP、POS、WMS等系统但数据分散的零售企业，通过九数云BI的直连现有数据源：用友、金蝶、旺店通、聚水潭等ERP系统，以及POS系统、电商平台等。

九数云支持通过API、数据库或Excel方式进行整合，配置一次、数据永久自动同步。

在其中搭建采销库存诊断模型，按小狄的诊断剧本跑通全链路：

“销售→采购→库存→商品结构→行动复核”

九数云的数据处理和计算模型功能，可以快速构建关键分析指标。

通过简单的“分析表”功能，关联不同数据源、写计算字段，实现多维度库存数据的整合。

这是目前最轻量的切入方式，不需要改造现有系统，最快1-2周内跑出第一批诊断结果。

诊断结果可以通过九数云与钉钉的交互能力，定时向负责人员发送提醒通知，让他们实时了解当前各商品的库存情况并采取相应措施。

整个数据链路，从多源数据接入、口径统一、指标计算，到诊断看板生成、自动化推送，全部在九数云一个平台内完成闭环。

九、为什么小狄能做到

• 诊断剧本

传统BI是：

指标→图表→人自己猜原因

小狄是：

经营问题→诊断剧本→多路径排查→证据收敛→候选行动复核→后验复盘

不只看库存高低、不只看销售排行、不只看采购金额，而是把销售、采购、库存、商品规则放到同一条诊断链里。

小狄交付的不是一组图，而是一套可复核的经营判断路径。

• 结果包驱动

普通AI的风险：

会说但不知数从哪来、能解释但口径不一定对、能建议但业务不一定能执行

小狄的方式：

确定性执行链路先算出结果→结果包盖章→Agent只读取结果包解释→候选行动必须复核

事实计算不交给AI；指标口径有版本；过程表可追溯；数据缺口会明示；候选行动不会自动变正式行动。

AI负责把结果讲清楚，不负责替企业拍板。

• 持续闭环

现在的分析项目：

做一份报告→开一次会→下个月重来

小狄：

诊断→复核→行动→回写→复盘→校准

每次诊断都留下证据，每条候选行动都能追踪，每次执行结果都能回看；有效规则沉淀，无效判断校准。

小狄不是让企业多看一次数据，而是让企业的经营判断力越跑越稳。

写在最后

其实我们的零售企业不是没有数据，而是缺少一条能把数据变成经营判断、再变成业务动作的链路。如果一个问题每个月都在复盘，却总是解释不清、推动不动、没有沉淀，那它就不只是数据问题，而是组织判断力的问题。

小狄想做的是：

不是等你问，而是先按诊断剧本，把销售、采购、库存里的异常路径跑一遍，把值得关注的问题推出来，再交给人复核

它把诊断结果变成补货、控采、调拨、清理、继续观察五类候选行动，每条行动都有处理对象、责任角色、触发证据和后续观测指标。

别人给你一次答案，小狄想帮你长出一套越用越准的经营判断力。