Overcoming reliance on GIS

Hello and welcome to Bite Size Electric, the podcast where we break down the biggest challenges and best practices shaping the future of electric networks, one bite at a time. I'm your host, Brandon Kirkin, and we are working through a five-part series on digital as-builds. My guest for this series is Matt Roberts, Director of Utility Solutions for IQGeo. In this series, we'll explore the challenges that utilities face during as-built workflows, the impact of these challenges posed to utilities, and what these utilities can do to improve their as-built workflows. Today, we're on part two of a five-part series on digital as-builds. In this part of the series, we'll talk about challenges preventing the field teams from capturing as-builds without accurate asset location content, and how this lack of geospatial data prevents them from executing their work effectively. I'm joined again by Matt Roberts, Director of Utility Solutions for IQGeo. Welcome, Matt. Glad to be back. So, Matt, let's start with how field users use the GIS during the as-built process. Are there common issues or limitations that result from depending on the GIS that you've experienced? Certainly. So, if you think about the GIS data and how GIS data has been entered for decades at this point is typically the assets in the GIS are drawn in the incorrect place. And for good reason at the time of entry of you're plotting the real world onto a two-dimensional, you know, a map, a construction print. So, therefore, you've got to do offsets. But as we've seen going forward with the as-building process is if you're continuing to build off of those incorrect, call it takeoff points, the data that you are putting back into your GIS is still in the incorrect spot. Because, you know, you're taking off from that offset pull, you're taking off from that offset transformer. And we're seeing more and more applications and more and more user feedback being that we want things drawn in the correct spot. And especially for the as-built piece, we want to be informed of the correct spot that that asset was actually installed on or constructed in. So, would you say that the main issue then for depending on the GIS for as-builds are the delays resulting from these inaccurate asset locations? Or are there other factors originating from the use of the GIS that slow down the as-built process? So, often what's slowing down the as-built process, and that's a good question, is not always the inaccuracy in locations, but the way in which the as-built data is being received by the GIS. Yes. So, if you walk into a utility, you see all sorts of different ways GIS data and as-builds are getting posted. But I'd still say even in 2025, the most common way as-built data is getting posted back into the GIS is a physical piece of paper construction print with lines, all sorts of pen colors, depending on the utility standards, that ultimately sits on a GIS tech or poster's desk and manually gets redrawn inside the GIS. Yeah, that makes sense. And that ties back to our first episode where we talked a bit about the challenges with paper processes for the as-built. So, that really does tie that together. Given that the process of as-building by nature happens in the field, are there any challenges specific to field usability that you're hearing from utilities? So, the biggest challenge we hear from utilities on field usability is really a lack thereof field usability in the sense of most of these utilities are being given their construction crews a piece of paper, which creates that problem I alluded to, where the tools that they are being given are so generic and not purpose-built for utility as-builds that they just lack the user confidence, user support, and ultimately acceptance. And oftentimes, they just go wayside. Great. Well, thank you very much for the insights as always, Matt. We'll continue this conversation in the third part of our series where we talk about app fatigue resulting from multiple applications that field teams need to rely on during the as-build process.