RT workflow analysis

RT Users
1

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