Like many analytics solutions, dashboards and scorecards are thought of in many varying ways from organization to organization or individual to individual. Just the terms alone often have varying definitions. One interesting way for developers and analysts to look at dashboards and scorecards is based on their level of interactive functionality. Should dashboards and scorecards be interactive in all cases? Many feel that dashboards and scorecards are always interactive, while many others feel that they should never be interactive.
Is there a right or wrong answer to that concept? There may be, but it would be appropriately based on the specific need of the business area and solution purpose that is being served. Let’s look at how to successfully incorporate the right level of interactive capability into your solution.
Basis Of Interactive Features
The usage basis of dashboards and scorecards is rooted in providing high level information that is quickly and easily visible on the performance of specific areas of business. Generally, said usage is for the purpose of keeping varying levels of management aware of the state of effectiveness of key areas of metrics that are deemed important for overall success of the business or at the least, the success of the specific area/function being monitored.
The concept of having an interactive solution refers to the user being able to leverage the solution for:
- Performing drill-down and drill-through functionality – this enables a deeper dive into the numbers behind the main charts/graphs/trends. Looking at lower levels of detail in order to understand the basis for metrics that are concerning or intriguing.
- Attaching of business and technical meta data that provides context that will assist in gaining a better understanding of the various metrics, sources of information, and rolled up content.
- Enabling teams of resources to leverage the same solution to differing degrees, typically in a complimentary manner. As certain leaders question numbers, they can contact expert analysts that have access to the same system, but have drilling access and are seasoned in investigating further and getting results back to the requestor.
There are some inherent complexities associated with providing these varying levels of functionality on any analytics solution. One concept to consider is that the dashboard or scorecard is meant to monitor or identify progress. In many cases, once you identify something that needs investigation, you then look somewhere else for the detail. For example, if the needle on your car’s oil gauge is not where it should be, one of the first things you must do is to open the hood and check the dipstick. While this may identify the issue, it is not all you need to diagnose the criticality of the problem. The main reason for this is that there could be several problems that could cause the results you are seeing and thus drilling in may be much more complex than simply going from a corporate view of numbers to breaking it down regionally. You may have to break it down by product/service, types of customers, cost/pricing, or any number of other variables.
Recognizing Your Business Users
Whether or not you have interactive capabilities built into your applications really depends upon the accurate recognition of the users you are serving and what they need to monitor. Personally, I am not a fan of talking about this from a requirements definition perspective, as too often, resources “gathering” requirements are taking orders for what to do without understanding the nature of the users. In this particular case, let’s try to explain by taking you through the identification of level interactiveness.
A user request for having interactive functionality in applications is more often a characteristic of how the question is asked or who it is asked of. If you are defining a solution for management or leadership, you must be working directly with them and you must understand how to listen to their needs, but also how to feed back to them the challenges presented with what they are asking for. Perhaps this is best represented by a comparison to the common requests by users for “real-time” data/solutions. While it is common for users to say they must have real-time, seldom is real-time truly the answer. It is very expensive, causes too much analysis of things that don’t change that often, and frankly may not be worth monitoring that frequently. When you are able to feed back to the requestor the challenges with their request, associated costs, additional timeframes required, and other pertinent factors, oftentimes the requirement changes quickly.
If you are focusing on executive leadership, you generally can define that you want very little interactiveness directly for those users. Executives rarely have time to delve into details and certainly should not be spending significant portions of their time trying to learn tools to do this type of analysis. It is most often far more advantageous to have them hire an analyst that they can call when they see a number that is intriguing or concerning. Now, that analyst will need access to what the executive sees and will need some solution that they can then use to drill into and through the detailed data in order to provide enough context back to leadership to enable them to make the necessary adjustments or recommendations.
In dealing with all other levels of management, it varies to the degree of their level of analytical need and comfort. Typically, financial leaders and managers are very analytical in nature and generally want to dig into the number. In the healthcare field we have found that physicians are very analytical in nature (consider what they do on a daily basis). Thus, any solutions for these types of users should have some level of interactive ability.
Lastly, consider what it is you are tracking. The data itself can be one of the most significant factors in defining the level of interactiveness required.
- Simplistic data that is well defined, frequently used, and fully appreciated actually requires very little interaction. Thus, these solutions are easier to build, maintain, and support.
- Metrics that are in the early stage of being adopted by the business typically require more interaction. The process of working out metrics both from a gathering and validation perspective, but even more importantly from a business adoption perspective. How the information is shared will evolve and grow as more is learned.
- Many levels of rollups also tend to require more levels of interaction. The greater the variety of summarization and factors incorporated into it, the more likely that users will need to progress down that chain of information.
When trying to define the level of interaction required by your analytic solutions don’t look for one person to give you the answer. Try to get inside of the true needs of the business. Start with understanding the background of the people who will be using the information, the type of information that will be tracked, the maturity of the information, and the levels of rollup required. Take special precautions to consider the needs and business nature of executive leadership. Even though it seems rather easy for a user to leverage the strong and easy to use tools of today, consider the user’s available time when advising when it might be better to hire and leverage analysts to drive into details and come back with findings.
About the Author
Bruce has over 20 years of IT experience focused on data / application architecture, and IT management, mostly relating to Data Warehousing. His work spans the industries of healthcare, finance, travel, transportation, retailing, and other areas working formally as an IT architect, manager/director, and consultant. Bruce has successfully engaged business leadership in understanding the value of enterprise data management and establishing the backing and funding to build enterprise data architecture programs for large companies. He has taught classes to business and IT resources ranging from data modeling and ETL architecture to specific BI/ETL tools and subjects like “getting business value from BI tools”. He enjoys speaking at conferences and seminars on data delivery and data architectures. Bruce D. Johnson is the Managing director of Data Architecture, Strategy, and Governance for Recombinant Data (a healthcare solutions provider) and can be reached at email@example.com