Application de Suivi Qualité

Introduction

L’objectif de cet article est de partager l’expérience que nous avons acquise lors de la transformation d’un logiciel de gestion d’incident (Request Tracker) en un système de gestion de qualité industrielle.
Il s’adresse aux responsables et aux techniciens qui souhaitent mettre en place une solution de gestion d’incidents fondée sur le logiciel libre RT.

Introduction à la gestion d’incidents

La gestion d’incidents consiste à :

alerter et déclarer ;
valider et répondre ;
suivre et chiffrer les incidents.

De nombreux professionnels ont besoin de ce type de fonctionnalités, notamment dans :

les centres de support clients ;
la gestion de parc informatique « Help desk » ;
l’industrie.

Chaque profession dispose de son propre vocabulaire mais le processus de gestion est plus ou moins le même :

Solution libre « Request Tracker »

Request Tracker est un logiciel libre édité par la société « Best Pratical Solutions » sous licence GPL.

Il est composé de plusieurs éléments :

un moteur de gestion de « tickets »
une base de données relationnelle
plusieurs interfaces : web, ligne de commande et messagerie.

Fonctionnalités

Les principales fonctionnalités du logiciel sont les suivantes :

déclarer, assigner, organiser, rechercher et répondre à un incident ;
la déclaration peut se faire via l’interface web ou bien via l’envoi d’un mail ;
historique complet des actions et de toutes les modifications entreprises ;
interface multi-utilisateurs et traduction en de nombreuses langues ;
support de nombreux types de bases de données relationnelles (MySQL, Oracle, PostreSQL, etc...) ;
décompte du temps consacré ;
moteur de recherche / extraction des informations.

Point fort : la personnalisation

La plus grande force du logiciel, est la facilité de personnalisation :

champs personnalisables (« Custom Fields »), il s’agit d’attribuer des champs de différents types à un événement ;
scripts (« Scripts »), il s’agit d’un système de macros déclenchées en fonction d’un événement. Par exemple, il est possible d’envoyer un mail à un responsable lorsqu’un certain type d’incident est signalé ;
une multitude d’options de configuration ;
une architecture modulaire.

Point faible : la complexité

l’installation n’est pas des plus aisée et demande des compétences non négligeables en informatique, il faut donc compter une bonne journée ;
l’application est gourmande en ressources, il est nécessaire de la déployer sur une machine relativement puissante avec des ressources disques et mémoire conséquentes et même sur une bonne machine, il faut prendre le temps de « Tuner » le système pour obtenir de bonnes performances ;
la charte graphique par défaut n’est pas très jolie, mais c’est un point assez subjectif ;
l’ergonomie de l’interface graphique n’est pas ce qu’ont fait de mieux en la matière. Certains écrans sont fouillis et très complexes à utiliser. De plus, les contraintes liées aux formulaires web n’arrangent pas les choses.

Toutefois, RT est le logiciel libre de référence en matière de gestion d’incidents. Il est utilisé par de nombreuses entreprises ou organisations parmi lesquelles : la NASA, Merrill Lynch, Freshmeat, Free Telecom,... (voir la liste)

Analyse des besoins et des solutions proposées

Gestion Qualité Industrielle

Les missions du service Qualité du Client sont multiples :

Alerter/informer d’une non-conformité ;
Mettre en place des actions correctives afin de remédier à ces non-conformités ;
Mettre en place des actions préventives ;
Chiffrer les coûts des non-conformités et des actions de correction et prévention qu’elles engendrent.

Cette gestion nécessite de désigner des responsables d’action et de fixer des délais de réalisation. L’ensemble de ces éléments doivent être organisés et hiérarchisés pour mieux en assurer le traitement et le suivi.

Pertinence de l’utilisation d’un système de gestion d’incident

Partant du principe qu’une gestion de non-conformité et une gestion d’incidents répondent aux mêmes principes de traitement, l’adaptation de RT à une problématique Qualité devient alors une question de sémantique.

