First published on February 17 2011, 4:14 PM
History of the recent past.
I was by a customer doing something very sexy like tweaking indexes in aggregate fact tables when the company controller, a nice young woman, dropped by while having a break. She saw me there and said with an angel face:
“This year I’m not going to budget by Excel anymore”
“Whoa! Wadda you mean?”
“I’m fed of having all those sheets. I need to consolidate by hand, it’s a pain”.
“So you need something to collect data in an orderly manner and to consolidate and aggregate them in a coherent assembly?”
“Yes, I need a budgeting application.”
I was by the same customer, doing something billable like having an Espresso from the vending machine when the revenue manager entered the break room. She (actually a very fascinating lady in her forties) saw me and told:
“What I’m interested the most, in this datawarehouse thing, is the future.”
“I need to see my orders portfolio, and the sales pipeline. I need to hypothesize about conversion rates. I need to simulate the effect of customer acquisitions or churns. I need to know where I must pour my sales effort.”
“So, you need something to make simulations?”
“I need something to continuously revise my budget, I need a budgeting application”
Actually they’re both right.
The majority of the budgeting applications out there are of the first type. They let people input figures in an orderly way, at various aggregation levels. The workflow is controlled, some batch operations like allocations or other calculations can move data from one budgeting step to another.
Some other applications are designed to make calculations, simulations and what-if. They focus on statistic methods and forecasts.
Very few (and very expensive) applications can, somehow, handle both the requirements.
The difference, nonetheless, is large: in one case you sort numbers, in the other you are calculating the numbers themselves.
I can hear vendors claiming that their applications can handle both smoothly but this is hardly true when confronted with users’ expectations. One of the things I learned is that, when talking budget, non technical users have a severe difficulty when describing the operational flow. So, when they describe a feature, it’s hardly what you have in mind and the implementation you’re thinking to will likely be unsatisfactory. The only way to get it right is a) experience b) mock the process with them and ask where every number should go and what every command should do.
Did you ever see something different? I’d love to hear about you application features supporting one function or the other.