The data most likely to mislead an optimization model often looks perfectly ordinary in a spreadsheet. The problem is not always an obvious missing cell. A machine can be listed as available even though it is waiting for maintenance. An employee may appear qualified because an old spreadsheet has not been updated. A delivery deadline may be recorded in local time while the planning service interprets it in UTC. Each discrepancy can change the choices the solver considers feasible.
This is why data preparation is not an administrative prelude to optimization. It is part of the modeling work. A useful system must represent the operation with enough fidelity that its recommendations can survive contact with reality.
Begin with decisions, not columns
An operations database may contain thousands of fields, but a scheduling model needs only those relevant to its decisions, constraints and objectives. For a production schedule, this might include jobs, processing durations, machine eligibility, calendars, material availability and due dates. For a workforce roster, it could include qualifications, contracts, availability, coverage requirements and preferences. The first job is to understand what each field means, who maintains it, and whether the meaning is consistent across systems.
This is why data preparation is not an administrative prelude to optimization.
Even a simple quantity such as processing time can be ambiguous. Is it an average from historical data, a standard estimate, a minimum or a guaranteed duration? Does it include setup, inspection and transfer time? If the model treats an average as certain, it may produce schedules that are too tightly packed. Where durations are uncertain, a practical design might use buffers, scenarios or robust constraints. Those are modeling choices, not automatic properties of the data.
Four checks that uncover avoidable failures
Completeness. Can every required job, resource or shift be represented? Missing records often cause a model to optimize only the visible portion of a problem, which can make the result look better than it is.
Consistency. Are units, identifiers and calendars aligned? One source may record minutes and another hours. Two systems may name the same machine differently. Daylight-saving changes can create nonexistent or repeated local times, so timestamps and time zones need an explicit policy.
Validity. Are the values plausible and up to date? A negative processing time should be rejected, but even a positive number can be stale or copied from the wrong process. Validation rules should include operational expertise, not only data types.
Provenance. Can a planner trace a recommendation to the inputs and assumptions that produced it? Versioned inputs make decisions reproducible and allow teams to explain why yesterday's schedule differs from today's.
Those are modeling choices, not automatic properties of the data.
Do not silently repair hard requirements
Some missing fields can be estimated safely for exploratory analysis. Others should stop the run or trigger an explicit review. A missing staff preference is not necessarily the same as missing a legally required qualification. A blank delivery deadline might mean “not specified,” or it might mean an integration failed. The difference determines whether the problem can be solved responsibly.
A well-designed optimization workflow makes these distinctions visible. It reports invalid input, documents fallback rules, and distinguishes hard requirements from uncertain estimates. Data validation should happen before expensive solve requests whenever possible, with independent checking of the returned solution afterward.
Build the smallest useful data contract
A good integration defines the required input schema, valid ranges, time conventions, identifier rules and version information. It also specifies what happens when a source is unavailable or late. This need not begin as a large architecture exercise. A carefully designed example dataset, reviewed with the people who do the planning, can expose more important problems than weeks of API design performed in isolation.
When the data and the model agree with the real operation, optimization becomes much more useful. The algorithm can then spend its effort comparing genuine choices rather than producing precise answers to inaccurate descriptions.
For how these inputs reach the model and how decisions return to existing systems, see From Enterprise Data to Better Decisions.