Part 1: 5 Key Questions When Creating a Dashboard/BI Platform for your Organization
The Guide to Building a Dashboard for your Organization
The following article (5 Key Questions When Creating a Dashboard/BI Platform for your Organization) is part of our Free Guide to BI.
There are 5 areas companies should focus on if they are in the process of creating a dashboard/BI platform for internal use of for external client use:
What Does the User Need?
Very often, business intelligence (BI) projects are focused on showing the current state of the company or department: how many unique visitors the site had yesterday or what the cost of user acquisition was over the past week. But data in nice graphs doesn’t necessarily answer the key needs a user may have. When creating a dashboard/BI platform, it is important to clearly identify (1.) which business units and people can benefit and (2.) what specific decision points need to be improved for each. It is critical to ask prospective end-users the questions they grapple with and the answers they depend on to succeed.
Why? Because if users do not get clear answers to their questions, ones that can help them better fulfill their goals within the company, they are going to become very quickly disinterested. These answers guide the data that needs to be collected, and how that data needs to be combined and presented to be useful for the user. A running tally of the number of employees by department might not be that interesting for human resources (HR), but the number of candidates or the cost of hiring a new employee by marketing channel might very well be.
Answering users’ pain points will drive addictive value. As will ease of use, reliability, daily updates (hourly in those circumstances when there is a business need), and clear actionable advice (the Holy Grail of BI) And, the more users depend regularly on data from the BI platform to improve performance, the more likely the platform will be successful.
What Data Needs to be Collected?
Generally, the value that comes from successful business intelligence projects is based on answering specific user questions that can’t just be addressed by a single data source. It requires combining data from disparate datasets to produce the right insights for users. Yet, most established businesses rely on a combination of homegrown and third-party systems/tools to run day-to-day operations, from finance and HR to editorial and marketing. And, knowing where an organization’s data is held does not necessarily mean it’s available.
While tools (e.g. Zapier) exist to allow easy exporting of your data, many legacy systems require development time to make the data available in a usable format. The process of extracting and cleaning that data can be painstakingly lengthy, especially in complex legacy systems that were never designed to interact with other applications. But, clean data is critical if you want to get coherent results in reporting.
Dashboards are only as good as the data that is put into them. Because of this, and the cost and time associated with extracting and cleaning data (particularly cleaning data processes that are prone to break), it is better to narrowcast initial BI projects to a small number of users that have similar needs (say from the same business function). You could have a number of great looking dashboards that were built for many different types of users and business units, but are actively used by no one because the data is hard to support and unreliable.
Should we Buy vs Build?
Nearly every SAAS (software as a service) tool used by a company today offers a dashboard (e.g. Salesforce, Google Analytics, Facebook Business). Many just focus on their own datasets, but some (e.g. Salesforce) allow you to connect external data to create more complex reporting. There is also a long list of powerful dashboard specific tools (e.g. Domo, Tableau) that specialize in connecting with a large set of internal and external datasets.
These “buy” options (because you are buying a prebuilt tool/system) provide everything you need to create a great reporting platform for your organization. Except maybe if you have very complex requirements (e.g. like those linked to ERP systems) or you must have full customization of your BI platform (especially in terms of design). For example, if you want the dashboard(s) to completely match your site’s design or you need new, non-standard charts. In such cases you may have to look at building your reporting platform with the help of systems integrators (e.g. Microsoft, IBM) or your developers.
Deciding amongst all these solutions can be tricky and will depend largely on the scope of the project, whether it is for an internal or external audience, your organization’s budget, technical resources and ability, data (its state and size), and the deadline for completing the initial version. The chosen solution, whether it is built internally, purchased from a third party, or a combination of both, must answer the following questions:
- Can it easily integrate with key third-party data that may become important long after the tool/system has been set up?
- Is the underlying data used to populate the graphs hosted by the tool/system or elsewhere (e.g. on-premise hosting)?
- After the tool/system is up and running, how easy is it to build a visualization? Does it require a developer or can a business person create a new graph to add to the existing dashboard(s)?
- Will it support UX demands in terms of visualizations and functionality (like triggers)?
- Is it cost prohibitive to scale up and have key personnel across all business units accessing the interactive reports/dashboards?
- For a complete list of requirements check out Selecting a BI Solution.
Generally, most small, medium enterprises will go with dashboard specific tools for their internal reporting because it is less costly, and full design control is less important than being able to create on-the-fly visualizations. But, they will go with custom solutions for their client facing reporting because the look and feel is critical, even though updates become more laborious.
How to Design my Dashboard to Improve Usage?
In order to strive towards to daily usage, the end-user needs to be able to:
- Easily see how the charts answer their specific needs and most pressing questions. Sometimes it is worth repeating those questions in the design to help make that connection.
- Clearly understand the data that is being provided to them. That means having comprehensive descriptions of what is being shown on the dashboard, But, also that means being extremely clear as to when the last update was, when the next update will be, and whether any data cleaning processes have failed making the current data unreliable.
- Set reminders (delivered by in-system alert, SMS and/or email) when a metric has changed beyond a certain set threshold.
- Use and decipher the data and charts on their mobile phone. Most dashboard tools have a poor mobile experience that require you to design around those limitations.
- Request or build new charts and new analysis. The BI platform needs to answer today’s user questions and not just the ones from 6 months ago. Most businesses’ needs are ever changing, and being responsive to those new needs will maintain a BI platform’s relevance and boost long term usage.
How Do I Get Management Buy-In for BI?
That is why, when seeking approval for a reporting/BI project, you should:
- Focus on a business unit /function first. Do not try to do everything at once, especially if there is limited BI experience within the organization.
- Plan for extensive training. Those who could benefit most from the data and knowledge found on the reporting/BI platform are not always adventurous enough to change their ways and actually use what was built. But, you also want business units/functions to have the ability to create their own charts and dashboards to answer pressing questions without having to wait on busy developers.
- Build user accountability into the project. Many users who detailed their needs and for which dashboards were built, never end up using the result of all that effort. Why? It could be lack of training, unmet expectations with regards to the data or the functionality of the platform, or just laziness. Either way, unless you are tracking usage at the user level you may miss issues that arise.
- Include a Proof of Concept (POC). These can be time consuming and costly because of the time and effort required from employees involved. But, they are necessary to identify data and functionality issues as early as possible that could cause unplanned delays later in the project.
- Consider the cost and benefit of having all key staff across the organization using the platform. As the BI platform becomes the source of truth for the organization more and more employees will need it. But, that adoption will be impaired by the cost of adding each new user (e.g. license, training).
- Remember that such projects require continued investment to improve the quality of the underlying data and the visualizations built on top of that data. Business challenges will evolve as will user needs, and the BI platform must keep on answering those pressing questions to remain relevant.