Fishwick P.A. (editor) Handbook of Dynamic System Modeling

Подождите немного. Документ загружается.

33-10 Handbook of Dynamic System Modeling

program keeps a count of how many are available, but their individual states are not tracked.

Resource contention occurs when the same resources are needed by different entities at the same

simulation time. The number of resource types in a DES model is another clue to its complexity,

but this is not the same as the number of resource items.

Whether a system element should be treated as an entity or as a resource is a decision for the modeler

and it is normal for either representation to be possible for one of more classes of object in the system. In

management science, DES models are built for particular purposes, typically to support decision making

and planning, and this purpose will often be what determines the representation. Consider the simulation

of a telephone call center in which callers dial in, wait for an operator, hold a conversation, and then end the

call. If we need to know the performance of each operator within the call center, then we will represent

these as entities whose precise behavior and quirks will be modeled. However, if we are only interested

in the general performance of the population of operators, we may choose to represent them as a resource

pool. In this second case, when a new call arrives, we check to see if the pool of available operators is greater

than zero; if not, the call will not be taken until an operator becomes free. If the current pool size is greater

than zero, it will be reduced by one (if a single operator is required) at the start of the conversation. At the

end of the conversation, the operator is now free and the pool size will be increased by one to represent this.

As well as representing the entities and resources, we also need to capture how they interact and change

state through time. This leads to the second set of terminology.

3. Simulation events: These are instants of time at which signiﬁcant state changes occur in the system,

such as when a customer arrives, a machine breaks down, or some operation begins. Note that the

analyst must deﬁne whether an event is signiﬁcant or not in the context of the objectives of the

simulation. For example, when simulating an airport baggage system it may not matter when a

rain shower begins and ends. However, when modeling the use of airspace around an airport, this

might be an important consideration when trying to establish separation rules for landing aircraft.

4. Simulation activities: Entities move from state to state because of the operations in which they

engage. The operations and procedures that are initiated at each event are known as activities and

these transform the state of the entities. For example, a phone conversation in a call center requires

a caller and an operator to co-operate for a period while the conversation proceeds. The start and

end of the conversation may be modeled as simulation events, and the conversation itself, which

takes time, is a simulation activity. Its start changes the state of caller and operator, and so does

its end. It can only begin if the caller is waiting and the operator is currently idle. Hence, starting

a simulation activity depends on the system state and also changes that system state. Ending a

simulation activity also changes the system state.

5. Simulation processes: Sometimes it is useful to group together a sequence of events in the chrono-

logical order in which they will occur. Such a sequence is known as a process and is often used to

represent all or part of the life of an entity class. For example, a phone call arrives at a call center,

may join a queue, may renege and leave the queue, may be answered by an operator and will then

leave the system. Hence simulation processes may include logical decision points.

6. Simulation clock: Since a DES model is concerned with the dynamic behavior of a system through

time, this movement of time must itself be simulated. As mentioned earlier, time does not progress

smoothly within a DES, but jumps from event to event in a chronological sequence. The simulation

clock time is the point reached by current simulated time in a simulation. Hence in a simulation

where the time unit is minutes, the test “is clock = 240?” might be used to test whether a lunch

break is due. If so, appropriate activity could then be initiated in the simulation.

33.3.4 Activity Cycle Diagrams in Conceptual Modeling

There are many different approaches to conceptual modeling in DES, each offering some support to the

modeler trying to represent the important elements of a system that will be simulated using a DES model.

Examples include event graphs (Schruben, 1983; also in Chapter 23), control ﬂow graphs (Cota and

Dynamic Modeling in Management Science 33-11

Call

Hang on

DRIVERS

Speak

Wait

Watch

Idle

Talk

Busy

Locate

Found

Despatch

OPERATORS

Avail Ready

Briefed

Travel

Repair

Listen

TRUCKS

Drive

Stopped

FIGURE 33.2 Separate activity cycles for the CallOut simulation.

Drive

Stopped

DRIVERS

Wait

Idle

Talk

Busy

Locate

Found

Despatch

OPERATORS

Avail

Ready

Briefed

Travel

Repair

TRUCKS

Call

Hang

FIGURE 33.3 Combined activity cycle diagram for the CallOut simulation.

Sargent, 1990), Petri nets (Zimmerman, 2004; also in Chapter 24), and activity cycle diagrams, which are

described here. Activity cycle diagrams are very simple and require the modeler to represent the interaction

