260 likes | 506 Views
A Case Study: Implementing Supportworks Professional Helpdesk at Drew University. Betsy Black & E. Axel Larsson Drew University, Madison, NJ. Student Computing at Drew University. Computer Initiative (CI) – ubiquitous computing – began in 1984 with Epson QX-10.
E N D
A Case Study:Implementing Supportworks Professional Helpdesk at Drew University Betsy Black & E. Axel LarssonDrew University, Madison, NJ
Student Computing at Drew University • Computer Initiative (CI) – ubiquitous computing – began in 1984 with Epson QX-10. • Desktops evolved to laptops by 1988 (Zenith 181). • CI allows us to limit support to Drew-issued machines. • Campus-wide network placed increased demands on support organization.
Homegrown Helpdesks • 1998-1999: paper forms and DEC Notes in OpenVMS 7.2. • 1999: web-based tracking (helpdesk.drew.edu) with customer access to view tickets. • 2000: Oracle-based application (Beacon.drew.edu) included inventory information on the various models, allowing us to track repeated hardware problems.
Inventory management • Drew needed a more robust inventory management solution. • Windows servers allowed for development of Microsoft SQL Server database. • Enterprise application specialist developed uTrack for asset management, including program type (student-owned, Helpdesk loaner, departmental purchase, etc.) • Faculty/staff upgrade and purchase request tracking; and other assets within the department(s). • Web-based upgrade request tracking for customers.
Support Organizations at Drew • In the Fall of 2002, the department of Academic Technology at Drew underwent an organization change. The old structure was:
Selection process and feature list • Committee comprised of members from 3 technology departments as well as the VP for University Technology. • Required features identified: • Online customer access to track existing tickets. • Ability for customers to open tickets via online interface. • FAQ and knowledgebase feature. • Full text searching. • Integration with inventory database. • Ease of use for casual users.
Helpdesk packages we considered • FrontRange’s Heat • FAQ and knowledgebase packaged separately. • Very costly for our licensing requirements. • Blue Ocean’s TrackIt! • Did not have required functionality. • Hornbill’s Supportworks Helpdesk Professional • Packaged with FAQ and knowledgebase • Ability to escalate between support organizations • Reasonable licensing w/educational discount.
Supportworks Selected • Supportworks Helpdesk Professional chosen. • Committee formed in June to implement the product. • Included members of CNS, ITS, Administrative Computing, and Telecom. • Completed implementation by August 2003.
Support Groups • Groups used to simplify call assignment. • Unassigned calls are left in a group, and can be assigned to individuals within the group. • SLAs can escalate calls to a support group. • Support analysts can only exist in one group. • Fine for full-time staff. • Organize users in four groups corresponding to the technology departments. • Student employees present an issue. • Can work for more than one department. • Multiple accounts; use username prefixes to distinguish. • Authentication methods for analysts. • AD, LDAP, NDS, legacy NT 4 domain, etc.
Service Level Agreements • Two timers, response time and fix time. • Multi-level SLAs are in the works for the future. • Multiple sources for SLA assignment. • Customers, charge centers (departments), sites, problem profiles. • Multiple SLA responses. • Send mail. • Reassign the call. • Change call status indicators. (color codes) • Server side scripts. (PHP) • Each organization responsible for their own SLAs.
Problem/Resolution Profiles • Hierarchical profiles for reporting and SLA purposes. • Profile to any desired depth. • Selecting on a profile in a report gets all sub-profiles automatically. • Three levels of profiles at Drew. • Top level, general type of call. • Report problem, service request, how-to/training, maintenance, comments/suggestions. • Second level, specific application or service. • Third level, common problems.
Integration—Customers and Assets • Integration at database level. Sample PHP scripts provided by vendor for database import. • uTrack asset tracking application. • Drew-developed SQL Server 2000 application. • Database triggers synchronize to Supportworks database. • Customer data • Today—nightly database dumps from our administrative computing department. Perl scripts load the data. • Future—connected to our Novell eDirectory Identity Vault using Novell DirXML. Real-time updates.
“Hot” and “Known Issues” • Helpdesk analysts see Issues when they log into the system. • Issues can be internal or public, depending upon the nature. • Calls can be linked to an Issue, and then updated and closed en masse when the issue is resolved. • Helpful for system-wide problems with the network or phone systems.
Custom Call Classes and Forms • Call types are fully customizable. • Add tables and columns to the default DB schema. • Customizable call logging and call details froms with integrated form design tool. • Call classes we’ve added: • Classroom calls: Picklists for equipment involved. • On-Site calls: Building and room # fields. • Helpdesk intake: Associated loaner call field, picklists of equipment left at the helpdesk.
Self-Service • Web access for customers, allows them to: • Log new calls. • Check the status of and update existing calls. • Review issues. • Written in PHP. Fully customizable. • An excellent source of code for writing server side event scripts as well. • Drew customizations: • Themed to match our technology web site. • Novell iChain single-sign-on integration.
Pitfalls • Plan, plan, plan! • Our process was somewhat rushed as the Oracle license was expiring and we needed a solution fast. • Delineate problem/resolution profiles carefully and make sure all analysts understand how to associate calls correctly. • Implement a system for using call conditions to color code problem types. • Meet semi-annually to review the system and identify positives and negatives.
Pitfalls (cont’d) • Product limitations. • Windows client required for full analyst’s feature set. Web-based client is limited. • API docs limited. • Expansion in this area is a priority for the vendor. • Cited lack of internal API stability, training issues, as primary reasons for not opening this up right away. • Cache database makes database-level integration difficult for certain items. (Active calls mostly) • Windows client does not work through NAT. • UDP based notifications. Fixed in a future release.
Unexplored Features • Operator Scripts • Call “flowcharts” for first level support. Walks helpdesk operator through a script. • Responses to questions in the script can be recorded anywhere on the log call form. • Filters • Limit call display by any criteria selectable in an SQL WHERE clause. • Assign custom data dictionaries to analysts to limit call access.