1. Incident and Problem management

    Article: AN0001775Updated: 03.12.2018

    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.

×