see ItilProblems
see KEDB

Gantt lib :
http://roberto.open-lab.com/2012/06/14/the-javascript-gantt-odyssey/
http://gantt.twproject.com/
http://bastianallgeier.com/gantti/
http://www.phpkode.com/source/s/gantt-chart-class/gantt-chart-class/gantt.class.php
http://www.fusioncharts.com/goodies/fusioncharts-free/chart-gallery/
http://jpgraph.net/features/gallery.php
http://www.phpclasses.org/package/2737-PHP-Generate-project-progress-Gantt-charts.html
http://mbielanczuk.com/jquery-gantt/ (demo : http://jsfiddle.net/5LXAr/)

To be discussed and validated :
  • abandonned changes managed using trash ?
  • XACA : Utilisation de gabarits de demandes de changement ?
To be specified :
  • enchainement des statuts ?
  • gestion des taches
    • XACA : Un découpage en 3 phases est identifié : Plan for Updates (Authorize and Schedule Change), Co-ordinate change implementation (Includes build and test the change), Review and close change record. Donc je découperais en 4 onglets : Planification du changement (après validation) ou on pourrait visualiser le changement en entier, Phase de tests (Tâches), Implémentation (Tâches - voire pour intégrer à une possible gestion des MEP), Revue (pour clôture du changement et des éléments associés (problème, projet) ?)
  • gestion de l'approbation ?
    • XACA : La validation est importante. Le changement doit être suspendu le temps de la validation et refusé s'il n'est pas validé
  • conflits entre changements
    • XACA : utilisation des compteurs afin d’identifier les changements soumis par le même demandeur et concernant les mêmes éléments associés

A savoir

ITIL Exemple des champs liés à la documentation d'un changement

ID
Problème (ItilProblems) ou erreur connue liée (KEDB), projet
Description
objets liés au changement (CI)
Raison du changement
Risque si non application du changement
Demandeur
Date de la demande
Catégorie du changement (mineur, majeur..)
Délai prévu
Ressources
Coûts
priorité
Analyse d'impact
Plan retour-arrière
Bénéfices attendus
Validation (décision)
Commentaire de la décision
date de la décision
Plan de mise en œuvre
Planification de l’implémentation
tâches liés à implémentation
Revue des dates
Revue du résultat
Clôture

Implementation

A change :
  • Name
  • Content
  • Notes
  • entity + recursivity
  • Category (as for tickets)
  • Status : new, evaluation, approbation, pending, process (sub status : test, qualification, applied), review, closed, abandoned
  • Urgency, priority, impact (as for tickets)
  • Assignment (as for tickets) permit to set supplier ? : do it in tasks ?
  • Requester (as for tickets)
  • Recipient (as for tickets)
  • Dates : create, close, due
  • Task management (same ticket or more complex ?) : see projet plugin
    • more complex : name, type, state, % done, estimated time, consumed time, estimated cost, real cost, budget ?, father tasks, person in charge, assigned to (users, groups, supplier), comments, planification. May attached docs,
    • Tasks may be part of several changes
  • Solution (same ticket)
  • Analysis ? : impact, control list ?
  • Hardware linked ?
  • Roll Out Plan, Backout Plan, Check list ?
  • From projet :
    • Parent change
    • % Done
    • show on Gantt diagram
A task (from projet) :
  • Name
  • Type
  • State
  • Parent task
  • Blocked by childs ?
  • priority
  • % done
  • description
  • assign to : user / group / supplier
  • begin / end / actiontime / include in planning ?
  • show on Gantt diagram
  • autres participants : champ texte ? a garder ?
  • personnes affectées : champ texte ? a garder ?
Linked items :
  • tickets
  • problems
  • Documents
  • Approval : define the users (from CAB list / specific group ?)

-----
Conclusion séminaire :

Changement

  • Nouvel objet "Demande de changement"
  • Onglet principal :
    • Nom
    • Récursif
    • Description
    • Catégorie
    • Status (not really the same as tickets) : new, evaluation, approbation, process (sub status : test, qualification, applied), review, closed, abandoned
    • Urgence, priorité, impact
    • Assignation personne
    • Assignation groupe
    • Auteur
    • Demandeur
    • Date création, date de clotûre, date d'échéance
  • Incidents : liste les incidents/demandes de service attachés au changement
  • Problèmes : liste les problèmes attachés au changement
  • Documents
  • Evaluation
    • liste d'objets de GLPI impactés
  • Planification : tâches -> cf plugin projet
  • Approbation (utilisateur / groupe / multiple, etc) : aussi bien pour l'approbation de l'évaluation que pour la mise en production de celui-ci
  • Revue : la revue post-implémentation -> ensemble des tickets liés à la mise en production du changement
  • Résolution : permet de la clotûre par le client de la demande de changement
  • Est ce qu'on gère les budgets et coùts associés aux tâches ?

Catégories

Hypothèse 1 :
  • Les catégories de RFC sont les mêmes que celles des demandes de service
Hypothèse 2 :
  • Les catégories sont indépendantes de celles des problèmes et demandes de service

Le comité d'approbation

Hypothèse 1 :
CAB = Groupe GLPI

Hypothèse 2 :
CAB = objet séparé

Statuts d'un changement

  • Nouveau (Enregistré)
  • Evaluation : prépare une mesure d'impact sur le business du client, sur l'infra, sur les conséquences d'une non mise en oeuvre, sur l'orga, et l'évaluation des ressources permet de déclarer la demande comme évaluée
  • Approbation (en cours): demande soumise à une approbation multiple au(x) CAB (financière, technique, business, organisationnelle)
  • Réalisation : le changement a été construit, et peut être soumis aux tests
    Les 3 statuts suivants dépendent de l'avancement des tâches de ce type
    • Test : changement testé sur les aspects fonctionnels et exploitabilité
    • Qualification : changement accepté par le client après validation des tests
    • Mis en production / appliqué : changement mis en place avec accord du client
  • Revue en cours : après un temps défini de fonctionnement dans l'environnement de prod, le changement est évalué au travers d'une revue post-implémentation
  • Clos : la revue post-install a été déclaré satisfaisante. demande cloturée avec l'approbation du client
  • Abandonné : demande de changement abandonnée par le client

Impact, Urgence & Priorité

  • Reprise des mêmes valeurs que dans la gestion des incidents

Tâche

  • Nom
  • Type de tâche
  • % effectué
  • temps estimé
  • temps consommé
  • coût estimé
  • coût réel
  • taches parentes (possibilité de choix multiples)
  • Responsable
  • Attribué à Utilisateur / Groupe / Fournisseur
  • Documents
  • Commentaires
  • Planification ?

Possibilité de faire des tâches communes entre plusieurs changements.

Evolution des droits

  • faire une demande de changement (client / demandeur)
  • gérer les changements (gestionnaire)
  • XACA : valider un changement ?

Création d'une demande de changement

  • Utilisation des gabarits = demandes standards
  • Demandes non standards = création d'une demande sans passer par un gabarit
Création :
  • une demande de changement qui ne résulte de rien
  • via modif massive sur tickets ou problèmes
  • depuis un onglet d'un ticket ou d'un problème

Revue

  • Un changement ne peut passer à l'état "Revue" tant que toutes les tâches ne sont pas fermées.
  • Si le changement est lié à une tâche dans un autre changement, le passage en "Revue" de celui-ci entraine la fermeture de la tâche associée.
  • Si des problèmes sont liés à un changement, le passage à l'état "Revue" entraine l'ajout d'un suivi dans les problèmes

Notification

  • Ajout des notifications sur les modifications d'état du changement