Analyzing and Optimizing IMS Requests

The assignment is about analyzing the process description of a service desk at a university. The process involves taking phone calls and creating tickets based on the calls, with the outsourcer (Presidium) closing most tickets initially. If they cannot solve an issue, they escalate it to IRM. University staff then contact users for updates and can close tickets. There are 15,000 open requests, of which more than half are over a year old. The process lacks classification and tracking, with many requests going unclosed and unknown resolution.

BADM 6330 – Final Project: TX
University
Process Description
TX University is a four-year university with both graduate and undergraduate programs in 20 disciplines.
The school has about 40,000 students in total spread over six campuses. Ann E. is the newly appointed
manager of support responsible for the Computing Services Service Desk function, IRM (Incident
Resolution Management). There is at least one IRM employee at each site; the main campus has seven
permanent employees and many student workers. In addition, work is outsourced to Presidium for
about 75% of initial Tier 1 phone calls and web contacts.
There are three levels (Tier 1, Tier 2 and Tier 3) of tech support. Tier 1 is the lowest level of support and
accounts for about 90% of all contacts with Presidium accounting for all initial phone contacts (about
70% of total) and IRM managing all other forms of initial contact. Tier 2 is for Technical Support Staff
(university employees) and applies to all hardware issues and software supported by the university, e.g.,
Banner, the university web site, and some software used in classes. Tier 2 accounts for about 9% of all
contacts; Tier 3 accounts for about 1% of all contacts. Tier 3 support is provided by vendors of either
hardware or software.
Telephone and web forms are the two methods used to initiate contact for the service desk. Once
contact is made, phone, web form or email might be used for continuing contacts. Rarely is contact in
person so it is not discussed. All methods can result in telephone, email, web form contacts for updating
and/or resolving the issue if it is not done in the initial contact.
The general process is that a user initiates contact with a problem, request, or question. The caller is
validated as faculty, staff, or student and, if needed, updates the University Customer Database (UCDB)
with email and phone information. The contact is logged into Information Management System (IMS), a
home-grown incident tracking application to which both the university and the outsourcer have access.
A known errors database (KEDB) is checked to determine if there is a known problem with resolution
readily available. If an entry is in the KEDB, either a solution or workaround is passed to the user to try
to fix the problem. If possible, the request is serviced in the first phone call and the logged request is
closed by the individual logging the contact.
If the request is not serviced in the initial contact, Presidium is supposed to perform some
troubleshooting to see if they can fix all problems not in the KEDB; however, they often pass on
problems when there is no KEDB entry. If troubleshooting is performed, the actions tried should be
documented in the IMS software. Presidium transfers calls (via an automated call director (ACD) to
either Tier I or II in IRM; only Tier II IRM can escalate to Tier III, vendor support. Transfers from
Presidium usually go to Tier I IRM support which retries the KEDB and troubleshooting, documenting the
steps taken. If the individual cannot find a solution, the problem is transferred to Tier 2 support.
Transfers of responsibility through IMS are automatic. As a service contact is saved, the software checks
to see if transfer to another organization is checked. If so, the item is placed on a queue for automated
delivery to the next available person in that area (this areas to which electronic delivery is done include
IRM staff (Tier I internal) and Technical Services (Tier II). If Tier II escalates to a vendor, the individual
managing the contact also manages all interactions with the vendor(s). Any vendor interactions are

BADM 6330 – Final Project: TX
University
supposed to be documented in the IMS but there is no requirement or coercion available to ensure that
this is done.
All forms of interaction (phone, email, Internet, or none) can be used for contacts after the first,
depending on the nature of the problem (e.g., an item that is on FAQs on the web site is routed there via
the initial contact method or email. Interactions after the first are all supposed to be logged into the
IMS software but there is no mandatory entry nor is there automated escalation (e.g., to a high level of
support or manager based on time from request to expected resolution or type of request). As a result
some requests are lost and others are never closed.
IMS is a database for tracking and software for automated routing within the university. In addition, it is
the basis for the web application that provides status, resolution information, and so on to users via the
university web site.
There are 15,000 open requests of which more than half are more than one year old. There is no
classification of user, request, or other designation to facilitate resolution or tracking. Thus, when
forwarding is done, a request is generically sent to the next level. Items sent to vendors for resolution
are not tracked for timely resolution unless the outage affects many users. The original person logging a
request should be the person who monitors a request and closes it; however, the outsourcer does none
of that except for first calls resolved during the call. IRM or Tech Support are responsible for closing
requests that are passed to them but there is no clear policy for tracking responsibility. Similarly,
vendors do not close requests. Thus, many requests go unclosed with an unknown resolution.
About 1,000 requests are taken per day. Of these, 750 are completed in the initial phone call. Of the
remaining 250, 2 will result in vendor consultation and the remainder are managed (or missed) by IRM
(Tier I) and Tech Services (Tier II). About 50 requests/day have unknown resolution and are never
closed.
The service desk outsourcer (Presidium) only takes phone calls and creates tickets based on the phone
calls. In normal circumstances they will close the ticket on initial contact and solution is communicated
while on the phone and also via web form. If Presidium staff are unable to solve an issue they will
escalate the ticket to IRM and the user will be notified while on the phone as well as via the ticket. In
most cases the ticket will end up in the IRM service desk queue where university staff will contact the
user first via phone and if they are unable to get a hold of the person, a note will be sent via the ticket.
Then, depending on the issue, anyone within IRM can contact the user initially and for updates. Also,
anyone within IRM can close a ticket. For the most part, the tech who is working on the ticket will also
communicate with the user and close the ticket. Assume that by updating the IMS, the web site is also
updated. Many organizations use the logging DB as the method for also providing feedback to the users
so it cuts down on duplication of information.
Emails are not used as a means to request support. Email is used to communicate with the user while
working on the ticket (internal to IRM only). The web form is utilized both by Presidium and all
university employees to update customers.

BADM 6330 – Final Project: TX
University

BADM 6330 – Final Project: TX
University
Instructions
1. In an MS Word document using the template provided, list the following:
a. Role Identification: List the roles required to document the above process.
b. Value-add Analysis: Break down the above dialogue into steps. Columns explanation:
i. Role – what role from your list of roles is involved?
ii. Step – briefly describe the step.
iii. VA – categorize each step with value-add, non-value-add, non-value-add-
unnecessary. (VA, NVA, NVAU)
iv. If a step is NVAU please comment on how IDP should address the issue in a
better, optimized system.
c. Name the document IDP-VA-lastname. For example, my document would be IDP-VA-
Bonner.docx.
2. Build an as-is Swimlane diagram in Visio or MS Excel. (Note: You do NOT have to build a “to-be”
diagram.)
3. Write a short memo to the Manager of the Computing Services Service Desk (IRM),
recommending changes to the process based on your application of the VAA technique (and any
other techniques from the textbook you think would help your analysis). It should be 3 pages
max. Put this memo in a separate MS Word document and upload.
Grading
This exercise will be graded using on the rubric posted with the assignment on myCourses.
Remember that when it comes to the Memo content, there is no “right” answer. You must defend your
answer with logic.
Summary
You will submit three documents:
1. VA analysis (use template)
2. Swimlane diagram (Visio, Excel, PDF)
3. Memo to the Manager of the Computing Services Service Desk (IRM)