4 jours et 2 nuits de déploiement

Tycho's Supernova Remnant: Tycho's Remnant Provides Shocking Evidence for Cosmic Rays (The hot, expanding debris of a supernova observed in 1572.)

Les 4 derniers jours de 2009 nous avons déployé notre progiciel de gestion intégré ALIX dans le dépôt principal de l’un des grossistes majeurs en pharmaceutiques en Tunisie. C’est une opération pour laquelle nous nous sommes préparés toute notre vie… Ou presque, étant donné qu’au décompte final le projet a duré 3 ans et demi. Pour aboutir a ce déploiement qui consacre ALIX comme seul système d’information dans toute l’entreprise et sonne le glas de tous les autres logiciels utilisés de la production au recouvrement.

Une semaine avant…

Je venais de rentrer de Beirut, et ce weekend nous avions un inventaire dans le petit dépôt du client. Le système ALIX était déjà en production depuis plus d’un an dans ce dépot, mais c’est toujours délicat un inventaire. Parce que justement c’est 1 fois l’an et que par conséquent on n’a pas souvent l’occasion de le tester en production. De plus, suite au dernier inventaire nous avons fait des modifications majeures sur le système et aux procédures; et c’était donc du code frais que nous allions utiliser.

Tout s’est bien passé. L’enjeu principal dans les inventaires, qui restent sommaires au niveau applicatif, c’est le temps. Ce jour là nous avions fini plus tôt que prévu. Ce qui nous réconfortait dans nos choix et nous rassurait sur le plus important : le déploiement final dans le grand dépôt dont la date n’était toujours pas fixée mais qui était imminent.

Etant donné que nous avions fini tôt, M. Bechir qui supérvise le projet ALIX pour notre client, improvise une petite réunion. Il nous éxplique qu’il est satisfait et qu’il propose de déployer la semaine prochaine dans le grand dépot. Nous allons faire le déploiement dans les règles de l’art au début de l’année fiscale, ce qui avait l’avantage de limiter de façon radicale le risques de géstion liés au changement de système en cours d’annèe fiscale et d’intègration de données à partir de l’ancien système (forcément).

Avec Bechir et Hassen (l’équipe ALIXSYS, au cas ou vous seriez nouveau sur ce blog. Par ailleurs, ne pas confondre Bechir avec M. Bechir le client) nous avions déjà discuté de cette éventualité et avons conclu que nous étions préts. J’ai donc accépté.

Or rien n’était prêt. Les stations de travail et leurs périfériques qui devaient étre changés n’étaient pas inventoriées, le matériel n’était pas encore commandé, le chantier du réseau avait à peine commencé et il fallait encore des semaines pour qu’il se termine.

Heureusement qu’avec ce projet, j’avais appris quelque chose d’essentiel : le zen. Les choses se passent toujours mieux que prévu… si on se prépare pour le pire. Le truc c’est de ne pas essayer d’éviter le pire, il faut économiser ses éfforts pour être prêt quand le pire arrivera. J’ai donc proposé de déployer sur le réseau en place avec le matériel en place. Le raisonnement était qu’il est trop tard pour organiser quoi que ce soit qui implique une étude ou ne serait ce qu’une simple réflexion : nous allions mettre en place le matériel essentiel, c’est a dire les 2 imprimantes industrielles et stocker des stations de travail et des périphériques de rechange prêts a être déployés dés qu’il y a un problème matériel quelque part dans le dépôt.

Makram, le responsable informatique du client, n’était pas d’accord. Il n’y avait rien à faire pour le réseau, mais pour le côté matériel il estimait qu’il était possible d’inventorier les machines dépassées, les remplacer et switcher toutes les stations de travail sous Linux la nuit de l’inventaire. Et comme tout ce volet est sous sa responsabilité, il avait le véto. Nous allons donc faire comme il dit. Et nous allons voir qu’il avait raison.

La semaine suivante je l’ai passée a préparer 3 checklists : 1 pour l’inventaire, 1 pour le déploiement et 1 timeline. Ce travail a consisté a tester le système pour les cas d’utilisation de l’inventaire et du déploiement et faire une liste des points a vérifier et les taches a faire pour que tout se passe bien. Ensuite ces points sont discutés avec Hassen et Bechir qui enrichissent la liste avec leurs remarques. Nous avons fait cela tous les jours pendant toute la semaine. La timeline était subdivisée en 4 jours et etait mise a jour au fur et a mesure avec les taches qui devaient se faire un jour précis. Bechir et Hassen s’occupaient de régler les problèmes qui pouvaient être réglés tout de suite : certains détails de la procédure de déploiement pouvaient être réglés par des changements sur les application, notamment l’application d’intégration de données avec les anciens logiciels. A vrai dire il y a des défauts que nous avons découvert à ce moment là et qu’il fallait régler aussi.

1 pour le déploiement, 1 pour l'inventaire et 1 timeline

Week-end de l’inventaire : problèmes d’intégration de données

