Harrell−Ghosh−Bowden: I. Study Chapters 2.

System Dynamics © The McGraw−Hill

Simulation Using Companies, 2004
ProModel, Second Edition

C H A P T E R

2 SYSTEM DYNAMICS

“A fool with a tool is still a fool.”

—Unknown

2.1 Introduction
Knowing how to do simulation doesn’t make someone a good systems designer
any more than knowing how to use a CAD system makes one a good product de-
signer. Simulation is a tool that is useful only if one understands the nature of the
problem to be solved. It is designed to help solve systemic problems that are op-
erational in nature. Simulation exercises fail to produce useful results more often
because of a lack of understanding of system dynamics than a lack of knowing
how to use the simulation software. The challenge is in understanding how the
system operates, knowing what you want to achieve with the system, and being
able to identify key leverage points for best achieving desired objectives. To
illustrate the nature of this challenge, consider the following actual scenario:
The pipe mill for the XYZ Steel Corporation was an important profit center, turning
steel slabs selling for under $200/ton into a product with virtually unlimited demand
selling for well over $450/ton. The mill took coils of steel of the proper thickness and
width through a series of machines that trimmed the edges, bent the steel into a
cylinder, welded the seam, and cut the resulting pipe into appropriate lengths, all on a
continuously running line. The line was even designed to weld the end of one coil to
the beginning of the next one “on the fly,” allowing the line to run continually for days
on end.
Unfortunately the mill was able to run only about 50 percent of its theoretical ca-
pacity over the long term, costing the company tens of millions of dollars a year in lost
revenue. In an effort to improve the mill’s productivity, management studied each step
in the process. It was fairly easy to find the slowest step in the line, but additional
study showed that only a small percentage of lost production was due to problems at
this “bottleneck” operation. Sometimes a step upstream from the bottleneck would

23
Harrell−Ghosh−Bowden: I. Study Chapters 2. System Dynamics © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

24 Part I Study Chapters

have a problem, causing the bottleneck to run out of work, or a downstream step
would go down temporarily, causing work to back up and stop the bottleneck. Some-
times the bottleneck would get so far behind that there was no place to put incoming,
newly made pipe. In this case the workers would stop the entire pipe-making process
until the bottleneck was able to catch up. Often the bottleneck would then be idle wait-
ing until the newly started line was functioning properly again and the new pipe had a
chance to reach it. Sometimes problems at the bottleneck were actually caused by im-
proper work at a previous location.
In short, there was no single cause for the poor productivity seen at this plant.
Rather, several separate causes all contributed to the problem in complex ways. Man-
agement was at a loss to know which of several possible improvements (additional or
faster capacity at the bottleneck operation, additional storage space between stations,
better rules for when to shut down and start up the pipe-forming section of the mill,
better quality control, or better training at certain critical locations) would have the
most impact for the least cost. Yet the poor performance of the mill was costing enor-
mous amounts of money. Management was under pressure to do something, but what
should it be?

This example illustrates the nature and difficulty of the decisions that an
operations manager faces. Managers need to make decisions that are the “best” in
some sense. To do so, however, requires that they have clearly defined goals and
understand the system well enough to identify cause-and-effect relationships.
While every system is different, just as every product design is different,
the basic elements and types of relationships are the same. Knowing how the
elements of a system interact and how overall performance can be improved are
essential to the effective use of simulation. This chapter reviews basic system
dynamics and answers the following questions:
• What is a system?
• What are the elements of a system?
• What makes systems so complex?
• What are useful system metrics?
• What is a systems approach to systems planning?
• How do traditional systems analysis techniques compare with simulation?

2.2 System Definition

We live in a society that is composed of complex, human-made systems that
we depend on for our safety, convenience, and livelihood. Routinely we rely on
transportation, health care, production, and distribution systems to provide needed
goods and services. Furthermore, we place high demands on the quality, conve-
nience, timeliness, and cost of the goods and services that are provided by these
systems. Remember the last time you were caught in a traffic jam, or waited for
what seemed like an eternity in a restaurant or doctor’s office? Contrast that ex-
perience with the satisfaction that comes when you find a store that sells quality
merchandise at discount prices or when you locate a health care organization that
Harrell−Ghosh−Bowden: I. Study Chapters 2. System Dynamics © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

Chapter 2 System Dynamics 25

provides prompt and professional service. The difference is between a system that
has been well designed and operates smoothly, and one that is poorly planned and
managed.
A system, as used here, is defined as a collection of elements that function
together to achieve a desired goal (Blanchard 1991). Key points in this definition
include the fact that (1) a system consists of multiple elements, (2) these elements
are interrelated and work in cooperation, and (3) a system exists for the purpose
of achieving specific objectives. Examples of systems are traffic systems, political
systems, economic systems, manufacturing systems, and service systems. Our
main focus will be on manufacturing and service systems that process materials,
information, and people.
Manufacturing systems can be small job shops and machining cells or large
production facilities and assembly lines. Warehousing and distribution as well as
entire supply chain systems will be included in our discussions of manufacturing
systems. Service systems cover a wide variety of systems including health care
facilities, call centers, amusement parks, public transportation systems, restau-
rants, banks, and so forth.
Both manufacturing and service systems may be termed processing systems
because they process items through a series of activities. In a manufacturing sys-
tem, raw materials are transformed into finished products. For example, a bicycle
manufacturer starts with tube stock that is then cut, welded, and painted to pro-
duce bicycle frames. In service systems, customers enter with some service need
and depart as serviced (and, we hope, satisfied) customers. In a hospital emer-
gency room, for example, nurses, doctors, and other staff personnel admit and
treat incoming patients who may undergo tests and possibly even surgical proce-
dures before finally being released. Processing systems are artificial (they are
human-made), dynamic (elements interact over time), and usually stochastic (they
exhibit random behavior).

2.3 System Elements

From a simulation perspective, a system can be said to consist of entities, activi-
ties, resources, and controls (see Figure 2.1). These elements define the who,
what, where, when, and how of entity processing. This model for describing a

FIGURE 2.1
Incoming entities Outgoing entities
Elements of a system. Activities

Resources Controls

System
Harrell−Ghosh−Bowden: I. Study Chapters 2. System Dynamics © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

26 Part I Study Chapters

system corresponds closely to the well-established ICAM definition (IDEF)

process model developed by the defense industry (ICAM stands for an early Air
Force program in integrated computer-aided manufacturing). The IDEF modeling
paradigm views a system as consisting of inputs and outputs (that is, entities), ac-
tivities, mechanisms (that is, resources), and controls.

2.3.1 Entities
Entities are the items processed through the system such as products, customers,
and documents. Different entities may have unique characteristics such as cost,
shape, priority, quality, or condition. Entities may be further subdivided into the
following types:
• Human or animate (customers, patients, etc.).
• Inanimate (parts, documents, bins, etc.).
• Intangible (calls, electronic mail, etc.).
For most manufacturing and service systems, the entities are discrete items.
This is the case for discrete part manufacturing and is certainly the case for nearly
all service systems that process customers, documents, and others. For some pro-
duction systems, called continuous systems, a nondiscrete substance is processed
rather than discrete entities. Examples of continuous systems are oil refineries and
paper mills.

2.3.2 Activities
Activities are the tasks performed in the system that are either directly or
indirectly involved in the processing of entities. Examples of activities include
servicing a customer, cutting a part on a machine, or repairing a piece of equip-
ment. Activities usually consume time and often involve the use of resources.
Activities may be classified as
• Entity processing (check-in, treatment, inspection, fabrication, etc.).
• Entity and resource movement (forklift travel, riding in an elevator, etc.).
• Resource adjustments, maintenance, and repairs (machine setups, copy
machine repair, etc.).

2.3.3 Resources
Resources are the means by which activities are performed. They provide the
supporting facilities, equipment, and personnel for carrying out activities. While
resources facilitate entity processing, inadequate resources can constrain process-
ing by limiting the rate at which processing can take place. Resources have
characteristics such as capacity, speed, cycle time, and reliability. Like entities,
resources can be categorized as
• Human or animate (operators, doctors, maintenance personnel, etc.).
• Inanimate (equipment, tooling, floor space, etc.).
• Intangible (information, electrical power, etc.).
Harrell−Ghosh−Bowden: I. Study Chapters 2. System Dynamics © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

Chapter 2 System Dynamics 27

Resources can also be classified as being dedicated or shared, permanent or

consumable, and mobile or stationary.

2.3.4 Controls
Controls dictate how, when, and where activities are performed. Controls impose
order on the system. At the highest level, controls consist of schedules, plans, and
policies. At the lowest level, controls take the form of written procedures and ma-
chine control logic. At all levels, controls provide the information and decision
logic for how the system should operate. Examples of controls include
• Routing sequences.
• Production plans.
• Work schedules.
• Task prioritization.
• Control software.
• Instruction sheets.

2.4 System Complexity

Elements of a system operate in concert with one another in ways that often result
in complex interactions. The word complex comes from the Latin complexus,
meaning entwined or connected together. Unfortunately, unaided human intuition
is not very good at analyzing and understanding complex systems. Economist
Herbert Simon called this inability of the human mind to grasp real-world
complexity “the principle of bounded rationality.” This principle states that “the
capacity of the human mind for formulating and solving complex problems is
very small compared with the size of the problem whose solution is required for
objectively rational behavior in the real world, or even for a reasonable approxi-
mation to such objective rationality” (Simon 1957).

Bounded rationality—our limited ability to grasp

real-world complexity.

While the sheer number of elements in a system can stagger the mind (the
number of different entities, activities, resources, and controls can easily exceed
100), the interactions of these elements are what make systems so complex and
Harrell−Ghosh−Bowden: I. Study Chapters 2. System Dynamics © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

28 Part I Study Chapters

difficult to analyze. System complexity is primarily a function of the following

two factors:
1. Interdependencies between elements so that each element affects other
elements.
2. Variability in element behavior that produces uncertainty.

Interdependencies Variability Complexity

These two factors characterize virtually all human-made systems and make
system behavior difficult to analyze and predict. As shown in Figure 2.2, the de-
gree of analytical difficulty increases exponentially as the number of interdepen-
dencies and random variables increases.

2.4.1 Interdependencies
Interdependencies cause the behavior of one element to affect other elements in
the system. For example, if a machine breaks down, repair personnel are put into
action while downstream operations become idle for lack of parts. Upstream
operations may even be forced to shut down due to a logjam in the entity flow
causing a blockage of activities. Another place where this chain reaction or
domino effect manifests itself is in situations where resources are shared between

FIGURE 2.2
Analytical difficulty
Degree of analytical

as a function of the
number of
difficulty

interdependencies and
random variables.

Number of interdependencies
and random variables
Harrell−Ghosh−Bowden: I. Study Chapters 2. System Dynamics © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

Chapter 2 System Dynamics 29

two or more activities. A doctor treating one patient, for example, may be unable
to immediately respond to another patient needing his or her attention. This delay
in response may also set other forces in motion.
It should be clear that the complexity of a system has less to do with the
number of elements in the system than with the number of interdependent rela-
tionships. Even interdependent relationships can vary in degree, causing more or
less impact on overall system behavior. System interdependency may be either
tight or loose depending on how closely elements are linked. Elements that are
tightly coupled have a greater impact on system operation and performance than
elements that are only loosely connected. When an element such as a worker or
machine is delayed in a tightly coupled system, the impact is immediately felt by
other elements in the system and the entire process may be brought to a screech-
ing halt.
In a loosely coupled system, activities have only a minor, and often delayed,
impact on other elements in the system. Systems guru Peter Senge (1990) notes
that for many systems, “Cause and effect are not closely related in time and
space.” Sometimes the distance in time and space between cause-and-effect rela-
tionships becomes quite sizable. If enough reserve inventory has been stockpiled,
a truckers’ strike cutting off the delivery of raw materials to a transmission plant
in one part of the world may not affect automobile assembly in another part of the
world for weeks. Cause-and-effect relationships are like a ripple of water that di-
minishes in impact as the distance in time and space increases.
Obviously, the preferred approach to dealing with interdependencies is to
eliminate them altogether. Unfortunately, this is not entirely possible for most
situations and actually defeats the purpose of having systems in the first place.
The whole idea of a system is to achieve a synergy that otherwise would be un-
attainable if every component were to function in complete isolation. Several
methods are used to decouple system elements or at least isolate their influence
so disruptions are not felt so easily. These include providing buffer inventories,
implementing redundant or backup measures, and dedicating resources to sin-
gle tasks. The downside to these mitigating techniques is that they often lead to
excessive inventories and underutilized resources. The point to be made here
is that interdependencies, though they may be minimized somewhat, are sim-
ply a fact of life and are best dealt with through effective coordination and
management.

