ESUP-Portail Helpdesk : le suivi des demandes des utilisateurs à l’échelle d’un établissement

Copyright © 2005 – ESUP-Portail

ESUP-Portail Helpdesk :le suivi des demandes des utilisateurs

à l’échelle d’un établissement

Sébastien GaudinUniversité de Nancy 2

Pascal AubryIFSIC / Université de Rennes 1

Alexandre BoisseauUniversité de Brest

http://esup-helpdesk.sourceforge.net


?Prologue


Le GT-SSD

• Groupe de Travail Système de Suivi de Demandes

• Soutenu par l’UREC et le CRU

• Enquête fin 2004 sur l’utilisation des SSD– 120 réponses

Constat


Utilisez-vous un SSD ?Constat


Êtes-vous globalement satisfait ?Constat


Conseilleriez-vous l’utilisation d’un SSD ?

• OTRS, Request Tracker, Gédéon, …

Constat


Principaux apports des SSD

Organisation du travail de l’équipe

Qualité du service rendu

Base de connaissance

Visibilité du travail auprès des utilisateurs

Visibilité du travail auprès de la hiérarchie

Visibilité du travail au sein de l’équipe

Constat

1 (le plusimportant)

2

3

4

5

6 (le moinsimportant)


1 (le plusimportant)

2

3

4

5 (le moinsimportant)

PROBLÈMESHUMAINS

PROBLÈMESTECHNIQUES

Problèmes rencontrés

Difficulté de mise en place

Réticence des utilisateurs

Réticence au sein de l’équipe

Logiciel mal adapté

Lourdeur d’utilisation

Constat


Problèmes rencontrés

• Aie ! Les problèmes ne sont pas que techniques…– La solution doit être d’autant plus réfléchie

• Esup-helpdesk : un SSD supplémentaire– Oui, mais pas seulement

Constat


Mutualisation et support utilisateur

• Partout on mutualise– Applications centralisées– Matériels communs– Services partagés– Bâtir l’offre applicative autour du Système d’Information

• … sauf pour les Systèmes de Suivi des Demandes– esup-helpdesk se propose de combler ce manque

Constat Organisation du support


Découpage de l’établissement en services

• Assez étanche– pour assurer l’indépendance des services

• Assez communiquant– pour assurer le support au niveau de l’établissement

• Assez configurable pour s’adapter– à un support déjà existant– aux différences de fonctionnement des services



Appréhender la complexité

• S’adapter à la structure complexe des établissements

• Découpage quelconque– Par composante administrative, par campus, …

• Vision adaptative du support– Masquage de la complexité aux utilisateurs– En fonction de leur profil et leur localisation



Exemple simplifié (Nancy 2)

Campus 1(étudiants)




Campus 1(personnels)




Centre de ressources informatiques

PERSONNELS

ÉTUDIANTS

EXTERNES



Exemple simplifié (Rennes 1)

MATH SVE SPM INFO

CRI central

PHILO

Médecine PHARMA ODONTO

IGR

DROIT

Services communsBeaulieu

Servicescommuns

Santé

Services communsCentre

CAMPUS DE VILLEJEAN

EX

TE

RN

ES

CAMPUS DE BEAULIEU

CA

MP

US

CE

NT

RE



Virtualisation

• Les tickets déposés dans un service peuvent être automatiquement redirigés vers un autre service

• Donner une vision de proximité aux utilisateurs

• Permettre la modification du support en interne sans en changer la présentation externe




MATH SVE SPM INFO

CRI central

PHILO


IGR

DROIT


Servicescommuns

Santé


CAMPUS DE VILLEJEAN

EX

TE

RN

ES

CAMPUS DE BEAULIEU

CA

MP

US

CE

NT

RE




MATH SVE SPM INFO

CRI central

CRI cellule Beaulieu

PHILO


IGR

DROIT


Servicescommuns

Santé


CAMPUS DE VILLEJEAN

EX

TE

RN

ES

CAMPUS DE BEAULIEU

CA

MP

US

CE

NT

RE




MATH SVE SPM INFO

CRI central

CRI cellule Beaulieu

PHILO

CRI cellule Santé


IGRCRIcelluleCentre

DROIT


Servicescommuns

Santé


CAMPUS DE VILLEJEAN

EX

TE

RN

ES

CAMPUS DE BEAULIEU

CA

MP

US

CE

NT

RE



Découpage des services en catégories

