The IT Skeptic - Comments for "How ITIL gets Incident vs Problem wrong"

Exactly. KISS(Keep It Simple

Martin — Sun, 02 Sep 2012 12:13:57 +0000

Exactly. KISS(Keep It Simple Stupid)

Incident vs. Problem vs. Risk

guerino1 — Wed, 29 Aug 2012 23:32:53 +0000

Hi,

I know this has been beaten up, over and over again, and I don't know if this helps but some of the enterprises I've worked for or helped view Incidents, Problems, and Risks in the following manner...

Risk(s) = Potential Incident(s) (or negative outcome)
Incident(s) = Disruption (or negative outcome) caused by one or more Problem(s)
Problem(s) = One or more things that require correction in order to prevent or avoid Risks from occurring, at all, or Incidents from happening, again.

I hope this helps.

My Best,

FG
--
Frank Guerino
The International Foundation for Information Technology (IF4IT)

as simple as possible

skeptic — Fri, 24 Aug 2012 22:01:47 +0000

I'm with Aale on this

"Make things as simple as possible... and no simpler"

No

aroos — Fri, 24 Aug 2012 08:33:11 +0000

Yes, ITIL is a mess but not that way.

The original idea of having several lines in support is good but the are working in the same process. Also the idea of having someone looking for hidden causes and trying to prevent future failures is good.

If you call 2nd line PM, you lose both of these benefits.

Aale

Bad Interpretation of ITIL = Bad Support

Martin — Wed, 22 Aug 2012 19:38:28 +0000

I think this is the whole point. People are getting so hung up on the ITIL gravy train that they have forgot how to actually provide support. I think the simplest way to assimilate ITIL to the real world is to think of IM in the same vein as 1st line (which could or could not include helpdesk, desktop, server, network, etc.), and PM resembles 2nd line and beyond (could or could not include desktop, server, networks, etc.)
Organisations are trying too hard to assimilate their support functions to ITIL and making a real hash of it resulting in a balooning of process and ultimately ineffective support to the user base.
Just rememeber what it's all about - KISS

Real life and book

wernerroth — Fri, 17 Aug 2012 06:13:28 +0000

Rob, your split is closer to real life than ITIL. IMHO there are two confusions in the ITIL view of Problem Management.

In real soft words: An ITSM practice needs "someone" who spends time trying to avoid future Incidents by a close look after the Incidents are fixed.

The approaches in real life are very different and always far away from the ITIL view. For example in desktop computing a lot of organization do not care about 10 or 50 Incidents which may have the same root cause. They re-install on the machine, full stop. (BTW: I do not like this)

So here ITIL could be a better practice additionally listing some typical (mature) industry approaches (BTW: Not just in Problem Management).

Second confusion "pro-active". I assume this comes from mechanical parts, there you can measure slackness and say "this shaft will break down in 48 h". IT systems are deterministic machines. They break down by sudden. Ex-post IT experts can tell you why it broke down after 47 h.

Best Regards
Werner

PANIC (Problems And NOT Incidents, Clearly)

RichPem — Wed, 08 Aug 2012 14:40:30 +0000

Rob, I make you right that the definition of both incidents and problems needs attention. For problems, I have for a long time been using - word for word - the definition you've written in your post.

I think the incident one you've proposed is more problematic. Whilst Incident Management is by definition reactive, that doesn't - nor should it - mean that we wait for a user to spot the service interruption and report it before we act on it. Surely we hope that Event Management will spot the event that causes an Incident and give us warning way sooner than it will take users to. (Would we want our ISP to wait for us to call, or notice the incident and fix it whilst we sleep?).

I do agree that ITIL has handled the 'failed component' clumsily; I think it's because there's no actual problem investigation involved - the cause of the potential incident is known, it's therefore already a known error and very probably the remedial action is known too and doesn't need a business case approval before taking it.

Even if you talked about it in risk terms I don't think it gets less muddy. Incidents and problems might be analagous to issues and threat risks. The thing about a risk is that it's yet to happen; you could rightly argue that service hasn't been interrupted if it's a disk in a redundant array set, but there most definitely has been a fail event.

And incidentally, I imagine that many of organisations will have their Event Management systems raising incidents for any exception event that occurs. This is probably at the root of ITIL's wrestling with the definition. How do you automate the separation of exception events into 'incident' and 'problem' without overcooking the set-up and management costs?

Personally I think the answer to your question lies in problem priorities. It's something I don't think we handle anywhere nearly as well as we do incident priorities. Problem priority is about [potential] impact and urgency [~ likelihood]. If a component fails and the service risk level significantly increases then that's because the impact and likelihood combination has just changed. Action should be taken accordingly.

There's really not a problem with having component failure events being classified as high priority problems with remedial action comparable to a high priority incident; and if it suits your organisation, is there really a problem with such events being classified as incidents (particularly if they can be separated in MI).

So my definitions would simply be:

Incident: An unplanned interruption to an IT service or reduction in the quality of an IT service.

Problem: The cause or potential cause of an incident.

I have a fundamental problem with your statement "The conflicting priorities of restoring service and identifying cause are not mixed within one process, team and accountability." It's nice in theory, and I definitely agree with two-thirds of it - but not all organisations can support incidents and problems being separated to different teams for investigation and resolution. The processes may have different goals, but diagnostic and resolution activity in practice has much in common between both - and of course it will be the same mix of technical domains involved. Ultimately I think getting the priorities right will handle most of the conflict, with 'getting the process right' lapping up the rest.

Rich

So here, I think, I disagree.

kaimar — Wed, 08 Aug 2012 12:41:42 +0000

So here, I think, I disagree. Event Management detects a broken service in two cases - when there is yet no user impact and where there is already user impact. When there is no user impact yet, then maybe indeed it would be better to have Event->Problem workflow. If there already is user impact, then the workflow would be Event->Incident->Problem. Some of the Incident Management would be done by Service Desk (comms, searching the KEDB, etc) and some of it would be done automatically (automated repairs). Not all incidents that impact users need to have comms attached, usually because the impact lasts for a very short time, while the resolution can be both manual or automated.

In many cases service desk doesn't even need to be notified, because the incident, detected by event management, was resolved using automated repair. Is that automated repair problem management? I don't think so, because the only difference compare to your idea of incident management is the fact that the solution was automated, not manual.

going in circles

skeptic — Wed, 08 Aug 2012 10:38:00 +0000

This is going in circles.

Detecting a broken service is an Event. The Event Mgmt process raises a Problem record for that service (or Aale can call it a Fault if he feels better about that) and the Problem Mgmt techs get on it.

The service desk would be notified of the Interruption and would handle comms to users. That's why we have a service desk function in ITIL distinct from the processes. Comms isn't a process, it is an activity of the SD function.

In some cases Incident Management might contact users proactively to push them workarounds.

Since I've rejected the ITIL definitions of just about everything and introduced the Interruption entity I can hardly be accused of trying to "stay within ITIL".

a view too narrow

kaimar — Wed, 08 Aug 2012 07:11:06 +0000

"An incident is that a user perceives they are not getting their agreed service levels." Do these users always contact Service Desk to let the service provider know? Nope.

Monitoring can let the service provider know that something has happened and the user is impacted (slower service or, as I mentioned, occasional 503 pages). This needs to be dealt with.

Synthetic clients can test services 24/7 and can spot issues impacting n% of users. This needs to be dealt with.

Now who is responsible for taking care of these types of issues - impacting the user, but not reported by the user? What kind of communication with users is required to let them know of the issues and the resolution?

It seems like you are trying to redefine ITSM concepts while for some reason staying within the limits of ITIL (as Aale also commented). The ITSM world is much wider than that. I know that you know that :) Sometimes the reason why you cannot finish a puzzle is that you're missing too many pieces, not because it is too difficult.

