Gestion des travaux, des incidents et des demandes d’information (partie 2)

Cet article est la suite de Gestion des  travaux, des incidents et des demandes d’information (partie 1).

Je suis partie de la connaissance de ITIL, de la connaissance des divers processus , pour construire une solution capable des gérer des demandes de travaux, de gérer des incidents, et de gérer les demandes d’information.

La solution est open source, pragmatique, elle est factuelle et concrète.C’est un partage d’information sur l’utilisation de la partie helpdesk de l’outil GLPI.

Avant propos

Avant de commencer le deuxième opus. je vais donner quelques informations sur le contexte de la mise en œuvre de GLPI, et sur le pourquoi ?

Dans le contexte, d’une entreprise, l’achat d’une solution ITIL est un processus complexe, coûteux, et souvent très long. Je me suis trouvé dans le cas, de l’absence de logiciel, et de budget.

La gestion des travaux, des incidents et des demandes de travaux est un processus générateur d’échanges, d’aller -retour, de mails. Il faut essayer de capitaliser sur le contenu des travaux, des incidents et dégager des actions préventives. Je me suis retrouvé dans le cas de recevoir plus de 200 mail par jour , voir plus de 400 en cas d’incident grave. Un jour d’absence est nous voilà avec plus de 500 mails. Le logiciel de messagerie n’a pas le temps de suivre.

La gestion de beaucoup de mail par jour, est un processus carnivore, consommateur de temps. La plus-value est en chute libre, dans un contexte de monter en charge, il faut réagir, réfléchir vite et bien. Qui répond à quoi ? qui a répondu, ou en sommes nous ? Pour une demande mineure, nous avons au minimum quatre à cinq échanges de mail.

  1. La demande,
  2. j’ai bien reçu la demande,
  3. je traite,
  4. pouvez vous vérifier ?
  5. c’est bon.

La capitalisation est quasiment impossible, il faut remplir des fichiers en dehors de la messagerie, recopier l’incident, et la solution. Le suivi de l’activité doit être réalisée au fil de l’eau. C’est un travail titanesque . Cela gère des fichiers Excel et Word dans tous les sens. Ensuite, nous avons le souci du travail en parallèle avec les divers membres de l’équipe, des demandes traitées en double, etc ..

Le but de cet article est de partager une solution UTILE. La solution GLPI a été une bonne solution (transitoire). Il vaut mieux une bonne solution, que pas du tout. Je vais aborder divers aspects du logiciel et tenter de vous convaincre.

Dans l’article précédent, nous avons vu la partie utilisateur. Je vous propose de regarder la partie Support et Back office.

La partie Support – Back office

Je vais reprendre avec vous le cahier des charges du côté du Back office, et décrire la réponse aux divers points.

  • Gérer plusieurs groupes d’utilisateurs
  • Gérer plusieurs demandes en parallèle,
  • Cloisonner et identifier les demandes et les demandeurs.
  • Effectuer un suivi des demandes,
  • Obtenir des statistiques

Avant d’ouvrir le service, nous allons conduire une petite démarche de réflexion sur le paramétrage de l’outil et sur le mode de fonctionnement de l’outil, sur l’écosystème autour de l’outil.

  • Gérer plusieurs groupes d’utilisateurs

Dans une entreprise, les activités sont décomposées en plusieurs services, sous services , et ainsi de suite, jusqu’au niveau projet. Chaque projet suit  diverses phases jusqu’à la mise en production.

Les diverses phases

Les diverses phases.

Dans le schéma ci-dessus, j’ai représenté la vie de plusieurs projets depuis la phase conception, jusqu’à la mise en production.  Les projets suivent une feuille de route (roadmap), jusqu’à la livraison finale. Les feuilles de route sont constituées de cycle, de validation, de recette, de passage en comité, etc. Un grand projet passe par de nombreuses étapes, par de nombreuses versions, jusqu’à la livraison, et plus encore. Une équipe de développement travaille sur la version 2,3, l’équipe de recette travaille sur la version 2,1 et installe la version 2,2, l’équipe de production travaille sur la mise en place de la version 2.0.1. Le directeur du projet est en train de planifier la version 3, pour 2014.

La structure des équipes change, en fonction de la version, en fonction des travaux à venir, etc. Une équipe est une entité, un groupe de personnes, une étape dans un projet. Elle est dédiée au minimum à un projet. Prenons le cas de l’équipe de production, elle travaille sur la mise en production du projet  A, ensuite, elle va déployer le projet C, la version 2,1 de A, ensuite le projet B et ainsi de suite.

Les entreprises font de plus en plus souvent appel à des entreprises externes (TMA / TRA), à des équipes externes pour maintenir, construire, bâtir, faire la recette d’un morceau de programme, de logiciel.

La Tierce Maintenance Applicative est la maintenance appliquée à un logiciel ( « applicative » ) et assurée par un prestataire externe dans le domaine des technologies de l’information et de la communication.

Tierce Recette Applicative (TRA) est, dans le domaine informatique, un terme qui désigne une prestation proposée principalement par les SSII. Elle correspond à la mise en place d’une méthode de tests aux différentes étapes d’un projet afin d’en optimiser la recette finale. Il peut s’agir de traiter d’une application ou d’un site web (dans ce cas, elle est aussi appelée e-TRA).  (Source wikipédia).

Les sociétés de service en ingénierie informatique (SSII) offrent plus de souplesse et des ressources externes. La population qui travaille sur les projets est diverse et variée.

