4. Incident Management Process

Term/Theory

Definition/Point

Outlines

Process for dealing with all incidents (failures, questions, query)

Any event which disrupts or could disrupt service; could be from monitoring or end user call

Objectives

Primary objective: restore IT service to users ASAP

Other objectives:

• Detect/resolve incidents
• Align real‐time it activity to business priorities
• Identify potential improvements

Incident vs. Service Requests

Both incidents/service requests are reported to Service Desk

• Service Request - planned, repeatable
• Incident - unplanned, deviation from normal, reduction in quality of agreed service, could lead to disruption or reduction in service
• Incident models – provided guidance to deal with incidents

Major Incidents

Shorter timescale – separate procedures

Should include:

• Steps to take
• Chronological order
• who should do what
• timescale
• escalation procedures
• evidence preservation activities

Incident Steps

1. Incident ID – reported
2. logging – ticket opened; documentation of ~
3. Categorization – hardware, software, infrastructure
4. Prioritization – facilitate activities according to SLA/OLA/UC; priority given based on Urgency (timeframe which users required resolution) & impact
5. Initial diagnosis – L1 support, resolving incidents based on knowledge/experience/kb’s/diagnostic scripts; analysis may resolve on initial diagnosis and then close (FCR)
6. Escalation – guided by SLA, will follow major incident procedure
7. Functional escalation to tech teams
8. Hierarchical escalation to SDS and Inc process mgr
9. Investigation & Diagnosis – L3 support teams do their thing
10. Resolution & recovery
    1. Incident closure; stays open until related problem management activities are completed if a major incident

• Service requests are frequently recurring
• Allow for efficient/consistent service fulfillment (i.e. how do I add items?)
  • If cannot help, gets escalated to service desk, external vendors