2.4.2 Variability
Variability is a characteristic inherent in any system involving humans and
machinery. Uncertainty in supplier deliveries, random equipment failures, unpre-
dictable absenteeism, and fluctuating demand all combine to create havoc in plan-
ning system operations. Variability compounds the already unpredictable effect of
interdependencies, making systems even more complex and unpredictable. Vari-
ability propagates in a system so that “highly variable outputs from one worksta-
tion become highly variable inputs to another” (Hopp and Spearman 2000).
Harrell−Ghosh−Bowden: I. Study Chapters 2. System Dynamics © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

30 Part I Study Chapters

TABLE 2.1 Examples of System Variability

Type of Variability Examples

Activity times Operation times, repair times, setup times, move times
Decisions To accept or reject a part, where to direct a particular customer, which
task to perform next
Quantities Lot sizes, arrival quantities, number of workers absent
Event intervals Time between arrivals, time between equipment failures
Attributes Customer preference, part size, skill level

Table 2.1 identifies the types of random variability that are typical of most manu-
facturing and service systems.
The tendency in systems planning is to ignore variability and calculate sys-
tem capacity and performance based on average values. Many commercial sched-
uling packages such as MRP (material requirements planning) software work this
way. Ignoring variability distorts the true picture and leads to inaccurate perfor-
mance predictions. Designing systems based on average requirements is like
deciding whether to wear a coat based on the average annual temperature or pre-
scribing the same eyeglasses for everyone based on average eyesight. Adults have
been known to drown in water that was only four feet deep—on the average!
Wherever variability occurs, an attempt should be made to describe the nature or
pattern of the variability and assess the range of the impact that variability might
have on system performance.
Perhaps the most illustrative example of the impact that variability can have
on system behavior is the simple situation where entities enter into a single queue
to wait for a single server. An example of this might be customers lining up in
front of an ATM. Suppose that the time between customer arrivals is exponen-
tially distributed with an average time of one minute and that they take an average
time of one minute, exponentially distributed, to transact their business. In queu-
ing theory, this is called an M/M/1 queuing system. If we calculate system per-
formance based solely on average time, there will never be any customers waiting
in the queue. Every minute that a customer arrives the previous customer finishes
his or her transaction. Now if we calculate the number of customers waiting in
line, taking into account the variation, we will discover that the waiting line grows
to infinity (the technical term is that the system “explodes”). Who would guess
that in a situation involving only one interdependent relationship that variation
alone would make the difference between zero items waiting in a queue and an in-
finite number in the queue?
By all means, variability should be reduced and even eliminated wherever
possible. System planning is much easier if you don’t have to contend with it.
Where it is inevitable, however, simulation can help predict the impact it will have
on system performance. Likewise, simulation can help identify the degree of
improvement that can be realized if variability is reduced or even eliminated. For
Harrell−Ghosh−Bowden: I. Study Chapters 2. System Dynamics © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

Chapter 2 System Dynamics 31

example, it can tell you how much reduction in overall flow time and flow time
variation can be achieved if operation time variation can be reduced by, say,
20 percent.

2.5 System Performance Metrics

Metrics are measures used to assess the performance of a system. At the highest
level of an organization or business, metrics measure overall performance in
terms of profits, revenues, costs relative to budget, return on assets, and so on.
These metrics are typically financial in nature and show bottom-line performance.
Unfortunately, such metrics are inherently lagging, disguise low-level operational
performance, and are reported only periodically. From an operational standpoint,
it is more beneficial to track such factors as time, quality, quantity, efficiency, and
utilization. These operational metrics reflect immediate activity and are directly
controllable. They also drive the higher financially related metrics. Key opera-
tional metrics that describe the effectiveness and efficiency of manufacturing and
service systems include the following:
• Flow time—the average time it takes for an item or customer to be
processed through the system. Synonyms include cycle time, throughput
time, and manufacturing lead time. For order fulfillment systems, flow
time may also be viewed as customer response time or turnaround time.
A closely related term in manufacturing is makespan, which is the time
to process a given set of jobs. Flow time can be shortened by reducing
activity times that contribute to flow time such as setup, move, operation,
and inspection time. It can also be reduced by decreasing work-in-process
or average number of entities in the system. Since over 80 percent of
cycle time is often spent waiting in storage or queues, elimination of
buffers tends to produce the greatest reduction in cycle time. Another
solution is to add more resources, but this can be costly.
• Utilization—the percentage of scheduled time that personnel, equipment,
and other resources are in productive use. If a resource is not being
utilized, it may be because it is idle, blocked, or down. To increase
productive utilization, you can increase the demand on the resource or
reduce resource count or capacity. It also helps to balance work loads. In a
system with high variability in activity times, it is difficult to achieve high
utilization of resources. Job shops, for example, tend to have low machine
utilization. Increasing utilization for the sake of utilization is not a good
objective. Increasing the utilization of nonbottleneck resources, for
example, often only creates excessive inventories without creating
additional throughput.
• Value-added time—the amount of time material, customers, and so forth
spend actually receiving value, where value is defined as anything for
which the customer is willing to pay. From an operational standpoint,
Harrell−Ghosh−Bowden: I. Study Chapters 2. System Dynamics © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

32 Part I Study Chapters

value-added time is considered the same as processing time or time spent

