设计变更已经批准，正在生产的工单该怎么办？

设计变更至少要看两个时间点：一个是变更获批，一个是车间真正开始按新版生产。它们未必是同一天。

为什么？因为图纸和BOM可以先发布新版，车间手里却还有已经领料、已经开工的工单。这个时候，最让人拿不准的往往不是新版怎么建，而是手上这些工单，到底从哪一件开始改。

有人会说，新版一发布，系统里所有工单跟着更新不就行了？真这么做，已经领出去的料、做完的工序和检验记录怎么办？也有人觉得，旧工单做完再说。但如果变更是为了解决质量隐患，等整批做完可能就晚了。

所以，设计变更批准之后，先别急着按一个按钮“同步全车间”。先弄清楚三件事：改了什么、影响哪些在制工单、每张工单应该按哪个版本继续做。

先把变更说到车间能执行的程度

“产品BOM已更新”对计划员和班组长来说，还不是一条能直接执行的指令。他们得知道，旧件换成什么新件，工艺步骤有没有变，检验标准是不是也要跟着改。

比如只更换一个尚未领用的包装件，和改动已经装配完成的关键零件，处理方法就不可能一样。前者也许调整后续领料即可；后者得先确认已经做出的产品是否要隔离、返工或经评估继续使用。这里的“也许”和“得确认”很重要，具体处置要由研发、工艺、质量和生产根据变更原因决定，不能由系统替他们拍板。

还有一个经常被漏掉的问题：新版从什么时候、哪一批开始生效？有的企业按日期，有的按订单、批次或序列号；这些规则不先定，系统即使把最新图纸推到了车间，也回答不了眼前这张工单该用哪版。

别只找未完工的工单，要看它做到哪一步了

影响范围不能只靠筛选“未完工”。同样是未完工，有的工单尚未领料，有的已经领料但没有开工，有的正做到变更涉及的工序，还有的产品已做完、只差检验或入库。

这几类工单放在一张清单里，处理动作才有依据。

尚未领料的，可以先核对库存和采购在途，再决定是否切换新料；已经领料的，要把旧料的退回、替换或让步使用说清；已经加工的，则要看受影响的工序和产品范围，决定暂停、复检还是返工。至于已完工未出厂的产品，也不能因为工单状态显示“完成”就自动排除在影响范围之外。

查影响范围，不是为了生成一张漂亮报表，而是为了让每张工单都有明确的处置结果。除了工单，现有库存和已领物料也要一起看。否则决定切换新版之后，车间可能还是拿着旧料开工。最终怎么切批、怎么处置在制品，仍要按企业自己的工艺和质量要求定。

最怕的是，图纸变了，工单还沿用旧资料

影响范围找出来以后，下一步不是把原工单里的BOM字段直接覆盖掉。这样看似省事，事后却可能查不出生产时究竟用了哪个版本、领过什么料、检验依据是什么。

更稳妥的做法，是把变更单、适用范围、原工单版本和处置决定关联起来。需要改工单的，由有权限的人确认后再调整用料或工艺任务；不需要改的，也记下它为什么继续按旧版执行。已经做过的工序保留原始记录，后续若加了复检或返工，再增加对应的执行记录，而不是把历史抹平。

这也解释了为什么“图纸更新通知”不等于“变更已落地”。通知只能让人知道有新版；工单改没改、车间收到没有、旧料怎么处理、质量是否放行，还得逐项核对。

已有ERP或MES，缺的可能是中间这段协同

如果现有ERP或MES已经能管理变更生效、查受影响工单、记录工单调整和质量处置，先把这些能力用起来。没必要为了“做变更管理”再平行建一套账。

但也有企业的实际情况是：研发的变更单在一个系统，工单在ERP，现场报工在MES，领料和批次在WMS。哪个系统都能看到自己那一段，却没人能一眼说清“这次变更涉及的工单，哪些已经处理，哪些还等质量确认”。

这种情况下，织信可以用来补中间的协同过程。用数据表把变更申请、影响工单、处理责任人、版本选择和确认记录关联起来，再用工作流让研发、工艺、计划、质量按各自职责处理。需要和原有ERP、MES交换工单状态或处理结果时，可以用织信的自动化与API能力衔接，但前提是对方开放了相应接口。有了接口，也不等于所有在制工单会自动判定是否切换新版。影响判断与系统联调，都要拿真实业务数据验证。

为什么这件事值得用一个可持续开发的平台来做？因为变更规则不会永远只按一种产品、一家工厂、一套系统运行。今天是物料替代，明天可能是工艺参数调整；有的订单要从新批次生效，有的客户要求追到序列号。要是每多一种规则，就得靠邮件、Excel和口头通知补一遍，系统之间还是接不上。

最后用一张在制工单验收

选一张变更发生时正在生产的工单，从变更单出发往下查：它为什么被判定为受影响，生产到哪一步，谁决定停、改或继续，实际领用和检验记录对应哪个版本。再从工单反查，能不能找到批准它这样处理的变更单和确认记录。

两头都找得到，车间也能按新的处置继续干活，才算把设计变更真正送到了生产现场。否则，新版资料发布得再快，正在做的那批产品仍可能留在旧流程里。