BADM 6330 Business Process Management : Assignment
4 Pages1648 Words477 Views
Added on 2019-09-18
BADM 6330 Business Process Management : Assignment
Added on 2019-09-18
ShareRelated Documents
BADM 6330 – Final Project: TX UniversityProcess 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 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 andaccounts 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 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 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 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 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 Universitysupposed 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 viathe 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 isthe 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 arequest 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.
End of preview
Want to access all the pages? Upload your documents or become a member.
Related Documents
Different Functions of a Help-deska Worker Oxfam Charity | Reportlg...
|6
|893
|342