APPENDIX II
REQUIREMENTS OF A PLANNING SYSTEM
From a technology point of view, enterprise planning requires a set of integrated capabilities. Integration in this respect means that each function described is available for any data set within the same business model and can be used without limitation in order to support the goal of the system. In the authors’ experience, the following product capabilities are essential.
FLEXIBLE BUSINESS MODEL
A business model is used to describe any data to be collected, modelled, transformed, and reported for the purposes of planning and monitoring performance. The model will hold relationships between departments, products, services, and activities. Data will typically be held in a multi-dimensional form that is also able to support the following:
• Holding a range of data with differing dimensionality. For example, sales may need to be modelled at a customer and product level by region, and a strategic initiative may need to be modelled by activity and date. At some point, all of these different kinds of data with their different levels of granularity will need to be combined to give the full picture.
• Driver-based planning. Planning where entering a few variables, such as sales volume or staff numbers, can generate a range of related data, such as production and staffing costs.
• Time intelligence. As the planning horizon contracts, the ability to model some data at a weekly or even daily level becomes more important.
• The development of initiatives that are targeted at certain areas of the business.
• Storing initiatives separately from the main plan As initiatives are selected, their data should be combined with the ‘business as usual’ plan to give the overall situation.
• Coping with changing business structures. Over time, structures such as the organisation’s departments or strategy map will change. As a learning exercise, it is important to know what structures have existed for what time and how long, and to use this information to compare how things have changed over time.
• Electronically load or manually collect actual results and forecasts for comparative purposes.
AUTOMATED WORKFLOW
Planning is a continuous series of activities that involves different people at different times. This cannot be easily controlled through menu systems because the order and content of those menus will be determined by exceptions and events that may not be known in advance. To support continuous planning, the technology solution must be able to
• model the processes involved in planning and monitoring as a single continuous process.
• trigger any part of the performance management process based on exceptions or events.
• prompt users as to what they are responsible for and when they need to respond. This should be automatically generated from the modelled process and when activities are triggered through exceptions.
• send notifications of deadlines that have been violated and automatically escalate any items not completed within a predefined time.
• provide administrators with an interactive process timeline where they can look out for bottlenecks and re-assign or re-start tasks as appropriate.
TIME AND DATE INTELLIGENCE
Planning is primarily concerned with dates, whether that be starting an initiative, making resources available, asking someone to respond to a request, or the setting of a deadline to complete a particular action.
Time is not just a silo for containing data; it should be a true calendar that not only understands the normal spans of time such as days, weeks, months, and quarters, but can also be configured to understand weekends, holidays, seasons, and any other kind of time grouping that may exist within an organisation.
To go with this calendar, all data should be assigned a date (this is, a true date and not just a storage cell), irrespective of whether it belongs to a normal business function or a strategic initiative. The ability to assign true dates has some powerful management capabilities:
• First, it means data can be aggregated into multiple time spans as dictated by the chosen calendar(s). This allows the same results to be used in local management reports using the local calendar while at the same time reporting the base data according to the group adopted calendar.
• Second, because all data is date-based, the planning system is able to work out how to combine data with different periodicities (for example, combining data entered on a monthly basis with that entered on a weekly or seasonal basis). When using a true calendar, the system can intelligently work out the implications of holidays, and even when a week starts, to produce a consistent, accurate reflection of results in any defined time period.
• Lastly, the system should be able to warn users and management alike when agreed actions have not started or are failing to achieve the goals set. This early warning can be used to automatically trigger remedial action rather than relying on someone to notice the variance in a report that may then be ignored.
In addition to data, business structures, such as the way in which sales departments are organised, should also be date based. When reporting results in covering a particular time span, the system should allow the use of actual, current, proposed, or previous historical structure—or all of them. This allows users to see the impact of change without having to duplicate data or effort.
MEMBER ATTRIBUTES
Most enterprise systems in use for business planning are defined through the set-up of dimensions (for example, organisation, measure, time, version, and so on) and dimension members that are sometimes (for example, in the case of a department structure) organised by hierarchy. Although this is still essential, a planning system should also allow dimension members to be associated with one or more attributes.
Attributes define the characteristics of a member, as we discussed when defining the operational activity model. Attributes can include a range of textual types, including dates (very useful for when defining strategic initiatives), responsibility, and logical operators.
The system should allow these groupings to be used to analyse data irrespective of their hierarchical position (for example, show all initiatives that support the corporate goal of increasing sales, show initiatives whose actual start date is after the planned start date, and so on).
INTEGRATED REPORTING AND ANALYSIS
A planning system needs to combine information from both the normal operation of the business and strategic initiatives. It needs to have access to operational and financial data as well as to actual and planned dates, assigned responsibilities, and much more. This is more than numbers-based reporting; it needs to combine date, text, and structures that are then presented in a way that supports decision making. This is typically far more than can be achieved with a third-party add-on tool, and where reliance is placed on a single data store.
For this reason, a CPM system should allow the following:
• Data to be combined from the different data sets as required (for example, to combine key performance indicators [KPIs] with expenditure and external market data in such a way that could lead management to assess whether a plan is being executed)
• Data to be reported with different structures (for example, using member attributes or different versions of a structure)
• The inclusion of charts, grids, gauges with narratives, and number grids
• The set-up of complex reports that relate KPI data to resources and the achievement of results
• Reports that can sort and filter information based on dates, attributes, structure versions, and the person viewing them
• Reports that can be combined into packs that represent a specific topic (for example, all reports associated with monitoring execution)
AUDIT TRAIL
All data held by a planning system should be tracked in terms of how it was entered and modified throughout the different processes. This information should be available within selected reports so that managers can see the story behind each and every number.
INTELLIGENT ENTERPRISE-WIDE ACCESS
Finally, because a planning system is going to be accessed by many people across the organisation, the application should provide a simple way to manage and control them. This should include the set-up of a user passport that defines the following:
• Their role in a particular process
• The data they can view or modify
• The functionality they have access to, such as building reports or creating processes
• General settings, such as their language, credentials, and contact information
The planning system should also support approval processes (for example, when setting the start date or resources for a strategic initiative, and escalation paths should an activity be behind schedule).