Timefold’s Field Service Routing API automatically schedules around 50,000 maintenance operations per year for approximately 1,500 technicians, reducing dispatcher workload, improving qualification compliance, and minimizing travel time across a nationwide rail network.. It's hooked up directly into SAP S/4HANA, without a parallel data store. The solution was designed and implemented by e-switch and embedded into its SAP-based Mobile Productivity Suite.

[highlight]

Due to confidentiality requirements, the customer is referred to as a major European rail operator.

[highlight]

The problem

A major European transport company operates a nationwide network of passenger and freight rail. Keeping that network in service means maintaining many classes of asset on different intervals and to different safety rules: track, electrification and power systems, signaling and control, stations and terminals, trackside monitoring assets, and communication and IT infrastructure.

The first part of the problem is scale: roughly 50,000 maintenance operations per year, around 1,500 technicians, and maintenance facilities spread across the whole country. The second part is complexity. Technicians hold different qualifications. Many operations need several technicians on site at once, and operations depend on each other. Most jobs are reached by driving from one site to the next, so travel time is a real cost.

For more than a decade the rail operator had run e-switch's mobile and dispatching applications: e-companion for mobile execution and e-planning for dispatching, live since 2011. That digitized the work, but the assignment decision itself was still manual. Dispatchers decided who went where, and in what order, from experience.

Manual dispatch works at a small scale and breaks down as resources, skills, time windows, and exceptions grow. At 50,000 operations a year it had long ago crossed that point. The recurring problems were:

• Assigning that volume of operations by hand made good allocation impossible in practice.
• Address and qualification master data was incomplete or wrong, so any manual decision built on it was unreliable.
• There was no systematic check that the technician sent to a job actually held the required qualifications.
• Coordinating multi-technician operations and their dependencies was extremely hard to line up manually.
• Without route optimization, technicians spent more time driving than they needed to.

It was time to take a next step, far beyond simple dispatching: automated, optimized scheduling that supports the dispatcher rather than replacing their judgment.

Why they chose Timefold

A maintenance schedule isn't a calendar. It's a constraint problem, with qualifications, shifts, execution windows, travel, and inter-operation dependencies all interacting at once. The rail operator and e-switch learned how hard that problem is firsthand: they first built their own optimization model on a solver framework, initially on OptaPlanner and later on Timefold's Enterprise Solver. (Timefold is the commercial evolution of OptaPlanner, with over 20 years of constraint-solving heritage.)

[highlight]

In e-switch's words:

"Due to the high level of complexity, developing a bespoke optimization model proved to be very time-consuming, particularly when addressing requirements involving interdependent tasks."

[highlight]

Building and maintaining the constraint logic from scratch was not what their team wanted to focus on, and results weren't always stable. Once that became clear, the railway provider decided to move to Timefold's standard Field Service Routing (FSR) model, an out-of-the-box SaaS optimization engine for assigning technicians and vehicles to visits while respecting skills, time windows, travel, overtime, dependencies, and fairness. FSR ships with 50+ pre-built constraints, so the team didn't have to model the domain themselves.

"We transitioned to Timefold's standard FSR model, which significantly accelerated project progress and markedly improved optimization stability. The continuous enhancement of the standard FSR model further accelerates the implementation of new optimization scenarios, such as real-time planning."

The reasoning behind the move:

• FSR encodes the routing and assignment problem, so e-switch could configure constraints rather than build a model from scratch.
• It was more stable. The standard model produced more reliable results than the bespoke one.
• New scenarios get cheaper. Because Timefold keeps enhancing FSR and more and more capabilities get added, there is no risk of falling behind.
• It fits the deployment. The Field Service Routing model runs primarily on Timefold Platform, but can also be installed on-premise. In this case, the on-premise option was selected to meet the operator's operational and data-protection requirements.

This is a build-vs-buy story. Custom solvers and raw libraries make you model the domain and maintain it. The operator proved initial value with a custom model, then adopted Timefold's out-of-the-box model to ship faster, more comprehensive, and more scalable scheduling.

How it integrates with SAP

The rail operator runs SAP S/4HANA as the system of record for maintenance. One principle shaped the whole integration:

[highlight]

"A key principle of our approach is to avoid replicating SAP data into external database systems. Instead, data is read and updated directly within SAP, ensuring a true 1:1 representation without synchronization delays or inconsistencies."

[highlight]

Rather than copying work orders, asset data, and HR records into a separate optimization database and then managing synchronization, the solution reads master and transactional data directly from SAP and writes results directly back. There's no second copy of the truth.

“Work orders are divided into operations. Each operation can consist of multiple splits (visits), which are assigned to technicians (vehicles). A status schema is associated with each operation.

Following either manual assignment by a dispatcher or automatic assignment by the optimizer (FSR model), the operation is set to the PLAN status. Dispatchers then review the optimized schedule and may make manual adjustments or coordinate additional activities as required.

Once the planning has been finalized, the dispatcher releases the operation, changing its status to DISP (Dispatched). At this point, the assigned splits are transmitted to e-switch’s mobile application, e-companion, where they become available to the technicians for execution.” 

The integration flow

The integration is handled by an e-switch component, the XRB SAP listener / XRB SAP service, which sits between SAP and the Timefold FSR model. It's the optimization layer embedded into SAP rather than bolted on beside it.

