Do the Right Thing

- when clients aren’t clear about what they want

by Alistair Clark and Danilo da Silva Campos

This article draws some methodological and organisational lessons from our experiences in developing and implementing a supply chain model for a multinational company in Brazil. The lessons are from the soft side of OR modelling and centre on factors to which we should have paid more attention: the involvement of all potential users of a model, exploration of how users make decisions in practice and with what data, appreciation of the organisational constraints and culture of the decision-making environment, the pro-active and exhaustive validation a model with operational users rather than over-reliance on a client executive's strategic view of the model's purpose.

-oo0oo-

This article arose out of our experiences while designing and implementing a Linear Programming (LP) based Supply Chain Management (SCM) system for a multinational manufacturing company in Brazil. These experiences led us to reflect on how the project could have better been carried out so that the outcome would have been more satisfactory for us and certainly for the client. The events described below will be all too common for many OR practitioners who will have passed through similar situations. Our aim in putting down on paper what happened is to help us reflect on it, draw lessons and pass these on to others.

Bailey Industries is a large manufacturing group, based in Europe, but with several plants in the USA and Latin America. The name of the company and its products have been changed. Its plant in Brazil produces a key component, the alphode, for a number of in-company consumer plants overseas and some external customers. Several other Bailey plants also produce alphodes, but with lower volumes and variety than Brazil which had company-wide responsibility for the supply chain management of the product. This involved planning the production and shipment of alphodes from producer plants to consumer plants over a one-to-two year horizon. At the time, SCM planning was carried out using a large spreadsheet simulation model.

The managing director was a mechanical engineer by background and the chief financial officer an economist. Both were highly numerate and receptive to the idea that OR modeling could contribute to SCM planning which was a time consuming and stressful task for their staff. Many spreadsheet simulations were needed before a satisfactory plan was identified. Bailey's aim was to replace the simulation model with an optimising method that should be easier to use. The OR consulting company for whom we worked at the time was contracted by Bailey to produce a prototype system and then implement it.

The spreadsheet

There were many types of alphode, grouped into families. The producer plants each had several production lines, some of which were dedicated to certain families of high-volume types. The main purpose of the spreadsheet model was to ensure that sufficient alphodes were shipped so that production was not stopped at the in-company consumer plants. These plants specified their use and requirements of alphode types on a monthly basis and so, implicitly, their desired inventory levels of types over the months. External customers specified their requirements only.

The decisions made using the spreadsheet model were:

• the production and inventory levels of alphode types at each producer;
• the shipping of types between producer and consumer plants;
• in-transit inventory levels.

The task was tackled first at the level of families and production plants and then disaggregated into types and lines. All production capacity had to be used, so any excess after producing the requirements was used to produce the main type of each family. In-transit inventory was taken into account to forecast short-term consumer inventory. Furthermore the spreadsheet was used to monitor in-company swaps between consumer plants when there were shortages and also local sales to external customers by the consumer plants. The huge amount of data and the number of decisions to be made posed a considerable challenge to the Bailey staff involved. The spreadsheet model was very large (over 2Mb in size) and increasingly cumbersome to maintain.

Modelling

During the prototyping phase, a good deal of time was spent with the planners, understanding the system, collecting data, testing possible models and obtaining feedback of test results. We took care to keep plant management informed of our progress and made an effort to maintain a good friendly relationship with planning staff. Two members of the staff were highly supportive, but a third was more distant and skeptical of our work. This person was known generally within the plant to be a ‘difficult’ person, but would be a key user so it was crucial that he be brought round by the time the project was completed. This was achieved eventually, but during the project poor internal communication within the planning team was the cause of some tension when it transpired that he communicated with the managing director by passing intermediate managerial levels.

• Lesson 1: Be aware of such informal reporting and the potential consequences.
• Lesson 2: Get everyone who matters on board as soon as possible.

After several months, we had a prototype model ready, tested with plant data, and duly presented our report. This was read in Brazil and then sent to Europe for approval. A short time later, the prototype and its results were presented to the European executive responsible for the alphode producer and consumer plants company-wide. What was originally scheduled as a 15-minute presentation lasted an hour and a half, finishing with enthusiasm and praise for our work. ‘Wonderful!’, we thought, and went ahead with the operational implementation in Visual Basic for the user interface. Microsoft Access was chosen for the data-base, and the CPLEX linear programming solver [1] for the optimization.

In retrospect, this was when we made a major mistake. We had presented our prototype model and report, and too easily assumed that its executive approval meant that everything was understood and agreed. A more explicit response from the planning staff concerning all our operational assumptions and detail should have been more actively sought - we realized later that what the user staff really wanted was not so much a managerial planning model, but rather an operational scheduling tool which did not demand too much thinking on their part. When, as a consultant, one is operating under a fixed budget and schedule, the temptation is to skimp on time-consuming interaction, and get the report and specification out quickly. If the client approves it, and wants changes later, well then, that's their responsibility, isn't it? Of course, it is and it isn't, especially if you want further assignments and client references for new business.

