Questions in Chains

Originally posted on August 2 2011


When I was a young trainee, I was taught a rule: “Always ask the user which are the issues she needs to be fixed by the software, then make a software that fixes them”

This applied to Business Intelligence sounds like “Which are the business questions you are going to answer by this project?” The average reply is “What? I was just going to describe you the printouts we have now”.

 This is just the standard reply of who is not used to making analysis, but has always consumed some numbers, trying to figure out what’s happening.
Those who follow a more analytic line, on the contrary, tend to formulate chains of questions. They commonly check numbers, they spot something unexpected and then they investigate further.
The drill feature, implemented in countless systems, is the standard technological reply to these issues. Unluckily it suffers from a basic flaw: it goes into details while the answer might not be there.

 Some years ago one of the buzzwords in the market was “actionable BI”. Claiming that a tool thanks to some sort of inherent design, create actionable reports, is obviously nonsense. Nonetheless, investigating whether is possible to build a system that give a hint on what can be done at the end of chain of questions, is an important point.

 A good system, to support questions chains, must implement some rather complex features. Drill is just the beginning, also slicing and dicing, clustering and ranking are the bare minimum. 

Another, more subtle, feature is the ability to analyze business entities like they were objects. For example, for the credit manager the raw material which to operate on are the late payments. Each one of them is a single entity; it is related to a contract/order/invoice and to a customer. While the CFO needs aggregated figures, the CM needs to have always at hand all the details starting from the single payment. The CM world is populated with lists of late payments, with reminders, calls with the legal office etc. The CM will see her job in terms of payments collected; she will tick-off collected items, and she’ll see more coming; she will think of how many uncollected payments she’s going to handle, if there are few of high value or many of low value etc.  The total value split by customer class or product type is rather useless to her, but for statistical reasons.
From a technical perspective, this means arranging queries and navigation structures in the proper way. Knowing the proper way, requires deep business knowledge by the designer.

 Given that we have answered all the questions, than, what should we do to make the answers “actionable”? We must have a business model such that, entering the information we gathered, it tell us what to do, and how much. No use to say that this is a challenging achievement because we must already have classified all the possible issues and we must already have a solution for every issue. So much for creativity, fantasy and thinking out of the box. 
From a technical perspective, it is really hard to imagine how such a system could be implemented but for a few, delimited, areas.

 Ok, what’s the point then? Is BI non actionable by definition? Are the chains of questions doomed to remain loose at one end? No, you just need to have a man in the loop. You need someone who knows the business, of course and who knows the systems as well. I met a few, mostly women, who got spectacular results from taking advantage from the right mix of business and system knowledge. These people will need to do simulations, to actualy decide what to do, but this is another story.