我去年年底接手了一个做小家电的跨境卖家，月销大概两千万，遇到的问题是：后台库存显示有货，前台也敢挂“次日达”，但仓库连续三天发不出货，超时订单一路飙到 17%。我把订单、库存、物流三套系统的数据拉出来对了一遍，发现根本问题不在仓库没货，而是“数据库存发货适配”这个环节从一开始就做错了，库存数据告诉发货模块“你有货”，但发货模块拿到的是物理库存数字，完全不知道这些货已经被预售订单锁定，也不知道可用库存只够撑一天。
这个案例让我意识到一个关键判断：发货时效数据不是业务结果报表里的一个数字，而是库存调配决策的“报警器”。这篇文章会把我在这个项目里总结的设计框架、字段规则、判断节点和实施坑位都展开讲清楚，给正在做库存-发货联动的运营、产品和供应链负责人一个可以直接落地的参考。文章核心就一句话：库存决定能不能接单，时效数据决定库存该怎么调。
我做了这么多年供应链数据项目，见过最多的状态是：订单模块、库存模块、物流模块各跑各的，库存给订单喂“有没有货”，订单给物流喂“发什么货”，物流给管理层喂“发没发完”。这个链条是单向的，时效数据到了最后一步就断掉了，库存调配听不到来自发货端的任何声音。这是“发货适配”做不好的根因。
真正健康的联动关系是双向的。库存状态决定你能不能承诺时效，而实际发货表现又反过来告诉你库存结构哪里出问题了。比如某个SKU在这个仓库的时效达成率连续三天跌破90%，这说明什么？不是快递变慢了，而是这个仓的库存结构失衡，畅销SKU的安全库存设置不合理，或者调拨补货的频次跟不上消耗速度。
我用一张图说明传统模式和我要讲的联动模式之间的差异：
无论你的系统是自研还是用的现成ERP，要在“发货适配”上做出真正有用的联动，必须在这三个节点上做设计：
接单前：承诺校验。 系统要用“可售库存”而不是“物理库存”去校验有没有能力承诺时效。可售库存 = 物理库存 – 锁定库存 – 安全库存预留。这一步是用库存数据去管住时效承诺的入口。
接单后：时效触发复查。 当某个仓库某个SKU的实际发货时效滚动均值超过承诺时效的1.2倍时，系统要自动触发一次库存结构复查，把问题暴露在成为事故之前。
调配前：时效热力决定优先级。 当多个SKU同时缺货时，谁先调拨？不是按销量排，而是按“缺货造成的时效伤害大小”排。一个SKU虽然销量不高，但它已经被承诺了24小时内发货，超时赔付比例高，就应该优先调拨。
管理层看的时效报表是结果，库房看的时效明细也是结果，但在这两层结果之间缺少一个“触发动作”的机制。我做的核心设计就是把这个机制建起来，时效数据每四小时滚动计算一次，一旦触发阈值条件，系统自动生成调拨建议单，推给供应链负责人确认。这样时效数据就从“事后看”变成了“事前用”。
先交代一下上面那个小家电客户的完整背景。他们的业务是典型的跨境小家电，SKU 八百多个，国内三个仓，海外两个仓。日常还好，一到大促阶段就出乱子。
去年他们的会员日大促，第一天订单量暴增到日常的4.5倍。运营看到后台库存充足，直接把所有SKU都开了“次日达”承诺。结果第二天仓库发现，某款热门榨汁机的物理库存还有3200台，但其中2400台已经被预售和待发货订单锁定了，真正可用的只有800台。而这个时候前台还在不断涌入新订单，承诺24小时内发货。后续的结果就是：三天内超时未发订单累计到4200单，赔付金额超过16万。这不是仓库不干活，是库存数据和发货承诺之间的“适配校验”完全没有。
我把三套系统的库存数字列出来，后台库存管理模块显示可售库存充足，发货WMS系统显示物理库存够，ERP的订单模块用的是“不锁定”的裸库存。三个系统三个口径，没有一个统一的计算层。最终前台展示的“次日达”是基于ERP裸库存算的，也就是物理库存3200台。但发货WMS看到的是已经被拣货单和预订单占用的部分，问题就出在这。
很多团队说“我做过库存同步了”，但同步只是把库存数字从一个库复制到另一个库，真正需要做的是“适配”，发货承诺必须基于净库存来算，库存数据必须知道发货端正在发生的超时风险。这两个方向的信息流缺了任何一个，“发货适配”都不成立。我在这个项目里做的第一件事，就是统一口径：建立一层中间计算逻辑，把物理库存、锁定库存、在途库存、安全库存汇总成统一的“可承诺库存”，再把这个数字作为前端“次日达”开关的唯一依据。
以下误区不是从教科书里抄来的，是这几年做项目踩出来的。
这是一个最常见的误区。库存同步解决的是“数据一致性”，发货适配解决的是“业务语义一致性”。同步是手段，适配才是目的。比如你用中间表每小时同步一次库存数据，但同步过来的“物理库存”在发货模块里被当成“可承诺库存”来用，那你做一百次同步也没有用。我后来的做法是，在同步层之上再加一个“语义映射层”，把不同来源的库存字段翻译成发货模块能听懂的“可承诺库存”“锁定期库存”和“不可用库存”。
很多管理层看时效，只看一个“平均发货时长”的指标。这个数字极其有欺骗性。我见过一个仓库的平均发货时长是18小时，看起来达标了，但分布数据一拉开，发现40%的订单是6小时内发出去的，另外25%的订单平均拖了42小时才出库。均值是正常的，尾部是爆炸的。原因是这个仓库有一条爆款SKU的拣货路径设计不合理，大部分订单能快速发出，但这个SKU的每次拣货都要多花3个小时。只看均值，这个问题永远不会被发现。
多仓场景下，当B仓缺货而A仓有货时，很多系统的调拨逻辑只看“缺多少”，A仓调过去200台够不够。但这里面漏了一个关键变量：B仓的承诺时效还剩多少时间窗口。如果B仓这个SKU已经被承诺24小时达，而A仓到B仓的运输要36小时，那你调拨的数量就算填满了缺口也救不了时效。正确的做法是，调拨的逻辑必须带上“时效约束条件”，只把调拨作为一种有限的应急手段，同时开启订单拦截或承诺时效升级。
联动规则不是上线就完事的。我见过一个客户，规则跑了一个月还挺好，第二个月开始误报率暴增，因为“时效滚动均值”的窗口设置不对，大促期间时效天然变差，系统每天都在触发调拨建议，供应链团队索性把所有告警规则关了。这个问题的本质是缺少一个“反馈闭环”来校准规则阈值。我把监控体系拆成三层：第一层看规则触发率是否正常，第二层看触发的调拨建议准确率，第三层看执行后的效果有没有达到预期。每一层都要有明确的指标上限和人工复核机制。
最后一个误区是把调拨当成解决缺货的唯一手段。调拨本身消耗物流成本和管理精力，而且仓间调拨通常需要1-3天才能完成。如果某个缺货SKU的时效窗口只剩8小时，调拨根本来不及。这时候你可以选择：延长前端承诺时效、对在途客户做补偿、或者将订单转移到可达仓。调拨应该只是决策矩阵里的一种选项，而不是唯一的操作。判断标准是：调拨的时效收益、客户体验收益、物流成本三者的关系，是否比其他选项更优。
讲几个核心方法论。这部分是我在多个项目中沉淀下来的，不是哪本书上的模型，而是经历过失败和修正后的执行框架。
要谈联动的第一步，是让所有模块都用同一套库存语言。我在这个项目里把库存统一成四种语义，每一种都有明确的业务定义和计算边界。
| 库存类型 | 业务定义 | 计算公式（简化） | 发货模块的用途 |
|---|---|---|---|
| 物理库存 | 仓库里实际存放的实物数量 | 期初入库 + 采购入库 – 出库 – 报废 | 盘点差和实物管理的依据 |
| 可售库存 | 可参与新订单承诺的净库存 | 物理库存 – 锁定库存 – 安全库存预留 | 前端“次日达”开关的唯一校验值 |
| 锁定库存 | 已被订单占用但未出库的数量 | 待发货订单 + 预售订单 + 拣货中订单 | 防止超卖和重复承诺的关键输入 |
| 在途库存 | 已下单采购但未入仓的数量 | 采购单数量 – 已入仓数量 | 长期补货计划的数据支撑 |
这四个口径在现有ERP里通常散落在不同字段或表格中。要做适配，就必须建一个统一的计算层，让四个口径的数据在同一个时间维度上对齐。
下面这个字段设计是我在几个项目里打磨出来的版本，不同的ERP可能在字段名上有所差异，但你至少要保证有这些维度的数据。
— 库存-时效联动核心字段设计（参考版本）
CREATE TABLE inventory_fulfillment_sync (
sku_id VARCHAR(50) COMMENT 'SKU编码',
warehouse_id VARCHAR(20) COMMENT '仓库编码',
physical_stock INT COMMENT '物理库存数',
locked_stock INT COMMENT '锁定库存数（待发货+预售+拣货中）',
safety_stock INT COMMENT '安全库存预留数',
available_stock INT COMMENT '可售库存数', -- 末端由物理-锁定-安全计算得出
in_transit_stock INT COMMENT '在途库存数',
promise_delivery_hours INT COMMENT '承诺时效等级（小时）',
actual_sla_speed DECIMAL(6,1) COMMENT '实际发货时效滚动均值（小时）',
sla_achievement_rate DECIMAL(5,2) COMMENT '时效达成率（近7天滚动）',
overdue_order_rate DECIMAL(5,2) COMMENT '超时订单率（近7天滚动）',
allocation_suggestion_status TINYINT COMMENT '调拨建议状态：0未触发/1待确认/2已执行/3已关闭'
);字段设计好之后，真正让联动跑起来的是业务规则层。我常用的触发条件逻辑如下，核心是将时效数据和库存结构数据组合成“复合判断”，而不是单看库存量：
— 调拨建议触发条件（简化示例）
— 条件1：某SKU近7天时效达成率低于90%
— 条件2：该SKU可售库存预计覆盖天数小于3天
— 条件3：同区域其他仓库存在可用库存
三条同时成立时，系统生成调拨建议单，推送给供应链负责人确认。建议单里包含调拨SKU、调拨数量建议、来源仓、目标仓、预计时效差。如果条件1和条件2成立但条件3不成立，系统不生成调拨单，而是触发“补货建议”或“时效承诺升级”方案。
同一条规则不能适用于所有SKU。我给客户做了一套分层的阈值设计逻辑：高价值、高复购的核心SKU，时效达成率低于95%就触发复查；普通SKU，低于85%才触发；清仓和尾货SKU，只看超时赔付率，不看达成率。这样做的原因是，不同SKU的缺货和超时带来的业务伤害差异很大，用同一套标准只会让规则变得“要么过于敏感要么过于迟钝”。
这部分用实际数据来讲。为了避免涉及客户保密信息，所有数据都经过处理，但是结构是真实的，变化趋势是有代表性的。
我们第一版规则上线后，前两周误报率非常高，系统每天生成12到18条调拨建议，但供应链负责人复核之后，真正值得执行的只有3到4条。原因是“时效达成率”的滚动窗口设得太短，碰到大促余波，数据波动大，触发条件过于敏感。后来我们把滚动窗口从3天拉长到7天，同时增加了一个“单均超时分钟数”的辅助条件，误报率立刻降了下来。
稳定之后的数据表现非常明显。超时订单率从上线前的17%降到9.4%，调拨响应时间从平均6小时缩到1.5小时。更重要的是，这个阶段系统开始主动发现一些客服团队反馈了很久的问题，比如某个辅仓的某个SKU连续五天时效达成率低于80%，之前因为缺货量不大没人关注，但时效数据把它“钉”了出来。后来核查发现是这个辅仓的排班出了问题，拣货人员经常不在岗。
60天结束时，我拿到了几组关键数据：超时订单率稳定在6.2%，库存周转率从4.2次/季度提升到4.8次/季度，因为减少了大量无效调拨，月均调拨次数减少了31%。最终带来的是这个季度末的客户留存率比上个季度提升了4.3个百分点。我不敢说全是联动规则的功劳，但时效稳定性绝对是复购的重要变量之一。
最值得推荐的做法不是技术层面的字段设计，而是在业务层面把“平均发货时长”这个指标从考核KPI里拿掉，换成了“时效达成率+超时订单分布”的组合指标。这个改变让运营团队的目光从“仓库整体表现”转向“问题SKU和问题仓库的具体表现”，数据信号开始真正指导决策。
落地不一定是上一套完整系统。我建议分阶段、按场景推进，每个阶段的投入和收益不同，你的选择取决于当前最痛的环节在哪里。
如果你的团队现在连每天的时效报表都需要人工从WMS导出来，再用Excel拉透视表，那就先不要聊联动规则。先做基础的数据采集和可视化，把“物理库存”“可售库存”“时效达成率”三个核心指标统一口径，做成每天上午自动推送的简报。我见过太多团队一上来就想建自动化规则，结果数据源都不稳定，规则跑出来的全是垃圾建议。
这一阶段的核心动作：统一库存口径，建立每日时效简报，让数据先“看得见”。
如果数据已经有了，但联动还没有建立，那就选出10个核心SKU做试点。这10个SKU的标准是：高复购、高毛利、时效敏感。针对它们单独配置时效触发阈值和调拨建议逻辑，跑一个月看效果。试点成功后，再逐步扩展到全量SKU。
这一阶段的核心动作：搭建“接单前校验+接单后复查”的双节点规则，用试点SKU验证判断逻辑。
多仓场景最大的问题是“各个仓自扫门前雪”，A仓缺货宁可让订单超时，也不愿意向B仓调拨，因为觉得调拨麻烦。我的建议是先建立一张“跨仓库存总览”视图，让每个仓的管理者都能看到其他仓的可售库存，再配置调拨建议规则。这个动作不复杂，但能直接打破信息孤岛，为后面的自动化铺路。
如果你的问题不是超时，而是经常性断货，那说明你的补货计划缺了一个关键输入，消耗速率。补货量不能只看历史销量，还要看时效数据里的“动态消耗速度”。我的做法是基于最近7天的实际发货速率、当前可售库存和补货在途天数，计算一个“预计断货时间点”，再把这个时间点和采购周期做对比，确定补货触发点和补货量。
这个部分讲讲我在实践中的取舍判断，因为数据联动这事太容易掉进过度设计的坑。
调拨可以救时效，但调拨本身要花钱。我的判断标准很简单：如果调拨总成本（物流成本+管理时间+货损风险）高于该SKU预期超时赔付成本 + 客户流失风险的1.5倍，就不该调拨，而是做补偿方案。 当然每个企业的毛利结构不同，这个倍数只是一个起点，需要根据你的实际数据调整。
我在前几个项目里犯过一个错：过度追求自动化，把调拨建议设为自动执行，结果第二周就出问题了，系统误判了一个SKU的库存状态，自动发起了一笔不必要的跨省调拨，光运费就花了两千多。从那以后，我坚持“建议自动化，执行人工确认”的原则。系统生成建议单，供应链负责人一键确认或驳回，驳回的理由会作为反馈数据回到规则引擎里做阈值修正。这个取舍让系统的误判变成了学习素材，而不是业务事故。
时效联动带来的是短期履约质量的提升，但库存结构本身如果没优化，比如某些SKU在两个仓长期保持高库存低周转，那联动规则也只是治标。每季度要回过头来看一次：哪些SKU的库存结构是因为联动规则的调拨建议被优化了，哪些SKU其实应该降价清仓而不是继续调拨。这个取舍必须由业务负责人来做，技术规则替代不了商业判断。
联动规则需要数据，但实时数据往往拿不到，或者成本太高。比如“在途库存”的实时状态，需要和采购系统打通，不是每个ERP都能提供。我的取舍原则是：核心字段采用准实时同步（每30分钟一次），非核心字段采用小时级甚至日级同步。 时效数据里的“滚动均值”用每4小时计算的版本，不用实时流，因为调拨决策本身需要一个小时的响应窗口，精度太高没有意义，反而增加系统压力。
最后一条取舍也是最重要的：联动规则能不能被一线同事听懂，决定了这套系统能不能活下来。我见过一个团队把补货逻辑写成了包含17个参数的多因子模型，结果供应链负责人完全看不懂，每次建议都靠猜。后来我们把模型简化成“三个第一”原则：先看时效伤害最大的SKU，先调距离最近的仓，先补周转最快的货。模型一简化，执行率立刻翻了三倍。规则再聪明，人不用，就是零。
这篇文章的核心观点始终是一句话：库存决定能不能接单，时效数据决定库存该怎么调。 发货时效数据不是拿来发日报的，它是库存调配的预警传感器。如果你读完之后只记住一件事，我希望是“可在接单前做承诺校验、在接单后做时效复查、在调配前做优先级排序”这三个判断节点，把任何一个节点做实，你的库存和发货就能从“各说各话”走向“互相配合”。
我的建议是，不要一上来就铺开全量SKU的联动方案。先选10个核心SKU，明确库存口径，设好三个判断节点，跑四个星期，看超时订单率和调拨响应时间的变化。如果你需要一套可以直接拿来用的字段模板或触发规则示例，可以参考我在第四部分给出的SQL结构，把它改造到你自己的系统里。数据联动这件事没有完美的终点，但一定有一条值得启动的起点。
我先说结论：库存和发货对不齐，90%的情况不是技术问题，而是两个模块对“库存”这个词的理解根本不一样。库存模块关心“仓里实际有什么”，发货模块关心“现在能承诺什么”。这两个口径如果不做翻译，前端展示的可用量就是一张假地图。我曾接手过一家服装电商的库存改造。
他们的ERP库存表里只有一个字段叫“库存数量”，发货模块直接读取这个字段去计算可承诺时效。结果大促期间，仓库里有两万件商品是质检不合格品，系统却把它们当成正常库存去承接订单，最终超时订单超过四千单。后来花了三周重新梳理，核心动作是把库存拆成五个口径：物理库存、可售库存、锁定库存、在途库存、劣质库存。
真正的对齐逻辑，是要给每个库存口径配一个“发货可用度”。物理库存不代表可用，可售库存才是发货模块能用的数字。我把可售库存的定义定为：物理库存减去锁定库存、劣质库存、调拨预留库存。这个公式听上去简单，但每家公司对“锁定”的触发条件差异巨大，极容易漏掉“预售订单扣减”和“跨仓调拨在途”两类隐性锁定量。
落地时建议用一张标准口径映射表来强制对齐。具体字段包括：SKU_ID、仓库_ID、物理库存量、锁定库存量、在途入库量、调拨预留量、质量异常量、可售库存量、承诺时效等级。其中可售库存量必须由系统实时计算，不允许人工维护。至少每五分钟同步一次到发货模块，大促期间要缩短到一分钟。
最后要提醒的是，对齐不只是做一张表，还要做异常归因。每次出现库存与发货不一致时，要能追溯到是哪个动作切断了链路。比如调拨单创建后，库存模块做了扣减，但发货模块没有收到调拨预留的同步事件，就会出现“又欠又锁”的错乱。
所以我们后来规定：所有影响库存状态的操作必须向发货模块广播事件，而不是只更新一个汇总数字。这条规则让我们的库存差异率从7%降到了0.6%。
太多人把发货时效当成一个“月度考核指标”，但它本质上是一个高分辨率的供应链健康信号，应该按仓库、SKU、渠道三个维度去拆解。平均值是最大的信息杀手，因为它会掩盖结构性的恶化。我用一个真实案例来说明：某家零售商的两个仓库，A仓时效中位数1.2天，B仓时效中位数4.8天，合并统计的平均值是3天。
仅看平均值，你只会觉得“还行”，但B仓的履约承诺已经被击穿。我自己的监控体系里，发货时效看四个核心字段，而不是一个平均值。第一，超时订单占比：反映整体违约风险，超过15%就应该触发告警；第二，P90时效：代表最慢的10%订单有多慢，比平均值敏感得多；
第三，连续超时天数：单个SKU在某个仓库连续超时三天以上，往往不是物流问题，而是库存结构问题；第四，时效恶化斜率：用最近7天的P90时效做线性拟合，斜率为正且持续放大时，说明恶化的速度在加快。更关键的是要建立“时效信号等级表”。
我这里分享一套可复用的规则：当某仓库某SKU的P90时效连续3天大于承诺时效的1.2倍，标记为黄色预警，提示运营复查该SKU的安全库存；连续5天超过1.5倍，标记为红色告警，此时系统应自动生成调拨建议，通知对应角色的负责人确认。
这里注意，黄色做“复查”，红色做“行动”，不能越过黄色直接跳到红色，否则会出现大量无效调拨。另外，时效数据必须分桶存储。按“仓库×SKU×发货渠道”三个维度做聚合，而不是只汇总到公司层或仓库层。
因为同一个仓库可能同时服务天猫、京东、自有商城三个渠道，每个渠道的时效承诺不一样，混在一起统计完全没有预警能力。把均值拆成P90、超时占比和恶化斜率之后，变化很明显。原来发现库存结构问题需要等月度复盘，现在基本能在三天内定位到一个SKU和某个仓，然后触发补货或者调拨。这才是时效数据真正该做的事情。
看板解决的是“看见问题”，但要解决“响应问题”，必须把数变成动作。我见过太多团队，花三个月搭了一个精美的大屏，上面什么都有，但唯一的出路是“截图发微信群”。联动不是把数据放在同一页，而是让数据在正确的时间触达正确的人，并让他们做出正确的动作。
我梳理过大量案例，判断效率慢的堵点通常不在技术，而在三个衔接处。第一处是字段级关联缺失，时效表和库存表没有用“仓库ID+SKU_ID”作为联合主键对齐，导致两边数据无法在同一粒度下计算；第二处是缺少状态机判断，系统只展示数字，没有定义“什么信号对应什么动作”的规则；
第三处是流程上没有闭环，就算系统给出了建议，没有指定谁来审批，这个建议就永远挂在系统里。设计时要把触发逻辑放在一个独立的规则层，而不是塞进库存模块或发货模块的代码里。这样当库存逻辑调整时，不需要改动联动规则，反之亦然。规则层的作用是消费时效数据和库存数据，按照预置条件输出一个“调配建议单”。
我举一个可落地的触发条件示例：当某仓某SKU的最近7天P90时效大于承诺时效的1.2倍，且当前可售库存覆盖天数少于3天时，系统生成建议单，建议从指定仓库调拨补货，数量为建议安全库存与当前可售库存的差额。在实施上，我建议分两步走。
第一周先做只读模式：规则层计算完建议后只发送消息，不生成正式单据，让运营验证建议的准确度；连续运行两周后，如果准确率超过85%，再开放自动生成草稿单，仍然保留人工确认环节。直接一步到位自动调拨的风险极高，因为系统对市场变化的判断不可能完全替代人的经验。
联动有没有做成的验收标准，就一句话：当库存出现结构性缺口时，从信号产生到第一个调配动作生成，耗时是否控制在15分钟内？如果还需要运营打开看板、导出表格、自己算一遍，那说明联动还没完成。
这个问题的本质是：调拨资源有限，要把有限的库存给“最需要救火的仓”还是“最有机会增长的仓”。我的结论是，两者都不作为唯一的排序键，调拨优先级必须是一个综合分数，时效数据在其中起到“风险修正系数”的作用，而不是主排序键。我踩过这个坑。
之前我们只按时效严重度排序，把大量库存优先调到发货最慢的仓，结果发现那个仓的缺货不是因为需求大涨，而是因为销售趋势本身在下滑，调过去的货到了之后变成滞销库存，产生的仓储成本和资金占用远超调拨成本。这件事让我意识到，时效数据反映的是“当前痛苦”，销售趋势才是“未来回报”。
后来我把调拨优先级设计成一个量化打分框架，包含三个维度：需求端权重40%看未来14天销量预测的增长斜率；供给端权重30%看目标仓当前可售库存覆盖天数；风险端权重30%看时效恶化程度，用P90时效与承诺时效的比值来打分。这三个维度加权后得到调拨优先级得分，分数越高越优先处理。
时效数据在这个框架中的具体用法是设置“一票否则”的启动条件。例如某仓某SKU的P90时效连续三天超过承诺时效的1.5倍，即使需求趋势评分很低，也必须发起调拨评估，目标是维持基本的履约能力，而不仅仅是追求库存周转效率。换句话说，时效数据负责触发，销售趋势负责定调拨量。
调拨量也不是缺多少补多少，而要参考时效严重度做缓冲叠加。如果时效正常，建议调拨量等于安全库存缺口的1.2倍；如果时效严重恶化，建议加到1.5倍。这个缓冲系数解决了跨仓调拨过程中出现的需求波动风险，同时也避免了一旦调拨时效超过两天而带来的二次缺货。记住一个原则：时效数据的价值是预警和修正，不是主导。
如果你把时效权重放到最高，会得到一张“哪里最乱就调哪里”的救火地图；把销售趋势和时效数据结合起来，才能得到一张“现在处理哪里最有价值”的经营地图。
读者评论
作为电商运营，文中提到的“物理库存”和“可售库存”口径不一致的问题太真实了。我们大促时也踩过类似的坑，后台显示有货，前台敢承诺时效，结果仓库发不出货，赔偿和客诉全压过来。这篇文章把“可售库存=物理库存-锁定-安全预留”这个公式讲透了，后续我们准备直接把这一层计算加到系统里，避免再靠人工去判断。
做供应链的朋友可以重点看第三部分那五个坑，尤其是“只看均值不看分布”那条。我们自己仓库的平均发货时长一直很健康，但拆开看尾部订单严重超时，和文章里描述的直方图几乎一样。现在准备把时效分布的分位数纳入监控，而不是只看一个平均数，这样才对调配有真正的指导意义。
文章把“调拨决策”从单纯的数量逻辑扩展到了时效约束和成本性价比，这点很启发我。以前我们B仓缺货就从A仓调，很少算调拨在途时间和承诺时效窗口的关系。按照文中“调拨只看缺货数量，不看时效风险”的反例，我们打算在ERP里增加一个时效约束字段，把调拨建议改成基于剩余时间窗口的决策。
中间表格里那组对比数据挺有说服力：超时订单率从17%降到6.2%，调拨响应时间从6小时缩短到1.5小时。我们也是月度两千万左右体量，目前系统之间基本是单向信息流，看完这篇文章准备推动产品团队先做“统一可承诺库存”的中间层，把发货时效数据作为库存调拨的触发信号，而不是等最终报表出来再补救。