很多企业在评估排产系统的时候关注的第一个问题是能不能排出来给系统一堆订单、产能数据、约束条件系统能给出一个排产方案——这一步目前市面上大多数排产系统都能做到。但真正用了之后就会发现一个更现实的问题计划排出来之后变化马上就来。客户加了一个急单要插进去。一台设备突然故障产能没了。供应商说物料要晚到三天。质检发现某批原材料不合格要换料。这些变化发生的时候排产计划要不要调当然要。但怎么调一、重新排比第一次排难在哪技术上重新排比第一次排要复杂得多。原因在于几个约束。1. 时间约束必须快第一次排产可以慢慢算——花10分钟甚至半小时排出一版计划问题不大。但插单来了、设备故障了车间在等着。如果重排要半小时这半小时里车间是按老计划干还是停工等重排的时间窗口通常是以分钟计的不是以小时计的。2. 稳定性约束不能乱动重排不是把整个计划推翻重来。已经排好且在执行的工序不要动已经在路上的物料不要改已经跟客户确认的交期尽量不变。重排的本质是最小化调整——只改必须改的部分其余保持不变。这比从零排一版全新计划要难得多。因为不仅要找到可行解还要在可行解中找对现有计划扰动最小的那个。3. 一致性约束上下要同步重排的结果不能只停留在排产系统里。它需要同步到MES执行端、WMS物料端、甚至通知到相关岗位的人。如果重排了计划但执行端不知道排产系统和实际生产就会脱节。二、传统排产系统的重排方式大多数传统排产系统处理变化的方式说白了就是重新跑一遍。变化发生了→排产员手动修改输入参数→系统重新计算→生成新版计划→人工确认后下发。这种方式的问题很明显慢。重新计算整个计划数据量大、约束多耗时不短。粗暴。不管变化影响多大整个计划全部推翻重来。明明只需要调整两个工序的顺序结果整张排产表都变了。断层。重排结果需要人工确认后手动下发中间有时间差。在这个时间差里车间可能还在按旧计划执行。这种全量重排模式在变化不频繁的场景下勉强够用。但在多品种小批量、插单频繁、设备状态不稳定的制造环境中这种方式根本跟不上节奏。三、实时重排的技术架构成熟的排产系统在重排能力上通常有以下几个技术层面的设计。1. 事件驱动架构不是等人发现变化再去重排而是系统自动感知变化事件。设备故障了MES推送一个事件过来。物料晚到了WMS推送一个事件过来。插单进来了ERP推送一个事件过来。排产系统监听这些事件根据事件类型和影响范围自动触发对应的重排策略。2. 增量求解而非全量重算重排的时候不是把所有订单、所有产线全部重新排一遍。而是先分析这个变化影响了哪些订单、哪些工序只对这些受影响的部分重新求解。技术上这需要对排产模型做分区处理——把整体计划拆成多个相对独立的子问题变化发生时只重算受影响的子问题其余子问题保持不变。这样做的好处是求解速度快只需要算一小部分结果稳定大部分计划不变。3. 多策略重排引擎不同类型的变化需要不同的重排策略。插单找到最优的插入位置最小化对已有订单的影响设备故障把故障设备上的任务迁移到其他可用设备或者调整工序顺序物料延迟调整受影响订单的开始时间可能需要级联调整后续工序紧急订单提升优先级重新分配资源可能需要牺牲部分非紧急订单的交期每种策略对应不同的约束调整方式和优化目标。重排引擎需要能够根据事件类型自动选择合适的策略。4. 版本管理和无缝切换重排生成新版计划后需要跟旧版计划做差异对比确认影响范围然后无缝切换到新版。切换过程中已经在执行的工序不受影响只切换尚未开始的部分。切换结果实时同步到MES和执行端。四、实时重排对数据质量的要求更高全量重排对数据的要求是排产时准确就行。但实时重排对数据的要求是任何时候都要准确。因为重排是随时可能触发的。如果设备状态数据是过时的、物料库存数据是滞后的、订单优先级是过期的——基于这些数据做出的重排决策就是错的。这意味着设备状态需要实时同步不能靠人工更新物料库存需要跟WMS实时对接不能靠手工盘点订单优先级需要有明确的更新机制不能全靠销售口头说实时重排的基础不是算法有多强而是数据有多准。五、结语排产系统的技术门槛不在于能不能排出来——这一步大多数系统都能做到。真正的门槛在于变化来了之后能不能快速、稳定、准确地重新排。这需要的不是更强的求解算法而是一整套事件驱动、增量求解、多策略适配、版本管理的系统架构。这也是为什么有些排产系统看起来能用但用起来不行——第一次排产都差不多但应对变化的能力天差地别。你的排产系统面对变化时的响应速度怎么样