L’inventaire devait se faire le week-end, comme tous les ans, pour ne pas impacter la production. Le vendredi nous avons commencé a préparer le système, y compris les personnes en leurs donnant les instructions nécessaires. Les procédures d’inventaire se basaient principalement sur du papier mais avaient significativement changé et impliquaient maintenant plusieurs utilisateurs du système dans la saisie et le contrôle du déroulement en temps réel.  Nous avons fait en sorte que l’encadrement des utilisateurs soit fait par le personnel de l’entreprise qui est déjà formé. Le but étant qu’on soit disponible en cas de problème. On ne ferait donc rien. Et ça sera très bien comme ça. Et nous n’allons pas tarder a confirmer l’utilité de cette approche.

L’inventaire commence par le décompte des quantités physiques des articles en stock et se finit par leurs comparaison avec les quantités informatiques (prévues). Pour pouvoir commencer le décompte le plus tôt possible (lundi matin étant une date butoir : reprise d’activité) , nous avons choisi de faire une intégration des données en deux étapes. Nous allions intégrer les données des articles a partir de l’ancien logiciel de stock vendredi soir (ils ne risquaient pas de changer) et les données de l’état des stock samedi quand il n’y aurait plus d’activité dans le dépôt.

Samedi matin on vient, on fait rien, aucun problème. Samedi après midi, on intègre les données de l’état des stock et BANG! Nos états de vérification nous disent que les données intégrées ne correspondent pas aux informations données par l’ancien système. On a bien fait de rester disponibles. On a bien pensé que le bug serait facile a trouver au début,… à 1h du matin on était encore au bureau. Et vous savez le PC DOS virtualisé qu’on avait mis en place il y a presque 1 an pour convertir les listings de l’ancienne application? Eh bien, il nous a encore sauvé la vie. Après inspection minutieuse, il y avait au moins une dizaine de différences de plusieurs types dans les articles. Tous des problèmes d’intégration, aucun bug, et parfois des erreurs de jugement : dans le paragraphe précédent j’ai dit « ils ne risquaient pas de changer », eh bien ils ont changé les prix des articles.

Le dimanche matin, nous étions là. L’état du stock informatique intégré a partir de l’ancienne application était conforme et vérifié. Tout allait bien. Dans ma timeline, je vois : « dimanche : Installer le matériel de déploiement ». Étant donné que Makram avait décidé de switcher toutes les stations de travail à Linux, ça allait être le grand soir. L’après midi l’inventaire était bouclé sans incidents, ce qui représentait un temps légèrement inférieur aux inventaires pratiqués avec l’ancien système. Les utilisateurs directs et indirects étaient satisfaits. Le soir nous étions très fatigués nous sommes arrivés a installer tout le matériel, a convertir presque toutes les stations de travail à Linux et les configurer pour qu’ils se connectent sur l’application web ALIX. A vrai dire Makram et Hassen on fait presque tout le boulot. Nous avons désigné Bechir pour venir le lendemain a 6h du matin pour le déploiement : c’est à cette heure là que commence l’activité. Il fallait que quelqu’un se dévoue.

Bechir est capable d'analyser l'output d'une requête SQL en temps réel. Comme dans Matrix.

Premier jour d’utilisation : 1 processus et 2 interfaces utilisateur changées à chaud

Le 1er utilisateur du système fut M. Hmida, opérateur du centre d’appel qui commence sa journée à 6h du matin. Quand il a débarqué le paysage du dépôt avait complètement changé, sur sa station de travail aussi. Bechir était là pour le rassurer. Le premières commandes furent livrées sous la surveillance de Bechir, et en toute sérénité. C’est vers 9h quand tout le monde a débarqué, y compris Hassen et moi même, que les choses ont commencé a se corser.

Le serveur a commencé a échouer la baleine (en argot geek, ça veut dire avoir des problèmes de surcharge. voir Fail the whale). Le système était a la limite de l’inutilisable. C’était le bordel. Les commandes partaient en retard, le contrôle qualité était fait à l’emporte pièce. C’était le bordel.  Ça nous a pris 1 heure pour diagnostiquer le problème : 1 tableau de bord utilisé par ~50% des utilisateurs, notamment par les contrôleurs qualité,  bouffait les ressources comme pas possible. Réunion de crise : mesure d’urgence : rallonger le temps de rafraichissement des indicateurs. Ensuite discussion :

  1. Cette interface est irrécupérable. Elle doit afficher les commandes en cours avec leurs états en temps réel. Autant dire toute l’activité du dépôt. Elle traite énormément de données et on aura beau optimiser, on ne gagnera pas beaucoup et ça prendra du temps.
  2. Cette interface est utilisée par deux rôles dans le système : les contrôleurs qualité (en large majorité) et 8 magasiniers
  3. Les contrôleurs qualité (CQ) n’utilisent en fait qu’une seule fonctionnalité de l’interface et qui ne consomme pratiquement aucune ressource

