Reactive and Proactive Business Intelligence

Reactive and proactive business intelligence

A business intelligence application can improve a business process by monitoring the process and notifying a manager when there is a problem, or by helping the user meet the business goal before problems occur.
A reactive BI application reports the current state of business goals and objectives. The target audience is generally managers who must monitor the extent to which they are meeting objectives. Typical examples of reactive solutions are executive dashboards and scorecards, which show a graphical summary of actual-versus-target KPIs for measures like sales, inventory, working capital, service levels, and any other metric driven process.
In contrast, proactive BI helps the user meet a business objective. Proactive BI is most effective at the front line of a business. Here lie the tasks that drive the business. If we can perform front line tasks effectively, the high-level business objectives should look after themselves.

Getting the right mix

A business intelligence strategy can focus too much on reactive reporting. Readers who have seen business intelligence product demos may note that I devote little time in this series of articles to executive level dashboards with dials and traffic lights that indicate whether the organisation is about to implode or shoot for the stars. In the ten years that I have worked with users at all levels, I have seen little evidence that a narrow focus on executive dashboards is the best application of the BI budget or technology.
Instead, the incremental improvement in the decision making process at all levels of the organisation results in far more tangible benefits. Each time we build a BI solution for a business process, we can contribute the data we have been working with towards a holistic view to senior management. Using this approach, the executive dashboard becomes an aggregate of the BI strategy progress achieved to date, rather than the end goal. This bottom-up approach to implementation reduces risk because each discrete project delivers value to both operations and management.   
Dashboards, scorecards, and reports are often designed with compliance and monitoring in mind. The user – often a manager – will look at a scorecard and may see a red light next to sales. They have the ability to click on the light and see why the sales are down and whose desk they need to start banging! Given managers normally sponsor BI projects, this may not be a surprise, but it misses a big part of the BI opportunity. Before getting too obsessed with KPI monitoring, we should reflect on what percentage of the BI budget we used to help achieve those targets. 

Moving from reactive to proactive business intelligence

Consider a Financial Controller (FC) who has a target to reduce banking fees by 50%. She can see that reducing the number of overdraft breaches is the key to reaching this target. The problem is complicated because the bank requires three days’ notice to change the authorised overdraft limit. If the overdraft is not required, the company still has to pay additional fees for the facility. Balancing the cost of arrangement fees with the risk of a breach is the decision process that the FC hopes to improve.
A reactive solution might report the current overdraft limit, the account balance, and any known payments and receipts that are still to clear. The FC now has a daily snapshot of how close they are to the overdraft and can take action if she feels they are getting too close.
A proactive BI solution aims to move the decision maker a lot closer to action. The FC is only indirectly concerned with the current overdraft limit, account balance, and difference. What she really wants to know is whether they need to change the overdraft limit and if so, by how much.
Remember we are interested in what might happen in three days from now because of the time it takes to arrange a change. The FC may subconsciously consider a large number of variables when making her decision. We want to formalise these so that the BI application can do more of the legwork.
After an initial requirements analysis, we decide the following information is important.

Table – Data requirements for the overdraft management solution

Data	Rationale	Source system
Average current account balance for the equivalent week, one month ago	We assume that regular events occur in recent history	General Ledger
Average current account balance for the equivalent week, one quarter ago	We assume that regular events occur in recent history	General Ledger
Average current account balance for the equivalent week, this time last year	We assume that regular events occur in recent history	General Ledger
Invoices raised to customers between 30 and 60 days ago	Likelihood of receiving payment from customers	Billing
Planned annual leave for accounts receivable staff in the next week	Likelihood of receipts not being banked or allocated due to staff absence	Human Resources Management
Sick leave currently being taken by accounts receivable staff	Likelihood of receipts not being banked or allocated due to staff absence	Human Resources Management
Number of public holidays in the next week	Likelihood of normal business processes being delayed due to  greater proportion of holiday taken by staff and customer staff	Human Resources Management
Supplier orders submitted between 30 and 60 days ago	Likelihood of having to make large unscheduled payments in the near future	Order / Procurement
Planned marketing events for customers in the next 2 days	Customers sometimes bring cheques with them to marketing events as a good will gesture	Customer Relationship Management
Accuracy of predictive value for last week	Reporting how accurate our proactive model has been in predicting overdraft breaches	BI solution historical data
Accuracy of predictive value for last month	Reporting how accurate our proactive model has been in predicting overdraft breaches	BI solution historical data

Having brainstormed all the things that might directly or indirectly affect the chance of going overdrawn, we can then begin to assign weightings and make assumptions about their impact. The final model might state the likelihood of going overdrawn in 3 days and the predicted account balance. Alternatively, we may just display the data in a dashboard layout allowing the FC to assimilate the information quickly and make her own prediction. 
We may find we cannot obtain all of the data, in which case at least some part of the decision process will rely on manual effort or assumptions. We may also find that in the early stages the proactive BI is not particularly predictive. Measuring the accuracy of any proactive BI is crucial to determining this. You can use reactive reporting methods to monitor accuracy of previous predictions.
Even with incomplete data, the exercise of using a structured approach to decision making should result in a faster and more consistent process. When we make decisions using a consistent approach, it is easier to measure their effectiveness. Quantifying the effectiveness of existing decisions is an essential step on the path to improving them.
BI tools and methods are the ideal candidates for solving this type of data intensive question. The challenges include:

• Data consolidation – from an HR, CRM, Billing, and General Ledger system
• Data processing – complex calculations with large volumes of historical data
• Reporting – reporting the outcome, and providing intuitive navigation of the data

The generic BI solution architecture has a specialist tool for each of these tasks.

Reactive reporting used proactively

The discussion above may leave you with the impression that reactive BI is of less value than the proactive approach. However, a reactive solution can result in proactive decisions. For instance, a KPI dashboard shows the sales director that sales are below budget, and so he calls a meeting with his sales team to work on a strategy for improvement.
Reactive reporting is generally less complex, cheaper to implement, and is certainly preferable to no BI at all. It is also more transparent and the best starting point in an immature BI project because it is easier to validate the quality of the data. In the early stages of BI and DW projects, data quality is the primary concern for most users.
One final consideration for reactive reporting is the importance of designing metrics with the correct sensitivity. You need to consider how frequently you want to monitor the subject area (see KPI volatility example below). The selling point of the dashboard and scorecard approach is that it communicates only the essential information, removing noise. The user need only look at the status of a few gauges and they can monitor the health of the business.
Nevertheless, it is easy to design KPIs that are not sensitive enough to events to provide good indicators of emerging issues or opportunities. By the time an issue emerges on the KPI gauge, it is already known or too late to avoid.