actually undergoing some physical transformation or servicing. Inspection
time and waiting time are considered non-value-added time.
• Waiting time—the amount of time that material, customers, and so on
spend waiting to be processed. Waiting time is by far the greatest
component of non-value-added time. Waiting time can be decreased by
reducing the number of items (such as customers or inventory levels) in
the system. Reducing variation and interdependencies in the system can
also reduce waiting times. Additional resources can always be added, but
the trade-off between the cost of adding the resources and the savings of
reduced waiting time needs to be evaluated.
• Flow rate—the number of items produced or customers serviced per unit
of time (such as parts or customers per hour). Synonyms include
production rate, processing rate, or throughput rate. Flow rate can be
increased by better management and utilization of resources, especially
the limiting or bottleneck resource. This is done by ensuring that the
bottleneck operation or resource is never starved or blocked. Once system
throughput matches the bottleneck throughput, additional processing or
throughput capacity can be achieved by speeding up the bottleneck
operation, reducing downtimes and setup times at the bottleneck operation,
adding more resources to the bottleneck operation, or off-loading work
from the bottleneck operation.
• Inventory or queue levels—the number of items or customers in storage
or waiting areas. It is desirable to keep queue levels to a minimum while
still achieving target throughput and response time requirements. Where
queue levels fluctuate, it is sometimes desirable to control the minimum
or maximum queue level. Queuing occurs when resources are unavailable
when needed. Inventory or queue levels can be controlled either by
balancing flow or by restricting production at nonbottleneck operations.
JIT (just-in-time) production is one way to control inventory levels.
• Yield—from a production standpoint, the percentage of products
completed that conform to product specifications as a percentage of the
total number of products that entered the system as raw materials. If 95
out of 100 items are nondefective, the yield is 95 percent. Yield can also
be measured by its complement—reject or scrap rate.
• Customer responsiveness—the ability of the system to deliver products in
a timely fashion to minimize customer waiting time. It might be measured
as fill rate, which is the number of customer orders that can be filled
immediately from inventory. In minimizing job lateness, it may be
desirable to minimize the overall late time, minimize the number or
percentage of jobs that are late, or minimize the maximum tardiness of
jobs. In make-to-stock operations, customer responsiveness can be
assured by maintaining adequate inventory levels. In make-to-order,
customer responsiveness is improved by lowering inventory levels so that
cycle times can be reduced.
Harrell−Ghosh−Bowden: I. Study Chapters 2. System Dynamics © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

Chapter 2 System Dynamics 33

• Variance—the degree of fluctuation that can and often does occur in any
of the preceding metrics. Variance introduces uncertainty, and therefore
risk, in achieving desired performance goals. Manufacturers and service
providers are often interested in reducing variance in delivery and service
times. For example, cycle times and throughput rates are going to have
some variance associated with them. Variance is reduced by controlling
activity times, improving resource reliability, and adhering to schedules.
These metrics can be given for the entire system, or they can be broken down by
individual resource, entity type, or some other characteristic. By relating these
metrics to other factors, additional meaningful metrics can be derived that are
useful for benchmarking or other comparative analysis. Typical relational metrics
include minimum theoretical flow time divided by actual flow time (flow time
efficiency), cost per unit produced (unit cost), annual inventory sold divided by
average inventory (inventory turns or turnover ratio), or units produced per cost or
labor input (productivity).

2.6 System Variables

Designing a new system or improving an existing system requires more than sim-
ply identifying the elements and performance goals of the system. It requires an
understanding of how system elements affect each other and overall performance
objectives. To comprehend these relationships, you must understand three types
of system variables:
1. Decision variables
2. Response variables
3. State variables

2.6.1 Decision Variables

Decision variables (also called input factors in SimRunner) are sometimes re-
ferred to as the independent variables in an experiment. Changing the values of a
system’s independent variables affects the behavior of the system. Independent
variables may be either controllable or uncontrollable depending on whether the
experimenter is able to manipulate them. An example of a controllable variable is
the number of operators to assign to a production line or whether to work one or
two shifts. Controllable variables are called decision variables because the deci-
sion maker (experimenter) controls the values of the variables. An uncontrollable
variable might be the time to service a customer or the reject rate of an operation.
When defining the system, controllable variables are the information about the
system that is more prescriptive than descriptive (see section 2.9.3).
Obviously, all independent variables in an experiment are ultimately
controllable—but at a cost. The important point here is that some variables are
easier to change than others. When conducting experiments, the final solution is
Harrell−Ghosh−Bowden: I. Study Chapters 2. System Dynamics © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

34 Part I Study Chapters

often based on whether the cost to implement a change produces a higher return
in performance.

2.6.2 Response Variables

Response variables (sometimes called performance or output variables) measure
the performance of the system in response to particular decision variable settings.
A response variable might be the number of entities processed for a given period,
the average utilization of a resource, or any of the other system performance met-
rics described in section 2.5.
In an experiment, the response variable is the dependent variable, which de-
pends on the particular value settings of the independent variables. The experi-
menter doesn’t manipulate dependent variables, only independent or decision
variables. Obviously, the goal in systems planning is to find the right values or set-
tings of the decision variables that give the desired response values.

2.6.3 State Variables

State variables indicate the status of the system at any specific point in time. Ex-
amples of state variables are the current number of entities waiting to be
processed or the current status (busy, idle, down) of a particular resource. Re-
sponse variables are often summaries of state variable changes over time. For ex-
ample, the individual times that a machine is in a busy state can be summed over
a particular period and divided by the total available time to report the machine
utilization for that period.
State variables are dependent variables like response variables in that they
depend on the setting of the independent variables. State variables are often ig-
nored in experiments since they are not directly controlled like decision variables
and are not of as much interest as the summary behavior reported by response
variables.
Sometimes reference is made to the state of a system as though a system it-
self can be in a particular state such as busy or idle. The state of a system actually
consists of “that collection of variables necessary to describe a system at a partic-
ular time, relative to the objectives of the study” (Law and Kelton 2000). If we
study the flow of customers in a bank, for example, the state of the bank for a
given point in time would include the current number of customers in the bank,
the current status of each teller (busy, idle, or whatever), and perhaps the time that
each customer has been in the system thus far.

2.7 System Optimization

Finding the right setting for decision variables that best meets performance
objectives is called optimization. Specifically, optimization seeks the best com-
bination of decision variable values that either minimizes or maximizes some
objective function such as costs or profits. An objective function is simply a
Harrell−Ghosh−Bowden: I. Study Chapters 2. System Dynamics © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

