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
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.
Posted: Wed Jun 04, 2008 5:00 pm Post subject: Request/Incident Categories
Hello all,
I know that this has been more like an un-ending debate and it can be classified more into 'black arts' and that incident caregories actually depend on the business needs and the environment, but i was wondering that if someone is ready to share their active categories. I'm not really looking for a 'how-to', but i'm looking for the real thing, the actualy categories that you are using. I think having more practical examples will help everyone to enhance their categories more than having these endless debates.
Joined: Mar 04, 2008 Posts: 1883 Location: Newcastle-under-Lyme
Posted: Wed Jun 04, 2008 6:17 pm Post subject:
Fares
I'm afraid I'm going to have to disagree with you. this is not an unending debate and it is definitely not a black art. and people have already shared their actual categories (see the threads "Incident fix/closure codes" and "Cause and Resolution Codes" for recent examples).
It is not a never ending debate because once you have got your categories you get on with using them and stop debating it. Then you review how effective they have been and make changes based on experience and analysis, not debate.
It is not a black art because, to quote your own words "incident categories actually depend on the business needs and the environment"; again this means applying analysis and experience.
Now, when you look at someone's example:
- how do you know it is effective for them?
- what assumptions have they made?
- does effectiveness mean, for them, reporting on incidents or does it include problem management? continual improvement?
- what skill sets do they apply to their service incident function?
- how do you know they have requirements compatible with your own
- can you mix and match?
- is their business more complex / less complex than yours
- is their service management more mature than yours? less mature?
- will their example work for your staff? for your business?
You won't be able to answer those questions from the necessarily superficial information you get in a forum response.
The best you can hope for is that the examples do not just reinforce your current perceptions.
UKviking's answer is a good case. Ask yourself, what kind of analysis can be done on the basis of this configuration. Is that what you want to be informed about? or do you need to be able to answer different questions?
Sadly he is probably correct that the tools constrain what you can do, but in many cases that can be overcome and in some cases the tool ought to be destroyed. _________________ "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
thank you for you reply. Well, i was thinking of something simple and more or less similar to what you have, but i have been facing lots of issues in convincing my management with this apprach. they are looking for something more detailed, as in, listing every single application we have and it's categoris, including common applications like Word, Excel, .. etc.
for this the list can go to infinity and it will only complicate things, so i was looking for something to help with that and to guide me a bit on how we can have categories for these applications without complicating things.
Joined: Mar 04, 2008 Posts: 1883 Location: Newcastle-under-Lyme
Posted: Wed Jun 04, 2008 6:37 pm Post subject:
Fares,
you don't seem to be saying that you know what you want the categories for. The debate you describe seems to be - we must have categories, shall we make them simple or complex.
It is your need that should define how simple or complex they need to be.
My advice is blank out all the possible lists and sit down and decide what you want to achieve. _________________ "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
Joined: Sep 16, 2006 Posts: 3110 Location: London, UK
Posted: Wed Jun 04, 2008 9:34 pm Post subject:
Fares,
Like diarmid has said.... .. what information is wanted
from my world
1 - company A had 3 levels of categorization - outage / disruption / impact for web site/network/application/datacenter/ miscellaneous. That with the name of the incident group that is solving the issue made things easy to identify
2 - company b - had 40 classification - with one of them being Application - and that had 200 sub classification - and the support groups were not easily identified as to their function
Guess which tool was easier to use both from an operational POV and a amangerial reporting POV
You need to ask your mgmt .
WTF do you want from the tool in the course of managerial information
Once you have that, then you will have an idea if what to do for categorization w/in the tool
that and what services are provided and supported by the service desk/help desk/tool _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Posted: Fri Jun 13, 2008 2:04 am Post subject: Request/Incident Categories
Greetings, All:
I'm working everyday with incident reports generated from multiple systems and have observed one consistent weaknesses in most incident systems. ( My perspective is that of trying to drive useful management reporting and metrics off the incident systems. )
The issue is that too many systems allow incidents to be closed out without a clear and consistent root cause notation. The big enemies are failure to require a root cause description during ticket close out, and free form text.
For example, a root cause description of "hardware problem" is of no value to management, other than to count incidents - which could be done with a simple spreadsheet. From a management reporting perspective, much more can be gained when the root causes can be sorted and reviewed. For example, consistent root cause identification will allow managers to identify frequently needed parts so that spares can be stocked on site and downtime reduced.
The solution is to insert (or activate) fields in the ticket close out phase which deal with the problem "hard drive" (nouns) and the resolution "replaced" (verbs). These fields must validate or be drop downs so that mutant spellings, slang, and typos cannot be inserted.
Free form text is great for descriptive and historical detail - however any free form fields must be supplemented with codes/drop-downs/etc to enable sorting, categorization, and management reporting.
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
Forum FAQ
Search
Usergroups
Profile
Log in to check your private messages
Log in
