7 Replies Latest reply: Oct 2, 2012 4:46 PM by gsdhatt RSS

Work Order Type/Subtype/Categories Best Practices

John Ferragamo

We have been using Track-It at my organization for almost a year now with great success. So much so, that we are expanding the initial Technician scope to include other groups not previously apart of the intial scope.  As a result, this has forced us to reevaluate how our Types, Subtypes and Categories are  organized and has started a number of debates.

 

When we first took on the project of using Track-It, the majority of time was spent defining our Types with the hope being that we would publish the Self-Service Portal to our End users.  These Types were created with them in mind so when going to the portal to submit a request, they made sense and flowed logically based on the most common issues reported.  In the end the portal was never published to End Users so the need for it to be organized in that manner didnt really matter.  My end goal eventually will be to publish the portal to the Users for obvious reasons.

 

My question to the members is; How have you organized your Types so that they make sense to your Technicians, as well as End users and so they provide the most granular level of detail so reports are actually useful, while still not making them so convoluted that they are cumbersome to navigate?

 

An example of our current structure looks like this;

 

Account

New

Reset

Unlock

Computer Problem

Disk Space

Computer Request

Video Card

Email

Can't Send/Receive

Distribution List

Add/Modify

Delete

New

Internet

External Website

Internal Website

Network/Connectivity

_Change Request

_Repair Request

Phone - Mobile

Phone - Office

Printing

Remote Access

Software Problem

Software Request

 

The other piece we are hoping to use more is the Change Management module which would mostly be driven by these Types/Subtypes/Categories so having these make sense and relate to a Change Request is also a factor.

  • 1. Work Order Type/Subtype/Categories Best Practices
    Cris Coffey

    I hate to say this, but "it depends". :-)  Your structure above looks very straightforward and easy to understand. Some customers also have a top level item called Project, witih various categories underneath it and they use it to classify special long term projects. The one thing you have that is a little different is a Computer Problem vs. a Computer Request. I would say most times I have seen Computer as one level, then Problem/Request as a subtype and then the categories under that. However, as I said before, it depends. If this is working well for you, stick with it. There is no right or wrong way, only what works for your environment and users.

  • 2. Work Order Type/Subtype/Categories Best Practices
    John Ferragamo

    Thanks Chris, I know it is a loaded question to ask but I figured I'd ask the forum to see what others are doing.

     

    I actually have a meeting with the Technician Leads this week to review the changes are are thinking of implementing so hopefully that will go over well.

     

    Rather than a seperate Project Type, we have a Project Priority and hope to use that to drive part of the Change Mgmt integration.

     

    Thanks for your feedback.

  • 3. Work Order Type/Subtype/Categories Best Practices
    Cris Coffey

    No problem. Hopefully some other users will weigh in as well. As the forum traffic picks up, the responses should pick up as well.

  • 4. Work Order Type/Subtype/Categories Best Practices
    Marty

    We used to get granular on type/sub-type/category but found the end user just has too much trouble getting it correct so the technician ends up changing it anyway.   We simply stripped down the type and sub-type to a bare minimum of what we felt we needed to report trends on.  Then we created an unnamed user for each of the TYPES which have an email address of a distribution group thatis used by the skill routing policy to notify the group. The technicians in the group will assign the ticket to themself and assign the category correctly.  Not perfect but works for us.

  • 5. Work Order Type/Subtype/Categories Best Practices
    Brad McClave

    What I would do in your situation since other groups will be included is to use Type to match the group, then Subtype/Catergories as the Type/Subtype for each group.

  • 6. Work Order Type/Subtype/Categories Best Practices
    cbrock84

    All of this is good advice. We went the same route as Marty... we initially had the categories setup broadly, with very specific subtypes. Some of them were kind of ambiguous or "bled into" other categories so we simplified things quite a bit to keep them as straighforward as possible for the end users. Like Cris said above, it really depends on how your IT department plans on using the Help Desk module... just for desktop support or for your entire IT dept (including programmers, etc.)

     

    Just as an example, here is ours in case you wanted to see how others structured their categories:

     

    Hardware

    -Equipment Move

    -Keyboard/Mouse

    -Laptop

    -Monitor

    -Other

    -Printer

    -Request

    -UPS

     

    Network

    -Connectivity

    -Other

    -VPN

    -Wireless

     

    Projects

    -Users listed here

     

    Reporting

    -Client

    ---New

    ---Changes

    -Internal

    ---New

    ---Changes

     

    Servers

    -Migrate

    -Other

    -Provision

    -VM

     

    Software

    -Crashes/Errors

    -Other

    -Requests

     

    Telephony

    -ACD Issue

    -Mobile

    -Other

    -Phone Issue

    -Request

    -Voicemail

     

    User Accounts

    -Name Change

    -New Employee

    -Other

    -Permissions Change

    -Remove Account

     

    Websites

     

    -External/Internet

    -FTP

    -Internal/Intranet

     

    I left out some of our business-specific things like database maintenance/changes and programming for our in-house software solutions since they're likely irrelevant to most others using TI.

  • 7. Re: Work Order Type/Subtype/Categories Best Practices
    gsdhatt

    John:  By now, you've likely already created (and subsequently modified!) your taxonomy...  Just curious what you ended up with...

     

    We've been using TrackIt for ten years now (since v6).  We initially had a Type taxonomy similar to yours (and others).  Since then, we've spun things around to consider requests from our users' perspectives, rather than ours.  As a result, we've ended up with a taxonomy that echoes the service catalog that we hope to publish to our users.  Our upper-level Types are  Account Management, Configuration, Consulting, Design, Development, Documentation, Education, Installation, Maintenance, Procurement, and Repair.

     

    We've attracted the attention of other workgroups in our organization with our ability to report KPIs in a timely fashion, and the results we've obtained with cutting service-delivery times.  As a result, we'll likely move Types to SubTypes, and create new Types of:  IT Request, Facilities Management Request, etc. (where the Types divide the workgroups who access TrackIt).

     

    There are some things that are typed in a less well-organized fashion than we'd like, so we'll likely end up with some others, as well (like, "Governance/Compliance" for our SOx- and PCI-related issues, etc.).

     

    I'm not sure how that compares to how others are configuring Type/SubType/Category, but like Chris pointed out, perhaps others will share as this forum picks up traffic...

     

    Cheers,

     

    GD