Manufacturing
Production schedules and changeovers: what AI learns from planning decisions
By SourceX Editorial · Updated
Short answer
Production planning data teaches AI how planners trade off due dates, capacity, material and changeover cost on a real shop floor. The valuable record is the chain behind each schedule: the plan, every change, the stated reason and what actually ran. Save schedule versions and reschedule notes before an ERP or APS migration discards them.
Key takeaways
- A frozen schedule shows intent; paired with actual run times and change reasons, it shows judgment.
- Changeover logs with from-product, to-product and actual setup time teach sequencing trade-offs that public data rarely contains.
- Many ERP and APS tools overwrite the plan on every run, so schedule history often survives only in exports, reports and planner spreadsheets.
- Customer names, prices and customer-owned part designs are removed or excluded before planning records are licensed.
What counts as production planning data?#
Production planning data is the record of what a plant intended to build, on which resources, in what order, and how that intent changed as the week unfolded. It sits across the ERP, an advanced planning and scheduling tool if you have one, the MES and the planner's own spreadsheets.
Most mid-sized manufacturers already hold more of it than they think. Manufacturing ERPs such as Epicor Kinetic, Infor, Plex, DELMIAworks, NetSuite or SAP Business One hold work orders and production orders, and many plants also record labor or machine time against each operation, which shows what actually ran. The missing piece is usually the history of the plan itself.
- MRP planned orders and exception messages, with the planner's action on each
- Released work orders with routings, standard times and due dates
- Schedule snapshots or Gantt exports saved at a point in time
- Dispatch lists by work center or line, shift by shift
- Changeover and setup records with planned and actual times
- Reschedule notes, expedite requests and shortage emails
- Actual start, finish, quantity and scrap from labor tickets or the MES
Why do AI developers care about planning decisions?#
Planning decisions are valuable to AI developers because each one is a constrained, multi-step choice with a measurable result. A planner who pulls a hot order forward weighs material on hand, the setup it breaks, the operators on shift and the jobs that will now ship late, and the plant later learns whether the call was right.
Developers of planning and workflow agents need that pattern and cannot find it in public sources. Plants do not publish their schedules, and simulated factories lack the messy reasons real plans change: a supplier short-ships resin, a mold needs repair, a key customer calls late on a Friday. Records of planners overriding system suggestions carry the strongest signal.
Which schedule artifacts map to which AI tasks?#
Schedule artifacts are most useful when the plan, the change, the reason and the outcome can be linked by work order or job number. The table shows how each artifact typically maps to a task a model developer might train or evaluate.
A plant with only the outcome row still has something to offer, but the reason row is what turns a production log into a record of judgment.
| Schedule artifact | What it records | AI task it can support |
|---|---|---|
| Plan: dated schedule snapshot | Sequence, resource assignment and due dates at one moment | Learning baseline sequencing and capacity loading |
| Change: reschedule event | Which jobs moved, when, and by which role | Predicting which orders a disruption will push late |
| Reason: expedite note, shortage or machine-down message | Why the plan changed | Classifying disruption causes and drafting reschedule explanations |
| Outcome: actual start, finish, quantity and scrap | What really ran and how it went | Scoring whether a planning decision helped or hurt |
| Changeover log | From-product, to-product, planned and actual setup | Predicting setup time and proposing lower-cost sequences |
| MRP exception and planner response | The system suggestion and the human decision | Learning when experienced planners override the software |
How changeover records add value#
Changeover records add value because setup cost depends on the pair of products and the direction of the change, not on either product alone. In injection molding, going from a dark resin color to a light one usually takes far more purging than the reverse; on a food packaging line, moving from an allergen product to an allergen-free one triggers a full clean that the opposite move does not. Planners sequence around those asymmetries every day.
The weak version of this record is the standard setup time in the routing. The strong version is a log of every actual changeover with the products on each side, the time it took and anything that went wrong, which lets a model learn the real cost matrix rather than an average.
| Record detail | Weak version | Strong version |
|---|---|---|
| Setup time | Standard time from the routing | Planned and actual time for each changeover |
| Sequence | Job list with no order history | From-product and to-product for every transition |
| Reason | None recorded | Note on why the preferred sequence was broken |
| Quality | Not linked | First-piece inspection result tied to the changeover |
| Tooling | Generic resource name | Mold, die or fixture ID with condition notes |
Where planning history gets lost#
Planning history gets lost because most scheduling tools are built to show the current plan, not to remember old ones. A nightly MRP regeneration replaces yesterday's planned orders, and many APS tools overwrite the schedule each time the planner republishes it.
What survives is scattered: dated Excel versions of the master schedule on a shared drive, PDF dispatch lists in email, whiteboard photos and audit tables nobody reads. ERP migrations make it worse, because migration plans usually carry open work orders and leave closed ones, with their operation-level actuals, behind. Before a migration, preserve the following.
- Export closed work orders with operation-level actual times, quantities and scrap.
- Save labor and machine ticket history, planning to replace employee names with roles later.
- Collect dated schedule exports and planner spreadsheets, keeping their original file dates.
- Pull change logs or audit tables that record due-date and sequence edits.
- Archive expedite and shortage email threads that reference job numbers.
Illustrative: a custom molder that kept its schedule versions#
Illustrative: a fictional mid-sized custom injection molder runs Epicor Kinetic for work orders and an APS tool for finite scheduling. Its lead planner had saved a dated export of the schedule every morning for years, along with a running spreadsheet of mold changes, resin shortages and customer expedites keyed to job numbers.
When the company planned a move to a new scheduling tool, the COO asked whether that history was worth keeping. A metadata-only fit check described the record families without sharing any files: daily schedule snapshots, shop floor changeover logs with planned and actual times, and the reschedule spreadsheet. The rights review excluded customer-owned mold and part drawings, and preparation replaced customer names with codes and removed prices.
The resulting package linked each plan to its changes, reasons and outcomes by job number. The planner's spreadsheet, once seen as a personal habit, turned out to be the record that explained the decisions.
What gets removed or excluded before licensing?#
Planning records are licensed only after details that identify customers, people or protected designs are removed. Schedules look harmless, but job names often embed customer names, part numbers can point to a single buyer, and expedite emails carry names, phone numbers and sometimes prices.
Customer-owned designs and export-controlled work stay out entirely. Plants that do build-to-print work should tag those jobs early so the inventory can separate them from proprietary product lines.
- Customer names in job descriptions, replaced with stable codes
- Prices, costs and margins on work orders
- Employee names and badge numbers, replaced with roles
- Drawings and specifications owned by customers
- Jobs for export-controlled or defense programs
How SourceX approaches planning records#
SourceX scopes production planning data as one package within the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. The fit check asks only for metadata: which ERP, APS and MES tools hold the records, how many years of closed work orders keep operation-level actuals, whether dated schedule versions exist, and whether reschedule reasons are written down anywhere.
Under the SourceX Enterprise Data Value Framework, planner overrides and written reasons score on human-generated signal and domain expertise, and plan-to-outcome chains raise AI utility. Replacing customer names embedded in job descriptions adds preparation cost and privacy burden, which reduce net value. The supplier approves every step, and each package that proceeds carries a SourceX Evidence Packet recording provenance, licensing rights, permitted use, the privacy record and release authorization.
Frequently asked questions
Do we need an APS tool for our planning data to be useful?
No. ERP work orders with operation-level actual times, combined with dated planner spreadsheets or exports, can show plan, change and outcome. An APS tool helps because it holds constraints and sequences explicitly, but the link between a decision and its result matters more than the software that produced it.
Are planner emails and chat messages part of planning data?
They can be, because they often hold the only written reason a schedule changed. They also carry the most personal detail. Scope them to threads that reference job or work order numbers, and expect names, phone numbers, signatures and side conversations to be removed during privacy preparation.
How much schedule history is enough?
There is no fixed threshold. Continuous history that spans different conditions, such as busy seasons, supply shortages, product launches and staffing changes, is more useful than a long run of identical weeks. Gaps from a past migration are fine to disclose; they shape scope rather than ruling a plant out.
Could licensed schedules reveal our customers or capacity?
Customer names are replaced with codes, prices are removed, and the license limits permitted use and onward sharing. Plants that worry about revealing utilization can generalize resource names or shift dates by a fixed offset. Nothing is delivered until you have looked at a prepared sample and signed the release.
What if our plant schedules mainly on a whiteboard?
Outcome data still exists in labor tickets and work order history, so part of the chain is recoverable. The reasons behind changes will be thin, which lowers value. Some plants start recording reschedule reasons in a simple log, so future history is stronger even when past history is limited.
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.