This week, I spoke to a Web Intelligence customer who claimed to have found the perfect workflow for his ad-hoc users. His perfect workflow meant that almost none of his Web Intelligence users created their own queries but still were able to conduct ad-hoc analysis and ad-hoc reporting. Unfortunately, this evolution away from the historic “ad-hoc query” approach, while obvious to many WebI customers, is still painfully slow for others to embrace. I’ll explain what this customer’s perfect workflow is further below, but first some background.
For years industry analysts have categorized Web Intelligence as an “ad-hoc query” tool. This term unfortunately leads some customers to pigeon-hole the use-cases that WebI supports. Ad-hoc query implies that WebI users must create a query to retrieve specific data when they don’t have a report to respond to their business questions. As a result, BI administrators target certain business users and train them to use WebI to define ad-hoc queries.
Here’s why this categorization is less than helpful. At the very least, query is an incomplete concept in terms of actual requirements. Rarely does someone generate a query then stop. Invariably, the real goal is to make sense of the data retrieved, to answer business questions and then apply that knowledge somewhere else (e.g. sharing through copy/paste to building a dashboard or report). So to categorize a product as an ad-hoc query tool is like saying a fishing boat’s goal is only to locate fish (and not catch it, freeze it, bring it to shore, etc).
But more importantly, the act of defining a query is a significant barrier for most users. In all but the most simple query needs (which likely have reports that already exist) it is just hard to define a query. It requires deep knowledge of the data source – the data behind the measures, dimensions and details – as well as the mechanics of the user experience – how to define filters, subqueries, intersections, etc. And if you understand the data and how to use the query features, it also requires defining the logic for a query – which, sadly, can often be beyond the conceptual grasp of many business users. Even simple business questions can involve relatively complex queries, e.g. “What is store revenue for states with $50M+ in total sales?” Why do we expect the average business user should be capable of overcoming such hurdles?
“Well,” you might ask, “if they don’t define query, where do these non-querying users get their data from?” The answer is: Reports that others – experts from IT and power users from the Lines of Business – create to answer a broad set of questions. These reports are not narrowly defined like an ad-hoc query might be, but enable a broad range of questions to be answered. Lines of Business users who have more narrow questions can then use the reports they receive to conduct ad-hoc analysis and then ad-hoc reporting on top of the documents and analytics they receive.
So, this was the magic use case I referred to in the opening paragraph: BI content is authored by the few capable of identifying broad sets of requirements for Lines of Business and skilled at the science of query creation and the art of laying out reports for easy interactivity. The end-users consuming that content are not encouraged to create net-new queries, but instead to use input controls, formula functions, sorts, the ranking button, turn tables to different charts, etc. to answer their questions. My experience, and I have years of research to back it up, shows that interactivity on top of pre-defined reports is a much more successful way to introduce fact-based decision-making to business users.
I hope analysts finally change the name of the category. I’d love to see an “interactive consumption” tool” category emerge to replace it. I’m open to other terms, but “ad-hoc query” is a term that should just go away.