of entities and resources as a network that uses two symbols (See Figure 33.2 and Figure 33.3).

The rectangles represent active states, which may involve the co-operation of entities and resources. The

states of those entities and the size of the resource pools may change at the start and end of the activity.

Active states take simulation time (which may include zero time—for example, two customers may phone

simultaneously) and we assume that this time can be computed when the activity begins. That is, when it

begins, the start time of an active state is known and its end can be scheduled at some future simulation

time. When simulating a call center, a conversation between an operator and caller is usually represented

as an active state.

33-12 Handbook of Dynamic System Modeling

The circles are used to represent dead states, sometimes known as queues, and these have durations that

cannot be known in advance. Though we know the simulation time at which an entity enters a dead state,

such a state is deﬁned as one in which the entity waits until some event provides a resource or co-operating

entity that allows it to proceed from that dead state. Hence, we do not know the time at which it will end. A

dead state is always preceded by an active state and is always followed by an active state. When simulating

a call center, the time a caller spends waiting for an operator to answer is usually modeled as a dead state;

as is the time that the operator is idle, waiting for another call.

To illustrate the use of activity cycle diagrams, consider the operation of the CallOut response center.

CallOut provides a breakdown and recovery service to car drivers who pay an annual subscription. It

operates several call centers, one of which supports motorists whose car has broken down while on the

road. To use the service, motorists phone the call center—in most cases they do so from their cell phones

using the number for on-road breakdown assistance. When they phone the call center, their call is taken

by the ﬁrst available operator whose main task is to check that the caller has an up-to-date subscription

to CallOut, to note the precise location of the vehicle, its make and model details, and a summary of the

problem. At the end of the call, the operator checks a real-time location system to ﬁnd the nearest free

breakdown truck (the trucks carry GPS locators), to whom she allocates the call. The truck driver then

travels to the stricken vehicle, provides whatever aid is required, and, at the end of the job, reports back by

phone that he is free for another job.

There are three important simulation object classes which, at this stage, we can think of as entity classes:

•

Drivers: whose vehicles breakdown and who phone CallOut asking for assistance.

•

Operators: who take the calls from drivers and despatch a breakdown truck to the location of the

stricken car.

•

Trucks: which are despatched by the operator to the scene and offer aid.

Figure 33.3 shows an activity cycle for each of these entity classes.

The operators are initially Idle, they then Talk to a caller, after which they Locate and Despatch appropriate

resources, and return to an Idle state. Three of these are active states (Talk, Locate, and Despatch) and each

is separated by a dead state from the next active state. One such dead state, Idle, is genuine, the others are

there for convenience and to keep the rules of activity cycle diagrams.

The drivers are initially OK, and Drive a working vehicle until they break down (and enter a dead state,

Stopped) and Call the call center and Hang on until they Speak to an operator. They then Wait until

a breakdown truck arrives and then Watch while a repair is executed; after which they are OK again.

Following similar logic to the activity cycle for the operators, Wait is clearly a dead state and Phone is an

active state. Keeping to the alternative live and dead state rule means that OK is a dead state and Watch is

an active state.

Finally, consider the activity cycle of the trucks, which are initially ready for work in an Avail state, from

which they enter a Listen state in which they receive instructions from an operator, after which they are

Briefed. They then Travel to the location of the stricken vehicle, where they execute a Repair, after which

they are then once again in an Avail state. Instruct, Travel, and Repair are all active states and Avail, Briefed,

and Ready are dead states. Applying the alternate active: dead state rule, leads to the third activity cycle in

Figure 33.3.

As independent cycles, these diagrams are of little use. Their power comes when they are combined to

show the interaction of the entity classes; for it is this interaction that causes the dynamic behavior of the

system. An activity cycle diagram that combines the three cycles is shown in Figure 33.3, this is a little

messy, but can be very useful in conceptualizing a possible simulation model. Some of the active states

require the co-operation of two classes of entity: when an operator is in the active state Talk, this is the

same state labeled as Speak in the drivers’ activity cycle. This combined active state is labeled as Talk in

Figure 33.4. The operators’ active state Despatch requires the co-operation of a truck that is previously in

the Avail state. On the truck cycle of Figure 33.3 this is labeled as

Instruct and the operators’ label Despatch

is used for the combined active state. Finally, the active state Repair from the trucks’ cycle is clearly the

Dynamic Modeling in Management Science 33-13

