The IT Skeptic - incident

ITSM incident and problem: two names for three things

skeptic — Fri, 25 Jul 2014 10:59:19 +0000

Debate around the definitions of Incident and Problem never seems to end.
Here's my take on the fundamental issue that fuels the endless arguments: we have two entities trying to do three jobs.

When a service breaks, we have to deal with three things in support:

ITSM in Cherry Valley

skeptic — Sun, 17 Feb 2013 16:51:30 +0000

I'm getting lots of positive feedback about my series of articles for The ITSM Review, which use a train crash in Cherry Valley, Illinois as a case study for understanding incident and problem management. (It is part of a wider theme of my articles for The ITSM Review using railroad examples for service management).

It always mystifies me that people (and ITIL) don't grok this simple model: incident management is about users, problem management is about causes.

How ITIL gets Incident vs Problem wrong

skeptic — Mon, 06 Aug 2012 20:08:26 +0000

In ITIL, we don't separate Incidents from Problems properly. This causes a muddy and confused definition of both. Join me as I try one more time to make this clear.

Shopping: request vs incident

skeptic — Mon, 30 Jul 2012 19:47:23 +0000

Roy asked the question "Would you agree that there's no difference between walking into a store and buying something (perhaps asking a clerk where the item is located), and returning an item that is broken or which doesn't fit?". It was such a good example I decided to answer in a blog post.

The Standard+Case approach: applying Case Management to ITSM

skeptic — Mon, 18 Jun 2012 23:44:25 +0000

Here is an exciting new approach to categorising and resolving any sort of activity "tickets", such as requests (including incidents) on a service desk, problems, or changes. It is called Standard+Case until somebody comes up with a better name. I know there is so much to read these days, but if you have anything to do with service support or change management, read this. It'll change your year.

Standard+Case is a synthesis of our conventional "Standard" process-centric approach to responding, with Case management, a discipline well-known in some other industry sectors such as health, social work, law and policing.

S+C addresses criticisms of approaches like ITIL for being too process-centric and not allowing customers and knowledge workers to be empowered. S+C does not seek to replace or change ITIL or other theory: it expands and clarifies that theory to provide a more complete description of managing responses.

It provides a good skills path for service desk analysts that fits well with gamification. And Standard+Case is applicable to Problem Management and Change Management (and Event Management...) as well as Service Desk activities. S+C applies to anything that requires a human response: there's either a standard response or there isn't.

For more information about Standard + Case, see the Basic Service Management website.

Riddle me this: matching ITIL theory to the real world

skeptic — Fri, 21 Oct 2011 19:53:12 +0000

Calling all you ITIL theorists, philosophers, pontificators and pundits. Marty is back: our follower from the real world, trying to make sense of ITIL on its home grounds, the operations of big iron batch computing. Marty asks what happens after a service is restored? What does ITIL call the function of undoing the damage done while a service was unavailable? I have a view - of course - but I'm going to stay quiet - for a while- and hear what everyone else thinks. So have at it.

Choose your Major Incident Manager for who they are not what they are

skeptic — Sun, 13 Jun 2010 09:49:42 +0000

Could it be that the personality and skillset of the Major Incident Manager is more important than what role they have in the organisation? I think so. Too often we get hung up on theory and lose sight of what matters in a crisis - people.

The missing entity in ITSM models, the Interruption

skeptic — Sat, 24 Apr 2010 10:11:17 +0000

Long ago we used to follow the one true Codd, and data normalisation mattered. Now middleware, messaging, MapReduce and Twitter seem to have blown that idea away. Charles Betz may not agree but it seems to me data modelling is in retreat. Certainly it amazes me that a framework like ITIL can gain such ascendancy without even a token effort at a data model. (Personally i think that is just pandering to the vendors with existing products who would all end up with a non-complaint model). As a result I think some obvious entities are missed out, and one of those is the Interruption.

Shit happens, or how I learned to love the incident

skeptic — Mon, 08 Feb 2010 09:43:04 +0000

Complex systems are by definition broken. They will always break and sometimes they will break when everybody did what they are supposed to. Fixing the problem won't necessarily reduce the risk of another incident.

We should create the problem record right up front in an incident

skeptic — Mon, 28 Dec 2009 08:55:02 +0000

A BOKKED post three months ago drew a lot of attention. It was about the disconnect between Incident and Problem Management in ITIL V3 Service Operation. [See also the ITIL Wizard stirring the pot about Major Incidents] I've just discovered a response to that post which has popped my brain with its simplicity and clarity

What ITIL V3 says about the distinction between a Call and an Incident

skeptic — Thu, 22 Oct 2009 09:00:52 +0000

A hundred users call up and say they can't get emails. One incident or 100?

Fundamental and simple question. Go check ITIL for the answer. I'll wait.

Response Management

skeptic — Tue, 13 Oct 2009 22:43:15 +0000

The more I think about it the more convinced I become that the way ITIL and COBIT and ISO20000 structure incident and request fails the basic test of being customer-focused or business-aligned.

ITIL V3 Service Operation disconnect between Incident and Problem Management

skeptic — Mon, 07 Sep 2009 08:40:26 +0000

There seems to be a major disconnect between ITIL V3 Incident and Problem Management.

Say it ain't so!! ITIL V3 Incident and Problem processes do not determine the affected service

skeptic — Wed, 12 Aug 2009 03:15:17 +0000

This BOKKE (body of knowledge known error) has been posted for a day or so, hundreds of views. I was sure someone would say "no you idiot, service impact analysis is right here" but not one. It seems to be true.

ITIL Incident, is there a better word for it?

skeptic — Mon, 15 Jun 2009 23:47:58 +0000

Unemployed skeptics have too much time to ponder things. As I lay sprawled on the footpath outside the labour exchange in the sun, it occured to me that although we are stuck with the word "incident" for historical reasons, there must be a better word for it.

Are Incident and Complaint different things?

skeptic — Mon, 08 Jun 2009 03:17:23 +0000

Continuing our philosophising over Incidents, the service management group down at the employment centre were wondering about Complaints and Incidents.

Incidents overwhelm problems

skeptic — Sun, 01 Mar 2009 21:49:51 +0000

Problems suffer from the important/urgent dilemma. They are very important but struggle to get attention in the less mature shops over the incoming bombardment of incidents.

This is over simplistic but cute