Measuring the Value of Business Intelligence

Key Points

  • Never start a BI project with the sole aim of making short-term savings through technology consolidation
  • Think about how you will measure the success of the BI project. This will provide a focus and discipline for requirements. Use the stepping stone path to measure the impact of decision support solutions where the benefits are more difficult to quantify
  • Report automation generally creates value over and above the time saved in the preparation. When information is quicker and cheaper to obtain we may find many other opportunities for its use

It is easy to claim that BI helps people make better decisions. For all but the simplest business process, improving decision support involves more than delivering a report with graphs and gauges.

About CMBI

Measuring business intelligence value

Setting realistic expectations from the start of the program is the best way to create a sustainable BI capability. However, measuring effectiveness is also a good way to maintain sponsorship for the program. The following sections look at how you might capture the value of some typical BI scenarios.

Quantitative value measures

Report automation

Analysts and power users can spend a significant portion of their time producing regular reports and analysis. Although they are experts in the technology available to them – typically spreadsheets and personal databases – these tools are not ideal for creating and publishing regular analysis.
Because the analysis is complex to compile, the power users often believe there is little scope for efficiencies. Training power users in the BI toolset and assisting in the automation of complex data integration and analysis will produce immediate and quantifiable benefits. Freed from the routine workload, the user can concentrate on analysis or process improvement that delivers fresh insights or value to the business.
Report automation generally creates value over and above the time saved in the preparation. When information is quicker and cheaper to obtain we may find many other opportunities for its use.

BI in practice
Indirect benefits of report automation
I observed firsthand the indirect benefits of report automation during a project to produce a client relationship dashboard. The dashboard displayed a number of KPIs and historical trends and took about 3 hours per client to produce. Only the company’s most important clients warranted this expensive analysis.
If the sales or marketing team wanted to see similar statistics for emerging or target clients, they would have to make an ad hoc request. This would be time consuming and showed only a subset of the figures in the dashboard and without the same careful consideration for layout and presentation.
By automating the data integration and layout using BI tools we were able to produce the report for any of the company’s clients on demand. This freed up analyst time but also provided an improved service to marketing and sales.

Process automation and support

Process automation is another area where we can make quantifiable efficiencies. Unlike report automation, the users in a process improvement scenario are less likely to be data manipulation specialists. Because of this, significant process efficiencies are often possible with less technical effort than with the report automation scenario.
The difficulty here is spotting the opportunity. Unlike reports distributed by power users, there may be no visible evidence of a manual process. The user is simply doing the work as a way of achieving their primary business objective. Unless you take time to understand their process in detail, you would never know the opportunity exists. In addition, the user is unlikely to admit there is an issue. They may not realise there is scope for improvement or might be embarrassed to admit there is a problem.
The benefits of process automation, as with report automation, are not limited to the time saved by supporting a particular step. A real world example later in the chapter shows how a BI solution to a single accounts receivable process, measurably improved the cash flow for the whole organisation.

Technology consolidation

Never start a BI project with the sole aim of making short-term savings through technology consolidation. My experience is that introducing new BI technology eventually reduces reliance on existing equivalent solutions, but this is a gradual process.
Even when the new tools have overwhelming advantages, users comfortable with existing tools will be slow to transition. It is amazing how many dependencies come out of the woodwork if you try pulling the plug, even if you have performed some prior impact analysis. Being too aggressive about promoting new tools may only breed resentment of their use and miss a valuable opportunity.
Moving from one technology to another is an inevitable event in most businesses, and may save money in the long term. However, we should use the transition as an opportunity to review existing requirements, adding value through process improvement. We return to this discussion in the Migration projects section of Chapter 3.

Qualitative value measures

If the target process is highly repetitive and operational in nature then quantitative benefits are easier to measure. The benefit of providing BI to less frequent – but nonetheless regular – managerial decisions may initially appear far less tangible. Yet BI normally targets these decisions and the users that make them.

The stepping stone path to improving the decision process

It is easy to claim that BI helps people make better decisions. For all but the simplest business process, improving decision support involves more than delivering a report with graphs and gauges. Figure 2 (below) illustrates the stepping stone path that leads from a semi structured decision process to a structured decision supported by BI.

Stepping stone path to decision support
The stepping stone path to decision support

  1. In a manual decision process, the inputs vary over time depending on the availability of time or data. We cannot measure the effectiveness of the decision process (as opposed to the decision itself) because the inputs to the decision have not been formalised or recorded
  2. During process analysis, the decision maker takes a step back from the operational process and considers the ideal inputs for the decision. They may need some guidance from a BI specialist to start thinking about the full range of possible inputs. Chapter 3 looks at this step in more detail
  3. In the supported decision process phase, we design a solution using the findings from the previous stage. We support the decision by providing consistent data and giving consideration to the presentation. This is our first iteration of BI development for the process
  4. Once the decision maker has consistent and reliable inputs for the process they will have time to focus on the possible shortcomings of these inputs. This will lead to further iterations of the BI solution until the decision maker is satisfied with the support. At this point, we have a consistent decision process
  5. With a consistent process in place, we can focus on measuring the impact of that decision. Again, this is not an exact science but we aim to capture and record information that is indicative of the decision impact. Once in place, we have a measurable decision process
  6. A consistent and measurable decision process is not necessarily a good one. We just have a better idea of how good or bad it is. This allows us to modify the input variables systematically and assess the impact

This sounds great in theory. However, will it work with real decisions in the real world? It is probably fair to say that most BI projects do not have ambitions beyond the fourth stone – a consistent decision process. I think the benefit of the last two stones in the path comes from applying this thinking to the earlier stages. After all, what is the point in spending a lot of money on decision support if you have not thought about how you are going to measure the real benefit?

See Also