电商库存基础课：缺货预警相关的系统搭建一次讲透

电商库存系统最危险的时刻，不是库存显示为零，而是系统显示还有库存，采购却发现这批货根本撑不到下一次到货。我在做库存预警梳理时，反复遇到同一种情况：某个SKU账面可售库存700件，日均销量80件，供应商交期7天，业务人员看到库存数量并不紧张；但一场促销把日均销量推高到110件后，700件库存只够支撑约6.4天，货物还没到，商品已经进入缺货状态。缺货预警系统真正要回答的不是“现在还有多少件”，而是“现有可履约库存能否撑到下一次可靠补货到达”。

一、先讲核心结论：预警系统不是提醒工具，而是一套风险决策系统

1. 先统一库存口径，再讨论预警规则

如果仓库、订单、采购和销售团队使用的不是同一个库存口径，预警规则越复杂，误判反而越多。仓库说的是物理库存，销售看的是渠道可售库存，采购盯的是在途和已下单数量，财务关心的则可能是账面库存金额。这些数字都可能正确，但它们回答的是不同问题。

我通常会把库存拆成五个层次：物理库存、锁定库存、不可售库存、可售库存和在途库存。它们不能简单相加，也不能全部被当成“马上可以卖的货”。尤其是已经被订单锁定的库存、正在质检的退货库存和还没有入库的在途库存，不能直接支撑当前订单履约。

基础版可售库存可以用下面的关系式表达：

可售库存 = 物理库存 – 锁定库存 – 不可售库存 – 其他业务冻结库存

这只是便于沟通的简化公式。实际系统中，还需要根据仓库、渠道配额、调拨状态、质检状态和订单波次继续细分。公式本身并不难，难的是每一个字段都要有明确的业务含义、更新时间和责任人。

2. 用库存覆盖天数判断风险，用再订货点决定动作

固定数量预警适合销量很稳定的SKU，但同样是剩余100件库存，日均销量10件的商品还有10天库存，日均销量100件的商品只剩1天库存。因此，固定数量只能作为第一层提醒，不能独立承担缺货判断。

库存覆盖天数的基本计算方式是：

库存覆盖天数 = 当前可用库存 ÷ 预计日均销量

如果要判断是否来得及等到补货，可以进一步引入再订货点：

再订货点 = 采购提前期内的预计需求 + 安全库存

系统需要将当前可售库存、已确认在途库存、采购提前期、销量趋势和安全库存放在同一个判断链路中，而不是让运营人员打开五个系统后凭感觉拼数字。

3. 预警必须连接到责任人和后续动作

一条只写着“库存不足，请及时处理”的消息，实际上几乎没有执行价值。业务人员还需要知道：哪个仓库有风险、预计几天后缺货、是否已经存在采购单、供应商正常交期是多少、建议采购多少、谁负责确认，以及什么情况下需要升级给负责人。

我更倾向于把预警看成一张待办任务，而不是一条通知。预警状态至少应该包括“待处理、已确认、已创建采购单、等待到货、已恢复、误报、忽略及原因”。只有状态能够回写，系统才能在下一次复盘时解释：哪些规则有效，哪些预警只是制造噪音。

二、真实场景：为什么“有库存却缺货”比库存为零更难处理

1. 页面库存和履约库存不是一回事

在多渠道经营中，商品详情页显示的库存通常是销售渠道可见库存，而仓库系统记录的可能是整个仓库的物理库存。两者之间还隔着库存同步频率、渠道配额、订单锁定、仓内拣货和异常冻结。

例如，仓库里有500件商品，其中100件已经被订单锁定，80件处于质检状态，50件被分配给另一个渠道，剩下的270件才是当前真正可以继续销售的数量。如果销售系统仍然按照500件展示，短时间内就会出现超卖；如果库存预警按照500件判断，预警一定会延迟。

我在排查这类问题时，不会先问“预警阈值是多少”，而会先拉一张库存状态变更表，核对同一SKU在订单创建、付款、取消、拣货、出库和退货时分别发生了什么。很多所谓的算法问题，最后都变成了订单取消后锁定库存没有释放，或者退货入库后被错误地计入可售库存。

2. 缺货风险通常由三个时间差叠加产生

