Any organization worth its salt is well aware that data drives decision making, and teams know business intelligence tools can help to facilitate their decision-making processes. There are certainly many benefits to BI tools when used properly – increased organizational efficiency, faster analysis and intuitive dashboards, trusted and governed data, and increased competitive advantage to name a few.
The problem that has arisen in this age of self-service BI tooling is that now everyone has access to creating their own reports and dashboards. In theory, this sounds great. But in reality, organizations are now combating the chaos of no source of truth, many different views of the same data, and therefore no consistency in decision-making through these tools — the very purpose of them in the first place.
How can companies work through this challenge? What’s the first step? From our experience in this space, we’ve compiled some of the more common misconceptions surrounding BI tool use, and how they can be rectified.
One of the initial challenges companies face is a lack of a clear business objective behind the data they are showing. They don’t have a data value chain and, without it, they don’t have a clear idea of what the story they’re trying to tell with their data.
For example, a common goal of any business leader is to increase profits. This seems clear-cut enough, but when they’re looking at a dashboard, they need to be aware of what specific change they are trying to make, or what they must do in order to meet that objective. Do they need to cut wages? Do they need to lower costs? Often this underlying objective is skipped over, which leads to bigger issues.
In this part of the process, it’s important to ask, “What do you want your dashboard to do?” It’s about understanding what business leaders want to unlock and what the effect is they’re trying to have on their organization. To do this, it’s important to take the time to outline the questions your team is trying to answer with your dashboard or report. Specifically, do research around important questions like What is the goal that you are trying to achieve? Based on that answer, what actions are you taking toward that goal? What do you want to see happen in the future? Translating the answers to those questions into a dashboard or some other BI tool essentially says, “This is the best way we can communicate that.”
You get a dashboard, you get a dashboard, you get a dashboard!
Unfortunately, a lot of organizations take this approach and it can lead to considerable problems. Even when two teams work differently with the same data, it results in two different numbers, two different contexts, and a lot of time being exhausted determining who is right and who is wrong. (Trust us, we’ve seen this A LOT in our line of work.) If your story is incorrect, or your story is different from someone else’s, trust and your ability to collaborate is severely diminished.
It comes as no surprise then, that it’s very easy for teams to add their own bias to the data in this space. Our biases significantly influence how data is both interpreted and communicated and, as a result, a considerable amount of change management can be necessary. This situation can be particularly alarming, because when a client asks for a view with a particular bias removed, it can be a rude awakening to the actual status of things. To circumvent this issue, teams should spell out metrics and measurements from the get-go. Being transparent and up front with calculations in this way is critical for showing individuals where they went wrong with the data, and how they can fix it.
An enterprise retail partner found that many executive-level decisions were being made without the necessary supporting data to inform such decisions. The data itself was suspect, and reporting systems were inadequate. As a result, teams’ decision-making abilities were handicapped by inefficient processes and distrust in their own data.
Part of that distrust came from the fact that all of that data was housed in separate places, pulled from different systems, and owned by different teams. As a result, getting answers to questions often took days — and sometimes weeks. We worked with multiple teams to reassess, strategize, and integrate their disparate data systems, their different sources of truth, back into a single source — speeding up processes from hours or days to a matter of minutes.
Data isn’t inherently valuable, and this fact is only further compounded when many different teams or individuals spin off their own particular view of the data. When this behavior runs rampant, everyone crams more info in than necessary, and it doesn’t provide value as a result. Team X doesn't need to take Team Y’s sales data and add their own view. This creates too much data and puts too many unnecessary eyes on it – it’s essentially death by 1,000 filters. The issues created in this way will always significantly outweigh the benefits from each individual view.
To be fair, this problem usually arises out of good intentions. Someone recognizes a gap in their organization, so they make a tool that addresses that gap. But as that gap begins to fill in and teams get more visibility into that gap, others start branching off until you go from one view for one gap to 10 views for a variety of overlapping gaps. It’s essential that companies get a hold of those 10 disparate views that started as one thing, and ensure they get back to that single view.
There are wrong ways of presenting data from a visual standpoint. Many enterprise businesses tend to overlook this, don’t know about it, or completely disregard it. The fact is, there are clear best practices that determine what’s right and what’s wrong when it comes to data visualization – it’s not about personal preference.
So how do you determine the right way vs. wrong way? In many cases, there are defined industry rules. For example, data visualization best practices dictate that bar graphs should be used to denote volume whereas line graphs are well-suited to show change over time. For each visual display option you select, you should always ask, "Is this simply an option, or is this the most efficient, effective, and optimal option for the data story I want to tell?”
There is no getting around the fact that there are different groups across enterprises who need the same data source, but they need it for very different reasons. So the data needs to be presented in a way that supports the specific needs of all the relevant groups within a given enterprise, but it’s also necessary to show the data in a way that allows for open communication and breaks down silos across teams.
User-centric, persona-based BI tools are the ideal way to address this. In this way, true data democratization doesn’t come from giving everyone access to create their own dashboard, it comes from creating a single dashboard that gives all individuals the data they need to do their job, but in a consistent way.
Whether you assign an internal team or look for an outside team to help you create your strategy and governance, it’s important that you have some sort of gatekeeping around how your BI tools should be used. We know gatekeeping can be a dirty word in this space, but without some sort of structure to how it’s used, your BI tooling will quickly go from a helpful tool to mass chaos.
Enterprise business leaders need to dispense with the notion that BI tools will solve all of their problems or provide them with the answers they need all alone. Without a clear, researched business objective, organizations will find they have plenty of data, but little insight into it. In most cases, what enterprise businesses need isn’t another dashboard or another BI tool. What they really need is a source of truth. They need consolidation of the right data and everyone working off of the same view. The tool is not the fix; the strategy is the fix.
Need help getting your own single source of truth with your data? Our teams have partnered with some of the world’s largest organizations to help them integrate disparate systems and get better insights, faster. Learn More.