• Destiné à l’origine aux Universités– Plusieurs dizaines de milliers d’utilisateurs– Plusieurs dizaines de gestionnaires dans certains services

• Découpage quelconque– Par thématique (courrier électronique, développement, …)– Par bâtiment, par système d’exploitation, …



Virtualisation des catégories

Cellule de proximité A

Cellule de proximité B

web

mail

postes de travail Unix

postes de travail Windows

problèmes administratifs


salles libre-service

salles spécialisées

mail

web






web

servicesde scolarité

mail







mail

web


CRI central

web

mail


CRI central

web

mail




web

servicesde scolarité

mail







mail

web



Mise en œuvre d’une vision adaptative

• Définition de services et catégories– Stockées en BDD– Gérées au niveau de l’interface web

• Règles de visibilité– Définies de manière centralisée– Fichier de configuration XML

• Tests avant mise en production



Et combien de temps ça prend tout ça ?

• Pas mal, mais pas toujours là où l’on pense


t

Mise en place technique

CommunicationAcceptation de la solution

RéflexionOrganisation du support


La mise en place d’un SSD est un projet en soiConstat Organisation du support


Organisation interne

• Affectation des gestionnaires (administrateurs)– Aux services– Aux catégories

• Formalisation des compétences– Mise à plat des compétences individuelles et collectives– Détection des faiblesses, des trop grandes redondances



L’objectif principal : la satisfaction des utilisateurs

• Résolution plus rapide des problèmes• Meilleure gestion des priorités• Suivi en temps réel des tickets• Identification d’un interlocuteur unique et connu• Interface ergonomique et universelle• Confidentialité possible des échanges

Constat Organisation du support Satisfaction des utilisateurs


Saisie des tickets

• Objectif : posséder tous les éléments nécessaires à la résolution dès la saisie du ticket

• Étapes :– Choix du service puis de la catégorie– Choix d’un problème-type– Présentation d’un ticket pré-rempli

• Exemple : – « UFR Math » → « impression » → « bourrage interne »



Assignation automatique des tickets

• Le temps nécessaire à la prise en charge est souvent très pénalisant → assignation dès la création du ticket

• Algorithmes prédéfinis– Au premier gestionnaire disponible, de manière cyclique,

aléatoire, au gestionnaire le moins chargé, …

• Possibilité de personnalisation– Développement d’une classe Java– Interrogation d’une application de gestion de congés



Gestion des priorités

• Sans SSD, gestion par courrier électronique– Plusieurs stratégies possibles : FIFO, FILO, SISO, …SINO– Selon l’humeur du gestionnaire, le demandeur, le moment

de la journée, …

• Il faut déconnecter le suivi du courrier électronique !



Remontées d’alerte (gestionnaires)

• Rapidement filtrées vers /dev/null si trop nombreuses• Hautement configurables



Remontées d’alerte (utilisateurs)

• Redirigent vers l’interface (Reply-to: [email protected])



Un interlocuteur unique et identifié

• Interlocuteur unique– Pas de traitement parallèle des tickets

• Interlocuteur identifié– Toutes les actions sont nominatives et tracées



Une IHM à la hauteur… du plus novice

• Une interface simple et intuitive créée par itération en fonction des retours des utilisateurs



Visibilité / Confidentialité

• Intérêt de la visibilité– Pour partager les solutions (base de connaissance)– Pour éviter les tickets multiples pour un même incident

• Inconvénient de la visibilité, besoin de confidentialité– Échange d’informations sensibles– Obstacle à l’abandon du courrier électronique

• Visibilité et confidentialité ne sont pas antinomiques– Plusieurs niveaux de visibilité– Granularité très fine (service, ticket, action)



Base de connaissance

• Permet aux utilisateurs de chercher eux-mêmes la solution à leur problèmes– Accélération de la résolution

• Indexation par Lucene

• Interface de recherche avec critères avancés



Visibilité du travail effectué

• Vis-à-vis des utilisateurs– Ouverture et transparence perçues très positivement– Compatible avec la confidentialité

• Au sein des équipes de support– Partage de compétences

• Auprès de la hiérarchie– Est-il besoin d’expliquer ?

Constat Organisation du support Satisfaction des utilisateurs Autres objectifs


Intégration dans le S.I.

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

• Environnement Numérique de Travail– uPortal by JASIG

• Lien étroit avec les données du S.I.– Interface de recherche dans l’annuaire LDAP– Récupération des attributs LDAP– Utilisation des groupes uPortal



