What to look for in a Scenario Planning solution? part 3/4

Posted by:

What to look for in a Scenario Planning solution? part 3/4

In this series of blogs we will be looking at how scenario planning can help organisations produce better and more agile plans and forecasts. In the last blog we looked at how scenario planning models are built. In this blog we will consider what to look for in a scenario planning solution.

What to look for in a Scenario Planning solution?


To conduct realistic scenario planning requires the use of modern planning technologies.

Financial planning systems first became mainstream in the 1970-80s as business computing became more affordable and access made easier.  This was initially through specialised time-sharing bureaus such as Comshare that offered finance departments simple to learn yet powerful planning solutions. Products like FCS allowed planners to model their organisation and to run a series of scenarios. For example, the system could be set to vary the cost of materials by a range of incremental values, with the result of each scenario being captured for future reporting. Other capabilities included ‘Goal Seek’ where the model would attempt to reach a summary value such as Profit after Tax, by varying a number of underlying variables such as price and discounts.

As computing became affordable, many of the established planning products were re-written and made available for departmental computers and later on personal computers. However, due to the decrease in computing power these platforms offered and the inflexibility of their operating systems, many scenario planning capabilities were eliminated from these products.

Today, personal computers are more powerful than their mainframe predecessors, but it seems that modern software planning solutions have lost many of their abilities to support scenario planning. Part of the reason is that solutions often ‘hard code’ management structures/relationships into the design of the database holding the model, which makes it hard to see the impact of changing them. For example, to model an organisation structure that changes over time requires separate models, but whose output from one year to the next needs to be carried forward to each respective model. This is very time consuming and prone to error.

With this in mind, there are a number of essential features to look out for when selecting a system to conduct scenario planning. In summary they include:

  • The ability to define multiple, linked models. Organisations are typically complex and involve differing levels of detail. For example, to model sales effectively may require information about product and pack sizes, type and location of the customer, while production doesn’t need this but requires information on machine capacity and staffing levels. This type of relationship is best modelled separately but where the models are dynamically linked on data that affects them both (e.g. volume of product sold).
  • Models built from standard structure definitions. A typical organisation will need multiple models and so it’s important that these are built from a standard set of structural definitions. In this way, when a change is made to say the departmental structure, the relevant models are then automatically updated to reflect the change.
  • Ability to model the impact of structural change over time. As mentioned earlier, scenarios will need to incorporate changes to organisation structures, which may totally change the way data is consolidated or allocated. To do this requires a complete separation of data from model structures. The system will need to ‘know’ what structures apply to which time periods and then automatically use that definition to consolidate data. This cannot be handled manually with risking huge integrity issues.
  • Detailed audit trail. In order to understand a particular result, the reader will need to know exactly what structures were used in which time periods and the status of any variables. This will require the system to keep an extensive audit trail of exactly how any result was produced, how data/structures were changed and who changed them, all of which should then be available for reporting alongside the results they produced.
  • Ability to time shift data and structural changes. To go with the above point, the system should be capable of running different scenarios but where data can be ‘time-shifted’ – i.e. projects can be held back or put forward by x number of weeks. The results should then be displayed side-by-side so the viewer can see the impact of time.
  • Support for multiple users. Planning is rarely a single person exercise and so the system should be able to support multiple users. As scenarios are developed, the system will need to managed any interaction such as entering or updating data as and when required by the planning process.
  • Ability to track and monitor chosen scenarios. Once a scenario has been chosen, it should be possible to publish this to all users, collect and report actual results, along with forecasts as time passes. This in turn will lead to the development of new scenarios as the business world differs from what was first envisaged.

From the above requirements, it will be obvious that spreadsheets cannot handle this level of complexity. But neither can most mainstream planning products on the market that lack the capabilities outlined above. Instead it requires one of the new generation of planning products, such as CorPeuM, which was designed for real-world planning. For more information, download our paper on how CorPeuM supports strategy execution.


In our last blog in this series we will look at the benefits of scenario planning. If you can’t wait then you can download the complete set of blogs as a White Paper by registering here.



About the Author: