Dispatching & the Phased Rollout: From Gantt to a Working Program
🎯 Who this is for: Planners and schedulers who want the engine to hand off cleanly to the tools they already run, dispatch managers who need to know what changes on the ground, and anyone deciding whether — and how — to fund a Phase 4 Optimizer pilot.
Series: Part 5 of 5 — Maximo Optimizer Implementation Playbook (Series Finale) | Read time: 26 minutes
The Schedule Has to Land Somewhere
Four parts in, the solver has everything it needs: it knows the difference between drawing a schedule and computing one (Part 1), it understands the nine constraints and five objectives it is balancing (Part 2), it is reading clean craft, shift, and location data (Part 3), and it can estimate travel well enough to build a sane route (Part 4). None of that matters if the output is a file nobody looks at.
Optimizer does not introduce a new screen for dispatchers to learn. It writes its answer into the Manage Graphical Assignment Gantt view — the same short-horizon assignment tool covered in the MAS MANAGE series — and into the Dispatching Dashboard that Field Service Management already provides. This part is about that handoff: how the optimized schedule surfaces, what a dispatcher actually does with it, what it costs in AppPoints, and the documented rollout plan and payoffs that let you prove — or disprove — that the investment worked.
⚙️ From Solver Output to Graphical Assignment
Optimizer's output is a set of assignments: this work order, to this labor or crew, in this time slot. That output is not a separate artifact you export and interpret — it is written directly onto the Gantt chart dispatchers and planners already use.
| Step | What happens |
|---|---|
| 1. Solve | Optimizer runs against the current pool of work orders, constraints, and objective weights (Part 2) |
| 2. Publish | The optimized schedule appears on the Graphical Assignment Gantt, one bar per assignment |
| 3. Review | A dispatcher scans the Gantt the way they always have — by technician, by day, by craft |
| 4. Adjust | Manual changes are made the normal way: drag a bar, reassign a slot |
| 5. Validate | Every manual change is checked against the same constraints the solver honored — you cannot drag a job onto a technician without the right craft, or into a slot that violates SLA or availability |
| 6. Re-optimize | If enough has changed — new emergency work, a technician calling in sick — the dispatcher can trigger a fresh optimization rather than re-solving the puzzle by hand |
This matters for adoption. The single biggest reason optimization pilots stall is that they demand a new interface and a new workflow on top of an already busy dispatcher. Optimizer's design choice — publish into the tool that already exists — means the training cost is close to zero. The thing that changes is who filled in the Gantt first, not how you read it.
The constraint model does not turn off after the solve. A manual drag that ignores a craft requirement or an availability window is rejected the same way an infeasible optimization run would be. This is what keeps a "dispatcher override" from quietly degrading the schedule's data integrity — it can override priority and preference, not physics.
Graphical Assignment is actually three views, not one. It is worth being precise about which view a dispatcher is looking at, because "the Gantt" undersells what the application does:
| View | Purpose | Horizon |
|---|---|---|
| Work View | Unassigned work orders waiting for a slot — the backlog Optimizer draws from | Rolling, no fixed window |
| Assignment View | The Gantt itself: labor/crew rows against time, drag-and-drop assignment and reassignment | Short-term, typically 2-3 weeks |
| Dispatch View | A day calendar plus map, showing labor and crew assignments geographically with travel time factored in | Today / the current shift |
A dispatcher spends most of a shift in Dispatch View — it is the one built for "what is happening right now, where," which is also the view that overlaps with the Dispatching Dashboard covered next. Assignment View is where the heavier replanning happens, days or weeks out. Work View is the queue Optimizer is emptying; if it is growing rather than shrinking, that is usually the first visible sign a scheduling run needs attention before anyone opens a formal report.
📡 The Dispatching Dashboard: Real Time, Not a Snapshot
The Dispatching Dashboard arrived with MAS 9.0 as a purpose-built layer above Graphical Assignment, and its distinguishing feature is scope: it looks across one or more Graphical Assignment projects at once, rather than requiring a dispatcher to open each project individually to spot a problem. That matters for organizations running separate scheduling projects per region, per crew type, or per facility — the dashboard is where someone watching the whole operation notices that one project's Work View queue is growing while another's is empty, and can trigger a re-run with adjusted parameters without leaving the summary screen.
The Gantt is where the schedule is built and adjusted. The Dispatching Dashboard is where it is run — a real-time view of the day as it actually unfolds:
- Today's optimized schedule, by technician — the plan of record for the shift
- Work order status — assigned, in progress, completed, tracked as the day moves
- Map view — technician locations and their assigned work, geographically
- Real-time adjustments — as conditions change (a job runs long, a technician is delayed), the dashboard reflects it without a manual refresh cycle
This is where Optimizer's output meets the field-status model the MAS MANAGE series covers in detail. Manage 9.0's Field Service Management introduced a Dispatching Status with granular states — TRAVELLING, ONSITE, STARTED, RESTORED — alongside the existing Assignment Status, both fed in real time from Maximo Mobile. The relationship between the two systems is worth being precise about:
| System | Answers | Where it lives |
|---|---|---|
| Optimizer | What is the best possible schedule, given everything I know? | Runs once (or on re-optimization), writes to the Gantt |
| Assignment Status / Dispatching Status | What is this specific technician actually doing with the slot they were given, right now? | Updates continuously through the shift, fed from Mobile |
A technician accepting an assigned slot, traveling to it, arriving on site, starting work, and restoring service is the crew acceptance and execution workflow that turns an optimized assignment into completed work. Optimizer decides the what and who; the status model tracks the is it actually happening. When the two disagree — a technician stuck TRAVELLING far longer than the estimate assumed — that is exactly the signal a dispatcher uses to decide whether to intervene manually or trigger a re-optimization for the rest of the day.
👷 Crew Scheduling and Resource Leveling
Everything so far has described a single technician getting a single slot. A meaningful share of real dispatching is crew-based, and the solver handles that as its own dimension rather than as a special case of individual assignment:
| Capability | What it does |
|---|---|
| Crew assignment | Work orders can be assigned to a crew (a defined group of technicians) rather than one individual |
| Composition awareness | The model understands crew makeup — a lead-plus-apprentice pairing is not interchangeable with two leads, and the solver respects that when filling a crew slot |
| Workload balancing | Assignments are spread across crew members rather than repeatedly loading the same one or two people who happen to sort first |
| Overtime and shift handling | Overtime is scheduled only where the optimization model allows it, and shift-boundary constraints apply to crews the same way they apply to individuals |
Resource leveling is the closely related capability that operates one layer up from any single assignment: instead of asking "who can do this job," it asks "is this pool of technicians about to be over-committed." It prevents double-booking a technician across two work orders in the same window, smooths work distribution so one week is not starved while the next is swamped, and — the part organizations underuse — surfaces bottlenecks explicitly enough that the tool can point at a craft or shift with a structural shortage and suggest that hiring or contracting more of that resource, not further schedule tuning, is the actual fix. A dispatcher who keeps fighting the same craft shortage every week is looking at a resource-leveling signal, not an optimization failure.
🧭 Dispatcher Playbook: Override or Re-Optimize?
The review-adjust-re-optimize rhythm described earlier hides a judgment call dispatchers make dozens of times a shift: does this change warrant a manual drag on the Gantt, or does it warrant handing the whole remaining day back to the solver? There is no universal rule, but the shape of the disruption is a reliable guide:
| Situation | Recommended action | Why |
|---|---|---|
| One technician calls in sick, small day | Manual reassignment of their remaining stops to nearby crews | Small, localized change; a full re-solve is overkill and slower than a drag-and-drop fix |
| Regional storm creates 50+ new emergency work orders | Trigger re-optimization | The scale of new demand exceeds what manual redistribution can rebalance fairly across the whole territory |
| A technician is stuck TRAVELLING far past the estimated window | Manual check-in first, re-optimize only if it cascades | The status model (Assignment/Dispatching Status) is the better first signal — one delay does not always justify redoing the day |
| A required tool turns up missing at the job site | Manual swap to a technician whose kit has it, if one is nearby | Tool-availability constraints are already in the model; a swap within the existing schedule is usually sufficient |
| Resource-leveling flags a craft is structurally over capacity every week | Neither — escalate to staffing/hiring | This is not a scheduling-moment decision; re-optimizing the same shortage weekly just relocates the pain |
| A new SLA-critical work order arrives mid-shift with a tight deadline | Trigger re-optimization if more than one or two technicians are affected | Priority-weighted re-solving is exactly what the objective functions in Part 2 are tuned for |
The general pattern: manual override for small, local, one-off disruptions; re-optimization for anything that changes enough of the picture that a human redistributing it by hand would take longer than the solver would. Re-optimizing for every minor change is its own failure mode — it churns the schedule, erodes technician trust in the plan they woke up to, and burns solver time on problems a drag-and-drop already solved.
🔁 Re-Optimization Edge Cases
Re-optimization is not a single button with one behavior. Three edge cases come up often enough in a rollout to plan for explicitly:
- Protected assignments. A technician who has already started a job, or is mid-TRAVELLING to one, should not be silently reassigned by a fresh solve. Locking in-progress and en-route assignments before triggering re-optimization keeps the re-solve scoped to the remaining day, not the whole day including work that has already physically happened.
- Partial vs. full re-solve. A full re-optimization re-plans every remaining assignment from scratch, which can produce a schedule that looks unrecognizable compared to the one technicians started their day with — correct in aggregate, disorienting in practice. A partial re-solve that only touches affected technicians and unassigned work is usually the better default for anything short of a territory-wide emergency.
- Re-optimization frequency. Nothing stops a dispatcher from re-running the solver every time a single job runs ten minutes long, but doing so thrashes the schedule — technicians see their day reshuffled repeatedly, street-level routes get recalculated more often than they change, and trust in the plan erodes faster than any efficiency is gained. Treat re-optimization as a response to a change in scale (new emergency volume, a crew going down, a cluster of SLA risk), not a reflex for every minor slip.
🛠️ Troubleshooting the Rollout
Most post-rollout problems are not solver bugs — they are gaps between what the model can see and what is actually true in the field. A short list of the ones that surface most often:
| Symptom | Likely cause | Fix |
|---|---|---|
| Schedule keeps assigning a technician whose secondary craft would fit better | Secondary craft/skill data not populated or not visible in the assignment view | Verify secondary craft matching is configured and technician records include qualifying secondary skills, not just primary craft |
| Assignments split oddly across a shift boundary | Automatic shift-boundary splitting behaving unexpectedly for a non-standard calendar | Manually adjust the split's start/end, and confirm shift and break definitions match the actual calendar, not a default template |
| Two technicians on the same crew get uneven daily hours despite "balanced" objective weighting | Workload balancing weight set too low relative to travel-minimization or cost weighting | Rebalance the objective weights from Part 2 rather than treating it as a bug — it is a tuning gap, not a defect |
| Travel-time estimates drift from what technicians actually experience | Straight-line estimation in use where road-network routing (ArcGIS) would be materially more accurate | Evaluate ArcGIS integration (O-10) if travel accuracy is the recurring complaint, rather than only adjusting travel-speed parameters |
| Re-optimization silently reassigns a technician already en route | Re-optimization scope not restricted to unstarted/unassigned work | Confirm protected-assignment handling before enabling frequent re-optimization, per the edge cases above |
| Break-time or after-hours calculations look wrong for certain shifts | A documented gap: independent testing on MAS 9.1.2 identified unresolved issues with break-time and after-hours assignment calculations for some shift configurations | Test your specific shift patterns against a sandbox before trusting break/after-hours math in production, and track the issue against your support case if it reproduces |
The pattern across almost every row: the fix is data, configuration, or scope, not "the optimizer is broken." That has been this series' argument since Part 1, and the rollout phase is where it gets tested against a live dispatcher's patience rather than a design document.
📦 What's New for Optimizer in Recent MAS 9.1 Releases
DOC2's roadmap describes Optimizer's steady-state capabilities; it does not track point-release detail, which changes faster than a roadmap document. A few practitioner-relevant items from the Maximo Optimizer 9.1.0 release notes worth knowing before a rollout:
- Rollback functionality at Operator Maturity Level 3.3 — meaningfully improves resilience if an Optimizer operator upgrade goes wrong on OpenShift, letting an admin step back to the previous working version rather than troubleshooting forward under pressure.
- Improved Large Neighborhood Search (LNS) algorithm — targets scalability and performance on larger dispatching and assignment problems, relevant if your pilot's O-9 volume test (larger work order sets) showed the solver slowing down.
- Automated What-If Analysis, upgraded to use a Radial Basis Function approach for more accurate scenario evaluation — useful for a dispatcher testing "what if I move this crew" before committing to a re-optimization.
- Single Node OpenShift (SNO) deployment support — lowers the infrastructure bar for smaller or edge deployments that cannot justify a full multi-node OpenShift cluster just to run Optimizer.
- Centralized authorization through the common MAS navigation bar — aligns Optimizer's access model with the rest of the suite, reducing one more piece of bespoke setup during the Phase 4 pilot.
Confirm exact version numbers against IBM's release notes for your specific MAS 9.1.x build before planning around any of these — point releases move quickly, and the roadmap's steady-state description in DOC2 is the more durable reference for what Optimizer fundamentally does.
💳 What Optimizer Costs: AppPoints Licensing
MAS licenses everything through a shared AppPoints pool — you do not buy a standalone Optimizer license, you allocate points from the same budget that covers Manage, Health, Monitor, and everything else in the suite.
| Item | Typical Cost | License Type |
|---|---|---|
| Optimizer | ~10 AppPoints / authorized user | Authorized |
| Manage — Base (paired with Optimizer) | ~10 AppPoints / user | Authorized |
| Planner/Scheduler role bundle (Manage Base + Optimizer) | ~20 AppPoints / user | Authorized |
One clarification worth making explicit: Graphical Assignment and Scheduler themselves are entitled and installed as part of Maximo Manage — you are not paying an additional AppPoints line for the Gantt or the Dispatch View. The Dispatching Dashboard is the exception: IBM's documentation states it depends on Optimizer's graphical-assignment optimization models, so Maximo Optimizer must be purchased and installed to use it. The AppPoints cost is specifically for the Optimizer solver that fills those screens. That distinction matters when a budget conversation conflates "we already have Manage's scheduling tools" with "we have optimization" — the tools were always there; the engine is what you are buying.
Two things follow from this being a shared pool rather than a separate purchase:
- Enabling Optimizer competes with everything else you have already deployed. If your organization is already running Health, Monitor, and Predict per the earlier phases of this roadmap, adding Optimizer draws from the same finite budget — confirm headroom before you commit to a pilot, and confirm exact current costs with IBM or your business partner, since AppPoints pricing changes by contract.
- License the role that runs the engine, not everyone who benefits from it. A technician who simply follows their Mobile schedule does not need an Optimizer license — that cost sits with Manage Base + Mobile, already covered in earlier MAS MANAGE content. Optimizer's ~20-point Planner/Scheduler bundle should go to the two or three people who configure constraints, run optimizations, and tune weights, not the entire planning department.
🗓️ Where This Sits: The Phase 4 Rollout
Optimizer is not a Phase 1 application, and that placement is deliberate — it depends on a configured Scheduler and clean labor and location data that earlier phases exist to produce. In the documented roadmap, Optimizer shares Phase 4 (months 10-12) with AI Assist:
| Month | Optimizer track |
|---|---|
| Month 10 | Deploy the Optimizer operator, configure the initial model, begin cleaning labor data |
| Month 11 | Run optimizations, tune parameters, test dispatching against real assignments |
| Month 12 | Compare optimized vs. manual schedules, complete full evaluation |
Phase 4 deliverables for Optimizer: a model producing feasible schedules, an operational Dispatching Dashboard, and user feedback collected on the optimized schedules themselves.
Phase 4 success criteria for Optimizer: a travel-time reduction of at least 15% compared with manual scheduling — the same number carried through every part of this series, because it is the one figure the source roadmap actually publishes as a bar to clear.
✅ The Ten-Task Pilot: O-1 Through O-10
DOC2 lays out the Optimizer pilot as ten concrete team exploration tasks. This is the plan to hand your team, not a vague "explore Optimizer" line item on a roadmap:
| Task | Description | Effort | Depends On |
|---|---|---|---|
| O-1 | Review current scheduling process and identify pain points | 8-16 hrs | Scheduling team interviews |
| O-2 | Verify craft/skill data quality in Manage | 8-16 hrs | Manage data access |
| O-3 | Verify work location coordinate data | 4-8 hrs | Manage data access |
| O-4 | Deploy Optimizer operator on OpenShift | 4-8 hrs | OpenShift access |
| O-5 | Configure optimization model with current constraints | 8-16 hrs | O-2, O-3, O-4 |
| O-6 | Run first optimization on a sample work order set | 4-8 hrs | O-5 |
| O-7 | Compare optimized schedule vs. manual schedule | 4-8 hrs | O-6 |
| O-8 | Review results in Dispatching Dashboard / Graphical Assignment | 4-8 hrs | O-6 |
| O-9 | Test with larger work order volumes and iterate parameters | 8-16 hrs | O-6 |
| O-10 | Evaluate ArcGIS integration for travel optimization (if applicable) | 8-16 hrs | ArcGIS available |
Total estimated effort: 60-120 hours, roughly two to three weeks.
Two things worth noticing about the order. First, O-2 and O-3 come before O-4 — the pilot verifies data quality before it even deploys the operator, which is the whole thesis of Part 3 in engineering-plan form. Second, O-7 and O-8 are where the pilot either earns its budget or doesn't: O-7 puts the optimized schedule side by side with what a human scheduler actually produced, and O-8 is the first time anyone outside the configuration team sees the result in a tool they recognize.
📊 Three Use Cases, Three Documented Payoffs
The roadmap does not ask you to take Optimizer's value on faith — it documents three use case shapes, each with a stated result measured against a manual baseline.
| Use Case | Shape of the Problem | Documented Result |
|---|---|---|
| Field Service Optimization | 50 technicians, metropolitan area, 200+ work orders/day across 500+ locations | 20-30% reduction in travel time; 15-25% more work orders completed per day |
| Maintenance Window Planning | Annual plant shutdown, 500+ work orders in a 14-day window, multiple crafts/tools/contractors, complex dependencies | 10-15% reduction in shutdown duration |
| Emergency Response | Storm damage creates 1,000+ emergency work orders overnight; re-optimizes continuously as new work arrives | Faster restoration; more equitable workload distribution across crews |
These are not interchangeable wins from the same lever. Field service is a travel story — the payoff is almost entirely about minimizing drive time across a dispersed territory. Maintenance-window planning is a dependency and resource-conflict story — the payoff is compressing a shutdown by finding a feasible sequence a human planner would take days to assemble by hand, and by surfacing resource conflicts before they become schedule slips. Emergency response is a speed and continuous re-optimization story — the win is not a static schedule but the engine's ability to keep re-solving as 1,000 new work orders arrive over a single night, something no dispatcher can do manually at that volume.
Know which shape your organization is actually solving for before you pick the success metric you'll report against. A field-service deployment that measures itself on shutdown compression is measuring the wrong thing.
🎯 Measuring Whether It Actually Worked
Every number in this part is relative to a manual baseline, not a theoretical optimum. That is a deliberate and honest framing choice carried from Part 1: Optimizer is not being asked to be perfect, it is being asked to beat what your best scheduler could produce by hand under the same constraints.
The minimum bar, documented once and repeated through the series: at least a 15% reduction in travel time versus manual scheduling. Below that line, the pilot has not proven its case.
A fuller measurement set, drawn from the use cases above and the pilot tasks that produce them (O-7 in particular):
- Travel time — total and per-technician, optimized vs. manual
- Work orders completed per day or per period
- Shutdown or maintenance-window duration, where applicable
- Workload balance across technicians or crews (not just total output, but fairness of distribution)
- Dispatcher time spent building the schedule manually, before vs. after
- SLA hit rate on priority and deadline-bound work
When the schedule looks worse than expected, the documented risk mitigation is specific and not a shrug: tune constraints with field input, and keep the manual override capability available. A schedule that ignores a constraint everyone in the room already knows about is not a sign the optimizer is bad — it is a sign a constraint that lives in someone's head has not yet been entered into the model. That is the same data-and-configuration diagnosis this whole series has been making since Part 1, applied one more time at the finish line.
The Series, Closed
Five parts ago this series opened with a warning: the first optimized schedule a team sees often looks worse than what a human would have drawn, and the wrong conclusion is "the optimizer isn't very good." The right conclusion, restated one final time, is that the optimizer is only ever as good as the constraints it can see — and everything between here and Part 1 has been the program for making those constraints visible.
- Part 1 drew the line between a drawing tool and a solver.
- Part 2 opened the engine: nine constraints, five weighted objectives, the parameters that steer it.
- Part 3 did the unglamorous work that actually determines schedule quality — craft data, shift calendars, coordinates.
- Part 4 made travel visible, from straight-line estimation through Esri ArcGIS routing.
- Part 5 closed the loop — the schedule lands on the Gantt your dispatchers already read, the pilot is ten sized tasks over two to three weeks, and success is a number you measure against your own manual baseline, not an abstraction.
Optimizer is a Phase 4 application for a reason. It rewards organizations that did the earlier work — configured Scheduler, clean labor and location data — with a documented, repeatable payoff. It punishes organizations that skip ahead with a schedule that "isn't very good," for reasons that were never the solver's fault.
References
IBM Official
- IBM Maximo Application Suite Documentation
- Maximo Manage Scheduler and Graphical Assignment (IBM Documentation)
- Maximo Optimizer configuration (IBM Documentation)
- IBM Maximo Application Suite AppPoints licensing
- Dispatching Dashboard (IBM Documentation)
- IBM Maximo Application Suite 9.1.0 - Maximo Optimizer 9.1.0 Release Notes
- IBM Maximo Application Suite 9.1.10 - Maximo Optimizer 9.1.9 Release Notes
Practitioner / Community
Source
- DOC2 — MAS Application Suite Add-Ons & Roadmap, §8.2.2 (crew scheduling), §8.2.5 (resource leveling), §8.2.7-8.2.8 (Graphical Assignment / Dispatching Dashboard integration), §8.6 (use cases), §8.7 (O-1 to O-10 pilot tasks), §13 (AppPoints), §16 Phase 4 (rollout timeline and success criteria).
- Cross-series: MAS MANAGE — Part 7 (Graphical Scheduling, Assignment, and Field Service Management) for Assignment Status / Dispatching Status detail.
- Discrepancy note: the Graphical Assignment three-view breakdown (Work View / Assignment View / Dispatch View) comes from IBM's current online documentation, and the MAS 9.0 origin of the Dispatching Dashboard from IBM's October 2024 FMMUG Scheduler overview rather than DOC2, which describes the integration at a higher level without naming individual views or a version. The MAS 9.1.x release-note items (rollback, LNS algorithm, automated what-if, SNO support) are similarly absent from DOC2's steady-state description — treat DOC2 as authoritative on what Optimizer fundamentally does, and the release notes as authoritative on version-specific detail.
Series Navigation
| Previous: | Part 4 — Routing & Spatial: Travel Time, Route Optimization & ArcGIS |
|---|---|
| Next: | 🎉 You have completed the MAS OPTIMIZER series. Return to the Series Index or continue with the MAS MANAGE series. |
About TheMaximoGuys: We help Maximo developers and teams navigate the move to MAS 9 with practical, no-hype guidance grounded in how the platform actually behaves.
Published by TheMaximoGuys | July 2026
Surendra Katta
Venkat Achanta