Managing categories between assignment groups

robert_price · ‎04-02-2015

We have a lot of groups in our IT department. Some of them have their own requirements for tickets, and some of them don't; some of our groups use the category/subcategory stack (using the dropdown category field), and some of them don't. However, all groups want to be able to transfer tickets between each other, and have those tickets retain the previous categories so they don't have to change said categories when they arrive (especially if they are going to be sent back afterwards).

In addition, our management wants to be able to make reports on ticket content based on the category field.

We've solved this issue with a complicated (and admittedly buggy) script, and a few extra category fields (specific to certain groups) when the group in question isn't going to be on the same reports as the others. However, I'm curious about how other companies handle this issue. Does anyone else have to worry about retaining categories between departments with category systems of their own? What's the bet way to handle this kind of thing?

de_dah · ‎04-06-2015

Our organization went through a few iterations, but in the end went with something fairly simple. There's a lot of data you can get out of a system, but the more complex your categorization is, the less likely staff are to properly categorize their tickets anyway. We decided to get into generalizations. Applications, Hardware, Security, Services, Network, Storage, Servers, etc. Under the first level, we've got some categorization that stays fairly generic, but in some cases, we get specific as well, depending on the needs of the IT groups and the mgmt. teams. We use UI sparingly and it only comes out to play with a few of our app support teams. Some of our categorization can be overlapped a bit, but when it comes down to reporting, we get some great data out of our structure. Our rule of thumb is that we can re-assign and re-categorize as often as needed, but the true categorization is what the ticket is closed with, as often you don't know what the real issue is until you've dug into it.

We also asked this question often - what kind of reporting do you want to get out of the system? Often, that drove the discussion of what was really needed for categories.

View solution in original post

de_dah · ‎04-06-2015

Our organization went through a few iterations, but in the end went with something fairly simple. There's a lot of data you can get out of a system, but the more complex your categorization is, the less likely staff are to properly categorize their tickets anyway. We decided to get into generalizations. Applications, Hardware, Security, Services, Network, Storage, Servers, etc. Under the first level, we've got some categorization that stays fairly generic, but in some cases, we get specific as well, depending on the needs of the IT groups and the mgmt. teams. We use UI sparingly and it only comes out to play with a few of our app support teams. Some of our categorization can be overlapped a bit, but when it comes down to reporting, we get some great data out of our structure. Our rule of thumb is that we can re-assign and re-categorize as often as needed, but the true categorization is what the ticket is closed with, as often you don't know what the real issue is until you've dug into it.

We also asked this question often - what kind of reporting do you want to get out of the system? Often, that drove the discussion of what was really needed for categories.