Much more time should have been spent ensuring the model specification was really what the user wanted and needed. We should have tested a far greater number of possible scenarios to provoke reliable user responses. The client was seduced by an attractive Visual Basic user interface and then displeased when the model logic did not produce the expected results. There were subtle misunderstandings concerning the role of excess inventory and variables which weren't really variables, but fixed by management because a consumer plant was possessive of its own planning and scheduling autonomy and wouldn't let the Brazilian planner do it for them.

• Lesson 3: Provoke an active response to your specificiation - don’t settle for a formal passive approval.

The original spreadsheet model depended on certain data inputs that were not explicit, but rather were known implicitly or only imprecisely by the users of the model. At the time this seemed a fault to us, but it turned out to be a feature that the user valued for its flexibility. Our system, which insisted on transparency of the data inputs upon which the decisions were based, did not have this feature.

• Lesson 4: Find out what the users want and value, and why. Even if it seems unreasonable there can be good organisational reasons.

However, we did insist that Bailey took action to reconcile the differences between the production rates data they used for planning and the real plant floor values, since the reason here was a lack of communication within the plant.

In retrospect, our system was too detailed - a more aggregated model would have been sufficient at the level of producer plant and family (rather than of production lines and types). In addition, the user wanted a more flexible model that would not always flag inconsistencies in the production data (eg current stock data sent in by some consumer plants). This was too rigid for Bailey's liking. More of the simulation and interaction aspects of the spreadsheet model should also have been retained.

Subjective preferences needed to be modelled better - the LP model filled up excess capacity in what seemed a ‘random’ manner to the user, who had certain preferred types for production and shipping. The bringing out and explicit identification of these user preferences took a long time. The client's dislike of the LP model as being too ‘random’ (ie too sensitive - why did changing just one input change the result so much?) required that we educated Bailey planning staff in the basic rationale of optimization.

Clearly it is important to speak the same language as the client. A ‘wrong’ solution for the Bailey scheduling staff meant it was infeasible. A ‘right’ solution meant feasibility. An ‘optimal’ solution meant a feasible and apparently reasonable solution that became the final result of a cycle of data adjustments and reruns. It was not ‘optimal’ in the strict OR sense, but was sufficient for Bailey. What the user basically wanted was a quicker and easier-to-use spreadsheet, over which he felt he had control. In the end, the client was essentially interested in a feasible plan, not a near-optimal one.

• Lesson 5: Make sure you and the client are speaking the same language.

The system has been implemented and is up and running at Bailey later than planned and over budget. The planning staff are using it, but finding the planning is now more ‘automatic’ than they would like, with the model seemingly taking away some of their power of decision making. One of us is still working with Bailey on the issue.

A more effective way

These and other experiences have helped us to mould a more effective approach to model identification and project management. We now give much greater emphasis to the clear specification and pro-active validation of a proposed model before implementing it as a software system. In parallel, the user must understand the behaviour and reasoning of the model, and clearly say what decisions he does not want the model to take. We insist that clients devote time to thinking about and defining their needs, and to working with us on the construction of the model and system. Outside consultants can bring expertise and experience to a project, but are no substitute for inside knowledge and user engagement. The users are the only persons who can validate a model and make it work, no matter how much high-level support and push the project has. Any user resistance must be appreciated (and not lamented) by the modeller and tackled. An understanding of the organisational environment is essential for this and the successful implementation of a model, as we found out to our cost. OR textbooks do of course emphasize the importance of validation, but there is nothing like your own experience to bring home this important message.

For the interested reader

[1] CPLEX, 1996, ILOG CPLEX Division, 930 Tahoe Boulevard, Building 802, Suite 279, Incline Village, NV 89451, USA. http:/www.cplex.com/

ALISTAIR CLARK is a Senior Lecturer in Management Science in the School of Business and Management at the University of Teesside. He was formerly a Production Systems Specialist at UniSoma SA, an Operational Research (OR) consulting and systems development company in Brazil. He has also been an academic adviser at IBM's Latin American Institute of Technology, and a lecturer at Kingston Polytechnic, London. His research interests include OR applied to production and operations management.

DANILO DA SILVA CAMPOS is 25 years old and graduated in Applied and Computational Mathematics from the State University of Campinas (Unicamp), So Paulo, Brazil. He is currently completing his master's degree in Systems Engineering at the same university. For the last three years, he has been an active OR consultant and now has his own company OpSearch Consultoria, specializing in logistics and production planning.

First published to members of the Operational Research Society in OR Insight April - June 1998