第一个时间差是库存数据更新时间与真实业务变化之间的差距。高峰期如果库存每30分钟同步一次，期间连续产生大量订单，系统判断的可售库存可能已经落后于仓库真实状态。

第二个时间差是从预警产生到采购人员确认之间的时间。预警发给无人负责的群组，往往要等到有人看到、转发、确认，风险才真正进入工作流。

第三个时间差是供应商交期与销售消耗速度之间的差距。供应商说7天交货，不代表每一单都能在7天内稳定到达。遇到排产、运输、质检和入库延迟，实际可用时间还会继续缩短。

缺货预警要覆盖的，是从数据变化到货物恢复可售之间的完整时间链，而不是只监控某一个库存数字。

3. 一个小型店铺也需要系统化预警

很多中小团队认为只有SKU数量达到几万时才需要预警系统。我的判断正好相反：SKU较少时更适合先把规则做简单、做准确，因为业务人员能够快速验证每条预警是否合理。

如果一个团队只有300个活跃SKU，却每周因为爆款断货损失销售，问题通常不在系统规模，而在于没有把销量、交期和库存状态放在一起看。哪怕先用数据表或可视化分析工具实现每日更新，只要能做到“风险列表、负责人、建议动作、处理状态”四项清晰，价值就已经超过单纯看库存余额。

三、常见误区：很多预警系统不是不够智能，而是基础逻辑错了

1. 误区一：把库存为零当成缺货预警

库存为零只能说明缺货已经发生，不能说明预警做得好。预警的价值是提前识别“按照当前消耗速度，库存将在未来某个时间点耗尽”，让采购、调拨或销售限流还有机会发生。

如果供应商交期为10天，而系统在库存降到零时才发消息，采购无论多么及时，都无法改变接下来10天的缺货结果。这样的提醒更像事后通知，不是风险预警。

我建议至少设置三个时间状态：库存覆盖天数高于采购提前期加缓冲期时保持正常；库存覆盖天数接近采购提前期时进入关注；库存覆盖天数低于采购提前期且没有确认到货时升级为严重风险。

2. 误区二：所有SKU使用同一个固定阈值

固定阈值之所以常见，是因为配置简单。问题是它忽略了SKU之间巨大的销售速度差异，也忽略了供应商交期、毛利、缺货损失和补货批量的不同。

日均销量为5件的长尾商品，库存低于50件可能仍能覆盖10天；日均销量为200件的爆款，库存低于50件就可能在几个小时内造成销售中断。把两个SKU都设置成“低于50件就提醒”，得到的不是统一管理，而是错误的优先级。

固定数量规则可以保留，但应当只承担“基础提醒”功能。真正影响采购动作的，应该是库存覆盖天数和再订货点。

3. 误区三：把在途库存全部视为可用补货

在途库存只有在到货时间足够可靠时，才具有补货价值。供应商刚刚承诺的数量、尚未发货的采购单、已经发货但没有物流节点更新的货物，可靠程度并不相同。

我会把在途库存至少分成“已确认发货、运输中、预计到货、逾期未到”四种状态，并给每种状态设置不同的可计入比例。对于交期不稳定的供应商，逾期未到的库存甚至不应继续抵扣缺货风险。

4. 误区四：预警越多越安全

预警数量增加，并不意味着风险识别能力提升。每天几百条重复消息会让业务人员形成“先忽略，之后再看”的习惯，真正严重的SKU反而会被淹没。

成熟的规则需要有冷却时间、重复合并、风险升级和异常分流。例如，同一个SKU在24小时内保持同一风险等级时只保留一条任务；只有库存覆盖天数继续下降、销量突然上升或在途货物逾期时，才重新触发升级通知。

5. 误区五：一开始就上复杂预测模型

预测模型可以处理季节性、趋势和活动影响，但它无法修复错误的库存口径，也无法解决采购单状态长期不更新的问题。模型输入不可靠时，预测结果只会让错误看起来更专业。

我的建议是采用渐进式路径：先建立库存状态和规则预警，再积累预警命中、误报、漏报和处理结果，最后决定哪些品类值得引入预测模型。对于销量稳定、供应商可靠的SKU，规则模型往往更容易解释，也更容易被业务接受。

四、专业判断逻辑：系统到底应该怎样计算“快要缺货”

1. 第一步：确定预警对象是SKU、仓库还是渠道