Au niveau du logiciel GLPI, j’ai décidé de gérer des groupes d’utilisateurs, au lieu des personnes, à cause des entrées et sorties des diverses personnes dans les divers groupes. Il est difficile de construire un annuaire d’entreprise avec toutes les personnes, de créer les bons groupes pour un coût faible.

  • Cloisonner et identifier les demandes et les demandeurs.

J’ai compté 10 équipes pour 3 projets sur le schéma. Dans la réalité, il y a beaucoup plus d’équipe, de projet, de version de projet et ainsi de suite. La première étape consiste à regrouper les demandes par groupe, par pôle fonctionnel, par entité, par type de projet, de trouver une taille d’équipe consistante en terme de demande. en terme de pérennité dans le temps.

Par exemple, j’ai trois projets qui vont faire des demandes autour du progiciel Jahia, j’ai 2 pôles recettes, j’ai un pôle mise en production. Le regroupement suit une logique de service, de département. Le choix des groupes est une opération un peu complexe. Il n’est pas évident de déplacer une demande d’un groupe dans un autre groupe. C’est une opération fastidieuse.

  • Gérer plusieurs demandes en parallèle

La création de groupe permet de scinder les équipes, de garantir une confidentialité autour des demandes, de les regrouper par typologie, de montrer (communiquer) un avancement dans le traitement des tickets. La segmentation des demandes et le regroupement par typologie, permet d’identifier les incidents à répétition, les problèmes et de mettre en œuvre des actions correctives. Très souvent un incident sur un composant, sur une couche logicielle se reproduit sur des projets similaires. La capitalisation et la vision ciblée sont essentielles.

Il y a un aspect dont je n’ai pas encore parlé, c’est la gestion, le cycle de vie d’un ticket. Un équipe d’un projet A crée une demande de travaux. La demande de travaux est liée à l’équipe A.  L’équipe J ne peut pas voir les demandes de l’équipe A  (le principe de cloisonnement mis en place).

Demande

Les demandes de travaux de tous les utilisateurs projet arrivent dans la file d’attente de l’équipe Back Office, elle voit tous les tickets. Les travaux sur les demandes sont engagés, traités, résolus et aiguillés par l’équipe Back Office. Elle est responsable de la bonne réalisation des travaux. Elle peut faire appel à d’autres services pour des travaux, à des experts pour la résolution d’incident, et ainsi de suite. L’équipe Back Office a un rôle de coordination des travaux.

L’outil GLPI est un outil non bloquant. Un utilisateur de l’équipe A peut ajouter à tout moment des informations complémentaires sur un ticket de l’équipe A non clos. Le complément d’information apparait dans le fil de résolution du ticket.

Effectuer un suivi des demandes

Formulaire de recherche des tickets:

Liste des tickets coté support

La partie haute de l’écran présente les divers critères de recherche. Il est possible de combiner divers critères de recherche.

Choisir les filtres : (ci dessous le statut d’un ticket)

DetailFiltre

Le suivi des demandes est une opération très simple, qui demande peu de temps de préparation.

Il suffit de regarder la liste des tickets non clos, de regarder la date d’ouverture du ticket, le type de ticket et le nombre d’interaction.

Le nombre de ticket traité peut être mesuré à partir de la liste des ticket clos. Il suffit de prendre la dernière page.

Et ainsi de suite.

Les informations contenant une demande sont stockées dans le ticket, il y a une centralisation de l’information dans les tickets, il n’y a plus de mail (en dehors de ceux de l’outil GLPI).

Un ticket est attribué à une personne. Il est facile de savoir à qui le ticket est assigné et de faire le point avec.

Obtenir des statistiques

L’outil GLPI propose un menu statistique très simple. Je me suis vite aperçu qu’il ne répond pas à mes usages. Je vous présente toutefois cette partie.

Diverses statistique de GLPI

Le menu Statistiques de GLPI.

nombre de ticket

Les statistiques ci dessus, sont obtenues mois par mois.

Regroupement par environnement

Ci dessus , le nombre de ticket total par environnement.

Comme vous pouvez le voir, la partie Statistiques de GLPI est pauvre. J’ai effectué des recherches sur internet autour du sujet. Il n’y avait pas d’autres outils.

J’ai réalisé les statistiques de l’activité dans Excel.

Conclusion provisoire

La partie Help Desk de GLPI n’est pas complète. Elle permet de réaliser un help desk , des opérations de qualité, et un suivi simple.

Il n’y a pas de circuit de validation, pas d’entrave à la communication entre le back office et le client. Le client peut à tout moment compléter sa demande de travaux, interagir avec le back office.  Toutes les interactions entre le client et le back office sont tracées dans l’historique du ticket.

L’intégrateur est à même de prendre des décisions, de traiter la réalisation du ticket, de faire suivre la demande et ou de faire monter la demande.

Il manque une partie validation de la demande d’un point de vue comptable et financier, et aussi d’un point de vue réalisation. Il est possible de mettre en place un circuit de validation en fonction de la nature, de la durée et de la complexité de la demande, une sorte de convention de service. Les tickets simples sont traités directement (< 1/2 jours), les demandes moyennes (< 1 semaine) sont soumises à une pseudo validation, les demandes importantes sont arbitrées. Les premières interactions sont utilisées pour chiffrer et valider la réalisation. C’est un déroutement de l’outil, par contre à l’usage, on se rend compte de l’efficacité. Il y a une trace du processus.

Publicités

A propos Duarte TERENCIO

Chef de projet et Architecte J2EE - Portail d'entreprise - Cloud computing Vous trouverez plus d'information sur la page "Me contacter"
Cet article, publié dans Organisation, est tagué , , . Ajoutez ce permalien à vos favoris.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s