ESC
Type to search across all articles and vendors
Implementation 13 min read

Change Management for FMS Projects

FMS deployment touches every department on site. Here's how to manage the technology, people, process, organisational, and MOS changes that come with it.

Ask most people what FMS change management means and they’ll talk about communication plans, training schedules, and getting operators on board. That’s part of it. But FMS deployment doesn’t just change how trucks get dispatched. It rewires how information flows across the entire operation. IT inherits a 24/7 production system. Geology suddenly depends on a dispatch engine to enforce material routing. Engineering has to update a digital model every time a dump moves. Training needs competency frameworks for roles that didn’t exist six months ago.

Technology Changes When Deploying an FMS

FMS introduces hardware, software, and data flows that didn’t exist before. The scope catches people off guard.

Hardware

Every production unit gets an on-board computer (or tablet display), a GPS antenna, and connectivity to the site network (whether that’s radio, WiFi, mesh, or a combination). The server room gains new infrastructure. The communication network, which was probably adequate for voice radio, now carries continuous position and status data from every equipped machine.

Software

The FMS application itself is only the starting point. Most deployments also require integration middleware connecting FMS to the ERP, maintenance management system (CMMS), geology/grade control platform, and reporting tools. Each integration is a project within the project.

Data

This is where the real shift happens. FMS generates continuous data streams: position updates, equipment status changes, payload measurements, cycle times, material tracking records. Most mines have never dealt with this volume or velocity of operational data. Questions that nobody asked before suddenly matter: Who owns this data? Who validates it? What happens when it’s wrong? What’s the retention policy?

IT/OT Convergence

FMS sits at the boundary between Information Technology (corporate systems, databases, business applications) and Operational Technology (on-board equipment, field networks, real-time machine interfaces). These have traditionally been separate worlds with separate teams, separate standards, and very different risk tolerances.

IT teams think in terms of patching cycles, change windows, and data security. OT teams think in terms of uptime, latency, and physical safety. When FMS forces these domains together, the friction points are predictable:

  • Ownership: Does IT own the servers and network, while OT owns the on-board equipment? Where’s the boundary?
  • Change control: IT wants scheduled maintenance windows. Production can’t afford two hours of FMS downtime mid-shift.
  • Cybersecurity: Connecting operational equipment to corporate networks creates attack surfaces that neither team has managed before.
  • Support model: When the FMS goes down at 2 AM, who gets the call, the IT help desk or the on-site OT technician?

Sorting this out before deployment saves enormous grief after go-live. Most mines that struggle with FMS adoption can trace at least some of their problems back to unresolved IT/OT governance. For a broader view of infrastructure planning, see Planning an FMS Implementation.

Organisational Changes: Roles, Ownership, and Decision Authority

FMS changes reporting lines, creates new roles, shifts decision authority, and creates cross-functional dependencies that didn’t exist before.

New Roles

Most deployments create or formalise at least three roles:

RoleResponsibility
FMS AdministratorSystem configuration, user management, road network updates, troubleshooting
Dispatch ControllerMonitoring dispatch compliance, managing exceptions, adjusting assignments in real time
Data AnalystValidating data quality, producing performance reports, identifying improvement opportunities

Some sites combine these. Smaller operations might push all three onto one person. But the work exists regardless of how the org chart handles it.

Shifted Decision Authority

The biggest organisational shock is where dispatch decisions land. Before FMS, a supervisor decides which truck goes where, usually by radio, often by gut feel combined with experience. After FMS, an algorithm makes the primary assignment. The supervisor’s role shifts to managing exceptions, monitoring system performance, and making strategic decisions the algorithm can’t handle (face changes, weather responses, priority shifts).

Some supervisors welcome this. Others feel deskilled. The ones who struggle most are often the best manual dispatchers. They’ve built their identity around making good calls quickly, and the system takes that away.

Who Owns the FMS?

This question generates more heat than it should, but it matters. Common ownership models:

  • Operations-led: FMS sits under the Production or Mining department. Advantage: close to the users. Risk: IT support gets treated as an afterthought.
  • IT-led: FMS sits under Information Systems. Advantage: proper infrastructure management. Risk: decisions get made by people who don’t understand pit operations.
  • Joint steering committee: Shared governance with representatives from Operations, IT, Engineering, and Geology. Advantage: balanced decision-making. Risk: slower decisions, diffused accountability.

There’s no universally right answer, but the decision needs to be explicit. Ambiguous ownership leads to finger-pointing when things go wrong.

