Incident logging is a somewhat straightforward activity. However, it is important to note that no matter how simple it may sound, organizations tend to go wrong in its implementation.
In the third set of the incident management lifecycle series, I will talk briefly about the incident logging activity.
To fully touch base upon the incident management process, I am leveraging on the incident management process workflow from the ITIL Service Operations publication.
Story So Far
In the first article in the series, I talked in detail about the various incident triggers such as event management tools and users.
The second iteration was about the basic difference between an incident and a service request.
Logging an Incident
Before we get into the activity of logging an incident, I want to stress the need for an incident management policy document which sets the groundwork and framework for incident management process to operate.
Policy Around Logging an Incident
The policy around incident logging goes something like this – every single incident must be logged.
Let’s say that a user calls to get an answer to a query – such as where is the My Documents folder. This is not an incident in the basic sense because nothing is broken. Yet, an incident must be logged to keep track of all the inputs and triggers.
This example does not restrict it to users, but also extends to other sources such as event management tools as well. Even if the tool identifies defined anomaly, it must log an incident before anything else can be done to diagnose and troubleshoot.
Incident Source
The incident form must have provision to capture the source of the incident.
This is an important factor to identify the ownership of the incident in terms of clarifications and confirmations, and it is also analyzed to find relevant information that can potentially act as an input for Continual Service Improvement.
Timestamps
Even if I don’t state that timestamps must be captured, most modern tools do it by default.
Timestamping is an important record that can define a lot of things in service management such as SLA measurements, incident management effectiveness and the service uptimes.
Recommended Fields for an Incident
The sky is the limit. You can have anything you want in an incident form. However, you need to define the data source for each of the fields, and also ensure that you capture something that is absolutely needed. Don’t just have a field because you thought about it. Analyze the need, and determine where it can be used
The ITIL Service Operations publication recommends the following fields for an incident:
■■ Unique reference number
■■ Incident categorization (often broken down into between two and four sub-categories)
■■ Incident urgency
■■ Incident impact
■■ Incident prioritization
■■ Date/time recorded
■■ Name/ID of the person and/or group recording the incident
■■ Method of notification (telephone, automatic, email, in person etc.)
■■ Name/department/phone/location of user
■■ Call-back method (telephone, mail etc.)
■■ Description of symptoms
■■ Incident status (active, waiting, closed etc.)
■■ Related CI
■■ Support group/person to which the incident is allocated
■■ Related problem/known error
■■ Activities undertaken to resolve the incident and when these took place
■■ Resolution date and time
■■ Closure category
■■ Closure date and time
Incident Updates
The next policy to be defined is around incident updates.
All incidents must be updated on a regular basis. Based on the priority of an incident, the policy defines the maximum permitted time between consecutive. Even if there is no progress, resolver groups must keep the ticket updated.
This comes in handy in tracking incidents by incident managers. If a team is not working on an incident, then there must be a good reason to it, right? Maybe the user is not around or maybe the team is waiting for a certain time when the incident normally recurs.
In these cases, the ticket must probably be placed On Hold. If the ticket is not updated, then the management tracking incidents will have no basis to keep a tab on the open incidents.
Next Up
In the next article in the incident management lifecycle series, I will talk about incident categorization.