Chapter 2 System Dynamics 35

response variable of the system. A typical objective in an optimization problem for

a manufacturing or service system might be minimizing costs or maximizing flow
rate. For example, we might be interested in finding the optimum number of per-
sonnel for staffing a customer support activity that minimizes costs yet handles the
call volume. In a manufacturing concern, we might be interested in maximizing
the throughput that can be achieved for a given system configuration. Optimization
problems often include constraints, limits to the values that the decision variables
can take on. For example, in finding the optimum speed of a conveyor such that
production cost is minimized, there would undoubtedly be physical limits to how
slow or fast the conveyor can operate. Constraints can also apply to response vari-
ables. An example of this might be an objective to maximize throughput but sub-
ject to the constraint that average waiting time cannot exceed 15 minutes.
In some instances, we may find ourselves trying to achieve conflicting
objectives. For example, minimizing production or service costs often conflicts
with minimizing waiting costs. In system optimization, one must be careful to
weigh priorities and make sure the right objective function is driving the deci-
sions. If, for example, the goal is to minimize production or service costs, the
obvious solution is to maintain only a sufficient workforce to meet processing
requirements. Unfortunately, in manufacturing systems this builds up work-in-
process and results in high inventory carrying costs. In service systems, long
queues result in long waiting times, hence dissatisfied customers. At the other
extreme, one might feel that reducing inventory or waiting costs should be the
overriding goal and, therefore, decide to employ more than an adequate number
of resources so that work-in-process or customer waiting time is virtually elimi-
nated. It should be obvious that there is a point at which the cost of adding another
resource can no longer be justified by the diminishing incremental savings in
waiting costs that are realized. For this reason, it is generally conceded that a
better strategy is to find the right trade-off or balance between the number of
resources and waiting times so that the total cost is minimized (see Figure 2.3).

FIGURE 2.3
Cost curves showing
optimum number of
resources to minimize
total cost.

Total cost
Optimum Resource costs
Cost

Waiting costs

Number of resources
Harrell−Ghosh−Bowden: I. Study Chapters 2. System Dynamics © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

36 Part I Study Chapters

As shown in Figure 2.3, the number of resources at which the sum of the
resource costs and waiting costs is at a minimum is the optimum number of
resources to have. It also becomes the optimum acceptable waiting time.
In systems design, arriving at an optimum system design is not always
realistic, given the almost endless configurations that are sometimes possible and
limited time that is available. From a practical standpoint, the best that can be
expected is a near optimum solution that gets us close enough to our objective,
given the time constraints for making the decision.

2.8 The Systems Approach

Due to departmentalization and specialization, decisions in the real world are often
made without regard to overall system performance. With everyone busy minding
his or her own area of responsibility, often no one is paying attention to the big
picture. One manager in a large manufacturing corporation noted that as many as
99 percent of the system improvement recommendations made in his company
failed to look at the system holistically. He further estimated that nearly 80 per-
cent of the suggested changes resulted in no improvement at all, and many of the
suggestions actually hurt overall performance. When attempting to make system
improvements, it is often discovered that localized changes fail to produce the
overall improvement that is desired. Put in technical language: Achieving a local
optimum often results in a global suboptimum. In simpler terms: It’s okay to act
locally as long as one is thinking globally. The elimination of a problem in one area
may only uncover, and sometimes even exacerbate, problems in other areas.
Approaching system design with overall objectives in mind and considering
how each element relates to each other and to the whole is called a systems or
holistic approach to systems design. Because systems are composed of interde-
pendent elements, it is not possible to accurately predict how a system will
perform simply by examining each system element in isolation from the whole.
To presume otherwise is to take a reductionist approach to systems design, which
focuses on the parts rather than the whole. While structurally a system may be di-
visible, functionally it is indivisible and therefore requires a holistic approach to
systems thinking. Kofman and Senge (1995) observe
The defining characteristic of a system is that it cannot be understood as a function of
its isolated components. First, the behavior of the system doesn’t depend on what
each part is doing but on how each part is interacting with the rest. . . . Second, to un-
derstand a system we need to understand how it fits into the larger system of which it
is a part. . . . Third, and most important, what we call the parts need not be taken as
primary. In fact, how we define the parts is fundamentally a matter of perspective and
purpose, not intrinsic in the nature of the “real thing” we are looking at.

Whether designing a new system or improving an existing system, it is impor-

tant to follow sound design principles that take into account all relevant variables.
The activity of systems design and process improvement, also called systems
Harrell−Ghosh−Bowden: I. Study Chapters 2. System Dynamics © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

Chapter 2 System Dynamics 37

FIGURE 2.4
Four-step iterative Identify problems
approach to systems and opportunities.
improvement.

Select and Develop

implement the alternative
best solution. solutions.

Evaluate the
solutions.

engineering, has been defined as

The effective application of scientific and engineering efforts to transform an opera-
tional need into a defined system configuration through the top-down iterative process
of requirements definition, functional analysis, synthesis, optimization, design, test
and evaluation (Blanchard 1991).

To state it simply, systems engineering is the process of identifying problems or

other opportunities for improvement, developing alternative solutions, evaluating
the solutions, and selecting and implementing the best solutions (see Figure 2.4).
All of this should be done from a systems point of view.

2.8.1 Identifying Problems and Opportunities

The importance of identifying the most significant problem areas and recognizing
opportunities for improvement cannot be overstated. Performance standards
should be set high in order to look for the greatest improvement opportunities.
Companies making the greatest strides are setting goals of 100 to 500 percent
improvement in many areas such as inventory reduction or customer lead time re-
duction. Setting high standards pushes people to think creatively and often results
in breakthrough improvements that would otherwise never be considered. Con-
trast this way of thinking with one hospital whose standard for whether a patient
had a quality experience was whether the patient left alive! Such lack of vision
will never inspire the level of improvement needed to meet ever-increasing
customer expectations.

2.8.2 Developing Alternative Solutions

