3
PLANNING TECHNOLOGIES
Technology has allowed organisations to plan at ever-increasing levels of detail, and the use of e-mail and network capabilities means that managers at all levels can be involved. However, with these capabilities come problems that can derail the very plans they were meant to enable.
SUPPORTING THE DECISION-MAKING PROCESS
Because of today’s complex and fast changing business environment, technology plays a key role in the development and tracking of plans. There is just too much data to consider and people involved to rely on intuition or gut feel. Imagine for a moment communicating with customers but without the use of email or a website. Other methods could be employed but the speed and cost efficiency of Internet based technologies create significant advantage for those companies that do use them over those that don’t.
Since the advent of the spread sheet, which is arguably the most important business tool created, planning models have become a way of life. In just a few minutes, any planner can quickly construct a simple model that shows the amount of resources expenses to be consumed and the revenues that can be expected by month. The results can be embellished with formulae to generate key performance indicators, perform currency conversions, and create consolidations of different departments. Reports can then be presented to management in the form of grids, tables, and charts.
The spread sheet has transformed planning, or rather, it has transformed the way numbers can be generated, massaged, transposed, redefined, accumulated, and presented. In the past, planners had to rely on manual tabulations or complex computer languages to compute totals and associated ratios, but today a spread sheet can perform all of these tasks easily and without the need for specialist staff.
So it is with other planning systems. All hold the promise of streamlining the planning process through the creation of models that try to mimic the business world. These models are then able to predict what may happen in the future based on a number of assumptions about the market and the anticipated relationships between business processes, inputs, and outcomes.
Streamlining the generation of numbers has given planners a number of benefits, including the following:
• Quickly assessing a range of likely outputs that reflect changing assumptions. By doing this management can be made aware of likely consequences and be prepared should they happen.
• Helping managers to focus on the future, rather than on the past. Models are there to predict what could happen and what needs to be done if the desired performance is to be realised.
• Challenging current business processes. They help management to think through the company operating structure, the drivers of risk and value, and the funding that will be necessary. They provide a concise, logical view that can be contested and ultimately proved, through which the organisation can learn more about the way it operates.
Just one word of caution—no matter how sophisticated a model becomes, it can never reflect the true complexity of the world in which we operate. Models are poor substitutes for reality which is subject to a range of unknowable forces that cannot be codified. However, their true value is in assessing changes to the organisation’s business processes. In other words, their purpose is to support business decisions.
It was in the 1960s that decision making became more of a science with Ronald Howard, a Stanford University professor, coining the term decision analysis. He was instrumental in developing practices and tools in support of organisational decision making that recognises the world is neither rational nor predictable.
In The Rational Manager: A Systematic Approach to Problem Solving and Decision-Making,1 published in 1965, the decision-making process was defined as the following set of management processes:
Establish objectives first.
Classify objectives and place in order of importance.
Develop alternative options.
Evaluate alternative options against all of the objectives.
Make a tentative decision based on the option most likely to achieve all of the objectives.
Evaluate the chosen option against potential consequences.
Implement the chosen option and additional actions required to prevent any adverse consequences from becoming problems.
To adopt a consistent, systematic approach, decision making requires organisations to use planning systems that are able to model their business processes in sufficient detail, and that can provide a number of analytical capabilities that support the seven steps previously mentioned. For many organisations this will mean moving away from using spread sheets as their primary modelling language to more robust software applications.
Eventually decision analysis will advance to decision management, relying on business rules including algorithms as promoted by James Taylor (www.decisionmanagementsolutions.com), but that is in the future.
PLANNING TECHNOLOGIES: THE SPREAD SHEET
When using any technology to plan, the organisation must first be translated into the world of the chosen planning solution. With spread sheets this world consists of three dimensions: sheets, rows, and columns. Typically, sheets are used to represent the organisation structure, columns are used to show version and time, and rows represent accounts. To these, cell formulae and macros add business intelligence such as the calculation of sub-totals, Key Performance Indicators (KPIs), and currency conversions.
Business intelligence in this context applies to the way in which relationships are defined to transform raw data into meaningful and useful information for decision making. For example, the cell containing the measure ‘gross profit’ is calculated by subtracting the cells that represent ‘direct costs’ and ‘total revenues’. Similarly, the cell representing the measure ‘net profit’ is derived by subtracting the cell that has the total of all related expenses, which itself has to be calculated, from the cell containing ‘net profit’ that has been previously calculated. From this management can decide whether the level of profit was adequate, and if not, what areas (that is, revenue or costs) are responsible.
When it comes to consolidating results from different processes or departments, assuming they have been set up as separate sheets, then multiple cell formulae will need to be defined that accumulate the cells from all of the measures on those departmental spread sheets. Of course not all of these formula will be simple additions, as those that calculate ratios will need to be recalculated at the summary level.
Calculations like these are easy to write, but given the number of them that need to be written and checked for anything but the smallest of organisations, the sheer volume becomes unmanageable. If we then start to add complexity in the form of currency conversions, cash flow, and balance sheet calculations that need to take into account prior periods, and dealing with lines of business, the resulting spread sheets become a major liability in that you cannot be sure the numbers are adding up correctly. This is only made worse as they are modified to cope with new requirements.
The problems caused by a spread sheet are down to fundamental flaws in their design when applied to organisational planning. These flaws are outlined in the following sections.
Two or Three Dimensional
As already mentioned, spread sheets are made up of rows, columns, and individual spread sheets that are used to represent the different elements of an organisation. However, organisations are not three dimensional; at a minimum they have at least five dimensions: department, measure, version, period, and year. (We will explain the concept of dimensions shortly, so just bear with us for the time being.) If an organisation also wants to plan by line of business, or by product and customer, then the number of business dimensions has just increased to eight.
In order to handle this level of detail, either the rows, columns, or spread sheets must represent more than one dimension. So typically an annual plan will consists of rows representing measures and another dimension (for example, sales being subdivided into customers, products, and lines of business). Columns will be used to represent periods, years, and version (quite often there is a comparison to last year actual when collecting next year’s plan). Of course these dimensions can be presented differently, but the point here is that the rules need to be carefully managed, as inserting any new rows, columns, and spread sheets could have a major impact on any rules already defined. This brings us to the next point.
Cell Meaning
All data held in a spread sheet is typically referenced by an intersection of row, column, and spread sheet. A particular cell reference ‘C23’ has no particular meaning; it is only by applying rules or macros that the content of any cell takes on its meaning. (It is true that Microsoft’s Excel software has the capability to define range names that can then be used in rules, however this facility involves a high degree of maintenance and cannot be used to track how Excel calculates a particular value.)
Using cell references in formulae are fine when the system is dealing with a relatively simple analysis, such as displaying the profit and loss (P&L) statement for a single company for one year. However, when the data has to deal with multiple companies, with multiple versions of the data (actual, budget, forecast) over multiple years and a mixture of balance sheets, P&L, and statistical accounts, then controlling the meaning of a particular cell and the way it should be treated within a calculation becomes increasingly difficult.
For example, calculating a variance or adding up accounts over time requires knowledge about the account type in order to create the correct formula. Balance sheet accounts cannot be accumulated over time. Creating a budget or actual variance with P&L accounts is not a simple subtraction because you need to know whether the account is a debit or credit. Copying formulae between types will give the wrong answer, so it is not even safe to drag formulae between rows and columns.
If a new row or column is inserted to cope with a new service or product line, there is a real danger that the rule logic will be compromised. If you are lucky, you will get a ‘#VALUE’ error message to let you know there is an issue. If you are unlucky, the error will go undetected until a crucial decision is taken and the error becomes apparent.
Limited Business View
Spread sheets only hold one view of the data, unless that data is duplicated via cell links. This view is fixed by determining what the rows and columns represent when first setting it up. For example, columns may be set up horizontally as time periods, with accounts displayed vertically as rows and the different sheets that represent departments. Of course you can mix dimensions such as displaying actual and budget values within a particular time period as columns.
The way the spread sheet is laid out gives you one view of the business. But what if you want a different view from the way the data was collected? For example, the budget or cash forecast will typically be entered with the columns representing each period next year. However, when reporting actual results, we will want to pick up just one of those budget periods (the current period) and then compare it with actual and forecast results. Of course things are never simple, as the forecast month that is picked will change each month and so any cell references to the original budget will have to change.
What if you want to analyse expenses by market sector or by product? To do this requires a different view of the data, where row and columns represent different items, but that involves either duplicating content or creating a large number of error-prone cell links to switch the data around.
Single User
Single user means that only one person can update the contents of a spread sheet file at a time. That is not a problem for personal use, but when used as an enterprise application where data is to be collected and consolidated from across the organisation, this presents a major problem. To get around this limitation, spread sheets are typically split into multiple files so that users are provided withjust their portion of the data for updating. However, even with small organisations, the number of spread sheets can rapidly increase to tens or even hundreds of files.
This proliferation of files now causes its own maintenance and control issues. For example, if you give someone a spread sheet to fill in a budget or forecast, how do you know that the version they send to you is the latest one, and that it has the same contents as the one they are viewing now? The short answer is you do not know, as you cannot control when they are no longer allowed to change values entered and what version they send to you.
Similarly, if you want to consolidate the answers, you will need a spread sheet that links to all of the other spread sheets to get the latest data. However, if that latest data is not actually the latest data (and you would not know), the integrity of the consolidated result is always in question. What happens if you issue a new spread sheet with new rules or accounts? What happens if they do not use that version? For these reasons version control becomes an unmanageable nightmare.
Lack of Workflow Capabilities
Most planning applications require a distinct set of operations to be carried out in a set order. For example, in a manufacturing company, there is no point in planning for the purchase of raw materials and components until after the sales forecast has been entered and approved. In modelling terms, the amount of sales is the independent variable and its required purchases are the dependent variable. As previously mentioned, when a forecast has been generated it should not be changed until the next round of planning. Similarly, data on current actual expenses should be loaded before we ask departments to review and forecast expenses into future periods.
The order in which things take place needs to be carefully controlled and orchestrated so that everyone knows what they need to do and when. Those overseeing the process need to know what the status is and where there may be capacity constraining ‘bottlenecks’ that are holding up production throughput located elsewhere in the chain. None of these capabilities exist within a spread sheet-based system.
As mentioned earlier, these limitations are caused by the fundamental architecture of a spread sheet, and they are the direct cause of a number of major issues when used for enterprise planning and reporting. Issues like these will lead to wrong results, many of which will go undetected. So why do organisations still use spread sheets? In our and other surveys, it is estimated that around 50 percent of organisations still use them for planning. Part of the reason may simply be due to their availability, low cost, and apparent ease of use, although these last two reasons are easily refuted in anything but the smallest of organisations. The reason could be due to the lack of knowledge about modern planning systems. It is true that in the past planning systems were expensive and complex, but as you will see in chapter 11, "Latest Developments in Planning and Analytics Technologies," things have changed quite a bit over the past few years. Affordable software is available.
PLANNING TECHNOLOGIES: MULTI-DIMENSIONAL DATABASES
In response to the limitations imposed by spread sheets and other two- or three-dimensional planning applications, specialist software vendors working in the 1970s developed the concept of the multi-dimensional database. These can be viewed as being spread sheet-like in that they can display data in the same way as a spread sheet, but underneath there are some fundamental differences that make them ideal for building complex planning and reporting models.
Multi-Dimensional
Figure 3-1: Schematic of a Multi-Dimensional Planning Cube
Multi-dimensional planning systems are set up in terms of the business dimensions to be modelled. This will almost certainly include the organisation structure, the accounts used to plan and report results, the time periods to be covered (for example, weekly, monthly, season), the years, the versions of data to be held (for example, actual, budget, forecast), any line of business or major product grouping, and so on.
Each of these business dimens ions is defined separately and uses common user-recognisable names. It is the intersection of these dimensions that defines a particular value (for example, actual sales of product P1 by department United States of America in March 2012). Figure 3-1 provides an example of how a multidimensional database holds data. Each underlined item is a member of a different business dimension, which in this example includes the version, measure, product, department, month, and year.
New dimensions and members can be added at any time by simply defining them to the system. These new members are then automatically available for planning.
When it comes to reporting, different slices of the database can be selected and displayed (figure 3-2). These view s, as they are known, access the same database and so data is not duplicated.
In order to display these views on a two-dimensional screen or paper, the different dimens ions are selected to form the columns and rows of the report. These dimensions are then known as the on grid dimensions, which can also be nested, so that, for example, versions can be dis play ed for each period being shown on the report. The remaining dimensions of the model are then known as the off grid dimensions and can be used to control what data is selected for the on grid dimensions. This is exactly the same concept as when using piv ot tables in Excel.
Not all members need to be displayed and so they can be restricted to what makes sense for the report being produced.
Figure 3-2A: Different Views of the Same Multi-Dimensional Cube
Figure 3-2B: Different Views of the Same Multi-Dimensional Cube
As well as providing fixed reports, analytical reports can be set up to allow the users to swap the rows and columns of the report. This enables them to view performance from a range of business perspectives without having to duplicate the data or ask for new reports to be developed.
Business Hierarchies
Unlike Excel pivot tables, dimension members in a multi-dimensional database can be arranged as one of more hierarchies. For example, the total company member can be defined as the aggregation of four divisions, which themselves can be defined as the aggregation of other departments. These hierarchies can then be used to consolidate data from those entities at the bottom of the structure to give intermediate consolidated results.
Some of the more advanced systems can store multiple hierarchies. For example, this year and last year’s organisation structure can be displayed. This then enables results from last year to be consolidated according to this year’s structure and still preserve results in last year’s format.
Name-Based Rules
Rules can be defined for each member of a business dimension. This typically happens on the measures dimension where rules can be set up to calculate sub-totals and ratios. These rules can access members in other dimensions and at different hierarchy levels, allowing the creation of allocation rules that span multiple structures. What makes these rules different from a spread sheet is that each rule uses specific member names, so users and administrators alike can easily understand what is being calculated. It also means that as new members are added, existing rules do not change and the integrity of results is preserved.
Multi-User, Role-Based Security
Most multi-dimensional systems recognise that a range of people will be accessing them, each with different roles and responsibilities. To support this, the database has security that is similar to relational databases where each user can be defined in terms of the data they can access, and also what they are allowed to do with it. For example, users may only be able to access their own department’s data where they can review past actual results or budgets and are only allowed to enter data into future forecast periods, when directed by an administrator.
This means that a single model can be used by many people from across the organisation, but with each person being controlled in terms of their access to data and the features they are allowed to use.
Unlimited Size
Today’s multi-dimensional models have limits that are much greater than those found in a spread sheet. They typically allow unlimited numbers of dimensions and dimension members and as many periods into the past and future as required. It means that the design of the system need not be limited by the technology, although they may become too complex to understand and the computing time performance may be compromised if the models become too large.
Financial Intelligence
Some of the more sophisticated multi-dimensional databases have built-in financial intelligence. This intelligence relates to the way in which measures that represent finance values are treated for consolidation, when aggregating time periods, or when used within a formula.
To invoke this intelligence, financial measures will require attributes that identify the following:
• Their natural sign (for example, debit or credit). This allows cash outflows such as expenses to be shown as a positive number and yet will be subtracted when being summed with a revenue number to calculate a net position.
• The type of account (for example, is it a balance sheet measure such as ‘cash at bank’, a P&L measure such as expenses, or is it a statistical value such as staff numbers). These types have significant implications when consolidating data. For example, when aggregating monthly data into quarters, you cannot just add up all of the cash at bank items for each month. The cash at bank value is whatever was there at the end of the last month, although the expense items must be summed. Similarly, measures such as staff numbers cannot be translated into a base currency. Ratios will need to be recalculated at consolidated levels, and other calculated measures, such as revenue = number of units sold x price, must be calculated at a department level and then consolidated.
• Financial measures (for example, what type of exchange rate is to be used when converting from local to base currency; is it the average, opening, or closing rate). Where subtotals are derived from measures that are converted at different rates (for example, closing stock value = opening stock value + additions - sales), an exchange gain or loss will occur so the system can be directed on what to do with the difference in the converted value.
Having this built-in financial intelligence greatly simplifies the set-up of calculation rules. Rules do not have to test the type of measure as this will be done automatically by the system. This ensures that calculations are performed in the right way and at the right time. For this reason alone, errors in setting up rules are far less likely.
Spread Sheet Access
In general, users like spread sheets. They like the formatting, charting, and note making capabilities but they dislike the limitations covered earlier. Fortunately, Microsoft has given Excel the ability to view and manipulate data within multi-dimensional databases that support the OLAP standard (OLAP is short for On-Line Analytical Processing and is sometimes used in reference to a multi-dimensional database). This means users can create reports where they can decide which dimensions make up the rows and columns on the spread sheet.
Data is filtered in two ways. First, Excel respects the database security system and so will only allow users to view data that has been assigned to them. Second, users themselves can filter out what is displayed on the report. To the data that is displayed, users can then add normal spread sheet formulae, formatting, charts, and colour coded exceptions. This means that anything Excel can do with data stored inside a spread sheet, it can do with a supported, external database.
It is important to stress here that the data is coming from the multi-dimensional database, which means as data gets updated in the model, the results in the spread sheet reports are also updated.
MULTI-DIMENSIONAL SYSTEM ISSUES
Given these capabilities, you may wonder why multi-dimensional databases are not universally employed for modelling. This isn’t due to a lack of marketing effort where many millions have been spent on promoting such solutions. Similarly, it’s probably not due to a lack of awareness as many leading analyst firms such as Gartner continually track and publish reviews on software vendors that produce multidimensional planning applications.
In our experience there are a number of issues that prevent their widespread use.
Comprehension
The first issue is one of comprehension. Just getting your head around multi-dimensional views can be a bit of a challenge if you have not come across the concept before. With spread sheets you can see the structure of three dimensions—’ows, columns, spread sheets—but after that the dimensions have to be imagined. Although Excel now has pivot tables that simulate some aspects of multi-dimensionality (for example, dynamic swapping of rows and columns with business dimensions), they still fall a long way short of what a true multi-dimensional database does.
It is interesting to note that back in the early 1990s, Lotus (later acquired by IBM) introduced a multidimensional spread sheet called Improv. This involved the use of names for defining measures and rules, which could also be grouped into different categories that could represent years, products, and departments in the same way as multi-dimensional systems do today. It still made use of cells as in a normal spread sheet, but these were only used to enter and view data and not to store data as in a conventional spread sheet.
Lotus Improv was a powerful tool but it did not take off. This is because many users just did not understand how to approach the building of models that have multiple dimensions. For example, when using a spread sheet you tend to start with what the report looks like, including the mix of the different dimensions on the page after which you can start to add the business rules by making reference to what is on the screen. Multi-dimensional models typically cannot be built this way. You need to first define the business dimensions and the relevant members before you can place them on a report page. Business rules are defined by going back to the dimensions definition and cannot be accessed from the report layout.
Complexity
The second area of concern is the apparent complexity of multi-dimensional databases. Some of this complexity is due to a misunderstanding of the concepts of multi-dimensionality as previously mentioned, but others are due to the age of some systems being offered by vendors.
Many of the systems around today still require some knowledge of information technology (IT) as they abound in the use of IT terms (OnLine Analytical Processing or OLAP for short, Extract, Transform and Load more commonly referred to as ETL), and in some cases model rules have to be written in a language known as MDX (MultiDimensional expression), which can be difficult for non-IT users to learn. The underlying technology also comes in a range of flavours such as relational star schema, multi-cube, in-memory, or hybrid, each with their own particular merits depending on what kind of model is to be built. These flavours then determine the way that user access profiles or backup procedures are set up, which may require an in-depth knowledge of the underlying database technology.
Some will require other software components to deliver a complete solution. For example, most will provide reporting as an optional extra, and few provide any form of process management.
Things are improving, particularly with the introduction of cloud-based solutions (see chapter 11, "Latest Developments in Planning and Analytics Technologies," for more details), but most systems available today still require a good knowledge of the IT infrastructure in which a model is to be built and accessed by users.
Data Uniformity
The third area of concern that has challenged multi-dimensional systems is that problems to be solved must have some degree of data uniformity. This means they must be described in terms of common dimensions and members that are then deemed to apply to all other dimensions and members. For example, defining the year dimension to have the members 2012, 2013, and 2014 means that these years apply to all versions of data, all departments, and all measures. This is because the cube created by the multi-dimensional database assumes that all dimension or member combinations apply to all others.
With the years example this is not a problem, but this is not always the case. For example, sales may be collected by product and customer as well as by operating unit, but balance sheet items such as fixed assets will not. Similarly, some expenses may only be assignable to the operating unit and have no connection with either products or customers. To store these values in a multi-dimensional database requires the set-up of members in both the customer and product dimensions which are basically ignored, but whose reference must be given when accessing the value in a formula.
There are ways around this problem, but the resulting solution can be more complex to set up. Recent developments in multi-cube and star-schema architectures have helped to alleviate this problem, but they are only typically found in the newer systems.
Effort and Price
The last area of issue is the administrative effort involved in setting up a multi-dimensional system. Unlike a spread sheet where Microsoft Excel is dominant (or at least sets the standards that other spread sheet vendors follow), there are different vendors offering different products at different levels of capability.
Most of these are relatively expensive to buy and typically involve an up-front purchase price that depends on the number of users, an annual maintenance fee that is around 10-20 percent of the software purchase price, training costs for administrators that can run into weeks, and an implementation fee where the vendor helps to design the initial model that can cost as much as the software fee. These costs provide a formidable barrier for organisations that have never used multi-dimensional systems.
The good news is that prices have been coming down and are likely to fall more as multi-dimensional software becomes more of a commodity product. More and more vendors now offer these systems as a service commonly known as Software as a Service (SaaS), where systems are rented rather than purchased. Microsoft has started to do this with their popular Office suite that avoids up-front costs and allows new users to try out the system before committing the company to an on-going level of expense.
For most of this book we will remain technology agnostic. That is, we will be describing the suggested planning models in terms that can be implemented with a range of solutions including a spread sheet, although the latter will challenge developers due to the inherent weaknesses that were outlined earlier.
MODELLING TOOLS
Most specialised planning systems come with a range of tools that can speed up the way in which plan data is generated. These tools are more than a set of rules that you would find in a spread sheet. They include a number of techniques that are often marketed as being essential for planning. They can be applied as required (that is, they do not have to be thought about when building a model), and can be used in combination with other tools.
Some of the more common tools and the buzzwords that go with them include the following:
• Extrapolation. This is where the system employs statistical techniques to analyse historic trends in the data and use them as the projection basis for automatically generating a forecast. The more sophisticated systems allow users to select the extrapolation method (for example, the use of least squares to fit the data to a set pattern) and whether or not to ignore abnormal exceptions, known as outliers.
• Allocations. Cost allocations are used to take a value and apportion it across the organisation according to existing values. For example, the cost of the human resources (HR) department is sometimes seen as something that should be shared by all departments based on the number of staff each have. To calculate this, the cost allocation module must first capture the expenses of HR and the total number of people in the organisation, excluding those in HR. The system will then create a value in a selected measure (typically referred to as cost allocation factor) for each department except HR, which is calculated as:
Ideally, this calculation should use activity-based costing (ABC) as the method to proportionately trace and assign the consumption of the resource expenses into calculated costs based on a cause-and-effect relationship. This provides higher cost accuracy and visibility to the drivers of costs. Most software vendors offer ABC features. Alternatively, commercial ABC software can be integrated with the financial system.
• Spread. This is a short cut method of entering a series of data, typically into the periods of a year. For example, by entering an annual amount the system is then apportioned into each period. The method of apportion can usually be chosen from a range of profiles (for example, 4-4-5, which says the last month in a set of 3 is to have an additional amount). The apportionment can be spread evenly across all periods, or it can be based on values that already exist (for example, sales volume to be sold).
• Bottom up or top down. This relates to how data is to be entered. Bottom up refers to departments at the lowest level entering values that are then consolidated to give a total company position. Top down is where a value is entered at a total level for a selected measure, which is then apportioned to all the units that consolidate to it. The apportionment is typically done in proportion to the existing values.
• Goal seek. Goal seek allows a user to select a particular measure that is typically a function of other measures at a consolidated level. The value that the user desires is entered and the supporting measures that can be changed are also selected. The system then works back through any calculations and consolidations, amending the selected measures in proportion to one another, in order to achieve the set target. If the target cannot be met, a warning is given.
This type of analysis can be quite sophisticated as it may require several consolidations in order to achieve the target. For example, setting a contribution level of 30 percent may involve buying more materials that in turn may increase direct costs due to additional storage being required, and at the same time lessening the purchase price because of volume discounts. This type of analysis may also cause circular references, which the more sophisticated systems are able to detect and solve through the use of simultaneous equations.
• Lock. In addition to the previously mentioned techniques, some systems allow users to lock values from being changed. For example, when performing a spread, extrapolation, or allocation, selected measures can be marked so that the system knows it cannot change these values. Similarly, if some of the data is there for reference (for example, displaying last month’s actual results while collecting a forecast), this can also be locked against the change.
• Thresholds. The more sophisticated systems allow the setting of thresholds on measures. That is, the measure can be changed but there are lower and upper limits that cannot be exceeded. This is useful when modelling things like production capacity, as there will be limits on what can be produced in any given time period.
• Approval process. This last tool is more of a system capability that can be applied to when and how data can be changed. For example, when setting budgets it is quite common to allow data to be entered by users for a set period of time, during which they can submit their final numbers for approval. Once done, they can no longer enter or change data—they are effectively locked out.
Those users designated as approvers will now be able to review what was entered and either approve or reject the submission. Rejected submissions are usually unlocked so that users can make changes in order to comply with any directive, after which they are resubmitted and relocked against further change.
This completes Section 1 of the book where we set out to provide a background to the state of planning within organisations. We have looked at the challenges managers face generated by the business environment, and outlined some of the more popular management methodologies that are employed to overcome the issues faced. And in this chapter we have touched on the role of technology and the capabilities of modern planning solutions.
We are now going to build on this foundation in Section 2 by focusing on what types of planning models an organisation requires and how they can be put together in an efficient and effective framework that truly helps organisations manage performance.
Endnotes
1 The Rational Manager: A Systematic Approach to Problem Solving and Decision-Making. Charles H. Kepner, Benjamin B. Tregoe. McGraw-Hill, June 1965.