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

A RENA C ONTACT C ENTER E DITION U SER ’ S G UIDE
8
• •
•
•
•
express ideas and objects. Historically, modeling has taken many forms: from
communicating through wall paintings to writing complex systems of mathematical
equations for the flight of a rocket through outer space. As a matter of fact, the progress
and history of science and engineering are reflected most accurately in the progress of our
ability to develop and use models.
One of the major elements required in attacking any problem is the construction and use
of a model. We use models because we want to learn something about some real system
that we cannot observe or experiment with directly—either because the system does not
yet exist, or because it is too difficult to manipulate. A carefully conceived model can
strip away the complexity, leaving only that which the analyst finds important. Such a
model can take many forms, but one of the most useful—and certainly the most often
used—is simulation.
Likewise, the concept of systems plays a critical role in our modern view of the world.
The fundamental idea of thinking about the world in terms of systems and trying to take
the systems approach to attacking problems has become so ingrained in contemporary
practice that we tend to take it for granted. The systems approach tries to consider total
system performance rather than simply concentrating on the parts [Weinberg, 1975]; it is
based on our recognition that, even if each element or subsystem is optimized from a
design or operational viewpoint, overall performance of the system may be suboptimal
because of interactions among the parts. The increasing complexity of modern systems
and the need to cope with this complexity underscore the need for engineers and managers
to adopt a systems approach to thinking.
Although complex systems and their environments are objective (i.e., they exist), they are
also subjective (i.e., the particular selection of included (and excluded) elements and their
configuration is dictated by the problem solver). Different analyses of the same objective
process or phenomenon can conceptualize it into very different systems and environments.
For example, a telecommunications engineer may think of a contact center system as a
collection of trunk lines and routing scripts. The contact center director, however, is more
likely to view the system as the combination of phone lines, scripts, contacts, agents, and
schedules. The vice president in charge of contact center operations may see the system as
the collection of all the centers her company runs/along with all outsourcers under
contract. Hence, several different conceptualizations of any particular real-world system—
and thereby several different models—can simultaneously exist.
System elements are the components, parts, and subsystems that perform a function or
process. The relationships among these elements and the manner in which they interact
determine how the overall system behaves and how well it fulfills its overall purpose.
Therefore, the first step in creating any model is to specify its purpose. There is no such
thing as the model of a system: we can model any system in numerous ways, depending
on what we wish to accomplish. Both the elements and the relationships included must be