We usually begin developing a solution to a problem by understanding the prob-
lem, identifying key variables, and describing important relationships. This helps
Harrell−Ghosh−Bowden: I. Study Chapters 2. System Dynamics © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

38 Part I Study Chapters

identify possible areas of focus and leverage points for applying a solution.
Techniques such as cause-and-effect analysis and pareto analysis are useful here.
Once a problem or opportunity has been identified and key decision variables
isolated, alternative solutions can be explored. This is where most of the design
and engineering expertise comes into play. Knowledge of best practices for com-
mon types of processes can also be helpful. The designer should be open to all
possible alternative feasible solutions so that the best possible solutions don’t get
overlooked.
Generating alternative solutions requires creativity as well as organizational
and engineering skills. Brainstorming sessions, in which designers exhaust every
conceivably possible solution idea, are particularly useful. Designers should use
every stretch of the imagination and not be stifled by conventional solutions
alone. The best ideas come when system planners begin to think innovatively and
break from traditional ways of doing things. Simulation is particularly helpful in
this process in that it encourages thinking in radical new ways.

2.8.3 Evaluating the Solutions

Alternative solutions should be evaluated based on their ability to meet the criteria
established for the evaluation. These criteria often include performance goals,
cost of implementation, impact on the sociotechnical infrastructure, and consis-
tency with organizational strategies. Many of these criteria are difficult to measure
in absolute terms, although most design options can be easily assessed in terms of
relative merit.
After narrowing the list to two or three of the most promising solutions using
common sense and rough-cut analysis, more precise evaluation techniques may
need to be used. This is where simulation and other formal analysis tools come
into play.

2.8.4 Selecting and Implementing the Best Solution

Often the final selection of what solution to implement is not left to the analyst, but
rather is a management decision. The analyst’s role is to present his or her evalua-
tion in the clearest way possible so that an informed decision can be made.
Even after a solution is selected, additional modeling and analysis are often
needed for fine-tuning the solution. Implementers should then be careful to make
sure that the system is implemented as designed, documenting reasons for any
modifications.

2.9 Systems Analysis Techniques

While simulation is perhaps the most versatile and powerful systems analysis
tool, other available techniques also can be useful in systems planning. These al-
ternative techniques are usually computational methods that work well for simple
systems with little interdependency and variability. For more complex systems,
Harrell−Ghosh−Bowden: I. Study Chapters 2. System Dynamics © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

Chapter 2 System Dynamics 39

these techniques still can provide rough estimates but fall short in producing the
insights and accurate answers that simulation provides. Systems implemented
using these techniques usually require some adjustments after implementation to
compensate for inaccurate calculations. For example, if after implementing a sys-
tem it is discovered that the number of resources initially calculated is insufficient
to meet processing requirements, additional resources are added. This adjustment
can create extensive delays and costly modifications if special personnel training
or custom equipment is involved. As a precautionary measure, a safety factor is
sometimes added to resource and space calculations to ensure they are adequate.
Overdesigning a system, however, also can be costly and wasteful.
As system interdependency and variability increase, not only does system
performance decrease, but the ability to accurately predict system performance
decreases as well (Lloyd and Melton 1997). Simulation enables a planner to ac-
curately predict the expected performance of a system design and ultimately make
better design decisions.
Systems analysis tools, in addition to simulation, include simple calculations,
spreadsheets, operations research techniques (such as linear programming and
queuing theory), and special computerized tools for scheduling, layout, and so
forth. While these tools can provide quick and approximate solutions, they tend to
make oversimplifying assumptions, perform only static calculations, and are lim-
ited to narrow classes of problems. Additionally, they fail to fully account for
interdependencies and variability of complex systems and therefore are not as ac-
curate as simulation in predicting complex system performance (see Figure 2.5).
They all lack the power, versatility, and visual appeal of simulation. They do pro-
vide quick solutions, however, and for certain situations produce adequate results.
They are important to cover here, not only because they sometimes provide a
good alternative to simulation, but also because they can complement simulation
by providing initial design estimates for input to the simulation model. They also

FIGURE 2.5
Simulation improves 100%
performance With
predictability. simulation
System predictability

50%
Without
simulation

Call centers Banks Airports

Doctor's offices Emergency rooms Hospitals
Machining cells Production lines Factories
0%
Low Medium High
System complexity
Harrell−Ghosh−Bowden: I. Study Chapters 2. System Dynamics © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

40 Part I Study Chapters

can be useful to help validate the results of a simulation by comparing them with
results obtained using an analytic model.

2.9.1 Hand Calculations

Quick-and-dirty, pencil-and-paper sketches and calculations can be remark-
ably helpful in understanding basic requirements for a system. Many important
decisions have been made as the result of sketches drawn and calculations per-
formed on a napkin or the back of an envelope. Some decisions may be so basic
that a quick mental calculation yields the needed results. Most of these calcula-
tions involve simple algebra, such as finding the number of resource units (such as
machines or service agents) to process a particular workload knowing the capacity
per resource unit. For example, if a requirement exists to process 200 items per
hour and the processing capacity of a single resource unit is 75 work items
per hour, three units of the resource, most likely, are going to be needed.
The obvious drawback to hand calculations is the inability to manually per-
form complex calculations or to take into account tens or potentially even hun-
dreds of complex relationships simultaneously.

2.9.2 Spreadsheets
Spreadsheet software comes in handy when calculations, sometimes involving
hundreds of values, need to be made. Manipulating rows and columns of numbers
on a computer is much easier than doing it on paper, even with a calculator handy.
Spreadsheets can be used to perform rough-cut analysis such as calculating
average throughput or estimating machine requirements. The drawback to spread-
sheet software is the inability (or, at least, limited ability) to include variability in
activity times, arrival rates, and so on, and to account for the effects of inter-
dependencies.
What-if experiments can be run on spreadsheets based on expected values
(average customer arrivals, average activity times, mean time between equipment
failures) and simple interactions (activity A must be performed before activity B).
This type of spreadsheet simulation can be very useful for getting rough perfor-
mance estimates. For some applications with little variability and component in-
teraction, a spreadsheet simulation may be adequate. However, calculations based
on only average values and oversimplified interdependencies potentially can be
misleading and result in poor decisions. As one ProModel user reported, “We just
completed our final presentation of a simulation project and successfully saved
approximately $600,000. Our management was prepared to purchase an addi-
tional overhead crane based on spreadsheet analysis. We subsequently built a
ProModel simulation that demonstrated an additional crane will not be necessary.
The simulation also illustrated some potential problems that were not readily ap-
parent with spreadsheet analysis.”
Another weakness of spreadsheet modeling is the fact that all behavior is
assumed to be period-driven rather than event-driven. Perhaps you have tried to
Harrell−Ghosh−Bowden: I. Study Chapters 2. System Dynamics © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

