It is becoming ever clearer that dashboards aren’t working out too well, any more than predecessor technologies like EIS (Executive Information Systems) did. The recurring problem with these technologies is that if they’re mind-numbingly simple, people don’t find them very useful; but if they’re not, people are overwhelmed and still don’t find them useful. This column by Sandra Gittlen does a good job of spelling the problem out.
I think there are lots of problems like that in BI, and what we need to do is step back and consider all the different kinds of BI that enterprises value and need. More precisely, let’s consider the major kinds of use of BI, because it seems that each calls for different kinds of technological support. Here’s one possible list:
- Early warning of situations that require action.
- Communication of company results.
- Deep analysis and decision support.
- Operational analytics.
Here’s what I mean by each category.
Early warning of situations that require action. This is the classic image of BI. People get reports or graphs on paper or on screen, see that some numbers are out of whack, and react accordingly. Dashboards can be a prettier version of the same thing, or they can be more focused on alarms and alerts. Nowadays, alarms and alerts can also arrive by IM, email, text message, pager, and so on.
On the one hand, a large fraction of the economic value in the history of BI has been generated in this area. On the other, technology for doing so is continually perceived as inadequate. I continue to think that KPI management, alerting technology, and so on are advancing much more slowly than they should be. Even the buzz around Business Activity Monitoring doesn’t seem to have accelerated things much.
Nor does this change when the warnings are the product of text or data mining. For example, despite a very interesting approach to generating alerts, at this point in its development Verix delivers them in uninspired ways.
Mainly, the supporting technology here is the standard query/reporting stack, including new dashboard/scorecard/alerting tools. It’s also the main place where data mining and text mining should be more integrated into standard BI than they are – i.e., to define and populate metrics and KPIs.
Communication of company results. Back in the 1980s, the conventional wisdom was that half the benefit of reporting tools was for actual analytics, while half was just for communicating among enterprise employees. That’s probably still valid.
BI vendors had the good idea a few years ago to build out their collaboration capabilities, but generally didn’t follow through on it, SAP somewhat excepted. Bad choice, in my opinion. The use of text search to get at BI results is something of a plausibility argument for my views in this area.
Again, the supporting technology here is largely the standard reporting stack. Portal/collaboration tools should be more involved than they are.
Deep analysis and decision support. Routine, scheduling reporting was covered in my first two categories. But this third one is where the bulk of ad hoc query and data mining fall. Generally, it’s where lots of specialized and/or calculation-intensive analytic technology comes into play. It’s also where the drilldown aspect of standard reporting shows up. Also, this is the area that is driving much of the recent transformation and disruption in the data warehouse market, because different kinds of BI need different kinds of data warehousing technology.
Operational analytics. In operational analytics, a small amount of analysis is done real-time or near-real-time, in connection with an operational business process. The most technically demanding examples are probably the customer-facing ones, such as call centers or personalized e-commerce sites. This is where the buzz around “active/enterprise data warehousing” is concentrated. There may also be interesting messaging aspects. And data mining scoring may be a consideration.