Entertainment Track: Integrating Beer Pub Tracking Software

1. Entertainment Track:Integrating Beer PubTracking Software Sue Hales, Bucknell University Rick Osterberg, Harvard University

2. Support Models Track:Problem Tracking Systems:One Year Later Sue Hales, Bucknell University Rick Osterberg, Harvard University

3. Applause! Applause! Applause! Applause! Applause! Applause! Applause!

4. Roadmap & Agenda • What is a tracking system? • What are the advantages? • Overview of different options • What you need to think about • Case study of two products • Future plans • What we learned • Discussion and questions

5. What is a tracking system? • Log walk-ins, calls, e-mails, visits • Route problems to appropriate individuals • Report on Help Desk statistics • Doesn’t necessarily include knowledgebase

6. Do you want tracking? Yes!

7. Do we have all the answers? No!

8. Top 12 Reasons... 6. Prevent requests from falling through the cracks 7. Track performance (department/staff) 8. Escalate “stale” tickets to get attention 9. Keep an accurate history of users 10. Track the different beers your staff has tried 11. Gather statistics to be proactive 12. Improve internal communication

9. Top 12 Reasons... 1. Because you didn’t already have enough projects to work on 2. Respond to “problem” users & parents 3. Reduce need for organizational knowledge 4. Because you always dreamed oflearning SQL 5. Increase ability for staff to cover each other and hand-off tickets

10. Help Desk Software Options • Commercial Packages • Remedy, Heat, Clarify, Apriori, McAfee • Home-grown desktop database apps • Filemaker, Access, FoxPro, 4D • More complex home-grown systems • Web, SQL back end, Perl, C++, CGI

11. Pros & Cons:Commercial Packages • Big $$ - Anywhere from $10K - $100K • You get what you pay for • Not necessarily tailored for your site • Often not cross-platform • Requires lots of in-house maintenance • Powerful! Lots of features • If you don’t have developers but have lots of money, may be good approach

12. Pros & Cons:Home-Grown Desktop Apps • Design limitations • Speed issues • Cross-platform issues • Inexpensive • Easy & quick development; modifiable • Tailored specifically to your site • Good prototyping tool • No developers or money? Good approach

13. Pros & Cons:More Complex Home-Grown • Requires back-end database • Requires in-house development skills • Long-term maintenance issues • Usually web based -- free clients • Tailored specifically to your site • Possible integration with external data • No money? Have developer? May be a good approach

14. What you need to think about • Resources • Features • Workflow Analysis • Design These will drive your tool selection

15. Resources • What can you afford? • Who will implement system? • What technical skill sets are available? • What external data can you use? • What back-end systems are available? • What client systems are there?

16. Features • Reporting and searching requirements • Need web interface? E-mail interface? • E-mail notification to staff? To users? • Automatic escalations? • Direct access to external data? • Scheduling of support staff? • Knowledgebase? • End-user/client access to system? • Inventory management? • Cross-platform requirements? • Clearly-defined scope. Don’t do it all in v1.0!

17. Workflow Analysis • What is your support structure? • How/to whom are problems reported? • How are problems assigned to staff? • by platform? application? department?location? round-robin? hardware vs. software? reporting method? combo? • What decisions should the computer make? Which should a human make? • e.g., who gets the ticket? should I send e-mail?is it an emergency?

18. Design • Table design • Usability/robust user interface • Minimize data entry • Automate workflow • Avoid hard coding specifics • What reports do you want to get out? • Security • Anticipate the unanticipated • K.I.S.S. principle

19. Don’t forget!!! • User guide/training • Debugging and usability testing • Volume and stress testing • Programmer documentation/comments • Communication with user base • A computer cannot determine if a user inputs a “helpful” description

20. Case Study:Grand Central Station

21. Bucknell University • liberal arts & engineering • located in Lewisburg, PA • 3400 undergraduates • 200 graduate students • 260 full-time faculty • 900 administrative staff • 42 computer center employees

22. Bucknell’s Computer & Communication Services

23. Where do problems go?

24. GCS Architecture • FileMaker Pro 4.0 clients (x-platform) • FileMaker Pro 3.0 server (on Mac) • 85 users (not concurrent)

25. Tickets Clients (~6000 records) Departments (~65 records) Staff (~125 records) Dorms (~15 records) RCC Dorm Assignments Supported Software PopUps Holidays GCS Files

26. Grand Central StationDemo

27. GCS: Future Plans • Web access • User submission of tickets • Live links to administrative data • Hardware work orders • Auto-escalation of tickets • Action items for tickets • … many others ...

28. Free (with restrictions) • Free only to higher-ed institutions • Cannot distribute it to other sites • Can freely modify (except for splash screen) • Can’t provide support • GCS-L for mutual assistance

29. Case Study: Hound

30. Harvard Structure

31. Harvard’s StudentSupport Environment • Support of students only • Network and non-network support • 60-70 student/casual employees • 45-50 students do residential support • 4 students: Advanced Support Team • 5 FTE in student support • ~25 FTE technical staff • 6500+2000 residential students (98%) • 20 geographical student support groups

32. Harvard Support Model • Sources of help • Help Desk • Help Phone Line (central) • help@fas e-mail • Residential UA (visit/phone/e-mail) • Residential UAs primary source of help • Escalate to Advanced Support Team • Escalate to technical groups

33. Project HoundArchitecture • Web/CGI/HTML interface (Stronghold) • provides good cross-platform support • SQL back-end (mSQL now, Oracle soon) • Perl (object-oriented) • good web/CGI interface, string handling • DBI database package: portability • well-known for future maintenance

34. Hound tables • People • Tickets • Actionlines (Tech Events) • Appointments • Userdump • 24 other auxiliary tables • join tables, lookup tables, etc.

35. Some Hound stats • Two students, 8 weeks to write • 2300 tickets, 11,000 action lines • 1600 people, 3400 appointments • Code base: 23,000 lines • 4300 blank lines • 2200 comment-only lines • 4400 code lines with comments • 12,100 uncommented lines • 639,000 characters of code

36. Hound Demo

37. Hound: Future Plans • Port to Oracle! • Public distribution • Users interacting directly with system • Better live admin data • More automation • Auto-escalation

38. What did we learn? • Need to look closely at your workflow • Solutions entered will not be knowledgebase-quality • Database performance is critical • Staff is resistant to change • User interface/ease of use critical! • Don’t try to everything the first time • Your school is different

39. Resources • Help Desk Institute • www.helpdeskinst.com/bg/sections/sec4.htm • Support Services Conference • www.sbforums.com/ssce • Service News • www.servicenews.com • Help Desk List (hdesk-l) web site • www.duke.edu/~pverghis/hdeskfaq.htm • Help Desk List (hdesk-l) Archives • wvnvm.wvnet.edu/htbin/listarch.viorexx?hdesk-l&listserv.202

40. With apologies to Monty Python... I’m an RCC, and I’m okay; I surf all night, and I sleep all day; I wear cool T’s, I get free lunch; I go to the laboratory; On Wednesdays I fix printers, and have troubled disks to fix; I wear cool T’s, I ping and pop; I don’t like to take showers; I always take my cell phone, and hang around in dorms; I wear cool T’s, the job’s a breeze; I get a beeper, too; I want to be a hacker, just like my dear Papa.

41. Discussion and Questions Thanks! Remember: BOF at 4:00 Sue Hales - Bucknell University Rick Osterberg - Harvard University