安全库存公式看起来只是“日均需求 × 交期波动 × 服务水平”的计算题，真正让仓库缺货或积压的，往往不是公式选错，而是公式吃进去的数据口径不一致：销售出库被当成真实需求、供应商承诺交期被当成实际交期、促销尖峰被平均值抹平。配置安全库存时，我会先追问“这个数由谁维护、依据什么更新、触发后谁采取行动”，再决定用哪条公式、接哪种工具。下面以可复核的计算方法、明确标注的情景模拟和工具分工，拆解一套能落地的配置思路。
安全库存是应对需求或补货不确定性的缓冲量；再订货点是库存位置降到某一阈值时启动补货的信号；订货批量则回答每次补多少。三者经常被放进同一个表格，却不能混为一谈。把“安全库存设成 300 件”当作全部配置，既没说明什么时候订，也没说明一次订多少。
在固定提前期、需求波动为主要不确定因素的简化场景中，常见配置为：安全库存 = 服务水平对应的 Z 值 × 提前期内需求标准差；再订货点 = 提前期平均需求 + 安全库存。如果每天需求相互独立、每天标准差近似稳定，提前期固定为 L 天，则提前期需求标准差可近似为日需求标准差 × √L。
如果交期也会波动，简化模型可以写成：提前期需求标准差 = √（平均交期 × 日需求方差 + 日均需求² × 交期方差）。再订货点仍是平均提前期需求加安全库存。这个模型适合用于建立分析框架，但数据分布、季节性、缺货截断、供应商批次差异等情况都可能让结果偏离实际。
我更看重公式是否匹配业务条件，而不是公式看上去是否复杂。数据质量不足时，复杂公式只会把错误参数包装得更精确。反过来，一个结构简单、数据口径稳定、异常能被人工复核的模型，通常比无人维护的精细模型更可用。
讨论工具对比时，建议把“工具”理解为一个工作链，而非只比较软件名称。至少要看四个环节：业务系统提供交易数据，分析层整理口径并计算参数，库存执行系统接收补货阈值，人员通过预警和复核流程采取行动。
如果某个工具只能展示图表、不能回写库存参数，它仍然可能是有价值的分析层，但不应被误认为完整的补货执行系统。反之，能自动下单的系统如果没有可靠的数据校验，也可能更快地放大错误。
假设某 SKU 连续 3 天销售为零，表格很容易将这 3 天识别为“没有需求”。但如果这 3 天库存为零，零销售可能只是无法成交，而非客户不需要。只用出库量计算日均需求，库存不足造成的需求截断就会被误当成需求变弱，后续安全库存反而越算越低。
我建议把库存状态和销售记录放在同一条时间线上。至少标记可售库存为零的日期、订单未满足数量、延期交付和取消原因。缺少这些信息时，可以先将断货期间标记为不可观测，而不是直接填成零需求。对历史较短或频繁断货的 SKU，参数应保留人工复核标志。
过去 90 天的日均需求，不能自动代表未来 90 天。如果这段数据包含一次大促、渠道铺货或季节峰值，简单平均会受到少数高值影响；如果需求正在爬升，向后看平均又会滞后。更重要的是，安全库存针对的是波动缓冲，并不等于对趋势或促销峰值的完整预测。
我会把需求划分为“基础需求”“可识别事件需求”和“无法解释的异常”。基础需求用于常规补货，已确认的活动量可通过活动计划单独纳入，无法解释的异常则进入数据检查或模型诊断。把促销期的峰值全部塞进日常安全库存，会让促销结束后的仓库仍背着高库存。
供应商承诺 7 天到货，不等于实际交期恒为 7 天。对于安全库存，关键是从采购订单发出到可用库存入库的实际天数；需要纳入质检、预约、跨仓转运等环节时，也要明确计时起止点。若采购单分批到货，应事先规定用首批到货、全部到齐还是可销售入库作为交期终点。
不同供应商、不同运输方式和不同季节可能有不同交期分布。把这些记录混在一起算一个平均值，会掩盖“常规线路稳定、旺季线路拖延”的事实。对关键物料，按供应商或供货线路分层通常比对全部采购记录求一个总平均更能支持决策。
采购关注供应是否及时，仓库关注可用库位和收货能力，财务关注资金占用。库存系统里显示的“总库存”可能包含在途、待质检、冻结、预留和不可售数量。计算可补货库存时，必须明确再订货点比较的是现有量、库存位置，还是“可用库存 + 已下单未到货 − 已承诺未发货”。
我通常会要求团队先写下库存位置定义，再讨论阈值。否则，同一条公式在不同人手里会得到不同动作：一方看到可用库存低于阈值就采购，另一方把在途订单也计入后认为无需补货。公式没有变，决策却相反，问题出在定义不一致。
所有商品都追求 99% 服务水平，通常不是精细管理，而是忽略了商品价值、替代性和供应风险的差异。一个低价值、容易替代、需求稳定的辅料，未必需要和停线关键件采用相同目标；反过来，关键件的缺货损失高，低服务目标也可能不合算。
服务水平应与缺货损失、持有成本和替代方案一起看。ABC 分类可反映金额或销量贡献，XYZ 分类可反映需求稳定性，但分类只能帮助分组，不能替代业务判断。若只按金额分层，金额低但会造成生产停线的物料可能被低估。
在常见正态近似中，Z 值和周期服务水平相关，但周期服务水平与满足率不是一回事。前者关注一个补货周期内是否发生缺货，后者关注需求数量中有多少比例被满足。对于需求量大、缺货会持续多日的场景，单看周期服务水平可能无法解释客户实际体验。
如果业务目标是满足率，应基于需求分布、补货批量、缺货回补方式和交货周期评估，而不是机械地将目标百分比换成一个 Z 值。简化公式可用于初始分层，但应通过历史回测或试运行验证结果。
平均交期 8 天并不意味着每次都在 8 天内到货。交期分布如果有明显长尾，少数延误就可能造成关键缺货。只关注均值，可能让团队误以为供应商稳定；只用最大值，又可能把罕见极端事件永久写进日常库存。
我会同时看交期均值、中位数、标准差、P90 或 P95 分位数，以及延误原因。若高分位交期主要由某种可识别的旺季或运输线路造成，可以考虑季节参数或线路策略，而不是让全年库存都按最坏情况配置。
历史销量是模型输入，不是未来保证。新品、停产品、价格变更、渠道迁移和产品替代都会让历史窗口失去代表性。若把新品上市前的零销量直接纳入平均，安全库存就会被压到接近零；若把停产前的峰值长期沿用，积压风险会升高。
对新品应采用相似品、上市计划和人工初始参数，并设定短周期复核；对退市品则应停止自动补货或设置清货策略。参数不是“算完就长期有效”，而是需要有生效日期、复核日期和责任人。
安全库存 500 件对高销量商品可能只够几天，对低销量商品却可能够一年。绝对量无法横向比较，也无法直接判断资金占用是否合理。建议并列观察库存覆盖天数、库存金额、缺货频率、过期或呆滞风险，而不是只考核“库存有没有达到安全库存”。
如果安全库存长期高于实际消耗，团队要追问是需求参数偏高、采购批量过大、交期信息失真，还是商品生命周期变化。单纯提高阈值以减少缺货，可能只是把问题从缺货端转移到资金和仓容端。
如果提前期相对稳定、需求波动明显，可以从“需求波动 × 提前期”模型开始。如果需求较稳定、交期波动较大，应重点估计实际交期分布。如果两者都在波动，可使用同时考虑需求和交期方差的模型。若需求有显著趋势、季节性或促销事件，常规安全库存公式应建立在需求预测误差上，而不是把整段历史销量的标准差直接代入。
需求预测误差是“预测值与实际值的差”，它比原始需求标准差更适合衡量预测模型未能解释的波动。对于有季节性的商品，若预测模型已解释季节变化，安全库存应缓冲的是预测误差；否则，模型可能把可预测的季节峰值也当成随机波动，导致缓冲过度。
建议按业务后果设定服务目标，而非先让系统给每个 SKU 一个默认值。可将商品分为关键保障、常规供货、可替代或按需采购等策略组，再为每组讨论服务目标。这里的分组不是固定答案，必须结合停线损失、客户承诺、替代品、供应商弹性和资金约束。
决策会议上，我会要求每个高服务目标都能回答两个问题：提高一个服务档位预计多占用多少库存金额？降低缺货的收益如何估算？如果这两个问题都没有数据，可以先通过小范围试运行建立基线，而不是把高目标当成“更安全”的默认选择。
异常值不应一律删除。一次极端销量可能是录入错误，也可能是大客户订单；一次超长交期可能是物流事故，也可能揭示供应商的真实尾部风险。合理做法是标记异常、分类原因、判断其是否应进入常规参数，并保留处理前后的计算结果。
参数更新不是越频繁越好。销量很低的 SKU，每天重新计算会让少量订单导致参数剧烈跳动；需求稳定、数据量足够的商品，可以按月或按补货周期刷新；旺季、供应商变更、新品爬坡期则适合更频繁复核。更新频率应和数据积累速度、业务风险相匹配。
我建议设置变更阈值，例如安全库存变化超过一定比例、再订货点变化超过某个数量、关键件服务水平下调时，需要人工审批。具体阈值由企业试运行确定，不宜把某个固定百分比包装成适用于所有行业的标准。自动计算可以提高效率，但重大变化应有解释和留痕。
下面是一组情景模拟数据，用于展示公式和工具设置，不是某家企业的真实经营结果：某 SKU 日均需求 42 件，日需求标准差 11 件，平均实际交期 8 天，交期暂时视为固定，目标周期服务水平取 95%，对应 Z 值约 1.645。
提前期平均需求为 42 × 8 = 336 件。提前期需求标准差约为 11 × √8 = 31.1 件。安全库存约为 1.645 × 31.1 = 51.2 件，按业务单位向上取整为 52 件。再订货点约为 336 + 52 = 388 件。
这个结果必须结合库存位置解释。若当前可用库存 210 件、在途 160 件、未履约订单 20 件，则库存位置可按 210 + 160 − 20 = 350 件估算，低于 388 件，触发补货评估。若系统只拿可用库存 210 件和阈值比较，可能发出更大的重复补货建议；若在途数据未及时更新，也可能漏掉实际供应。
继续采用同一组情景数据，假设实际交期均值为 8 天、交期标准差为 2 天。采用考虑需求与交期波动的近似公式，提前期需求方差为 8 × 11² + 42² × 2² = 8,024，标准差约 89.6 件。按 Z 值 1.645 计算，安全库存约 147.5 件，向上取整为 148 件；再订货点约为 336 + 148 = 484 件。
从 388 件到 484 件的差异不是“公式换了就该多备 96 件”的结论，而是提醒我们：交期标准差是否可信？2 天波动来自正常采购记录，还是混入了一次异常停运？交期起点和终点是否定义一致？如果这些问题没有核实，直接使用 484 件可能会形成过度库存。
同样地，如果交期标准差是由真实、重复出现的延误造成，忽略它也不合理。更好的动作可能是同时评估缩短交期、增加供应商承诺可靠性、改变采购频率和设置库存缓冲，而不是将全部风险都交给安全库存承担。
以九数云这类数据分析与可视化平台为例，我会把它放在“整理数据、计算参数、比较方案、追踪变化”的分析层来评估，而不是默认它替代仓库执行系统。实际可用的数据连接方式、计算能力、权限控制和写回方式，需要依据企业当前版本、数据源及部署方案向服务方核实。
一个有用的分析看板，不应只显示“安全库存 148 件”。我会要求它能下钻到 SKU、仓库、供应商和时间区间，看到需求均值与波动、实际交期分布、计算窗口、服务目标、公式版本、异常标记和上次更新时间。管理者才能区分“参数真的需要提高”与“数据刚好混入一次异常”。
如果分析结果需要写回 ERP 或 WMS，建议先通过受控文件、接口或审批流程验证字段映射，确认 SKU 编码、单位换算、仓库范围、有效日期和空值处理。不要因为看板里的“件”看起来正确，就默认执行系统中的计量单位也一致。正式自动写回前，应先用一批 SKU 做并行对照，并保留回滚机制。
每次生成参数时，至少保存：计算日期、需求窗口、有效需求天数、需求标准差、交期均值和标准差、目标服务水平、公式版本、旧值、新值、变化原因、审批人和生效日期。若发生人工覆盖，还要记录覆盖前后数值、原因和预计复核时间。
这样做的价值不只是审计。两个月后缺货时，团队可以判断是需求突增、供应延误、预测偏差还是参数过期；库存积压时，也能查到某次服务水平调整是否造成影响。没有版本记录，复盘就会退化为“系统当时怎么算的没人知道”。
| 情景参数 | 固定交期基准 | 考虑交期波动 | 解释与使用边界 |
|---|---|---|---|
| 日均需求 | 42 件 | 42 件 | 情景模拟值，应以有效需求日计算并识别断货日 |
| 日需求标准差 | 11 件 | 11 件 | 假设需求波动可用标准差近似描述 |
| 平均交期与交期标准差 | 8 天；按固定交期处理 | 8 天；标准差 2 天 | 模拟交期波动情景，实际必须统一订单与入库的计时口径 |
| 安全库存 | 约 52 件 | 约 148 件 | 均使用约 95% 周期服务目标；模型条件不同，结果不可直接当成真实建议值 |
| 再订货点 | 约 388 件 | 约 484 件 | 等于平均提前期需求加安全库存；还需结合库存位置与补货策略执行 |
电子表格适合小规模试算、公式检查和与业务人员讨论参数。优点是上手快、改动透明，缺点是容易出现多版本、公式被覆盖、权限难以控制和刷新依赖个人。SKU 数量少、参数变化频率低、责任人明确时，表格可以作为阶段性工具；一旦多人协同、数据跨系统或需要稳定审计，就应评估集中化分析流程。
若继续使用表格，至少锁定公式单元格，分开原始数据、计算结果和人工调整区，保存版本号与更新时间，并避免通过复制粘贴覆盖历史结果。表格的最大风险不是公式不会算，而是业务人员不知道当前打开的是否为唯一有效版本。
ERP 或 WMS 通常更接近采购、收货、库存和调拨动作，适合承载再订货点、最小库存、补货建议或执行状态。选择时不要只看“支持安全库存字段”，还要核实字段定义、按仓库还是按物料配置、参数更新方式、审批能力、在途和预留如何计入，以及能否查看参数计算依据。
如果系统只能保存人工维护的固定阈值，可以先用分析层计算建议值，再经审批更新执行系统。若系统提供预测或补货算法，也应使用代表性 SKU 回测，确认需求截断、交期变动和单位换算处理方式。功能名称相似，不代表模型假设相同。
BI 平台的价值通常在于连接多来源数据、建立指标口径、按维度分析和呈现变化。以九数云为例，可以将其作为候选分析平台，重点考察是否能适配企业的数据源、权限要求、刷新频率和计算流程，并演示从原始采购及库存记录到 SKU 参数的完整链路。功能清单应以供应方当前说明和实际测试为准，不宜只凭产品介绍推断其能完成自动补货执行。
我会让候选平台现场回答几类具体问题：能否追溯某个 SKU 的参数输入；数据刷新失败是否提示；同一指标能否按统一口径复用；是否记录计算逻辑版本；权限能否限制成本或供应商信息；结果能否以受控方式交给执行系统。若这些问题无法演示，即使看板美观，也未必适合承担库存决策分析。
| 对比维度 | 电子表格 | ERP 或 WMS | BI 或分析平台 |
|---|---|---|---|
| 适合承担的角色 | 小范围试算、参数核对 | 库存记录、补货执行与业务状态 | 跨系统分析、趋势诊断和管理看板 |
| 主要优势 | 灵活，验证成本低 | 接近交易流程，便于落地动作 | 便于统一口径、切片分析和追溯原因 |
| 主要风险 | 版本分散、误改公式、人工刷新 | 算法透明度和跨系统数据完整性可能不足 | 若无写回与审批链，可能停留在展示层 |
| 上线前重点验证 | 权限、版本、公式锁定和数据校验 | 库存位置定义、字段逻辑、审批与回滚 | 连接能力、刷新、计算留痕、权限和结果交接 |
工具选型不需要追求“一套平台包办一切”。更务实的组合，可能是交易系统维护原始事实、分析平台生成并解释建议参数、执行系统负责审批后的补货动作。关键在于字段映射和责任边界写清楚，避免同一参数在三个系统中各自变化。
先不要急着全面自动化。选取一批有代表性的 SKU，覆盖稳定品、波动品、长交期品、关键件和近期断货品，建立数据字典和人工复核表。采用简单公式生成参考参数，由采购和仓库共同检查异常，记录每次调整原因。
这一阶段的优先目标是确认数据能否支持计算，而非追求全量覆盖。若历史需求不完整、供应商交期起止点不清，先补采集和定义。用一张透明的参数表试运行，往往比一次性购买复杂能力更容易发现业务问题。
先检查参数粒度。总仓安全库存不能自动等同于各仓安全库存，尤其是跨仓调拨时间较长、区域需求差异明显时。按 SKU 与仓库组合计算会增加参数量，但能暴露区域缺货和总量过剩并存的问题。
如果仓间可以快速调拨，可将调拨时间和调拨可用量纳入库存位置判断；如果调拨成本高或时效不稳定，应评估区域独立缓冲。跨仓配置需要同时看总库存、仓间分布和调拨时效，不能只把每个仓的阈值简单相加。
优先补全实际交期、未满足需求和缺货损失记录，并对关键物料单独管理。安全库存可以作为缓冲，但不是唯一方案。双供应来源、供应商交付考核、替代料认证、提前锁定产能、加急运输预案和采购周期调整，可能比长期增加库存更有效。
此类商品不宜直接依赖无人审批的自动调参。对服务水平下降、供应商交期变长、关键件参数大幅变化等事件设置升级提醒，并明确采购、计划、生产等岗位的响应责任。缺货损失越大，模型越需要透明和可追责。
不要用高服务目标掩盖需求预测问题。先看安全库存覆盖天数、库存金额、批次有效期、最小采购量和供应商交货频次。针对保质期短的商品，库存优化需要同时考虑过期损耗和补货周期；针对慢动销商品，可评估按需采购、减少采购批量、替代料共享或供应商寄售等方案。
在资金约束下，服务目标需要有选择地分配。优先保障缺货后果高、不可替代且供应恢复慢的商品；对有替代品、需求低频或客户可接受等待的商品，可以接受更低库存或更长等待，但要把服务承诺与销售规则对齐。
自动化不是成熟度的唯一指标。对关键件保留人工审核，有时比追求全自动更合理；对稳定、低风险、高数量 SKU，自动更新则可能显著减少维护负担。取舍的核心是错误发生时的影响范围，以及组织能否及时发现和纠正。
试点期间至少跟踪缺货发生次数、缺货持续时间、库存金额、库存覆盖天数、临时加急次数、参数人工覆盖率和参数刷新及时率。不要只看“缺货是否下降”，还要观察为此多占用了多少库存、是否出现新的呆滞，以及业务团队是否能解释参数变化。
一条可用于决策的参数记录，至少应能回答：它属于哪个 SKU 和仓库？基于哪段需求与交期数据？采用什么服务目标和公式？最近一次何时计算？与上次相比变化多少？谁批准？若结果异常如何撤回？这些不是额外文书，而是把公式变成可靠业务动作的必要条件。
对于模型暂时解释不了的商品，不要为了覆盖率而强行自动化。可以保留人工设置，但要求写明原因和复核日期。人工判断不是系统失败；没有记录、没有复核期限的人工判断，才会变成难以治理的隐性参数。
安全库存上线后，应按月或按业务周期复盘。若缺货集中在某类供应商，优先检查交期和供应协同；若库存占用上升但缺货没有改善，检查服务目标、批量和数据口径；若参数频繁大幅跳变，检查窗口长度、异常值和低销量商品的计算稳定性。
我不建议把某一个缺货率或库存周转目标设置成跨品类的统一考核值。指标必须按商品策略和业务承诺解释，否则团队会通过提高库存换取表面服务改善，或者为了压库存而把缺货推给客户。应同时看服务、资金、风险和执行效率。
配置安全库存时，我的核心判断是：公式决定“怎么算”，数据治理决定“算得像不像”，工具分工决定“能不能稳定执行”，复盘机制决定“错了能不能及时纠正”。只比较软件功能列表，容易忽略真正的失败点，主数据不统一、断货需求被当成零、交期只取合同值、参数没人审批，或分析结果无法进入补货动作。
下一步可以从一批代表性 SKU 开始：先统一数据定义，再同时计算固定交期与波动交期情景，比较建议值及其业务解释；随后在电子表格、现有 ERP/WMS 和候选分析平台之间做同样的验收测试。包括九数云在内的分析工具，可以重点评估数据连接、计算追溯、权限、刷新和结果交接能力，但具体适配情况应以实际演示和试点验证为准。
最值得配置的不是一个看起来精确的安全库存数字，而是一套能说明数字从何而来、何时更新、何时不该自动更新，并能把异常交还给责任人的机制。当这条证据链跑通后，再扩大 SKU 覆盖和自动化范围，通常比一开始追求复杂公式更稳妥。
我在梳理仓库补货规则时，发现同一个安全库存公式，换一组数据就可能得出差很多的结果。我不确定应该先用简单公式快速上线，还是等需求波动和采购周期的数据都完整后再配置；日常需要哪些工具才能把计算和执行接起来？
先把安全库存和再订货点分开：安全库存用于缓冲不确定性，再订货点还要覆盖采购提前期内的平均需求。需求波动明显、供应周期相对稳定时，可用“安全库存 = Z × 日需求标准差 × √平均提前期”；再订货点 = 日均需求 × 平均提前期 + 安全库存。
例如某 SKU 日均需求 20 件，日需求标准差 6 件，平均交期 8 天，目标服务水平约 95%（Z 取 1.645），安全库存约为 28 件，再订货点约为 188 件。这里假设需求日与日之间相互独立、交期基本固定；若促销或周末效应显著，直接套公式会低估或高估库存。
如果交期也有明显波动，可用“安全库存 = Z × √（平均交期 × 日需求方差 + 日均需求² × 交期方差）”估算。数据工具不必一开始就复杂：表格适合验证公式和异常值，进销存或 ERP 适合维护补货参数，仓储系统适合把库存、批次和库位执行连起来。关键不是工具数量，而是需求、交期和库存口径一致。
我准备给仓库搭建安全库存管理，手头既能用表格，也能申请系统功能，但不想为了自动化把错误规则放大。我该怎么比较这些工具？哪些情况下表格够用，哪些信号说明该迁移到系统？
可按“计算、审批、执行、追溯”四件事比较，而不是只看有没有安全库存字段。表格容易检查公式，适合 SKU 少、参数变更不频繁的试算；进销存或 ERP 通常更适合管理供应商、采购提前期、补货点和采购建议；仓储系统更侧重账实、批次、库位与作业记录，未必负责预测需求。
工具适合场景主要风险 表格小规模试算、规则验证版本冲突、手工漏更新 进销存或 ERP采购与库存参数联动主数据错误会持续生成错误建议 仓储系统库存执行、批次和库位管理不能默认具备需求预测能力 我的判断是先用表格跑通一轮，再决定系统化：连续几周出现多人维护、参数来源说不清、补货建议无法追溯，才是迁移的强信号。
上线前拿同一批 SKU 对照人工计算与系统结果，逐项核对单位、在途库存、已分配量和交期口径；只要这些字段不一致，自动化并不会让结果更可靠。
我担心把公式算出的数字直接填进系统后，系统会把包装规格、在途货和缺货订单都算错。我想知道配置时要检查哪些字段，尤其是最小采购量、补货周期和不同 SKU 的服务水平该怎么处理？
配置前先统一口径：需求单位要与库存单位一致，采购提前期要明确是自然日还是工作日，需求数据要剔除退货、一次性项目单等非典型记录。再确认工具中的可用库存是否已扣除冻结、质检和已分配数量，并确认在途采购是否会计入库存位置。安全库存通常不是最终下单量。
系统建议量还要结合库存位置、再订货点、采购包装倍数、最小起订量和补货周期处理。例如计算建议补 37 件，但供应商按 12 件一箱供货，实际下单可能需向上取整到 48 件；如果系统把起订量当成安全库存，库存过高时就很难定位原因。不建议所有 SKU 使用同一服务水平。
高缺货损失、替代性弱的关键件可以设置较高目标；低价值、易替代且过期风险高的物料，应关注持有成本。首次配置可挑 10，20 个典型 SKU 做影子运行，人工核算公式、系统建议和实际下单量，确认差异来自取整规则还是数据问题后再批量启用。
我不想把安全库存设好后就长期不管，但也担心每周改参数让补货忽高忽低。我该用什么频率复核？除了缺货次数和库存金额，还有哪些数据能判断是公式不合适，还是供应商交期或需求本身变了？
复核频率应跟业务变化速度走：稳定、低波动 SKU 可按月或按季度检查；新品、季节品、促销品和交期不稳定物料，应在活动前后或供应异常后单独复核。不要因为一次缺货就立即提高所有安全库存，先判断是需求突增、交期延误、收货未入账，还是可用库存口径错误。
建议同时观察缺货率、库存周转或覆盖天数、预测误差、实际交期分布，以及系统建议量与实际采购量的差异。若缺货持续发生但需求预测误差稳定，重点查供应提前期和服务水平；若库存不断增加而缺货没有改善，重点查单位、冻结库存、在途重复计算、最小起订量和过期需求数据。
一次实用的复核方式是按 SKU 对比最近 8，12 周的日需求和实际交期，并记录参数修改前后的缺货与库存变化。每次只调整一类变量，例如先更新交期，再观察结果；否则同时改服务水平、需求窗口和起订规则，出了问题也无法判断是哪项设置造成的。
读者评论
把断货日的零出库直接算成零需求，这个问题很容易被忽略。将可售库存和订单取消记录放在一起看，比单纯拉长销量统计窗口更有用。
文中区分周期服务水平和满足率很关键。我们之前只调高服务目标，库存增加了，却没弄清客户实际满足情况；后续确实需要结合缺货量做回测。
实际交期的起止口径值得提前定好，尤其是分批到货和待质检库存。如果只按供应商承诺天数计算，再订货点看着精确，执行时仍可能缺货。