Methodologies for building supporting tables

[JimiJames]

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

[eisbergsk]

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?

[rjp]

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!).

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.