预警粒度不清，系统就会把不同问题混在一起。总仓库存充足但华东仓缺货，是仓配问题；全仓库存充足但某个渠道配额不足，是渠道分配问题；所有仓库都不足，则可能是真实补货问题。

我建议预警主键至少由“SKU、仓库、渠道、时间”组成。对于库存共享的业务，可以先在仓库层判断，再按照渠道优先级分配；对于渠道独占库存，则必须分别计算，不能用全渠道总库存替代。

2. 第二步：选择合理的日均销量

日均销量不是简单地把过去30天销量除以30。停业日、断货日、价格异常日和大促日如果直接混入，会导致销量基线被低估或高估。

对于常规SKU，我会同时观察近7天、近30天和去年同期数据。近7天反映最新趋势，近30天减少偶然波动，去年同期帮助识别季节性。系统不一定要马上采用复杂加权模型，但至少要把这些观察窗口展示出来，让业务人员知道日均销量是怎么来的。

如果一个SKU过去7天销量为840件，过去30天销量为1800件，那么近7日日均销量为120件，近30日日均销量为60件。两者差异达到一倍，说明商品可能处于活动期、增长期或异常波动期，系统不应该机械地选一个数字，而应触发“销量基线变化”检查。

3. 第三步：把采购提前期从一个数字变成一个区间

供应商交期写成“7天”并不代表每次都在第7天到货。更有价值的字段是承诺交期、历史平均交期、交期波动和逾期率。

如果供应商过去20次采购平均8天到货，但有4次超过12天，那么使用单一的8天作为补货依据会低估风险。对于高缺货成本的爆款，我会采用偏保守的交期基线；对于低价值长尾商品，则可以接受更高的缺货概率，避免过度占用资金。

4. 第四步：区分现货风险和供应链风险

当前可售库存不足，是现货风险；有采购单但到货不确定，是供应链风险；库存数据长时间未更新，则是数据风险。这三种风险不应该使用同一种红色提醒。

在系统中，我建议将风险拆成“库存不足、销量突增、交期延迟、库存异常、渠道分配异常”五类。这样业务人员看到严重预警时，能够知道应该采购、调拨、联系供应商，还是先修复数据。

5. 第五步：建立可解释的预警公式

基础版可以采用下面的计算逻辑：

预计缺货日 = 当前可售库存 ÷ 预计日均销量

风险库存差额 = 再订货点 – 当前可售库存 – 可靠在途库存

当风险库存差额大于零时，说明现有库存和可靠在途不足以覆盖采购提前期需求及安全库存。此时系统可以生成补货建议，但不应直接代替采购人员下单，因为最小起订量、包装倍数、仓容和现金流仍需要人工判断。

如果一个SKU当前可售库存700件，预计日均销量110件，采购提前期7天，安全库存300件，则：

• 库存覆盖天数约为6.4天。
• 采购提前期内预计需求为770件。
• 再订货点为1070件。
• 如果有500件可靠在途库存，风险库存差额为1070 – 700 – 500 = -130件，理论上暂时不需要新增采购。
• 如果在途库存只是供应商口头承诺、尚未确认发货，则不能按500件全额抵扣风险。

这组计算最容易被忽略的地方是“可靠在途库存”。在途数量越大，不代表风险越低；只有到货时间与销售耗尽时间匹配，它才真正能够降低缺货风险。

五、系统搭建：从数据底座到预警闭环逐层落地

1. 数据采集层：先解决“数据从哪里来”

缺货预警系统通常需要连接电商平台、订单系统、仓储系统、企业资源计划系统、采购系统和物流系统。系统不一定一次性打通所有接口，但必须明确每类数据的主来源，避免同一个字段在不同系统中各说各话。

2. 库存计算层：建立统一的库存状态模型

库存计算层的重点不是把所有数字加总，而是把库存状态和业务动作对应起来。一个商品从采购下单到最终售出，会经历采购中、运输中、待检、可售、锁定、出库和退货等多个状态。

建议系统保留每日库存快照。快照不是为了做漂亮的历史曲线，而是为了回答复盘问题：某次缺货预警产生时，系统看到的库存是多少？当时的销量基线是什么？采购单处于什么状态？如果没有快照，后续只能用最新数据倒推，很容易把历史问题解释错。

3. 规则引擎：把业务判断写成可配置规则

