Rockwell Automation Arena Contact Center Edition Users Guide - Manual (Page 22)

A RENA C ONTACT C ENTER E DITION U SER ’ S G UIDE
14
• •
•
•
•
On the other hand, we try to make the model as accurate as possible. Consequently, we
must simplify reality—but only to the point where there is no significant loss of accuracy
of outputs with respect to the study’s objectives.
We want to design a model of the real system that neither oversimplifies the system to the
point where the model becomes trivial (or worse, misleading) nor carries so much detail
that it becomes clumsy and prohibitively expensive. The most significant danger lies in
having the models become too detailed and including elements that contribute little or
nothing to understanding the problem. Frequently, the analyst includes too much detail,
rather than too little. The inexperienced tend to try to transfer all the detailed difficulties in
the real situation into the model, hoping that the computer will somehow solve the problem.
This approach is unsatisfactory: it increases programming complexity (and the associated
costs for longer experimental runs), and it dilutes the truly significant aspects and relation-
ships with trivial details. The definition of the model boundary is usually a tradeoff
between accuracy and cost. The greater the degree of detail to be modeled, the more pre-
cise and expensive the required input data. Therefore, the model must include only those
aspects of the system relevant to the study objectives.
One should always design the model to answer the relevant questions and not to imitate
the real system precisely. According to Pareto’s law, in every group or collection of
entities there exist a vital few and a trivial many. In fact, 80% of system behavior can be
explained by the action of 20% of its components. Nothing really significant happens
unless it happens to the significant few. Our problem in designing the simulation model is
to ensure that we correctly identify those few vital components and include them in our
model.
Once we have tentatively decided which components and variables to include in our
model, we must then determine the functional relationships among them. At this point, we
are trying to show the logic of the model; i.e., what happens. Usually we use a flowchart
or pseudo-code to describe the system as a logical flow diagram.
Experimental design
We have defined simulation as being experimentation via a model to gain information
about a real-world process or system. It then follows that we must concern ourselves with
the strategic planning of how to design an experiment (or experiments) that will yield the
desired information for the lowest cost. The next step, therefore, is to design an experi-
ment that will yield the information needed to fulfill the study’s goal or purpose.
The design of experiments comes into play at two different stages of a simulation study. It
first comes into play very early in the study, before the model design has been finalized.
As early as possible, we want to select which measures of effectiveness we will use in the
study, which factors we will vary, and how many levels of each of those factors we will
investigate. By having this fairly detailed idea of the experimental plan at this early stage,
we have a better basis for planning the model to generate the desired data efficiently.