Skip to Content

Have you heard the IT consultant-seagull joke?  It runs something like this:

Q:  Why are IT consultants like seagulls?

A:  Because they have big bills and hover around squawking at you, before crapping on you and flying off, leaving you with a mess.

There is a serious point here, that IT solutions, implemented by IT ‘experts’ so often leave behind a system that, whilst being functionally acceptable, is rigid and a pain to maintain for the business.  This is particularly true of financial planning solutions, where a key success factor is the agility of the solution and its ability to accommodate changes in the planning model brought about by the inevitable business changes resulting from fluid market conditions.  Solutions that are delivered in times of financial retrenchment where the focus is on cost-reduction and profitability maintenance are often unable to support the sort of planning required in times of growth where the focus shifts to testing out new markets and/ or products.

Actualisation is the process of replacing forecasted figures for a recently closed fiscal period with actual financial results into the latest forecast.  The current range of planning solutions, most of which are based on multidimensional database platforms with sophisticated ETL components, mean that this process should be fully automated.  It never ceases to amaze me when I find planning solutions that require users to spend significant time each period keying in actuals figures to update their forecasts.  The potential to reduce this significant manual effort (often 2 or 3 mandays per period per planning entity) is often a key benefit in the business case for introducing a more up-to-date system.

Any financial budgting/ forecasting process will inevitably require some administrative overhead.  The key is to ensure that this is streamlined so that it does not become a barrier to an efficient month-end close process.  Most planning applications contain a workflow component which can be used to manage the forecast process centrally.  Visibility is given on the progress of the various planning entities required to submit budgets and forecasts and communication between the central administration and the planners is supported by the tool, providing a full audit of correspondence in convenient format.

Best-in-class planning applications, such as Business Object Business Planning and Consolidation (BPC), are marketed as being owned by the Finance department, rather than IT.  This is an important distinction as, in order for finance departments to keep pace with the changing business environment in which their organisation operates, the tools with which they predict future performance and health of the organisation must be flexible enough to accommodate those changes, and those changes must be able to be made by the FP&A analysts using the tool.  Any system requiring intervention from IT in order to make small inevitable changes to a planning model, or to output reports, will cause frustration with the tool and a reversion to offline spreadsheet models.  This importance must be borne in mind beyond the choice of planning tool, and through the implementation of the tool.  Change management and training are key, with involvement of the business as members of the development team being essential if the tool is to be properly supported by Finance once the consultants have left. 

Despite the importance of business involvement throughout the planning application implementation, consultants have an important role here – to impose the rigours of best practice software development and project management, and to bring to bear the benefit of their experience in implementing successful systems.  Some areas will remain technical, most notably integration of actuals and master data into the planning application, and a limited amount of bespoke development may be introduced into the system to achieve further efficiencies, but care must be taken to ensure that these developments are future-proof and will not become a barrier to the business maintaining the solution on an ongoing basis.

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Dirk Herzog
    except that you don’t need to use BPC. I’ve implemented some agile planning solutions with SAP BW 3.5/7.0 and one of the requirements always was flexibility. As a consultant I don’t WANT to always be called by the customer for minor modifications if they can do it themselves.
    (0) 
    1. Tristan Colgate Post author
      Hi Dirk,
      On your point about BPC, I absolutely agree.  It’s not the technology that is used, but the approach to building and architecting the solution.
      (0) 

Leave a Reply