规则引擎至少需要支持阈值、时间窗、分级、抑制、升级和例外处理。规则应该由业务人员能够理解和调整，而不是每次修改安全库存都要等待开发上线。

以“预计缺货风险”为例，规则可以拆成以下条件：

1. 当前可售库存大于零。
2. 库存覆盖天数小于采购提前期加缓冲天数。
3. 可靠在途库存不足以覆盖风险库存差额。
4. 未来7天没有已经确认的促销取消或销量下降因素。
5. 同一SKU在冷却时间内没有生成同等级预警。

如果条件全部满足，系统生成采购预警；如果同时检测到订单量异常增加，则将风险升级；如果库存同步超过设定时间没有更新，则转入数据异常队列，而不是继续用旧库存计算采购建议。

4. 触达层：通知渠道服从责任链，而不是越多越好

日常提示可以进入系统待办或企业协作工具，严重缺货风险可以通知采购负责人和业务负责人，库存数据异常则应通知系统管理员。不同风险使用不同渠道，才能让消息具有优先级。

我建议每条预警都带上以下字段：

• SKU编码和商品名称。
• 风险仓库与销售渠道。
• 当前可售库存和可靠在途库存。
• 预计日均销量及统计窗口。
• 库存覆盖天数。
• 采购提前期和安全库存。
• 预计缺货日期。
• 建议采购量或调拨方向。
• 当前责任人和处理截止时间。

5. 任务层：让预警能够被确认、转派和关闭

预警任务必须有明确的生命周期。采购人员确认后，应能够关联采购单；仓库调拨后，应能够填写调拨单；供应商延期后，应能够更新预计到货日期；商品恢复可售后，系统再自动关闭或转入复盘。

特别要保留“误报原因”和“忽略原因”。如果某SKU连续三次被忽略，原因都是“活动已结束”，说明系统应该增加活动结束条件；如果大量预警被标记为“库存数据错误”，说明应优先修复数据同步，而不是继续调整阈值。

6. 用九数云搭建可视化监控层

在中小团队或业务部门自建预警分析时，我会优先考虑把九数云作为分析和可视化层，而不是让它承担所有交易系统职责。这样分工更稳妥：订单、仓储和采购系统负责产生业务事实，九数云负责把多源数据整合成库存看板、风险清单和管理分析。

具体可以把SKU主数据、每日库存快照、订单明细、采购单、在途节点和活动计划接入分析模型，再通过字段关联形成“SKU，仓库，渠道，日期”的分析粒度。看板首页不应只放库存总额，而应优先展示缺货风险SKU数、预计7天内缺货SKU数、逾期在途金额、预警处理时长和按时恢复率。

我尤其建议建立两个页面：一个给运营和采购使用的“今日待处理预警”，另一个给负责人查看的“库存健康度趋势”。前者关注行动，后者关注结果。将两类需求放在同一个页面里，往往会导致既不适合操作，也不适合管理。

九数云的价值在这里主要体现在多表关联、指标计算、筛选下钻和可视化呈现。比如业务人员点击某个严重预警SKU，可以继续下钻到仓库库存变化、近30天销量、关联采购单和供应商到货记录，而不是停留在一张红色列表上。

需要强调的是，九数云或其他分析平台不能替代库存事务系统。订单扣减、采购下单、仓库出入库仍应在各自业务系统完成；分析平台应保留数据来源和更新时间，避免业务人员把看板上的统计结果误认为实时交易库存。

六、用一组SKU数据跑完整流程：从预警到补货建议

1. 示例数据与计算前提

下面是一组用于说明方法的情景模拟数据，SKU设为“便携榨汁杯A”，不代表任何企业的真实经营数据。该商品常态日均销量80件，当前促销期预计增加30件，供应商承诺交期7天，安全库存设为300件。

2. 不考虑活动时，风险已经接近临界点

按常态日均销量80件计算，700件可售库存可以支撑8.75天。表面上看，这比7天采购提前期多出1.75天，似乎还有缓冲；但安全库存为300件，意味着真正不应被日常销售消耗的缓冲数量已经达到较高水平。

如果只使用“可售库存大于500件，所以安全”的判断，会忽略安全库存已经被纳入可售库存总量这一事实。安全库存不是额外存在的一批货，而是当前库存中需要被保护的部分。随着销量增加，系统必须重新计算库存何时会跌破安全库存线。