En 15 minutes nous avons fait une nouvelle interface pour l’armée des CQ, en 15 minutes nous l’avons testée, en 15 minutes nous l’avons déployée, en 30 minutes nous les avons formés. Ce sont les joies du MVC et de l’architecture RESTful. Ce fût une réussite : la charge du serveur est tombée de moitié. Les CQ ont même préféré cette interface, évidemment : elle est plus simple.

Si nous avons pu faire cette interface aussi rapidement, c’est qu’elle fait partie d’une catégorie de tâche que nous avons classée dans notre wiki dans : « Les tâches que nous n’aurons jamais le temps de faire ». Nous avions bien identifié un problème d’ergonomie dans cette interface (les CQ n’utilisaient que 0.1% de cette interface), nous avions bien discuté et trouvé une solution élégante, mais rien ne justifiait de leurs faire une interface propre jusqu’à maintenant. Parce que l’ergonomie n’est pas une science exacte et :

  • Nous n’avions reçu aucun feedback négatif de la part des utilisateurs (testeurs)
  • Du point de vue de l’expérience utilisateur, plus il y a d’utilisateurs qui utilisent une interface, mieux c’est. Ils s’entre-aident. C’est l’effet communauté. C’est pour cela que je pense, par exemple, que les interfaces personnalisées sont généralement mauvaises du point de vue de l’expérience utilisateur.

Hassen en vitesse de croisière

Changer les procédures au nez et à la barbe de ISO9001

Le système était redevenu utilisable, d’autant plus que l’heure de pointe pour l’activité est passée. Tout allait bien, ou presque… Malgré le fait que ALIX fonctionnait bien, les commandes continuaient à prendre un léger retard. A première vue, ça bloquait au niveau de la préparation des commandes. Une petite inspection sur place pour prendre le pouls des utilisateurs, à permis très vite d’identifier le problème. La procédure était trop lourde et les commandes s’accumulaient au milieu du magasin.

Par rapport au petit dépôt sur lequel ALIX s’était fait les dents, ce dépôt si est énorme. Il est subdivisé en 8 zones, dont 3 sont contiguës et numérotées 1,2,3.  La procédure imposait une validation au début et a la fin de chaque zone. Mais voilà, le zones 2 et 3 étaient dépendantes de la zone 1 : on ne pouvait commencer la zone 2 qu’après avoir fini la zone 1. Ce qui fait que dépendamment des commandes, le magasinier  de la zone 2 pouvait terminer une commande et revenir au début de sa zone pour se retrouver avec 5 commandes en attente et d’autres qui arrivent (ça peut prendre beaucoup de place). Ce qui ajoute a la confusion c’est qu’il doit aussi gérer se propres priorités et renseigner le système. Ce n’était clairement pas faisable. Et les commandes s’accumulaient en zone 2.

Ce qui est incroyable c’est que cette procédure était en place depuis des années et était même documentée et certifiée ISO9001, mais l’ancien système de gestion de flux – développé par nous mêmes d’ailleurs. Une ancienne version de ALIX – permettait de la contourner. Ils validaient toutes les zones qui restent à la fin de la journée!!

Réunion de crise : mesure d’urgence : faire sauter la zone 2. Après avoir discuté des conséquences possibles, nous avons simplement dit au magasinier de la zone 2 d’ignorer le système et de faire juste son travail de préparation des commandes. Ensuite nous avons fait sauter quelques verrous par ci, par là, et nous avons entrepris de changer l’interface des magasiniers pour que ces trois zones se comportent comme une seule zone dans certains cas. Et tant pis pour ISO90001, il suivra. Cette dernière tâche prendra le reste de la journée et le lendemain matin.

La magie

Le lendemain la magie à opéré. Malgré le fait que le serveur continuait a faire des pics de charge a 10 (normalement le maximum c’est 1) tout marchait, les utilisateurs – bizarrement – ne se plaignaient pas, et les commandes étaient traitées au rythme normal comme si de rien n’était. Nous n’en revenions pas. On est restés sur nos gardes toute la journée, mais rien.

Bien sûr, il y avait encore plein de choses à faire, une longue liste de défauts a corriger, des fonctionnalités a ajouter, mais il n’y avait plus le bordel. Il faut comprendre que le plus grand défi dans un projet qui implique autant de personnes est logistique et organisationnel. Si la sauce ne prend pas, vous aurez beau faire, le projet sera un échec. Le utilisateurs sont inter-connectés procéduralement, si une partie refuse d’utiliser le système parce qu’elle estime qu’il est inutilisable, vous n’aurez pas le temps de corriger le problème avant qu’une autre partie n’arrête de l’utiliser parce que son utilisation du système dépend de la première.

J’avais planifié 2 jours de bordel, et ça s’est résolu en 1 jour. J’estime que c’est un succès notable. Mais pour rendre a césar ce qui appartient à césar, ce succès n’est pas le nôtre, c’est celui de l’entreprise qui a commandé le projet avec tous ses employés et ses gestionnaires que je tiens a remercier particulièrement. A vrai dire mon impression est que toutes les conditions du succès étaient là avant qu’on arrive.

No comments yet

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :