Sunday, 17 January 2010

What makes a BI reporting tool great?

I've seen numerous forum posts on places like LinkedIn where people have been asking questions like "what is the best BI reporting tool on the market?"

Quick answer: it doesn't really matter!

The technically-minded (and vendors) may now be spitting out their coffee and looking at the screen in disgust towards my lack of regard for 64 bit processing, deployment flexibility and single architecture. Don't get me wrong, these features are good features, however, in my mind, what makes a BI reporting tool a great business tool is:

1. the process that surrounds the tool, and
2. the people involved in making this process successful

I've come across organisations where they have fantastic BI technology, with all the add-on components money can buy, but it sits there largely unused by the business community because:

1. they don't know how to use it
2. it doesn't do what they want it to do, or
3. they don't trust the data

In order to ensure that your BI implementation does not go down the same well travelled path, here are some critical success factors to think about:

1. Listen to the business

I cannot stress enough how important it is to listen to the business, and how often it is overlooked in favour of simply migrating current data environments to map straight to the new BI reporting tool. You know what? Yep, you guessed it. New technology, same old problems.

The business hold the key to a successful business intelligence implementation. The business are the customer, and they know what they want to achieve from the implementation.

Back in the early 2000s while I was working as a credit risk analyst for a mobile telecommunications billing company, the company had invested a massive £5 million into building a new data warehouse and reporting environment. Upon go-live it was clear that the project had failed. One of the 3 major reasons for failure was that the business felt that the implementation didn't deliver what they wanted, due to the business not being consulted in enough detail. The project team simply misunderstood the business requirements. (the other major reasons were poor data quality, and poor query response times)

Last year I conducted a BI capability exercise as a consultant for another major telecommunications company. We were sponsored by the CFO to interview business users to ascertain what the business wanted from a BI tool prior to investment in new enterprise-wide BI technology.

We arranged focus sessions with a large sample of employees, ranging from technical analysts, to product managers and heads of departments from across the business in order to get a representative view of how different people extract and consume data. We spoke to them about:
  • what they wanted to report on
  • how they wanted to use the tool
  • how they wanted information presented
  • how they wanted information delivered
  • concerns and issues with current BI landscape
  • what they would want in an ideal world
This information is crucial to ensure that you can deliver a strategic BI Implementation which the business will embrace, support and utilise.

2. Ensure that there is correct metadata attached to your data

If the business don't understand the data, they are not going to use it, or they are going to use it incorrectly. Inaccurate metadata, or worse, a total lack of metadata is a key contributer to poor data quality. Poor data quality is a key contributer to misinformation. Misinformation leads to poor decisions, and poor decisions can impact the bottom line.

You wouldn't attempt to speak a foreign language without first consulting a dictionary, so why should business be any different?

What is good metadata in the context of metadata for a business user?
  • A meaningful name of the data (ie. the report name, or OLAP cube name)
  • Defined business terms for each field within the data
  • Information relating to data owner (who owns the report, or the cube)
  • Business rules and any criteria applied to the data are clearly defined
Metadata should be stored in such a way that it is easy to access and view. Perhaps, kept as a 2nd tab of a report, or on a Wiki, or even a centrally-stored spreadsheet. It should allow a business user to understand exactly what data is trying to tell us, and in what context.

3. Ensure effective information demand & supply processes exist

When I say 'Information Demand' I am talking about the process of how a business user would request information. This process should be supported by a strong team of analysts who can translate and prioritise business requirements into reports, OLAP cubes etc. Ensuring they capture things such as:
  • identification of metrics/dimensions required
  • business rules to be applied
  • presentation (fixed format, dashboard, cube)
  • delivery (frequency, method)
  • known issues (data quality, lack of robust data feed)
As well as being able to understand the business requirements, the analysts should also understand the technical capabilities of the enterprise architecture to aid the delivery of the correct data, defined in the correct way, first time.

When I say 'Information Supply' I am talking about the process of building the report or the cube from the business requirements ascertained by the analyst.

A large problem with a number of BI Implementations is that business users state that "it takes too long to get new data" and that "BI report development takes too long, so I look around for another method of getting the data I need".

Effective Information demand & supply processes - involving strong communication to bridge any gap between the business and IT - are required to maintain a good level of service to the customer, and ensure that these statements do not apply to your BI Implementation.


I'm going to end this post here without touching upon the need for data quality profiling before embarking upon a BI project, because you undertake data profiling as standard for all data-related implementations and migrations... right?


Post a Comment