TUTORIAL: TOOLS AND METHODOLOGIES FOR EXECUTING SUCCESSFUL SIMULATION CONSULTING PROJECTS

Proceedings of the 2012 Winter Simulation Conference

C. Laroque, J. Himmelspach, R. Pasupathy, O. Rose, and A.M. Uhrmacher, eds

TUTORIAL: TOOLS AND METHODOLOGIES FOR EXECUTING SUCCESSFUL

SIMULATION CONSULTING PROJECTS

Carley Jurishica

Nancy Zupick

Rockwell Automation Rockwell Automation

180 Harvester Drive, Suite 190 2100 Corporate Drive, Suite 550

Burr Ridge, IL 60527, USA Wexford, PA 15090, USA

ABSTRACT

When problems are extremely complex, highly variable and too big for simple calculations, a simulation

project solution should be considered. Not surprisingly, the resulting project endeavor will also be com-

plex and should be managed with a clear strategy and attention to detail. This paper will extend beyond

basic project tips by providing specific tools and methodologies to help simulation leaders execute suc-

cessful simulation consulting projects inside or outside their organization.

1 INTRODUCTION

This paper is organized in three key sections, Gathering Requirements, Building the Model and Deliver-

ing Results. In the “Gathering Requirements” section we will highlight how to identify a project and

move from an initial scope to a final detailed functional specification. The “Building the Model” section

will provide specific tips for managing the model building effort. Finally, the “Delivering Results” sec-

tion will focus on creating models that are easy for analysts to run scenarios and understand project re-

sults. Figure 1 provides a high-level view of the project life cycle and common deliverables from each

phase. These phases and deliverables will be discussed in more detail throughout the paper.

Gather

Requirements

BuildModel

Deliver

Results

Functional

Specification

ModelLogic

Animation

UserInterface

Model

Documentation

Analysis

Report

ProjectDeliverables

Software

Figure 1: Simulation project phases and deliverables

Simulation is a vast field and may encompass a variety of interpretations. Throughout this paper,

when we mention simulation, we are referring to a broad collection of methods and applications to mimic

the behavior of real systems, usually on a computer with appropriate software (Kelton, Sadowski, and

Jurishica and Zupick

Swets 2010). We have attempted to provide tools and methodologies that are independent of any particu-

lar software application. We do represent Arena simulation software from Rockwell Automation and in

some instances the examples provided are specific to the Arena software application.

We will use various terms throughout this paper. Some key definitions are provided below.

Simulation Consulting Project Manager Individual responsible for managing the simulation pro

ject and the simulation consulting team.

Simulation Consultant Any individual whose primary expertise is in executing simulation projects.

Client The end user of the simulation model or model information for the purposes of decision-

making.

Simulation Consulting Project An engagement between the simulation consulting project manager

and the client for the purpose of building a simulation model that will be utilized for decision making.

Simulation Team Member Any individual involved directly or indirectly in the simulation consult

ing project.

2 GATHERING REQUIREMENTS

2.1 Is Simulation the right Tool?

Simulation is another tool in your toolbox for problem solving. Not all problems will require or even

benefit from a simulation study. Defining the problem and having a clear understanding of the project ob-

jectives should be the first step for the simulation team.

With a clear project objective, it can be determined which tools will help achieve the goals. Under-

standing how different tools and methodologies should and should not be applied is a necessary skill on

any project team. As noted by Balci (2011), a large-scale M&S (modeling and simulation) application

development requires many areas of expertise including simulation modeling methodology, software en-

gineering, statistics, systems analysis, project management, and problem domain-specific knowledge.

In Table 1 we provide a guideline for when simulation might be appropriate for a project. There are

several common characteristics of simulation projects. These characteristics, along with example situa-

tions and why simulation is a good fit are provided.

Table 1: Guideline for determining if simulation is the right tool for a project.

Characteristic Example Why Simulation?

Highly Variable

Processes

Healthcare. A healthcare manager

needs to determine the emergency

department (ED) bed capacity. The

ED has variable patient arrival rates

and variable staff service times. Var-

iability also exists in equipment fail-

ure and repair times.

A key advantage of simulation is

the ability to handle variability.

Variability is inherent in all sys-

tems. It disrupts systems. Without

variability, performance would of-

ten be easy to predict. Accurately

capturing system variability will re-

sult in better analysis and decision

making.

Jurishica and Zupick

Process Interde-

pendencies

Manufacturing. A plant manager has

