Production Scheduling & Gantt Optimizer

The problem this solves

Production control in Dynamics 365 Finance & Operations schedules well in batch. It does not schedule well in conversation. A planner who needs to answer "what happens if I pull this order forward two days" today opens the Gantt chart, reads a static picture, backs out, changes a date on the production order, reruns operations scheduling, and looks again. The loop is minutes long and it destroys the plan they were trying to protect, because the scheduling engine rescheduled everything downstream of the change with no way to preview the damage first.

The second gap is setup time. Standard route setup time on an operation is a single figure. Real shop floors pay a different changeover depending on what ran previously — colour sequence on a coating line, tooling family on a press, allergen order on a food line, viscosity on a filling line. F&O has no native concept of a setup matrix keyed on the transition between two jobs, so the sequence the scheduler produces is capacity-feasible and economically wrong.

The third gap is comparison. There is exactly one schedule in the system at a time. A planner cannot hold two candidate plans side by side, score them, and commit the better one.

ECOSIRE builds a scheduling workspace that closes all three gaps against your live F&O data, in your environment, as an X++ extension.

What ECOSIRE builds

Interactive Gantt over live production orders

An embeddable Gantt surface bound to ProdTable, ProdRoute, ProdRouteJob and WrkCtrTable, rendered per resource group and per individual resource. Jobs are dragged, resized, split and reassigned directly on the chart. Every move is validated in memory against finite capacity from WrkCtrCapRes and the resource calendars in the calendar framework before it is allowed to land, so an impossible placement is refused at the point of the gesture rather than discovered on the next scheduling run.

The chart reads material availability from on-hand and expected receipts so a job whose components will not be there is visibly flagged rather than silently scheduled.

Sequence-dependent setup matrix

A new setup-matrix table keyed by resource, from-characteristic and to-characteristic, where the characteristic is drawn from a field you nominate — item group, product dimension, a product attribute, or a custom field on the released product. When jobs are sequenced on a resource, the transition cost is read from the matrix rather than from the flat route setup time, and the sequencing routine minimises total changeover across the horizon for that resource.

The matrix is maintained by planners in a standard F&O form, imported through the data management framework with a dedicated data entity, and versioned so you can see what the numbers were when a given plan was committed.

What-if scenarios

Scenarios are stored plan variants. A planner clones the live plan, works on the clone freely, and the live production orders are untouched until commit. Two or more scenarios are compared on a scorecard: total makespan, late orders and total lateness in days, resource utilisation per work centre, total changeover minutes, and material shortage count. Commit writes the accepted scenario back to ProdRouteJob and the production order dates through the standard scheduling API so downstream F&O behaviour — job cards, route cards, WIP — stays native.

Automatic sequencing and rescheduling

A sequencing engine that runs either on demand from the workspace or as a recurring batch job through the SysOperation framework, with the usual batch group, recurrence and alerting behaviour. Objectives are configurable per resource group: minimise lateness, minimise changeover, or a weighted blend. Frozen-window support means jobs starting inside a configurable horizon are pinned and never resequenced under the operators' feet.

Integration surface

Data entities are exposed for the setup matrix, scenarios and scenario results so the plan can be read by Power BI or an external planning tool over OData. Where a mobile or Power Apps front end is wanted for shop-floor visibility, the same entities back it — we scope that as an option rather than assuming it.

Everything is built as extensions in a dedicated model: event handlers, table extensions and Chain of Command. There is no overlayering, so your one-version upgrade path is unaffected.

Who this is for

Discrete and process manufacturers running production control in F&O across one or several legal entities, where a small number of planners carry the sequencing decisions for many resources. It is most valuable where changeover is expensive relative to run time, where the order book changes intra-week, and where the answer to "can we take this rush order" currently requires a planner to guess.

It is not the right fit if your production is single-stage with negligible setup, or if you are not yet using route-level operations scheduling at all — in that case the groundwork comes first and we will say so during scoping rather than sell you a scheduler you cannot feed.

How delivery works

Scoping call. We walk your production control setup: resource groups, route structure, how setup time is currently modelled, which fields carry the sequencing characteristic, how many legal entities are in scope, and what your planners do today in spreadsheets. We look at the actual data, not a questionnaire.

Fixed quote. You receive a written scope with the objects to be built, the integration points, the F&O version and update level targeted, what is explicitly excluded, and a fixed price. Nothing starts until you accept it.

Build. Development happens in our own F&O development environment against a copy of your configuration where you can provide one. Typical lead time is two to four weeks depending on the scope agreed.

Install in test. We deliver a deployable package. It goes into your sandbox through your LCS pipeline, we configure the setup matrix and scenario defaults with your planners, and you run your own acceptance against real orders. Changes inside the agreed scope are made here.

Production. Once you sign off in sandbox, the same package is promoted to production through your normal release process. We support the go-live window and hand over the source.

Support. A defect-support window is included from production go-live, covering anything that does not behave as specified. Enhancements beyond the agreed scope are quoted separately.