jump to navigation

Unimaginative Specification – Red Flag #1 on why BI reports fail January 27, 2006

Posted by Cyril Brookes in BI Requirements Definition, General.

Is your BI Reporting system specification simply a set of KPIs drawn from a standard set of corporate or industry KPIs, metrics or measures?

 Following the dictate of Peter Drucker, mentioned in my January 10 post, and given the highly developed state of our report building tool kit, I am comfortable pontificating: 

“Effective BI systems are more difficult to specify than to build”; and
“Efficient, but ineffective, BI systems, are trivial, unimaginative, applications designed independently of the way user executives actually use their information to find problems and make decisions”.

The critical factor, I believe, is having a good understanding of why our BI system is being created at all.    Surely it is to provide information – but to what purpose?  I fear many BI specialitst want to “get on” with the job of building, and will take any old specification that appears credible so they can do just that!

Often an executive needs information to help solve a problem that he/she is facing now.  I call this “Problem Solving” type information.  It’s important, but we only need it when we’ve actually got a problem to solve.  Most of the time executives are looking for “Comfort” and are “Finding Problems”. 

Therefore, I contend that most BI systems are not designed for “Problem Solving”, for example, all the dashboards, static reports, standard query responses, etc. are intended to supply information on a routine, or ad hoc, basis, but in a pre-formatted style.
 In these cases, information has only two uses:
1.       To provide comfort to the executive that he/she has access to enough data to assess the true status of the business – good or bad
2.       To highlight potential problem areas, i.e., situations that may need a response, including providing alerts to the executive pointing at unusual or potentially dysfunctional objects, events or trends

I am sure that there is no way that a set of standard measures or KPIs, drawn from some tool bag, can offer a useful approach to (2) and they will probably provide a boring and uninviting design for (1). It’s obvious, I believe, that KPIs are not the simple concept that some IT analysts think they are.  They are often, in the executive mind anyway, hierarchical (broad and narrow concepts) and inter-dependent (one KPI may be computed from two or three others).  Further, the executive usually needs to “Get a Real Handle On..” the KPI to help him/her complete a mental understanding of a business process.  This means that the presentation, format, granularity and accuracy of this KPI as supplied will be critical, and may be different for each individual.  My research has shown that there are three important aspects:

    1. The Measure, Metric or KPI itself; e.g. “What is our profitability”

    2. The Granularity of the reporting – i.e.in data modelling speak what dimensions are relevant (two answers here, one for normal reporting and one for drilldown)

    3. The Reporting Extensions:  Is the basic number all thats wanted, or do we want variances against benchmarks, forecasts, dashboard lights, etc.

 This is not to say that a list of KPIs is not useful or important.  Quite the contrary, such a list is an essential starting point for a specification process.  It’s just that such a list should not, also, be the end point of the process.
 Summarizing, if you have these symptoms of Red Flag 1: Unimaginative Specification:

  • The BI reporting is directed at the bald presentation of standard KPI measures 
  • The specification is built around one or more pre-existing reports, and the elicitation process has not extended beyond those reports
  • The Dashboard design is based on the content of a pre-existing financial report set, plus an exception or two
  • The designers asked the executive users “what information do you want” and they came up with this list, based on reports they get now

THEN:  its going to be boring, uninspiring and heavy going for the executive user;  and the Red Flag #1 is waving, and some extra consideration appears warranted.  It appears logical to do this before you build the system! 



No comments yet — be the first.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: