Vous n'êtes pas identifié.
#1 18-03-2009 17:18:48
- fabien
- Manager
- Date d'inscription: 11-02-2009
- Messages: 47
Justifier la gestion des changements
Lorsque nous expliquons l'intérêt de mettre en place un processus de gestion des changements, nous citons des exemples de changements non contrôlés ayant généré des catastrophes.
L'un de mes préférés est celui-ci :
Bug informatique pour l'assurance maladie
10 millions d'euros ont été versés par erreur à des cliniques privées à la suite d'un bug informatique dans le système de traitement des caisses d'assurance-maladie.
Le Parisien a révélé que le logiciel de la Caisse d'Assurance Maladie, mis en place en 2001, a eu des ratés coûteux. Le logiciel de télétransmissions qui permet aux professions médicales (Médecins, Kiné, infirmière, ...) d'envoyer les feuilles de soin, sans passer par le mode papier, a remboursé, deux fois certaines cliniques. Pierre Fender, directeur de la répression des fraudes de la Sécurité sociale, cité par le Parisien, estime que «le montant total des doubles paiements effectués alors par erreur par les caisses d'assurance maladie aux cliniques est bien de 10 millions d'euros». Certaines cliniques ont déjà commencé à rembourser, mais que d'autres ont mis l'affaire devant les tribunaux.
Avez-vous d'autres exemples amusants ? 
Fabien - Tournai
ITIL Service Manager
Hors ligne
18-03-2009 17:18:48
- AdBot
- AdSense
#2 18-03-2009 17:29:44
- fabien
- Manager
- Date d'inscription: 11-02-2009
- Messages: 47
Re: Justifier la gestion des changements
Plus proche de nous, cet autre exemple :
Un jeune chef de projet embauché chez un grand distributeur spécialisé a pour première mission de modifier le format des étiquettes de facing afin d'afficher le prix en euro en plus du prix en francs. Il y a 7 types étiquettes différents. Il s'acquitte consciencieusement de sa tâche, et même un peu plus : tous les codes articles sont affichés verticalement pour prendre moins de place, sauf celui de la grosse étiquettes A4, qui est affiché horizontalement, et dans une autre police en plus ! Son sang de cartésien ne fait qu'un tour, et il réaligne derechef le code article indiscipliné ! Ce petit changement ne sera pas signalé à son client, c'est le petit cadeau bonus de l'informaticien 
Quelques mois plus tard, les incidents commencent à remonter : pas moyen de lire le code article sur les étiquettes pour la moquette. Il faut toujours monter sur l'échelle. Les fameuses étiquettes A4 étaient utilisées pour les hauts de rayon, et massivement en période d'inventaire !
Le mieux est l'ennemi du bien !
ps. je demande sincèrement pardon à tous les chefs de rayons qui ont eu à souffrir de mon excès de zèle
Fabien - Tournai
ITIL Service Manager
Hors ligne
#3 19-03-2009 08:37:40
- yvmarchand
- ITIL guru
- Date d'inscription: 24-11-2008
- Messages: 82
Re: Justifier la gestion des changements
Un exemple lointaint vu dans la grande distribution.
Un developpeur modifie un calcul de taux de TVA. Il passe rapidement cette modification en production. C'est bien un besoin client mais il n'y a pas de changement ni de concertation avec le client ou la DSI.
Pas de chance, la modification se plante. Résultat toutes les lignes de caisses des hypers et supers marchés du groupe sont HS le lendemain matin.
Résultat, toutes les lignes de caisses seront HS une journée, la moitiée seront opérationnelles au bout de 2 jours et l'ensemble sera opérationnel au bout d'une semaine. Dommage colatéral, le développeur a été viré 3 jours après sa mise en production.
Cdlt,
Yves
Hors ligne
#4 19-03-2009 16:38:14
- fabien
- Manager
- Date d'inscription: 11-02-2009
- Messages: 47
Re: Justifier la gestion des changements
Si je développe cet exemple :
- Le développeur aurait dû effectuer une demande de changement
- Dans le cas le plus extrême cette demande aurait été classée en pré-autorisée, mais une alerte aurait été déclenchée car le processus (supporté par un outillage adapté) aurait décelé un lien entre le composant impacté par le changement (calcul du taux de TVA) et un composant "critique" (la ligne de caisse). De plus, le développeur aurait été forcé d'indiquer le type de communication client, la nature des tests, le plan de mise en oeuvre (pas de site pilote). Ces deux éléments auraient au minimum incité le développeur à se poser les bonnes questions.
- Dans le cas général, le changement aurait été identifié comme "significatif" : impact potentiel maximum (toutes les lignes de caisse, changement apparemment anodin mais tests et pilote peu significatifs), et urgence forte (composante légale). Il aurait été traité par une instance de décision indépendante (contrôleur ou CAB) du développeur.
Quant au dommage collatéral, il suppose que le process de gestion des changement existait et qu'il était connu de tous. Ou que le développeur était un sous-traitant 
Fabien - Tournai
ITIL Service Manager
Hors ligne
#5 19-03-2009 17:32:55
- yvmarchand
- ITIL guru
- Date d'inscription: 24-11-2008
- Messages: 82
Re: Justifier la gestion des changements
fabien a écrit:
- Le développeur aurait dû effectuer une demande de changement
- Dans le cas le plus extrême cette demande aurait été classée en pré-autorisée, mais une alerte aurait été déclenchée car le processus (supporté par un outillage adapté) aurait décelé un lien entre le composant impacté par le changement (calcul du taux de TVA) et un composant "critique" (la ligne de caisse). De plus, le développeur aurait été forcé d'indiquer le type de communication client, la nature des tests, le plan de mise en oeuvre (pas de site pilote). Ces deux éléments auraient au minimum incité le développeur à se poser les bonnes questions.
Tout a fait.
Il n'y a pas eu (ou pas vraiment) de test. De plus, pour l'entreprise en question il était habituel de passer en production via des pilotes de + en + gros (1magasin, 5magasins, 50magasins, puis géné).
Depuis, l'entreprise a mis en place un processus de changement. Pas à cause de ce dysfonctionnement mais dans le cadre d'un approche ITIL plus globale
Cdlt,
Yves
Hors ligne
#6 19-03-2009 17:34:47
- yvmarchand
- ITIL guru
- Date d'inscription: 24-11-2008
- Messages: 82
Re: Justifier la gestion des changements
fabien a écrit:
Quant au dommage collatéral, il suppose que le process de gestion des changement existait et qu'il était connu de tous. Ou que le développeur était un sous-traitant
C'était un presta .... donc la procédure a été très rapide une fois le "fautif" et la solution identifié il a fait ses cartons 
Dernière modification par yvmarchand (19-03-2009 17:35:04)
Cdlt,
Yves
Hors ligne
#7 23-03-2009 21:06:08
- chtitil
- Practitioner
- Date d'inscription: 22-11-2008
- Messages: 18
Re: Justifier la gestion des changements
fabien a écrit:
Si je développe cet exemple :
- Le développeur aurait dû effectuer une demande de changement
- Dans le cas le plus extrême cette demande aurait été classée en pré-autorisée, mais une alerte aurait été déclenchée car le processus (supporté par un outillage adapté) aurait décelé un lien entre le composant impacté par le changement (calcul du taux de TVA) et un composant "critique" (la ligne de caisse). De plus, le développeur aurait été forcé d'indiquer le type de communication client, la nature des tests, le plan de mise en oeuvre (pas de site pilote). Ces deux éléments auraient au minimum incité le développeur à se poser les bonnes questions.
- Dans le cas général, le changement aurait été identifié comme "significatif" : impact potentiel maximum (toutes les lignes de caisse, changement apparemment anodin mais tests et pilote peu significatifs), et urgence forte (composante légale). Il aurait été traité par une instance de décision indépendante (contrôleur ou CAB) du développeur.
Quant au dommage collatéral, il suppose que le process de gestion des changement existait et qu'il était connu de tous. Ou que le développeur était un sous-traitant
Si le développeur avait juste testé .... ??
Cela pour dire que les éléments du processus de gestion des changements s'appuient sur une organisation rodée. Ce n'est pas le processus qui détermine l'organisation ...
En y réfléchissant, un développeur capable de mettre en prod en direct (et non testé), c'est significatif de l'état de l'organisation (qui a les développeurs qu'elle mérite) ? Non ?
A bientôt ..... ;-))
Hors ligne