OPERATIONAL USE OF SIMULATION IN PRODUCTION MANAGEMENT
Introduction
For some years now simulation experts have pointed at the potentials of and the need to use simulation at
operational level in production management. A number of papers dealing with manufacturing simulation
has also tried to address simulation’s place in a CIM environment. But I feel that too little concern has been
taken in trying to find the effects of using this type of simulation has on the organisations implementing it,
and on the humans working in the organisation.
Traditional use of manufacturing simulation
Up to now manufacturing simulation has been used mainly in situations where the decisions to be made,
have mainly long term effects. It has been used for decision support in situations that are months and maybe
years ahead, as one of many tools in factory planning. A typical example is the use of simulation to decide
on the number of machines of a certain type in an extension of an existing plant, i.e., a decision at strategic
level, see Section 1.5. In such project-like tasks there are days and weeks available (and certainly needed)
for doing all the different jobs that are needed for a complete simulation experiment. Specially the data
collection and the verification/validation phases of an experiment should be kept in mind. They are both
time consuming, and they need to be performed in co-operation with the personnel responsible for the plant.
Scheduling systems
Computer aided systems for scheduling or detailed planning are a family of systems closely related to
simulation systems. In fact many people refer to testing different schedules in a scheduling system as being
simulation. And they are fully entitled to do so.
As I see it, scheduling systems and some simulation systems are coming very close in their approach. In
fact we will in near future see scheduling systems with true simulation functions and simulation systems
with much more advanced scheduling functions.
What is simulation in this context
Again it is necessary to mention two of the criteria for defining what is simulation in this context. To be
able to define it a simulation system, the system must use statistics, and have a dynamic behaviour.
Using statistics is required in two stages of an experiment;
* Modelling by using statistical distributions
* Result calculations by statistical methods
To be able to create a realistic model, even when modelling the duration of this week’s jobs on a certain
machine resource, statistical distributions must be used.
And the results from one replication = one occurrence of the event sequence, are not enough to be able to
predict whether for instance a schedule is feasible. Repeated replications with the same input, and statistical
result collections, must be applied to get reliable results.
A dynamic behaviour means that a “true” simulation system does not know what the next job is going to be
until the previous is done. A scheduling system “knows” the schedule for each - 2 -
resource for a fixed period of time ahead (one day, one week). A simulation system does only know what is
currently being done, and is prepared for any influence (delay of material, prolonged jobs, breakdown of
machines, etc.).
Section 7.6 will give some ideas about how scheduling and simulation systems may be used to improve the
planning function and the evaluation of plans.
Manufacturing simulation at an operational level
Traditionally, manufacturing simulation has been used at factory planning level, i.e., for design of layout
and capacity analysis. For some years now people have been talking about simulation of plans and
schedules on a weekly, daily or even hourly basis. Between these levels there are all sorts of combinations.
Differences between simulation used at operational level and strategic level
Table shows some of the characteristics of these two levels that simulation may be used at. It must be pointed out that the
table shows the values for the majority of experiments/models. There are, of course, many exceptions from these.
One example is that models used at strategic level may well be small, but still most of them are large.
Characteristics Operational level Strategic level
Model size small (medium) large
Simulation period short long
Robustness of models low high
Input accuracy high medium (high)
Output accuracy high medium (high)
Detailing high (extreme) low
No. of scheduling rules large small
Model size
This is just to point out that models used in simulation at operational level are normally smaller than those
used at strategic level. By size is meant the size of the real world the models are representing (# of products,
# of resources, area, etc.).
[Link] Simulation period
The values here are obvious, but still interesting. The simulation period in operational simulation varies
from a month and down to one day, or even half a day. A strategic simulation period is normally between
one week and up to more than a year.
Again there are exceptions. One example is a peak-time simulation experiment in connection with an FMS
installation. This is a strategic simulation experiment, but the simulation period may only be a few hours.
The normally short simulating periods in operational use increases the importance of proper use of warm up
time, replications, and statistical treatment of the output. Use of these functions should therefore be
automated for the user. - 3 -
[Link] Robustness of models
This has certainly much to do with the size of the models and the simulation time. Large models run for
long periods tend to be more robust than small models run for short periods. The stride for robust models
also at operational level results in high demands on input and output accuracy, in detailing and in the
number of scheduling rules needed. Robust models are essential in this type of simulation. Answers from
the simulation are needed almost immediately, and mistakes should not occur. In order to avoid mistakes
the manual input from the keyboard should be as small as possible, and the simulator must be totally
reliable. It must also be able to spot and correct any obvious mistakes or misunderstandings.
[Link] Accuracy in input and output
"Nonsense in, nonsense out" is absolutely valid for operational simulation. But quite a lot can be done to
prevent nonsense from appearing in the input.
[Link] Detailing and number of scheduling rules
Again these points are obvious. To be able to analyse a scheduling rule, this scheduling rule must be
modelled in detail.
7.3 Technical features
There is a number of technical features that must be available in a simulator if it is going to be implemented
as a decision support tool at operational level. These features can all be connected to the characteristics in
Table 7.1. Another way of illustrating why operational simulation is different from strategic simulation, is
shown below. These are the most important reasons why so many improvements are needed;
* Increased detailing and robustness needed
* Shorter time available for experiments
* Higher accuracy needed
* Non simulation experts performing the experiments
The rest of this section will try to relate these reasons to the direct effects on the technical appearance and
implementation of a manufacturing simulator used at operational level.
In later parts of this section a set of algorithms will be described. These algorithms were developed to
improve the speed of performing simulation experiments of a case study at Raufoss AS. This study may be
categorised as tactical; deciding on rules and principles of production management and control.
Increased detailing
In input
The increased detailing concerns different areas of a simulation model. First there is a need for more
detailed input to the system. This can be illustrated by an example. When modelling for a strategic purpose,
it is possible to simplify the inter arrival rates of jobs of the same type by- 4 -
using a distribution. This satisfies the required detailing, and it is possible to make decisions based on the
results from this simulation.
If modelling for an operational purpose, there may be only one occurrence of each job type. This fact
requires a more accurate input of the arrival time of the jobs. These arrival times may be the planned start-
up times or start-up windows.
For a manufacturing simulator to be adequate for both strategic and operational simulation, it must be
flexible in the input module. And this is a really big challenge, because flexible often means complex.
Model behaviour
The other main effect of the high degree of detail needed concerns the model behaviour. This means that the
simulation system must be able to behave the same way the real systems do, and to follow the same
planning, scheduling and controlling rules. One example is the rule telling what happens to an order if there
is no room for it in the queuing place in front of a machine. Try find a place for it near by, or transport it to
another buffer store? And what happens if there are no trucks available for this transport?
The main problem here is that some of these rules are not strictly algorithmic, they may vary from person to
person executing them, and also vary with time. The conclusion is that it must be possible to model the use
of these rules on an individual basis.
There are at least two alternatives when trying to solve this problem. One is to make a company specific
implementation of the simulator. The other is to implement a large number of rules to choose from.
We have been using the last one of these solutions. Although there seems to be an enormous number of
situations and rules, they can be generalised and grouped into a reasonable number. With a limited effort we
have covered between 80 and 90 % of the situations. This is based on a survey made in three different
company installations. But in the remaining 10-20 % there may be situations that are critical to the validity
of the model [19].
In the other solution there is a danger that it is impossible to finish; there will always be another rule that is not
implemented yet. And 90 % of the time will be used trying to model the remaining 10 % of the situations.
Traditional approach
The traditional approach when a company is considering a manufacturing simulation experiment, is to
regard this a project. The project is limited in time, and the results from it is used only once. When deciding
on who should perform the experiment, two alternatives are considered and weighed. The one that is most
often used is to hire one or more simulation experts for the entire job. The other is to engage one of the
companies own potential simulation experts for the job. Such experts inside the company is often hard to
find, and they must be trained properly for the job. It is often programmers that are picked for the job.
It is also a question which type(s) of tool(s) that is going to be used. This may vary from general purpose
programming languages to special purpose manufacturing simulators. I will here concentrate on the use of
general purpose manufacturing simulators.
When hiring someone from the outside (another company or perhaps the programmer group in your own
company) for a strategic simulation job, the job is probably properly done. But there is a number of
disadvantages and pitfalls as well. I will here mention those that are also important when the possibility of
expanding or continue the experiment into use at operational level is considered.
Expertise is bought, not accomplished
By this is meant that when the project is finished, the company does not know much more about simulation,
they have just got the results.
Unwilling to co-operate
Simulation may well be regarded as a sort of test of how well the company is running. If people get the feeling that
this is the case in a negative sense, they are not willing to co-operate. And if they are responsible for providing
model input, this is crucial for the entire experiment.
Validation and verification are difficult
One of the toughest jobs in a simulation experiment is the validation and verification tasks. There are many
pitfalls here; things that are obvious to one part (and therefore not mentioned), may be unknown to the
other.
No faith in results
There is always a danger that since some "outsider" has performed the experiment, the people who are
going to use them do not rely on them.
As it probably can be seen these problems and pitfalls affect three main areas; the organisation of the
simulation project, the organisation of the company itself when using simulation, and the human aspects.
Organising a manufacturing simulation experiment and installation of a manufacturing
simulator
In this section I will mention some ideas and advice to consider when organising a simulation experiment or
project. These advice are valid for medium and large companies. Small companies (less than 200
employees) will probably have to approach this problem somewhat different from what we are suggesting.
Often they do not have the capacity of allocating own people, and will probably not have the same benefits
of doing so.
The use of external expertise
There is a number of excellent simulation consultants and experts around. And when you are conducting a
"one of a kind" strategic simulation experiment, the best solution will be to hire some of these experts for
the job. But if the plan is to use simulation regularly in the future, the only solution is to establish expertise
within your own company. The external experts may well be hired in the start-up phase. A large part of their
effort should be training of the company’s personnel not only in using simulation, but also on how
simulation works.
Project organisation
The project manager must, of course, be one from the company. And this must be a production manager,
production planner or at least someone from this department. He or she should not be a programmer or a
computer specialist. Or this should at least not be his/her major occupancy. Remember that the goal of such
a project is to improve production management, and not to implement another computer system.
But someone with computer system responsibility must be a part of the project team. The users must, of
course, be represented, and also someone from the shop floor, preferably from the workers’ union.
The hired simulation experts’ role should be more the one of a consultant, and should also be responsible
for the training and education within the project.
Another thing I want to point out is how important it is to perform a feasibility study as the first major task in the
project. This study will answer the question whether it is possible to implement the expected system within the time
and resources available.
Before an installation is complete, a thorough training of the users must take place. This has certainly more
to do with the human impacts of using simulation, and will be dealt with in a later - 9 -
section. But it must be included as a part of the project tasks, and considered carefully when estimating the
installation costs and benefits.
The manufacturing organisation
The decision of implementing a simulation system for operational use has an effect on the organisation
itself. And this is true even if the decision of implementing the system is a consequence of a reorganisation.
I will not go into a detailed description of distributed production management. I will just point out some
facts about this trend within production management theory. The main idea is to distribute the responsibility
of production management. Groups of people, departments, production lines, etc. are given long term
production tasks, and they control the department themselves. They are allowed to do this as long as they
are able to fulfil the long term production tasks.
To be able to control the department they need among other things, computer tools that are reliable. They need a tool
to verify that the production requirements that come from production management really are feasible. And they need
a tool to verify that the detailed plans and schedules that they put up also satisfy these long term plans. Installation
of a simulator as a decision support tool can be the answer to both these two needs.
Human impacts
The organisational impacts are significant, and so are the impacts this type of use of simulation has on the
humans in the organisation.
It is already pointed out that representatives from the different groups of employees must take part in the
specification and implementation project.
This goes all the way from designing the different strategies and rules that the simulation system is to be
controlled by, till the everyday use of the simulation tool. To be able to design and implement the strategies
and rules, the planners, schedulers, and foremen have to reveal how they really run the machines, cells and
workshops. And this is often not done by using the well defined principles that the manager believes is
being used.
Another sensitive area is trying to estimate the uncertainty in operation times and machine availability.
When someone is asked how things are going in a cell, it is simply human to give values that at least are not
worse than expected. It is only natural to forget some of the breakdowns from last year.
But the real problem is convincing the people that a computer program can predict anything better that they
can. Remember that these people may have been working in the cell for years. A similar problem is the fear
of comparing the real production figures with those that the computer simulation came up with. It is always
difficult to put enough "noise" into a model, and this is the main reason why the simulation results are better
than the real ones.
Again the question of distributed responsibility is important. If also the payment strategies are made dependent of
the ability to fulfil plans in separate departments, the local manager and his crew will be more interested in using
simulation. A good simulation study may be used to verify that the long term plans are simply unrealistic.
