交付管理 · 交期承诺 · 跨部门协作

交付管理 Know-how：
让交期承诺有据可依，告别全公司救火模式

销售对客户承诺 15 天交付，第 14 天才发现物料不够。交期承诺不是销售一个人的决定——它需要库存、采购在途、采购周期三组数据支撑。但大多数中小企业，承诺环节没有系统支持，销售凭感觉拍交期，全公司跟着救火。本文拆解交期承诺的四个断点，给出一份让承诺有据可依的修复路径。

可发库存采购在途需交付对比供应商直发交期承诺

超兔一体云 · 产品团队 / 22 年企业数智化一线观察 · 技术和场景系列

发布时间：2026-09-04 14:23

01现场：第 14 天才发现物料不够

一家做五金配件的工贸企业，销售老李接到客户电话，要150个产品，问15天能不能交。老李打开系统查了一下库存——显示200个，客户要150个，够了。老李回客户："15天，没问题。"

老李查库存的这个动作，不到30秒。系统里200这个数字，他没多想——系统显示有货，那就有货。但他不知道的是，200这个数字是怎么来的：50个是实打实在货架上的，150个是采购单已下但还没到货的"采购在途"。系统把这两部分加在一起显示总量200，但没拆开告诉老李"其中150个你发不了"。

第12天，老李查了一下出库进度，发现还没出库。问仓库，仓库说："你这单的出库任务排到后天了，没问题。"老李放心了。

第14天，客户打电话催："明天能不能发？"老李去催仓库，仓库翻了出库任务说："这单关联了采购单，采购的货还没到，我们发不了。"

老李愣了。他查库存的时候显示 200 个，但那 200 个里面有 150 个是采购在途——采购单已经下了，供应商还没发货。他看到的是"账面库存"，不是"可发库存"。账面上有 200 个，实际能发的只有 50 个。差的 150 个，要从采购到货、入库、质检之后才能发。

老李回客户："可能要再等几天。"客户在那头沉默了三秒，说："我找别家问问。"

一个 15 天的承诺，在第 14 天崩了。崩的原因不是某个人犯了错——仓库没出错，采购没出错，销售也没出错。每个人都做了自己该做的事，但没有人看到全链路。老李查的是库存，仓库看的是出库任务，采购追的是供应商发货——三个人的信息各自正确，合在一起才发现对不上。

02交期承诺的"单方面决策"问题

交期承诺，表面看是销售对客户说一个日期。实际上，这个日期是三个部门联合算出来的：库存有多少能发、采购的货什么时候到、仓库什么时候能出库。这三个数字，销售承诺时一个都没查。

这不是老李不负责。是他没有工具查——库存查询只显示总量，不显示多少是可发的、多少是采购在途的；采购在途数据在采购员手里，不跟销售共享；采购周期（从下采购单到货到仓库要多久）在采购员脑子里，没有系统记录。

于是销售承诺交期，靠两个东西：经验和运气。经验告诉他"这个产品一般 15 天能到"，运气决定"这次是不是一般"。运气好，承诺兑现了；运气差，第 14 天崩盘。问题不是销售不靠谱，是承诺环节缺了一层系统支持——承诺之前，需要有人把库存、在途、周期三组数据拉到一起算一遍。

03交期承诺的四个断点

从销售对客户说"15 天"到货发出去，中间有四个信息断点。每个断点都可能让承诺变成空头支票。

断点一 · 库存：账面数 ≠ 可发数

销售查库存，系统显示 200 个。但 200 个里面，可能有 150 个是采购在途——采购单已下，供应商还没发货，系统里算作"库存"但实际不能发。销售看到的是账面库存，客户要的是可发库存，两个数字之间的差，就是采购在途的数量。这个断点与前篇《库存不准》一脉相承——库存数据本身的准确性是基础，但即使数据准确，"账面"和"可发"之间仍然隔着一道缝。

伤的是谁：对客户做了承诺的销售，和最终发不出货的仓库。

断点二 · 在途：采购的货什么时候到

采购单下了，供应商确认了，但什么时候发货、什么时候到仓库——这个信息在采购员手里，不跟销售共享。销售不知道在途的货今天到还是下周到，就无法判断"15 天"这个承诺能不能兑现。在途数据不透明，是交期承诺最大的盲区。

伤的是谁：承诺了交期却无法跟踪兑现进度的人——销售。

断点三 · 采购周期：从下单到到货要多久

库存不够，需要采购。从下采购单到货到仓库，要多久？这个周期决定了交期的下限。但采购周期没有系统记录——它散在采购员的脑子里，靠的是"这个供应商一般 7 天发货"的经验判断。经验没有数据校验，就不可能精确——供应商有时候 5 天发货，有时候 10 天，采购员取一个平均值告诉你"7 天"，但你这次可能恰好赶上了 10 天。

伤的是谁：基于错误的周期估算做承诺的销售，和被催到崩溃的采购。

断点四 · 跟踪：状态变了没人通知

