a case study implementing supportworks professional helpdesk at drew university n.
Skip this Video
Loading SlideShow in 5 Seconds..
A Case Study: Implementing Supportworks Professional Helpdesk at Drew University PowerPoint Presentation
Download Presentation
A Case Study: Implementing Supportworks Professional Helpdesk at Drew University

A Case Study: Implementing Supportworks Professional Helpdesk at Drew University

138 Views Download Presentation
Download Presentation

A Case Study: Implementing Supportworks Professional Helpdesk at Drew University

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. A Case Study:Implementing Supportworks Professional Helpdesk at Drew University Betsy Black & E. Axel LarssonDrew University, Madison, NJ

  2. 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.

  3. Homegrown Helpdesks • 1998-1999: paper forms and DEC Notes in OpenVMS 7.2. • 1999: web-based tracking ( with customer access to view tickets. • 2000: Oracle-based application ( included inventory information on the various models, allowing us to track repeated hardware problems.

  4. 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.

  5. Support Organizations at Drew • In the Fall of 2002, the department of Academic Technology at Drew underwent an organization change. The old structure was:

  6. And the new structure is:

  7. 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.

  8. 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.

  9. 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.

  10. 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.

  11. Support Groups

  12. 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.

  13. Service Level Agreements

  14. 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.

  15. Problem/Resolution Profiles

  16. 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.

  17. “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.

  18. 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.

  19. Custom Call Classes and Forms

  20. Custom Call Classes and Forms

  21. Custom Call Classes and Forms

  22. 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.

  23. 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.

  24. 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.

  25. 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.

  26. Questions?