Stupid bloody terminology!

[fishkake]

Hi guys.

This is just silly. Look at this:

(pseudo-quote from "Incident Management" chapter of Service Support ITIL book):

Classification and Initial Support :

Classify incidents
Match Against Known Errors and Problems
Inform PM of new Problems, and unmatched Incidents
Assign Impact/Urgency
Provide Initial support (find quick resolution)*

Investigation and Diagnosis:

Assessment of Incident Details
Collection and Analysis of all related information, and resolution*
(including work around) or a route to n-line support

Resolution and Recovery:

Resolve the incident with a workaround*, or raise an RFC
Take recovery action

Could somebody please tell me the difference between the three things I have marked with a * !? Surely these are all the same thing! This is infuriating terminology, its proving incredibly hard to apply to our organisation.

Thanks peeps

Christoph

[rjp]

FishCake - I feel your pain - and can almost the taste that yummy golden coating of fried breadcrubs...

I have heard it said many times that experienced IT people coming to ITIL struggle more with the terminology than newbies. I suspect this is true. Like many other 'engineered' conceptual frameworks ITIL has what might be termed a sub-technical vocabulary which appropriates terms with fairly broad common sense meanings and stipulates more narrow, and hopefully precise definitions.

Having said that, it helps to bear two things in mind: a) The ITIL was written by a series of comittees of experts, and being the work of many hands is not totally consistant in its terminology. But all up it is not riddled with inconsistencies either. b) The underlying context for all the terms are the processes in which they 'belong'.

In Incident Management the term 'resolution' gets used. Resolution is also used in Problem Management. In Availability Management the term 'repair' get used for 'System Incidents' instead of resoultion. And so on. The slippage can mess with anyone's head.

And to address your marked '*' points. Resoultion is a 'stage' in the Incident Lifecycle. Which is what the Resoultion and Recovery reference is refering to. It is also the 'objective' of incident management and the process allows for the fact that the resolution of an incident ideally will occur as early in the process as possible. In the process context this means that a 'resolution' may be identified at the time the report of the incident is made. As a process stage however, finding a resoultion at diagnosis and classification does not contradict the definition of the stage. As soon as you apply it, you are by definition in the Resoultion and Recovery stage of the lifecycle.

Workarounds are resolutions - becasue they restore the client/business service (capability). They are however a type of resoultion ( a subset of the overall concept), and there are other ways to resolve an incident than workarounds.

In general watch for distinct 'entities' in ITIL that are generally thought to be synonymous outside it, eg: Resolution, repair, workaround, etc. or Problem, Incident, Known Error. Also keep an eye on the difference between the specific and the general. For example in general parlance a 'known error' could mean that it is generally known that network switches of type x have a tendency to a particular failure. In ITIL a known error is a specific control record indicating that an actual configuration item is 'broken'. So in general terms a known error might be seen as 'knowledge' and persistant. In ITIL a known error records a single state in the infrastructure and in fact goes away once the error is fixed. 'Known' in the process control context means, discovered and recorded (and ready to be actioned) - nothing more.

The process always provides the context in which the definition applies.

BTW: If you want to be entertained by how tangled one can get in terminology search for the Process Vs Procedure post in this forum

[itilimp]

*makes way through the fog and comes out in the sunlight*

I understand that they may be standardising and trying to eliminate the confusion caused by terminology in the refresh, is that correct?

[fishkake]

So I just go through each stage in Incident Management, but if I find a resolution, skip the rest and close the Incident, yes?

Why couldnt they just say this in the book. I was wondering why ITIL demanded that I resolve my Incidents at least three times.

Thnaks a lot, this site is proving quite a resource...
_________________
95% of computer problems are easy to solve, but most of the problems are in the other 5%

[rjp]

Not so much 'skip' the rest as complete them 'en passant'.

It might also be interesting to consider that the 'sates' incident records pass through in the processes is usually something like:

New
Assigned
In Progress
Pending (optional)
Resolved
Closed

Which isn't reflected in the Incident Life Cycle - but then the ICL does not show tracking. control, monitoring, ownership, (assignment), or escalations (though the later is in the extended process description). So the ICL is obviously intended to be an outline of the 'resoultion activity' more than a specfic process definition for an incident record.

[Fabien]

You can find info also in the IM process diagram where escalation is illustrated. In that part of the Service Support book, they define that the initial support is basically about basic troubleshooting, mainly based on existing information, while the analysis which is carried out in Investigation & Diagnosis is usually performed by a Specialist group. Thus in your original question, the scope of the activity (looking for a workaround, or actually investigating the cause of the incident) is what would differentiate the terms.

rjp might have covered that but somehow I felt like this would be a summary
_________________
BR,
Fabien Papleux

Accenture
Technology Consulting | Service Excellence
Red Badge Certified

Twitter @itilgeek