Even though multiple authors have elegantly defined what a dashboard is, the industry still has an abstract—almost mystical—conception about them. One thing is certain: they are a means to display information. However, if they are well designed and adequately delivered, they can do much more than that.
It is vital to understand that a dashboard is more than just a couple of charts and tables packed together. It is a tool that helps users navigate freely through the data and shows them things that cannot be seen otherwise. They transform simple data into useful and elegant visualizations that help companies gain a better view of their performance and allow them to make better decisions.
Building a dashboard is not an easy task. It requires a great understanding of the business, a lot of creativity, and a robust set of technical skills. However, most of the time, the developers are so absorbed in the tools, calculations, and data sources that they forget the true nature of dashboards: supporting the business.
We will start our journey by defining some phases that will help you understand the business environment and devise a strategy that will ultimately lead you to creating a stunning dashboard. These are not intended to be strict norms that must be followed by heart. Instead, they should be seen as general recommendations that will guide your efforts in the right direction.
The six steps that will help you to start your dashboard initiative are:
Define your audience.
Spot the business need.
Choose the right KPIs.
Get to know your data sources.
Tell a story.
Enjoy the process.
Dashboards are no longer tools that are designed exclusively for the CEOs who want to review the financial results of their companies. As more organizations realize the potential behind their data, the conception of dashboards as everyday tools to enhance operations, monitor business processes, and support decision making at all levels has substantially increased.
The first step to create a stunning QlikView dashboard does not have to do with charts or tables. Instead, your initial goal is to define who your audience will be. By knowing who is going to work with the applications beforehand, you can choose the best way to present the data according to their specific needs. So jump into your users' shoes and imagine what they would want to see in their dashboards every morning, what kind of questions they are going to ask, and which visual representations would be the best options to answer them.
For example, if you were working on a dashboard for the CEO of an international firm, you would probably have to avoid enormous tables that show even the tiniest detail of the operations. His strategic role usually calls for a broader view of the company, so this level of detail would only make him lose focus. A better approach would be showing the top metrics that define the company's performance and compare them to their objectives or even industry standards. On the other hand, if you were working on a dashboard for your company's help desk, it would be useful to have not only high-level metrics but also detailed information regarding specific issues and their resolutions. As you can see, picking the correct level of granularity early in the project can save you a lot of predicaments and help you choose the correct language for each audience.
Another example of this concept is the unit of measurement that you select to present the data. The same metrics can have different representations depending on the viewers' perspective and preferences. For instance, the CFO may be accustomed to seeing all the information in monetary terms, while the plant manager (in charge of manufacturing the products) is more comfortable talking about the gallons produced, pallets shipped, or watts consumed.
Building analytical applications is both a social and a technical endeavor. So, if you have the chance, take some time to talk to the users about their everyday needs and pains. After all, any QlikView application should be focused and built around them.
Now that you have identified your audience, you must assess what they are looking for. In this regard, most IT departments rely solely on a requirement-gathering document. However, this method tends to be not only boring but also quite ineffective. These documents are usually generic templates that cover every initiative regarding technology, whether it is about programming a Point of Sales system, creating a corporate website, or changing an email password; so, they typically fall short when it comes to understanding the rationale behind a new analytical dashboard.
To ensure success, you must go further and establish a conversation directly with the users. This dialog should focus on the type of dashboard they are looking for, but more importantly, it should clarify what they want to achieve by using it. By listening to them, you will get a better grasp of the current situation, understand their goals, and—hopefully—be able to provide them with a better solution.
Start by asking simple questions about the process or business unit in hand (sales, recruitment, call center, account receivable, and so on) and the difficulties that they face while executing and monitoring it. For example:
What is the primary objective of the process?
Who is involved? Are there third parties?
Is there any specific problem you are facing nowadays?
How do you evaluate its performance?
Do you have a defined goal/budget/quota?
After that, ask them about the application they dream of. For instance:
What KPIs do you want to see?
Which filters do you need?
Do you have any preferences regarding the visual representations?
How often do you need to update the data?
Do you have all the data sources needed to calculate those KPIs?
During this phase, it is also convenient to define the intent of the application. Whether it is to analyze data and foster discovery, present high-level KPIs, or just report operative metrics, each application should be designed differently depending on how it is going to be used. The number of tabs, the distribution of the filters, and the type of objects used to display the data are just a few examples of the elements that might change depending on the tone of the dashboard.
If you establish a true conversation with the users, these sessions could change a phrase such as "we need a sales application" to something much more descriptive, such as "our biggest concern is to achieve this year's quota, so we must keep a close eye on the salespersons' monthly performance". In the end, a deeper understanding of the business needs will always translate into better dashboards and happier users. As you can imagine, the motivations behind a dashboard are quite diverse, but once you understand the true business need, you can act accordingly.
When I talk about this subject, I always remember a conversation I had years ago with the vice president of a financial firm here in Mexico. After reading an extensive requirement-gathering document that left me with more questions than answers, I went to his office to try to clarify the motivation behind the QlikView initiative. As the conversation went on, we reached a point when he defined exactly the application he needed in just a few words. He told me "Julian, I want a dashboard that lets me know who I have to yell at every morning. I will not be the one fixing the issues, so do not give much detail. I just need to know where the problem is and who is responsible for solving it". To be honest, the expectations he had of the dashboard had nothing to do with what the document depicted. Unfortunately, most of the time, you will find yourself in situations like this one, so I strongly recommend you to involve the business users as soon as you can.
The term Key Performance Indicator (KPI) refers to the most relevant metrics that reflect the functioning of a company. They are calculated differently depending on the nature and goals of each organization. Whether you are working with classic indicators like the net profit, market share, and churn rate or new trends such as the number of followers and check-ins, there is no doubt that KPIs are at the heart of any meaningful dashboard.
Most of the time, the metrics you intend to show in your applications are already being captured and monitored. If this is the case, it is advisable to meet with the business unit that is doing it and ask them about the data sources, the frequency of reporting, the most common issues they face, and any other relevant information about the process.
A recurrent problem in big companies is that each department calculates the KPIs in different ways according to the data sources they have available and their particular interests (not always obtaining reliable figures). This could turn into an issue later, so it is better to address it early on by meeting with the appropriate stakeholders and selecting the correct data sources and calculations.
Choose only the most relevant metrics and avoid using KPIs that no one understands. If you think that there is a new KPI that should be included or an old one that should be taken out of the picture, communicate it to the stakeholders. Some companies often keep indicators more as a tradition than as something that adds real value to their analysis. On such occasions, an external point of view can help them fine-tune their ideas and envision a better dashboard.
There is a moment in a company's life when analyzing every chunk of data is important. However, having dozens of KPIs just because you have enough data to calculate them is not worth it. Just try to imagine the head of the HR department opening a dashboard in the morning and yelling, "Oh my God, the percentage of left-handed employees in our legal department is alarmingly high. We must take action!". This example may sound a bit extreme, but you get the idea.
In this regard, you must work side by side with the users to select only the metrics that really matter. There's nothing wrong with having a dashboard with only two or three KPIs as long as they are useful and have an impact on the business.
By this point, you should know exactly who your audience is and what they are looking for. Now, it is time to turn into the technical terrain and meet the raw materials you will be working with: the data sources.
Although data modeling is not the focus of this book, we cannot deny the fact that information and its adequate transformation are the foundations of any QlikView dashboard. Therefore, it is important to ensure that you have the appropriate resources available to fulfill the business needs described previously. In this regard, be sure to assess the following elements:
Type of data source: Will you be working with transactional databases, enterprise data warehouses, Microsoft Excel files or application logs?
Connection: Is the information in your premises or do you need to establish a connection to cloud services or other sources?
Ownership: Is it an internal data source, or is it in charge of a third party? Is it governed by the IT department or another business unit?
Reliability: Can you trust that the data is correct and complete? Is it likely to have quality issues?
Volume: Are you dealing with a small data set or are you going to work with several millions of records?
Update frequency : How often do you need to refresh the data? Do you really need a real-time application? Can your infrastructure handle it?
Having a basic understanding of these topics gives you a better perspective of the technical environment and may help you during the implementation of the dashboards.
Additionally, this phase is the perfect moment to bring out your inner data scientist and get your hands dirty. Don't settle for the charts and tables you have been asked for; give yourself the chance to explore the data. You might be surprised by the insights you can get from just playing with the numbers for a few minutes. Some interesting elements you can look at are:
Associations: Load the data into QlikView and take advantage of the associative model by analyzing the relationships between the fields (green, white, and gray have never been so useful).
Cardinality: Familiarize yourself with how many products, employees, and suppliers the company has. It can give you a better perspective so that you can choose the right charts for each scenario.
Rankings: Is there an element that is consistently at the top of the lists? Who is the best salesperson? What is the best-selling product?
Distributions: Discover the shape of the distributions of some metrics. Do all our stores have the same margin? Do we have certain territories where the employee turnover is higher?
Trends and fluctuations: Time to create a calendar and check if we deal with a seasonal market or a random one. Are our stocks going up or down? What is their rate of change? Are they slow and steady or fast and volatile?
Correlation: Is there a correlation between the customer's age and the average ticket? Or maybe between the types of materials we are using and the production scrap?
The more you know about the data, the better understanding of the company you will have. In consequence, your analyses will be significantly more robust and derive valuable discoveries for your firm.
Building a dashboard is all about telling a story. The only problem is, most of the time, you do not know how that story will develop. It may become an epic fable of success, great sales, and operational efficiency, or it could turn into a haunting tragedy that depicts customer churn, high employee turnover, and quality issues. In either case, your dashboard should be able to handle it and communicate those insights to the users.
The best recipe is to keep it simple, focus on the key performance indicators, and start building around them. The idea is to create a robust and flexible structure that lets users navigate freely thought the data. As a result, our charts and tables will do all the work, and the story will smoothly unfold before their eyes.
In order to achieve this easy navigation schema, you just have to picture what the user will want to see next. For example, imagine that we are creating a sales dashboard for a worldwide retailer. We decide to start our story with a relevant indicator: the sales figure for this month. As we will discuss in the next chapter, numbers such as this have little value unless we put them in context, so we could opt to make a comparison against the budget or the performance for the same period of the last year, ending up with something similar to the following image:
Now, it is time to take out our Nostradamus cloak and try to foretell what the next question will be. After seeing an increase or a decline in the sales, a user could enquire whether she is dealing with a local phenomenon or whether it affects all the countries equally. In response, we could create a table with the regional performance, such as in the following image:
Once you realize that Sweden has had a rough year, you can turn the analysis towards each store or even take it to the product level; so our dashboard must be able to handle all these scenarios. As you can see, once you identify your audience and understand what objectives they pursue, it is easy to emulate their train of thought and build a dashboard that truly responds to their needs.
Last but not least, enjoy the whole experience! For me, building dashboards is one of the most rewarding activities about being a consultant. It gives you the opportunity to interact with people from multiple functional areas and get involved with intricate business processes. Without a doubt, it is a great opportunity to learn in both the technical and the functional ends.
If somewhere along the way you feel discouraged, just remember that you might not be curing cancer or ending world hunger, but you are certainly supplying your colleagues with better weapons to fight their everyday battles. Building dashboards is a way for you to boost their abilities, help them work smarter, and hopefully, make their lives easier.
Moreover, if QlikView is a new tool for your corporation, you might be fostering a paradigm shift by moving their current decision-making process away from random hunches, preconceived bias, and #YOLO to a more formal, governed, and powerful information-based process.