The IT Skeptic - Comments for "Separation of incident and call"

inward-facing technology focus

Platos dITILectic — Fri, 25 Sep 2009 14:14:50 +0000

Valid point on many levels. For example, ITIL does introduce/get into (3) Service Provider types, but doesn't take this far enough...i.e., one could argue the need for three Service Strategy (SD, etc?) books, one each from the perspective of the three Service Provider types....once ITIL v3 introduces these three, much of the discussion afterwords goes back to generalizing on guidance for the "service provider," and only occasionally making specific correlations back to the specific provider types. (My experience is that good providers handle my calls differently when they know they are in direct competition for my money/business.)

Still, one might find it helpful to examine how to talk about best practice for "call" handling in an outward-facing service focus context from the perspective of different service provider types; or indeed, in the case of CMMI-Svrs, from the perspective of many different types of businesses in the entire service industry...

Or, you could state generally, that if there is a business need (or agreement with the business...i.e., SLA) for how to answer/respond to, etc calls, and not just incidents, faults, events, problems, etc, then the provider should have the processes (and hopefully tools) in place to do so.

But obviously, we get into the old argument about how much is too much prescriptiveness...too specific or trying to cover too many specific situations creates a scope nightmare for any publisher in these areas...and also scares away the larger numbers looking for guidance generally...or those not wanted/willing to wade through the mass of "specific-to-others-but-not-me" scenarios before finding the one diamond that fits their setting...

We take our fundamental knowledge for granted and so did the ITI

skeptic — Thu, 17 Sep 2009 21:51:32 +0000

thanks, we're getting to a very fundamental question here. So fundamental I've moved it up to a blog post

Where does it say Incident = Call???

mbuzina — Thu, 17 Sep 2009 21:06:11 +0000

Hi skep, I have not read the whole mile long discussion here, but I must say I can compare your question to someone looking for an explicit proof that an ice cream is not a car.

No documentation I have read (Cobit, ISO 20K, ITIL 1, 2 & 3) talks much about calls (the DS 8.2 is the closest). So why should an incident be a call? Why do people just assume an incident to be something just because some vendors have named the records in their system calls (requests? tickets? anything else anyone?). Why do you have to explain to your client that apples and grapes are not same and then you have to find best practice to prove it? Just go to chapter 12.4.2.1 in CS (common sense) and you may find it.

Who ever said that ITIL, COBIT or anything else contains a model of the objects involved in ITSM? I know it is time for one, but still is none. If we get to a single (object / data) model, things may become easier, but the vendors will be comparable and they won't like that at all.

Regards,
Marc - http://buzina.wordpress.com

Perhaps Fault and Error are the same thing

skeptic — Thu, 17 Sep 2009 19:45:44 +0000

An Event is just something that happened of interest. the vast majority of them do NOT lead to an Incident or Error or Fault or Problem.

An Error is (by that definition) a state of a thing - no action associated with it. there should be a related Problem which involves the action.

A Fault is a type of Response, a work ticket, a job to be acted on just like an Incident or Request is. There is a response process associated with it. It usually leads to a Problem (there may be a few rare scenarios where it does not - where we choose not to fix the Error identified by the Fault report).

Perhaps Fault and Error are the same thing, but I remain convinced Fault and Incident are NOT the same thing: muddying the two Response processes of Fault and Incident together as ITIL V3 did only makes for a very unclear and confusing definition of what an Incident is, and it confuses and complicates the communication, prioritisation and escalation.

Where's the beef? :-)

DavidM — Thu, 17 Sep 2009 15:11:39 +0000

I said we don't need a "fault" -- and frankly I think it's very confusing in the context of Incident.

An Incident is the unplanned interruption or degradation in performance.

I don't have any problem with the definition, as it is.

An Event is a change in state that has significance...

Again, NO problem with the definition.

My issue is that I would have rather seen them reference Event as part of the rest of the definition of Incident.

As I said, to include "Fault" in the context of Incident is wrong, not needed, confusing... and I think we agree. I know we do about this: A fault isn't an incident!

In fact, if anything I'd relate "fault" closer to problem (since it's likely to cause incidents :-)) than anything else.

BUT: Fault IS defined with "See Error" and Error is defined as (in the Service Operation volume):

A design flaw or malfunction that causes a Failure of one or more Configuration Items or IT Services. A mistake made by a person or a faulty Process that affects a CI or IT Service is also an Error.

So, in the words of Clara Peller: "Where's the beef?" :-)

David

(for those who don't remember or don't know:
http://www.youtube.com/watch?v=Ug75diEyiA0 )

-d-

A fault is not an incident

skeptic — Wed, 16 Sep 2009 09:09:00 +0000

Don't be such a traditionalist. There's either one kind of request (including requests for restoration of service) or there are lots - there certainly aren't two for any reason other than historical.

read the post I referred to: I believe there is one entity, a ticket or request, with many categories, and there are variations on a core process for each category or type.

Specific to fault: a fault is "most likely the cause" of an incident but not necessarily: that's exactly why they had to invent the clumsy V3 definition - to cover the times when it isn't.

here's the reasoning they used to lump faults in with incidents: "If an event detects a fault, we need to run around being urgent until we fix it. let's see, the process for running around being urgent is the incident process therefore a fault is an incident." Wrong. there are several running-around-being-urgent processes for several categories of ticket or request or whatever we call the master entity.

AND THEY ARE DIFFERENT PROCESSES. We do not respond to a fault and an incident in the same way. For a start a fault has no user, and is not subject to an SLA. Incident prioritisation doesn't work for a fault: remember no service is impacted. Escalation communication matrices are also different: "hello Mister Business Owner, its 2:30 am and we are calling you to tell you that we have an internal fault that hasn't impacted any of your services yet but it is really serious and we think it might". yeah right.

Cmon throw off those mental chains! A fault is not an incident.

What's reality?

DavidM — Wed, 16 Sep 2009 03:41:41 +0000

I don't know that "fault is needed if the definition an incident changes to also reference Events.

An unplanned interruption is an incident.
Degraded performance == incident.

Both, as you say deviations from expected or agreed (I'd also add perceived) service levels.

I don't see fault as necessary (in that it's most likely the cause of one of more incidents aka a problem and therefore covered). In fact, I think the addition of the term might be confusing...

... and reality is still covered. :-)

Bottom line: the customer/user doesn't care about the distinction if things don't meet expectations.

re: Request Fulfilment (the process to handle everything else that isn't an incident). Without digging into it in more detail, I can accept it as the catchall for everything else. Note: other than querries for advice (and in some organizations that could also be covered) each service request (i.e., everything that isn't an incident) is also covered by and SLA and subject to review by CSI and SLM with a SIP if necessary.

(Alphabet soup, anyone ?? :-))

David

Semantics -- again :-)

DavidM — Wed, 16 Sep 2009 03:31:12 +0000

Back to the concept of working and the way things were written (and probably edited).

We're actually in agreement, though I would have used different language to say the same thing. :-)

David

ITIL analogy

skeptic — Tue, 15 Sep 2009 20:20:17 +0000

You've prompted me to publish one of the backlog of about 40 blog post ideas I have: a similar analogy for ITIL you might like

inward-facing technology focus

skeptic — Tue, 15 Sep 2009 20:08:00 +0000

Exactly. That's an incident. See my other comment: incidents and faults are not the same thing but parts of ITIL V3 are still written with an inward-facing technology focus, not an outward-facing service focus

Ah, Perception!!!??? :-)

DavidM — Tue, 15 Sep 2009 20:01:39 +0000

Rob,

You've raised a very interesting point. Typically the way things SHOULD work is the various targets are defined in the SLA supporting this service. However, if the performance or availability (etc) don't meet expectations, what's happening? I've been in 1 organization where users thought things should be faster because of the way their management set expectations. Actually performance was well within the negotiated targets in the SLA. However, perception is reality.

After some discussion, I suggested the client generate an incident. The solution didn't involve any changes to the infrastructure. Instead we generated an RFC to add or change training about the service to better (properly) set and manage expectations.

David

half-assed descriptions

skeptic — Tue, 15 Sep 2009 19:57:00 +0000

As I've blogged eslewhere, there aren't 2 processes (incident and request), there is one process with at least a dozen categories.

ITIL V2: one process: incident, everything else ignored
ITIL V3: two processes: incident, and everything-else

Both are half-assed descriptions of the true situation. maybe ITIL V4 will do it properly

An Incident is a deviation from expected/agreed service.
A Fault is something broken.
An Event can alert us to either or both.
Both can lead to a Problem.
A Problem might generate 20 Incident reports and two Fault reports - perfectly normal.

Clear. Easy to grasp. Reflects reality.

You know what I meant

JamesFinister — Tue, 15 Sep 2009 19:55:23 +0000

Delegate:"But ITIL" (V1 in those days, but obviously we didn't know it was only v1) "says ...whatever"

Well Known ITIL celebrity " Yes, I know it does, I wrote that. I was wrong."

Delegate "But ITIL says.."

WKIC* "Yes, but I wrote it and I was wrong. It won't work"

Delegate "But ITIL says.."

WKIC "ITIL didn't say anything, I said it, and I was wrong."

Delegate "But ITIL says..."

I think the exchange lasted twenty minutes.

*Name of WKIC available on request. I did worry in the early days of the Foundation exam that he could never remember the right answer to one question on the dummy paper, even though it was his own question, proving that the best of us can be tripped up on the process v function issue.

Event Management is abnout reporting

DavidM — Tue, 15 Sep 2009 19:53:21 +0000

Diagnosis is not an activity that is part of Event Management. Notification, detection, filtering, correlation, trigger, response selection, review, closure, yes; diagnosis, no. How the event is to be handled is part of response selection.

Whether it's reported to Incident Management, Problem Management or both or something else happens is part of the response selection activity.

David

Oy! :-)

