You are not logged in.
Bonjour,
Dans le cadre de la gestion d'un changement ou d'un incident, une date de réalisation (changement) ou de résolution (incident) sont souvent un besoin du demandeur ou de l'utilisateur.
Cette notion est d'ailleurs tres lié au concept de SLA (Service Level Agrement, ou Niveau de Service) qui fait d'ailleurs partie des concepts ITIL.
J'ai donc l'impression que pouvoir rajouter cette notion de 'date de fin', souhaitée (ou 'imposée' par un SLA) permettrai une utilisation de GLPI plus orienté fourniture de service...
Je pensais à un champs generique 'date de fin/resolution/...' qui ferait partie du formulaire de saisie de ticket.
Si la possibilité de definir/gerer des SLA etait par ailleurs integré (resolution des tickets en priorité haute, en moins de X heures, etc ...) il serait alors possible par l'utilisation des regles, de definir 'automatiquement' une date de resolution d'un ticket créé.
J'imagine d'ailleurs qu'une information particuliere (couleur speciale, alerte mail, ...) devrait/pourrait etre utilisé pour signifier qu'un ticket à dépassé sa date de reésolution maximale.
Voila, c'est ce que je vois des outils de gestions de HelpDesk chez mes clients, avec leur forces et leur faiblesse, et j'ai l'impression que c'est un des points qu'il manque à GLPI pour pouvoir leur proposer cet outils (avec la notion de workflow qui me semble t'il serait interessante aussi, par exemple, dans le cas de demande de changement ou de travaux tres procedurés).
En meme temps, je ne suis pas du tout developpeur, alors ce que je dis là, ben ... peut etre que c'est difficile à mettre en oeuvre, ou bien que ca n'interesse pas tant de monde que ca ;-)
Quoi qu'il en soit, merci pour le boulot accompli, j'adore cet outil ..!
Last edited by fouqueto (2008-08-27 09:51:24)
Offline
Oui mais ce n'est pas à l'utilisateur de gérer la durée maximale de résolution.
Pour l'automatique, c'est plus complqiué car tu peux avoir un ticket sur un serveur qui doit être résolu en 1 heure et un poste en 2 heures voire pour être plus compliqué, un autre serveur pas important pourrait être en 2 heures aussi
Offline
Je suis d'accord (quoi que tu puisse considérer l'utilisateur comme ton client, et avoir signé un SLA avec ton client) en ce qui concerne le fait que l'utilisateur ne definisse pas la durée de resolution d'un incident.
Par contre, en utilisant GLPI pour gerer des changement (en plus des incidents), une date de fin demandée doit alors pouvoir etre utilisé.
Pour aller plus loin, on pourrait imaginer :
- une date de réalistation demandé (par le demandeur du changement, donc)
- une date de réalistation proposé/planifié (par l'implementaur, donc)
- une date de réalisation effective (mais la date de cloture du ticket est OK pour ca)
En ce qui concerne la définition 'automatique' de date de résolution, avec l'utilisation des regles, et en implementant la notion de SLA, ca devient une matrice :
SLA1[Serveur Critique], SLA2[Serveur Normaux], SLA3[Poste Critique] x regle d'attribution, en fonction du materiel concerné par exemple (ou tout autre...).
Offline
Je ne peux que vous inviter à lire le wiki développeur qui contient déjà un certains nombres de réflexions sur ITIL, les SLAS etc et d'éventuellement les compléter.
JMD / Jean-Mathieu Doléans - Glpi-project.org - Association Indepnet
Apportez votre pierre au projet GLPI : Soutenir
Offline
Merci pour la réponse, je ne m'étais pas aventuré dans le wiki developpeur.
Offline