ITIL Service Management: May 2010

Every time user calls in, we log it as the new incident. Or we update an existing incident.
What happens when one major business service goes down? Do we log every call from a different user as a new incident?
Are these just related incidents or there is only one incident? What are calls?

I have seen a few interesting discussions on the Net about the technology of Service Desk Incident logging.

Since I have some 18 years of IT Service Management experience in practice and in theory, and this is a matter I have a strong opinion about, I might say a few words about it.

INCIDENT MANAGEMENT PROCESS
Incident Management is the oldest and most chewed up process in all IT Service Management. Everyone does Incident Management. Maybe not Capacity Management or IT Financial Management, but Incident Management is in phase 1 of most ITSM/ITIL implementations. So it is the best defined and best known process. Everyone interested in ITSM knows everything about it. Right?

DEFINITIONS
What was the definition of an incident? Here are some:

ITIL V2: any event which is not part of the standard operation of a service and which causes, or may cause, an interruption to, or a reduction in, the quality of that service.
ITIL V3: An unplanned interruption to an IT service or reduction in the quality of an IT service. Failure of a configuration item that has not yet impacted service is also an incident, for example failure of one disk from a mirror set.
MOF: Failure of a service or component to provide a feature it was designed to deliver.

Very nice. All bases covered. Very defined. For decades.

SCENARIOS
So consider a few scenarios:

User cannot log in, she forgot her password. Service Desk creates a incident ticket and resolves it in a first call. Splendid.
User has a problem with his PC. Service Desk assigns a technician on that incident . Technician visits the customer, resolves the incident and SD closes it.
Print server goes down. No one in the headquarters can print. Imagine the legal department people. Sales girls and their Tenders & Invoices... Hell must be a nicer place to be. Phones are off the hook, percentage of unanswered calls goes up fast.

Imagine a mail server crash in a large enterprise. That must be a show. This is a very common case, happens every day in IT all over the world.

So then, is every new call from a panicking user a new incident? Or it is just one incident, and many end user calls (inquiries?). Read ITIL books V2 and V3 all you want and you won't find the answer.

V2 books are in favor of rule that every new call is an incident. OK maybe if the same contact person calls a second time, then it can (maybe) be logged in the same Incident record. But, another person, another Incident.

V3 broke Incident management into new Incident Management and Request Fulfillment with an eye on Event Management. So everything is not an incident any more, it can be an user request. Which doesn't help us here much. Every call about the incident is still an incident by our good ITIL books. And that's best practice. Sort of.

ITIL Service Management sure has some place for improvement here. What I feel sorry for is that authors of V3 strived to cover as much new territory they could (Knowledge Management? Strategy Generation?), creating more ambiguity and material which will need improvement, and flaws of the basic processes remain uncovered. Best practice system should cover such basic scenarios as above mentioned.

What happens in example above, if every call is an incident? All incidents are logged and categorized. A lot of them.

If a mail server went down, is it a new incident every time user notices he can't send mail? No, of course not. It's ONE incident, i.e. one interruption of the mail service. In a good Service Desk environment this incident will often be recorded before any user notices it. The amount of users impacted will only influence Priority of the incident, (remember, Impact X Urgency), not the number of incidents.

This is a nice question I have asked every ITIL trainer/consultant I've met, and I've always had fun.

HOW SHOULD IT BE DONE?

So, how do you do it at home?

In my company, Service Desk has an Incident Management tool which enables us to log an Incident. All later calls from the same contact person (department) are logged as updates of that incident.

All later calls from new persons regarding that incident (mail server down!) are creating new tickets which are connected to that first incident. These related tickets are not considered incidents, we call them simply "tickets".

When the original incident is resolved, an original contact person for that incident is asked to confirm. Incident is then closed, and all associated tickets too. All contact persons from these tickets get a notification about the closure and are asked to reopen the incident if they feel their service is not yet restored.

Some tools on the market even have special entities, "Calls", which are linked to an initial Incident in a similar manner. Some other tools are at least able to interlink incidents so that when the original one is resolved, SD people can at resolve related incidents one by one, "on foot".

This scenario can repeat quite often in enterprise Incident Management, even in mid-sized managed service companies. So it would be nice if someone explained it to good ITIL best practices author.

NOTE

There is one potential catch with "One incident/Many tickets" method: if you treat various departments or business units of your company as different customers, i.e. you have a different SLA with Finance, Legal or Marketing, then you would want incidents and outages to show on their respective SLA reports. If your IM and reporting tools are not perfectly linked to the service Configuration Items in your CMDB or your Service Catalog item, you will probably want to create one incident for every contracted SLA.

This will also be the case if your contact defines a business unit associated with the incident, and the reporting tool regards incidents as service disruptions on associated business units. Here the value of a good Service Catalog/Portfolio comes to the fore.

Sometimes this vagueness is justified by “descriptive, non prescriptive” nature of ITIL. Well in my humble opinion, if something is called best practice, then it should describe the best practice of common events.

It would be very nice if this issue gets to be addressed in the next ITIL release, don't you agree?