Copyright 2009 © Consortium ESUP-Portail JASIG Spring Conference, Dallas, Texas, March 1-4, 2009...

JASIG Spring Conference, Dallas, Texas, March 1-4, 2009

Copyright 2009 © Consortium ESUP-Portail

esup-helpdesk:a mature portlet for uPortal

Pascal AUBRYUniversity of Rennes 1

ESUP-Portail consortium

JASIG Spring Conference, Dallas, Texas, March 1-4, 2009 Copyright 2009 ©

A French survey in 2004

• Do you use a helpdesk?

• Why don’t you use a helpdesk?

Yes - 34%

No, but tried already - 6%

No - 60%

Other - 15%

Department members

are not ready - 1%

Do not see the point -

3%

Users are not ready -

14%

No answer - 7%

Lack of time - 32%

Lack of information about the

tools - 28%


A French survey in 2004 (cont.)

• Are you satisfied by using a helpdesk?

• Would you recommend using a helpdesk?

Not satisfied at all - 5%

Not satisfied - 5%

More or less satisfied -

10%

Satisfied - 39%

Very satisfied -

41%

Absolutely - 80%

No - 0%

Maybe - 20%


The main benefits of helpdesks

• Organization of the support team• Quality of the support• Knowledge database• Making the work visible to the users• Making the work visible within the team• Making the work visible to the hierarchy


Making the work visible

• To users– Exposing the work is appreciated– generally results in an overall improvement of the

relationship between users and the support team

• Within support teams– Share competences– Improve communication

• To the hierarchy– Should I really explain?


The main issues with helpdesks

• User reticence• Support team reticence

• Installation problems

• Unadapted software

• Heavy usage


Is esup-helpdesk just another helpdesk?

• Definitively not

• By and for the Higher Education

• User support at establishment-level– Close to the Information System

(CAS/LDAP/uPortal)


Mask the complexity from users

• Universities are complex structures

• This complexity must be masked to users

• Users are shown only the departments they have to see depending on– Their profile (LDAP/uPortal)– Their localization


Cutting the establishment into departments

• Discrete enough– to respect the natural independence of departments

• Communicative enough– to allow tickets to pass from one department to

another one

• Flexible enough– to take into account any existing support structures


Simplified example(University of Rennes 1)

MATH CHEM PHYS COMP

Central Support Team

PHILO

MEDICINE PHARMA ODONTO

ECONOMY

LAW

CommonSciences

department

CommonHealth

department

CommonLaw/Economy

department

HEALTH CAMPUS

OU

TS

IDE

US

ER

S

SCIENCES CAMPUS

LA

W/E

CO

NO

MY

CA

MP

US


Virtual departments

• Tickets can be automatically moved to another department

• Give the impression of support proximity

• Allow internal reorganizations– Without changing the external presentation


Simplified example(University of Rennes 1)

MATH PHYS COMP


PHILO


ECONOMY

LAW

CommonSciences

department

CommonHealth

department

CommonLaw/Economy

department

HEALTH CAMPUS

OU

TS

IDE

US

ER

S

SCIENCES CAMPUS

LA

W/E

CO

NO

MY

CA

MP

US

CHEMCHEMMATH PHYS PHILO

Sciences support team


Health support team Law/economysupport

team

ECONOMY

LAW


The external view of the helpdesk

MATH CHEM PHYS COMP


PHILO


ECONOMY

LAW

CommonSciences

department

CommonHealth

department

CommonLaw/Economy

department

HEALTH CAMPUS

OU

TS

IDE

US

ER

S

SCIENCES CAMPUS

LA

W/E

CO

NO

MY

CA

MP

US


The internal view of the helpdesk

COMP


CommonSciences

department

CommonHealth

department

CommonLaw/Economy

department

OU

TS

IDE

US

ER

S

SCIENCES CAMPUS

LA

W/E

CO

NO

MY

CA

MP

US

Sciences support team

Health support team Law/economysupport

team

HEALTH CAMPUS


Cutting departments into categories

• Large support structures (universities)– Thousands of users– Dozens of managers in departments– Thousands of tickets

• A flat structure is not sufficient

• Any sub-division is allowed– By thema (email, courses, development, …)– By building, by operating system, …


Cutting departments into categories


Virtual categories

Department A

Department B

web

email

Unix workstations

Windows workstations

administrative problems


Self-service workstations

Specialized workstations

email

web


Virtual categories

Department A

Department B

web

AdmissionsAdministration

and Bursar's Office

email

Unix workstations






email

web


Virtual categories

Central support team

ema

il

Department A

Department B

web


and Bursar's Office

email

Unix workstations






email

web


Virtual categories

Central support team

web

ema

il

Department A

Department B

web


and Bursar's Office

email