same as the active state Watch from the drivers’ cycle. In combining the two, the trucks’ state name of

Repair is used.

Examining the combined activity cycles of Figure 33.3 provides some useful insights that will serve the

basis of the implementation of a suitable DES model using computer software, independent of the type of

software used. First, we can write down the conditions that govern the start of the active states that involve

the co-operation of two or more entity classes. The Talk active state can only begin if two conditions hold:

•

There must be a driver who is in the dead state Hang on.

•

AND an operator in the dead state Idle.

Likewise, for the Despatch active state to begin, two conditions must both be satisﬁed:

•

There must be a truck in the dead state Avail.

•

AND an operator in the dead state Found.

The start of the Repair active state is also governed by two conditions:

•

There must be a truck in the dead state Ready.

•

AND a driver/car must be in the dead state Wait.

Notice that an unspoken approximation has crept into the model: we are not distinguishing between

drivers and cars. This is reasonable, unless the purpose for which the model is being built requires us to

do otherwise.

The other active states (Drive, Locate, and Travel ) do not require the co-operation of two entity classes

to begin. These are active states in which their relevant entities (drivers for Drive, operators for Locate,

and trucks for Travel) are bound to occur once the preceding active is complete. For example, the truck

will automatically enter the Travel active state once the Despatch active state is complete—which means

that it will spend zero time in the intervening dead state, Briefed. The same applies to drivers in the OK

dead state and to operators in the dead state, Busy. These dummy dead states are needed so as to allow

the separation of the life cycles (or processes) of the co-operating entities at the end of the active state in

which they have co-operated. It is tempting, but inadvisable, to ignore these dead states; and doing so may

lead to problems later.

In this way, we can use devices such as activity cycle diagrams to represent the logical interactions

between the entities and resources of the system. Rather more detail will be needed if the conceptual

model is to be implemented in computer software, but modeling in too much detail at the start of the

simulation project is almost always a mistake.

33.3.5 Implementing a DES Model in Computer Software

There are many different DES computer packages available on the market. The OR/MS Today magazine of

INFORMS publishes occasionalsurveys of available software and the annualWinter Simulation Conference

(www.wintersim.org) usually includes presentations from the major vendors. Hence there is plenty of

choice and gaining information has been made much easier by the Internet. Broadly speaking, there are

two ways in which a DES model may be implemented in computer software: write a program or use a

VIMS.

Whatever the mode of implementation, it is important to distinguish between the model logic and the

simulation executive (sometimes known as the simulation engine). The model logic is an expression of the

rules that govern the system being simulated—its active and dead states and the rules that govern the state

changes. Each different DES model will have its own application logic, as captured in the conceptual model.

By contrast, the simulation executive is general purpose and can control any DES model whose logic is

expressed in a suitable form. The executive exists to ensure that the entities and resources change state at

the right simulation times and as required by the conditions in the simulation. In most circumstances,

the modeler is concerned only to ensure that the model logic is correctly expressed; that is, the simulation

executive is provided by the software vendor and is usually hidden from the modeler.

33-14 Handbook of Dynamic System Modeling

33.3.6 Discrete Event Simulation using a VIMS

As stated earlier, most simulation applications in management science are implemented using VIMS, which

require little in the way of computer programming. These are shrink-wrapped software systems such as

Arena, Witness, Simul8, MicroSaint, and Automod in which models are built by point and click using

predeﬁned objects for which the user must supply properties. Though there is no proper survey evidence

to support this assertion, the proportion of discrete simulation applications that use a VIMS may be as

high as 90%, with many of the remaining being large-scale models developed in the defence sector. The

latter, by contrast, usually involve signiﬁcant programming and may require explicit management of the

events that comprise the dynamic behavior of the simulation. The pros and cons of the two approaches

are discussed at length in Pidd (2004b).

Why are VIMS so popular? Because they offer the prospect of rapid application development by people

who are not computer professionals. There is no doubt that a VIMS can be easy to learn, at least for

straightforward applications, as most simulation instructors will testify. However, it is also true that a

VIMS can run out of power when faced with large and complex applications. This, of course, may not

matter for routine business applications in which the 80:20 rule may apply: that is, a simple model may

be good enough. Few senior managers would invest very large sums in a one-off capital development

based on a complicated stochastic analysis with wide and overlapping conﬁdence intervals. All models are

approximations; very approximate models are often good enough in management science, and VIMS are

good enough for very approximate models.