3. 促销后，库存覆盖天数低于交期

促销期预计日均销量为110件，700件库存只能支撑约6.36天，已经少于7天采购提前期。换句话说，即使今天立即下采购单，按照正常交期，货物仍可能在库存耗尽之后才到达。

因此，这个SKU至少应进入“严重预警”或“紧急补货评估”，并同时检查三个问题：活动销量是否会继续增加、500件在途是否已经确认发货、是否存在其他仓库可以调拨。

4. 在途库存可以降低风险，但不能自动关闭预警

如果500件在途库存已经发货，物流节点正常，预计3天后到达，那么它对短期风险有实际帮助。活动期3天预计消耗330件，剩余可售库存约370件，货物到达后可以避免立即断货。

但如果这500件只是采购单上的计划数量，供应商尚未确认排产，那么它不能作为可靠补偿。系统应将“计划在途”和“已确认在途”分开。前者可以展示在看板上，后者才可以用于降低缺货风险。

5. 补多少货不能只看缺口

按照活动期日均销量110件、采购提前期7天和安全库存300件计算，再订货点为1070件。当前可售700件，可靠在途500件，理论上库存总覆盖为1200件，高于再订货点130件。

但是，1200件并不是今天可以销售的现货，其中500件需要经过运输、入库和质检。若预计3天后到货，短期无需新增紧急采购；若到货日期不确定，则应至少把供应商交期风险纳入判断，并根据最小采购量、活动剩余天数和现金流做采购决策。

在九数云看板中，可以把这组数据做成“库存构成、销量趋势、预计缺货日期、在途状态和预警处理状态”的联动视图。业务人员点击SKU后，先看库存是否真实，再看销量是否发生变化，最后看在途是否足够可靠。这种下钻顺序比直接给出一个“建议采购500件”更安全。

七、不同业务情况下的行动建议：同一个红色预警不一定采取同一个动作

1. 销量稳定、供应商可靠的常规SKU

这类SKU最适合使用库存覆盖天数加固定安全库存的组合规则。系统每天更新日均销量，当覆盖天数低于采购提前期加2至3天缓冲时生成提醒，低于采购提前期时升级。

行动上可以优先采用常规采购，不必过度增加安全库存。因为供应商交期稳定，缺货概率相对可控，过高的安全库存反而会增加资金占用。

2. 销量快速增长的爆款SKU

爆款最容易出现“历史平均销量还不错，但未来几天一定不够用”的情况。系统应缩短销量统计窗口，增加近7天和近3天趋势，并把加购、预售、活动报名或直播排期作为需求信号。

行动上应同时评估采购、跨仓调拨、渠道限量和活动调整。如果单纯等采购到货，可能已经错过销售窗口；如果盲目大批量采购，又可能在热度结束后形成积压。

3. 大促、直播和短周期活动商品

活动商品不能使用普通日均销量直接计算。活动前应建立独立需求计划，把预计曝光、转化率、活动时长、客单件数和退款率纳入估算。活动进行中，还要按小时或更短周期观察订单增长速度。

如果活动销量明显超过计划，应快速执行库存保护措施：减少非核心渠道可售量、限制单用户购买数量、调整广告投放或将预售规则提前启用。预警系统应该支持这些动作的记录，否则复盘时无法判断缺货究竟是采购不足还是活动策略失控。

4. 季节性商品和生命周期商品

季节性商品不能只看最近30天销量。冬季服装、节庆礼盒、户外用品等商品的需求受季节、天气、节假日和生命周期影响明显，历史同期数据往往比近期均值更有参考价值。

对于新品，则要接受数据不足的现实。新品初期可以使用同类商品作为参考，设置较保守的补货批量，同时观察首周销售速度和退货情况。不要因为系统没有足够历史数据，就假装预测结果很精确。

5. 长尾商品和低毛利商品

长尾商品不一定值得维持很高的安全库存。如果商品缺货后替代品很多，且供应商交期短，可以接受较低库存；如果商品是配件、耗材或组合商品中的关键部件，即使销量不高，缺货也可能导致整套订单无法履约，这时需要提高优先级。

系统可以结合毛利、销售贡献、缺货损失和采购难度进行分层，而不是只按销量排序。库存管理的目标不是让所有SKU都不缺货，而是在可接受的成本下保护最重要的销售和履约结果。

