Analytics solutions require many different efforts, tools, and components in order to be successful.  Good data capture and validation, sound integration practices, and an appropriate front end user tool that is set up and deployed successfully.  It also takes a valid business need and a user that is willing and able to receive value out of the resulting solution in order for the organization to realize value.

In all analytics efforts, whatever you can do to simplify the user interaction experience will not only create a more satisfied user group, but it will typically reduce the support time spent on complex interfaces.  This month I would like to share an analytics solution tip that can help alleviate confusion, reduce support, and increase buy-in from users.

Problem Scenario

When deploying a user front end for your analytics solution, there is always a dynamic that is very important to the user that concerns what data is in your warehouse.  As users run queries or view reports/dashboards/scorecards, invariably they will run into the situation where the data isn’t right (or at least to them it just doesn’t seem like it could be).  In most cases, they will be correct, but there will also be a reason for it and too often that reason is a pretty simple one that is not easy to identify.   Typically they will spend some quantity of time delving into their concern and perhaps even quantify what data doesn’t seem right.

What happens next centers around the user calling (or paging) their technical support experts and explaining the problem.  Technical resources then begin the analysis process in an attempt to figure out why that specific data on that specific report is not correct.  Please consider, most organizations that build data warehouses are not staffed by only one individual who knows everything that is going on with their solution and is always available to help with any questions/problems.  In fact, the person being called often has to do some digging just to get up to speed with exactly what the user is looking at, what they are challenging, and where to look to begin the root cause analysis.

Too often, after hours of investigating the user’s questions, digging around in the database to look at specific tables or fields, and discussing with other technical resources, the support resource will find out that the data integration jobs that load that data have not run yet, were not successful, or no data was available to be loaded.  Upon following up with the user who reported the initial dilemma, the user is obviously a little upset or bothered that they wasted their time when the data wasn’t even ready to begin with – how many other times had they done that and not even realized it?

Tip For Simplifying

There are a few things I like to incorporate into every data warehouse solution.  One feature I emphasize as critical to every front end interface is the inclusion of a data status bar placed right on the login or initial navigation screen.  The intent is that when anyone initially logs in to your system, they will see a summary area (relatively small in stature) that is very similar to a dashboard that shows when the data was last updated and what data was not loaded or had no records.  During user training and solution rollout, it is critical to highlight to users this part of the screen, get them familiar with what they can find/see there, and help them understand how it can alleviate analysis headaches and time.

The content of this area can differ greatly from one solution to the next.  It depends on the number of sources or data integration jobs, the critical types of data displayed in your solution, the differentiation in data loading frequencies, and common data load challenges.  A key feature is to display a one-line status that shows all data current (on schedule) when there are no identified data discrepancies.  If there is any data that is not up to date or known data issues, then a different message, ideally in a color that signals an alert is displayed with information about the issue and when the issue will be resolved.

The source of the information in the status bar comes from the technical meta data that is captured from your various ETL jobs.  Thus, it requires that you have a tracking mechanism built into your data integration process that captures this information and stores it in a table within a location that is easy for your applications to access.    The data issue identified may have resulted out of job failure, although often more appropriately, the job may not have abended, but may have rejected all records, had no records to process, or just not run at all.

It is worthy to note that when properly designed and structured, this type of solution can also serve a side benefit of providing the basis for paging/alerting technical resources to what may have occurred even though there are no job failures.  Since the information is stored within the data, the ability to have a single paging process for this type of data problem is easily implemented.  If you develop tables to store user role/function contacts, standard messages, and escalation procedures, it is also then flexible enough to provide a standard communication process and response or follow up.

Summary

We are always looking for ways to improve the experience of our users and invariably receive pressures to minimize support and maximize delivery of new functionality and additional data sources.  The main purpose for this recommendation is to improve the user experience.  While it is easier to build in this type of functionality as your solution is being designed, the value of incorporating it after the fact will help improve the user experience while improving the technical support, standardizing response, and minimizing effort.

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 bjohnson@recomdata.com