"After years of frustration our key stakeholders now have a good view of some of their key performance indicators, there is also less time spent preparing the data for analysis"

Our Partnerships Include
Contact Us

Demand-Driven Business Intelligence

Posted by Peter George, 17 December 2012
Tags: , ,

Demand-Driven Business Intelligence

Few areas of business are immune to the forces of supply and demand. Business Intelligence (BI) is no exception.  BI Teams supply a product, information, which aims to meet the demand coming from information consumers. Of course there are differences between BI and widget-making: information is less tangible, and BI’s end consumers are often stakeholders internal to the organisation. But the same principles apply, and we would be wise to heed the lessons of supply and demand from more traditional industries.

Being Demand-Driven

One important lesson from industry is that product design and manufacture should be driven by demand. Even in Agriculture, one of the most traditional of industries, there is a strong drive towards demand-driven production. It’s no longer a case of just rearing as many sheep as you possibly can, herding them into a truck and hoping for the best. These days every part of the process, from conception to final packing, has a deliberate focus on the requirements of the end consumer - busy shoppers in London or Paris.

In the same manner, BI should be demand-driven. “If you build it, they will come” may work in the movies, but in BI it is merely a recipe for disappointment, even disaster.  Sadly, lacklustre project outcomes are not uncommon in BI – in fact industry analysts Gartner suggest that around 50% of BI projects fail to deliver, and the most common reason for this is the failure to understand and deliver to the requirements of the organisation. 

How can BI be more Demand-Driven?  

Here are two simple approaches that every BI initiative should include:

  1. 1.       Use a Translator

If you liken the BI team to a bunch of Kiwi farmers, then the CEO is an uncompromising Parisian chef.  In the case of farmers, to be demand-driven they need to understand their consumers and what they are demanding.  To get the best result from an exchange with a Parisian chef you would be wise to involve a translator – someone who can not only speak the language of both groups, but who also understands the realities of both the paddock and the kitchen.  The same is true of BI – the demands of the CEO (or other information consumer) need to be captured and understood, but the BI developer is not always the best person to achieve this result.  The ‘translator’ in the BI case is usually a Business Analyst (BA) but the concept is the same: the BA’s job is to translate organisational requirements into language that makes sense in the world of the BI developer. To do this effectively, the BA needs to not only understand the practicalities of BI, but also have a good awareness of the overall organisational context as well.

  1. 2.       Nail Down the Functional Requirements

If you’re developing a new smartphone to take to market, you need to have a clear idea of what the consumer wants the product to be able to do: it needs to make calls; it must have GPS, and so on.  The statement of functional requirements of the phone (i.e. what it can do) is the principal point of contact between the demands of the phone consumer and the engineering that actually puts it together.  A BI project is no different – the statement of functional requirements should be the core document that spells out what is “demanded” of the BI project, and be the primary point of contact between the information consumers and the BI team. Since BI is an information-based product, the functional requirements will usually involve statements concerning the information content that will be provided, or perhaps even specific questions or analysis that the BI deliverables will address.

There are many benefits to a carefully constructed and detailed statement of functional requirements, but some of the key ones that influence project success are:

  • Being top-down and demand-driven, it ensures that the BI project is focused on tangible results and agreed benefits from day one.      
  • It effectively defines the scope of the project. Any activity or deliverable included in the project is only useful in so far as it supports the functional requirements.  If it doesn’t support them, why are you doing it?
  • It provides a touchstone that every part of the BI project can be referred back to.
    • Q: Is this a good solution design – A: How well does it support the requirements
    • Q: Which source applications do we need to integrate – A: What data is necessary to meet the stated information requirements
    • Q: What testing should we do – A: Test that each of the detailed requirements are met
    • At the end of the project it is very easy to demonstrate success. A clear and demonstrable connection between requested functionality and delivered product builds up the credibility of the BI team.

In Summary

Business Intelligence is as much about supply and demand as any other area of business. As Business Intelligence professionals we can improve our ‘product’, and the success of our projects, by becoming increasingly demand-driven in our approach to Business Intelligence.

Peter George is a Senior Consultant with Montage - Business Intelligence


0 users have rated this article

Go Back
© Copyright Montage Professional Services Ltd 2018