been tasked to increase throughput by

5%. There are several areas that

might be improved, but she is unsure

on which area she should focus. If

she makes changes to improve the

performance of one machine on the

line, it is difficult to know how it will

impact the upstream and downstream

processes.

Simulation allows analysts to study

system interactions. Processes

should not be analyzed in a silo. All

systems have interdependencies.

Users can change one or more vari-

ables in the model and clearly un-

derstand how the entire system is

impacted.

Identify Bottle-

necks

Restaurant Drive-through. A fast

food restaurant has recently heard

complaints from customers about

how long they are waiting in the

drive-through line. Cars have been

alking and reneging from the line.

The manager would like to test add-

ing a lane and changing the way staff

handle customers prior to making the

real-world changes.

Queueing theory is at the core of

simulation. The average time enti-

ties spend waiting for resources and

the average numbers of entities

waiting for a resource are key out-

put statistics of a simulation study.

These statistics are automatically

calculated by the simulation soft-

ware. Experiment with the model to

determine which changes will re-

duce the bottleneck in the real

world.

Analysis Over

Time

Airport Security. An airport chief

operations officer is trying to deter-

mine how to staff the airport security

checkpoint. Arrival of travelers to

security varies by time of year, day

of week and time of day.

Simulation allows you to look at a

system dynamically over time. Re-

lying on average values for planning

can be misleading. Use simulation

to plan staff schedules and resource

availability by time of day, week or

any planning horizon.

Animation Mining. A mining operations man-

ager needs to demonstrate the impact

of changing the number of trucks and

shovels on the overall mining

throughput. He would like to clearly

present to his management team the

system bottlenecks, resource utiliza-

tions over time and how future

changes will impact the overall sys-

tem using an animation of the mine.

Animation builds confidence. See-

ing the system dynamically change

over time with realistic visuals cre-

ates system buy-in and agreement

among decision-makers. A valid

model, backed by real data and

compelling animation, will help

leaders to make decisions.

Jurishica and Zupick

Process Com-

plexity

Call Center. A call center manager

needs to improve the service level of

his call center. There are many dif-

ferent types of callers. Callers speak

different languages. The request for

service may arrive to the call center

via email, fax or phone. It is difficult

for him to wrap his mind around all

the dynamic business rules. Deter-

mining the ideal staffing and process

flow is critical, but the complexity is

overwhelming.

Simulation projects can handle

complexity. Simulation models are

dynamic and based on real-world

variability over time. Making deci-

sions regarding complex systems

using a simple spreadsheet and av-

erage values can be dangerous.

With highly complex systems,

simulation will provide more de-

tailed information to allow for better

decision making.

Sometimes the desire to apply simulation will cause individuals to apply it to all situations. This can

result in a project being more complicated and costly than necessary and lead upper management to have

a poor opinion of simulation. Simulation is powerful. Understanding when a project will and will not

benefit is an important skill. Consult experienced simulation experts if you are not certain if simulation is

the correct tool for a problem.

2.2 Scope of Work

Once it has been determined that simulation is a proper approach, the simulation team must scope the pro-

ject and develop a detailed functional specification. The final functional specification will be a roadmap

for model development and act as a written agreement among all simulation team members.

To ensure the final functional specification contains all key information, a formal process for re-

quirements gathering is recommended. First, the simulation consulting project manager must work with

the client to identify all process owners and participants that should be interviewed as a part of the infor-

mation gathering exercise. We recommend a scope of work template, similar to the one provided in Ta-

ble 2, as a starting point.

Table 2: The Scope of Work template is a guide for gathering requirement information. This information

is used to create the functional specification that will serve as the project roadmap.

Background

Provide any background information on the company and problem.

Project Objectives

Define the goals of the study.

What questions are you trying to answer?

 Major capital expenditure decisions – Should we invest in new equipment?

 Bottlenecks – How can we reduce the queueing at the resource?

 Resource planning – What is the ideal staff schedule for the week?

 New system design – How should we layout the system? How much

equipment do we need? How much inventory do we need?

 Major changes to an existing system – How will the changes impact the

current system? How can we minimize the disruption and maximize the

change effect? Is our design adequate?

Jurishica and Zupick

Process Flow and System Specifications

In order to build a valid model, the simulation team must map out process. Re-

gardless of the industry (healthcare, government, manufacturing, etc.) there is a

movement of entities (people, widgets, orders, etc.) through the system. This flow

must be documented.

