rules) by learning and adapting to the environment.
Jennings (2000) too emphasizes the need for
presence of agent attributes that are active rather
than purely passive. Active agent attributes are
essential for autonomous behaviour by which agent
can make independent decisions.
We adopt Bonebeau’s (2001) view to identify
agents in this system. The agent-set is a mixture of
autonomous, semi-autonomous and dependent
agents. Figure 1 has the topology of the agent based
model used in this study. Each agent is explained in
detail in the following sub sections.
3.1.1 Tickets
In IT production support, a ticket is an abstract unit
of work. Ticket can be any one of events, incidents,
problems, access requests and change requests.
Based on the business needs, tickets have to be
handled within specified time as directed by the
Service Level Agreements (SLAs). Typically, the
SLA terms are dependent on the ticket’s priority.
Priority is a composite of the urgency of the ticket
(how soon the business needs to be resolved) and
impact (how many users are affected by the ticket).
Also, tickets vary based on the type of skill required
for resolution. A “Technology Tower” signifies a
method of work organization usually employed in IT
production support where issues are grouped along
technical domains. Examples of technology tower
could be “.net”, “Java”, “SQL” etc. Naturally, the
skills needed to resolve tickets belonging to each of
these technology towers are different. While the type
of skill needed for resolution determines the ticket’s
technology tower, difference in level of skill needed
for resolution determines the level of support tickets
are routed to or eventually escalated to.
Since ticket handling is a knowledge intensive
task, a repository of all the information known about
tickets is maintained. The repository can take the
form of a set of standard operating procedures
(SOPs) or entries in Known Error Database
(KEDB). The effort needed to resolve tickets has
been observed to follow Power Law Distribution
(PLD). Based on the above described characteristics
the list of ticket attributes are shown in Table 1.
3.1.2 Resources
Despite the ongoing drive towards automation,
ITSM is majorly a human centric system. Tickets are
handled by resources, which are categorized into
multiple teams based on their skills and
specializations. In a typical IT production support
setup, tickets are responded and resolved by
resources. Response includes identifying, logging,
categorizing, prioritizing, routing and conducting
initial diagnosis of tickets. Whereas, Resolution
relatively is a more complex task. It involves
performing a set of steps to resolve a ticket. And, it
is done at the level of support that corresponds to the
ticket’s required resolution skills.
As given in Table 1 resources are characterized by a
set of static and dynamics attributes in our model.
While, technology tower, competency, cost,
likelihood of absence are the attributes that remain
static over the simulation. In contrast, ticket, shift,
net effort are the attributes that change dynamically
with the environment. The support structure support
in the model comprises of two technology towers
with teams divided into three and two levels of
support. Further, the support service is to be
provided 24x7, divided into 3 shifts of 8 hours each..
3.1.3 KEDB Agent
It is critical for any IT production support
engagement to record the knowledge acquired by
human resources in the process of handling tickets to
the extent possible. Of the multiple knowledge
management processes proposed in ITIL v3 (Cannon
et al, 2007), maintaining a well recorded Known
Error Database (KEDB) is vital to conduct efficient
IT service operations.
The purpose of a Known Error Database
(KEDB) is to store the knowledge of tickets– and
how they were overcome – to allow quicker
diagnosis and resolution when they recur (Cannon et
al, 2007). The first response to any service outage is
to quickly fix the issue and bring the system back up
to ensure service availability. The issue would then
be sent for root cause analysis, where a decision to
implement a change to prevent future occurrences of
incidents or update the KEDB with a workaround is
taken. The cost benefit analysis determines if there is
a business case for a permanent solution.
In our model, KEDB, as an agent, is
characterised by the following attributes. Integral to
the KEDB is its software efficiency which identifies
a new incident and matches with a KEDB record if it
exists. We codify the search efficiency of KEDB on
a scale of 0 to 1. The number of records/articles in
the database is the second attribute. The last attribute
is the overall efficiency of KEDB which directly
impacts the average resolution time. It is derived
from the other two attributes (number of articles and
search efficiency).