Unix workstations






email

web


Implementing such a customized vision

• Create departments and categories

• Define visibility rules


Test the rules before applying them


Ok, but how long will it take?

• Quite a while, but not always where it was expected

t

Technical implementation

CommunicationAcceptation of the solution

ReflectionOrganization of the support


Formalizing the competences

• Map categories to competences

• Define the members of the categories– i.e. determine who will follow up on tickets

corresponding to certain competences

• A real chance to detect weaknesses as well as redundancies in a support team


A tool to support usersor to supervise managers?

• Statistics

• Often the main motivation

• Often the main reject reason

• The risks are really minor compared to the benefits


Statistics


Statistics (cont.)


Statistics (cont.)


Statistics (cont.)


Statistics (cont.)


Statistics (cont.)


The main goal: user satisfaction

• Quick, low-problem ticket input

• Good reaction times

• High-quality knowledge database

• Good priority management

• Real-time follow-up of tickets

• Clear identification of a unique speaker

• A universal and ergonomic interface

• The possibility of confidential exchanges


Quick and low-problem ticket input

• Goal: have all the elements needed to resolve problems as soon as tickets are created

• 2 steps– Choose a category– Fill a pre-completed ticket

• Links to FAQ

• WYSIWYG


Step 1: choose the category


Step 2: fill a pre-completed ticket


Automatic assignmentof tickets to managers

• Often the thing that takes the most time is deciding who takes charge of a new ticket– Assign the ticket at creation

• Predefined algorithms respond to the most common needs– assignment to the first available manager, cyclical

assignment, random assignment, …– Custom classes can be added

• (simple) Java development, e.g. link to a calendar


The knowledge database

• The essential contribution of the helpdesk– Users can find the solution of their problems

without creating a ticket• FAQs can be added to tickets

– More structured information• Full-text indexation (both tickets and FAQs)


Priority management

• Without a helpdesk, by email– Several strategies: FIFO, FILO, SISO, …SINO– Essentially depending on the manager’s mood

• The support service must be completely separated from the email inbox


Ticket monitoring


Ticket monitoring

• Often quickly filtered to /dev/null (SPAM)

• Highly configurable, by the users themselves

• Tickets can be monitored individually


Ticket monitoring (for managers)

• Pre-defined policies– None, minimal, medium, assiduous, complete– For each department

• Daily reports


Daily reports


A unique and identified speaker

• No multiple and conflicting responses– Waste of time– Deplorable image of the support team

• Faceless but not anonymous– Every action is nominative and logged


A user interface for everyone

• Simple and intuitive– Used by both technical and non technical people


Visibility / Confidentiality

• Interest of visibility– Share solutions (knowledge database)– Prevent from several tickets for a single problem

• Drawbacks of visibility, need of confidentiality– Exchange sensible information– A good pretext not to use a helpdesk ;-)

• Visibility and confidentiality are reconciled– Several visibility levels– High granularity (department, ticket, action)


Supporting both local and outside users

• All the support in one tool• Authenticate outside users (email/password)

• Some use the email authentication only


Integration into the IS

• Single Sign-On– CAS (Central Authentication Service)

• uPortal by JASIG– Use of uPortal groups and user attributes

• LDAP– search interface– Attributes retrieval


Internationalization

• 3 languages available yet

• All the strings externalized– Resource bundles– Any key can be overidden by deployers

(without editing the distributed bundles)


Canned responses

• At application, department or user-level


Bookmarks and history


External feeding

• From applications– Thanks to a web service

• From IMAP accounts– A crontab periodically scans IMAP folders– Pattern-based SPAM detection


The software

• Part of the ESUP-Portail software– Open source (LGPL)– Collaborative development

• 10 commiters in v2, 3 commiters in v3

– ~30 institutions in production

• Based on esup-commons– Spring, JSF, Hibernate, Lucene

• Portlet or servlet!– Quick-start available


A 10 years old project

• 1999: ifsic-helpdesk– PHP application at IFSIC (part of the University of Rennes 1)

• 2004: esup-helpdesk v1– uPortal channel at the University of Rennes 1

• 2007: esup-helpdesk v2– uPortal channel in 30 universities and schools

• 2008: esup-helpdesk v3– JSR-168 portlet (or servlet)

• 2010: jasig-helpdesk?– Candidate to the JASIG incubator


esup-helpdesk in France

v2v3


esup-helpdesk in Europe

v2v3


Esup-helpdesk in the world

• We believe in the JASIG incubator…

v2v3

Date post:	17-Jan-2016
Category:	Documents
Upload:	brooke-scott
View:	214 times
Download:	0 times

Copyright 2009 © Consortium ESUP-Portail JASIG Spring Conference, Dallas, Texas, March 1-4, 2009...

Documents