Below are examples of leading questions to ask process owners and participants.

 How does an entity move through the system?

 What kind of constraints are in the system?

 What business rules need to be considered in this process?

 Are there exceptions to how an entity might be handled at different steps

in the process?

 What types of bottlenecks currently exist in the system?

Ask a lot of questions during this phase! This is a significant time of system dis-

covery during the project life cycle. Developing a final process flow chart using a

professional diagramming application is highly recommended.

“What-if” Scenarios

Define the “what-if” scenarios that will be tested using the model. Understanding

the questions that need to be answered by the model will be of particular im-

portance to the model builder. This information will drive the detail and complexi-

ty of the model.

 What if we add new machines?

 What if we increase equipment speeds?

 What if we change our product mix?

 What if we change our resource schedules?

 What if we change our facility layout?

 What if the demand for our services changes?

 What happens if we change the capacity of our system?

 What if we modify specific business rules?

Key Performance Indicators (KPI)

Defining the KPIs is critical. When running “what-if” scenarios, these outputs will

be compared among scenarios to assist with decision making. Below are some

common KPIs.

 Resource utilizations

 Total throughput

 Work in process

 Cycle time

 Costs

 Shortages

 Time in queue

 Number in queue

Jurishica and Zupick

Animation Requirements

Define the simulation animation requirements. Depending on the simulation soft-

ware used for the project, the animation opportunities will vary. It is important to

define the animation expectations at the onset of the project.

Below are several options that may be available.

 Statistical reports only

 Live data dashboards including plots, charts and variable animation that

update while the simulation runs

 2D animation

 3D animation

Assumptions

Managing the complexity of the simulation project and model is a developed skill.

We can provide endless advice, but as noted by Sadowski (1991), there is no sub-

stitute for experience. Knowing what details to include and exclude from the mod-

el must be defined and agreed on. Having written documentation of the project as-

sumptions is important. Below are some generic sample assumptions.

 The model assumes that all resources behave the same. The model will

not be concerned that different workers that have different skills.

 Rare weather events that may disrupt operations will not be modeled.

 There is an infinite supply of raw materials. This is not a constraint in the

operation and we will assume there is always availability of raw materials.

Deliverables

Define the final project output. The simulation consulting project manager and the

client must agree on specific deliverables before the project begins. Below are

possible deliverables.

 Functional specification

 This document will serve as a contract between the simulation pro-

ject manager and the client. All known details about the project

should be documented in the functional specification.

 Simulation model logic

 Simulation model animation

 Model documentation

 User interface

 Simulation consultants may develop an easy-to-use interface for

entering data and reviewing results.

 Software licensing

 If the client will be running scenarios on their own, they will need

access to the model and software to run the model.

 Analysis report

 A detailed report of all scenarios runs and results. Specific rec-

ommendations to system improvements based on the results of the

scenario analysis may be included.

The scope of work template requires input from many different simulation team members. System

managers, model builders, key stake holders and people working in the system will all have insights.

100

Jurishica and Zupick

This phase of the consulting engagement can be quite eye-opening. New system pain points, processes

and behaviors are often discovered when the team is forced to look at the process in such detail.

2.3 Functional Specification

With the scope of work information, the simulation consulting team is now ready to develop a detailed

functional specification. Whether the consulting project is between two parties in the same organization

or between two different companies, a functional specification should be developed. All details from the

scope will be clearly defined in the functional specification. Below are the key sections, at a minimum, to

include in the functional specification.

 Project sign off agreement*

 Background

 Project objectives

 Process flow and system specifications

 “What-if” scenarios

 Key performance indicators

 Data requirements*

 Animation requirements

 Assumptions

 Deliverables

 Timeline*

 Payment terms*

 Additional terms and conditions*

Many of these sections have been discussed as a part of the scope of work, but several new areas are

needed for the functional specification. The new areas are noted in the list above with an asterisk “*”.

A critical part of the functional specification is the project sign-off agreement. The simulation con-

sulting project manager and the client must sign the functional specification. This ensures that both par-

ties agree on the purpose of the project and all details surrounding the simulation model. As Sadowski

(1991) notes, the simulation consulting project manager needs to know what the client expects and the

client needs to know what the simulation consulting project manager will deliver. If a new request re-

garding the project surfaces, an addendum to the functional specification should be created and signed.

Figure 2 provides a sample project sign off agreement.

Project Sign Off Agreement

[Client] agrees to engage with [simulation consultants] to develop a simulation model per the

