The preparation of a budget or financial plan is a process that follows a precisely defined sequence of activities that everyone must adhere to. Therefore, the most important outcome of implementing a planning system is not the application of the tool, but the creation of a planning model. Namely, if all the ingredients are not included and perfect, bad ajvar will be eaten next year.
My good friend, a long-time finance and controlling director at a well-known, medium-sized Croatian company, has an unusual habit of comparing planning and budgeting to making winter preserves, regularly calling the annual plan – ajvar. She says this is due to a trauma from her youth when, as a young intern in controlling, she first participated in budgeting and during those few weeks, when the supply of red peppers at markets was at its peak, she spent whole days, even weekends, merging and refreshing documents in Excel and checking formulas and numbers.
There simply was no time for her praised homemade ajvar that season.
In my friend’s company, Excel was long the only tool used in the planning and budgeting process, and IT support existed in that it had, as she says, one ‘kid who enjoys writing incomprehensible macros in Excel.’ One year, the ‘kid’ was away at just the wrong time, and their manual ‘flayer’ got stuck, taking them three days to find out why the final numbers, no matter what they changed in the templates, were persistently nonsensical. That year, a planning system finally entered the ‘ajvar.’ And then came her question: ‘What do you advise me, dear?’
Technology is less important
Of all the advice and related anecdotes I have accumulated or realized over the years in various implementations, this is the first and most important. Although projects for implementing planning systems begin with the introduction of a specialized tool intended to facilitate and accelerate planning, the nature of these projects should be primarily business-oriented and remain so.
I do not mean to say that the choice of tool is unimportant. On the contrary, it is essential to fit it into the technology and infrastructure, and its cost is usually a significant part of the total project cost. The capabilities of the tool are also important, but the market state is such that they are more or less uniform: web access, functions for easier input, ‘break-back’ functionality, clear and easy rights assignment, process monitoring and status tracking, version creation, connectivity with Excel, and so on.
Part of the technological work that also needs sufficient attention is the preparation of all transactional and master data important for planning, which often must be defined in advance or differ from current ones, meaning the introduction of new procedures for their maintenance and/or extraction and later linking to track the achievement of plans. The existence of a data warehouse will greatly facilitate this work, and in every other case, the creation of a data warehouse should certainly be included in the project.
It is often overlooked that such projects provide an opportunity for (re)definition and improvement of planning processes. Unfortunately, not everyone notices this opportunity or utilizes it equally well for some other reason. The preparation of a budget or financial plan is a process in which individual parts of the plan are interdependent, and there is a precisely defined sequence of activities that everyone must adhere to for the process to be effective.
What is more important – the forest or the tree
Therefore, the most important outcome of implementing a planning system is not the application of the tool, but the creation of a planning model that incorporates all business rules and the process nature of planning. A common dilemma in implementing such systems is the breadth and depth of the future planning model, where breadth refers to the set of all areas that will be covered by the implementation project and the future model, and depth refers to the level of details and templates included.
Finding the ideal measure is not always easy, and there is no universal rule. If a company already has numerous, detailed documents and formulas that it uses to calculate various plans or parts of plans that ultimately end up in, for example, the planned RDG, then it is not surprising that it expects the same from the future system. It is quite another question whether it is necessary to include everything in the system.
Well-designed planning models include precisely defined details and relevant ‘drivers’ exactly at the level where they are important. Everything else is excess and slows down both the preparation process and the analysis of the final result. Not to mention how negatively it can affect the accuracy of plans.
