Learn about NexusCon!
👋 Welcome to Nexus, a newsletter for people applying analytics and other smart building technology—written by James Dice.
If you’ve been forwarded this email, you can sign up for your subscription here:
This is an experiment, and I’d love your feedback. If you have thoughts, questions, ideas or tips, join the discussion on LinkedIn or hit reply.
+ I had the flu this week, so I haven’t written much worth sharing. If you’re new around here, check out some of my older essays that received some 👏:
+ The latest on LinkedIn:
Agree or disagree?
"Fault Detection and Diagnostics (FDD) is a specialized field with plenty of actors while not many active users, so we're waiting to see when it becomes a normal practice. We have enough new frontiers to break in addition to FDD."
- Anonymous
+ The “State of Energy Management” Survey of Building Owners (Smart Energy Decisions)—I almost spit out my coffee when I heard on the Modern Energy Management podcast that, according to this survey, 55% of building owners are still practicing manual data entry for their utility bills.
And sadly, it does match my experience. I’ve had many clients who employ a full time person to do one thing: simply punch in utility bill data into a spreadsheet. And I’ve had other clients who include this as one of their many—far too many—responsibilities.
And now we begin my rant:
At Nexus we like to speculate about future solutions—the best of what’s to come, like digital twins. We like to talk about the latest and greatest new solutions on the market. But with utility bills, it’s not about what’s to come in the future. It’s not about sexy new hashtag-worthy buzzwords.
This is a solved problem that every building owner can and should implement today. Every building owner should have their utility bill data automatically acquired, stored in a database, checked for errors, analyzed for common faults (such as spikes and leaks), and sent to Energy Star Portfolio Manager within 24 hours of the utility creating the bill. And it can cost less than it does to pay someone to put it into a spreadsheet, with far better results. And that someone is now freed up for more meaningful and fulfilling work: acting on the analytical results.
Okay, rant over. Let’s take it to the positive side: while 55% is a sad number, it’s also a HUGE opportunity to implement a simple, cheap solution at scale. This industry doesn’t have a lot of those opportunities.
+ Define analytics KPIs that align with the building owners’ (Propmodo)—While I find the writing tough to follow, this article highlights what I see as another underutilized best practice: tailoring analytics KPIs to the building owner’s jobs to be done.
It’s not enough to collect building data and simply display it. It’s not enough to show energy-only KPIs. Dashboards and analytics should be designed to move up the owner’s priorities list, all the way to their top priority.
Here’s an example KPI from this article: Tenant Retention. In other words, what is the tenant turnover rate?
(…) that’s fundamentally where the (owner’s) revenue comes from, and that’s where the revenue persists.
How can you boil all the data you collect down to a few metrics that communicate how well the owner's various jobs are being done?
+ Defining KPIs at the system level (HPB Magazine)—At the other end of the spectrum, it’s also not enough to show only whole-building KPIs. KPIs can and should be used at the system level to enable deeper insights and save analysis time.
While performance diagnostics are most effective at the system level, KPIs presently are mostly available for the component- or whole-building-level, leaving a gap in system-level KPIs.
For example:
Washington State recently approved an HVAC-focused KPI called “Total System Performance Ratio” (TSPR) into its energy code, which will take effect in July 2020.4 The TSPR compares a building’s annual heating and cooling loads to the amount of energy required to provide these heating and cooling services. Washington State modified the TSPR metric for their code by assessing carbon emissions rather than energy use. A building that sacrifices services, for example more relaxed heating and cooling setpoints or reduced hours of operation, will show reduced HVAC energy use, but not a better TSPR.
Us analytics nerds will point out that an annual KPI is too much of a lagging indicator. Why can’t this be a real time metric? As in: show me the TSPR right now, in real time.
OK, that’s all for this week—thank for reading Nexus!
👋 Welcome to Nexus, a newsletter for people applying analytics and other smart building technology—written by James Dice.
If you’ve been forwarded this email, you can sign up for your subscription here:
This is an experiment, and I’d love your feedback. If you have thoughts, questions, ideas or tips, join the discussion on LinkedIn or hit reply.
+ I had the flu this week, so I haven’t written much worth sharing. If you’re new around here, check out some of my older essays that received some 👏:
+ The latest on LinkedIn:
Agree or disagree?
"Fault Detection and Diagnostics (FDD) is a specialized field with plenty of actors while not many active users, so we're waiting to see when it becomes a normal practice. We have enough new frontiers to break in addition to FDD."
- Anonymous
+ The “State of Energy Management” Survey of Building Owners (Smart Energy Decisions)—I almost spit out my coffee when I heard on the Modern Energy Management podcast that, according to this survey, 55% of building owners are still practicing manual data entry for their utility bills.
And sadly, it does match my experience. I’ve had many clients who employ a full time person to do one thing: simply punch in utility bill data into a spreadsheet. And I’ve had other clients who include this as one of their many—far too many—responsibilities.
And now we begin my rant:
At Nexus we like to speculate about future solutions—the best of what’s to come, like digital twins. We like to talk about the latest and greatest new solutions on the market. But with utility bills, it’s not about what’s to come in the future. It’s not about sexy new hashtag-worthy buzzwords.
This is a solved problem that every building owner can and should implement today. Every building owner should have their utility bill data automatically acquired, stored in a database, checked for errors, analyzed for common faults (such as spikes and leaks), and sent to Energy Star Portfolio Manager within 24 hours of the utility creating the bill. And it can cost less than it does to pay someone to put it into a spreadsheet, with far better results. And that someone is now freed up for more meaningful and fulfilling work: acting on the analytical results.
Okay, rant over. Let’s take it to the positive side: while 55% is a sad number, it’s also a HUGE opportunity to implement a simple, cheap solution at scale. This industry doesn’t have a lot of those opportunities.
+ Define analytics KPIs that align with the building owners’ (Propmodo)—While I find the writing tough to follow, this article highlights what I see as another underutilized best practice: tailoring analytics KPIs to the building owner’s jobs to be done.
It’s not enough to collect building data and simply display it. It’s not enough to show energy-only KPIs. Dashboards and analytics should be designed to move up the owner’s priorities list, all the way to their top priority.
Here’s an example KPI from this article: Tenant Retention. In other words, what is the tenant turnover rate?
(…) that’s fundamentally where the (owner’s) revenue comes from, and that’s where the revenue persists.
How can you boil all the data you collect down to a few metrics that communicate how well the owner's various jobs are being done?
+ Defining KPIs at the system level (HPB Magazine)—At the other end of the spectrum, it’s also not enough to show only whole-building KPIs. KPIs can and should be used at the system level to enable deeper insights and save analysis time.
While performance diagnostics are most effective at the system level, KPIs presently are mostly available for the component- or whole-building-level, leaving a gap in system-level KPIs.
For example:
Washington State recently approved an HVAC-focused KPI called “Total System Performance Ratio” (TSPR) into its energy code, which will take effect in July 2020.4 The TSPR compares a building’s annual heating and cooling loads to the amount of energy required to provide these heating and cooling services. Washington State modified the TSPR metric for their code by assessing carbon emissions rather than energy use. A building that sacrifices services, for example more relaxed heating and cooling setpoints or reduced hours of operation, will show reduced HVAC energy use, but not a better TSPR.
Us analytics nerds will point out that an annual KPI is too much of a lagging indicator. Why can’t this be a real time metric? As in: show me the TSPR right now, in real time.
OK, that’s all for this week—thank for reading Nexus!
Head over to Nexus Connect and see what’s new in the community. Don’t forget to check out the latest member-only events.
Go to Nexus ConnectJoin Nexus Pro and get full access including invite-only member gatherings, access to the community chatroom Nexus Connect, networking opportunities, and deep dive essays.
Sign Up
Nexus Labs exists to move the smart buildings industry forward, without the fluff.
On Wednesday, we send out the renowned (and free) Nexus Newsletter.