specifications provided in this document. [Insert any additional detail regarding project]

_______________________

Client Name Date

Title

Company

_______________________

Simulation Consulting Project Manager Name Date

Title

Company

Figure 2: Project sign off agreement

101

Jurishica and Zupick

Once the project has been defined, a timeframe for the simulation project should be estimated. The

estimated timeframe along with milestone dates should be established. A regular meeting schedule

should also be agreed on between the simulation consulting project manager and the client to ensure the

project stays on track. Dates should be adjusted as necessary throughout the life of the project.

Depending on the nature of the engagement, project payment terms may be necessary. The payment

terms should be included with the functional specification. They provide the total cost to the client for the

described project.

Finally, the functional specification should include any additional terms and conditions. Figure 3

provides example terms and conditions. Any particular legal terms that may need to exist between com-

panies can also be listed in this section.

Simulation Terms and Conditions

1. The client agrees to supply all requested data and information supporting this

project to the simulation consultants in a timely manner. The simulation con-

sultants will provide a complete list of requirements during the initial kickoff.

2. The client agrees to provide a single project management contact. This point of

contact will facilitate project meetings, arrange for on-site interviews, and en-

sure that project reviews and meetings are conducted in a timely manner.

3. Changes to the scope of work requested by the client throughout the duration of

the project will be immediately identified and communicated through simula-

tion project manager. This prevents schedule overruns due to unnoticed chang-

es in the scope of work. Estimates of the cost, scope and schedule of the chang-

es will be provided when a change in scope is identified. If there is a change of

scope, the simulation consultants will not begin work on the proposed change

until the client provides a change order, letter of intent, or e-mail approving the

change.

4. The client agrees to provide a signoff of the functional specification.

5. The client agrees to provide a signoff of model completion.

6. Prices do not include travel expenses, which will be invoiced as incurred.

Figure 3: Sample Simulation Terms and Conditions

A challenge with any simulation project is managing complexity. Simulation is powerful and you can

model to the smallest level of detail. Too much detail will slow the model building effort, model testing

and validation. Identifying the appropriate level of detail to meet the project objectives is a developed

skill. We agree with Sadowksi (1991) that the natural tendency of the novice modeler is to include too

much detail, whereas the more experienced modeler tends toward greater abstraction. The functional

specification should guide the model builder and help them to provide the right level of detail in the mod-

el.

3 BUILDING THE MODEL

As with starting anything, beginning to build a simulation model can be overwhelming. With a com-

pleted functional specification, the process should be easier. As mentioned, the functional specification

will serve as the roadmap for the model building process.

Below are factors to consider when starting the model building process.

 Who will build the model?

 Will there be a user interface (UI) to the model?

 Will data be read into the model?

102

Jurishica and Zupick

 Who will collect the data?

 Where is the data stored?

 How will the model outputs be extracted?

 How will the model be utilized?

 Will there be more than one model or will one be used to analyze all “what-if” scenarios?

If more than one person will be involved in building the model, their roles should be clearly defined

at the project start. Project management, data collection, model building and UI development roles will

all need to be defined. On small projects, these roles may be the responsibility of only one individual, but

on larger, more complex projects, there may be multiple people involved across different teams.

Generally the framework for the input and output of data can be created as the model building process

commences. In some cases a custom UI is not necessary and the analyst will choose to change inputs di-

rectly in the software application and review the reports directly from the software application. A custom

UI can help speed up model experimentation and allow the simulation consultant to easily hand off a

model for analysis by someone not familiar with the simulation software application. Simulation consult-

ants who frequently deliver models to clients will likely have a pre-built framework for interfacing with

the model. Most common, interfaces are developed in Microsoft Excel, Access or a VB form. If the

model and UI will be delivered to the client, special attention should be paid to the usability of the inter-

face along with documentation on how to run the model via the interface.

The UI can also be used as a guide for data collection. The simulation consulting project manager

and the client must agree on who is responsible for collecting data to support the model. This role varies.

Sometimes the client prefers to assume responsibility and other times a simulation consultant will take the

lead. Data collection can be overwhelming and a project bottleneck. Someone must be assigned owner-

ship. It is best practice to list the known data needs and this responsibility in the functional specification.

The model building itself can be divided among more than one individual, however it is imperative

that one member of the team be responsible for managing the collaborative effort and for maintaining the