八、不同方案的取舍：表格、分析平台和定制系统怎么选

1. 电子表格方案：适合验证规则，不适合长期承载闭环

如果活跃SKU不多、仓库数量有限、每天只需要一次更新，电子表格可以作为第一阶段工具。它的优势是成本低、调整快、业务人员容易理解。团队可以先用表格验证可售库存公式、库存覆盖天数和预警等级是否符合实际。

但表格很容易出现版本混乱、人工复制错误、公式被覆盖和责任状态无法追踪等问题。当每天需要合并多个渠道、多个仓库和采购单时，表格的维护成本会迅速超过它的初始优势。

2. 分析平台方案：适合快速建立统一看板和经营分析

九数云这类分析平台更适合承担数据整合、指标计算、可视化看板和下钻分析。对于已经拥有订单、仓储和采购系统的企业，分析平台可以减少重复导出和人工拼接，让管理层看到跨系统的库存健康度。

它的边界也很明确：分析平台通常不是订单扣减、仓库出入库和采购审批的唯一事务来源。若企业需要在预警产生后自动锁库存、自动下采购单或执行复杂的库存分配，就需要与业务系统和接口服务继续集成。

3. 定制系统方案：适合规则复杂、实时性要求高的企业

当企业拥有大量SKU、多仓多渠道、频繁活动和严格履约要求时，定制库存中心或规则引擎更有价值。它可以处理事件驱动库存更新、复杂渠道分配、供应商交期预测和自动化任务流转。

但定制系统的成本不只在开发，还包括需求治理、接口维护、数据质量、权限设计、测试和持续运营。如果基础库存口径尚未统一，直接开发一套大系统，往往只是把混乱固化成更昂贵的流程。

4. 我的选型判断：先看决策复杂度，不要先看SKU数量

SKU数量不是唯一标准。一个只有500个SKU但活动频繁、渠道复杂的企业，可能比拥有5000个稳定SKU的企业更需要自动化。真正应该评估的是：每天需要合并多少数据源、多少次库存变更、多少种例外规则、多少人参与处理，以及缺货一次会造成多大损失。

如果团队还不能准确回答“可售库存由哪些字段组成”，不建议直接采购复杂系统。先用数据分析工具完成口径统一和预警复盘，等规则稳定后再决定哪些环节值得自动化。

九、上线后的评估：不要只看缺货率，还要看预警是否值得信任

1. 先看预警准确性

预警命中率可以理解为：产生预警的SKU中，后来确实进入缺货风险或需要采购、调拨的比例。命中率过低，说明规则过于敏感、库存数据不准确或活动例外未被识别。

但命中率也不能孤立使用。为了追求高命中率，团队可能把阈值设置得非常宽松，结果漏掉大量真正风险。因此必须同时看误报率和漏报率，并按SKU类型、仓库和渠道分别统计。

2. 再看处理效率

预警从产生到确认的时间，反映通知和责任分配是否有效；从确认到创建采购单的时间，反映业务流程是否顺畅；从创建采购单到恢复可售的时间，则反映供应商、仓库和物流的综合效率。

如果预警确认很快，但恢复可售仍然很慢，问题可能不在预警系统，而在供应商交期或入库能力。如果预警长期无人确认，则应先修复责任链，而不是继续优化预测模型。

3. 最后看经营结果

最终要观察的指标包括缺货率、订单履行率、库存周转率、库存覆盖天数、加急采购次数、滞销库存金额和库存资金占用。不同指标之间需要结合分析，因为降低缺货率可能是通过大量增加库存实现的，不一定代表经营质量真正提高。

4. 给系统设置复盘周期

基础规则建议每周快速复盘，每月进行一次结构性复盘。每周关注新出现的严重预警、逾期在途和重复误报；每月则重新评估销量基线、供应商交期、安全库存和商品分层。

对于大促和季节性商品，不能等到月度复盘才调整。活动前要做一次预演，活动中按实际订单速度校正，活动后再检查剩余库存和退货库存是否会造成新的积压风险。

十、落地执行清单：用四周把缺货预警从想法变成可运行机制

1. 第一周：盘点字段和业务口径

第一周不要急着做漂亮看板，应先列出所有库存相关字段，并让仓库、采购、运营和技术人员逐一确认。每个字段都要写清定义、来源、更新时间、是否可以计入可售库存，以及发生异常时由谁负责。

