The IT Skeptic - Comments for "What ITIL V3 says about the distinction between a Call and an Incident"

Master Incident beats Problem to a pulp

Emerson Freedman — Wed, 08 Feb 2012 14:06:16 +0000

Problem is feeling very sad and lonely, because Master Incident has come in and taken over his turf, without so much as a fair fight.

Problem has lost the right to own any situation that involves "multiple related incidents" and has been relegated to the annals of history.

Having beaten Problem to a pulp, Master Incident is now eyeing up Major Incident's territory. However, IT Service Continuity and Service Recovery have Major Incident's back, providing Master Incident with a real fight.

Will Problem see its nemesis fall, and rise to power as the keeper of the truth, aka "root cause analysis"?

Stay tuned, for iTIL V4, coming soon to a 3rd party supplier near you!

what guidance does HDI give on this?

skeptic — Tue, 27 Oct 2009 18:52:13 +0000

Whether ITIL is descriptive or prescriptive, it purports to DESCRIBE best practice. To what purpose? if it is to describe abstract principles that are to be interpreted by expensive priests ...er... consultants, then much of the detail in ITIL would seem to restrict the creative genius of those stellar persons.

On the other hand if it is to DESCRIBE what best ITSM looks like for those not blessed with a prior in-depth knowledge of ITSM, then I'd say how BEST to handle and categorise incoming calls to a service desk was a pretty fadurkin' fundamental omission.

You folk in HDI, what guidance does HDI give on this?

Descriptive not proscriptive

DavidM — Tue, 27 Oct 2009 14:35:46 +0000

Maybe I'm missing something -- again. :-) What's the real issue here?

Isn't ITIL descriptive -- or supposed to be? It's guidance not "the holy writ" -- which means there's room for interpretation.

If ITIL was supposed to be proscriptive (a la PMBOK or PRINCE2) I'd agree with the questions raised.

Something I said on Twitter I believe to be relevant here: ITIL confused leads to dogma, ITIL understood leads to ITSM.

In other words, it's a matter of what works. An incident is the unplanned interruption or degradation in quality of...

Multiple calls about the same interruption or same quality issues doesn't make each individual call an incident. Whether or not the organization does or doesn't categorize is less important than addressing the overall goal of Incident Management: do something to restore service as rapidly as possible. I thought it was about... that the end result real goal was IT service management.

Every incident (not call, incident) should have a review before the ticket is closed. The purpose for the review is to get the right categorization, etc. In other words, there's the specific incident goal (restore service quickly) and the overarching process goal that includes learning and improving.

What did we do right?
What did we do wrong?
What can be done better?
How do we keep this from happening again?
What type of (and when is) follow-up required?

Given the discussion it's clear that I don't understand something -- and I'm not sure what it is? Someone please tell me what I've missed.

Thank you.

David

let the solution define the category

skeptic — Mon, 26 Oct 2009 19:10:09 +0000

P.Menafee, your "let the solution define the category" (which bis what I'm sure you meant :D) approach is sensible. It is a fresh way of looking at what I have advocated: there is only one entity, a Response, which we categorise as we go along, and only one process for dealing with them - with variants.

Yes, focus on solution

vinodka — Mon, 26 Oct 2009 16:53:10 +0000

There you go, I could not put that in so short and sweet way: " Let the solution define the problem" - Exactly what I used to think and I would put that as " let the solution define category/ticket type" Ultimately the user want a 'solution' to their need (for support).

Thanks
Vinod Agrasala
www.itserviceview.com

I agree that ITIL does not have that distinction

Prashant Bhardwaj — Mon, 26 Oct 2009 16:48:37 +0000

and was just putting across a way that I have seen this distinction being handled!

Sounds a bit familiar

P. Menefee — Mon, 26 Oct 2009 16:26:09 +0000

Your second option reminded me of an organization I helped over ten years ago. Their solution is still very relevant and impressive today. There was no manual categorizing of calls by the Service Desk. It was their opinion, and is still mine, that we want the support staff to be focused on the solution, not taking time to put the call in its proper bucket. Let the solution define the problem. The service support team simply asked a series of questions (read mostly from the screen) and recorded the user’s response. After some time, nearly 95% of all calls went according to script. The problems users faced were recorded as well as a host of data about the call, staff response, workarounds, etc. We also had a list of workarounds with no solutions and a few with no work around which were immediately escalated. If we wanted to investigate calls about a particular application outage we simply looked at that date or applications history. The system had its problems but by in large I'm still waiting form some of the big vendors to catch up. And it still pains me when I hear first tier staff ask which category they need to put a particular call in - it is a waste of their time and far too subjective.

Would you like a problem with your incident?

Quatroux — Mon, 26 Oct 2009 14:47:12 +0000

Doing your incident correlation in problem is really a workaround because the tool is a bad fit for existing process. I've also seen this when the service desk doesn't do any serious incident correlation and blindly pushes tickets to backline teams where the correlation occurs. If it works, keep it up. However, I have to wonder how a mature problem landscape is naviagted when the waters are muddied by incidents.

Event, call, Incident and request

Vinod Agrasala — Mon, 26 Oct 2009 14:24:08 +0000

Pardon me, I am a bit confused on the focus of this debate:
Is it 'what should be the better way to handle such scenarios' or 'Is ITIL having a clear guidance on that?

It is not really clear on the best practice (er..Good Practice) documentation of ITIL.

We have guided a couple of organizations around this question -
though really haven't put such a deep thought into this.
Not much different from what Skeptic and some others have put across:

We start with an Event (detected and handled through event management process) and a call (handled as human reporting at service desk)

Now an event - if it is an interruption (or potential interruption) of a service - gets logged/categorized/tagged as Incident.Other events are handled through different response selection in event management

A call at service desk can be treated in two possible ways:

1. It is logged as a call/ticket (or whatever) - and then categorized/tagged as incident or service request as the case may be.
or
2. It is logged as an incident - and later categorized/tagged as service request (if it not an interruption or potentiona interruption) and passed through request fulfilment process. - the good old V2 structure of Incident management process.

The second option "incidentally" (pun int. again :-) ) removes the need of an entity called call/ticket before Incident.