model. Whether one or more individuals are building the model logic, it is important to:

 Maintain easy to understand naming conventions.

 Build the model in a modular format.

 Review the model on a consistent basis to ensure that the logic design mimics the real system

or reflects a proposed system as closely as possible.

 Provide model documentation.

 Utilize a simple method of version control in order to document model progress as well as to

provide a backup version should anything happen.

 Maintain backups of the model versions on multiple machines and/or servers.

Establishing consistent naming conventions throughout the model logic will make it easier to under-

stand, especially if multiple people will be building the model. In Arena, a typical naming convention is

to place an alpha prefix before the name of a modeling element. For example, attribute names may begin

with “a_” and resource names begin with “r_”. No matter what software application is used, it is recom-

mended to establish naming conventions prior to building the model.

A modular approach to model development allows the simulation consultant to keep the model orga-

nized and makes it easier to debug as code is appended to the model. The functional specification should

help the simulation consulting project manager to identify appropriate sections of the system that may be

developed independently. For example, if an emergency department model is going to be built, the model

builder might first develop and test the upfront registration process. Once this is code is established and

verified, they may move onto the initial nurse and physician assessment portion. The model builder

should not attempt to develop the logic for the entire system at once. It is even more important to build

103

Jurishica and Zupick

the model in a modular format when the effort is collaborative. This avoids duplicate model building and

makes it easier to copy code from a smaller model to the master project file.

It is advisable to define as many fixed aspects of the model before beginning to define the logic. For

example, in Arena defining the resources, variables, attributes and other model elements prior to building

the model logic that will reference those elements, will allow for more efficient model development.

While Arena allows the user to create elements on the fly, defining them ahead of time keeps the model

builder focused on developing logic rather than trying to determine what to call the next resource. A sim-

ilar approach in other software applications will likely prove useful.

At the beginning of the project, the client and the simulation consulting project manager should agree

on a regular schedule for reviewing the model progress. Depending on the project, it may be necessary to

meet every other day or once a week to review the modeling efforts. These meetings ensure the project is

progressing as expected and on track per the timeline in the functional specification. Reviews also allow

the simulation team members to ask questions and get further clarification if necessary. In some cases,

the scope of the project may change. It may be necessary to go back to the functional specification and

amend the project definition.

Documentation is a must! Documenting the model logic and creating documentation that describes

the model and how to run it makes it easier to maintain and update in the future. Table 3 provides com-

mon simulation project documentation.

Table 3: Simulation project documentation

Document Description

Functional Specification The functional specification provides a com-

plete overview of the project scope. It is a

roadmap for the project execution.

Model Logic Documentation In the simulation software application, the

model builder must document their code. The

logic, what is does, how it may need to be up-

dated, how it affects other logic and more

should be noted.

Model Run Documentation Documentation on how to use the interface, run

the model, change inputs and review outputs

should be developed. If multiple models are

developed from the project, clear notes on what

each model does should be established.

Project Analysis Report After the experimentation and analysis is com-

plete, a report containing the simulation outputs

for each scenario should be developed. Any

specific recommendations from the study

should be included in the analysis report.

It is important to save the model frequently and to create versions of the model at various stages of

the process. This allows for security backups and the ability to return to a specific stage of the modeling

effort if needed for debugging purposes or to create variations of the model. Having the model backed up

on more than one machine, a server, or a DVD is also recommended; hard drives crash and laptops are

lost or stolen.

Once the model is complete, verification and validation begins. In most cases, the verification has

been taking place during the model construction. Verification is ensuring that the model behavior makes

sense; entities are moving in the direction they should be and process steps are taking place as expected.

The animation will aid in model verification. Validation will be a simulation team effort. The simulation

consulting team and the client team must agree that the simulation model outputs are close enough to the

104

Jurishica and Zupick

real system outputs before experimentation. If the model cannot be validated then it cannot be used for

proper analysis.

4 DELIVERING RESULTS

Once the model is complete and validated, model analysis and experimentation can take place. As

part of the functional specification, the simulation consulting project manager and the client should have

agreed upon the project deliverables. The simulation consulting team may have agreed to provide a simu-

lation model and UI to the client and the client to take the responsibility of running scenarios and analyz-

ing the results. On the other hand, the consulting team could execute the scenarios defined in the func-

tional specification and provide a written report to the client with the key performance indicators and

recommendations from the scenarios. In either situation, the simulation team will need to collaborate to

ensure the model experimentation is run and interpreted correctly.

In the case where the model is handed off to the client, it is important to make sure that the contact,

