Nonanalytic NonapplicationsMost analytic applications lack the interactivity and procedural structure to be called suchI love my job. As an analyst and consultant, I get to view and test drive lots of different analytic applications, whether produced by a vendor for resale or by an IT professional for an internal audience. But the work has its tense moments. I regularly have to explain to the proud creators of an analytic application that their brainchild has little or no analytic capability and that it doesn't operate the way I believe an application should. Half of my argument is semantic, splitting hairs over the meaning of "analytic." The other half is subjective, concerning my preference for procedural applications. But there's more to my argument than semantics and subjectivity. It reveals two requirements for analytic applications: An analytic application should be interactive and analytic (not just static, like a report), and it should have procedures that guide the user through an analysis, the way other types of applications automate linear business processes. Unless these two requirements are satisfied, a so-called analytic application is merely a nonanalytic nonapplication. REPORTING IS NOT ANALYSISMost of the analytic applications I see are largely devoted to reporting, not analysis. For instance, I recently saw the latest release of a leading product for Web-site traffic analysis. Despite the rubric "analytic application," it consisted of nothing but static reports. I learned a lot about Web-site traffic by reading the reports online, but I wouldn't call the experience analytic. Reporting is not analysis. But the line between them gets fuzzier all the time, so how do you tell them apart? Here's the sweeping generalization that works for me: Reports are static, analyses are interactive. By interactive, I mean that the user can create and change the data set being analyzed, using some form of query in real time. A classic example is when a user selects a few dimensions and drags them into a pivot table. My favorite kind of interactivity is "visual query," where the user clicks a visualization (whether a traditional bar chart or a more modern cluster graph) to select a subset of data for further analysis. Obviously, my sweeping generalization breaks down with parameterized reports, which give the user a bit of control over the content of the reported-on data set. Furthermore, leading edge reporting technologies today produce online reports, which enable users to change chart types, fonts, colors, and so forth. Although users can interact with the presentation attributes of an online report, the data content is still largely static. With the static nature of most reporting in mind, let's turn our attention to the least analytic of analytic applications, namely dashboards and scorecards. Many of these (especially homegrown varieties) are designed for monitoring performance metrics, not analyzing them. The cliche user is a harried executive who pauses for a nanosecond to glance at visual performance meters like speedometers, thermometers, and traffic lights. When all are green, it's time to head for the golf course. But how does the executive determine the cause when the metrics go red?
|
 |
Most Popular This Week
IE Weekly Newsletter
Subscribe to the newsletter
| |
|