1. SAP pushes data out via RFC. SAP sends data to the XRB SAP listener, which has registered itself at an SAP RFC destination.
2. Request translation, SAP XML to FSR JSON. The listener converts SAP's request structure (XML) into the FSR model's JSON input, mapping orders, operations, technicians, shifts, and skills onto the FSR domain model. This mapping layer is the heart of the integration.
3. Timefold solves. The FSR model, running as an on-premises Kubernetes deployment, optimizes the assignment of operations to technicians.
4. Response translation, FSR JSON to XRB SAP service structure. The listener converts the FSR response back into the XRB SAP service structure.
5. Write-back via function module. The XRB SAP service calls the SAP MPS function module, which updates assignments, travel durations, and the schedule directly inside SAP.

The integration runs in two modes: batch for bulk and periodic optimization, and event-driven (webhook) for on-demand triggering. With the no-replication principle, optimization always runs against live SAP data and results land straight back in SAP.

What was hard, and how it was solved

The hardest problems were in the data, not the solver.

• Qualification and skill data. Constraint-based skill matching is only as good as the underlying data. The operator reviewed qualification and skill data repeatedly, then completed and restructured it so the solver could enforce skill constraints reliably.
• Geo-coordinate accuracy. Minimizing travel depends on knowing precisely where each job is, but many rail assets have no street address and sit far from any mappable building or road. Coordinate data had to be revised before routing could be trusted. We increased the maxDistanceFromRoad parameter to ensure that routes can also be generated for locations whose coordinates are situated further away from officially mapped roads, such as assets located along railway tracks. In practice, technicians typically park their vehicles at the nearest accessible road and walk the remaining distance to the work location.
• Mapping SAP structures. Translating SAP's order and operation structures onto the FSR model, and back, was a core part of the listener's job.

[highlight]

e-switch's lesson for other SAP integrators:

"A significant portion of dispatching expertise currently lives solely in the minds of individual dispatchers. To scale, this tribal knowledge must be formalized, translated into structured data, and maintained within your ERP system. This is exactly where Timefold helps. Because the Field Service Routing API operates on structured inputs, it forces the formalization of implicit rules, turning a dispatcher's intuitive knowledge into systemized, reproducible data."

[highlight]

Optimization forces tacit dispatcher knowledge to become explicit, encoded as constraints and data, and held to a higher quality standard.

How the API works

The problem maps onto Field Service Routing directly: order operations and splits (visits) are assigned to technicians (the mobile resources in FSR). The objectives are to minimize travel time and to satisfy qualification and skill matching and technician availability.

The constraints the solver handles include:

• Qualifications and skills: only assign a technician certified for the job (hard constraint).
• Technician shifts: respect when each technician is available.
• Order execution windows: earliest start and latest end per operation.
• Travel time: minimize driving between sites (soft constraint).
• Plan as early as possible: schedule work early to leave room for the unexpected.
• Operation dependencies and multi-technician coordination: line up operations that must happen together.

For urgent or unplanned maintenance, the current phase relies on manual intervention in e-planning. The next phase introduces real-time planning, building on continuous enhancements to the standard FSR model.

Timefold’s workforce scheduling APIs support labor-law-style constraints such as shift and overtime limits, but the organization remains responsible for verifying its own compliance.

The outcome

The clearest change is in what dispatchers do.

[highlight]

"The workload of dispatchers is significantly reduced, shifting their role from active planning to monitoring. This enables them to utilize their time more efficiently for higher-value dispatching and planning activities."

[highlight]

Automating the assignment of roughly 50,000 operations a year removes the manual allocation burden and frees experienced dispatchers to focus on exceptions, coordination, and improvement.

A second outcome is data quality. Because the optimizer is hooked directly to SAP, the project included a thorough review of master data, especially address, geo, and qualification data. That data was cleansed and improved across multiple phases. It's a benefit that outlasts the project, since cleaner master data improves every process that touches it.

For an SAP-centric organization, the architecture delivers specific value:

• Existing SAP core and master data is used directly for optimization, with no new system of record to maintain.
• No replicated database, so a true 1:1 representation of SAP data with no synchronization delays.
• Fewer manual steps in dispatching, with results landing back in SAP where work is executed and tracked.

By matching skills, coordinating multi-technician jobs, respecting shifts and execution windows, and minimizing travel, the solution addresses exactly the failure points of manual scheduling.

What started as a dispatching challenge evolved into a fully integrated SAP optimization platform. By combining e-switch’s deep SAP expertise with Timefold’s Field Service Routing engine, the rail operator can now optimize tens of thousands of maintenance operations annually while keeping SAP S/4HANA as the single source of truth.

What's next

The roadmap points to real-time planning: moving beyond manual intervention for urgent work toward continuous, automated re-optimization. Because the solution is built on Timefold's continuously enhanced standard FSR model, scenarios like this can easily be adopted.

About the partnership

Timefold builds optimization APIs that solve complex scheduling, routing, and resource allocation problems. The Field Service Routing model used here assigns technicians and vehicles to visits while respecting skills, time windows, travel, overtime, dependencies, and fairness. Timefold is an optimization layer that embeds into other software and workflows; it isn't a full field service management platform.

e-switch is the implementation partner that delivered the solution. e-switch has deeply integrated its Mobile Productivity Suite into SAP S/4HANA, supporting service and maintenance operations through configurable mobile (e-companion), dispatching (e-planning), and optimization (e-optimize) applications. The rail operator has run e-switch's mobile and dispatching applications in production since 2011. The e-optimize project, powered by Timefold's FSR model, is the next step toward automated, optimized scheduling.