On ne parle plus d’incident, mais de non-conformité, on ne dit plus ticket, mais fiche qualité, un incident n’est plus résolu, mais une fiche est soldée, etc.

Néanmoins, il reste pertinent (et nécessaire) de se pencher sur les spécificités du Client en exploitant le fait que RT est très personnalisable.

En effet, l’objectif est, dans le mesure du possible, d’adapter l’outil aux pratiques du Client et non de le contraindre à une logique induite par un fonctionnement trop rigide du logiciel.

Personnalisation de la solution

Adaptation du processus

Pour chaque type d’incident, une fiche est créée. Celle-ci se présente sous forme d’un formulaire permettant d’identifier l’incident et d’informer les responsables par le biais d’une liste de diffusion :

Chaque fiche donne lieu à la mise en place de plusieurs actions avec pour chacune un responsable.
Une fois l’ensemble des actions qui composent une fiche réalisée, celle-ci est soldée.
Au cours de ce processus, les utilisateurs ont la possibilité :

d’échanger des fichiers ;
de communiquer par écrit.

Le service Qualité n’a plus qu’à valider l’ensemble des actions et à exploiter les informations fournies.

Exploitation des informations

Pour exploiter l’ensemble des informations fournis, les utilisateurs disposent d’un moteur de recherche simplifié et d’un système d’extraction de statistiques : le moteur d’état.
Celui-ci permet principalement de calculer les coûts des incidents et de les afficher sous forme de tableaux :

Les problématiques techniques rencontrées et leurs solutions

Description de l’architecture du logiciel

Voici le schéma de l’architecture générale du logiciel. L’ensemble est écrit à l’aide du langage de programmation Perl.

Base de données relationnelle, le logiciel dispose d’une couche d’abstraction par rapport à la base de données grâce aux modules DBI ;
Les requêtes effectuées sur la base sont construites par le biais du module DBIx::SearchBuilder ;
Le coeur du logiciel est composé d’un ensemble de modules / classes Perl : Ticket, User, Group etc.
Au dessus de ces modules sont greffées trois interfaces :
- en ligne de commande ;
- via la messagerie, il s’agit d’un script qui fonctionne comme le programme procmail ;
- web, celle-ci est écrite à l’aide du système de modèle Mason. Il s’agit d’un framework permettant la réalisation de site web en Perl. Cette interface fonctionne de plusieurs manières (CGI, FastCGI, mod_perl) à l’intérieur d’un serveur HTTP comme Apache.

Problématiques techniques et solutions de mise en oeuvre

Le piège des « Custom Fields »

Voici la structure utilisée pour prendre en charge les champs libres dans RT :

Cette structure est inspirée par les algorithmes de persistance objet, en effet les « custom fields » sont vus comme des attributs pour les objets (Ticket, Queues, etc.).
Le principal problème de l’algorithme choisi est qu’il ne monte pas en charge, en effet il faut faire de nombreuses requêtes SQL pour obtenir la valeur d’un champ libre.
D’autres algorithmes, plus efficaces, mais plus complexes sont décrits dans le livre de référence.
Par conséquent, il ne faut pas abuser de cette fonctionnalité et limiter le nombre de champs personnalisés, dix nous semble être le maximum.
Si vous voulez étendre les attributs des différents objet, il est préférable de modifier le schéma de la base de données.

Complexité du moteur de recherche

Le moteur de recherche disponible par défaut dans le logiciel est extrêmement puissant. Il permet la création de requêtes « Ticket SQL », forme de SQL simplifiée permettant de rechercher dans la base de données. Le problème est que ce moteur de recherche est inutilisable, car trop complexe.
Un utilisateur, ne saura jamais s’en servir, même après une longue formation.
Nous avons donc récrit, un moteur de recherche simplifié. Avec un accès rapide aux recherches les plus fréquentes et un choix limité aux critères les plus importants.

Vision métier de la base de données

Le client avait besoin de voir et d’extraire les informations de la base de données. Dans un premier temps nous lui avons donné accès à la base de données du logiciel, mais cela est relativement complexe, notamment pour récupérer les valeurs contenues dans les champs personnalisés.
Pour contourner le problème nous avons mis en place un système de « View ». Celui-ci fonctionne de la manière suivante :

