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?
Joined: Nov 16, 2004 Posts: 24 Location: Australia
Posted: Tue Jul 26, 2005 3:39 pm Post subject:
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
Joined: Mar 12, 2005 Posts: 255 Location: Melbourne, Australia
Posted: Tue Jul 26, 2005 5:52 pm Post subject:
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 )
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:
'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.
Joined: Jan 16, 2005 Posts: 37 Location: New Zealand
Posted: Fri Jul 29, 2005 11:25 am Post subject:
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...
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