Task: Log Incident
Log Incident
Disciplines: Incident Management

Purpose

To initiate the Incident Management Process.

Relationships

RolesPrimary Performer: Additional Performers:
Outputs

    Main Description

    Incidents can be reported by the customer or technical staff through various means, i.e., phone, email, or the CRM's self service web interface. Incidents may also be reported through the use of automated tools performing Event Management. Reported incidents should then be recorded in the CRM in order to allow work on the incidents to begin. As far as possible, all key components should be monitored so that failures or potential failures are detected early, so that the incident management process can be started quickly.

    Steps

    Record Incident in CRM
    All incidents must be fully logged and date/time stamped, regardless of whether they are raised through the Service Desk or event alert. All relevant information relating to the nature of the incident must be logged so that a full historical record is maintained - and so that if the incident has to be referred to other support groups, they will have all relevant information at hand to assist them.
    Accept Information from Customer

    Case information coming from the customer can occur through either Service Desk calls or emails, or can be inputted by the customer into the CRM case.

    Identify event as incident or request

    Verification of event categorization. If the event is not related to one of the published services listed in the service catalog, then the event should be listed as a service request. Published services and related cases should be considered, and if the event is a service request, the case should be updated as such and actions taken should follow the appropriate Request Fulfillment Process. If the event is an incident, planned procedures should follow the Incident Management Process.

    Categorize incident based upon predetermined scripts and search functions

    Relate the incident to one of the published services in the Service Catalog, and relate the case to any cases that have been reporting over the same issue. Multiple people reporting the same issue means the impact of the issue is broader than the original scope suggests. Published services and existing related cases should be considered.

     

     

    Incident Level

    Severity

    3 - Low

    Issue prevents the user from performing a portion of their duties. 

    2 - Medium

    Issue prevents the user from performing critical time sensitive functions.

    1 - High

    Service or major portion of a service is unavailable.

    Impact

    3 -Low

    ·   One or two personnel

    ·   Degraded Service Levels, but still processing within SLA constraints.

    Incident 3

    Incident 3

    Incident 2

    2 - Medium

    ·   Multiple personnel in one physical location.

    ·   Degraded Service Levels, but not processing within SLA constraints or able to perform only minimum level of service.

    ·   It appears the cause of the incident falls across multiple functional areas.

    Incident 2

    Incident 2

    Incident 1

    1 - High

    ·   All users of a specific service.

    ·   Personnel from multiple agencies are affected.

    ·   Public facing service is unavailable.

    ·   Any item listed in the Crisis Response tables.

    Incident 1

    Incident 1

    Incident 1

    Verify event is truly an incident

    Verification of event categorization. If event is not related to one of the published services listed in the service catalog, then the event should be listed as a service request. Published services and related cases should be considered, and if the event is a Service Request, the case should be updated as such and actions taken should follow the appropriate Request Fulfillment Process. If the event is an incident, planned procedures should follow the Incident Management Process.

    Set priority for incident based upon predetermined definitions of impact and severity
    The priority given to an incident that will determine how quickly it is scheduled for resolution will be set depending on a combination of the incident severity and impact. If the event is a priority 1 incident, meaning that a service is partially or completely unavailable, all mid-level and senior OMES/ISD Management should be alerted to make certain any resources necessary to the resolution will be immediately made available. Impact and Severity of events are key considerations in this step, and priority should be set accurately.
    Perform Initial Diagnosis and attempt to find solution
    If the incident has been routed via the Service Desk, the Service Desk Analyst must carry out initial diagnosis, using diagnostic scripts and known error information to try to discover the full symptoms of the incident and to determine exactly what has gone wrong. The Service Desk representative will utilize the collected information on the symptoms and use that information to initiate a search of the Knowledge Base to find an appropriate solution. If possible, the Service Desk Analyst will resolve the incident and close the incident if the resolution is successful.
    Assign Case
    If the necessary information to resolve the incident is not in the Knowledge Base, the incident must be immediately assigned to an appropriate provider group for further support. The assignee will then research the issue to determine cause and remediation options.
    Update Case information

    Key Considerations

    Access to CRM.

    Alternatives

    The customer can use various alternatives, such as calling or emailing the Service Desk, or using the CRM Self-Service.