An order for 200 units is due on Thursday. In the enterprise resource planning system (ERP), the order is released and the promised date is recorded. The warehouse system can confirm material for only 120 units at present. Two machines are eligible to make the product, but the manufacturing execution system (MES) knows that one of them is already occupied. The workforce calendar shows when qualified operators can run either machine.
Each system describes part of the same order, yet none contains an executable production schedule. An optimizer needs a coherent view of the available choices: how much can be produced, on which machine, at what time, with what material and staff. The questions are mathematical, but assembling the information that makes them answerable is an engineering and operational task.
The example follows a typical integration pattern, from order data to a checked plan.
Start with the order, not the system inventory
A tempting first move is to map every database that might contain useful information. An ERP holds orders and dates; an MES describes active operations; a warehouse management system (WMS) tracks stock; maintenance and workforce systems record equipment and people. The integration diagram can grow enormous before anyone has decided which choice the optimizer is meant to make.
Return instead to the 200-unit order. The decisions might be which jobs to release, which eligible machines to assign, how to sequence operations, and whether the Thursday promise is still feasible. These choices determine what information is essential: quantities, material readiness dates, current work, durations, setup requirements, machine calendars, operator qualifications, and the relevant delivery commitments. The model also needs an objective, such as minimizing lateness or changeover cost under nonnegotiable operational rules.
Processing durations may be expressed in minutes in one place and hours in another; working calendars may use local time while service events use UTC.
Hundreds of other ERP fields may be irrelevant. Conversely, one missing fact, such as the time the remaining material will arrive, may decide whether Thursday delivery is possible at all. The data requirement follows from the decision and its constraints, not from what is easiest to extract.
One order, several versions of the truth
The ERP says 200 units are on order. The WMS says material for 120 is physically available. These statements are not necessarily inconsistent. One describes a commitment; the other describes inventory. A schedule treating all 200 units as ready for production would confuse two different facts and might be mathematically feasible only because the model's input is wrong.
The integration needs a field-by-field account of authority and freshness. ERP may own the customer promise; WMS may own stock availability; MES may own actual work progress; maintenance may own outages. When sources disagree, the workflow should have a defined response, whether that means waiting for an update, applying an approved reconciliation rule, or asking a human to resolve the conflict.
Identifiers can be just as troublesome as quantities. One system's LINE-04 may refer to a resource identified differently in another. An incorrect mapping can assign the order to equipment that cannot make it. Processing durations may be expressed in minutes in one place and hours in another; working calendars may use local time while service events use UTC. A daylight-saving transition is a reminder that even an apparently simple time interval can have more than one representation.
These details do more than complicate data cleaning. They reveal how an organization actually operates. A team may discover that a rule enforced informally by a supervisor has never been recorded, or that two departments use the same term for different states of an order.
A schedule belongs to a moment in time
Suppose the planning application gathers the current order, material, machine, and staffing facts at 10:00 a.m. and starts the optimizer. At 10:02, a machine reports a breakdown. At 10:04, the solver returns a schedule assigning part of the order to that machine. Its answer may be correct for the 10:00 inputs and unusable at 10:04.
The mathematically cheapest plan is not helpful if it assumes workers can undo tasks already completed or that customers have not been told their delivery times.
The remedy is not to demand perfect real-time synchronization among every enterprise system. It is to give each optimization run an explicit input snapshot: a coherent set of facts, their relevant timestamps or versions, and the model and rule versions used. The returned plan should be associated with that snapshot so the application can establish what was known when it was computed.
A nightly extract may be sufficient for monthly planning. A production recovery decision may need prompt event updates. Either way, the application should check changes that matter before accepting or executing a proposed schedule. In the example, the machine outage should prompt a new snapshot and a new decision, not an automatic publication of the earlier result.
Replanning should respect what already happened
When the machine fails, the planning system should not treat Thursday's order as though work had never begun. Any units already produced remain produced. Work in progress, approved commitments, material consumption, and tasks that cannot be interrupted may constrain the next plan.
A previous schedule can be useful as a reference or, where supported, a starting point for the solver. But retaining finished work or holding an assignment fixed is a separate modeling requirement, not a property guaranteed by reusing a candidate solution. A robust workflow distinguishes what can change from what has become part of operational reality.
That distinction can make a revised schedule more valuable than a completely new theoretical optimum. The mathematically cheapest plan is not helpful if it assumes workers can undo tasks already completed or that customers have not been told their delivery times.
Better algorithms can improve the quality of those alternatives and shorten the time needed to investigate them.
Solving and acting are different stages
After an optimizer proposes a schedule for the 200-unit order, someone may still need to review it. The result should show assignments, start and finish times, relevant objective measures, and whether the model's feasibility checks passed. A solver status indicating that a time limit was reached with a feasible plan is different from a proof of optimality; a missing feasible plan is different again.
Only an accepted decision should be written back to ERP, MES, or another execution system. A practical flow therefore has identifiable stages: collect and validate the snapshot, construct the model, solve within the available budget, check and present the result, obtain the required approval, and perform controlled writeback. Updates should be traceable and protected from accidental duplication. Sensitive workforce and commercial records should be accessed and retained only as required for the task.
This does not require a comprehensive new platform on day one. A scheduled export and planner-approved import may be appropriate for a first project. Where the decision's value and time pressure justify it, the workflow can evolve toward APIs, event-driven updates, and controlled execution.
What integration ultimately makes possible
Once the order can be traced from commitment through stock, capacity, scheduling, approval, and execution, optimization becomes more than a calculation performed occasionally. A planner can ask whether earlier material arrival would protect Thursday's deadline, whether a qualified operator is the limiting resource, or which commitments must change after a machine outage. Each question starts from an explicit set of facts and produces alternatives that can be examined on the same terms.
Better algorithms can improve the quality of those alternatives and shorten the time needed to investigate them. Yet the most important integration achievement may be less visible: the organization can tell which facts a decision relied on and whether they are still true when the decision is put into effect.
An organization does not need to replace its ERP, MES, or warehouse software to benefit from optimization. It needs a reliable route from operational facts to meaningful choices, and from an accepted choice back to the people and systems responsible for carrying it out. That is what turns an interesting calculation into an everyday planning capability.