BADM 6330 – Final Project: TX University
Added on - 18 Sep 2019
Showing pages 2 of 4
BADM 6330 – Final Project: TXUniversityProcess DescriptionTX 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 appointedmanager of support responsible for the Computing Services Service Desk function, IRM (IncidentResolution Management). There is at least one IRM employee at each site; the main campus has sevenpermanent employees and many student workers. In addition, work is outsourced to Presidium forabout 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 andaccounts for about 90% of all contacts with Presidium accounting for all initial phone contacts (about70% 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 allcontacts; Tier 3 accounts for about 1% of all contacts. Tier 3 support is provided by vendors of eitherhardware or software.Telephone and web forms are the two methods used to initiate contact for the service desk. Oncecontact is made, phone, web form or email might be used for continuing contacts. Rarely is contact inperson so it is not discussed. All methods can result in telephone, email, web form contacts for updatingand/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 isvalidated 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), ahome-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 resolutionreadily available. If an entry is in the KEDB, either a solution or workaround is passed to the user to tryto fix the problem. If possible, the request is serviced in the first phone call and the logged request isclosed by the individual logging the contact.If the request is not serviced in the initial contact, Presidium is supposed to perform sometroubleshooting to see if they can fix all problems not in the KEDB; however, they often pass onproblems when there is no KEDB entry. If troubleshooting is performed, the actions tried should bedocumented in the IMS software. Presidium transfers calls (via an automated call director (ACD) toeither Tier I or II in IRM; only Tier II IRM can escalate to Tier III, vendor support. Transfers fromPresidium usually go to Tier I IRM support which retries the KEDB and troubleshooting, documenting thesteps 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 checksto see if transfer to another organization is checked. If so, the item is placed on a queue for automateddelivery to the next available person in that area (this areas to which electronic delivery is done includeIRM staff (Tier I internal) and Technical Services (Tier II). If Tier II escalates to a vendor, the individualmanaging the contact also manages all interactions with the vendor(s). Any vendor interactions are
BADM 6330 – Final Project: TXUniversitysupposed to be documented in the IMS but there is no requirement or coercion available to ensure thatthis 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 viathe initial contact method or email. Interactions after the first are all supposed to be logged into theIMS software but there is no mandatory entry nor is there automated escalation (e.g., to a high level ofsupport or manager based on time from request to expected resolution or type of request). As a resultsome 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 isthe basis for the web application that provides status, resolution information, and so on to users via theuniversity web site.There are 15,000 open requests of which more than half are more than one year old. There is noclassification of user, request, or other designation to facilitate resolution or tracking. Thus, whenforwarding is done, a request is generically sent to the next level. Items sent to vendors for resolutionare not tracked for timely resolution unless the outage affects many users. The original person logging arequestshouldbe the person who monitors a request and closes it; however, the outsourcer does noneof that except for first calls resolved during the call. IRM or Tech Support are responsible for closingrequests 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 theremaining 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 neverclosed.The service desk outsourcer (Presidium) only takes phone calls and creates tickets based on the phonecalls. In normal circumstances they will close the ticket on initial contact and solution is communicatedwhile on the phone and also via web form. If Presidium staff are unable to solve an issue they willescalate the ticket to IRM and the user will be notified while on the phone as well as via the ticket. Inmost cases the ticket will end up in the IRM service desk queue where university staff will contact theuser 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 alsocommunicate with the user and close the ticket. Assume that by updating the IMS, the web site is alsoupdated. Many organizations use the logging DB as the method for also providing feedback to the usersso 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 whileworking on the ticket (internal to IRM only). The web form is utilized both by Presidium and alluniversity employees to update customers.