Chapter 2 System Dynamics 41

figure out how your bank account balance fluctuated during a particular period
when all you had to go on was your monthly statements. Using ending balances
does not reflect changes as they occurred during the period. You can know the cur-
rent state of the system at any point in time only by updating the state variables of
the system each time an event or transaction occurs. When it comes to dynamic
models, spreadsheet simulation suffers from the “curse of dimensionality” be-
cause the size of the model becomes unmanageable.

2.9.3 Operations Research Techniques

Traditional operations research (OR) techniques utilize mathematical models to
solve problems involving simple to moderately complex relationships. These
mathematical models include both deterministic models such as mathematical
programming, routing, or network flows and probabilistic models such as queuing
and decision trees. These OR techniques provide quick, quantitative answers
without going through the guesswork process of trial and error. OR techniques
can be divided into two general classes: prescriptive and descriptive.

Prescriptive Techniques
Prescriptive OR techniques provide an optimum solution to a problem, such as
the optimum amount of resource capacity to minimize costs, or the optimum
product mix that will maximize profits. Examples of prescriptive OR optimiza-
tion techniques include linear programming and dynamic programming. These
techniques are generally applicable when only a single goal is desired for mini-
mizing or maximizing some objective function—such as maximizing profits or
minimizing costs.
Because optimization techniques are generally limited to optimizing for a
single goal, secondary goals get sacrificed that may also be important. Addition-
ally, these techniques do not allow random variables to be defined as input data,
thereby forcing the analyst to use average process times and arrival rates that can
produce misleading results. They also usually assume that conditions are constant
over the period of study. In contrast, simulation is capable of analyzing much
more complex relationships and time-varying circumstances. With optimization
capabilities now provided in simulation, simulation software has even taken on a
prescriptive roll.

Descriptive Techniques
Descriptive techniques such as queuing theory are static analysis techniques that
provide good estimates for basic problems such as determining the expected
average number of entities in a queue or the average waiting times for entities in
a queuing system. Queuing theory is of particular interest from a simulation
perspective because it looks at many of the same system characteristics and issues
that are addressed in simulation.
Queuing theory is essentially the science of waiting lines (in the United
Kingdom, people wait in queues rather than lines). A queuing system consists of
Harrell−Ghosh−Bowden: I. Study Chapters 2. System Dynamics © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

42 Part I Study Chapters

FIGURE 2.6 Arriving entities Queue Server Departing entities

Queuing system
configuration.

.
.
.

one or more queues and one or more servers (see Figure 2.6). Entities, referred to
in queuing theory as the calling population, enter the queuing system and either
are immediately served if a server is available or wait in a queue until a server be-
comes available. Entities may be serviced using one of several queuing disci-
plines: first-in, first-out (FIFO); last-in, first-out (LIFO); priority; and others. The
system capacity, or number of entities allowed in the system at any one time, may
be either finite or, as is often the case, infinite. Several different entity queuing be-
haviors can be analyzed such as balking (rejecting entry), reneging (abandoning
the queue), or jockeying (switching queues). Different interarrival time distribu-
tions (such as constant or exponential) may also be analyzed, coming from either
a finite or infinite population. Service times may also follow one of several distri-
butions such as exponential or constant.
Kendall (1953) devised a simple system for classifying queuing systems in
the form A/B/s, where A is the type of interarrival distribution, B is the type of
service time distribution, and s is the number of servers. Typical distribution types
for A and B are
M for Markovian or exponential distribution
G for a general distribution
D for a deterministic or constant value
An M/D/1 queuing system, for example, is a system in which interarrival times are
exponentially distributed, service times are constant, and there is a single server.
The arrival rate in a queuing system is usually represented by the Greek letter
lambda (λ) and the service rate by the Greek letter mu (µ). The mean interarrival
time then becomes 1/λ and the mean service time is 1/µ. A traffic intensity factor
λ/µ is a parameter used in many of the queuing equations and is represented by
the Greek letter rho (ρ).
Common performance measures of interest in a queuing system are based on
steady-state or long-term expected values and include
L = expected number of entities in the system (number in the queue and in
service)
Lq = expected number of entities in the queue (queue length)
Harrell−Ghosh−Bowden: I. Study Chapters 2. System Dynamics © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

Chapter 2 System Dynamics 43

W = expected time in the system (flow time)

Wq = expected time in the queue (waiting time)
Pn = probability of exactly n customers in the system (n = 0, 1, . . .)
The M/M/1 system with infinite capacity and a FIFO queue discipline is perhaps
the most basic queuing problem and sufficiently conveys the procedure for -
analyzing queuing systems and understanding how the analysis is performed. The
equations for calculating the common performance measures in an M/M/1 are
ρ λ
L= =
(1 − ρ) (µ − λ)
ρ2
Lq = L − ρ =
(1 − ρ)
1
W =
µ−λ
λ
Wq =
µ(µ − λ)
Pn = (1 − ρ)ρ n n = 0, 1, . . .

If either the expected number of entities in the system or the expected waiting
time is known, the other can be calculated easily using Little’s law (1961):
L = λW
Little’s law also can be applied to the queue length and waiting time:
L q = λWq
Example: Suppose customers arrive to use an automatic teller machine (ATM) at an
interarrival time of 3 minutes exponentially distributed and spend an average of
2.4 minutes exponentially distributed at the machine. What is the expected number of
customers the system and in the queue? What is the expected waiting time for cus-
tomers in the system and in the queue?
λ = 20 per hour
µ = 25 per hour
λ
ρ= = .8
µ
Solving for L:
λ
L=
(µ − λ)
20
=
(25 − 20)
20
= =4
5
Harrell−Ghosh−Bowden: I. Study Chapters 2. System Dynamics © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