Borrowing from ITIL service management can help structure this. Two roles matter:

  • Business Owner: Accountable for the business outcomes the FMS is supposed to deliver: production targets, cost reduction, safety improvements. This is typically the Mine Manager or General Manager of Mining. They don’t touch the system day-to-day, but they approve budgets, set strategic priorities, and are the ultimate escalation when the FMS isn’t delivering value.
  • Service Owner: Accountable for end-to-end delivery of the FMS as a service: uptime, performance, change control, vendor management, user support. This maps to the OT Supervisor, Mine Systems Superintendent, or equivalent. They represent the FMS in change advisory discussions, negotiate support agreements with the vendor, and own the response when the system goes down at 2 AM.

Underneath the Service Owner sits the day-to-day FMS Administrator who handles configuration, user management, and first-line troubleshooting. The hierarchy (Business Owner, Service Owner, FMS Admin) creates clear escalation paths and separates “is this system delivering value?” from “is this system running properly?” When those questions land on the same person, one always gets neglected.

How FMS Affects Each Department

Every department on site experiences FMS differently. Understanding what each group gains, loses, and fears is the foundation of effective change management.

Operations and Production

Operators move from radio-based dispatch to screen-based instructions. The adjustment is mechanical (learn the interface) and psychological (accept that every movement is now tracked and measured). The surveillance concern is real. Operators know their queue times, idle periods, and route deviations are all recorded. The common mistake is dismissing this as resistance to change. It’s a legitimate concern about how data will be used, and it deserves a straight answer.

Supervisors face the authority shift described above. They also gain something: real-time visibility across the entire fleet, which was impossible when they relied on radio calls and windshield surveys. The good ones discover that FMS frees them to focus on the decisions that actually need human judgement.

IT

IT inherits a production-critical system on a mine site that runs 24/7. For corporate IT teams accustomed to business-hours support and scheduled maintenance windows, this is a culture shock. The system doesn’t wait for Monday morning. If the FMS goes down on a Saturday night shift, production stops dispatching efficiently and someone needs to respond.

IT also faces the OT unfamiliarity problem. On-board computers in haul trucks aren’t laptops. GPS infrastructure isn’t a standard network deployment. The environmental conditions (dust, vibration, temperature extremes) are nothing like a server room.

OT and Electrical

The OT team handles the field-side equipment: on-board computers, GPS antennas, and radio infrastructure. They’re used to maintaining equipment in harsh conditions, but FMS adds software complexity on top of their traditional hardware focus. The boundary with IT (who fixes what, who escalates where) needs to be crystal clear.

Engineering

Mine planners and engineers might not use the FMS directly, but their work feeds it constantly. Every new road segment, dump relocation, load point change, or pit stage advance needs to be reflected in the FMS road network and operational model. This creates a change control process that most engineering teams haven’t dealt with before.

In practice, this means engineering can’t just move a dump and tell the supervisor at the start of shift. The FMS needs updating first, or trucks will be dispatched to a location that no longer exists (or sent on a route that hasn’t been built yet). The turnaround time between mine plan changes and FMS updates becomes a workflow dependency.

Geology

Grade control integration is one of the higher-value FMS capabilities, but it’s also one of the more disruptive changes for geology teams. FMS can enforce material routing, sending trucks to the correct destination based on the grade block they loaded from. This means geology’s dig plans and grade block definitions need to be current, accurate, and loaded into the system.

When it works well, FMS enforces compliance that previously relied on operator memory and supervisor vigilance. When it doesn’t (usually because grade block data is stale or boundaries are poorly defined), trucks end up at the wrong destination and the geology team loses trust in the system fast.

Training

Training teams face the broadest change management challenge. Every FMS user role needs a competency framework: operators, dispatchers, supervisors, maintenance planners, engineers, geologists. Initial training is just the start. There’s also new starter induction (every new employee needs FMS training), refresher programmes, and change management for system upgrades and version releases.

The logistics are painful. A mine running four-panel rosters needs to deliver the same training session at least four times to cover every crew. Night shift crews are notoriously hard to reach. And training close to go-live (which is when it’s most effective) competes with every other operational priority.

Maintenance

Maintenance teams gain access to equipment health data, automated downtime tracking, and potentially condition-based maintenance triggers. The shift from reactive (“fix it when it breaks”) toward condition-based monitoring (“the system flags that this component’s operating parameters are outside normal range”) sounds good on paper. In practice, it requires maintenance planners to trust system alerts enough to act on them, scheduling work based on condition data rather than calendar intervals or operator complaints. Full predictive maintenance typically requires integration with specialised analytics platforms beyond the FMS itself.

Alert fatigue is the common failure mode. If the system generates too many low-confidence alerts, maintenance teams learn to ignore them, and the monitoring capability becomes worthless.

Process Changes: Dispatch, Handover, Reporting, and Material Tracking

FMS doesn’t just automate existing processes. It eliminates some, creates others, and fundamentally alters the ones that remain.

Dispatch

