The sixteen tabs problem
How DC energy ops accumulated fourteen systems that don't talk to each other. It's not a technology problem.
Nobody decides to run energy ops across fourteen systems. It accumulates. You buy a BESS, the vendor ships a portal. Add a solar array, another portal. Grid operator dashboard. DCIM for the white space. BMS for the mechanical side. Procurement gets a trading terminal. Someone in finance needs SAP. Before anyone notices, the ops lead has sixteen tabs open and a spreadsheet reconciling three of them by hand every Monday.
This is the state of most data centre energy operations in Europe right now. Not a technology problem. A procurement-history problem.
One operator we've spoken to in FLAP-D runs seven monitoring systems at a single 30MW site. Seven. None of them talk. Their lead energy engineer estimated three hours a day of manual reconciliation — screenshots, exports, copy-paste into a shared tracker. Extrapolate that across a portfolio of twelve sites and you're looking at a full-time-equivalent burning hours on what is, bluntly, data plumbing.
The operators who notice usually try one of two things.
Option one: buy a new dashboard that promises to unify everything. Works for about eight months. Then you add an asset, the vendor's API isn't supported, and you're back to fifteen tabs plus a sixteenth that now also needs integrating.
Option two: build it in-house. Engineering team gets excited. Six months later they've got a Grafana instance that pulls from four of the seven systems and a backlog of connector work longer than the original dashboard problem. Meanwhile nobody's optimising anything. They're all maintaining the pipes.
Neither works because the problem isn't visibility. It's action. Knowing your BESS is at 40% SOC while day-ahead prices spike only matters if you can do something about it automatically, inside the dispatch window, without routing through a human who's in a meeting.
Most of the sector still hasn't internalised that.
The good news is the gap between "we know what we should do" and "we do it" is now measurable. That's new. Five years ago you couldn't reliably price the cost of a missed dispatch. Now you can. An operator running 20MW of behind-the-meter storage in DE who misses two high-imbalance events a week is leaving something in the range of [€X]k on the table each month. Whether that number makes the business case depends on the site. But at least now you can put it in the board pack.
There's a secondary effect worth naming. Every additional dashboard reduces the probability that any one of them actually gets looked at in real time. Ops teams default to the one or two systems that surface the loudest alarms. Everything else becomes forensic, checked only after something has already gone wrong. Which means you paid for monitoring infrastructure whose real function is generating the log entry you reference at the post-incident review.
The vendors know this. Most of them have started building integration surfaces of some kind over the last eighteen months. Open APIs, webhooks, exports to time-series databases. Every pitch deck now has a slide about it. Adoption is another matter. The integration work sits on the buyer side, competes with a dozen other engineering priorities, and slips. Buyers who've tried to run the integration in-house and the ones who've outsourced it to the SI community both report roughly the same outcome: the integration surface promised in the RFP and the integration surface available in production are not the same surface.
Anyway, the sixteen tabs aren't going away on their own.