[rt-users] RT workflow analysis [long]

[Tim Wilson]

Hi everyone,

We have been using RT for a little over a year now (recently upgraded  
to 3.4.1 on Debian with PostgreSQL and mod_perl) and it has become an  
integral part of the tech support infrastructure in our entire school  
district. As we have learned more about what RT can do we've found  
new applications for it. There are two applications that are of  
particular interest, and I would appreciate it if any of the RT gurus  
on this list had time to look over the following and comment. While  
the specifics may be unique to our organization, I'm sure that the  
general principles would be of interest to many RT users and admins.  
(I would be happy to summarize whatever comments are made in the  
wiki.) So if you'll pardon the lengthy post, here we go:

I. Reflecting organizational workflow in RT queues

Our tech support organization is multi-tiered. We have at least one  
tech support person in each of our 10 schools (9,000 students total  
and almost 3,000 computers), a district IT office, and a district  
repair facility. A typical tech support issue involving our repair  
facility might look like this:

1. Teacher identifies tech problem (creates initial RT ticket in  
building queue)
2. Building-level tech support evaluates (comments or replies via RT)
3. Building tech decides it's a district issue (moves ticket to  
district IT office queue)
4. District IT determines that the computer needs repair (moves  
ticket to repair queue)
5. Repair is made (queue-specific custom fields are filled in with  
information about the type of repair that was made)
6. Repair tech moves ticket back to building queue after completion  
of repair
7. Building tech closes ticket

Questions:

* Is it wise to mimic your organizational workflow in the  
configuration of RT queues? We haven't had any apparent problem with  
this, but maybe there's a better way.

* Most tech support issues never involve a visit to the repair  
facility. I don't want to clutter all of the building-level queues  
with custom fields that are related to a repair, but I also want the  
building techs to see (but not change) the repair-related custom  
fields once the equipment is returned to them and the ticket has been  
moved back into their queue. As far as I can tell, if a custom field  
doesn't exist in a particular queue, then custom fields that were  
filled in while the ticket was in a different queue are never  
visible. It seems like there should be a better way. Suggestions?

II. Implementing other business processes

In our school district all technology purchasing is supposed to be  
made centrally through our IT office. Teachers and administrators  
submit purchase requests throughout the year and often forget to  
consult with the tech support people to make sure that they are  
ordering the right version of software for the right platform with  
the right number of licenses, etc. We think that we can use RT as a  
part of the ordering process and prevent this problem. Our proposed  
solution looks like this:

1. Requester submits their technology order to RT via email through a  
Web form. Key elements of the order (date needed, final destination,  
etc.) are parsed by RT and included as custom fields.
2. New ticket is created in "order" queue
3. Building-level tech support people are added as watchers on the  
ticket based on the final destination of the equipment (information  
acquired via the Web form)
4. Ticket owner (our purchaser) and building techs corresponds with  
requester about details of the order. This should ensure that the  
correct equipment is ordered. No surprises!
5. (Optional) Purchase is approved via RT's approval mechanism
6. Order is placed and item is received
7. Purchasing agent closes initial ticket which triggers the creation  
of a new ticket in the building queue (with original ticket as  
parent). This allows the building tech to use RT as they deploy the  
technology and to refer to the original ticket for clarification if  
needed.
8. Building tech closes the ticket on completion of the deployment.

Questions:

* Does this sound like a reasonable approach? Would anyone recommend  
modifications?

* What other business processes are good candidates for the RT  
treatment? (A list of these would be a nice addition to the wiki, I  
think.)

Of course, none of this cool stuff would be possible without RT's  
excellent design. Hats off to Jesse, the other members of the Best  
Practical crew, and all of the rest of the RT developers.

-Tim

-- 
Timothy Wilson
Technology Integration Specialist
Hopkins ISD #270, Hopkins, MN, USA
ph: 952.988.4103  fax: 952.988.4311  blog: http://technosavvy.org