Page 1 of 1

Requesting help on improving ITSM classification structure

Posted: Sun Mar 01, 2015 7:31 pm
by phit
Background: Our classification structure was all over the place because all the service desk managers had their hands in it and so there was no set rule for each level. We kept adding more classifications every time they requested and so getting meaningful reporting was a futile endeavor. Then we had a new director and manager come in and long story short, they selected me to create a new classification structure from scratch and I had full control, mostly with a little nudge here and there.

So who am I? I'm a sr. service desk technician/engineer that has been with the company for 6 years and this was where I started in IT. I have no experience with how other companies have their classifications set up, nor do I have any ITIL certifications or training. Not exactly sure why I was selected to take on his project but I'm glad they did because I feel like I am making a real difference.

What I've done: I've read through all the ITIL and ITSM classification content that I could find including posts from rjp on this forum to the IT Skeptic. I've also pulled quite a bit of my hair out because every time my model seemed to work, it will fall apart when I started to test it with some real world examples. With that in mind, the model that I will present to you was the best thing that I could come up with in 2 1/2 months time while still handling the day to day operations. Ah, yes. I have limitations placed on me as well.

Limitations: We have no service catalog (I am working on it now), no CMDB and an underutilized problem management module. Change management is great since we had consultants build it for us. However, all 3 (incident, problem and change) are essentially different islands that sometimes connect. I prefer the customer facing view for our technicians/engineers for ease of classification but our sr managers want to link incidents to what broke. They like to review the incident data after the fact for patterns so many times we wouldn't have a problem to link the incidents with, plus the service desk usually has no idea what's going on in the back end.

Model: We currently use a 4 tiered model that goes from Service > Category > SubCategory > CauseCode. Since we don't have a working service catalog, we had to make do with using our incident module to manage issues and requests. I added "SD" in front to group our classifications since other teams use ITSM as well. The cause code is a little redundant but it was the last thing I had time to look at. I wanted to decrease the options from 250+ (yes, you read that right) to less than 10 if possible. For SD User Training, I thought it might be useful to separate out items that we could create documentation or train the end users so they can service themselves since we have limited IT resources.

Classification structure in Excel from my dropbox
db {dot} tt/1nyJFxyO

Cheat Sheet in PDF we send to our technicians from my dropbox
db {dot} tt/tk0ktZUe

The model is more of a hybrid where it is customer facing or requires an IT perspective when selecting classifications. It wasn't my intention since does cause confusion on how incidents should be classified but it was the best that I could come up with at that time.

I've stretched the definition of Moves/Adds/Changes in the SubCategory so it can be used for things like modify a setting, add software, uninstall a patch, loan a laptop, etc. I wanted to decrease the amount of subcategories so our technicians/engineers will know what to expect regardless which classification they go through.

Things I need help on:
1. How would you improve on the current model?

2. What perspective should our technicians/engineers have when classifying incidents while still satisfying our sr. managers? Some of our tickets have vague info which is reflected in the examples below.

a. Example #1:
Symptom: Error message pops up when logging into internal web app with IE.
Resolution: Delete cache, close IE and re-open.
SD Application > Internal Web App
SD Desktop Software > Internet Browser

b. Example #2:
Symptom: Cisco hard phone displays error that it's reconfiguring constantly causing dropped calls, ISP and no other users are reporting issues. User is working from home and was issued a Cisco router with VPN set up.
Resolution: Reboot router but we're not exactly sure if this really resolved the issue
SD Hardware > Hard Phone
SD Hardware > Router
SD Network Connectivity > LAN

c. Example #3:
Symptom: User reported that second monitor is not working
Resolution: Remoted in and had to modify display settings to extend to second monitor
SD Hardware > Monitor
SD Desktop Software > Operating System

d. Example #4:
Symptom: Virus outbreak on workstation
Resolution: Run anti-virus
SD Desktop Software > Operating System
Maybe create a new service like SD Security > Virus? Would this mean we would have to create other things like malware, getting spoofed emails, etc.?

e. Example #5:
Symptom: From home, the user is unable to remote into the computer within the office
Resolution: Rebooted PC
SD Network Connectivity > Remote Access
SD Desktop Software > Operating System

f. Example #6:
Symptom: Laptop won't connect to the Citrix desktop (clicks on icon but nothing happens)
Resolution: Rebooted laptop
SD Application > Citrix
SD Desktop Software > Desktop Software* or even Operating System?

g. Example #7
Symptom: User unable to log into Windows workstation within a Windows domain
Resolution: We have 3 domains (west, central, east) and the fix was to have the user put "west\username" in the username field
Not really sure here. We used SD Desktop Software > Operating System

I was really excited with this model (5th version) since it seemed to make a lot of sense until we really started to use it. From seeing the feedback I've received from the service desk, they really like this model compared to the old one. Service requests seems to work really well with this model but it can get confusing for service issues.

I apologize if this falls under TL; DR (Too Long; Didn't Read) but I felt it has to be this way for you to see what we're going through. Thank you for your time.

Posted: Mon Mar 02, 2015 2:18 am

Thanks for the long email.

First, tell your management to get you trained in ITIL

You definitely will benefit (career wise)

Ticket classification is a two part process - the ticket classification and closure classification

I will use one example

Virus infection

The fault could be classified as a

System - Security Incident - if the system is infected
if the virus is application specific, then use

Application - Security

Once the ticket is closed, then one of the closure codes for security could be Virus Infection

Please reply. I check this daily.

And yes I am the grumpy one

Posted: Mon Mar 02, 2015 11:18 am
by phit
Thanks for letting me know. I wasn't aware that links are not allowed since that's an option available when posting. When you said links are not allowed, did you mean just that so I can just post the URL by itself? Showing the classification structure in a pivot table seems to be the easiest way to show everyone what it looked like.

My boss wants to send me to get training on ITIL (at least the foundation) but I have so much work to do. I know the work will never end so I'll need to make time somehow.

I think I see how you're going with the classification. Basically go from general in the first few tiers to specific in the last tier. By going your route, how many options do you expect to see? We had 250 options before implementation the new classifications and I prefer for our closure codes to be confusing again.

Posted: Mon Mar 02, 2015 3:50 pm
If you put a link, mangle it

www dot banana dot com as opposed to ....

The number of options is immaterial

The goal is to properly classify the tickets - when creating and when closing / resolving them

the easy part is the create classification

be generic but specific

application / name / fault or request (2 tickets classification)
system / soft or hardware / fault

then the closures should relate to the action taken to close the ticket (resolve the incident or complete the request) w/o reference to the type by default

Posted: Mon Mar 02, 2015 7:25 pm
by phit
Done. I created a mangled links pointing to my dropbox acct so classifications in Excel are accessible again.
UKVIKING wrote:be generic but specific

application / name / fault or request (2 tickets classification)
system / soft or hardware / fault
I think my classifications are already set up that way unless you meant that the subcategory should only have "fault or request" to generalize the options. Regardless, it seems like I should really focus on building on my cause codes.

You wouldn't by any chance know of an existing classification structure that fits your recommendations so that I may use as a reference?

Posted: Wed Mar 04, 2015 1:59 am
there is no 'official' closure code reference

Most tools have them

However use the following as the guide

The closure code and the Incident classification - both initial and final - should provide management information about where and what has been impacted. The only thing that is not covered is the customer (user) which should be the affected person in the ticket

Think about the output from the ticket system and how it would be presented to mgmt in reporting