In a previous post I talked about the most common issues that rise while introducing a structured planning/budget process based on one of the big platforms available on the market. It looks fair to also talk about the issues that these platform actually address well.
There are literally dozens of budget solutions available on the market but we have 3 big players: SAP with BPC, IBM with Cognos TM1 and Oracle with Hyperion (Marketing guys, please forgive me if I did not use the correct latest name). These 3 are comprehensive Enterprise Performance Management suites that include more than simple budgeting, they are development platforms. So, a budgeting or a planning project WILL involve some amount of development; if nothing to initialize budget data and to download them to a reporting application (since typically, you compare your budget with your actual).
What do you get, pretty much out of the box, once you have loaded your data in one of those applications?
First, you get the ability to enter an aggregate number and have it split on its component. You may have your data initialized with last year's figures, than decide that Oklahoma, which absorbed 1.23 M$ in sales will go up to 1.55 M$, enter the new number at aggregate level and have it split on single customers and products in Oklahoma.
Identifying an appropriate splitting rule is not always easy (what happens if I change the average Oklahoma trade discount from 6% to 7.5%? All the discounts are to be risen by a quarter or I should add 1.5% to every discount?), like inferring the rules of what should happen depending on what measure I am changing (if I change the Total Sales, should I change price, quantities or both? Then how?).
This feature spares a lot of work in refining low level numbers to comply to top down directions. So,if your budget/planning/forecast process implies a high number of revisions, driven from a top-down logic, the use of a planning application will spare time and resources.
In an spreadsheet world, this process implies that the people at the bottom of the budget chain must individually revise their work to fit into the new top down direction. In an application driven world they will likely need to do some adjustments but they will be given a coherent starting point for their job.
According the previous example, the 1.55 M$ will be split among all the Oklahoma customers according to the agreed rule (the easiest way is a proportional way) in such a way that the total is 1.55 M$. It will also update all the products sold to a single customer to make the totals meet. The distribution created by the top down, then, is likely to need some adjustment and every salesman can adjust the product sales for each customer or balance two customers. Doing this from scratch is obviously more intricate and time consuming.
~ * ~
The other important issue addressed is workflow management. Every chunk of data depends from some other data, and these data often are owned by different groups within the company. For example, those who devise prices will consider the market but also costs. Costs are prepared by procurement and production, prices by marketing or sales.
So, it is only logical that budget/planning/forecast preparation follows a precise workflow. All these applications, in a way or another, provide a robust workflow engine to organize the job.
Other than the obvious organizational issues, these engines also address another important point which is often overlooked. They let the data flow seamlessly through the application to the correct user. In principle, a new price for a product can flow directly to the P&L to asses the impact of the change. I say "in principle" because the process is not always straightforward, it may require some rather heavy development and it may not be in real-time, but is always preferable to manual aggregations and transformations, but for the smallest data-sets.
On the back side, it happened to me to see companies where the budget process was particularly complex and intricate, to purchase a budget application to tidy it up. The project outcome was not particularly remarkable, since all the mess flowed from Excel files to the application. At the end of the day, it was necessary to step back, organize the process on paper, and implement it back into the budgeting application. It will just do quickly and smartly what you would do slowly and painfully in Excel but you need to have a clear idea of what to do before starting in both cases.
~ * ~
Obviously, these suites offer much more. They all have an engine to manipulate data in order to create P&L, Financial Statements and Cash Flows. They may be integrated with predictive analytics. They can be used for consolidation. They can be used for simulation and corporation-wide what-if analysis. They offer costing engines (or can be adapted to be used as such).
All of this, though, comes with a price attached: development. A complex project might be required to fully exploit those features.
I want to be absolutely clear: I am not bashing the products (I had a lot of fun with some of those myself), they provide real value and, possibly, they can be a huge improvement to spreadsheet based solutions. I am just saying that creating an integrated planning/budgeting environment, beyond the features seen above, requires a project, to obtain a useful result, and this point is often forgotten when an application is purchased.
As usual, I am happy to be proven wrong. Let me know!