As I said

aroos — Wed, 08 Aug 2012 05:13:02 +0000

Don't you see how hopeless it is to use ITIL terminology but give it a different meaning.

Yes

skeptic — Tue, 07 Aug 2012 22:12:53 +0000

Yes.

That's not what ITIL says, but it is what I think it should say.

An incident is that a user perceives they are not getting their agreed service levels.
Incident management is about getting them to again feel they are getting their agreed service levels.
Incident management is an outward facing process - a subset of request fulfilment - dedicated to providing maximum service to users.
Incident management is the responsibility of front-office outward-facing customer-service (actually user-service) teams with their own tools around service desk, CRM, SLM etc

Period. Nothing else. One process one purpose. one accountability, one set of goals and metrics. incident management. Don't confuse an incident with an interruption. Different entity.

There are inward-facing back-office technical teams whose role is to look after the components of the service. As part of that their job is to remove causes of service failure and therefore to restore the underlying service. Different people, different purpose, different goals and metrics, different tools. Ergo different process. Problem Management.

Split the rock.

only user contact?

kaimar — Tue, 07 Aug 2012 21:33:09 +0000

Are you saying that Incident Management applies *only* in cases where the users themselves contact the Service Desk (by whichever means) about the issues they have encountered with the service, and everything that does not originate from the users is a part of something else, e.g. Problem Management?

