Choosing an energy management information system: a requirements checklist

An energy management information system is bought once and lived with for years, so the selection deserves more than a feature comparison. The definition, and how an EMIS differs from a building automation system, is covered in what is an EMIS. This article is about the next step: writing requirements you can score, so the choice rests on what the software has to do for your portfolio rather than on the demo.

The evidence that these systems pay off is reasonably strong. The US Department of Energy's Smart Energy Analytics Campaign analyzed data from 96 commercial organizations totaling 518 million square feet and nearly 6,000 buildings in its third year, and found median energy savings of 4 percent for energy information systems and 9 percent for fault detection and diagnostic software after two years, with a one- to two-year simple payback. The spread between organizations was wide, and much of the difference came down to how well the data came in and whether anyone acted on it.

So the checklist below leads with data, then analytics, then everything else.

Decide before you shop

Four decisions shape every requirement. Scope: is this whole-building utility analysis, system-level fault detection from BAS points, or both? The first needs bills and interval meters; the second needs trend data from controls and is a different, and usually more expensive, product. Sites: how many, in which provinces and states, with how many providers? Commodities: electricity only, or gas, water, steam and fuel oil too, because a system that treats gas as an afterthought will misreport a Canadian portfolio where heating dominates. Users: who logs in weekly (the energy manager), monthly (finance), annually (sustainability, auditors), and who never logs in but needs a report in their inbox.

Write these down as a one-page scope statement and attach it to the RFP. Every vendor then answers the same question, and the scores are comparable.

Group 1: data acquisition

Everything downstream depends on how the data comes in. Require, and test, each path you actually have.

• Bill ingestion for every provider and commodity in the portfolio, including PDFs and portal downloads, with every field captured (usage, demand, reads, dates, rate class, each charge), not only totals.
• Interval data through Green Button where it exists: utilities in nearly all 50 US states and two Canadian provinces offer it, at 5-minute, hourly, daily or monthly intervals depending on the provider, with file import for the rest.
• Submeter and BAS data through standard protocols or gateways, with a meter hierarchy you can edit yourself.
• Weather, floor area, occupancy and production data as first-class inputs with effective dates.
• An inbound API so your own systems can push data, and documented behavior when a provider changes its bill layout.

Group 2: data quality and validation

Ask what the system does when a number is wrong, because it will be. Across a portfolio, estimated reads, split periods, unit mix-ups and duplicate bills are routine. Require validation on arrival: bills checked against reads, tariff and prior periods; interval data checked for gaps, spikes and duplicates; every exception routed to a named person with the evidence; every correction logged with who and why. Require lineage: any figure on any chart traces to the source document and field. And require that estimated values are visibly flagged in every view, not blended silently into a monthly total. The properties to test are set out in what clean, structured utility data requires.

Group 3: analytics

Analytics are what the demo shows and what most RFPs over-specify. Keep to what your users will act on. Baselines: define a baseline period per site and meter, regress consumption against weather and other drivers, and report avoided energy against it in a way that follows IPMVP Option C conventions. Weather normalization: heating and cooling degree days on a base temperature you choose, from a station you can see. KPIs: energy use intensity, cost per unit, load factor, peak demand and baseload, computed on validated data and comparable across sites; the set facility teams actually use is in the energy KPIs facility teams should track. Anomaly detection: alerts on deviation from expected consumption, after-hours use and baseload creep, with thresholds you control and a record of which alerts were acted on.

Judge dashboards on whether they lead to a decision, which is the test applied in energy dashboards that drive action. A chart nobody changes a setpoint over is decoration.

Group 4: reporting and integrations

The EMIS will not be the only place the data is used, so how it leaves matters as much as how it arrives. For Canadian and US portfolios the first integration is ENERGY STAR Portfolio Manager. EPA offers a suite of RESTful web services that allow you to exchange data with Portfolio Manager, and NRCan's Canadian adaptation has been in place since 2013 with more than 150 Canadian weather stations, so require a scheduled two-way connection rather than a manual upload template. Then require exports and a documented outbound API for BI tools, a feed to the ERP or AP system for costs and accruals, and consumption by fuel, site and period in a form your GHG inventory can consume, with the factor set and method recorded. Scheduled reports distributed to people who never log in complete the group.

Group 5: administration, security and commercial terms

Administration: role-based access by site and function, single sign-on, an audit log of who changed what, and self-service onboarding of a new site without a professional-services ticket. Security: where the data is hosted (data residency matters for some Canadian public bodies), encryption in transit and at rest, and the vendor's independent security attestation, which you should ask to see rather than take from the website. Commercial: the pricing basis (per site, per meter, per data point, per user), what onboarding costs and how long it takes, who does bill entry when the vendor's automation fails on a format, data ownership and export on termination, and the release cadence. Assembling parts of this yourself is a real option for large portfolios; the trade-offs are in build vs buy for utility and energy data management.

A scoring table you can defend

Weight the groups before you see a demo, score each vendor 1 to 5 per group, and multiply. The weights below suit a multi-site owner-occupier; a consultant or a campus will shift them.

Score on your own data. Give each shortlisted vendor a month of real bills from your hardest sites and one known billing error, and score groups 1 and 2 on what comes back, not on the presentation.

Red flags

Some signals should cost a vendor points regardless of the demo. The demo runs on sample data and they decline to load yours. Bill entry turns out to be done by people, with turnaround measured in days, and the contract does not say so. The system stores totals and usage and drops demand, reads and rate class. Estimated reads are not flagged anywhere in the interface. The Portfolio Manager connection is an upload template. Pricing is per user, so the people who should see the data are kept out to save seats. There is no documented outbound API, or it is a paid add-on discovered after signature.

A short RFP question list

1. Which of our providers and bill formats do you already read automatically, and what happens when one changes its layout?
2. Show us how a bill with an estimated read and a wrong rate class appears to a user, from alert to resolution.
3. How does a figure on a dashboard trace back to the source document and field?
4. Describe the Portfolio Manager connection: direction, schedule, and how meter mapping is maintained.
5. What is the outbound API, what does it cost, and what are its limits?
6. Where is our data hosted, who can access it, and how do we export everything if we leave?
7. What is included in onboarding for the sites in our scope statement, in days and dollars?
8. Which parts of the data feed depend on people rather than software, and what is the turnaround?

Whichever system you choose, it will only be as good as its feed. MartinAI sits in front of the EMIS: it reads every bill, meter file and portal export across electricity, gas, water and steam, validates and normalizes the data, and delivers it to the EMIS, Portfolio Manager, BI, ERP and emissions tools through one connection. That makes the scoring table simpler, because groups 1 and 2 stop depending on the EMIS vendor. The broader discipline is described in energy data management explained.