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: CCarner
New Today: 33
New Yesterday: 89
Overall: 139451

People Online:
Visitors: 56
Members: 1
Total: 57 .

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 - Incident Categories
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Incident Categories

 
Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion
View previous topic :: View next topic  
Author Message
dsquared
Guest





PostPosted: Wed Jul 06, 2005 1:57 pm    Post subject: Incident Categories Reply with quote

Hi there,

I've done some searching online and am struggling to find anywhere that someone has put together some sort of rough template of a solid ITIL aligned incident classification structure. I fully realise it's horses for courses per organisation in this regard but at a very simple high level there must be some way to make recommendations without going into detail.

I need this to be able to make recommendations to the central IT area based on planned changes to our incident management software tool.

Can anyone point me in the direction of such information or have that information themself?

thank you
Daniel
Back to top
Gav
Itiler


Joined: Nov 16, 2004
Posts: 24
Location: Australia

PostPosted: Tue Jul 26, 2005 3:39 pm    Post subject: Reply with quote

Top Level:

Hardware
Software
Changes
Service Requests
Other


Sub-Levels are then as per your reporting requirements. Percievably there is no Incident that would fall outside any of these categories, however you always include 'other' as a category to capture Incident types you may not have thought of.

Trend analysis of the 'other' queue will either provide you an indication of what other category you need, or what further training your staff need :p
Back to top
View user's profile
rjp
Senior Itiler


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

PostPosted: Tue Jul 26, 2005 5:52 pm    Post subject: Reply with quote

This one comes up so frequently that the first thing I recommend you do is search this site; there are quite a few discussion already here about this very question (and I have contributed to a few myself Wink )

Secondly if you are looking for quick of-the-shelf templates or examples try the BECTA FITS site - (British Communications Educational Communications and Technology Agency / Framework for ICT Technical Support.

This actually a support site for British Secondary Schools, but they developed the FITS in conjunction with the OGC (ITILs owners) and, unusually, have a large number of examples and templates in the public domain. If they don't quite suit they are usually well done and a good place to start.

And to reply more directly....

Incident classification frequently goes astray because people try to shoe-horn too much into there 'classification' tree. Usually you will have a group (1 to 3) of fields on your Incident Records that are related in a tree, and are the designated Incident Classification Fields.

You do, however, have a whole record - and 'classification' - establishing 'what' type of incident a record represents - will (and should) involve more than your 'classification' fields.

Some things to consider:

Are you classifying your incidents or your infrastructure?
You need to be able to relate an incident to failed CIs (configuration items), primarily because technical expertise required for resolving many incidents tends to be distributed according to technological expertise.
But is there a better way available to you of capturing this information than your classification tree - if so use it.

Are you attempting to classify Incidents by their Symptoms?
Be aware that symptoms without the associated CI are less meaningful, and listing symptoms tends to mean the classification tree ends up with symptoms + infrastructure in it, which is most situation will be too complex. Symptoms should be recorded but remember they will proliferate constantly, and for many incidents you will not get a consistent usage of your symptom-terms because there is often more than one symptom to choose from. It will be very hard to get a (relatively) stable classification tree - which may make baselines and trend analysis quite difficult.

Are you classifying incidents or calls?
What is the initial record really - and how do your tools or processes use it? So if you actually have an 'Incident Reporting' interface / console, is it the place to be entering requests for changes: RFCs and Incident Reports have a different structure and you will want your consoles/processes to reflect the differences.
Of course if you are really classifying calls - which will then 'branch' into different types of requests and reports then classify your call records accordingly and look for a means to classify incidents after that primary distinction has been made.

Have you kept it simple?
Do you have one classification rule per level (for a multi-level classification) scheme, or will users encounter different classification rules depending on which branch they take? Where you implement a tree of classifications, the rules should be consistent, and the tree neither too wide, nor too deep - if you want the Service Desk to perform Incident logging efficiently.

Do you have defined Services and/or associated SLAs?
If so think about whether these can help sort out Incident Classification - if not in the designated fields, then definitely elsewhere on the record, so the designated fields can carry less information, but still work effectively.
SLA/Service relationships may help with escalation paths to n-level support for incidents not resolvable at the Service Desk.

Are you utilizing your Service Desk software (if you have some) effectively?
Most of the better tools out there can do assignment, escalation timers, reporting, ect. of more than just the designated 'classification' fields. So consider whether you are trying to build the triggers and parameters for too many processes off one small set of fields, when it would be better for base the process logic on a number of fields on the Incident Report Record.

How far into ITIL are you - and is their pressure to use Incident Classification to fill the gaps?
Most implementations of ITIL start with the Service Desk and Incident Management and work their way back into other processes.
There is nothing wrong with this strategy, but it helps to stay clear on what capabilities will not be achievable in the first rounds, and make sure others are clear also.
So as I intimated above, Incident Management is not Configuration Management - but if you don't have your CIs recorded and tracked, there will be pressure to meet this gap inside your Incident Management processes (and record structures) because ITIL based Incident Management is intended to be used with an adequate CMDB in place.
Likewise Change Management - if it's not there you may be under pressure to have RFC classifications in your Incident Report classification schema.
Problem Management has a Known Errors Database - which has a knowledge management function in that it provides support for Incident matching at the Desk. But both the KEDB and knowledge management in general are serious areas of functionality that need specific attention. Until they are in place there will be pressure to have an Incident Classification schema that can fill in these gaps.
To be practical you really have to identify the gaps and be very clear headed about which ones you will give some currency to, (and how much).
You might like to produce a mini-mission 'statement' for you Incident Classification schema: EG:
Quote:
'The schema will support the quick and accurate identification of second level support staff/groups with the technical expertise/responsibility to resolve the incident.'
Then as capability gaps present themselves you can weigh up whether attempting to address them will degrade that core requirement or not.
You may still end up with a two headed beast, but that will be easier than wrestling with a six or seven headed one.
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
blamblam
Itiler


Joined: Jan 16, 2005
Posts: 37
Location: New Zealand

PostPosted: Fri Jul 29, 2005 11:25 am    Post subject: Reply with quote

Analyse what you want to get out of it. What are your KPIs and SLAs? How you need to report will often dictate how you need to structure your classification tree.

But keep it simple to start with. There is nothing wrong with starting with a few high-level categories. If you find a category accounting for 30% of all you calls, for example, then consider how you can sub-categorise it. Work in that basis and you will find that it naturally evolves into what you need.

There is no point in locking into a classifaction tree that just isn't reporting what the business needs to know...
Back to top
View user's profile Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion 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.