the whole point of my post

skeptic — Tue, 07 Aug 2012 19:31:42 +0000

The point of my post is that you are taking too broad a view of "incident". I say it should be focused on users. One process one purpose. Sure it is part of a wider picture of restoring a broken service. We have problem management for that. Problem mgmt's purpose is to remove the causes of failure. The whole point of my post is to say don't double up on that.

Don't use the word incident

aroos — Tue, 07 Aug 2012 11:41:08 +0000

One of the main sources of confusion here is the word incident, which has several meanings. I don't think one can have intelligent discussion of ITSM with ITIL terms;)

"Incident management should

kaimar — Tue, 07 Aug 2012 11:31:36 +0000

"Incident management should be about restoring service to users" - yes. Restoring involves restoring a failed service and a degraded service. In the first case users understand something is wrong (a 503 page, etc.), in the second case they might experience degradation but won't necessarily report it. Impact is there nevertheless. Many incidents should be taken care of automatically (restoring the service in 30sec rather than 30min). The rest do need nice people talking to unhappy users, but it only one part of the whole picture, not the whole picture.

falling into the same trap

skeptic — Tue, 07 Aug 2012 11:20:31 +0000

Nope. You are falling into the same trap ITIL did when it bunged failed components in there.

Incident management should be about restoring service to users. the process should be built around that, and the people should be skilled at that. fast restore, finding workarounds, being nice to unhappy people.

If you want to fix a broken service, that's a problem. use the right people and tools to fix it.

That was the whole point of my post.

interruption != downtime

kaimar — Tue, 07 Aug 2012 10:26:35 +0000

Makes sense, in general. But:

"An Incident is a user reporting an unplanned interruption to a service."

Sometimes the user realizes there is an interruption, and sometimes they don't. I don't think incidents can only be reported by users, they can also be found by monitoring - e.g. when something happened and the service is slower than usual (therefore directly impacting user experience) we shouldn't rely on just the users to report this. And the more automation there is in place, the more are Event, Incident and Change Management becoming one process (Find&Fix). This is divided into Manual (needs someone to investigate/repair) and Automated (automated fixes). The latter, in turn, can be divided in two: Reactive (service degradation beyond tolerance) and Proactive (service degradation within tolerance [no user impact or tolerable user impact]).

When redesigning/redefining ITIL processes, we should not build the initiative on the model where stuff breaking is considered an exception.

More mixed up still

JamesFinister — Tue, 07 Aug 2012 09:02:16 +0000

Risk management is just one of the processes/capabilities thta I think ITIL doesn't map on to problem management in a way that is useful. I stress the term useful because this isn't an academic debate - failing to understand and implement effective problem management costs companies money, reputation and creates negative customer satisfaction.

At the simplest level many organisations don't distinguish between 3rd level support, the workflow of managing problems and the activity of actually identifying and removing the root causes. The result is often a mechanistic approach that never achives the desired outcomes, and often this approach is reinforced by carlessly framed KPIs and targets.

It is perhaps telling that in very few organisational designs that I've done in recent years have i made provison for a dedicated problem manager. Instead I prefer to split the process between CSI, the service desk, support teams and service managers.

Problem with the problem

aroos — Tue, 07 Aug 2012 08:32:58 +0000

...is that in many cases it is not a problem;)

Let me explain. The cause of the incident may be crystal clear. A component has failed. The SD can provide a workaround and fix the customer but it cannot fix the failed component. There is nothing problematic about the failed component, it is a calculated risk. There is a team which routinely fixes failed components. This is different from the situation where you have unexpected interruptions but do not know what is causing them.

I would kick problem management out and talk about Risk management. That would include problem, Availability and CSI. Unknown causes represent a potential major risk.

This in not so complicated but you are absolutely right that ITIL has mixed up the concepts. And each ITIL version/edition has different incident/problem concepts.

Aale