Concept prototype
Group Transformation Command Center
A transformation command centre for a fictional energy company, with a grid balancing pilot that shows how an optimisation engine earns trust.
Take the 4-step tour of the grid pilot →
Qhorvane Energy is a fictional Saudi energy company created for this concept. All data is illustrative.
The gap
Most transformation dashboards report. They show the number of initiatives, a budget and a status colour, and leave leaders where they started: knowing the state of things, but not what to do about them.
Optimisation pilots have the same problem from the other side. The maths usually works. What stalls them is everything around the maths: nobody can see what the engine is doing, operators don't trust a schedule they can't question, and the steering committee has no fair way to judge whether it beat the method it replaces.
This concept tackles both. The command centre turns portfolio reporting into decisions. The grid pilot shows one of those decisions in detail: should an optimisation engine schedule a regional grid?
What it does
The command centre
- Executive view. The decision that is due, six headline figures, and the pilot's 24-hour load curve, with nothing on screen that is only decoration.
- Strategy to delivery. Vision 2030 pillars cascade down through programmes to initiatives, so the link between "the strategy" and "the work" stays visible.
- Investment prioritisation. Initiatives mapped by strategic value against execution risk, so the fund-or-stop conversation happens on evidence.
- Change readiness and benchmarking. Who owns what, whether the organisation can absorb the change, and how it compares with anonymised peers.
The grid balancing pilot
- One day, one grid area. A 24-hour schedule for a regional grid with nine gas units, a 300 MW battery, a demand-response block and a large solar share.
- Current against optimised. The same forecast runs through today's rule-based method and through the optimiser, scored by the same model. One switch flips between them.
- Four scenarios that re-plan. A normal day, a dust storm that cuts solar by 40% from 11:00, an evening heatwave, and the largest unit tripping at 19:00. The schedule re-plans, and the screen says what changed.
- An explain panel. Why does the battery discharge at 18:00? Why does a peaking unit stay off? Each answer shows what the alternative would cost, and every alternative is a real re-run of the solver, not a written excuse.
- Accept or override. Operators can accept a recommendation or override it with a reason. Every decision lands in an audit trail the regulator view can read.
- Seven roles, one dataset. Control room operator, day-ahead planner, plant manager, regulator, solution integrator, programme manager and executive. Each sees what they need, and only operations roles can act.
- Governance built in. A business case, stage gates, a risk log and the decision due: proceed from shadow mode to supervised live use, or stop.
- Where every number comes from. A "Show data sources" switch tags each panel with its source, how it is produced, how fresh it is, and whether that feed exists today, so the dashboard doubles as a delivery roadmap.
- A four-step tour. What it saves, watch it re-plan, why operators trust it, and the decision.
What the numbers say
On a normal illustrative day, against today's rule-based schedule:
| Current | Optimised | |
|---|---|---|
| Operating cost | $2.05M | $1.96M (−4.6%) |
| Solar curtailed | 569 MWh | 264 MWh |
| CO₂ | 18,691 t | 18,368 t |
| Unit starts | 6 | 4 |
| Lowest reserve (650 MW required) | 962 MW | 650 MW |
Across the other three scenarios the saving is smaller, between 1.4% and 2.7%. The heatwave honestly needs one more unit start than today's method, not fewer. Reserve never falls below the standard in any scenario.
The business case turns this into $5.4M–$8.7M a year for the pilot area, after two deliberate haircuts: savings counted on only half the days in a year, and only half of those realised, to allow for forecast error, operator overrides and slow adoption. The pilot itself saves nothing. It runs in shadow mode, and benefits start only after a go decision.
How it's built
A single static page: HTML, CSS and plain JavaScript, with Chart.js for the charts and self-hosted open-licence fonts. No framework, no build step. It is deployed on Cloudflare Pages from a GitHub repository. 119 Playwright tests check every role, every scenario, every override, keyboard access, colour contrast and an automated accessibility scan before anything ships — and one test fails if the savings ever drift outside a believable 1–6% range.
The solver is deliberately simple and labelled as such on screen. It is a priority-list unit commitment with a greedy improvement pass and multi-start search, followed by merit-order dispatch with ramp limits. It is not the point. The point is the layer around it, which stays the same whatever engine runs underneath: the operator screen, the explanations, the override trail and the gates. In a real pilot, candidate engines (classical, quantum-inspired or otherwise) would compete in shadow mode against the current method and a classical baseline. Whichever wins on the customer's measures earns the next gate.
The numbers are real. The company isn't.
Qhorvane Energy, its units, people and figures are invented. The framework is real. Saudi Arabia's target of 50% of power from renewable sources by 2030 comes from the Saudi Green Initiative, and it is why curtailed solar matters: every megawatt-hour thrown away at midday is renewable output the system paid for and did not use.
A fictional company keeps the work publishable and makes the method transferable. The same pilot structure fits any utility facing the same problem.
Resisting green
The first version of the optimiser produced a result I couldn't publish: it saved money while curtailing more solar than today's method. Nothing in the model valued lost sunshine, so the solver happily kept gas units running through midday to avoid restart costs. The fix was to model what utilities actually pay: curtailed renewable energy is usually still paid for under the power purchase agreement. Once that cost was in, the optimiser started soaking up midday solar with the battery, as a real scheduler would.
The explain panel caught the second problem. It asked "why does Unit 4 stay off?" and found that starting it was actually cheaper. The solver had settled for a good plan, not the best one it could reach. I added a multi-start search, and the panel now only reports alternatives the solver genuinely tried and rejected. If an explanation feature can embarrass your engine, it is doing its job.
I also kept the gains modest on purpose. A demo that claims 20% savings tells an industry reviewer you don't know the industry. Single-digit savings that come from storage timing and fewer peaking units are believable, and they are the optimiser's share only: same forecast, same units, same reserve rule.
The honest part
The solver was never the hard problem. Getting the data in and getting people to trust what comes out is.
A real version needs live unit status from SCADA, battery telemetry without gaps, demand-response availability from an aggregator that has agreed to share it, and forecasts good enough to survive a dust storm. Then it needs operators who believe the schedule enough to follow it, and a regulator who signs off on the audit trail. The pilot also leaves things out that a production system cannot: network limits, forecast uncertainty and maintenance windows. The integrator view lists them openly.
That is why the pilot ends in a decision gate rather than a go-live date. Twelve weeks in shadow mode, beside the current method, with clear criteria: beat it on cost and curtailment on most days, never breach the reserve standard, and get at least 80% of recommendations accepted by the people who run the grid.
What I'd do next
- Run the classical baseline beside the optimiser, so the three-way comparison is on screen rather than only in the business case.
- Model forecast uncertainty, so the plan carries reserve for a bad forecast as well as a lost unit.
- A screen-reader and real-device pass; automated checks only catch part of what matters.
- Pilot with one utility's real published data.
Built by Shiraz Hussein. Planned with Claude, built with Claude Code, reviewed and tested by hand.