Most Field Service Management rollouts on Maximo succeed or fail on three decisions, and they are almost always made before the supplier ever opens a deck. They are not technology decisions. They are operating decisions that the project then has to live with for the next several years.
Here are the three, in the order we tend to see them matter.
Decision one: which of the FSM components are actually in scope
FSM on MAS is not a single product. It is a set of capabilities — Maximo Mobile, Scheduler, Optimizer, Spatial, Collaborate — sitting on top of Manage. The first decision the operator has to make, before anyone draws an architecture, is which of those are actually in scope and in what order.
The pattern that holds up is to anchor on Mobile and Scheduler first. Mobile gives the technician the asset record on the tablet. Scheduler gives the planner the capacity picture. Almost every operating benefit of FSM comes from those two being properly designed against the trade and the planning function, before anything else is layered on. Spatial is genuinely useful where the work is geographically distributed and the location of the crew matters as a planning constraint, but it does not earn its licence on a tightly clustered estate. Optimizer is the most powerful and the most often misapplied — it produces optimal schedules against the constraints it is configured for, and the rollouts that fail tend to be the ones where the planning function is not yet ready to use what it produces.
The mistake we see most often is “all of them on day one.” The mistake we have made ourselves, once or twice, is “Optimizer because the steering committee wanted Optimizer.” The right answer is sequence: Mobile and Scheduler first, Spatial and Collaborate where the operating model warrants them, Optimizer last and only when the planning function is mature enough to use it.
Decision two: there is one asset record, not two
This is the decision that quietly decides whether FSM is the extension of Manage it is supposed to be, or another parallel system in waiting.
The technician opens Mobile in the morning and looks at a work order. That work order is attached to an asset. The question is: is the asset the same record the planner planned against, the maintenance engineer trended last quarter and the reliability engineer wrote up after the last failure?
If the answer is yes — one asset record from plan to dispatch to close-out — FSM compounds the value of Manage. The data the technician captures flows back to the same record the rest of the operation reads. Failure codes, photos, time on tools, parts used, all of it accrues to a single source of truth.
If the answer is no — there is a “field” version of the asset record alongside a “back office” version of the asset record — the operator has built a second system. Within a year, the two records have diverged, and the question of which one is correct becomes a standing argument.
The decision sounds obvious. It is not always obvious in the implementation. Suppliers occasionally propose architectures where Mobile holds its own asset record cache that periodically reconciles. The right answer to that proposal is “no.” The asset record lives in Manage. Mobile reads from it and writes to it. There is no second copy.
Decision three: the dispatch operating model has to be designed before Optimizer
Optimizer is a constraints engine. It produces schedules that minimise an objective function — usually some combination of overtime, travel, SLA risk and crew utilisation — subject to constraints about qualifications, parts, lone-worker rules, contractual SLAs and the working week. The schedule it produces is only as good as the constraints it is given.
The decision the operator has to make is who in the planning function owns the constraints, who tunes them, and who is allowed to override the schedule. That is not a technology decision. It is a decision about how the planning function works.
Where it is made deliberately, Optimizer earns its licence inside two quarters. The planning function becomes more strategic, the dispatchers spend their time on exceptions rather than on routine plotting, and the technicians get a schedule that holds up against the day’s reality.
Where the decision is deferred, Optimizer produces schedules that the dispatchers override every morning. Within a quarter, the technicians have noticed that the schedule on their tablet at 06:00 is not the schedule they actually run, and the credibility of the whole programme leaks. Within two quarters, the planning function has reverted to the old way of doing things and Optimizer is sitting there unused, generating an OpenShift bill.
The fix is to design the dispatch operating model first — who owns the constraints, who tunes them, who overrides them — and then turn Optimizer on against that model. Not the other way round.
What this means for sequencing
The implication of these three decisions is a particular sequence. Get Manage in good enough shape to be the spine. Roll out Maximo Mobile against the trade, with the asset record kept in Manage. Stand up Scheduler against a planning function that understands its own capacity picture. Add Spatial where the geography matters, and Collaborate where the technician genuinely needs the remote-expert help. Then, and only then, turn Optimizer on against a designed dispatch operating model.
The mistake is doing this as a stack of technology decisions. It is a stack of operating decisions, and the technology is the easy part.
Closing position
The three decisions — what is in scope, that there is one asset record, that the dispatch operating model is designed before Optimizer — decide whether an FSM rollout on Maximo lands. They are made early, often before the supplier walks in, and they are almost never undone in flight.
For the broader implementation pattern, see IBM Maximo Field Service Management — how we deliver it and the pillar guide for buyers. For the mobile-specific operating story, see Maximo Mobile.