And to talk about the scenario of master incident, I think linking to the master ticket is the more logical option, with clear criteria for doing so.

Outage

epistemological — Mon, 26 Oct 2009 05:13:17 +0000

When I got my ITIL cert we commonly logged each call reporting an outage as an incident (Unicenter Service Desk, as we use it does not manage "calls" per se) and collect all of the incident tickets under a "problem" ticket and that problem ticket is managed by both the problem management group and the department responsible for resolving the outage. All of this is pretty straightforward in my organization.

implication

skeptic — Fri, 23 Oct 2009 19:10:06 +0000

Sorry Prashant but I don' think that has advanced our discussion any. Both instances are a case of introducing the Call entity in front of the Incident entity.

Incidentally [pun int.] that extract is one of many that implies (or certainly can be interpreted that) there is NOT any additional Call entity in front of Incident: Incident Management includes ...events which are communicated directly by users... Incidents can also be reported and/or logged by...

What about Events?

Prashant Bhardwaj — Fri, 23 Oct 2009 15:58:31 +0000

I was reading through your post and then went back to the book to read more. Here is what it says

"Incident Management includes any event which disrupts, or which could disrupt, a service. This includes events which are communicated directly by users, either through the Service Desk or through an interface from Event Management to Incident Management tools. Incidents can also be reported and/or logged by technical staff (if, for example, they notice something untoward with a hardware or network component they may report or log an incident and refer it to the Service Desk). This does not mean, however, that all events are incidents. Many classes of events are not related to disruptions at all, but are indicators of normal operation or are simply informational "

From my experience with two organizations here is how they modelled

1. First contact is a call. A call can be an incident, a service request or How-To question. Calls are to be handled by the Service Desk and most how-to should have a first contact resolution and so on... multiple calls does not necessarily mean multiple incidents.. if they are for the same issue, One incident should be attached to multiple calls and the priority/urgency/severity increased for that incident. The tool in this case was Tivoli CSD

2. First contact is a Service Management Ticket... it would become an incident ticket only if it qualifies as an incident! so SM tickets to IM Tickets and IM tickets would usually be less than SM tickets. Tool used here is the HPSC

pros and cons

skeptic — Fri, 23 Oct 2009 02:00:30 +0000

Not sure. there are pros and cons.

Whatever you call it and wherever you put it, there is a missing entity. there needs to be two entities: the service outage (one per outage) and the user impact (one per user). Which ever one is labelled Incident, there needs to be the other. ITIL doesn't say which and never talks about the need for both.

What gets my attention is that after twenty years no-one has weighed the pros and cons and documented the best practice, least of all in ITIL

So whats the upside

buraddo — Fri, 23 Oct 2009 00:31:17 +0000

So whats the upside of a call/contact label ?

Or are you going to make me read the forum ?

Brad Vaughan

jump to conclusions

skeptic — Fri, 23 Oct 2009 00:10:06 +0000

I agree, but I think the danger is in how one approaches each call, not in the model. For example in the scenario you describe (same one I and also David Cannon :D described in that forum thread) it is just as easy to jump to conclusions when each call is an incident, and automatically link the incident to a Master Incident assuming same root cause.

When do you assign call to incident

buraddo — Thu, 22 Oct 2009 21:35:21 +0000

If a call is not an incident, when and why do you assign it to an incident? Are you short-cutting the evaluation of the incident by creating a new process ?

If the customer says "my email is not working" then by attaching it to an incident, you assume that the same cause is the result of the symptom.

Test Scenario: If the email is down due to a major networking failure (which you do not know yet) in one division in the company and 100 users are affected, and another customer rings in with "my email is not working" and the cause is finger trouble on a password, or they forgot to plug the network cable into the back of the machine. The 101 customer waits until the network falure is fixed, and then finds out they need to plug in the cable.

If you create a call or contact label, are you then saying to connect the call/contact to an existing incident as a shortcut instead of running through the predefined analysis flow to find a work-around which includes assessing against all the know workarounds for that symptom type.

So when is this shortcut analysis flow effective. Is it the 10th common symptom call or the 100th ?

$0.02

Brad Vaughan

one current generation ITSM

Visitor — Thu, 22 Oct 2009 20:22:00 +0000

one current generation ITSM automation suite [ed: name removed] includes the concept of an interaction (to log the calls) with the ability to 'escalate' to incident, which can also we tagged to a master incident. Kinda complex but makes for complex reporting
[ed: several do this but not all]

Even if...

Quatroux — Thu, 22 Oct 2009 15:57:16 +0000

Even if ITIL doesn't tell you which way to go, do the "certified" tools? IF you find an ITSM tool that allows you to log calls (not all do), is that an extra step for every incident? What if you only have one call? Mirror this with the "internal assignment" feature of some tools. Do you create an assignment if it is a first call resolution? I don't look to ITIL or MOF to answer all of this. I simply wanted to echo the point that the tools are equally undecided.