La base de données récupère les valeurs des champs personnalisés à l’aide d’une fonction PL/SQL, ce qui permet à l’utilisateur d’effectuer des interrogations sur les données. Les modifications sont prise en compte par une fonction.

Quelques idées d’amélioration et projets intéressants

Amélioration de l’API de récupération des objets dans la base de données

Le « framework » RT, ne propose qu’une seule fonction pour récupérer un objet dans la base de données : Load.
Il est dommage que cette fonction ne permette pas de préciser quels sont les attributs / éléments dont nous avons besoin.
Par conséquent, il arrive souvent de charger un objet complexe, comme un ticket, pour seulement en afficher un ou deux attributs.

Choix d’un autre algorithme pour prendre en charge les champs personnalisés

Une autre algorithme que celui qui est utilisé actuellement dans l’application permettrait de stocker bien plus d’informations dans les champs personnalisés.

Ergonomie

L’interface de RT est complexe et donc difficile à prendre en mains, voici quelques pistes pour rendre son interface web plus agréable :

Utilisation de requête HTTP asynchrones (AJAX)

Cette méthode est actuellement à la mode, car elle repousse les limites des possibilités offertes par les technologies du Web. Lors de la modification de RT, nous avons ajoutés de nombreuses fonctionnalités dynamiques telle que la complétion automatique, la validation lors de la saisie des formulaires, etc...
Nous pensons que l’architecture globale de l’application est bien pensée et par conséquent l’utilisation de cette méthode peut apporter beaucoup dans l’ergonomie de l’application.
Elle gomme aussi l’impression de lourdeur qui est liée à l’utilisation de formulaire web classique.

Création d’un client riche en XUL

Les fonctionnalités offertes par l’interface du logiciel sont nombreuses et les limites des technologies web se font vite sentir. L’adaptation de la technologie XUL permettrait de fournir une interface graphique riche disposant des fonctionnalités classiques telles que : les menus contextuels, le glisser/déposer et des contrôleurs complexes.
Le projet est moins ambitieux qu’il n’y paraît, il faut principalement décrire l’interface web en XUL et fournir les données (objets, et recherches) au format RDF.

Idées de projets intéressants

Fédération d’identité

Voici le scénario qui pourrait être réalisé grâce au support des spécifications « Liberty Alliance » dans RT.
« Vous êtes le fournisseur d’une entreprise, vous vous identifiez auprès de votre système d’information, puis vous vous connectez sur l’interface de gestion d’incidents de votre client pour signaler un problème. Sans aucune intervention de votre part l’ensemble des informations vous concernant sont remplies dans l’interface... ».

Pour réaliser ce scénario, il faudrait ajouter le support de la bibliothèque Lasso pour la fédération d’identité (ID-FF) et l’échange d’attributs (ID-WSF) dans RT et le faire communiquer avec un fournisseur identité, comme Authentic.

Intégration avec un PABX

Le téléphone demeure l’outil le plus exploité pour effectuer une demande. En moyenne, 46% des demandes sont réalisées par ce canal, la messagerie arrive juste derrière avec 44%. Par conséquent, si vous voulez prendre en charge le plus efficacement possible les incidents, il faut inévitablement marier ces outils : la téléphonie, la messagerie et le système de gestion d’incident.
Request Tracker, prend très bien en charge la messagerie, mais néglige le téléphone.
Le mariage entre le système de PABX Asterisk et RT semble être très intéressant .

Conclusion

Lors de la modification du logiciel RT, nous avons beaucoup appris.
Ce logiciel propose diverses fonctionnalités et peut répondre à de nombreux besoins en entreprise.
Si vous vous apprêtez à modifier votre installation ou étendre de RT, j’espère que cet article vous apportera des informations intéressantes.
Je vous conseille vivement de réfléchir sur la manière dont vous aller vous y prendre, car il suffit parfois de deux ou trois lignes de code pour complètement modifier le comportement du programme.