Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: A81G
New Today: 42
New Yesterday: 49
Overall: 146071

People Online:
Visitors: 46
Members: 1
Total: 47 .

Languages
Select Interface Language:


Major ITIL Portals
For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone

Related Resources
Service related resources
Service Level Agreement
Outsourcing

Note: ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.


The Itil Community Forum: Forums

ITIL :: View topic - Methodologies for building supporting tables
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Methodologies for building supporting tables

 
Post new topic   Reply to topic    ITIL Forum Index -> Problem Management
View previous topic :: View next topic  
Author Message
JimiJames
Newbie
Newbie


Joined: Aug 18, 2005
Posts: 1

PostPosted: Thu Aug 18, 2005 11:36 pm    Post subject: Methodologies for building supporting tables Reply with quote

My organisation is suffering from a fairly messy category tree / problem type table, and root cause table. The issue is that the definitions of what these terms meant were not always fully understood and the process for changing these tables has holes in it that an elephant could stumble through! Are there any methodologies out there for developing sound, relevant, robust category trees (problem types) and for defining root causes? Also, what is the official definitions of root cause and problem type?

P.S. My apologies if part of this post is a little off-topic.

Thanks
James
Back to top
View user's profile
eisbergsk
Senior Itiler


Joined: Nov 01, 2004
Posts: 81
Location: Sask, Canada

PostPosted: Fri Sep 23, 2005 7:20 am    Post subject: categories & lists, oh my Reply with quote

I'm not really sure what a category tree is used for.... can you explain a little more?
Anyway, I've found that focussing on the 'root cause' can sometimes derail the problem process.
I deal with high severity incidents, usually after the incident is resolved (ie. client is back in service) Sometimes the root cause of the failure is not known. Sometimes it is known, but there is no action that can be taken against that particular CI. Since my objective is to identify changes that can be made to our infrastructure that will prevent or eliminate incident reoccurrence, I use problem categories that are very simple - (Application, Network, Server, eXternal, Procedure, Hardware) & name my problems by the CI of the Known error, like A-LotusNotes-101. So the focus is on the fix, not the failure.
Does this help?
Back to top
View user's profile Send e-mail
rjp
Senior Itiler


Joined: Mar 12, 2005
Posts: 255
Location: Melbourne, Australia

PostPosted: Fri Sep 23, 2005 12:26 pm    Post subject: Reply with quote

Now I know this will sound a bit pedantic, (and personally I find pedantry annoying), but talking about the root causes of problems introduces two distinct things where the ITIL process recognises two ways of looking at the same thing. And it will tangle up the classification task - so bear with me.

In ITIL a problem is a cause: The root cause of an incident. ITIL doesn't talk about the root causes of problems. The problem management process finds and eliminates the 'causes' of incidents (or potential incidents when the process in is proactive mode.)

Problems are, by definition, the unknown underlying cause of one or more actual or potential incidents.

Problems (sort of) become known errors when the cause is discovered. I say 'sort of' because the problem remains 'alive' until the error is eliminated, and the known-error is usually written up in a different record.

Your problem record and known error record are describing two aspects of the same thing. The known error is not the cause of the problem. The problem and the known-error are two ways of representing the cause of incidents.

So, onwards and upwards, to the question of classifying 'problems'.

ITIL offers a sample schema, and the thing to note about that schema is its not very good (gasp!Wink).

It isn't very good because there are ambiguities. (The terminal illness of classification schemas)

For example, some people will (rationally) see Procedure Failure -> Change Management as a specific instance of Non CI causes -> Human Error. And why on earth is Change Management under the Procedure Failure node and Problem Management under the Non CI causes node?

To get a good classification schema up and running, you should be able to simply and clearly state what it has to do. Some possible objectives are:


  • Organise problems by the kind or error: Human error, physical failure of a CI, capacity failure (eg, packet crashes on a subnet), incorrect documentation, etc.
  • Identify which area is responsible for the problem - usually by technology areas or systems: Network, Desktop, SAP, Email, etc.
  • Identify the CI that failed: Rack, Switch, Monitor, etc.
  • Identify the service degraded or impacted by the problem


and so on.

Of course what will trip you up is trying to combine a number of these into a single schema, or picking one that doesn't capture all the problems that might occur. For example if you just stick to CIs, how are you going to classify human error problems, without punching some of those holes you talked about.

But more importantly all these approaches overlook one thing: Classification answers the 'what kind' question. But it is kind of central to the nature of problems that what makes a problem a problem is precisely the fact that you don't know what it is. If you did it would be a known error!!!

And as the problem management process proceeds, it is highly likely that a number of things initially presumed about a problem will change. For example you may create a problem based on Incidents X, Q, and P, and after some investigation discover that while X and P have the same underlying cause Q is something different. What you thought was a component failure turns out to be an incompatibility introduced by a change. What you think is a capacity issue ends up being traceable not to insufficient capacity, but to users doing unqualified searches on a table somewhere with five squillion records in it.

So my advice is don't use the classification for anything that other fields, and relationships will do: matching problems to CIs for examples, or to incidents.

And keep the in initial primary classification very simple, short and focused: Say a generic 'type'(suspected), or perhaps just enough to indicate the main area of responsibility for find the error.

Allow other more detailed fields as required by your circumstances that will classify the problem once the error is found - but keep the classification of the error type to the known error record.

And be very careful about deploying classification 'trees': Problems are complex things by nature, and the nested-concept approach is going to be extremely awkward to implement. Use multiple fields by ball means, but for problem classification it is better to allow and combinations that independent fields provide than restricting classification to the exclusive or alternatives imposed by hierarchical trees.

NB: If you are using a specific tool to manage your processes, it will impose a certain model on you which make make some this moot - but I would still recommend keeping problem classification very simple, and try to identify what all the other fields and relationships are doing, and not duplicating that in the classification schema.
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Problem Management All times are GMT + 10 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003 http://www.nukecops.com

Forums ©

 

Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.