Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Current »

This past summer, Computing and Network Services in conjunction with the new Enterprise Technology Center and CLA Computer Science major Stephan Wozniak started the process of replacing the system we use to track trouble tickets and service requests at the CNS Helpdesk and other areas of University Technology with a new system we call MI6.

The MI6 system is currently in use at the CNS Helpdesk and we are in the process of expanding its use throughout University Technology to track projects and other service requests.

MI6 has already had a positive impact on the CNS Helpdesk and we are confident that the system's simplified workflows, tailored specially to Drew's needs, will help to reduce errors and improve customer service throughout University Technology. You can learn more about the MI6 system and its public face, the new Technology Support Portal, in our online guide.

A successful student partnership

The MI6 project continues a long tradition in University Technology of engaging Drew students in the development of important IT projects – both to the benefit of the University and to the students in providing the opportunity to learn through experience with real enterprise technology. CLA senior Computer Science major and Student Systems Administrator Stephan Wozniak is the lead developer for the MI6 system. In addition to developing the Technology Support Portal self-service site for MI6 and the Helpdesk's paperless signature system, Steve coordinated business process evaluation and design activities at the Helpdesk, ran development meetings, and trained employees on the new system.

Why MI6?

We have been using a commercial Helpdesk package called Supportworks since 2003. Supportworks was a capable product and has served us well, but since the beginning there were certain problems. Using the Supportworks system it was too easy for a mistake to be made and for a ticket to "fall through the cracks" because it was put somewhere in the system where it wouldn't be noticed. Because the workflow - the sequence of steps that an issue moves through from getting opened to being resolved - in Supportworks was fixed and generic, the system did not allow us to track specifically where something was at the Helpdesk. The system was too "open-ended". Most commonly, the issues with Supportworks deficiencies manifested themselves in the repair process for student laptops dropped off at the Helpdesk.

Supportworks, like most Helpdesk packages, is designed around a typical corporate Helpdesk. A typical corporate IT support department will employ a small number of full-time technicians who are assigned specific cases to work on through inception to completion. Systems like Supportworks are designed to work well with this model. Each technician can see the issues that the Helpdesk manager has assigned to them and post updates as they work on the ticket. Tickets can be assigned to other technicians as needed and the question of "where is this ticket in the Helpdesk?" is a simple matter of knowing which full-time technician it is assigned to.

The CNS Helpdesk doesn't work that way. Being primarily student staffed and with the students working relatively short desk shifts (at most a few hours at a time), a single individual cannot "own" a ticket from the time a computer is dropped off at the Helpdesk to the time it is returned to the customer. During the lifetime of a ticket, it may be worked on in stages by a half dozen student employees. "Where is this ticket in the Helpdesk?" is not a question that can be simply answered based upon who currently "owns" it; rather, we need to know what step it is in the workflow. Is it waiting for additional software diagnostics? Hardware repair? Are we waiting for parts? Is it waiting for re-imaging? Are we waiting for something from the customer? Where the ticket is in the workflow will determine where the computer is physically in the Helpdesk, what the next step is, and where, when, and what priority it will be worked on.

In an environment like the CNS Helpdesk where an issue can change hands several times, and there is a large volume of issues, it is also critical that the software help the employees to avoid making mistakes. For instance, the workflow system should alert or prevent an employee from sending a customer computer to be reimaged if the customer has not consented to the reimaging.

Finally, the system needs to be adapted to handle the typical workload we see at Drew. At the CNS Helpdesk certain services, like re-imaging student computers, dominate the workload. Give the volume of re-imaging requests we see, we need a system that allows us to design a custom workflow just for this task and other common tasks, turning the process into an efficient "assembly line" style operation.

The critical realization that led us to the design of MI6 is that the Drew CNS Helpdesk is very much unlike a traditional corporate Helpdesk. Especially with regard to the student computing program, it is more akin to a retail operation. Upon understanding this, we were able to expand the scope of what we were looking for beyond the traditional realm of Helpdesk tools.

MI6 is not typical Helpdesk software

The MI6 system is not built on top of a traditional commercial Helpdesk package. In building MI6 we started with the very-powerful and cost effective JIRA issue tracker from Atlassian. JIRA is a project management tool and bug tracker designed for software development teams. Unlike many bug trackers (and Helpdesk packages for that matter) JIRA is extremely flexible, allowing us to customize - without programming - the issue types, fields, and even the workflows in the system. Using this capability, we were able to turn JIRA from a system designed to track bugs and enhancement requests for a software company into a system for tracking student computer repairs and house calls for the CNS Helpdesk.

Simply adopting JIRA isn't the end of the story though. Because JIRA was designed as a project management tool, it did lack certain features common to most Helpdesk systems, such as a robust customer self-service site. In order to address this need, Steve designed a custom web application – the Technology Support Portal – which provides self-service for JIRA as well as other internal support tools. Steve was also able to make the Helpdesk repair operation almost completely paperless. Combining low-cost consumer touch screen monitors with a custom web application within the Technology Support Portal, customers can now sign their computer intake and pickup receipts electronically.

We believe that the MI6 system represents an ideal combination of commercial software and home-grown tools. By leveraging the power of JIRA, we were able to minimize the complexity of the custom code we did have to develop for the self-service site. Since all of the workflows, fields, issue types, and other details are stored as configuration in JIRA rather than in code, we have a system that's easy to customize as our business needs change in the future.

By combing a powerful commercial product with "light weight" integration techniques and custom code, we were able to develop and deploy the MI6 system rapidly, over the course of a single summer. We were able to spend most of the time focusing on the business processes in the Helpdesk, rather than the programming. At weekly meetings, Steve led the team through the process of evaluating and designing the Helpdesk workflows. We were able to consider carefully the types of issues that come into the Helpdesk and think about the optimal progression of these issues through the Helpdesk and the other areas of User Services in CNS. The end result is a system which is a custom-fit for Drew's computing program, but with a minimum maintenance burden of custom software, and which can be easily altered in the future.

Moving forward

The CNS Helpdesk is the first area of University Technology using the MI6 system, but it is far from the last. We have just started designing the workflows for ITS and the new ETC department and hope to have all of University Technology migrated off of Supportworks by the end of the Fall semester.

Once University Technology is fully implemented on the system, the next step may be to take MI6 "on the road" to other areas of the University that have a need to track customer service requests and projects.

Please stay turned for more updates about the MI6 project in the future and let us know what we can do to make the system work for you.

  • No labels