Planning, Budgeting & Forecasting Processes – Planning Models vs Business Intelligence Tools  
5th November 2007
Planning models and Business Intelligence (BI) tools are the twin heart of the performance management framework, but they have very different roles to play, even in an all-in-one software solution. The key difference is that planning models create new information (plans, budgets, forecasts), whereas BI tools manipulate and report information that is created elsewhere. In the third of a series of six articles, FSN contributing editor Steve Bows explains how an appreciation of these differences can help to design a more elegant and flexible technical solution to the organisation's planning requirements.

Business Intelligence – Gaining a Deeper Understanding
Dashboard
Before examining the characteristics of planning models, it is worth looking briefly at Business Intelligence (or BI) tools, to better illustrate the contrast between the two. Fundamentally, BI tools are designed to interrogate data and to display it on screen in such a way that the non-technical business user can navigate through it and find what they need. Typically this takes the form of dynamic charts, graphs and tables, which can be brought together and arranged in the form of dashboards and scorecards in larger implementations. By using a single access point to a range of disparate data sources, managers can track and analyse the important metrics of their business without having to know which systems they have been generated from, which means that they can spend more time deciding what to do, and less time searching for the right numbers in the first place.

The idea is not new – BI concepts grew from the Executive Information Systems (EIS) of the 1980s, maturing alongside the data warehousing technology that supports such a system. Indeed it is difficult to over-stress the importance of a well structured underlying data layer to BI implementations. In the previous article I explored the concepts of multi-dimensionality, and how a data mart or data warehouse can help structure data in such a way that “dynamic” reports can be written (using BI) that automatically refresh when a new dimensional member is added (eg the opening of the Newcastle office, reporting in the same format as the other offices). The success of a BI implementation depends largely on the quality of the data supplied to it by the data mart or warehouse – engaging and guiding the user through the BI interface is important, but if the numbers are “wrong” then no amount of whistles and bells will persuade them to use it!

So, if the concepts of Business Intelligence, and its supporting data structures, have been around such a long time, why have we seen such a sudden take-up only comparatively recently? The answer may lie in the means of deployment – many BI vendors now have zero-footprint web portals for business users, extending the reach of the solution far beyond the traditional senior management group. With no software to roll out and maintain on users' desktops, managers of all levels can participate in the analytical process and appreciate at first-hand the power of BI tools. This in turn fuels further demand for the inclusion of new reports and whole new data sources in the solution, and can lead to an exponential upswing in the “return” on the original BI investment.

As a result, the focus of development effort from the BI vendors has turned from the mechanics of their products (which are now mature) to the continuing enhancement of the user experience – boosting the response times for complex user requests, integrating with other end-user applications (such as the MS Office suite), and in making the interface richer and more intuitive. BI is rapidly becoming part of the typical end-user application list, and an accepted way of communicating strategy and results from the senior management group.

Planning Technology – Predicting the Future

Planning software offers the capability to build financial models within a multi-dimensional framework, a vital part of any planning process. For example, planning revenue by product and customer requires the ability to model the effect of both simultaneously, rather than the one-at-a-time approach forced on the planner by the flat two-dimensional world of traditional spreadsheets. These models also need to be connected together in a more robust way than spreadsheet links – enabling fluctuating revenue predictions to ripple through to the costing models automatically.

This is the sort of joined-up environment that internal and external stakeholders expect from the finance function, but one that has proved remarkably elusive to deliver over the past ten to fifteen years. One reason for this difficulty is that it has not had the same development history as BI, and only relatively recently has it reached a level of stability and functionality that is suitable for enterprise-wide deployment. But there is a deeper reason for the perceived difficulty of planning implementations – we expect the technology to perform many different and often mutually exclusive roles.

On the one hand, planning models are like an ERP system, with many linked modules performing specific roles within the planning process. For example, the Revenue, Salary, Direct Expenses and Capital Planning modules all have very unique dimensional structures, user groups and planning techniques – Salary Planning may be limited to HR, Revenue planning to the sales managers, and Capital Planning may be available to everyone but require more stringent authorisation procedures. All have inputs and outputs from other modules (eg headcount caps are determined by sales growth) and relate to a common set of dimensions provided by the general ledger and payroll system (via the data mart). So far so good – this provides a good first step in thinking about planning model design.

On the other hand, however, planning models are designed to replace the Excel planning environment, and will only be accepted by the user community if they deliver the same capabilities for ad-hoc analysis and planning that have made the spreadsheet the accountant's tool of choice. This presents an interesting dilemma for the planning systems architect – robust and centralised, or flexible and distributed?

Integration – Sharing the Load

This desire for both robustness and flexibility needs to be balanced carefully to produce the ideal planning framework, and this requires a creative design approach. If we start from the modular, ERP-based, view of the planning system outlined above, we can add flexibility in a number of ways:

First of all, we must strip out all barriers to flexibility within the models, allowing them to be rebuilt frequently as the business reacts to market conditions. The major barrier is the storage of history (actual data, previous forecast versions and the like) within the models – this data may be recalculated or lost altogether if formulae and structures are changed, and this prevents any changes being made. This is only a problem if the models are being used as both reports and input templates, but this is often the case where BI is not available to the planner, or at least not properly integrated.

The solution requires leveraging the other parts of the performance management framework. By pushing the results of the planning process (usually at GL account level) back to the data mart, it is possible to use the power of BI to analyse it properly, alongside other data held in the data mart. More granular data that doesn't fit naturally within the existing data mart structure can be reported on by BI as an “unstructured” data set. Either way, get the data out and get it properly archived and accessible, thereby freeing your hands to get creative with the design of the new planning models.

The Integrated Planning Solution – an Example using the Cognos CPM Suite
Planning Technical Framework
Secondly, determine which parts of the planning process need to be centralised, and use them as the “hub” into which both the data mart and the more distributed models integrate. This way you can keep overall control of the planning process, whilst empowering managers with specific expertise to design the outer-lying modules. Allowing modules to develop independently, with careful recognition of the effect on the interfaces between them, shares the load and creates a more agile development path.

The Importance of Collaboration

The ideal planning system therefore represents a symbiosis between the three elements of the performance management framework, with each part supporting the others. Developing this type of planning solution requires a multi-disciplinary approach, involving co-operation between finance, IT and project professionals to achieve the desired result. In the next article we'll examine these project roles in more detail, and how choosing and motivating the right people for the team can be the biggest factor in a planning project's success.
Fast Close to the MAX by Gary Simon
 
 
About Us
Privacy Policy
Contact Us
Copyright © 2007 FSN Publishing Limited. All Rights Reserved.
Use of this website signifies your agreement to the Terms of Use.