44 Part I Study Chapters

Solving for Lq:

ρ2
Lq =
(1 − ρ)
.82
=
(1 − .8)
.64
=
.2
= 3.2
Solving for W using Little’s formula:
L
W =
λ
4
=
20
= .20 hrs
= 12 minutes
Solving for Wq using Little’s formula:
Lq
Wq =
λ
3.2
=
20
= .16 hrs
= 9.6 minutes

Descriptive OR techniques such as queuing theory are useful for the most
basic problems, but as systems become even moderately complex, the problems
get very complicated and quickly become mathematically intractable. In contrast,
simulation provides close estimates for even the most complex systems (assum-
ing the model is valid). In addition, the statistical output of simulation is not
limited to only one or two metrics but instead provides information on all per-
formance measures. Furthermore, while OR techniques give only average per-
formance measures, simulation can generate detailed time-series data and
histograms providing a complete picture of performance over time.

2.9.4 Special Computerized Tools

Many special computerized tools have been developed for forecasting, schedul-
ing, layout, staffing, and so on. These tools are designed to be used for narrowly
focused problems and are extremely effective for the kinds of problems they are
intended to solve. They are usually based on constant input values and are com-
puted using static calculations. The main benefit of special-purpose decision tools
is that they are usually easy to use because they are designed to solve a specific
type of problem.
Harrell−Ghosh−Bowden: I. Study Chapters 2. System Dynamics © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

Chapter 2 System Dynamics 45

2.10 Summary
An understanding of system dynamics is essential to using any tool for planning
system operations. Manufacturing and service systems consist of interrelated
elements (personnel, equipment, and so forth) that interactively function to pro-
duce a specified outcome (an end product, a satisfied customer, and so on).
Systems are made up of entities (the objects being processed), resources (the per-
sonnel, equipment, and facilities used to process the entities), activities (the
process steps), and controls (the rules specifying the who, what, where, when, and
how of entity processing).
The two characteristics of systems that make them so difficult to analyze are
interdependencies and variability. Interdependencies cause the behavior of one
element to affect other elements in the system either directly or indirectly. Vari-
ability compounds the effect of interdependencies in the system, making system
behavior nearly impossible to predict without the use of simulation.
The variables of interest in systems analysis are decision, response, and state
variables. Decision variables define how a system works; response variables
indicate how a system performs; and state variables indicate system conditions at
specific points in time. System performance metrics or response variables are gen-
erally time, utilization, inventory, quality, or cost related. Improving system per-
formance requires the correct manipulation of decision variables. System opti-
mization seeks to find the best overall setting of decision variable values that
maximizes or minimizes a particular response variable value.
Given the complex nature of system elements and the requirement to make
good design decisions in the shortest time possible, it is evident that simulation
can play a vital role in systems planning. Traditional systems analysis techniques
are effective in providing quick but often rough solutions to dynamic systems
problems. They generally fall short in their ability to deal with the complexity and
dynamically changing conditions in manufacturing and service systems. Simula-
tion is capable of imitating complex systems of nearly any size and to nearly any
level of detail. It gives accurate estimates of multiple performance metrics and
leads designers toward good design decisions.

2.11 Review Questions

1. Why is an understanding of system dynamics important to the use of
simulation?
2. What is a system?
3. What are the elements of a system from a simulation perspective? Give
an example of each.
4. What are two characteristics of systems that make them so complex?
5. What is the difference between a decision variable and a response variable?
6. Identify five decision variables of a manufacturing or service system
that tend to be random.
Harrell−Ghosh−Bowden: I. Study Chapters 2. System Dynamics © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

46 Part I Study Chapters

7. Give two examples of state variables.

8. List three performance metrics that you feel would be important for a
computer assembly line.
9. List three performance metrics you feel would be useful for a hospital
emergency room.
10. Define optimization in terms of decision variables and response variables.
11. Is maximizing resource utilization a good overriding performance
objective for a manufacturing system? Explain.
12. What is a systems approach to problem solving?
13. How does simulation fit into the overall approach of systems engineering?
14. In what situations would you use analytical techniques (like hand
calculations or spreadsheet modeling) over simulation?
15. Assuming you decided to use simulation to determine how many lift
trucks were needed in a distribution center, how might analytical models
be used to complement the simulation study both before and after?
16. What advantages does simulation have over traditional OR techniques
used in systems analysis?
17. Students come to a professor’s office to receive help on a homework
assignment every 10 minutes exponentially distributed. The time to help
a student is exponentially distributed with a mean of 7 minutes. What are
the expected number of students waiting to be helped and the average
time waiting before being helped? For what percentage of time is it
expected there will be more than two students waiting to be helped?

References
Blanchard, Benjamin S. System Engineering Management. New York: John Wiley & Sons,
1991.
Hopp, Wallace J., and M. Spearman. Factory Physics. New York: Irwin/McGraw-Hill,
2000, p. 282.
Kendall, D. G. “Stochastic Processes Occurring in the Theory of Queues and Their
Analysis by the Method of Imbedded Markov Chains.” Annals of Mathematical
Statistics 24 (1953), pp. 338–54.
Kofman, Fred, and P. Senge. Communities of Commitment: The Heart of Learning
Organizations. Sarita Chawla and John Renesch, (eds.), Portland, OR. Productivity
Press, 1995.
Law, Averill M., and David W. Kelton. Simulation Modeling and Analysis. New York:
McGraw-Hill, 2000.
Little, J. D. C. “A Proof for the Queuing Formula: L = λW.” Operations Research 9, no. 3
(1961), pp. 383–87.
Lloyd, S., and K. Melton. “Using Statistical Process Control to Obtain More Precise
Distribution Fitting Using Distribution Fitting Software.” Simulators International
XIV 29, no. 3 (April 1997), pp. 193–98.
Senge, Peter. The Fifth Discipline. New York: Doubleday, 1990.
Simon, Herbert A. Models of Man. New York: John Wiley & Sons, 1957, p. 198.