IT Incident Management and Analysis Using Non-classical Logics

. The classification and the proper incident handling in an IT environment are strategic to remain competitive in corporations. Service Desk technicians with knowledge and expertise can often have conflicting beliefs in their analysis. This study aims to apply Paraconsistent Logic to treat contradictions directly in the classification of incidents in IT, helping managers to improve the quality of services they provide to users through the efficiency of the Service Desk in decision-making.


Introduction
Organizations currently rely increasingly on various IT (Information Technology) services for maintenance of their operations [1]. Proper management of these services is of paramount importance because in many cases the services are subject to incidents, which may be defined as unplanned events that have the potential to lead to an accident. Although the concept of incidents seems to deal with faults that occurred or that may occur and/or may be foreseen by the IT team, in several areas as an example: telecommunications, infrastructure and defects in software.
Categorization and correct classification of incidents is of paramount importance, as they may cause stoppage of important services and result in financial losses and even cause impact on the organization's image. Classification of incidents is the act of identifying the exact kind of incident and what components are involved, as well as determining the incident priority, which is, for example, classifying it as critical or not.
However, big part of the technical support in IT is run by contracted companies that have no commitment with the organization's business and most importantly, are not properly prepared in what regards the correct classification of incidents.
The more precise the categorization and the classification are, the faster will the service for the requesting user be, and it can also help in referring it for more advanced support teams to resolve the issue.
Depending on the size of the operation, the Service Desk can have many technicians of level 1 (first contact with the user), and differences in classification of incidents occur frequently, i.e. the same type of incident can be classified as critical by a technician and as not critical by the other. Therefore, classification is naturally subject to inconsistencies. On the other hand, it is well known that Classical Logic cannot deal with contradictions, at least directly. So we have to seek suitable logical systems, The goal of this work is to use Paraconsistent Annotated Evidential Logic E (Logic E) [2] to address inconsistencies in the classification of IT Incidents, helping managers to maintain the quality of services used by the organization for the increase of the efficiency in the Service Desk area. We used the ITIL (Information Technology Infrastructure Library) as a management tool, which is a framework of better practices that deal with Incident Management in IT and the ISO/IEC 20000, which addresses this concept depicting Systems Certification of Services Management in IT.

ITIL -Information Technology Infrastructure Library
ITIL describes a set of best practices for managing IT services, improving the relationship between the strategic management of the company's business to these services [3].
Incident Management focuses primarily on restoring the service as fast as possible, minimizing the negative impact on business. A workaround or quick fix, which allows the client to return to work and ensures that the highest levels of availability and quality of service, according to the service level agreements (SLA) [4].
The term incident [5] is any event that is not part of the standard operation of a service and that causes or may cause interruption or reduction of its quality.
The objectives of the Incident Management, according to ITIL, are: ─ Re-establishing the IT services as soon as possible in accordance with the service level agreement; ─ Establishing workaround solutions, while identifying the root of the problem; ─ Reducing the impact of the incident on the operations of the business; ─ Maintaining communication between IT and users about the state of the incident; ─ Ensuring the highest level of quality of services rendered, according to the ANS.

ISO/IEC 20.000
ISO/IEC 20000-1:2011 defines the requirements for the IT services provider to manage its processes and delivered services with acceptable quality for its customers. It is divided into: Management Systems and Management Processes, where the former is aligned with ISO 9001:2000 and the latter, which is our focus, receives strong influence of ITIL, library of best IT services management practices, covering four macro-processes: delivery, resolution, control, release and relationship.
In this norm, there is a topic which addresses the resolution process specifically, visualizing the Incidents and Problems Management.
In the Incident Management, its goal is to restore the agreed services as soon as possible to the company, or to respond to requests of the services.
The norm also points out that it is appropriate that there are [6]: ─ Receipt of the call, record, determination of the priority, classification; ─ First level of resolution or referral; ─ Consideration of security issues; ─ Tracking and managing of the incident life cycle; ─ Verification and closure of the incident; ─ First level of contact with the customer;

