What Budget and Planning Apps do Not do

Originally Posted March 28 2011

These have been bad days, on the private side, but I’m back writing.

i-say-no.png

As you already know I think to Business Intelligence as something more interactive than current applications, and I call it #newBI. I invoke a new generation of interactive applications that could give the business user the real feeling of:

 

1) the actual building blocks of the business

2) what figures would look like if a specific action is taken.

Actually, all these things could be done with current software, paying the price of doing a lot of work on the user or development side that should be done by the application. In particular there are some features which are hardly seen in budgeting software but they are almost always required and hardly considered beforehand.

Adding a new Product/Customer/Salesman/Work Center etc.
Often a dummy code for the new item is provided and the planner can enter numbers on it. But, what if I want to add as many items as I need? If my plan for the future is to have 10 new customers, can I add 10 new codes? Then, I start with empty customers. I would like to add an averaged/median customer on the area where it is located, I might have forecasts at a level higher than that required detail (the new customer is a 150k $ customer but I do not know exactly what is going to buy etc.) and I should not be forced to artificially create that detail on my own.
In general, what I need to do is seeing the figures if I add 3 customers here, 5 there and I lose 1 over there, with no need for a tedious input rebuilding the entire customer profile. This requires some assumptions that should be defined while customizing the application and a range of options to be chosen from. The user should have a button marked “add new customers”. When clicked she should be prompted with the type of the customer, the area or whatever relevant and the system should add them to metadata, fill the data accordingly, and clearly mark them to make them stand out from the others.
The same applies when a new salesman or a new work center or a new warehouse are added: the user will think on terms of the “new” items and the system should let them operate on the “old” and “new” items separately. 

Item Replacement
Often an item is replaced by another. It might be the case of new and old products, of a churning salesman or an employee who leaves. It is apparently easy, just move the numbers from the old to the new and zero the old one. Actually, the devil is in details.
First, there’s no guarantee that an old item is replaced with something identical. A new salesman replacing a leaver, will likely follow a slightly different area. Second, period comparisons will require a comparison with the replaced item, at least for the first year. So, a system should trace exactly the replacements for implementing correct comparisons.

Hierarchies Organization
Hierarchies are always seen as something complex to be managed, but an overlooked complexity is their change over time. Pruning, grafting and switching from the historical view to the current view should be absolutely easy. I mean that these operations should be GUI operations and should not require any batch processing. This is necessary because, before arranging hierarchies, the user is likely to determine how these are to be arranged. To determine the new arrangement she must likely make experiments, testing different options and assessing the outcome in term of figures. This process can’t be too burdensome, otherwise the application will surely fail user expectations.

Make simulations.
Users often need to make simulations to take sensible decisions, analyzing data is often not enough. This goes usually under the name of What-If analysis and is performed by Excel. No use to say, a proper #newBI application should provide a way to work on it without passing through  Excel. For example, what if the labor cost goes up 5%? Calculating this implies a complex and non-linear procedure of price revision. Nonetheless, it’s nothing out of reach of an application, but the additional modeling features required to do so is hardly implemented
There are quantities which are subject to market variations and they’re just a fact of life (gas price, inflation etc.) and their impact on the business should be known and constantly assessed. Other quantities are levers which are in the management’s hands to actually steer the business (discount level, advertising investments, selling expenses etc.) and their impact should be thoroughly simulated by a model to define the overall profitability and cash-flow.

What I described above is just a sample of the requests I received, during the years, from my customers who, in a few cases, find the budget applications they just purchased somewhat delusional because they did not anticipate correctly the amount of work required to address all these issues. Organizing data, splitting on save, managing versions and workflows is something they do very well, and much better than an Excel sheet. Interacting naturally with data is something much more difficult to be found, even in top tier software.

Happy to be disproved guys! Let me know your experience and tell me how your favorite app has no shortcomings. Be ready for a giveaway on the subject in the next future. Think of a killer feature for your budgeting and planning application and stay tuned to get an insightful prize. 

 

Tags

budgetingplanning

2114 views and 2 responses

  • Apr 4 2011, 5:53 PM

    Twitter.com/dhawkins_ibm responded:

    Good points. Funny how everyday functionality is not typically anticipated by designers. I would add a couple of others.

    Adding text to capture text/explanations around planning decisions and having an easy way to retrieve and read those as a reviewer. How often is it just easier to print out a draft plan for review but then the decisions or thoughts that formed the basis of the plan are in a separate email, printed at the back of the report (with no easy way to cross-reference to the plan), or scribbled out in a presentation that accompanies the plan? It would be nice to capture all that in the same place at the same time.

    Another fun one is ability to save, maintain, and leverage different versions or scenarios of the plan. In the Excel world, we just save a copy and name it something different. In application land, each version could have significant space requirements in the database since the version defines the entire data set (drivers and results) and not just the few input variables that are different. There needs to be some way to save snapshots of relevant scenarios and make then available and findable by the planners who may use them.

    I would love to hear the other ones that you have run across.

  • Apr 26 2011, 7:25 AM

    Adel responded:

    Great summary of user disappointments ... special mention to discontinued/new products and customers.

    In my (humble) opinion, usually it's a good idea to separate applications based on needs: keep high level ones for general/strategic decisions and very detailed ones for operational decisions. Why? because it can be difficult to make changes to small apps but when you want to change huge ones (that carry everything) you might be in trouble.

    Another important point is, as Augusto said, budgeting apps are a mega Excel processor, so make
    the choice based on your needs or you will be disappointed.

    Though on a more optimistic level, budgeting apps (when deployed correctly) can change users lifes.

    Ps: Augusto can you please contact me, I can't find your contact info and I don't want to spam your discussion.