You are not logged in.
Bonjour a tous (et toutes mes excuses pour mes accents inexistants : clavier qwerty),
Ayant depuis peu commence a deployer GLPI en clientele, je me suis retrouve rapidement face a un probleme de poids : les RSI / DSI doivent rendre des comptes, l'un d'eux etant une justification des investissements faits en terme de ressources humaines au sein du helpdesk.
Pour repondre a cette problematique, je me suis bien evidemment penche sur les fonctionnalites statistiques de GLPI et travaille d'ailleurs actuellement a l'elaboration d'un dashboard synthetique dedie au superviseur presse.
Le probleme est que ce besoin de justifier le temps homme aupres du DAF ne rentre pas vraiment dans le cadre du SLA mais plutot dans celui d'une collecte du temps reellement alloue au traitement d'un ticket.
Bien sur, pour les operations planifiees, nous avons le planning, dont les entrees sont exploitees par le module statistiques de GLPI, mais quid du temps passe hors planning, generalement au helpdesk (appels et sessions de remote assistance) ?
Partant de cette question simple, je ne vois que 2 options : trouver un plugin implementant une fonctionnalite de chronometrage en temps reel des tickets, ou bien le developper moi-meme.
N'ayant pas trouve de solution existante, je serais curieux de savoir si quelqu'un a deja eu l'occasion de plancher sur ce point. Si tel n'est pas le cas, ce serait un plaisir pour moi d'en faire l'objet de ma premiere contribution active au projet.
Dans l'attente de vos retours,
Bonne soiree a tous.
Offline
'chronometrage en temps reel des tickets' ? c'est à dire? donne des exemple de ce que tu entends par là
PS : j'ai aussi un clavier qwerty et je fais des accents
Offline
'chronometrage en temps reel des tickets' ? c'est à dire?
C'est vrai que maintenant que je le relis, ce n'est pas tres explicite.
Quand je parle de chronometrage, je parle d'avoir un decompte aussi precis que possible du temps passe sur un ticket. Concretement parlant, il s'agirait d'un timer qui peut se declencher suivant differentes actions :
A la creation du ticket par le technicien (sur reception d'appel par exemple)
Lors du chargement du ticket (mais pour que cela soit fiable il faudrait distinguer 2 niveaux d'acces au ticket : consultation / modification, sinon on risque de cumuler des temps superflus)
Par activation manuelle de celui-ci, generalement au debut de toute actions diagnostique/corrective
A chaque arret du timer (quand/comment l'arrete-t'on ?), le temps decompte serait stocke en base (par enregistrements horodates ou si on veut faire plus simple sur un champ incrementable qui s'ajouterait a la table glpi_tickets, mais la premiere option me semble plus viable si on veut avoir la possibilite de faire un cacul realiste des temps de chaque technicien et aussi avoir un historique complet). Il pourra ainsi etre puisse par le module statistiques pour s'ajouter aux temps collectes depuis le planning.
Bien sur cela apporte tout son lot de contraintes en terme d'implementation mais si le concept de base te branche, on commencer a plonger dedans, j'en vois deja quelques-unes se profiler.
donne des exemple de ce que tu entends par là
Je vais te donner le seul exemple que je pratique en permanence, avec notre propre systeme de ticketing (un morceau de notre systeme cadre fait maison qui tourne sur un Domino prehistorique) :
Lorsque nous recevons un appel client, nous creons un ticket.
Instantanement, un chrono se met a tourner cote serveur.
Le chrono retourne sa mesure des que le ticket est enregistre, celle-ci est stockee (va savoir si chaque enregistrement est distinct ou s'ils sont tous cumules en base, seul notre DG le sait).
Des que nous reprenons un ticket existant, par activation d'un bouton "modifier", le chrono se remet a tourner. Il retourne son resultat et subit un reset a chaque action "enregistrer" ou "quitter & enregistrer".
Une fois le ticket clos, la facturation mensuelle du client cumule les temps generes par les chronos et ceux renseignes par les techs lors de leurs interventions sur site.
PS : Pour le qwerty, je n'ai pas encore bien appris mes ALT codes, une revision s'impose .
Offline
Bonjour,
Je me permte d'exhumé ce post car actuellement cette fonction me manque. Si besoin, je peux même financer vu que je lorgne sur la concurrence avec abonnement.
Nusa
Debian 12.5
GLPI 10.0.16
Plugins : import Fabricants; forme Creator, Oauth IMAP
Offline
Je vous propose de déposer vos spécifications détaillées dans la partie évolution : http://glpi.userecho.com/
CentOS 6.5 - CentOS 7.x
PHP 5.6 - PHP 7.x - MySQL 5.6 - MariaDB 10.2 + APC + oOPcache
GLPI from 0.72 to dev version
Certifiée ITIL (ITV2F, ITILF, ITILOSA)
Offline
Bonjour,
Et si l'on veut financer directement le projet sans attendre le vote de la communauté?
J'ai aucune notion du coût de ce genre de demande.
Nusa
Debian 12.5
GLPI 10.0.16
Plugins : import Fabricants; forme Creator, Oauth IMAP
Offline
A ce moment là il faut contacter un partenaire GLPI : http://glpi-project.org/spip.php?article297
CentOS 6.5 - CentOS 7.x
PHP 5.6 - PHP 7.x - MySQL 5.6 - MariaDB 10.2 + APC + oOPcache
GLPI from 0.72 to dev version
Certifiée ITIL (ITV2F, ITILF, ITILOSA)
Offline