The most visible process change. Manual dispatch (supervisor assesses the pit, picks up the radio, directs trucks) becomes algorithmic assignment with human oversight. But you need clear rules for when and how to override the system. What happens when the algorithm sends a truck somewhere the supervisor knows is wrong? Who has override authority? How are overrides logged and reviewed?

Shift Handover

Pre-FMS shift handover is largely verbal: what happened, what’s planned, what to watch out for. Post-FMS, handover includes system status, data quality checks, active assignments, pending road network changes, and any unresolved system issues. The handover becomes structured and data-driven, but only if someone designs the handover process and builds it into the shift routine.

Production Reporting

Manual tally sheets and end-of-shift spreadsheets give way to automated reports. This is faster and more accurate, but it creates a false sense of precision. Automated reports are only as good as the data going in. Someone needs to validate data quality, investigate anomalies (why does the system show 15% idle time on Truck 42 when the operator says they were loading?), and understand what the numbers actually mean.

Road Network Management

Every change to the physical mine (new road, relocated dump, closed haul route) must be reflected in the FMS. This creates a formal change control process: request the change, update the digital model, test the routing, deploy to production. Mines that treat FMS updates as an afterthought end up with trucks being dispatched on routes that don’t match reality.

Material Tracking

Ore versus waste routing, grade control compliance, stockpile management: all become more rigorous when FMS tracks every load from source to destination. This tightens accountability (you can see exactly which truck dumped which load where) but also requires more disciplined dig plan management from geology and more rigorous location definitions from engineering.

Management Operating System (MOS)

FMS data doesn’t just sit in reports. It should flow into the structured management cadence that drives daily, weekly, and monthly operational decisions. This is where FMS connects to the Management Operating System.

Tiered Review Cadence

Most mining MOS frameworks use a tiered meeting structure:

TierCadenceFMS Data Role
T1: Crew/shift levelStart of shift, end of shiftReal-time assignments, shift production vs plan, equipment status
T2: Supervisor/departmentDailyPrevious shift performance, cycle time trends, utilisation, dispatch compliance
T3: ManagementWeeklyFleet productivity trends, cost per tonne, availability vs utilisation, improvement projects
T4: Site leadershipMonthlyStrategic performance review, capital equipment decisions, long-term fleet planning

Before FMS, most of this data was compiled manually, often late, often incomplete, sometimes inaccurate. FMS makes the data available in near real-time, which is powerful but also exposes performance gaps that were previously hidden in aggregated weekly reports.

KPI Framework

New metrics become available and need to be built into performance management: truck utilisation, queue time at shovels, hang time (shovel waiting for trucks), cycle time variance, dispatch compliance rate, payload accuracy, material routing compliance. The MOS needs to define which metrics matter at each tier, what the targets are, and what the escalation path is when performance drifts.

Cultural Shift

The deeper change is cultural. MOS shift reviews move from anecdote-driven (“we had a good shift, got a lot of dirt moved”) to data-driven (“utilisation was 78% against a target of 82%, with 4.2 minutes average queue time at Shovel 3”). Supervisors present data, not stories. This is uncomfortable for experienced operators and supervisors who’ve built careers on gut feel and pit sense, but it doesn’t replace those skills. The best outcomes happen when data and experience work together.

Common FMS Change Management Mistakes

A few patterns show up repeatedly on sites that struggle with FMS change management:

  • Treating it as a technology project. The vendor installs the system, IT supports it, operations uses it. In reality, FMS is an organisational transformation project with a technology component. (See Common FMS Implementation Pitfalls for more on what goes wrong.)
  • Starting change management at go-live. By the time operators first see the system, their opinions are already formed based on rumour, previous site experience, and what they’ve heard from other mines. Start early.
  • One-size-fits-all communication. An operator’s concerns about surveillance have nothing in common with IT’s concerns about 24/7 support. Tailor the message to the audience.
  • Ignoring the MOS connection. The system generates data. If nobody changes how that data flows into management decisions, the FMS becomes an expensive tracking tool instead of an operational improvement platform.
  • Underestimating training logistics. Four crews, three shifts, remote site access, competing operational priorities. Budget twice the training time you think you need.

Key Takeaways

  • Map change across all five dimensions (technology, organisational, people, process, MOS) before deployment, not just the obvious ones.
  • Resolve IT/OT ownership and support models before go-live. Ambiguity here creates chronic problems.
  • Design stakeholder engagement for each department separately. Operations, IT, Engineering, Geology, and Training each have different concerns and different change curves.
  • Build FMS data into your MOS cadence from day one. If the data doesn’t drive decisions, adoption stalls. See Continuous Improvement Using FMS for what comes next.
  • Budget training for four-panel coverage, refreshers, new starters, and system upgrades, not just the initial rollout.
implementationchange-managementtrainingstakeholdersMOSIT-OTFMS