DavidM — Tue, 15 Sep 2009 19:41:53 +0000

Jim,

I've been in the room and had the same experience both as a delegate and as the author!

The word "Chutzpah" comes to mind. :-))

David

Experts and everyone elses

DavidM — Tue, 15 Sep 2009 19:37:58 +0000

I'm also an ITIL Trainer and ITSM consultant (been in the ITSM space almost since before it had a name, but that's another story :-)).

I don't have any problem suggesting the Experts might want to take another look. We spend the time working on what is behind the ITIL definition and also point out how their interpretation might not jibe. I've NEVER gotten the comment that even suggests I don't (a) know what I'm talking about (b) don't know "X" (c) or that I'm deviating from best practice -- in over 25 years of being an independent "ITSM" consultant.

I also have not found incident-problem debates to be endless. I explain it this way:

Everyone is familiar with the difference if we take it out of an IT context. Try this approach: Question, if someone sneezes or coughs, what's the cause, what's the problem? Answer: You don't know if it's allergies, bacterial, or viral without doing some investigation (potentially including tests like blood work). Any doctor will tell you that the symptom is just one potential manifestation of the real problem. So, as the doctor, what do you do? You treat the symptom (incident) in the best way you can, given the information avaiable from the patient until the real cause (problem) comes back after you've done the investigation and tests. Effectively the Doctor is involved in Incident Management, the lab (or other diagnostic tools, like MRI, CAT scan, X-Ray, etc) are part of Problem Management. The two work hand-in-hand to get the patient healthy.

Put another way: In medicine: The symptom is never the cause. Same thing is true in IT, the Incident (symptom) is never the Problem (cause). I also refer them to the quote I posted here from the Service Operation volume that states rather emphatically, that problem and incident are separate entities and remain so, always!

From there it's always been a, "Next," and we're on to the next topic.

David

Event

JamesFinister — Tue, 15 Sep 2009 19:17:07 +0000

Don't have the books in front of me - but does an event get resolved as such, or do they just end? I remember an old debate about whether we resolved incidents but removed problems.

Would have been happier with specific mention of Event

DavidM — Tue, 15 Sep 2009 16:36:22 +0000

I think I understand the intent of the way ITIL V3 defines an Incident -- and that was specifically to include Events and Event Management as part of the proactive process of resolving Events that could lead to incidents before the customer/user is aware of the issue.

However, the current wording stinks. If instead of trying to get cute, if they'd referred explicitly to an "event" things might have been better. For example:

...unplanned interruption or.... An Event that has not caused a visible unplanned interruption or degraded service quality is (or could be -- and leave it up to the organization???) also an incident.

One of the critical aspects of Event Management is knowing what "normal" is so that when something happens that has "significance" it can be identified as deviating from the baseline (aka normal).

Also, I thought (and you've hit part of the problem that I hope will be addressed with the planned revision) is the confusion between "incident" and "Service Request." The queries and questions aren't incidents, that are service requests.

David

All too true!

JamesFinister — Tue, 15 Sep 2009 11:29:35 +0000

I've been in a classroom with one of the original authors when a delegate couldn't understand he was telling the person who wrote the book that he was wrong about what ITIL meant

James Finister
Wolston Limited
www.wolston.net
www.coreITSM.com
http://coreitsm.blogspot.com/

"Best practice definition"

vinodka — Tue, 15 Sep 2009 07:54:10 +0000

Yeah, I agree with the perspective of both you and David. I used to keep that perspective, explanation and interpretation till V3 came out.
However, my debate was basically from the ITIL V3 definition of Incident.

As a trainer, consultant etc when you work in the Industry, the client organizations (fortunately or unfortunately) has "ITIL Experts" who will go with ITIL definition (and their/their trainer's interpretation of those!).
It next to impossible, for convincing them - because they have a "strong" back up of the "Best practice definition" in ITIL! Many a time, I myself has landed into messy situations for giving logical / practical explanations that might not go "theoretical" as ITIL - to the extent of comments like: 'You dont know ITIL' or 'you are deviating from 'best practice'!' - to the extent of eroding the trust the client has on your "knowledge" or "expertise".

Incident vs Problme debates are always end-less, so on top of that if we add messy definitions of Incident and Problem, it is fun time!

I hope, the new "Editions" address these critical issues with best practice definition/documentation.

Vinod