who will be running and working the model, knows how to use it. It is critical to formally train the end

user and that the model builder has designed an easy to use UI. It is also important to clearly document

how to run the model and review the results. Figure 4 is a sample Excel UI for a simulation model. Fig-

ure 5 is an example of a VB user form that prompts the end user for inputs. Figure 6 is a web-based inter-

face developed for a user to input and view the results of a simulation model over the web.

Figure 4: Excel user interface example

Figure 5: VB user form input example

105

Jurishica and Zupick

Figure 6: Web-based user interface example (developed by Systems Navigator,

www.systemsnavigator.com)

Part of the consulting deliverables may be a model analysis report. In this case, the simulation con-

sulting team agreed to run the scenarios defined in the functional specification and provided a detailed re-

port with the results of the simulation. The analysis report may include, but is not limited to the sections

noted in Table 4.

Table 4: Analysis report contents

Analysis Section Description

Executive Summary Provides a brief overview of the project problem, objectives and rec-

ommendations. Someone who is not familiar with the project should

be able to read the executive summary and understand the goals and

conclusion.

Background Any necessary background on the project, company and problem.

Model Building and

Validation

This section of the report should address the model building process

and a discussion of the validation process to promote model credibil-

ity (Law 2003).

“What-if” Scenario

Results

Provides a thorough analysis of the scenarios that were defined in

the functional specification along with the simulation model results

for the KPIs defined.

Conclusions and

Recommendations

Provides analysis and recommendations for the project objectives

based on the scenario results.

106

Jurishica and Zupick

At the end of the project, the functional specification, model analysis report, supporting documenta-

tion and simulation model will provide a complete overview of the project. These project files should be

preserved by the simulation team as a record of the project.

5 CONCLUSION

Executing a simulation project is not trivial and the simulation project will never go exactly as planned.

Scope will change, data gathering will be more difficult than initially expected, the model will be chal-

lenging to validate and the team will be frustrated at times. Still, establishing a framework for conducting

projects and following this framework with rigor will increase the likelihood of success. After each pro-

ject, the simulation consulting team should discuss what went right and what went wrong. Tools and

methodologies should be continuously updated and improved.

REFERENCES

Balci, O. 2011. “How to Successfully Conduct Large-Scale Modeling and Simulation Projects,” In Pro-

ceedings of the 2011 Winter Simulation Conference, edited by S. Jain, R. R. Creasey, J. Himmel-

spach, K. P. White, and M. Fu, 48-55. Piscataway, New Jersey: Institute of Electrical and Electronics

Engineers, Inc.

Kelton, D., Sadowski, R., and Swets, N. 2010. Simulation with Arena. 5th ed. New York: McGraw-Hill.

Law, A. 2003. “How to Conduct a Successful Simulation Study,” In Proceedings of the 2003 Winter Sim-

ulation Conference, edited by S. Chick, P. J. Sanchez, D. Ferrin, and D. J. Morrice, 66-70. Pisca-

taway, New Jersey: Institute of Electrical and Electronics Engineers, Inc.

Sadowski, R. 1991. “Avoiding the Problems and Pitfalls in Simulation,” In Proceedings of the 1991 Win-

ter Simulation Conference, edited by B. L. Nelson, W. D. Kelton and G. M. Clark, 176-182. Pisca-

taway, New Jersey: Institute of Electrical and Electronics Engineers, Inc.

AUTHOR BIOGRAPHIES

CARLEY JURISHICA studied industrial engineering at Northwestern University. In 2008 she received

her Masters of Engineering Management from Northwestern University. She has been working for

Rockwell Automation with the Arena simulation software product for over 8 year. She started her Arena

career as a simulation consultant, teaching Arena training classes and executing projects for external cli-

entele. From 2008 – 2010 she spent time in a sales role, selling Arena software and services. Currently

she is the Arena Product Manager. Her email address is [email protected].

NANCY ZUPICK (formally Swets) received her bachelor’s degree in industrial engineering from the

University of Pittsburgh. In 1997 she joined Systems Modeling (later acquired by Rockwell Automation)

in the technical support group where she worked for over a decade assisting clients with their simulations

in a wide array of industries. From 2008-2011 she was the Requirements Analyst for Arena. Currently,

she is the Arena Simulation Consulting Manager responsible for a team who provides training, mentoring

and turn-key projects to Arena customers. She is also co-author of the 5

edition of the Simulation with

Arena textbook. Her email address is [email protected].

107