Fishwick P.A. (editor) Handbook of Dynamic System Modeling
Подождите немного. Документ загружается.
32-14 Handbook of Dynamic System Modeling
Journals and Trade Magazines
ACM Transactions on Modeling and Computer Simulation (TOMACS)—http://www.acm.org/tomacs
NTSA Training Industry News—http://www.ntsa.org/ and http://www.ndia.org/
National Defense Magazine—http://www.ndia.org/
Military Training Technology Magazine—http://www.mt2-kmi.com/
Training and Simulation (Annual Issue). Published by the Armed Forces Journal International—
http://www.afji.com/
Phalanx and Military Operations Research Journal—http://www.mors.org/
SCS Journal of Defense Modeling and Simulation—http://www.scs.org/pubs/jdms/jdms.html
Web Sites
ACM Special Interest Group on Simulation—http://www.acm.org/sigsim/
Army Modeling and Simulation Office—http://www.amso.army.mil/
Center for Army Lessons Learned—http://call.army.mil/call.html
Defense Modeling and Simulation Office—http://www.dmso.mil/
Institute for Simulation and Training—http://www.ist.ucf.edu/
MSRR—http://www.msrr.dmso.mil/
National Simulation Center—http://leav-www.army.mil/nsc/
National Training Center—http://www.irwin.army.mil/
Program Executive Office for Simulation, Training, and Instrumentation—http://www.peostri.army.mil/
SEDRIS—http://www.sedris.org/
Simulation Interoperability Standards Organization—http://www.sisostds.org/
Simulation Technology Magazine—http://www.simulationtechnology.org/
33
Dynamic Modeling in
Management Science
Michael Pidd
Lancaster University Management School
33.1 Introduction .................................................................33-1
Models to Support Decision Making
•
Dynamic Systems
Modeling in Management Science
33.2 An Approach to Dynamic Systems Modeling in
Management Science ...................................................33-4
Project Management Skills
•
Conceptual Modeling
Skills
•
Technical Skills
33.3 Discrete Event Simulation ...........................................33-7
What Types of Problem are Well Suited to Discrete-Event
Simulation?
•
Common Application Areas for
Discrete-Event Simulation in Management Science
•
Discrete-Event Simulation Terminology
•
Activity Cycle
Diagrams in Conceptual Modeling
•
Implementing a
DES Model in Computer Software
•
Discrete Event
Simulation using a VIMS
33.4 System Dynamics in Management Science .................33-16
System Structure and System Behavior
•
Qualitative
System and Dynamics: Causal Loop Diagrams
•
Quantitative System Dynamics: Level-Rate Diagrams
33.5 Model Validation ..........................................................33-21
33.6 Chapter Summary ........................................................33-22
33.1 Introduction
There was a time when even large businesses were staffed by many clerical workers whose main role was to
process data and turn it into information. The data included sales invoices, payments, orders, production
schedules, and the like. It had to be processed so that the managers of the organization, whether public
or private, could make sound decisions. Decision making is a fundamental part of any manager’s job;
sometimes the decisions are trivial and have little impact, but others are so significant that they could open
up new opportunities or ruin the business. Nowadays, the serried ranks of clerical workers have gone in
advanced economies and information processing is automated in computer systems, some of which offer
decision support. The importance of decision making and the use of information on which to base those
decisions led to the development of management science: sometimes known as operations research in the
USA or as operational research in the UK.
This chapter focuses on dynamic modeling to support decision making and planning as it has developed
in management science. A glance at the catalog of any academic publisher will show that there are many,
many texts that cover the techniques associated with management science. Examples include Hillier and
Lieberman (2005), Daellenbach and McNickle (2004), and Taha (2003) and the list of such books is
constantly changing. This chapter is not intended to provide a condensed version of these books, but
instead discusses dynamic systems modeling in management science and provides practical tips on how
33-1
33-2 Handbook of Dynamic System Modeling
to go about doing this. Clearly, not everything can be covered in the space available, and much more detail
can be found in Pidd (2004a).
Models are used in decision making and planning to explore the consequences of decisions before they
are made. The decisions may be one-off: for example, a business may wish to plan its distribution network
for the next few years. Getting this right can save much money. A model that carefully explores the various
options against likely demand and cost scenarios can be very useful in this regard. Other decisions are
repetitive, for example airlines make routine use of dynamic pricing systems when selling tickets over
the Internet. As most of us know, two passengers sitting in adjacent seats on the same flight may pay
very different fares. Often these differences are due to the time at which the flight was booked, with early
bookers paying the lowest prices. As the flight fills, so the ticket prices rise, though they may fall again
if demand is lower than expected. This dynamic pricing, which is relatively simple for point-to-point
airlines, is executed through a set of interlinked models that forecast likely demand through the booking
period and adjust the prices so as to maximize revenue or profit from the flight. Similar systems are used
for other “perishable” goods (ones with no value after a sell-by date) such as hotel rooms. An airline that
operates many flights could not use dynamic pricing without automated decision models.
33.1.1 Models to Support Decision Making
The obvious first question to be faced is: Why use models to support good decision making and planning?
Aren’t some managers just very good, intuitive decision makers? Why go through all the rigmarole of
modeling to support a decision? While it may well be true that some managers are good intuitive decision
makers, a look at the longer term financial performance of almost any organization, whether public or
private, makes it clear that these are rare beasts. The trick is not to make a single, good decision, but to go
on making sensible choices time after time. For present purposes a model to support decision making will
be defined as follows (taken from Pidd, 2003):
an external and explicit representation of part of reality as seen by the people who wish to use that
model to understand, to change, to manage and to control that part of reality.
This may seem a little vague, so it will now be unpacked in a little more detail.
As Sterman (2000) and others in the system dynamics community point out, we all use mental models
to understand our experiences and to plan for the future. For example, I live on the west coast of Britain
near the sea, where the weather is very changeable and can switch from sunshine to rain rather quickly.
Over time, I have learned to “read” the sky and the wind to forecast the weather in the next few hours
or so. Though this mental model can be improved by experience, it is really not much use beyond an
immediate prediction and is unlikely to work for locations on the east or south coasts; let alone on another
continent. Early weather forecasting was based on folklore, which embodied experience: “Red sky at night,
shepherd’s delight, red sky at dawning, fisherman’s warning.” However, things are very different now, and
it is possible to get a 5-day weather forecast for almost anywhere in the world by logging on to one of
the many Web sites that provide this service. How is this done? Data from terrestrial weather stations and
from orbiting satellites is fed into data centers that use mathematical models of the weather systems to
predict the weather. This is obviously easier in some locations (for example in a desert) than others, but
the same generalized models are used. These were developed by meteorologists over many years and are
external and explicit—that is, anyone who understands the science and mathematics can explore, criticize,
and improve them. The models used in management science to support decision making and planning
are likewise external and explicit and open to scrutiny.
The second part of the definition stresses that such models are representations of part of reality. This
is important, because models are always simplifications. Any model that is as complicated and complex
as the system it represents would be as expensive to build and as difficult or dangerous to use. Models are
used in place of real experimentation, which was often known as “suck it and see” by old-style engineers—
an approach that seems attractive, unless the system being studied contains the economic equivalent of
strychnine. It is important to realize that the simplification needed to build a model is actually a good
Dynamic Modeling in Management Science 33-3
thing and should not be regarded as a limitation. It forces the modeler and decision makers to focus on
the important aspects of the system being studied. Thus, models that forecast sales in a supermarket may
be based on loyalty card data and it is usually enough to divide customers into categories for targeting
purposes, rather that considering them individually. That is, a simplified model of purchases by different
categories of customer may be enough.
The third part of the definition stresses that people are involved in the modeling and the use of the
model and that they have purposes in mind. This provides guidance on the appropriate simplification, as
discussed in the previous paragraph, and is also important when assessing whether a model is valid. In these
terms, a valid model is one that is useful enough for the purpose in hand—even if it is not good enough
for some other, possibly related, purpose. For example, a model to support the daily scheduling of jobs
in a manufacturing plant will need to be very detailed and will probably incorporate the characteristics of
jobs in the order book and of the available manufacturing resources. In contrast, a model to plan capacity
over the next 3 years may need to focus on trends in orders and likely changes in technology but will
not incorporate details of individual jobs. Thus the second, longer term, model may be very useful for its
intended purpose but may be hopeless for daily job scheduling.
It is also important to realize that models are used for decision support and planning rather than to
totally replace human decision making. Thus, an important maxim for modeling is: model simple, think
complicated. The models are used to free humans for tasks that they are rather good at—making sense
of unstructured situations—by performing the rapid calculations and inferences that most people do
relatively poorly. If the model turns out to be too simple, then it can always be made more complicated. In
one-off decision making, this essential link between the human decision maker and the model is obvious,
but what of routine decision making such as dynamic pricing systems? Though these systems, if well-
designed, are adaptive to changes in the environment such as increases in demand or costs, they have their
limits. For example, intense competition on a route may lead an airline to introduce a wholly new fare
structure to win customers. This will require human intervention and decisions; supported, of course, by
appropriate decision models.
The other human component in model building and use, which is often sadly ignored, concerns the
nature of “reality”—a term used in the definition. Sometimes, we are not modeling reality, but are
investigating something that does not exist—the future—and a model that is valid for now may not be
valid for then. Recognizing this is important. Also, we must ask what we mean by reality. This is an issue
considered by philosophers for millennia and it has practical import in modeling. First, people differ in
what they regard as “real.” Sometimes this is because they are psychotic, but this is rarely the case. It is
well known in the law courts that two people can provide quite different accounts of the same incidents
and neither may be lying. They have seen the incident from different perspectives and may have different
experiences with which they make sense of what they have seen. That is, each person’s knowledge is partial
and personal. Sharing and exposing that knowledge to criticism makes it more likely that the knowledge
will be more complete. This is well illustrated in the following story that seems common in a number of
cultures:
Six blind men are led into a circus ring, not knowing where they are and are asked, using touch, to
say where they are. The crowd watches with interest as an animal is brought slowly and quietly into
the ring. The men touch it at different places. One cries out,‘I’m sure I’ve found a tree, it’s rough like
bark and I can put my arms around it’. Another tries the same and agrees; then another and a fourth.
The fifth man reports that he’s holding something long, narrow and sinuous—which must be a tree
creeper. The sixth man makes the same claim. Together they confer and announce that they’ve been
led into a tropical forest. Meanwhile the crowd is stifling its laughter, knowing that the blind men
have been feeling their way around an elephant.
The point of the story is that no human is omniscient like the crowd but we all, like the blind men, have
only partial knowledge. Sharing this incomplete knowledge makes it more likely that we will establish the
truth, but there is no human guarantee. Reality and its modeling is an elusive concept, since modeling
forms part of the investigation of that reality.
33-4 Handbook of Dynamic System Modeling
Thus we arrive at the final part of the definition, which again stresses the purposes for which the models
are built and used. Though this section has focused on decision making, models are used in management
science for other purposes, too. For example, most police forces operate control rooms and these act as
contact points for members of the public who may phone in to report an incident or to ask for help. In the
UK, each police force is required to meet national standards that specify, for example, the proportion of
calls that are answered within 15 s. If a police force finds that it is not achieving these standards, it might
choose to model the controlroom operations to investigate what is happening and why targets are not being
achieved. That is, models are used to explore the“as is”situation as well as to conduct“what if”experiments.
33.1.2 Dynamic Systems Modeling in Management Science
There are two approaches to dynamic system modeling that find broad use in management science to
support decision making and planning. Each of these is discussed in much more detail later in this chapter,
butaquickoverviewisasfollows:
•
Discrete-event simulation (DES): in which a system to be modeled is treated as a set of discrete
entities (people, machines, vehicles, and orders) that change state from time to time. The states
are discrete: for example a machine may move between states such as busy, idle, under repair, and
warming up. Thus, the states are modeled as discrete attributes of the system entities. The dynamic
behavior of the system is thus the result of the interactions between entities as they change state. The
simulation model consists of sets of rules that define how different entity classes change state, given
particular conditions within the simulation. To build a DES, the modeler must decide which entities
to include and must find some way to represent the logic of their state changes. Most organizational
systems include variable behavior (e.g., the number of calls received per hour at a contact center)
and DES models often use random sampling methods to cope with this variation. In DES models
are usually developed using software known variously as simulators, or visual interactive modeling
systems (VIMSs). Examples include Arena, ProModel, AutoMod, Witness, Simul8, and Micro Saint,
descriptions of which can be found in the annual Proceedings of the Winter Simulation Conference.
•
System dynamics: in which the focus is not on individual entities and their state changes, but rather
on populations of objects and the rules that govern their behavior through time. It is normal to think
in terms of flow rates (e.g., orders received per day) and accumulations (e.g., the order backlog),
often abbreviated as rates and levels. These are used to model the structure of business processes so
as to understand the effect that information feedback has on their behavior. Thus, process structure
is seen as important in system dynamics modeling and it is assumed that behavior follows from
this structure. Most system dynamics models are developed using dedicated VIMS and popular
examples are Stella (also known as IThink), Vensim and Powersim.
33.2 An Approach to Dynamic Systems Modeling in
Management Science
A number of texts, notably Robinson (2004) and Pidd (2004a), provide advice on how to participate in
and manage a simulation modeling project so as to ensure that it adds value. It is important to realize that
a successful simulation project requires more than a set of technical skills—though these are obviously
essential. A successful study is usually based on three different sets of skills, which can all be developed
with experience.
33.2.1 Project Management Skills
Within management science, most projects have a life cycle of their own, beginning with the need to
understand what the client wants or needs and ending either with further work, or with the end of the
current project. Figure 33.1 is a grossly simplified version of this cycle and shows 3 phases, each of which
could, in turn, be regarded as a further cycle of activity.
Dynamic Modeling in Management Science 33-5
Initial negotiation and
project definition
Project management
and control
Project completion
More wor
k
Closure
FIGURE 33.1 Management of a simulation project.
1. Initial negotiation and project definition: in which the terms of reference for the work are discussed
and agreed, usually within some defined budget. It is often very difficult to do this for two reasons.
First, though loath to admit it, most clients do not know precisely what they want from such a study
and therefore cannot define what must be done. This is not because the clients are incompetent
but because there are several ways in which models are used and the actual use may only emerge
after some time. In addition, most clients are not modeling experts and may under-estimate or
over-estimate the work that is needed. It is also true that the modeler is unlikely to be an expert in
managing the system she is studying. Hence, the project definition is something that is negotiated
between two parties with different interests and with partial knowledge.
2. Project management and control: projects rarely run smoothly and slippage against dates and budgets
is highly likely unless the project is properly managed. This requires the project manager, who may
be the analyst engaged in the technical work, to keep in close touch with the client. Disappearing
off to another site for weeks on end is not an ingredient in a recipe for success. Instead, it is normal
to agree a series of milestones for the work and to review progress against them. This may require
considerable interpersonal skills as well as technical ones. Milestones may not be met for very good
reasons, at least from the analyst’s viewpoint. These include a changing view of what is required as
both modeler and client start to realize what is needed. They also include shortages of data, which
were assumed available when the project was defined. Sadly, technical incompetence by the analyst
is another reason for slippage. If there are good reasons for the slippage, then client and project
manager need to revise the milestones as appropriate.
3. Project completion: projects typically end in three ways. The first is that client and analyst agree that
the work has been satisfactorily completed and that there is no need for further work, at least at
this time. The second is that both client and analyst agree that further work is needed, possibly in
refining the same model or in doing other related work. If this happens, it is wisest to manage the
new work as a new project. Third, things may have gone so wrong that the project ends in failure
and this sometimes happens despite great effort and good practice.
33.2.2 Conceptual Modeling Skills
As noted earlier, a management science model is a simplification and abstraction that includes factors
believed to be relevant to some defined purpose. This raisestwoobvious questions: what should be included
and how do we decide this? In answering these questions it is helpful to distinguish between a conceptual
33-6 Handbook of Dynamic System Modeling
model and the implementation of that model. In the case of computer simulation, the conceptual model
is implemented in computer software so that the model may mimic the dynamic behavior of the system
being modeled. There is no widely accepted definition of the term “conceptual model,” so for present
purposes, it is defined as “an external statement of the factors and relationships that should be included
in an implemented model.” As earlier, the reason for stating that this is an external statement is to ensure
that it is open to scrutiny and debate by other people. A purely mental and unexpressed conceptualization
cannot be scrutinized or properly debated by other people.
Used in this sense, a conceptual model is a statement of the elements of a system that are thought
important enough for inclusion in some implemented model. Needless to say, such a conceptual model
will develop through time and is part of a learning cycle in which the modeler develops ideas about the
elements of a system that are important enough to feature in the model. Developing a conceptual model
is rarely straightforward and is an aspect of practice that distinguishes novices from experts. It requires a
process of investigation in which the modeler tries to tease out what the client requires in the model while
trying to understand the main features and behavior of the system to be modeled.
Consider, for example, the task of developing a simulation of a call center. It would be a strange
simulation model of this that did not include some aspects of the behavior of the customers who phone
the call center. However, which of these aspects should be included and in what detail? For example, are
all callers to be treated as if from the same population, or should they be classified into subgroups? This
will depend on the nature of those callers but also on the purpose of the simulation project. The overall
population of callers may include some who need advice and others who wish to purchase a product. If
the main aim is to establish an appropriate staffing level for current demand it may not be important to
distinguish between them. However, if the aim is to consider what would happen if the business generated
more new customers, then it is probably important to distinguish between them. Similarly, in what detail
should the behavior of the call center operatives be modeled? Is it enough to develop a model based on
probability distributions of call durations, or is it important to model worsening performance toward the
end of a shift (if this occurs)?
Hence, a conceptual model must capture the important elements of the system to be modeled in a form
that is independent of the computer software used for the model’s final implementation. There are several
approaches that can be used and one, activity cycle diagrams, is discussed later in the chapter.
33.2.3 Technical Skills
Developing and using dynamic models in management science requires the modeler to develop skills in
two areas of work: computing and statistical methods. However, this does not mean that the modeler must
be a professional computer scientist or statistician. It was once true that dynamic models could only be
implemented on a computer if the modeler were a skilled programmer or had access to someone with
those skills. Hence, early books on computer simulation provided specific advice about how particular
programming languages could be used. Indeed, the very earliest such simulation models were implemented
before languages such as FORTRAN (let alone Visual Basic or Java) were in widespread use. Hence, the
early modelers had to learn how to program a computer in binary, machine code or assembler. Thankfully,
those days have long gone.
Most simulation applications in management science are implemented using VIMSs in which the model
is developed interactively by selecting objects from a palette and linking them on-screen. To do this requires
the usual skills with a PC that children acquire at home or at school. Hence, the vendors of these systems
are fond of implying that using their products requires no skill beyond this, but it is not true. As will
be clear later, using a VIMS almost always requires the modeler to write some code, though not a full
program. Some training and experience in computer programming is therefore desirable.
The dynamic systems modeled in management science are rarely deterministic: that is, they are not
wholly predictable. A business that can be certain of the precise demand for its products, with customers
that always do the same things, and whose production technologies are utterly reliable is very fortunate
indeed. Most organizational systems exhibit considerable variation. Some of this can be understood by
Dynamic Modeling in Management Science 33-7
analyzing root causes but some can only be understood by expressing it in statistical terms. Hence, we
might conclude that the number of calls per hour arriving at a call center can be modeled as a Poisson
distribution. Therefore, though we can never say how many calls will arrive in the next 60 min, we can
have some idea of the likely number if we apply correct statistical principles. Modelers must develop skills
in data analysis (to fit distributions to observed data sets), statistical inference (to see if observed variation
is significant), and in probability theory to underpin the other two areas.
33.3 Discrete Event Simulation
Within management science, two types of simulation modeling find widespread use: DES and system
dynamics; the latter is considered later in the chapter. There are many excellent introductions to DES and
the annual Winter Simulation Conference (www.wintersim.org) includes a range of tutorials, some aimed
at beginners and others at people who wish to further develop their skills and knowledge. The approach
taken here is based on the lengthier coverage in Pidd (2004a). Perhaps the most thorough coverage of DES
is to be found in Law and Kelton (2000). Other chapters in this book covering DEVS, Event Graphs, and
ARENA also provide valuable insights into the methods and practice of DES.
33.3.1 What Types of Problem are Well Suited to Discrete-Event
Simulation?
Many applications of DES involve queuing systems of one kind or another. The queuing structure may
be obvious, as in a queue of jobs waiting to be processed on a machine, or in a stack of aircraft waiting
for landing space at an airport or of phone calls arriving at a call center. As time progresses, queues build
up or are reduced as demand varies and as service patterns change. Mathematical queuing theory (see
Hlynka, 2004, for a survey of available books) can be used to model some simpler queuing systems, but
is ineffective when demand is nonstationary and when customers baulk (refuse to join a queue because
it looks too long) or renege (enter a queue but leave it before being served)—which is common in most
real applications. Sometimes, the queuing structure may be less obvious, as in the deployment of fire
appliances in a large city. In this case, the customers are the fires needing attention and the servers are the
fire-fighters together with their associated equipment.
DES is worth considering for systems with the following characteristics:
•
They are dynamic: that is they display distinctive behavior which is known to vary through time.
This variation might be due to factors which are not well understood and may therefore be amenable
to statistical analysis—for example, the apparently random failures of equipment. Or they might be
due to well-understood relationships which can be captured in equations—for example, the flight
of a missile through a nonturbulent atmosphere.
•
They are interactive: that is, the system is made up of a number of components that interact with
one another and this interaction produces the distinctive behavior of the system. For example, the
observed behavior of aircraft under air traffic control will be due to the performance characteristics
of the individual aircraft, the intervention of the air traffic controllers, the weather, and any routing
problems. This mix of factors will be varying all the time and their interaction will produce the
observed behavior of the air traffic.
•
They are complicated: that is, there are many objects in the system of interest, and their individual
dynamics need careful consideration and analysis.
Despite the availability of excellent computer software for developing DES models, it is still true that
building, testing, and using such a model is surprisingly time-consuming. Hence, it is sometimes better
to try a very approximate mathematical model before resorting to simulation. If a discrete-event model is
being considered, then a number of characteristics are likely to be present in the system to be modeled.
33-8 Handbook of Dynamic System Modeling
•
Individual entities: the behavior of the system comes from the behavior of individual objects of
interest, usually known as entities. The simulation program tracks the behavior of each of these
entities through simulated time and will be minutely concerned with their individual logics. The
entities could be truly individual objects (e.g., machines, people, and vehicles) or could be a group
of such objects (e.g., a crowd, a machine shop, and a convoy of vehicles).
•
Discrete events: each entity’s behavior is modeled as a sequence of events, where an event is a point
of time at which the entity changes state. For example, a customer in a shop may arrive (an event),
may wait for a while, their service may begin (an event), their service will end (an event), and so on.
The task of the modeler is thus to capture the distinctive logic of each of these events (e.g., what
conditions must hold if a begin service event is to occur?). Though real-time flows smoothly, the
flow of simulation time in a DES is not smooth, as it moves from event time to event time and these
intervals may be irregular.
•
Stochastic behavior: the interval between successive events is not always predictable, for example the
time taken to serve a number of customers in a shop will vary. There may sometimes be obvious
and entirely predictable reasons for this (the server may speed up as the queue of waiting customers
increases) or there may be no obvious reason to explain things. In the latter case, the varying
intervals between events could be represented in a probability distribution and modeled by taking
samples from that distribution.
33.3.2 Common Application Areas for Discrete-Event Simulation in
Management Science
There are many different application areas for DES and surveys of the use of MS/OR methods usually place
simulation as one of the top three most frequently used approaches. The Winter Simulation Conference
(ref) is a fertile hunting ground for those seeking case studies of successful applications.
The last 20 years have seen increased competition between manufacturing companies and this has led
to a range of strategies including cost reduction and product differentiation. Both of these have relied
on increased automation, which in turn depends on large-scale investments. It clearly makes sense to
ensure that the investment is a wise one before making it and DES is often used for this purpose. The
idea is to simulate the operation of a manufacturing system before installing it or to simulate an existing
manufacturing system to seek performance improvements.
Many of the early simulation applications within MS/OR were in primary industries such as coal and
steel. Since then, simulation has been used in many industries including food manufacture, microelectron-
ics, aerospace, and automobile assembly. The latter is especially significant, since some of the commonly
used VIMS (most notably Witness) were developed within the automotive industry, which is where they
find most of their users. Hence, the terminology of many VIMS is geared toward that application area,
using terms like work station, conveyor, and cycle time.
A second major application area for DES is health care. Worldwide expenditure on health care has been
rising steeply in recent years. Current estimates suggest that health care expenditure in the USA amounts to
about 17% of GDP, of which about 50% is funded through taxation. In the UK, where most health care is
funded through taxation, it will soon account for about 10% of GDP. Why these large sums? First, because
people’s expectations are rising and, second, because of technological developments. Given the scale of
this activity and the risk of adverse outcomes from medical interventions, it is clear that improvements in
health care delivery are needed. Simulation methods have been successfully used in many areas of health
care. Example include: models of disease transmission for AIDS and hepatitis; models of treatments and
intervention for glaucoma and cardiac shunts; and models of hospital operations such as clinics and
emergency departments. Despite this level of activity there are curiously few VIMS dedicated to health
care modeling.
A third major area can be summarized under the heading of business process improvement; once
known, rather unfortunately, as business process re-engineering (BPR). Many organizations have tried
to streamline their business processes so as to make efficiency gains and, at the same time, to make
Dynamic Modeling in Management Science 33-9
their operations increasingly customer focused. For example, buying car insurance 20 years ago was a
long, drawn-out process involving forms completed by hand, visits to agents, repeated correspondence,
and laborious comparisons of quotations. Now we take it for granted that we can phone an insurance
company and arrange the insurance in a few minutes in a single conversation. Alternatively, we can use
price comparison Web sites and then enact the purchase using Web forms. A transaction that once took
a couple of weeks, end-to-end, now takes a few minutes. A similar story applies to the purchase of airline
tickets. These customer-focused business processes depend on IT systems that enable prices to be quickly
generated, credit standing to be quickly checked, and transactions to be completed with the minimum of
fuss. However, even the best IT in the world is a waste of time unless the processes are properly designed
and managed. Hence, computer simulation models are commonly used in the design and improvement
of call centers, workflow management systems, and document production systems.
A fourth major application area is transport and physical logistics—the movement of people and goods
and the associated systems that support this. Airlines and airports have long been major users of simulation
models to design and improve terminal buildings and baggage systems. Likewise, options for air traffic
control are usually simulated before any attempt at implementation, it being much safer if a simulated
aircraft runs out of fuel in a simulated flight. Physical distribution and supply chain management are two
more major application areas for computer simulation in transport and physical logistics. Large retailers
commonly own regional distribution centers to which suppliers deliver goods and from which sorted
supplies are sent to retail outlets. These centers are large complex operations that must run in a highly
synchronized manner if supplies are to reach the retail stores in time to meet customer demand. Simulation
methods allow supply chain managers to see how the centers will operate and to experiment with policies
that will enable proper synchronization.
Finally, and possibly the largest application area of all, is defence. War gaming and battle planning
have long been a feature of military training and the increasing expense of high tech battle equipment
makes simulation an essential part of most military operations. Applications are not restricted to gaming,
however, and range from studies equipment, of logistics operations, of deployment options through to
battle simulations. Not surprisingly, the majority of defence simulations are not reported in the open
literature.
33.3.3 Discrete-Event Simulation Terminology
Some writers have tried to develop precise definitions of the terms used in DES modeling, notably Zeigler
(1976) whose concept of DEVS is discussed in Chapter 6 of this book. However, the use of terms in the
DES community is not always consistent. This section defines terms as they are normally used. The first set
of terms refers to the objects within the system and the second set refers to their state changes and activity.
When referring to the objects in a DES model it is normal to divide them into two main types.
1. Simulation entities: These are the individual elements of the system that are being simulated and
whose behavior is being explicitly tracked. Examples might include machines in a factory, patients
in a hospital, or aircraft at an airport. When the simulation is implemented in computer software,
the computer program maintains information about each entity and therefore each one can be
individually identified. As an entity changes state in the simulation, the computer program keeps
track of these state changes. The overall system state is a result of the interaction of the simulation
entities and resources (see below) and the number of entities in a model gives some idea of how fast
it will run. Simulation entities are, conceptually at least, divided into classes which display similar
behavior. Examples might include a class of aircraft, of customers of doctors, or whatever. Taken
together, the number of entities and the number of classes partially determine the complexity of a
DES model.
2. Simulation resources: These are also system elements but they are not modeled individually. Instead,
they are treated as countable items whose individual behavior is not tracked in the computer
program. Examples might be the number of passengers waiting at a bus stop or the number of
boxes of a product available in a warehouse. Thus, a resource consists of identical items and the