• 确认SKU、仓库和渠道主数据是否统一。
• 核对物理库存、锁定库存、不可售库存和可售库存的关系。
• 清理长期未关闭的采购单、调拨单和退货单。
• 检查订单取消、退款和售后状态是否能够正确释放或扣减库存。
• 记录每个数据源的刷新频率和最近一次更新时间。

2. 第二周：选择一批代表性SKU验证规则

不要一开始就把所有SKU纳入。可以选择20至50个SKU，覆盖爆款、稳定品、季节品、新品和长尾品，使用历史数据回放规则，观察如果系统当时发出预警，业务人员是否会认为它合理。

这一阶段要特别关注两类反例：系统没有预警但后来缺货的漏报，以及系统预警后业务完全不需要动作的误报。反例比平均结果更有价值，因为它们能直接暴露规则边界。

3. 第三周：在九数云中建立两个看板

第一个看板是“库存风险工作台”，服务于日常执行。它应该支持按照风险等级、仓库、渠道、商品负责人和预计缺货日期筛选，并能下钻到库存状态、销量趋势、采购单和在途节点。

第二个看板是“库存经营复盘”，服务于管理决策。它应展示缺货率、订单履行率、库存周转率、滞销库存、预警命中率、误报率和处理时长趋势，让负责人看到规则调整之后经营结果是否真的改善。

看板中所有指标都要显示统计周期和更新时间。尤其是“当前可售库存”和“预计缺货日期”，如果数据延迟超过业务允许范围，应直接显示数据异常标识，而不是继续展示一个看似精确的数字。

4. 第四周：绑定责任、时限和升级规则

每个预警等级都要有处理时限。例如提示级可以在当天关注，普通预警要求一个工作日内确认，严重预警要求在数小时内完成采购、调拨或销售策略调整。具体时限应根据商品价值、渠道承诺和供应商交期确定。

还要明确无人处理时的升级路径。任务超过时限未确认，自动升级给商品负责人；超过第二个时限仍未处理，再通知供应链负责人。升级不是为了增加压力，而是为了避免风险停留在一个没有实际决策权的人手里。

5. 上线后持续保留人工判断

系统可以给出预警和建议采购量，但不应在所有品类上自动下单。采购人员仍然需要检查供应商是否有产能、仓库是否有容量、活动是否会变化、商品是否即将下架，以及是否存在替代品。

好的系统不是消灭人工判断，而是把人工判断从“找数据、拼数据、猜风险”中解放出来，让人把时间用在真正需要权衡的决策上。

十一、结语：先让系统解释缺货，再让系统预测缺货

缺货预警系统最容易被误解成一个“库存低于阈值就发消息”的功能。真正可用的系统，至少要完成四件事：统一库存口径，识别未来缺货时间，区分风险来源，并把预警转成有人负责的处理任务。

我在实际梳理库存问题时，最看重的不是系统是否使用了复杂算法，而是它能不能解释一条预警为什么产生。业务人员应该能够沿着一条清晰路径看到：当前可售库存是多少，销量基线怎么计算，供应商交期是否可靠，在途库存能否按时到达，预计哪一天会跌破安全库存，以及现在应该采购、调拨、限流还是暂时观察。

如果企业正在从零搭建系统，我建议不要先追求全自动补货。第一步应是选取一批代表性SKU，统一库存字段，建立覆盖天数和再订货点规则；第二步用九数云等分析平台做风险看板和历史复盘；第三步根据误报、漏报和处理结果优化规则；最后才决定是否把采购建议、审批和库存动作进一步自动化。

我的独特判断是：库存预警系统的成熟度，不是由预警数量、算法复杂度或页面数量决定的，而是由“预警能否被相信、被处理、被验证”决定的。

下一步可以从一个具体SKU开始，填写物理库存、锁定库存、不可售库存、日均销量、采购提前期、安全库存和可靠在途库存七项数据。只要这七项数据能够稳定更新，你就已经具备了搭建基础缺货预警系统的起点。随后再把仓库、渠道、活动和供应商交期纳入模型，逐步从“看库存”走向“看风险”，从“收到提醒”走向“完成补货闭环”。

免费注册

咨询方案

扫码咨询方案