承诺之后不是结束，是开始。物料状态在变化——供应商发货了、到仓库了、质检通过了、可以出库了——每一步变化都应该通知到销售。但大多数中小企业没有自动通知机制：采购员收到货不告诉销售，仓库入库不告诉销售，销售不知道自己的承诺能不能兑现，只能一个个去问。跟踪断点让承诺变成了盲盒——销售不敢主动联系客户，因为不知道该说好消息还是坏消息。

伤的是谁：在不确定中等待的销售，和等不到回音的客户。

04三层根因：为什么交期总靠拍脑袋

道理不复杂——承诺之前查一下库存、问一下采购、算一下周期，谁都知道更靠谱。可为什么中小企业的交期承诺还是停留在"拍脑袋"上？原因分三层。

流程层 · 承诺无"交期计算"环节

中小企业的标准流程是：客户问交期→销售凭经验报一个→下单→等出货。整个流程里没有"交期计算"这一步——没有人把库存、在途、采购周期拉到一起算一遍。流程缺这一步，不是忘了加，是加了之后执行不动：库存数据不够准、在途数据不透明、采购周期没有记录——三个前提都不满足，"交期计算"就是空转。

数据层 · 三组数据散在三个部门

库存数据在仓库系统里，采购在途数据在采购员手里，采购周期在采购员脑子里。三个部门各有各的系统或记录方式，数据不互通。销售承诺交期时，需要跨三个部门拉数据——但在中小企业，跨部门拉数据的成本比"拍脑袋"高得多。不是不想查，是查的代价太高。

组织层 · 销售-采购-仓库各自为政

销售管接单，采购管买货，仓库管发货——三个部门各有各的 KPI，信息不共享是常态。销售不愿意提前告诉采购"可能要下单"（怕采购先安排了别的事），采购不愿意把供应商到货时间告诉销售（怕销售催），仓库不愿意把出库排期告诉销售（怕销售插单）。信息不共享不是技术问题，是部门博弈问题——每个人都在保护自己的节奏不被打乱。

05修复路径：从"凭感觉"到"有依据"

修复的方向，是在销售对客户承诺交期之前，加一步"交期计算"——把库存、采购在途、采购周期三组数据拉到一起，算出"最早什么时候能发"。超兔一体云的需交付与库存对比，就是这一步的系统实现^[1]。

第一步 · 需交付与库存对比：自动算缺口

系统从执行中的合同、订单中合计需交付数量，与库存、采购在途数量对比，自动算出"需要采购多少"^[1]。销售不用跨三个部门拉数据——系统已经算好了。这一步解决了"数据散在三个部门"的问题：不是让三个部门共享数据，是让系统自动汇总。

第二步 · 采购在途可视化

智能采购中心在计算采购量时，会考虑采购在途数量^[2]——已下采购单但还没到货的部分，自动从缺口中扣除。这意味着销售看到库存时，系统已经把"在途的货"和"能发的货"分开了。销售看到的不是"账面 200 个"，而是"可发 50 个，在途 150 个，在途预计 X 天到货"。

第三步 · 供应商直发：省掉中间环节

有些场景不需要等货到自己的仓库再发。采购单支持供应商直发模式^[3]——供应商根据采购单直接发货给客户，省掉"到货入库再出库"的中间环节。采购直发必须关联在订单下，先有客户订单才有采购直发。客户签收后自动触发采购单完成和关联订单的发货单创建^[3]。供应商直发把交期从"采购到货+入库+出库"压缩到"供应商直接发货"，交期承诺的确定性大幅提升。

第四步 · 入库确认与多次入库

采购到货后，入库单必须经过库管人员审核确认^[4]——与实际收到货品对比确认后，方可完成入库。支持分多次入库^[5]——到多少入多少，不用等全量到齐。这意味着采购在途的货，部分到货就能部分可发，不用等全量到齐才出库。多次入库让交期承诺有了弹性——不是"全到才能发"，是"到多少发多少"。

06代价与边界

07回到现场

老李又接到客户电话，要150个产品，问15天能不能交。

这次老李没急着答。他打开超兔一体云的需交付与库存对比^[1]。系统列出这个产品的数据：需交付150个，库存50个，采购在途100个（预计7天到货）。系统自动算出：库存缺口100个，已由采购在途覆盖，无需追加采购。

老李看到了三个数字：50、100、150。50是能发的，100是在途的，150是客户要的。三个数字之间的关系一目了然——不需要打电话问仓库，不需要发微信问采购，不需要翻Excel算缺口。系统把三个部门的数据拉到一张表里，30秒算完。

最早可发日期：在途到货（7 天）+ 入库确认（1 天）= 8 天。

老李回客户："8 天能发。"不是 15 天——是 8 天，有依据的 8 天。

客户在那头说："这么快？"老李说："不是快，是准。"

第 7 天，采购在途的 100 个到货，库管确认入库^[4]。第 8 天，出库发出。承诺兑现了。不是靠运气，是靠数据。

老板打开系统，看到的不只是一张出库单，而是这张出库单背后的完整链路：库存 50 + 在途 100 = 可承诺 150；在途 7 天 + 入库 1 天 = 最早 8 天可发。交期第一次有了计算痕迹，不是拍脑袋的痕迹。