Paraconsistent Annotated Evidential Logic Eτ
Roughly speaking, Paraconsistent logics are logics that can serve as underlying logic of theories in which there are formulas A and A (the negation of A) both true without being trivial [2]. There are infinitely many paraconsistente systems. In this work we consider the Paraconsistent Annotated Evidential Logic Eτ. The atomic formulas of the language of the Logic E are of the type p, in which p is a proposition and e (, )  [0, 1] is the real unitary closed interval.
With the uncertainty and certainty degrees we can get the following 12 output states (Table 1): extreme states, and non-extreme states. It is worth observed that this division can be modified according to each application [10]. ─ Vscct = maximum value of uncertainty control = Ftun ─ Vscc = maximum value of certainty control = Ftce ─ Vicct = minimum value of uncertainty control = -Ftun ─ Vicc = minimum value of certainty control = -Ftce All states are represented in the next Figure (Fig.1).

Methodology
The methodology is as follows:  [11], as it presents a set of characteristics that verify whether software can be considered "of good quality", on Table 2:

Factors Sections
F1-Is the slowness in a system a critical incident? S1-In ERP Systems S2-In Supporting System S1-ERP not available F2-Is the interruption of service a critical incident?
S2-Supporting System not available 6. Data collection: We have developed an online questionnaire to obtain quantitative data (see Table 2). Twenty seven IT professionals answered, where the mathematical average of the values found was calculated and grouped into: A: nine final users, B: nine Service Desk analysts and C: nine IT managers. The groups were chosen from the SLA according to ITIL. 7. Object of study: Extensive direct observation of experts. 8. Construction of database: Responses were collected between values of 0 and 1: Table 3. Data collection from experts i) From the data in Table 3, it was applied E Logic and we obtained:

Analysis and Discussion
After analyzing the data employing the Logic E it was concluded: F1-Is the slowness in a system a critical incident? F1-S1 -Slow ERP System: The result was found to be true, it can be considered a critical incident because the ERP is an integrated system and can be used throughout the organization and its unavailability is of high impact.
F1-S2 -Slow support system: The result is true, it can be considered a critical incident, since this system concentrates on the activities ERP does not perform, for example, specific customizations required by business line, sometimes referred to as ADD-ON.
F2 -Is the interruption of service a critical incident? F2-S1 -Unavailability of ERP: The result found was true, it can be considered a critical incident, because the unavailability of an ERP system would damage one or more activities of the company and the impact would be immense: financial losses and low credibility with the users of the organization.
F2-S2 -Is the interruption of the support system services a critical incident? The response after analysis with the E logic was true; it may be considered a critical incident. When we talk about legacy systems or customized systems, it can impact directly and negatively in the areas of business, as we have discussed in item F2-S1.

Comparisons with real data
We used information from a foreign trade company, here as "A", which has headquarters in Santos (São Paulo) and two branches, one in Vitória (Espírito Santo) and another one in Itajaí (Santa Catarina). This company uses ERP SAP/R3 system for Small Business, customized with a module ADD-ON of Foreign Trade and Electronic Invoice. Moreover, it used two Support Systems: A Legacy System used for Customs transaction of ports and another Logistic System for load control, in addition to other system developed internally for controlling suppliers contracts (customs brokers and carriers) and their respective SLA. It has major MPLS links (Embratel) between headquarters and branch offices, and secondary radio links (WCS).
There are, on average, 100 employees, its capital is of family origin and it was requested that its name and period of analyzed data remained secret.
A survey about Critical Incidents in the analyzed period of 1 year was conducted, starting in March/x1 and finishing in February/x2. According to a chart that summarizes the total analyzed incidents.

Fig. 3. Total of Critical Incidents -COMEX "A"
We analyzed situations in which the ERP or Support System were unavailable or slow, as well as disconnection between headquarters and branches. We didn't observe a direct correlation between disconnection and slowness or unavailability of Systems (ERP or Support), as they didn't occur in the same months.
It was noticed that situations when the system is slowcan foresee a possible stop of their systems. The chart below represents this situation month by month. Analyzing the data of the critical incidents of company "A", it can be compared with the results presented in item 4 by logic E, according to the items below:  The critical incidents that are related to links won't always impact the whole company. In most cases they are related to specific problems, for example a particular server.  The continued slowness of a given system can foresee a possible unavailability in the immediate or farther future.  The unavailability of the company's "core" systems may be a potential trouble spot that causes loss of competitiveness in business, financial impacts and even negative impacts on the company's image.