Classifying Incidents, Problems and Changes

One of the tasks that many Serio Administrators can find a little daunting is preparing categorisations for Incidents, Problems and Changes. What I’m referring to us populating the data fields that help us to manage tickets.

I’m going to list some tips to help those setting about this for the first time, or those reviewing their categories.

  • Remember that someone will have to use this information during Issue logging, so make the number of Problem Area Categories that you have available during Issue logging less than 12 or so if you can. Then try to keep the number of Problem Areas within each Category less than 12 as well. Doing this gives a reasonable list for helpdesk and service desk staff to work with.

  • It’s OK (and indeed desirable) to have a small number of Issue Types. Remember these just record the type of ticket – for Incidents, you might have Fault, Query, Work Request and so on.

  • Try to create categories and data that is unambiguous. In an ideal situation, there will be an obvious best choice for most Issues being logged. Overlap in Problem Areas can cause the same type of fault to be classified in different ways.

  • The data you are creating will be used in Incident, Problem and Change reporting.

  • If you are starting from scratch, remember to examine any legacy data you have.

  • Also if you are starting from scratch, don’t be afraid to prepare your data away from the tool itself. Sometimes it’s useful simply to write your data down in a familiar tool such as a spreadsheet where your focus will be on the data rather than the software ITSM tool. However, if you do this make sure you are familiar with the structure of the data the tool requires.

  • It’s a process. Therefore after setting-up your data see how it’s working by examining tickets you’ve logged. Don’t be afraid to remove data that is not being used.

  • Remember that Serio allows you to have different classification data for Incidents, Problems and Changes.

  • Finally, have an ‘other/unclassified’ category. This will help for odd types of infrequently occurring Incidents – but make sure that this is not overused.