Incident and Problem management

Incident management focuses on restoration of unplanned interruption or deterioration of quality of services as quickly as possible to minimize impact on business. Problem management focuses on analysis and elimination of root cause of incidents in order to eliminate possible incidents in future.

The below text contains basic principles of implementation of these processes in ObjectGears, as they reflect best practises of ITIL v3 - Service Operation.

Incident is a fundamental entity of Incident and Problem managemet processes. It represents an interruption or deterioration of a service. Incident is created at the time when such a situation is identified.

Impact, urgency, priority and target resolution time

Key incident attributies are its Impact and Urgency. Impact represents how much business is affected - from the perspective of number of users or customers (from individuals, over a group to large numbers), financial loss or organization reputation. During implementation of the process, particular levels of impact are described from the viewpoint of the given organization. Urgency represents rate of need to solve the situation from the perspective of tendency to increase incident impact (impact may spread when incident is not solved), not changing impact extent or on the contrary tendency of a spontaneous impact fade out. Priority matrix is defined, that sets Priority for particular combinations of impact and urgency.

Example of a priority matrix 

Impact	Urgency	Priority
High	High	1 - Critical
High	Medium	2 - High
High	Low	3 - Medium
Medium	High	2 - High
Medium	Medium	3 - Medium
Medium	Low	4 - Low
Low	High	3 - Medium
Low	Medium	4 - Low
Low	Low	5 - Very low

There is a Target response time and Target resolution time of the incident corresponding to each priority. E.g. a critical incident then has to be immediately confirmed for take over for solving and target resolution time is 1 hour.

Priority example 

Code	Name	Target response time	Target resolution time
1	Critical	Immediately	1 hour
2	High	10 minutes	4 hours
3	Medium	1 hours	8 hours
4	Low	4 hours	24 hours
5	Very low	1 day	1 week

Each incident is at the time of its creation classified from the perspective of impact and urgency and based on these values priority is calculated. Based on affected service and maximal time for solving target resolution time is determined.

Example: If the service is guaranteed only from 8:00 to 17:00 and an incident with priority and time for solving 8 hours is identified at 16:00, the target resolution time is set to the next day 15:00. This time reflects incident seriousness and need for service availability and sets a corresponding target time. Less important incident then has set corresponding target time and staff is not forced to work extraordinary shifts to resolve it.

Incident categorization

Incident is categorized to determine resolution group and for follow-up reporting - identification of areas, where incident occur most often.

Incident creation and relation to other entities and processes

Incident can be created in three ways:

• Incident created by IT staff
• Incident created by IT staff when solving User call. IT Service Desk identifies, that there is an incident based on a User call. (ObjectGears enables a fast incident creation from a User call and its linking by means of a button in the User call record.)
• Automatic creation by a monitoring system that asses certain situation (e.g. unavailability of a service, server etc.)

Known error

When solving an incident it may be found out that the cause of it is a Known error. IT maintains in ObjectGears records of known errors. Linking incident to a known error enables later on to set impact of known errors on business, number of incidents associated with them, success of their solving etc.

Problem

When solving an incident the solver may find out that the cause of incident is a known Problem. Linking Incident to a Problem enables to set impact of a certain problem, that is not solved yet, on business,  number of incidents or outages associated with it etc. In case that the solver identifies incident cause and associated problem is not yet created, ObjectGears enables a fast creation of Problem from Incident and its linking by means of a button in the Incident record.)

Also problem may be linked to a record of a Known error.

Workaround

Since the objective of Problem solution is to eliminate its root cause, its expected resolution time is by nature longer than in case of incident. When solving a problem solver sometimes identifies a Workaround - a temporary solution that circumvents cause of a Problem. In such a case it is necessary to link Problem to the Workaround. If an Incident occurs later on and it is associated with the given Problem, the solver may solve the Incident by the steps described in the Workaround.

Change

If a need for a Change (see Change management) is identified when solving Incident or Problem, this Change is recorded and Incident or Problem linked to it. This enables to trace back Changes made due to solving a certain Incident or Problem.

Functional and hierarchic escalation

In case it is obvious the incident cannot be resolved by Service desku staff, it is functionally escalated - incident is passed over to the 2nd level solvers (a specialized team according to the area the incident comes to - e.g. Servers, DB Administrators...). Similarly Incident and Problem can be escalated to a 3rd level support - vendor. At this moment a Service request is created based on a contract that is between the customer and the vendor. Since ObjectGears enables an effective linking of particular entities, it is possible to liks to Service requests also in the Incident detail. Solver, manager or any other staffer can see a complex picture of solving the given incident or problem including performed Changes or work of vendors to which Incident or Problem was escalated.

Hierarchic escalation comes about when it is obvious that an Incident was not/won't be resolved in time, it is necessarz to allocate extra resources to solve the incident or plan extraordinary steps. Responsible IT managers are informed within hierarchic escalation.

Knowledge Base

Knowledge from solving Incidents and Problems shall be reflected in Knowledge Base and created or updated articles shall be linked to relevant Configuration items.

Configuration items

It is necessary to link Configuration items to Incidents, Problems, Changes and other entities used in the Incident and Problem management management, which they relate to. ObjectGears then enables displaying Incidents, Problems, Changes and other entities, that were linked them when Configuration items are displayed. This provides a complex view on a given Configuration item to the user.