Workitem Tagging Instead of Expanise Classification List

Brad_McKenna

Hello All,

We have an expansive Classification list for our work items that is up to 3 levels deep, covering 300+ unique classifications. As you could imagine, this does not work for us as we often have to use reporting that searches titles and descriptions for descriptors. Due to this, we are nearly about to use a solution recommended to use by a PFE that we had onsite previously.

I am looking to the community to see how you all tackle the solution of having core Classifications of no more than 10-15, while providing a means to provide an additional layer of specifics relating to the work item.

Our plan has been to reduce the classifications to the core ~10 classifications, then use/misuse Business Services to essentially provide the ability to tag additional descriptors to tickets to provide the additional value in reporting. This involved bloating Business Services with a Display Name as our descriptor, then exposing a special object picker for our users to add these 'tags' to tickets.

Any thoughts that you have are greatly appreciated.

Geoff_Ross

Brad,

One methodology that has worked for me in the past to to use Classification to mean only the 'type of issue' not what systems etc have been affected.

EG, you might have classifications of Hardware Fault, Access Issue, Software Bug, User Error (Insert comedy acronym here) . This ends up being a short list.

Then you can use affected items to track what the issue was with. If it is a service, link to a business service, if its a certain piece of hardware / software, link to that.

This gives you a multi-dimensional approach with shorter lists but still many unique combinations.

So,
'Can't into my PC' becomes Access Issue affecting PC1234
'Print server crashes' becomes Hardware Fault affecting Print Services

Finally, a very nice way to use this is to have the same Classification list as your Resolution Category list (as well as the default ones). This allows you to report against, not only what the initial analyst (or end user) thought the problem was but also, what the problem turned out to actually be.

Back to the example of 'Can't log into my PC'. After some investigation and possibly escalation, the issue could have turned out to be a Hardware Fault with the PC, such as NIC failure preventing logon. The classification could remain a Access as that was the initial symptom, but the resolution would be Hardware Fault. This provides some very interesting data for example, how many 'Software Bugs' turn out to be 'User Error'.

Anyway, this post is getting quite long. As i mentioned, this is one method, that might work, it doesn't cover everyone's situation.

Geoff

Brian_Wiest

This was a fun challenge from our management as well. Basically needing to provide the end result of metrics for software, internal applications, and services. Management was always questioning why 70% of our support calls were software issues. They wanted to know more of the break down.
How we are accomplishing this. 
We pretty much stuck with the out of the box classifications and added some sub classifications under each group. See attachment. 
With this we classify the incident type for breaking down our call volume.
Then we train the analysts to use configuration items for reporting on specific business services. This also gives management a break down when attempting to know the volume on specific software, services, etc.
Then we direct as much as possible to the service catalog where depending on the use case we have simple list questions in the RO to gather metrics that we map to custom generic fields we added to the incident form. 
(We have 10 generic extension fields on incidents)
Example use case Hardware service 

So now I can run a report for a specific hardware model and get a pie chart of the which hardware failures
Since the ext fields are mapped from the simple list drop downs of the RO we control free form entries keeping our reporting clean

We do the same with software and other more know business services.
Then we extended the resolved by classification a little bit to report on the "other" end of the incidents. 
HTH

Brad_McKenna

Thank you @Brian_Wiest and @Geoff_Ross I appreciate the feedback from both of you. 

Both helping to think of things a bit differently on how we should proceed. Thank you also for providing the excel doc showing examples of how you tackle this issue Brian.  Extremely helpful!

Great idea Geoff with using classifications and resolution categories. Resolution categories is one of those items for us that were left default,  and have resulted in little value and confusion.  Great way to make those more meaningful.