Driver-Based Planning Step 5: Choosing software
Posted by Michael Coveney
In this series of blogs I am providing a comprehensive approach to the design, construction, roll-out and maintenance of a modern driver-based planning solution. In this blog I look at choosing a planning software solution.
So far in this series of blogs, we have identified the purpose of the model, the reports and analyses required, the users involved and documented the source of the data to be entered. Having done this we are now in the position to choose a software solution whereby we can build the model. Be aware that the right software will result in fully integrated models that are easy to maintain and that will fully support decision-making. However, the wrong solution will create simplistic isolated models, that will become expensive to run and unable to support the business.
Software solutions come in two types: Tools and Applications.
Tools provide an environment where the user can build whatever they like. A spreadsheet is a great example of a tool that can be used to build driver-based models as well as other types of system such as a project and personnel scheduling. In comparison, an application has more specialised in-built functionality aimed at particular tasks. For example, a planning application would know how to perform currency conversions and consolidate data across an organisation hierarchy without the need for specifying detailed rules on how this is accomplished.
The advantage of an application over a tool is that much of the functionality is provided without having to write code which makes them easier and faster to set up and maintain, and more important, less prone to errors.
To build driver-based planning models, a software application ought to provide the following capabilities ‘out of the box’:
Multi-dimensional Data Model – The application should support the setting up of models that reflect how the organisation is structured in terms of geography, departments, products and services. It should also support the different types of variable found in financial systems – e.g. P&L, Balance Sheet and statistical accounts, and ‘know’ how these are aggregated through organisational hierarchies as well as time groupings such as quarterly and annual amounts.
Platform – The environment in which a model is setup should allow the creation of multiple linked models where data can be passed/accessed directly between models and where definitions of variables and structures are common.
Data Management – The system should be able to summarise, de-code and import data from other systems, leaving audit trails as to what has been loaded, when and by who. It will also support manual data entry where users can enter data directly through screens, from CSV files, or via a spreadsheet.
Data Generation – As well as allowing models to calculate values in reference to drivers, there should be options to duplicate data, uplift ranges of data by percentages and project data forwards through trends so that ‘what if?” scenarios are easy to perform.
Security – It should allow users to be defined in terms of their roles covering the data they can see and manipulate, according to the management process being supported.
Workflow – The system should provide a way where users are led and directed through the various management processes. It should chase them up when action closing dates are near and provide those controlling the process with a clear overview of what has and hasn’t been done.
Reporting and analysis capability – It should be able to generate a range of reports including graphical representations of data, as well as scorecards and dashboards.
These should be configured in terms of content for individual users and distributed automatically when available. Users should also be able to produce their own analyses but using the latest data stored in the model so that only ‘1 version’ of data is ever used.
Collaboration – The system should have capabilities for sending comments between users and attaching notes to particular data items.
Exception alerting – The system should constantly monitor data and results and produce automatic alerts on user-defined exceptions. This should also include escalation capabilities should the exceptions be ignored.
As a final check, it’s worth checking out customer references who use the intended solution in the same way you plan to do. No system will meet all your needs and so it’s a good idea to evaluate systems on a scoring system with capabilities that are ‘musts’ and ‘desirable’. Lastly, find out what developments the vendor has in place for the solution and where they see it going over the next few years.