Figure 33.4 shows the logical composition of a typical VIMS. It presents a user interface that exploits

theAPIprovidedbythe operating system (usually a version of Windows™).Working withthe user interface,

models may be developed, edited, and run and experiments may be conducted. The latter usually requires

at least some statistical analysis, and VIMS usually allow the export of results ﬁles in some suitable format

for a spreadsheet or statistical package. Models are constructed by selecting icons that represent features

of the system being simulated and these are linked together on-screen, and parameterized using property

sheets. This is ﬁne if the objects provided are a good ﬁt for the application. However, the default logic

provided by the simulator may be inadequate to model the particular interactions of speciﬁc business

processes. To allow customization, most VIMS provide a coding language in which interactions can be

programmed. Some do this with a general-purpose programming language (e.g., Visual Basic or C#).

Others incorporate simulation quasi-languages that permit little beyond the assignment of attributes, the

deﬁnition of if statements, loops, and limited access to component properties. However, the modeler need

not write a full program, merely code sections to represent speciﬁc logic.

Inside every VIMS is a generic simulation model that is not usually available to the user, who works with

a network diagram that represents the activity and interactions of the model. Figure 33.5 shows such a

network for an accident and emergency department of a hospital using Micro Saint Sharp (Micro Analysis

and Design, 2005), a DES VIMS. In essence, the generic model takes the network diagram as data.

Experimentation

Model

running

Model

development

User Interface

Model builder

and editor

Simulation and

application

classes

Generic model

Analysis and

experimentation

toolkit

Simulation

engine

FIGURE 33.4 Internal organization of Visual Interactive Modeling Systems.

Dynamic Modeling in Management Science 33-15

Patient

arrives (1)

Assign

triage (2)

Registration (3)

Major

treatment (4)

Minor

treatment (5)

Prescribe

treatment (8)

Carry out

nurse orders (9)

See nurse (6)

Re-evaluate

patient (11)

Admit

patient (12)

Discharge

patient (13)

See doctor (7)

TESTS (14)

FIGURE 33.5

Micro Saint Sharp task diagram for an accident and emergency

department.

33-16 Handbook of Dynamic System Modeling

Thus, if it were thought desirable, a VIMS on-screen network could be replaced by a series of verbal

commands each of which carries attribute data to represent the property sheets. The generic model

assumes that simulation entities change state and it reads the network description to deﬁne the sequence

of those states and the conditions that govern them. The code fragments, in whatever simulation language,

are then used to modify the standard generic model in some way or other. Once suitably parameterized,

the generic model is run by a simulation executive, which sequences and schedules the tasks that deﬁne the

application model. Like the generic model, the simulation executive is also hidden from the user. Hence,

the form of the simulation executive is rarely revealed by the VIMS vendors, who are keen to present their

software as easy to use and also powerful. How the simulation runs is deemed to be of little concern to the

users.

33.4 System Dynamics in Management Science

DESs are based on the dynamic interactions of individual simulation entities, using rules to represent this

logic. System dynamics, an approach introduced in Chapter 27, is the other dynamic modeling approach

that is commonly used in management science. In system dynamics, the aim is to model system behavior

at a more macroscopic level by considering how system structure may affect system behavior. Since a

systems perspective underpins system dynamics, this has led some enthusiasts to claim the name “systems

thinking” for their approach. This is a shame, since there are many different varieties of systems thinking,

as discussed, for example in Jackson (2003). Further damage is done by overblown claims such as those of

Senge (1999), whose popular book “The ﬁfth discipline” shows how the ideas of system dynamics can be

used to support organizational learning. This is ﬁne, but the claim that this represents a whole new way of

thinking that is revolutionary seems somewhat exaggerated. Instead, we should regard system dynamics

as providing a way to support thinking about decisions and plans.

When ﬁrst developed by Forrester and his colleagues in the early 1960s, system dynamics, then known as

industrial dynamics (Forrester, 1961), had a strong engineering “feel” about it. Indeed, Forrester acknowl-

edged that he had taken ideas used in control engineering in which feedback structures are modeled as

differential equations (see Chapter 17 and Chapter 18). Forrester replaced the differential equations with

ﬁrst-order difference equations (see Chapter 27) and simple Euler–Cauchy integration. The result was an

approach that could be used by people who were not trained engineers. The industrial dynamics approach

stressed system simulation in which models consisting of linked sets of difference equations were run

through time to provide a system simulation. This quantitative system dynamics was joined, some years

later, by qualitative approaches that stress the use of system dynamics to develop understanding rather than

as a simulation tool. Both approaches will be brieﬂy covered in this chapter. For a thorough description of

both approaches see Sterman (op cit), for a quantitative treatment see Coyle (1996) and see Wolstenholme

(1990) for a more qualitative treatment.

33.4.1 System Structure and System Behavior

To illustrate the difference between system structure and system behavior, consider the following example.

Suppose we notice that the sales of a product have increased and we start to think about why this has

happened. That is, we try to develop a causal argument that links the observed increase in sales with some

other inﬂuences and events. In effect, this is a set of informal hypotheses such as: sales have increased

because the weather is good or sales have increased because we had the stocks in the shops when the

customers wished to buy them. This is, of course, what economic modelers aim to do when trying to

understand economic behavior—though in their case, the models are usually based on equations that rely

on statistical methods for their parameters. In economic models and in system dynamics, the aim is to

show how changes in one factor affects other variables. The intention is to help people to understand the

effect of their actions and those of others.

The question is, what causes the observed behavior? A fundamental assumption in system dynamics is

that behavior is a result of structures—both inside the system and in its environment. However, these are

Dynamic Modeling in Management Science 33-17

not structures as might often be understood—such as the number of staff employed or the layout of a

factory. Instead, they are the underlying, general features that can be observed across many types of system.

At their most basic, these are the feedback loops and delays that are present in most organizational systems.

System dynamics provides a way to model those feedback structures and delays so as to understand how

they affect the behavior of the system.

With this in mind, it is important to understand the distinction between content and structure. Structure

deﬁnes how variables interact, and content expresses the meaning of those variable and interactions—

rather like considering syntax and semantics in language. Two systems may have similar structures but

quite different content. For example, a supermarket and a telephone call center can both be analyzed in

terms of their queuing structure. Both systems have customers who are served, but the meaning (and

importance) of the customers differ. In the call center, the customers are calls awaiting response, whereas

in the supermarket the customers are the shoppers. Coyle (op cit) points out that the management scientist

has to maintain two views of a system at the same time. To model it, the system must be seen in terms of

its structure, but to consider making changes it is crucial to keep in mind the meaning of the variables.

Only then will it be clear which changes are feasible.

33.4.2 Qualitative System and Dynamics: Causal Loop Diagrams

As an example, consider the parent company of the CallOut response center introduced earlier in this

chapter. Suppose that the managers of this business are concerned about customer churn: that is, though

they gained new customers they also lost customers during the year. Because of this concern they have

called a meeting and as the discussion proceeds it becomes clear that most people think that the best way to

reduce this problem is to increase their marketing effort. This thinking is captured in the diagram of Figure

33.6, which shows that they regard marketing effort as having two components: marketing expenditure

and the effectiveness of their advertising. Figure 33.6 is an example of a causal loop diagram in which the

arrows are intended to show causal links between two factors. Each arrow carries a sign: a positive sign

indicates that an increase in the factor at the tail of the arrow will also lead to an increase in the factor at its

head. A positive sign also means that any decrease in the factor at the tail of the arrow is expected to lead

to a decrease in the factor at its head. Conversely, a negative sign indicates that an increase in the factor at

the tail of the arrow is thought likely to lead to a decrease in the factor at the head of the arrow. Likewise,

a negative sign could indicate that a decrease in the factor at the tail of the arrow is thought likely to lead

to an increase in the factor of its head.

Customers

New customer rate

Ad effectiveness

Ad spend rate

Lost customer rate

Customer target





FIGURE 33.6 Causal loop diagram for advertising to gain new customers.

33-18 Handbook of Dynamic System Modeling

Thus the main loop of the diagram reﬂects straightforward beliefs and also what we might think of as

the “physics” of the system. That is, an increase in the number of new customers will lead to an increase

in the number of customers. This in turn will lead to a decrease in the expenditure on advertising, since

as they edge closer to their target number of customers, they can reduce advertising. It is also believed,

quite reasonably, that increasing advertising expenditure will lead to an increase in the number of new

customers. This loop is known as a balancing loop in the terminology of system dynamics and it reﬂects

negative feedback control. That is, the number of customers will not continually increase because, as the

number of customers increase, advertising expenditure will decrease, which will decrease the number of

new customers. This, of course, only works because an increase in the number of customers leads to an

increase in the number of lost customers that will, in turn, lead to a decrease in the number of customers.

Finally, since they believe that advertising effectiveness can vary, the diagram shows a positive link between

advertising effectiveness and of the number of new customers recruited. There is, of course, a problem

with the worldview shown in the causal loop diagram. It assumes that they can do nothing about the

number of customers that are lost each period.

Once they realize that this is wrong, they can construct a rather better causal loop diagram as shown in

Figure 33.7. This time two new factors have been included: marketing spend and expenditure on incentives

to existing customers. The idea of this is to retain existing customers since it is usually the case that doing

so is cheaper than spending money to gain new ones. There is a positive link shown between customers

and total marketing expenditure, since the more customers they have the more they can afford to spend

on marketing. In turn, marketing expenditure is split between incentives and advertising and it is clear

that a major decision facing the company is how to divide this expenditure between the two types of

marketing. There is a negative link from incentive expenditure to the number of lost customers, since

it seems reasonable to believe that the more they spend on these incentives the less likely customers are

to leave. This leads to a second balancing loop on the diagram which connects the customers, incentive

expenditure and lost customers.

Causal loop diagrams of this type are used in two ways. First, they are at the core of what has come to be

known as qualitative system dynamics. In this mode, the idea is to encourage individuals and, especially,

groups of people to sketch out their thinking using causal loop diagrams. Even if the diagrams do not lead

to a simulation of some kind they can be very useful devices for encouraging people to think about the

factors to be considered when tackling a difﬁcult issue. In addition, skilled users of system dynamics can

recognize features of these diagrams that are based on structures found in many different types of system.

Customers

New customer rate

Ad effectiveness

Ad spend rate

Incentive spend rate

Lost customer rate

Customer target





Marketing spend rate



FIGURE 33.7 Causal loop diagram for customer retention expenditure.

Dynamic Modeling in Management Science 33-19

Richmond and Petersen (1994) and Sterman (op cit) provide several examples of these system archetypes

and discuss the effects that they are likely to have on system behavior.

33.4.3 Quantitative System Dynamics: Level-Rate Diagrams

System dynamic models are based on two fundamental concepts as discussed in Chapter 27: levels (some-

times known as stocks) and rates (sometimes known as ﬂow rates). Levels represent accumulations within

a system and will persist even if all activity within the system ceases for a while. For example, in Figure

33.6 and Figure 33.7, customers are clearly a level since, even if the company ceased to recruit any new

customers, the customers that they do have will remain, at least for a while. Rates or ﬂow rates represent

activity within the system and these dropped to zero when activity ceases. It should be obvious that the

number of new customers recruited in any period is a rate, as is the number of customers lost in a period.

Advertising expenditure is also a rate and it will vary from period to period depending on the policy of the

company.

Figure 33.8 shows a level-rate diagram based on the causal loop diagram in Figure 33.6 using the

symbols provided by the Powersim software (www.powersim.com). Similar symbols are used in other

system dynamics software: levels are shown as rectangles and rates are shown as pipes with valves on them.

New customers are seen as arising from a cloud and this is to indicate that this source is not included in the

model; that is, the cloud represents the system boundary. Likewise lost customers disappear into a cloud

since we are not intending to model their destination. The main physical ﬂow of the model represents

customers and it should be clear that if the inﬂow of new customers exceeds the outﬂow of lost customers,

the number of customers will increase. In a system dynamics model, a level will always have at least one

outﬂow or at least one inﬂow. In our example the level has one inﬂow and one outﬂow. Advertising

expenditure is also modeled as a ﬂow rate and this is seen as an emerging from a cloud and disappearing to

a cloud because the model is not concerned with where this money comes from, nor where it goes to. The

rate of expenditure on advertising is a function of the actual number of customers and the target number

of customers. In addition, like all businesses, there is a limit to their expenditure and so Figure 33.8 has

an extra parameter—the maximum advertising spend each month. Finally, the diagram also includes two

diamond shapes of which one represents the number of customers they would like to have (customer

target) and the other represents the effectiveness of a particular advertising campaign. The diamonds

indicate that these are parameters for the model.

As discussed in Chapter 27, a system dynamics model consists of two main types of equations: level

equations and rate equations. When a modern system dynamics package such as Powersim, Stella/IThink

Lost customer rate

Loss proportion

New customer rate

Ad spend rate

Customers

Customer target

Ad effectiveness

FIGURE 33.8 Powersim diagram for advertising to gain new customers.