GeoBI Implementation

This is the second in our series examining the concepts and benefits of Geographic Business Intelligence (GeoBI). In our previous post, we introduced the topic of integrating business intelligence and GIS in a self-service operating model.  In this post we identify some GeoBI implementation approaches we’ve observed, what doesn’t work, and considerations for a successful implementation.

We work with a wide variety of clients, and some of them are savvier than others when it comes to using spatial data across their organization. Many who have a BI program have noticed that analysts are looking for ways to analyze and visualize their BI in a map context. And if spatial information wasn’t considered when they first implemented BI, they’ve tried to patch it in using an ad-hoc approach, but the results were not what they expected.

The ad-hoc approach is the wrong approach

An ad-hoc approach to integrating location data with BI ended up giving one client the following analysis workflow:

• The business analyst starts by examining data in the data warehouse.
• Since the analyst is comfortable using Excel, they export raw data from the data warehouse to a spreadsheet for further analysis.
• Once they’ve massaged the data so that it meets their needs, they ask the GIS department to develop this into a map-based report they can share with their team or management.
• The GIS analyst can’t use the data as provided, so they need to manually process the data they received from the business analyst.
• Next, they determine what spatial data they need, and merge it with the spreadsheet data.
• A map is generated, and provided to the analyst for review.
• Of course, the map they created didn’t meet the business needs, so there are revisions to be made.
• Another map is generated, which finally communicates the information needed for the business unit’s report.

Whew! This is slow and inefficient. And consider the impact this back-and-forth creates when the GIS department is already overwhelmed with other projects and requests – there would be no way to create this report in a timely manner.

And this approach doesn’t enable self-service BI – the analyst needs another department to render their results for them, then they need to review the map. Again – more back and forth. Data discovery is not easily done in this scenario.

There’s duplication of data, since the business analyst modified data from the data warehouse, and the GIS analyst modified this data yet again. This is inefficient and, highlights that the data warehouse – or source of truth – isn’t being used as expected. This could lead to results and reports that are not repeatable, and lots of extra time taken to manage or describe these intermediate data products.

You need the right data and tools

We’ve also seen organizations who provide their analysts with BI tools that have some spatial capabilities. This allows the analysts to perform some BI in a map context. But often, the tools have limited or specific capabilities and don’t allow them to visualize the information in the way they want to.

A key issue we’ve seen many examples of our business units not having access to up-to-date mapping data, so they’re no longer working with source-of-truth, and their analysis is not what they expect. Again, they need assistance from the GIS department to complete their analysis and reporting. The GIS analyst then needs to recreate the analysis using the correct, current spatial data and generate a new visual report to meet the requirements of the analyst.

This is slow, prevents the organization from achieving self-service BI and limits their ability to have GeoBI be pervasive through your organization.

It’s important to have the right tools available to analysts. And to determine what tools are appropriate, you’ll need to assess what capabilities your analysts will require, and what tools will work with your data and BI platform.

You don’t necessarily need to buy new technology – you may have tools that can work for your specific needs.

As well, data modeling and data management are important. Your spatial data has to be structured and stored in such a way that it will work with your BI and that analysts know what to do with it.

Why ad-hoc, standard approach does not work

So without a thoughtful approach to GeoBI, it is difficult to successfully leverage your spatial data and technology with your BI platform.

As we’ve shown, an ad-hoc or limited approach to GeoBI will lead to inefficiencies in analysis and reporting.

One of the expectations of a BI program is fast, repeatable results. But if it’s not fast or repeatable then that’s a problem and you need to address it.

Next, when analysts don’t have the information they need or the tools to do their job, then they don’t have the ability to perform self-service BI or to use effective, interactive, map-based dashboards.

Also, relying on the GIS department is slow, and takes them away from other, more productive work. And there’s a cost to using additional resources that need to be accounted for

So an ad-hoc or limited approach will not work, and you need a GeoBI strategy that’s going to be successful