Maintenance schedules that are solved, not argued about.
An asset-management and maintenance-optimisation platform for a national electricity utility. It holds the asset estate, models crews, shifts, spares, outage windows and travel as real constraints, and generates the maintenance schedule against a mathematical solver — with what-if analysis, a Gantt view, crew-load reporting and a geographic asset map, in Hebrew and English.
Too many variables, and most of them are people.
The requirement, in the customer’s own words, was a system to manage turbines and other equipment across many locations where the plan depends on a great many variables and on people — and which had to be easy to use. Those two requirements pull against each other: the honest formulation is a large constrained-optimisation problem, and the people who run maintenance are not operations researchers. The product resolves that by solving the hard problem underneath and exposing it as a planning workspace, a Gantt and a set of questions you can ask.
Five things that follow from treating it as an optimisation problem.
The schedule is solved, not drafted
Maintenance planning across a large asset estate is a constrained optimisation problem — crews, shifts, skills, spares, outage windows, travel and asset criticality all bind at once. It is handled as one, against a mathematical solver, rather than assembled by hand in a spreadsheet and defended afterwards.
What-if before commit
The value of solving it is being able to ask the next question. Change the crew availability, move an outage window, raise an asset’s criticality — and see the resulting plan before anyone commits to it.
People are a constraint, not a resource pool
Teams and shifts are modelled explicitly, and team load is a first-class report. A plan that is theoretically optimal and requires a crew to be in two substations at once is not a plan, and the system is built to know that.
The estate is geographic
Assets sit in locations and travel between them costs time. A map view is not decoration here — it is how the planner sees the constraint that a Gantt chart hides.
Hebrew and English, properly
The interface is fully bilingual with genuine right-to-left support, not a translation layer bolted onto a left-to-right design. For the people who actually schedule the work, that is the difference between a usable system and one that gets worked around.
It plans the work. It does not operate the plant.
This is a maintenance planning, scheduling and reporting system. It does not operate, control, monitor or protect electrical equipment; it is not a SCADA system, not a protection system and not part of any safety function. It decides when a crew should go and service an asset — the asset itself is run by the systems that run assets.
Every asset, its type, its place and its criticality.
Distance is a constraint, so geography is a view.
The register covers the equipment classes a transmission and distribution estate actually contains — turbines, transformers, electrical panels, conductors, breakers and generators — each with location, criticality and current status. The map view exists because travel time between sites is one of the binding constraints on any real schedule, and a Gantt chart cannot show it.
- Asset register by type, location, criticality and status
- Geographic asset map across the estate
- Asset-type and status distribution reporting
- Spares and materials inventory tied to the work that consumes them
Planned, corrective, and coordinated with the outside.
Maintenance tasks run against assets through pending, active, completed and failed, on a control board that shows the current position. A rule builder lets the maintenance policies that generate and constrain work be edited by the people who own them rather than by a developer. External coordination is modelled explicitly, because a large share of utility maintenance waits on somebody who does not work for the utility.
Solve it, then interrogate it.
A solver, not a sorting rule.
The schedule is expressed as a constrained-optimisation problem — crews and their skills, shift patterns, outage windows, spares availability, travel between sites and asset criticality — and solved as one, using a mathematical programming solver with IBM CPLEX as the reference. That matters because these constraints interact: relieving one almost always tightens another, which is precisely what hand-built schedules get wrong.
- Crew availability, skills and shift patterns as hard constraints
- Outage windows and asset criticality weighted into the objective
- Travel between locations costed into the plan
- Spares and material availability bound to scheduled work
- Policy rules from the rule builder applied to the formulation
Five ways to look at the same plan.
Gantt
The plan over time, per asset and per crew.
What-if
Change an input, re-solve, and compare before committing to anything.
Performance forecast
Projected execution against the plan, rather than only the plan itself.
Team load
How the work distributes across crews — the check that catches an impossible schedule.
Reporting covers planned versus completed versus failed over rolling months, alongside asset-type and status breakdowns, so plan quality can be assessed against what actually happened rather than against what was intended.
Every area.
Assets
- Asset register — Every asset with its type, location, criticality and status — turbines, transformers, electrical panels, conductors, breakers and generators.
- Asset map — The estate plotted geographically, so distance and clustering are visible when planning.
- Inventory — Spares and materials, tied to the work that consumes them.
- Status distribution — The current state of the estate at a glance, by asset and by task state.
Maintenance
- Maintenance tasks — Planned and corrective work against each asset, with state through pending, active, completed and failed.
- Control board — The operational board for what is happening now and what needs attention.
- External coordination — Work that depends on outside parties — contractors, authorities, other departments — tracked rather than assumed.
- Rules — A rule builder for the maintenance policies that generate and constrain work, editable without a developer.
People
- Teams & shifts — Crew composition, shift patterns and availability as explicit scheduling inputs.
- Team load — How the proposed plan distributes across crews — the report that catches an impossible schedule.
- Users — Access and roles across planners, supervisors and crews.
Planning & analysis
- Planning — The optimisation surface where the schedule is generated against its constraints.
- Gantt — The plan over time, per asset and per crew.
- What-if analysis — Change an input, re-solve, and compare the outcome before committing.
- Performance forecast — Projected execution against the plan.
- Overview & reports — Planned versus completed versus failed over rolling months, plus asset and status breakdowns.
Platform & approach.
| Domain | Maintenance planning and scheduling for a large, geographically distributed asset estate |
|---|---|
| Optimisation | A constrained-optimisation formulation solved against a mathematical programming solver, with IBM CPLEX as the reference |
| Constraints | Crew availability and skills, shift patterns, outage windows, spares, travel, asset criticality and policy rules |
| Asset types | Turbines, transformers, electrical panels, conductors, breakers and generators |
| Analysis | Gantt, what-if re-solve, performance forecast, team load and geographic asset map |
| Rules | A user-editable rule builder for maintenance policy |
| Localisation | Fully bilingual Hebrew and English with complete right-to-left support |
| Interface | Web application with a planning workspace and a reporting workspace |
Delivered for a national electricity utility. The customer is not named and the branding in the screenshots on this site is blurred at their request.