Transcript A Case Study: Implementing Supportworks Professional

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.
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 (studentowned, 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:
University
Technology
Administrative
Computing
Telecom
Department of
Academic
Technology
User Support/
Computer Store
Faculty
Technology
Lab
Staff
Technology
Lab
Systems
Administration
Training
Resource
Lab (Student)
And the new structure is:
University Technology
Administrative Computing
Telecommunications
Computing & Network Services
Instructional Technology
User Support/Computer store
Faculty Lab
Systems Administration
Staff Lab
Enterprise Applications
Student Technology Lab
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.
CNS
Helpdesk
selection
committee
AC
ITS
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.


Student employees present an issue.



Organize users in four groups corresponding to the technology departments.
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.
Support Groups
Service Level Agreements

Two timers, response time and fix time.


Multiple sources for SLA assignment.


Customers, charge centers (departments), sites, problem
profiles.
Multiple SLA responses.





Multi-level SLAs are in the works for the future.
Send mail.
Reassign the call.
Change call status indicators. (color codes)
Server side scripts. (PHP)
Each organization responsible for their own SLAs.
Service Level Agreements
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.

Problem/Resolution Profiles
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.

Custom Call Classes and Forms
Custom Call Classes and Forms
Custom Call Classes and Forms
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.

Questions?