Most ITSM consultants prefer to start off the blocks with the design and implementation of the incident management process. Also, by hanging onto the low hanging fruits in the form of incident management process development and implementation, you can certainly prove your authority in the ITIL area to the customer.
I don’t blame them because the process gives you the comfort feeling that can help soothe your nerves whenever you start engagements. And the customers too like to see something on the table as quickly as possible. However, in my opinion, I have made it no secret that the configuration management process must be introduced first, as it serves as the foundation before you start laying the bricks for the IT service management to take you to the pinnacle.
Let’s not rake up the discussion around which process to implement first, as I intend to introduce incident lifecycle in this post.
Incident Management Lifecycle as per ITIL Publication
The incident management lifecycle in the Service Operations publication is a decent one. It provides the various stages of the lifecycle in a snapshot. The workflow below is a replica of the official incident management lifecycle.
I have explained the lifecycle of an incident in my book – “Become ITIL Foundation Certified in 7 Days: Learning ITIL Made Simple with Real-life Examples
Let’s break this down into simpler pieces so it’s easy to assimilate.
Incident Management Triggers
One of the key characteristics of processes is that they have triggers. Without a trigger, no process will get underway. Incident management too has quite a few triggers. As per the official publication, the triggers identified are:
- Event Management
- Web Interface
- Phone Call
A trigger is something that gets the process started. For incident management, the trigger must be an indication that some service is either not working or is working in a degraded mode.
Incident Management Trigger – Event Management
One of the automated triggers that we see today is from the event management process. The event management process keeps a tab on the services using tools such as Nagios, Tivoli, Splunk, and AppDynamics. Whenever the service or the component that is being monitored does not work as expected, the event management process triggers an incident to be created and assigned to the relevant team for their action.
Example: Let’s say that all servers are being monitored as a part of the event management process. Let’s say that one of the servers goes offline. The Splunk monitoring tool tries to make contact with the server a couple of times, and if in vain, it will provide necessary information to the ITSM tool to create a P2 incident and assign it to the server support team. Normally, information is exchanged between the event monitoring tool through APIs.
Incident Management Trigger – Web Interface
It is a common occurrence these days that users are able to log incidents on their own, without having to make phone calls.
A web interface is enabled through the ITSM tool (normally with a wrapper built around it), where the user logs in pertinent information and logs the incident.
Depending on the process definition, all the user logged incidents could be looked at by the service desk, or in an efficient process, these incidents can be directly routed to specific resolver teams.
Logging of an incident using web interface is not only done by users, but by IT staff themselves. Incident management clearly makes IT staff responsible for raising incidents if they come across any service outage or degradation.
Incident Management Trigger – Phone Call
Yes, some people are archaic. They still like to pick up the phone and call the service desk. Normally those who call are those who have faced service outages that impact their work. Rightly so, they need resolution immediately.
The calls made by users are routed to a service desk, which acts as a single point of contact for all types of issues. For example, if you have Outlook issue, you call the service desk. If you have a laptop issue, you call the service desk. And likewise, if you have a problem with the internet, you end up calling the service desk. You don’t get to choose to call the resolver team directly anymore! There was a time when users knew the resolver teams directly and reached out to them with their issues. This ancient way is not streamlined and led to higher priority incidents getting neglected.
It is not uncommon to see IT staff call the service desk to report incidents. It may be due to laziness or process definition that all incidents have to be logged through a phone call to the service desk.
Incident Management Trigger – Email
Some users like the IT executives are used to sending and receiving emails. So, for them, the preferred type of logging an incident is to send out an email to a particular mailbox listing out the issues they are facing. Either the ITSM tool is smart enough to log an incident directly, or somebody at the other end of the mailbox (normally service desk) go through the email, and log an incident.
I am not a big fan of this trigger for an incident as a number of details can be missed out in an email, and the service desk has to communicate back and forth to get all the information handy on the incident ticket.
I had once devised an email template which can be used by those wishing to log incidents through an email. Once users fill out the template and send the mail, the ITSM tool would automatically raise an incident and send out an acknowledgment mail with the incident number. In the backend, I had mapped the email template tables with various tables in the incident ticket. I had used the CA Unicenter Service Desk tool.
Incident Management (Missing) Trigger – Chat
I am surprised that the chat option has been missed out by the ITIL official publication. It is quite powerful, and it gives plenty of room for the service desk to multi-task by chatting with multiple users at the same time. On a phone call, they can only engage one user at a time, and maybe with chat, they can engage five users simultaneously.
Basically, if the chat option is available, the user can use a chat program to talk to the service desk and log an incident.
This is indeed my favorite option for logging incidents.
What is Next?
In this piece, I have introduced the various triggers that are available in the incident management process, including the ones that are not listed in the official publication.
In the next article, I will discuss the following block, where the incident management checks if the logged incident is indeed an incident, instead of a service request. This is a very critical activity, and I will explain it in the next article in the incident management lifecycle series.
If you are not ITIL Foundation certified yet, pick up a copy of my book “Become ITIL Foundation Certified in 7 Days: Learning ITIL Made Simple with Real-life Examples
2 comments
[…] the first article in the series, I talked in detail about the various incident triggers such as event management tools and […]
[…] is the second article in the series. In the first one, I introduced the incident management lifecycle workflow and discussed the incident management triggers in detail. Once an incident is detected based on the […]