Assistance interne et externe

• Permet de gérer l’ensemble du support utilisateur

• Authentification des utilisateurs externes– « à la Sympa » (mot de passe envoyé par mail)

• Note : certains exploitants n’utilisent l’outil qu’avec l’authentification externe



Outil d’assistance, outil de surveillance

• Possibilités d’extraire des statistiques– Collectives– Individuelles

• Principale motivation de mise en place d’un SSD

• Principale raison de refus des SSD

Constat Organisation du support Satisfaction des utilisateurs Autres objectifs Dérives et dangers


Doit-on pour autant en ignorer les avantages ?

• Les risques de dérive ne doivent pas être une barrière

• Nécessité de discuter ce point avec la hiérarchie

• Distribution officielle sans statistique individuelle– Jugées trop difficiles à exploiter– Volonté des développeurs

Constat Organisation du support Satisfaction des utilisateurs Autres objectifs Dérives et dangers


L’outil esup-helpdesk

• Partie du projet ESUP-Portail

• Logiciel libre (licence LGPL)

• Spécification UML, 100% Java

• Développement collaboratif

Constat Organisation du support Satisfaction des utilisateurs Autres objectifs Dérives et dangers L’outil esup-helpdesk


Historique du projet

2001

Ifsic-helpdesk is running at IFSIC (University of Rennes 1)

The very first textual specifications of esup-helpdesk

esup-helpdesk is running at University of Rennes 1

UML specifications and coding

esup-helpdesk is officially presented at JRES’2005

esup-helpdesk is distributed by consortium ESUP-Portail

Demonstration site is online

Consortium ESUP-Portail is formed20

0220

0320

0420

0520

0620

07

esu

p-h

elp

de

skif

sic

-he

lpd

esk



Standards ouverts uniquement

• Rendu XML par Xalan/Xerces• Indexation par Lucene• Web Services par Axis

• Persistance des données par Hibernate– Abstraction du SGBD / abstraction des données– Optimisation des accès à la base de données– Pas de problème de montée en charge



Architecture

• Complexe…

JVM

Tomcat

uPortalesup-helpdesk

navigateur

base dedonnées

JREJRE JRE

servlet

HTTP

XMLHibernate/JDBC

HTML

HTML



Le package Quick Start

• Environnement non dégradé– Utilisé en production

JVM

esup-helpdesk-quick-start

navigateur

base dedonnées

JRE

HTTP

Hibernate/JDBC

HTML



Déploiement

Under production Production planned Testing



Déploiement

Under production Production planned Testing ESUP-Portail



Perspectives

• Fonctionnalités– FAQs– Statistiques– Hibernate 3– JSR168 (portlet)

• Internationalisation

2004

2005

2006

2007

1.4.0 – first release distributed

very first textual specifications

1.7.9 – ticket templates, LDAP search

1.4.4 – internationalization

UML specifications and coding

1.5.0 – confidentiality1.5.3 – esup-helpdesk-quick-start1.6.0 – virtual categories1.7.0 – Lucene indexation1.7.6 – email feeding1.7.7 – web services

1.8.0 – deep linking

1.9 - FAQs

1.10 – statistics

2.0 – Hibernate 3

3.0 – JSR168

Vous êtes ici



La route qui mène au SSD est longue…et la route est savonneuse !

• Les choses ont peu changé ces dernières années…– Petit manuel anti-dépression à l’usage des AS&R,

Gérard Milhaud et Olivier Pagé, JRES 2001– Ah, si : les SSD sont là et ils sont performants

• Pourtant, les réticences le plus fortes ne viennent pas des utilisateurs !– Masochisme quand tu nous tiens ;-)

Constat Organisation du support Satisfaction des utilisateurs Autres objectifs L’outil esup-helpdeskDérives et dangers La route est longue…


Le SSD n’est pas un choix

• Dans tous les cas, le support passera par un SSD– Plutôt le choisir aujourd’hui que le subir demain !

• Impératif : volonté politique forte



Morale

Bûcheron et castor sur le support peinaient

Tant qu’à la dépression leur boulot les menaient

Le bûcheron choisit un très beau SSD

Et le pauvre castor se mit au LSD

http://helpdesk-demo.esup-portail.org


Documents

ESUP-Portail Helpdesk : le suivi des demandes des utilisateurs à l’échelle d’un établissement