"Root Cause" and "Closure Codes"

General discussion on all aspects of the IT Infrastructure Library (ITIL)
Post Reply
User avatar
bigolbear1970
Newbie
Newbie
Posts: 1
Joined: Thu Sep 24, 2009 8:00 pm

Thu Oct 01, 2009 9:14 am

Heres an interesting one, i'd be interested in your opinions

As most people do, we have "root codes" and "Closure Codes" in our fault logging system

As an example, I've just been looking at the an incident where somebody said "the registration number of vehicle "A" is incorrect on the Fleet Management database. Please correct it"

My colleague has closed the log off with root cause code "Data" and closure code "Modify"...in my opinion, when we come to run stats in 12 months time and we get 2000 "data/modifys" it will be totally meaningless.

My view was that, yes its data, but we should use something a bit more specfic than Modify....I suggested "Setup" so that when we look back at this one we can instantly see that the root of this incident was a data setup issue - data modify is meaningless

My colleagues are arguing with me about this though as they say closure code "Modify" is correct because thats what they did to close it

I'm sure you guys must have come across this type of thing before - do you have any opinions?

Kieran


User avatar
Diarmid
ITIL Expert
ITIL Expert
Posts: 1894
Joined: Mon Mar 03, 2008 7:00 pm
Location: Helensburgh

Thu Oct 01, 2009 9:42 am

Why do you think data is the root cause?

Surely in this case the root cause has got to be the circumstance that allowed the data to be incorrect?

Hopefully the resolution involved verify as well as modify for that datum, but why do you want the closure code to be part of the information about root cause?

How do you know it was a data setup issue and not a corruption or a 'modify' action that caused it to be wrong?

I think this "root code" sounds more like symptom than cause.

A root cause of "data" would only be useful if you had no control over the data, but you do if you can modify it.
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
User avatar
tolman101
Senior Itiler
Senior Itiler
Posts: 44
Joined: Sun Sep 25, 2005 8:00 pm
Location: Sweden

Mon Jan 25, 2010 5:38 am

I agree.

The root cause needs to be the cause of the incorrect data.

Closure code could be used to describe what was done to remedy the issue but doesn't give you much information to make improvements other than understanding how often resolvers are performing certain remedial tasks.

You should also combine this information with a configuration item to give maximum value, but you probably already do this in some form or another, perhaps with an issue area if not with a CMDB.
Post Reply