Chapter 11
The implementation of a mathematical programming system of planning
11.1 Acceptance and implementation
Most of this book has been concerned with the problems of formulating and interpreting the solution of mathematical programming models. There is, however, generally another phase to be gone through before the solution of a model influences the making of real decisions. This final phase is that of gaining acceptance for, and implementing the solution. Many people who have been involved with all the phases of formulating a model, solving it, interpreting the solution, gaining acceptance for the solution, and then implementing it have found the last two phases to be the most difficult. In some cases, they may have stumbled fatally at this point. There are a number of lessons to be learnt from such experiences that are considered in this chapter. Obviously, the problem of acceptance and implementation will depend on the type of organization involved as well as the type of application. It is useful here to classify mathematical programming models for planning into short-, medium- and long-term planning models.
Short-term planning models may be simply ‘one off’ models used to decide the answer to a specific question, for example, do we build a new factory or not, what is the optimum design for this communications network? If these questions are unlikely to recur then there is generally little to be said about the acceptance and implementation. The solution produced by the model is either used or not used. For other short-term planning questions that do arise regularly at daily or weekly intervals, there may be an implementation problem. Firstly, it should be pointed out that in some cases a mathematical programming model may be applicable but unworkable. For example, a complicated distribution or job-shop scheduling problem may be essentially ‘dynamic’. Changes may be taking place all the time, new orders may be coming in and machines may be breaking down. It might be impossible to define a once and for all schedule. To adapt such a schedule to each change might involve a rerun of the model. Unless the changes were infrequent and the model comparatively quick to solve, such an approach would be impossible. In such cases, special purpose adaptive (and probably non-optimal) quick decision rules would probably be used. Some short-term decision problems that occur regularly can often be tackled through a mathematical programming model. Day to day blending problems, for example, may be of this nature. Sometimes fertilizer suppliers or food manufacturers run small linear programming models for individual orders or blends. In such cases acceptance of the method must have already been achieved. An organizational problem will also have had to be solved probably by automating the conversion of the data into a standard type of model for quick solution by a computer (probably through a terminal). The use of such short-term operational models creates few other implementation problems because once accepted their use is fairly straightforward.
Medium-term planning is usually considered to involve periods of a month up to one or two years. It is for these problems that mathematical programming has been most widely used to date. Once a medium-term planning model has been implemented and is being used regularly, it may be incorporated into, or form a starting point for, a longer term planning model typically looking up to about six years ahead. The problems of getting acceptance of such models are similar but usually more acute in the case of longer term planning. Both are considered together.
Much has been written on the more general problem of how to gain acceptance for and ensure the implementation of the results of any operational research study. A clear and useful account of the considerations that should be made is given by Rivett (1968). The main lesson to be learnt is to involve the potential decision makers in a model building project at an early stage. If they have lived with the problems of defining and building a model they will be much more likely to accept and understand its final use than if it is sprung on them at a late stage. Early involvement by top management can have its dangers. It is possible that the development of a model may get bogged down in detailed technical arguments between managers who would normally never be concerned with such technicalities. More seriously, a model building project might be rejected at an early stage through disagreement over detail. These risks are, however, normally worth taking in comparison with the risk of rejection at the final hurdle. Involving top management will often be by no means easy. They will need to understand the potentialities of a mathematical programming model but will probably lack both detailed technical knowledge as well as detailed departmental knowledge of some aspects of their company. Some of this detail may well need to be incorporated into the model. The solution is probably to involve one or two such managers in the model building project as well as give regular presentations to the others. There is then of course another danger to be avoided. It is important not to oversell the model. If it is thought that the model will answer every question, then later, disillusion may be in store.
Many people have found that a new mathematical programming model has gained acceptance when the answers which it produces confirm a decision that has already been made. For example, an important investment decision may have been made in some other way. If the answer to the model confirms this, the ultimate regular use of mathematical programming may be assured.
It has already been suggested that sometimes the very exercise of building a model leads to the explicit recognition of relationships that were not realized before. In such circumstances the modelling exercise may be as valuable as the answers produced. When this happens the effect on management may well be to make the use of mathematical programming more acceptable.
The ultimate acceptance of a regular mathematical programming system of planning usually requires organizational changes that are considered in the next section.
A very full and useful description of the experiences in developing and gaining acceptance for a large long-term planning mathematical programming model in British Petroleum is described by Stewart (1971).
An analysis of the factors that make for success or failure in implementing the results of corporate models is given by Harvey (1970). On the result of a survey he isolates the characteristics of both management and decision problems that lead to success or failure in the implementation of a model. Problems of implementation are also discussed very fully in the book by Miller and Starr (1960).
A perceptive analysis of three industrial problems where linear programming has yielded disappointing results is given by Corner (1979). He draws conclusions and presents advice on the basis of these experiences.
Finally, as was mentioned in Section 2.3, it seems quite likely that mathematical programming methods will be incorporated in much larger pieces of software known as decision support systems. The resultant systems will usually be tailor-made to specific applications. In this way much of the effort of model building will be transferred to the computer system. It will then be necessary to include model building expertise in the designing and writing of such systems.
11.2 The unification of organizational functions
One off the virtues of a corporate planning model is that many interconnections between different departments and functions in an organization have to be represented explicitly. The obvious example is production and marketing. In many manufacturing industries these two functions are kept very separate. The result is sometimes a divergence of objectives. Production may be trying to satisfy orders with a reasonable level of productivity. Marketing may be trying to maximize the total volume of sales rather than concentrating on those that make the greatest contribution to profit. One of the greatest virtues of a product mix type of model is that it forces marketing to take account of production costs. The result is almost always a reduction in the range of products produced to those that can be produced most efficiently. In practice with this type of model the incorporation of the marketing function can present difficulties. As was suggested in Section 3.2 it may sometimes be politically more acceptable to first of all leave out the marketing aspect. A model is built simply to meet all market estimates at minimum production cost. When this type of model has come into regular use it can fairly easily be extended also to decide quantities to be marketed, taking into account their profit contributions. The marketing division of a company is often less able to quantify its data and more reluctant to accept the answers produced by a model. Indeed, their individual objective may be at variance with that of the company. Stewart (1971) gives a case history of a linear programming model built for the Gas Council, which was considered to be of little use for marketing.
In order to give an idea of the different company functions that can be incorporated in a mathematical programming model, Figure 11.1 demonstrates how purchasing, operating and planning functions can become involved in a model.
The model here is described by Williams and Redwood (1974) and takes in all the functions in the box enclosed by a dotted line. It is a multi-period, multibrand model for aiding decisions of the purchase of edible oils on the commodity market and their blending together into foods. The involvement of different functions and departments in the building and use of a model such as this can force some degree of centralization on an organization. This aspect is considered in Section 11.3.
While the explicit recognition of interrelationships in an organization through a model is desirable, it usually makes extra coordination necessary for the supply of data to, and the use of, a model. Often, this requires the creation of a special job or even a small department. Such a coordinating role is often effectively done through the management accounting department. They are one of the few departments with an overview of the whole organization.
One of the possibly contentious results of decisions, which may be reached through a corporate model, should be recognized. Because such a model will have a corporate objective, this may conflict within the objectives of individual departments. It has already been pointed out that a marketing division may force them to reduce their product range and therefore their total volume in the interests of greater company profit. The disputes that may result in consequence are added reason for obtaining top management backing for this method of planning. In Section 4.1 it was demonstrated through a very simple example how a corporate objective could result in an individual factory having its individual profit reduced in the interests of overall company profit. Again the possible political implications are obvious.
Although there may be obvious difficulties in getting different departments to work more closely together, there can be advantages resulting from a planning model. The combination of a large amount of data and information in one computer model can lead to greater convenience. Each department can be given the relevant portions of a computer run. Problems of communication and incompatibility of information will be reduced in consequence. One of the by-products of a corporate model is usually greater contact between departments. Each department will want to know what information other departments have fed into the model, because this may affect the suggested plans for their own department.
The correct use of a multi-period model for planning has already been mentioned in Section 4.1. Such a model may well provide operating information for the current time period as well as provisional information for future periods. Such a model would generally be rerun at least once in each period, giving the same combination of operating information and planning information based on the best available future estimates that have been fed into the model.
11.3 Centralization versus decentralization
A corporate model obviously brings into its orbit many aspects of an organization, which might normally be separated into different divisions. Sometimes these divisions may be separated geographically. In some respects the resulting greater centralization of planning may seem desirable. The small example of Section 4.1 demonstrated how individual factories in a company might produce sub-optimal plans when working independently. In the last section, it was pointed out how the recognition of the interdependence of different departments in an organization often results from a model. Although many of these features are to some degree desirable, when carried to excess they may be far from desirable. In fact, the increasing disadvantages of greater and greater centralization have been a major factor in discouraging the continual growth in the size of mathematical programming models.
In theory, decomposition, which was discussed in Section 4.2, offers a way out by avoiding the need to include all the details of an organization in one total model. Unfortunately, the computational problems of using a decomposition method in general have not yet been fully resolved. At present, it cannot be considered to be a sufficiently developed technique to be always usable in practice. Moreover, mathematical methods of decomposition do not always correspond to acceptable decentralized planning methods. This aspect of the subject has been discussed by Atkins (1974).
Stewart (1971) rather surprisingly suggests that the use of a long-term planning model in British Petroleum led to some degree of decentralization. In particular, it was then possible for a division to obtain complete information before making a plan themselves rather than the information being restricted to head office. This enabled the division to take on more responsibility. On the other hand, the division now had to work within some centrally defined objective rather than choose its own objective. People now, however, felt that they were working to an independent system, in the form of a model, rather than being simply dictated to by head office. This, to some extent, made centralization more acceptable.
As was pointed out in Chapter 6, a wealth of information can be obtained from the solution to a linear programming model. For large corporate models this excess of information can create difficulties. It is very important to ensure that departments only get relevant information; otherwise, they can be submerged. The use of an automatic report writer as discussed in Section 6.5 is obviously desirable. Such a report writer can be designed to produce the information in different sections for the use of different departments.
It is necessary to strike a correct balance between the model builders, the contributors of data and the managers who use the results. There is a great danger, in a large organization, of them losing touch with one another. Relevant data may not be used at the right time and inaccurate results may be obtained. Ideally, management will become accustomed to using a model on a ‘what if …’ basis. They will ask questions which the model builder will be able to answer quickly by new runs or post-optimal analysis.
The degree of centralization or decentralization, which the use of a model should be allowed to impose on an organization, must obviously depend very much on the organization and its ultimate objectives. In consequence, few general guidelines can be given. The recognition of the problem of centralization is, however, important. It is interesting that mathematical programming was used quite widely in the former communist countries for national economic planning. In the West, this is far less common. Models are usually limited to the level of individual companies.
11.4 The collection of data and the maintenance of a model
The collection of data is a major task in building a large mathematical programming model for the first time. Once this has been done, the organization should be geared to providing and updating the data regularly. Inevitably, much work will be involved in collecting suitable data. Coming from different departments, it will often need to be standardized. Again such standardization and coordination will ultimately need to be the responsibility of a special person or department if the model is to be used regularly. As has already been pointed out, a management accounting department is often a suitable place to which to entrust this responsibility.
The person entrusted with the regular collection and standardization of the data must be in a position where he/she is kept up to date with all changes. These changes will come from different departments. There may be marketing estimates, changes in productive capacity, technological changes in production processes, and changes in raw materials costs. Ensuring that all this information gets incorporated in the model and it remains an up-to-date representation is no mean task. It may sometimes be necessary to do preliminary processing of the data. For example, sales estimates may be the result of a regular forecasting exercise. This may require preliminary computation. It may be necessary to convert costing data to a suitable form, for example, to ensure that only variable costs are used. With some packages it is now possible to prepare, manipulate and present the data though spreadsheets. The solutions are sometimes conveniently presented in this form also.
The use and regular updating of databases to include all relevant statistical information is of value when used in conjunction with a mathematical programming model. Such databases may also be used for other purposes as well within an organization. It is important, however, to ensure that their organization and design are compatible with the mathematical programming model used. Most commercial package programs for mathematical programming can be incorporated as part of a much larger computer software system (e.g. a decision support system) using a database.
As with so many computer applications their use does not reduce the need for employees; instead, it changes the type of employee required and sometimes increases the total number of people. It should be obvious that the problems of collecting data and maintaining a model deserve considerable attention and effort if its use is to be effective. The gain should come from the wider range of policy options that can be considered as well as their greater reliability.