Business-owned planning applications - Are we at the Pearly Gates?

7 February 2011

Nicholas Chambers

Nicholas Chambers


An overstatement? An exaggeration? A sales gimmick? – You could justifiably ask all of these about the above statement. But putting aside the cynicism borne from sitting through one too many marketing campaigns and sales pitches for one second, think to yourself...should this be true?

Admittedly, SAP and other enterprise vendors have claimed with the release of each new generation planning toolkit that this has finally been achieved. These claims are typically greeted with a round of scepticism that is proven correct as these rapidly fall under the wing of IT and the business lose interest or fall foul of a tiresome change management process. However, I want to explore why this should still be the result to aspire to and how SAPs current offerings match up against it. And I'm going to do this as a 4-blog series. 

  1. Why business owned planning applications are successful (this blog)
  2. A brief history of SAPs Planning Applications
  3. SAP BusinessObjects Planning and Consolidation (SAP-BPC)
  4. The future (?)

So what do I mean by a business-owned planning application?

Possibly illogically, let’s start with what I don’t mean. I do not mean it remains the exclusive domain of the business and the IT team stays completely away. It still requires a collaborative approach between two. The business should however, be the driving force behind it from the point of inception and they should remain the owners of the system through into the live system.

Project phase: The IT team will typically complete the configuration and development steps and provide a project framework within which to work. But the business should be engaged at all levels throughout - the business sponsor making decisions and driving requirements, the key business users getting knowledge transfer of the configuration and handover and end users receiving training on the tool.

Run phase: By owning the application in the productive system the business should be able to maintain and make minor changes according to future changes to the organisation and not be tied down to the restrictive IT change management process (discussed later on...).

A number of key business users who use the tool as part of their monthly/yearly planning process should be trained to understand the workings of the tool enough to make minor changes, make efforts at troubleshooting user issues and provide an initial impact analysis for enhancements.

Why business-owned planning applications are successful

Firstly, I want to point out that having a planning application owned and driven by the business is no guarantee of success; without input from IT or the rigours and change management processes that have been developed over countless years of software implementations, projects can still fail.

But having a genuine ownership of the model, the solution and the implementation process by the business can immediately start the project on the right foot.

Immediate buy-in & user adoption: One of the challenges of a typical IT-driven project is to find a sponsor from the business that is truly willing to get involved, take responsibility and drive the necessary business process change throughout the organisation. With a project initiated and owned throughout by the business this buy-in is immediate – this is not a project that should fail due to poor user adoption or one that should flounder waiting for business decisions.

Agile approach: Planning applications, more so than other applications, lends itself to an agile implementation approach – in fact this is highly recommended. Despite the large effort that theoretical accountants have put into finding budgeting, planning and forecasting best practices; no two organisations (and quite often no two departments) plan the same way. This requires a high level of collaboration between the development team and the user representatives to ensure that the application is a good fit for how the business operates.

Flexibility vs. rigid change management: Planning is all about the future, either predicting it with forecasts or direct it with budgets; but the commonly used and apt cliché “who knows what tomorrow may bring” is very applicable when looking at Planning projects, whether this be in ever changing requirements during the build phase or organisational/environmental changes during the run phase.

As such, the project approach and software needs to be flexible enough for these unexpected changes (before you get out of your armchairs I’m not advocating developing something so generic that it doesn’t fit the original purpose – just to be able to accommodate likely future changes such as new business units or drivers). In terms of project approach we’ve already discussed the usefulness of an agile methodology, software we will come to later when we discuss SAPs offerings but in short it should allow the business to create new master data, new organisational hierarchies and new ‘what-if’s’ in scenario planning without having to go through a three month change management process that is typical for most IT applications.

A mother’s love...

A less scientific observation, but one I think is useful to acknowledge (no references I’m afraid, but read it in a newspaper a while back)...

Companies that have jobs where mobile devices are required (i.e. the machine you sign when accepting a delivery, etc.) are increasingly finding that they are having to spend considerable sums on ensuring these devices are durable and robust as they are often thrown around and break down. However, its been noted that these devices break more regularly than the same workers’ mobile phones, which it has to be said are typically a lot less durable (try dropping your iPhone and see if you still have a screen...go on I dare you!).

The point being, if people have no stake in something or feel no real sense of ownership or responsibility then they are less likely to look after it or give it a chance. This principle is the case for an IT application too, if the user community feel this is something that is being thrust upon them they will not engage with it as you would hope and would be less inclined to give it a chance if there are bugs.

However, if the business was involved and owned the system from the outset then they have a vested interest to ensure it works and in theory will give it the same number of chances that a parent would a disobedient child.


View comments


Blog post currently doesn't have any comments.

Bluefin and SAP S/4HANA - welcome to the one horse race

We use cookies to provide you with the best browsing experience. By continuing to use this site you agree to our use of cookies.