Site: US UK AU |
Nexcess Blog

Zen and the Art of IT Support, Part II: Beginning with Incident Management

May 15, 2013 0 Comments RSS Feed

Zen and the Art of IT Support, Part II: Beginning with Incident Management

When tackling a topic as large as IT support, the discussion (much too often) stalls at the point of deciding where to begin. After all, as I mentioned in the first part of this series, we debate the question, “How do we better support our users?” to the point where we would all like to (figuratively) beat ourselves over the heads using a wooden board with nails sticking out of it. For many in the industry, self-mutilation is almost preferable to discussing the topic yet again.

There is, however, a way out (without bloodying yourself or that lovely wooden board with the nails sticking out of it).

Using the IT Infrastructure Library (ITIL), an organization can identify its support needs and those of its users. However, as the framework can be daunting to anyone when first approached, my suggestion is to attack it in chunks. As the King of Hearts says in Lewis Carroll’s Alice in Wonderland, “Begin at the beginning… and go on till you come to the end…”

Thus, let’s begin at the beginning.

The most easily implemented (and the one that can stand alone most easily) is incident management. As defined on Wikipedia:

Incident management aims to restore normal service operation as quickly as possible and minimise the adverse effect on business operations, thus ensuring that the best possible levels of service quality and availability are maintained. ‘Normal service operation’ is defined here as service operation within service-level agreement (SLA) limits.

(Note, for this blog post, I’m including ITIL’s request fulfillment along with incident management. Request fulfillment, according to Wikipedia, “focuses on fulfilling Service Requests, which are often minor (standard) changes (e.g., requests to change a password) or requests for information.”) and stands hand-in-hand with incident management. For some organizations (Nexcess being one), request fulfillment actually will need to be its own process (as opposed to subordinate to incident management) due to the amount of actually made by users and the content of those requests. This is the exception, though. In most support organizations, Request Fulfillment will follow the same escalation paths as outlined in incident management.)

Keeping in mind incident management can also rely upon workarounds to restore service, the entire objective is to restore service for the user(s) affected and allow other areas of the organization to deal with the larger concerns of what caused an issue or how to safeguard against it in the future. In this regard, incident management is highly reactive, as it depends on the user reporting the incident and support acting upon the report. There is very little that is proactive about incident management, and that is one of the reasons it is the best of the group to begin with. Since (I would argue) the vast majority of support providers have a basic and reactive “help desk” handling their incidents, this would simply be a refinement of the current process. A standard help desk already focuses on restoring service (though it sometimes overreaches and ends up attempting to do more than just incident management), so codifying the process and using that to shape the way incidents are managed (and help the support staff not overreach when working on an incident) is the logical place to begin introducing ITIL to a support organization. It doesn’t add too much complexity to the already existing structure, and it doesn’t drastically change the current approach.

Changing the approach and moving from reactive to proactive comes later. Incident management allows for (formal or informal) operational level agreements (OLAs) to then be created and establish expectations between areas within the organization (such as operations or networking, for example). Those expectations, again, then help the support staff when they need to communicate anything to the users. Instead of vague notions and dodging the question, it allows for a stronger (and more reliable) interaction with the user. An OLA should also provide both the support staff and the other department the ability to review incidents in order to identify trends and begin to address issues proactively (thus decreasing the reactive responses to similar incidents).

Returning to the idea of “Zen” and the absorption of knowledge that is a part of it, introducing incident management first is also one of the best ways to introduce a quality of service the users and employees need (while demonstrating how this can work across the rest of the organization). It assists in guiding the employees and helping them understand what they are expected to do and how they are expected to do it. By assisting the employees, it then, in turn, assists the users because now the employees can communicate their better understanding of the situation to the users. It, coupled with the service level agreements (more on them in future posts), works to manage the users’ expectations and not make the employees on the phones and tickets feel as though they are being left to fend for themselves.

Most importantly, incident management lays the foundation for the necessary next steps in implementing ITIL: Knowledge Management, (in order to expand upon handling incidents and requests (and do so well) by both users and employees) and the end goal of any “help desk” attempting to attain the ultimate level it can in its existence… the Service Desk.

Posted in: Nexcess