Branimir Valentic So, an incident occurred. Service is affected. If you are lucky, event monitoring tools are in place and you will notice the incident before users do. Unfortunately, according to my experience, most incidents are reported by users. Anyhow, now’s when the Incident Management process takes over.
The Incident management process as described by ITIL
Let’s recall the purpose of an Incident Management process as defined in ITIL Service Operation: to restore normal service operation as quickly as possible and to minimize the adverse impact on business operation. Emphasized – “as quickly as possible.”
Is there anything that could be done to speed up incident resolution? If an incident is logged using the IT Service Management (ITSM) tool, i.e. user portal, and there is not enough information to diagnose an incident, there is little that IT can do in the first step. The advantage is that the user, i.e. requestor name, is known. So, the Service Desk (SD) has to call back and gather all necessary data. But, the clock is ticking.
Luckily (or not?), users feel it is quicker and easier to call the Service Desk and talk to someone. There’s your chance. With the user still on the phone, the Service Desk has to try to solve the incident without escalation. Finding out what exactly went wrong (believe me, it sounds much simpler that it really is) and what the symptoms are is the only possible starting point. I noticed that a lot of Service Desk employees are easily taken into useless discussions.
Matching
There are few things that can help to diagnose and resolve incidents by the Service Desk:
Diagnostic scripts – communication script made for particular incident category. Service Management has a lot experience with services it supports and can point to the most critical parts of the service (based on experience or on proactive analysis). This is especially useful in cases when there is a lot of staff rotation at the Service Desk. If the resolution is not known, a diagnostic script will help to isolate the cause of an incident and collect symptoms (for later diagnosis and investigation).
Known error database (KEDB) – many service management tools (and almost all of the enterprise-class ITSM tools) have KEDB. This is a database where known errors (and respective solutions) are stored. Service Desk employees use search functionality (a skilled SD employee will easily identify keywords describing the incident) and try to match the incident with a known error.
Problem matching – it could happen that an incident with the same symptoms is already opened, the problem recorded (meaning, someone is already working on it), and a workaround exists.
Incident matching procedures help to prevent doing the same thing several times.
KEDB and problem matching will contain all relevant information and there is no need to start the investigation from scratch.
Diagnostic scripts simplify, standardize and optimize diagnosis and resolution of incidents. Even though they are used inside the Service Desk, they can be published and used by end users. Once I found the questionnaire used by the Service Desk published as a workflow in HTML form. In such a way, users can navigate until they get to the solution. This increases user satisfaction (people feel “smart enough” to solve the incident by themselves) and saves resources inside the ITSM organization. Quite the contrary, some large service providers do not allow opening an incident until you pass one such questionnaire.
Figure: Incident matching procedure
What’s the importance of initial diagnosis?
Recently, I spoke with a few users at one of my customers’ businesses. I ask them to describe their Service Desk and they replied: “Forwarding managers!” Explained – what the Service Desk does is escalate most of the incidents. And users don’t get the feeling that they are efficient, i.e. they are not of much help. Skilled staff is one of the answers, but sometimes it’s hard to find appropriate people. Other solutions include incident matching procedure (with well-developed KEDB and active Problem Management process) and powerful service management tools, which are a great help for the Service Desk to solve incidents during the first call.
Nice and efficient, isn’t it? Well, it’s not that simple. There will always be incidents that can’t be resolved by the Service Desk. They will be escalated (to the next support level – Functional escalation). And that is OK as long as the Service Desk keeps ownership of those incidents.
Or, back to the title – the Service Desk has to navigate throughout the whole journey. Otherwise, every crossroad will be a potential pitfall and ETA (Estimated Time of Arrival) changes to -> unknown.
You can also check out a free preview of our Incident Management Process template to see activities, roles, and responsibilities applied to incident resolution.
