假如你是工厂的销售，客户发来一句：“这批货周五能交吗？”

你先找生产计划人员问进度，听到“已经做了一部分”，又去找仓库核对物料，再问质量人员什么时候能检验。几通电话打完，聊天窗口还停在客户的那句话上，你却仍然不敢答应。

大家都在认真回答，只是各自知道的，都是订单的一部分。客户想知道的则是：这100件货，到底能不能按时收到？

工厂做数智化，可以先从这样的事做起。销售查一笔订单，就能看到目前做到哪儿、哪些事还没确认，以及该找谁继续核实。让交期答复有据可查。

有了进度，还要接着问什么？

拿一笔模拟订单来看。虚拟制造企业A的订单O-1101共100件，计划11月6日周五交付。这里说的交付，是客户收到货，具体收货时段还没有确认。

假设到了11月4日上午10点，60件已经合格待发，还有40件待完成，已发货数量为0。

知道这些，销售已经能说明当前进度了。不过，要回答周五能否全部交付，还得把剩下的安排问清楚。

这40件所需的物料，什么时候能到位？生产什么时候能完成，后面有没有安排检验？等货都准备好了，装运和运输能不能赶上客户的收货时间？

只要其中一项还没落实，交期就得再核实。碰到临时异常，直接打电话沟通也很必要。麻烦的是，这次问清了，却没有留下大家都能查到的记录。下一位同事接到客户的询问，又得重新问一遍。

“做完了”，还得看做到哪一步

问进度时，一句“做完了”很容易让人松口气。但车间说的做完，可能只是机加工结束，后面还有检验、包装。

在这笔订单里，“合格待发”指已经通过检验、可以安排发运；“已发货”才表示货已经交给承运方。发出去之后，什么时候到客户手里，还要看运输和收货安排。

所以，60件合格待发，表示这60件已具备发运条件，客户还没有收到。另有40件仍待完成，两部分合起来才是订单需要的100件。

如果客户愿意分批收货，可以再商量先发多少、剩余什么时候到。不过，这笔订单还没有确认能否分批，销售也就不能直接把“先发60件”当作已经谈好的方案。

在系统里，销售应该能查到什么？

把这些信息放到同一笔订单下，销售接到询问时，就可以先按订单号查一遍：客户要多少、车间做到哪一步、物料是否够用、检验有没有安排、货发了没有。

每项状态也要能找到依据。生产进度对应报工和计划记录，物料对应库存及占用记录，检验对应检验与放行记录，发货对应装运和物流记录。数量旁边，还应有更新时间、负责岗位，以及尚未确认的事项。

比如，查到剩余40件还没有确认完成时间，就请生产计划人员补充；客户的收货时段不清楚，就由销售去问。这样，同事之间沟通时，能直接说清楚还缺哪项信息，已经核实过的内容也可以接着用。

给客户的答复也会具体一些：“截至11月4日上午10点，60件合格待发，还有40件待完成。剩余生产、检验和交付安排还在核实，周五能否100件全部送到，目前还不能确定。”再和负责核实的同事约好时间，给客户一个明确的回音。

记录有人维护，查询才有用

要让这样的查询真正帮上忙，还得把三件事安排好。

先说清楚谁来更新。生产、仓库、质量和发货各有各的记录，状态变了，需要有人及时记下来，出现缺项也能找到负责的岗位。

再看记录是什么时候更新的。昨天下班前的进度，未必能回答今天上午的问题。页面刚刷新过，也要留意里面每一项业务记录的时间。

还要把影响交付的事情写明白。剩余生产要等什么，检验能不能衔接，装运和收货是否安排妥当。暂时没问清的，就留在“待确认”里，方便接着跟。

至于这样做能省多少时间，可以拿同一类交期询问记一段时间的账：收到问题后，多久能形成完整答复，需要再找几个人确认，答复和后来的实际情况是否一致。系统查询、日常更新和异常核对花的时间，也一起算进去，才看得出流程有没有改善。

客户下一次问交期，销售能先把查到的进度说清楚，再把还没落实的事情跟下去。这件事做顺了，数智化的价值也就更容易看见了。