The IT Skeptic - Comments for "ITIL V3 Service Operation disconnect between Incident and Problem Management"

problem records are incomplete

skeptic — Fri, 18 Jun 2010 20:56:00 +0000

"create a Problem for every Incident" is NOT what i said, or at least not what i meant. Sorry if you inferred it that way. I'd have thought it is pretty clear that i understand "Problem Management's job is to remove the cause of Incidents. It's not to fix the specific singular cause of one incident." I certainly didn't say that. Are you confusing problem management with problem records.

If an incident was resolved without invoking the problem team, but it was caused by an underlying problem now resolved, however you define a problem, then I think it should either be linked to an existing problem record that caused it and that problem closed, or a new problem record should be opened and then closed recording how the problem was resolved. If you choose to regard a failed hard drive (I'm assuming you mean on a desktop/laptop) as not a problem then that is fine so long as the scope of the definition of "problem" is well understood and consistent.

A better example would be a failed network or storage component that causes an incident, or several incidents all related to a master incident. Level 2 support identify the cause, swap the device, and notify the Service Desk to contact the users and close the incident(s). There was a problem but no problem record. A week later it happens again but this time there is no spare (guess why). They open a Problem record and make whatever workaround they can until the spare arrives. In order to report on how often that device is failing, or to recognise a pattern of failure, you now need to report across both incident and problem records: the problem data on its own has little meaning.

If you don't open a problem record every time there is an occurrence of whatever-you-define-to-be-a-problem then your problem records are incomplete. i don't think problem records exist solely as work tickets for the problem team - I see them as information for other processes, including CSI.

Misuse of Problem

RichC — Fri, 18 Jun 2010 14:02:31 +0000

I know this is quite old, but I had to respond to this last post. We were taught explicitly that you do *NOT* want to create a Problem for every Incident. Every Problem was created due to an Incident, but not every Incident has a Problem spawned as a result. I can't tell you how many times that was repeated.

For example, an application failing because of an issue with a server may only generate an incident. That organization may have plans to deal with that failure, execute them and restore service. There is no underlying "Problem". Another organization could have something similar happen, but identify that the outage experienced is not acceptable and that an underlying Problem is that there's not sufficient redundancy built into their design. Changing their architecture could eliminate that service outage. Another organization could identify that, after service was restored, the root cause was a bad driver on a system and that they use that same driver on 500 other systems. That would then spawn a Problem.

Problem Management's job is to remove the cause of Incidents. It's not to "fix" the specific singular cause of one incident. A failed hard drive is not something that Problem Management would deal with. A cracked screen on someone's laptop because they dropped it is not something that a Problem would be generated for.

far more accurate and complete problem reporting

skeptic — Mon, 23 Nov 2009 03:24:18 +0000

Not necessarily. What you describe is only one manner in which to use problems, and I think it has issues. if you only open problems when there is a potential recurrence, then you are using the incident record to cover some instances of problems and the problem record to cover others. if you only use the problem record to track the instances you describe then I'd say your problem reporting is pretty useless.

I think it is fairly common for a problem to be created from every incident where there is a problem (i.e. an underlying cause to be "fixed") identified or even suspected. This gives far more accurate and complete problem reporting

ITIL's failure to make these considerations clear is a deficiency which will lead to many sites going down the wrong paths. Nice future work for consultants trying to sort it out I guess.

Well, here's the intent: If

Hazen — Mon, 23 Nov 2009 02:20:25 +0000

Well, here's the intent:

If this issues happens again it may constitute a problem; ie; services will be impacted as a result of this incident, and we cannot prevent this incident's recurrence therefore problem management is to maintain knowledge of this incident and the scenario in which it occurred to prevent the scenario from arising again. This is seen when dealing with compound issues that have 2 or more root causes.

ITIL to become a religious text

skeptic — Thu, 08 Oct 2009 21:00:24 +0000

Atul, I think we are all pretty clear on the distinction between Incident and Problem.

I've raised the possibility before that ITIL is just a casual fireside chat not to be taken too seriously. But that's not how it is sold. If ITIL is only broadly applicable in spirit and not necessarily in the detail, then how can we have four-tier certfication and product compliance? No that's a cop-out, sorry. An excuse for a sloppy product.

The last thing we want is for ITIL to become a religious text, comeprehensible only to learned scholars who make a living interpreting it to the lesser mortals. ITSM isn't brain surgery and it isn't mysticism.

ITIL is guidance. the interface between incident and problem is fundamental. it should be described properly. it's not.

IM/PM so you're not working all AM/PM

AndyIvey — Thu, 08 Oct 2009 16:18:22 +0000

That’s pretty much how I’ve always understood it. IM puts the fire out (workaround or solution) and PM (if necessary) will clean up the mess, investigate cause, and prevent future fires. A lot of clients want to push the high severity incidents straight to problem for “added visibility.” The thing these environments all have in common is poor event correlation at the service desk. They need a second process (PM) to cover a gap in their incident process.

This reminds me of the difficulty so many ITSM tools have with logging calls and marking an incident as the “lead”. This is where clients that ship high severity incidents to PM have the advantage. They can overcome tool limitations and log every call as an “incident” and then link them all to a single, lead problem.

Orientation of IM / PM.

Atul Kherde — Thu, 08 Oct 2009 12:39:33 +0000

My own humble two cent thoughts:

Incident Management: should be more concerned about 'getting it rolling first'. In other words, IM should help the user to do what they want to do, and keep the focus on resolving the user's difficulty. 'Repairing the infrastructure' can be a secondary objective. e.g. If a user is not getting printouts, then IM should FIRST the user to get a printed copy - even if by a workaround of redirecting to another printer, and SUBSEQUENTLY try to fix whatever is wrong with the errant printer - if possible. The incident was about "not being able to get a printout", so the moment the user gets the printout, the incident is closed.
In short, IM is an outward looking process, which is primarily tasked with helping users for higher productivity. IM might also provide information to PM regarding any problems, etc. but that is secondary.

Problem Management: On the other hand, the PM process is concerned with keeping the infrastructure healthy by identifying and resolving problems lurking in the infrastructure. The PM process scans through the incident database to look for trends, frequency (repeating incidents) and high impacts to identify problems. In the above example, if the printer repeatedly fails, it will be captured in the frequency analysis and someone will start thinking, "Why is this printer failing again and again?" As the root cause is unknown, it can be logged as a problem for further processing through the Problem Control. The moment the root cause is KNOWN, it doesn't remain a problem anymore, but becomes a KNOWN ERROR, and is handlled by the Error Control processes.
In short, PM is an inward looking process by which the infrastructure stays healthy by identifying and eliminating problems.

ITIL v2/v3 was written by a large number of authors as a collaborative effort. Let us take it in a generic sense, the way it was meant to be, and not a LEGALISTIC sense where every comma and fullstop matters. My personal opinion is that rather than harping and carping about "what the book says", we should capture the generic sense from these books and use it to implement 'sensible' processes in client environments as long as we stay within the generic boundaries of the processes.
Which is why it is said, ITIL has to be adopted and then ADAPTED. If everything was supposed to go by the book (like aircraft maintenance procedures) then there was ABSOLUTELY no need and scope for ADAPTATION.
Another important perspective: Many people might object that my response is more v2 than v3. So, whattt? v2 and v3 are not black and white..! Personally to me, as long as the purpose is served, any discussion about whether something falls in v2 or v3 seems futile. These are not two different things!

Thanks for reading patiently.

Atul

obvious but essential

skeptic — Fri, 25 Sep 2009 00:53:50 +0000

Here's another piece of Incident Response that seems to me obvious but essential to describe if ITIL is actually guidance. it's from the OGC Change Log, issue 178:

In 4.4.5.9 it is suggested that related Incident records that are still Open should now be closed. However, the situation of related CLOSED incidents also needs to be considered - these may need to be revisited, and perhaps re-opened. This is particularly the case where problem resolution overcomes the need for users to resort to a sub-optimal work-around. (This might in some cases be handled by a message broadcast on the Intranet.

deficiency

skeptic — Thu, 24 Sep 2009 03:35:46 +0000

No matter how you frame it, there is a process for resolving problems. that process has a number of triggers, (including triggers from the separate proactive problem discovery process).

one input is a trigger from the incident process which passes incident information.

there is an incident resolution process whose objective is to restore service. One secondary output from that process is a trigger (and information) to initiate the problem resolution process.

That trigger may be secondary to the incident resolution but it is still an extremely important linkage. outside of actual servioce restoration it is the second-most important thing the incident process does.

And yet the documentation of the incident process mentions it in only one of several places where it can happen.

and that doesn't strike you as a deficiency in the documentation?

Strictly Speaking it's really about ITSM

DavidM — Thu, 24 Sep 2009 03:13:03 +0000

I think part of the problem is that we're attempting to be much too literal. The real subject is less ITIL and more specifically ITSM. In other words, it's not about "doing" ITIL as much as it is USING ITIL to achieve ITSM. It's guidance, not "writ" (holy or otherwise :-)).

Incident records are just one source of input to Problem Management. Incident and Problem Management aren't sequential with Incident Management throwing something over the wall to Problem Management (and the team that will work the reactive part of the problem management process waiting). In reality it's asynchronous operation between the two processes (Incident and Problem Management).

David

Good article

aroos — Wed, 23 Sep 2009 14:48:21 +0000

Jan's is good, read it.

Aale

Output of Incident Management is resolution

DavidM — Wed, 23 Sep 2009 12:42:36 +0000

We may have to agree to disagree. If an incident and problem are separate incidents, and remain so always, then 1 of the outputs of incident managemnet is not, cannot be a problem. To do so would create a linkage that should not exist.

One of the outputs of incident review may indicate that this is (or likely to be) a recurring incident, and if so create a problem record for investigation. But this is done in conjuntion with Problem Management.

Incident records are in input to problem management (along with a lot more including the Service Desk, Supplier Proactive Problem Management, etc).

This is one of the challenges I had with V2 that V3 resolves. Lifecycle arranges the processes in an ordering or sequence. So, could the wording be improved? Sure. Is there an issue regarding "linkage" between incident and problem? Not the way I view it.

SO Section 4.4.5 mentions Proactive Problem Management and it's also mentioned in Figure 4.4, but the detailed section isn't there, so it's not a new concept. Adding error control would be (and I don't think it's necessary, but that can be a topic for another thread or post :-))

David

the biggest flaw in itil.....

jvbon — Wed, 23 Sep 2009 11:55:32 +0000

... is the misconception of process and function. If you want to learn more, please read the article I wrote on this issue in the "IT Service Management - Global Best Practice" guide, volume I.
The result of this flaw is that ITIL cannot be implemented, which is a generally accepted fact. Instead, ITIL can be perceived as a reference model, with useful guidance - but you need an implementation framework (not a model!) to make it work. Currently, and afaik, there is only one implementation framework available in the market.
To answer your question: Availability planning is not a process in terms of incident/change/problem management being processes. It is a highly polluted term that is already covered by some of the core processes (in casu incident and problem....). You can even entirely lose the term if you have covered your basic processes.
A second big flaw in ITIL is that it has an inconsistent terminology, causing many semantic problems. Cause of this is the general lack of architecture in the model. This can all be solved, but it requires that you adapt a good architecture, rebuild your framework, and as a consequence you change some of the guidance of ITIL. I've read many posts in this blog environment in the latest months that clearly illustrate how hopelessly lost many people are when they stick to the ITIL terminology.

"management" is not a process

skeptic — Wed, 23 Sep 2009 11:32:14 +0000

"management" is not a process. Maybe it is an sometimes an activity rather than a function but it is never a process. Managers do not execute repeatable defined transactions with inputs and outputs - at least good ones don't. They own, manage, measure and improve. I was overjoyed when they called it Request Fulfilment.

Incident resolution is a process. So too is problem resolution. And change review. Maybe so is Availability Planning
JvB! It's late, help me out here - you've done this analysis so well...

Both a function abd a process

aroos — Wed, 23 Sep 2009 06:36:34 +0000

I think one could have a Problem Desk and a problem management process. Proactive problem management should be an activity of the desk. In real life I have seen Service Desk managers and IM process managers doing the proactive problem management.

Aale

Processs and Function

JamesFinister — Wed, 23 Sep 2009 06:13:35 +0000

I thought it was said somewhere in V2, if not V3, that there is a distinction between problem management qua a process and problem management qua a function? I certainly remember teaching in V1 days that when a problem manager is involved in resolving major incidents they are not doing problem management.

I'll have to go and look it up.

One of the outputs of incident process is a Problem

skeptic — Wed, 23 Sep 2009 04:43:00 +0000

The Mandate for Change explicitly says "no new concepts" but evidently that doesn't include missing concepts like proactive problem management. Wonder if they'll put error control back while they're at it?

Strictly speaking and never mind what ITIL says, Problem Management is a function. Problem Resolution is a process. It is a bit late for ITIL to start getting exact about the word "process" :)

likewise Incident Management, but whatever. One of the outputs of Incident Resolution process is a Problem. At what points in the process can this output occur? That is the question not properly answered by the book that started this whole discussion and it seems an important one.

Another approach

DavidM — Wed, 23 Sep 2009 04:18:08 +0000

Sorry that it took me this long to be able to articulate the issues in this way.

Both Incident Management and Problem Management are processes. Processes have 4 common characteristics: measureable, done on behalf of a customer/stakeholder, produces specific out, and has inputs/trigger.

Inputs to problem management include incident records, Event Management output, Access Management and more. So, the linkage is there as inputs to the process. I get the impression that there is the possibility that some of the argument for the type of linkage suggested would be necessary if Problem Management was a Function.

Spend some time earlier today talking with Dave Cannon about some of this (notion of function v process) and he concurred. He also suggested that one of the areas that should be a concern is the explicit absence of proactive problem management -- coming in the revision.

David

Very good point

aroos — Sat, 12 Sep 2009 06:22:52 +0000

The Problem - Incident interaction is difficult and we definitely need a best practice for this area. My feeling is a lot of people are not even aware of the difficulty.

Aale

Problem Identification

david.stucky — Fri, 11 Sep 2009 18:03:25 +0000

I fully agree that the guidance is less than clear on this point. But, it's not complicated. Just a little be of reasoning and awareness of generic process structure pretty clearly tells us that the first and probably most helpful point at which problems are ID'd comes during the Initial Diagnosis step of Incident Management.

In short, this step in Incident Management provides the best opportunity to prod Problem Management into action...

You can read more about that here.