4. 排程数据模型与信息准备
紧急插单能否被快速、准确地重排，取决于系统在插单发生的那一刻，能否立即拿到一组完整、可信、时效足够的数据。很多工厂的重排程失败，并不是算法不行，而是数据模型没有建好：订单和工序混在一张表里，设备能力只写了额定产能，物料齐套状态靠人工口头确认，日历里没有换型时间。结果是排程引擎算出一个“数学上最优、现场无法执行”的计划。本节要解决的核心问题是：为动态重排程建立一套主数据模型，并明确数据采集频率、质量与实时性要求，最终收敛到“重排程最小数据集”。
一、重排程需要的主数据模型
排程的本质是在“资源约束”下对“任务”进行时间分配。因此主数据模型可以围绕六个核心对象展开，它们之间通过明确的引用关系连接，而不是各自孤立。
订单（Order）是需求来源，关键字段包括订单号、客户、需求数量、交期、优先级、订单状态（已确认/已下达/已完工）、是否允许拆分。紧急插单通常表现为一条新订单，或对已有订单交期的强制提前。
工序（Operation）是订单的展开结果，一个订单对应一条工艺路线上的多道工序。关键字段包括工序号、工序名称、所属订单、前后置工序、标准工时、准备时间、可替代设备组、是否关键工序。工序是排程的最小任务单元，重排程时被移动的正是工序。
设备（Machine/Work Center）是资源。关键字段包括设备编号、所属工作中心、额定产能、可用日历、当前状态（运行/停机/维修）、当前在制工序、换型矩阵。设备不能只写“产能=100件/小时”，还要能表达“A产品换B产品需要40分钟”这类换型约束。
物料（Material）决定工序能否开工。关键字段包括物料号、需求量、已到货量、预计到货时间、齐套状态、替代料关系。物料不齐套时，工序即使排上设备也无法执行，因此物料可用时间必须作为工序最早开工时间的约束之一。
人员（Labor）在劳动密集型或需要资质认证的工序中是硬约束。关键字段包括人员/班组编号、技能等级、可操作设备、班次日历、当前任务。若某工序需要持证人员，则人员可用性会直接改变排程结果。
日历（Calendar）是时间的“合法区间”。包括工厂日历、设备日历、班组日历、节假日、计划停机、临时加班。日历决定了每天可排产的时间窗口，是排程时间轴的基础。
工艺路线（Routing）把订单、工序、设备、人员、物料串起来。关键字段包括路线版本、工序顺序、每道工序的设备组、标准工时、准备时间、物料清单（BOM）引用。工艺路线是排程的“模板”，订单下达后按路线展开为具体工序。
这些对象之间的关系可以用下面的结构图表示：订单展开为工序，工序引用工艺路线、设备、人员、物料，设备与人员受日历约束，物料有到货时间约束。
二、数据采集频率与实时性要求
不同数据的变化速度差异很大，如果全部按“实时”要求采集，成本高且不必要；如果全部按“日结”处理，插单时又会拿到过期数据。合理的做法是按变化频率和影响程度分层。
| 数据对象 | 典型变化频率 | 建议采集方式 | 重排程实时性要求 |
|---|---|---|---|
| 订单 | 随时（插单/改期） | ERP 事件推送 | 秒级～分钟级 |
| 工序进度 | 每完成/开工一次 | MES 报工 | 分钟级 |
| 设备状态 | 停机/维修时变化 | 设备信号或人工报障 | 分钟级 |
| 物料到货 | 每日或每批次 | WMS/收货单 | 小时级 |
| 人员班次 | 每日/每周 | 排班系统 | 小时级 |
| 日历 | 低频（节假日/停机计划） | 计划维护 | 天级 |
| 工艺路线 | 低频（版本变更） | 工艺系统 | 天级 |
判断实时性要求的一个实用原则是：该数据变化后，是否会导致当前排程结果不可执行？如果会，就必须在重排程触发前拿到最新值。例如设备突然停机，若不更新设备状态，排程仍把工序排在该设备上，计划立即失效，因此设备状态必须分钟级。而工艺路线版本变更通常只影响未来新订单，天级同步即可。
三、数据质量要求
重排程对数据质量的敏感度远高于静态排程，因为插单会放大误差。需要重点控制四类质量问题。
- 完整性：工序缺少标准工时、设备缺少换型时间、物料缺少预计到货时间，都会让排程引擎使用默认值或直接跳过约束。建议在数据进入排程前做必填校验。
- 一致性：同一设备在 ERP 和 MES 中的编号必须一致；同一物料在 BOM 和库存中的单位必须统一。否则关联查询会漏数据。
- 准确性：标准工时若长期未更新，排程结果会系统性偏乐观。建议按实际报工数据定期回算，例如每季度用最近三个月实际工时修正标准工时。
- 时效性：数据有值但已过期，比没有值更危险。例如物料“预计到货”仍是上周的日期，排程会误判齐套。
一个常见陷阱是：为了追求“实时”，把大量高频信号直接接入排程引擎，导致数据抖动。例如设备状态在“运行/待机”之间频繁跳变，若每次跳变都触发重排程，会造成计划频繁变动、现场无所适从。正确做法是设置状态稳定窗口，例如连续 3 分钟保持停机才判定为“停机”，再触发重排程。
四、重排程最小数据集
插单发生时，系统不需要全量数据，但必须拿到一组“最小可用数据集”。这组数据决定了重排程能否在秒级到分钟级内完成。最小数据集可以按“任务、资源、约束、状态”四类组织。
任务类：待排工序列表（工序号、所属订单、前后置关系、标准工时、准备时间）、订单交期与优先级、已开工未完工工序的剩余工时。
资源类：可用设备列表（设备号、所属工作中心、当前状态、当前在制工序及预计完工时间）、可用人员/班组（技能、班次、当前任务）。
约束类：设备日历与班次日历（未来 7～14 天的可用时间窗口）、换型矩阵、物料齐套状态与预计到货时间、工艺路线版本。
状态类：当前排程快照（每道工序的计划开始/结束时间、占用设备）、设备实时状态、工序实际进度。
可以用一个具体的教学示例来理解最小数据集的作用。假设某注塑车间在 14:00 接到紧急插单：订单 X，数量 2000 件，交期次日 18:00，产品需要两道工序——注塑（设备组 M1/M2，标准工时 0.5 分钟/件，换型 40 分钟）和包装（设备组 P1，标准工时 0.2 分钟/件）。系统需要立即拿到：M1、M2 当前在制工序及预计完工时间；M1/M2 的换型矩阵（当前产品换 X 产品需要多久）；包装工序的可用人员班次；物料是否齐套。若 M1 当前在制工序预计 16:00 完工，换型 40 分钟，则注塑最早 16:40 开工；2000 件 × 0.5 分钟 = 1000 分钟 ≈ 16.7 小时，跨班次后需按日历扣除休息时间。这些计算全部依赖最小数据集中的字段，缺一项就会导致结果不可信。
落地建议：把最小数据集固化为一个“重排程输入视图”或接口契约，每次插单触发时由系统自动组装，而不是让计划员手工从多个系统导出。视图字段应稳定、可校验，并记录数据时间戳，便于事后复盘“当时用的是哪一版数据”。
总结来说，排程数据模型不是把 ERP 表原样搬过来，而是围绕“工序可执行”重新组织：订单展开为工序，工序绑定设备、人员、物料和日历，工艺路线提供模板。数据采集按变化频率和影响程度分层，质量上重点保证完整、一致、准确、时效。最终收敛到重排程最小数据集，让紧急插单发生时，系统能在分钟级内给出一个现场可执行的新计划。