Superman Makes BI Actionable by Asking, “Who Should I hit?”

When Superman goes into action, does he usually know only that truth, justice and the American way are under attack OR does he know that truth, justice and the American way are under attack AND who the bad guys are?  I think you’ll agree that he generally knows both that there’s a problem and who to go after.  For, you see, Superman is working with actionable business intelligence.  (BTW, I’ll have to check our records but I believe that Dataspace was the developer of his BI system )

 

Actionable has been a hot term for a while now.  Everyone wants their BI to be actionable BUT, how many folks actually step back and try to understand what ‘actionable’ means?

To me, actionable means that BI shouldn’t just deliver information but should deliver information that drives toward a reactive or proactive plan of attack.  For example, which of the following is more useful:

Here is a list of our YTD sales by salesperson

OR

Here is a list of our YTD sales by salesperson compared to their YTD sales quotas?

The first one gives you information.  The second one gives you information you can act on – you know where your problems are and you know who to call.

It’s important to note that actionable data is different at the field level than at the executive level.  Field level managers are focused on addressing immediate issues; answering the question, “Where are my problems today?”  For example:

• In a distribution facility: What shipments are late?
• In a sales organization: Which salespeople are selling below their targets?
• In a hospital: What maintenance must be performed in order for us to remain compliant with relevant laws?

 

On the other hand, rather than solving a problem with today’s details, executives focus more on managing their subordinate managers.  An executive might ask a set of questions like:

• What is the general trend in our sales, or distribution, or maintenance performance?
• How does that trend compare to the goals I’ve set for the period?
• Is the trend headed in the right direction?
• Who’s the manager who’s responsible for that part of our business?

Even though executive-level and field-level managers have different ways of viewing data, if you capture enough detail, the same data can serve both audiences.  Ralph Kimball, father of the star schema, suggested that we capture a lot of detail because we can always summarize up to the executive level.  He also knew that if we store only aggregate data, we’ve lost the detail; we can’t get back down to the field level.

The key to success here is to ask: what does my user do with this report once he has it?  Does he take some action?  If so, are we directing him toward that action or just giving him information with no idea of what to do with it?  (BTW, if he doesn’t take some action, then why are we spending money to give him reports?)

So, to be the Superman of BI requirements, don’t look just at what data you can produce but work with your users to understand their business processes and how the reports you deliver can facilitate them.  Remember, you’re not delivering data, you are fighting to support truth, justice and the _______ (your nationality here) way.

Tying the BI tool to the user

Yes, a 747 and a Cessna can both be used to transport you from point A to point B but, isn’t the 747 a bit of overkill for the pilot who just wants to fly himself to the next airport for a $100 hamburger?  Well, in Business Intelligence (BI), many organizations buy a fleet of 747s when all they need is a few Cessnas – they buy tools that are powerful but overkill for most of their users.  A great example of this is when a company buys 7,000 licenses of an expensive, powerful OLAP tool, intending to outfit their entire staff with OLAP.  Is there a need for advanced online analytical processing (OLAP) in the company?  Almost certainly.  Are there 7,000 users who are going to slice and dice through their data?  Almost certainly not.

You can think about BI needs as a pyramid, small at the top and large at the bottom.  At the very top are a few analysts who use data mining tools to identify unexpected relationships and build predictive models by looking at huge data sets (Can you remember when the data mining companies were looking to put mining on every desktop?  Mining on every desktop?  Really?).

Just below the data miners is another, slightly larger, layer of folks who need to slice and dice through their data – the OLAP users.  These folks are looking for things like what products are selling well, in what regions and by which salespeople.

Next is the bulk of the pyramid – the folks in the field who are just trying to get their jobs done.  The folks who need BI to execute specific business processes: to see which customers receivables are over 30 days old; to see where maintenance crews have been assigned for the week; to do the actual day-to-day work of the company.  Do these folks need to slice and dice through huge quantities of data?  No.  These folks generally need a set of predefined reports which have a few flexible parameters for users to complete to specify exactly what data to report on.

While the major BI tool vendors sell their tools as allowing users to create their own reports and to slice and dice their data, the bulk of the pyramid never uses this capability.  Instead, when these tools are released to users they are released with libraries of pre-configured reports.  Most users never do more than use these reports or, occasionally, request new ones.

Once you understand this reality, you start to look at the concept of BI tool standards quite differently.  More on this in a future post.

Think you’re overbuying in BI?  Drop me a line.

– Ben