Contexte

Lors d’une récente mission dans une compagnie d’assurance internationale, j’ai eu le plaisir d’accompagner plusieurs équipes dans la mise en œuvre d’une obeya sur des projets de mise à jour de serveurs applicatifs. Au total, quatre équipes de six ou huit personnes chacune étaient embarquées dans l’obeya ayant pour objectif de traiter l’obsolescence des serveurs par la mise à jour des Systèmes d’Exploitation – OS, des Bases de Données – BD,  et par le cryptage de certaines données (fichiers, tables…). Les équipes étaient composées de représentant métier, chef de projet MOE, chef de projet exploitation, architectes, DBA, ingénieur système, experts sécurité, consultants externes… Le système d’information de cette grande entreprise comporte plusieurs milliers de serveurs dont la robustesse, la disponibilité et la sécurité doivent être renforcées en traitant l’obsolescence notamment grâce à ces projets. Bien que lancés depuis plusieurs années, les projets avaient été suspendus puis relancés plus récemment dans le contexte législatif de GDPR.

En démarrant la mission, j’ai rapidement compris que l’équipe n’avait pas les idées claires sur les grandes étapes pour pallier à l’obsolescence des serveurs et surtout que personne n’était vraiment d’accord sur les principales étapes et qui en était responsable. Les choses étaient encore moins claires sur le détail de chacune des activités, le temps d’exécution de chaque étape (par exemple : combien de temps prend le cryptage d’une BD de 1 To sur MariaDB, quel est l’impact sur les performances en lecture, en écriture…), les prérequis nécessaires et enfin qui fait quoi dans le process. Chacun avait son point de vue sur les actions qu’il devait réaliser mais personne n’avait la vue globale sur l’ensemble du processus.

Etape 1: apprendre à livrer manuellement une première « bonne pièce »

Plutôt que de se lancer dans un interminable diagramme type RACI (Responsible Accountable Consulted Informed), je leur ai demandé de représenter sur des posts-its les macro-étapes sur lesquelles il y a un début de consensus. Sur cette base minimaliste, nous nous sommes alors lancés dans notre première cérémonie hebdomadaire d’obeya avec chacune des 4 core-teams (core team = équipe d’experts / opérationnels réunis dans la salle d’obeya pour produire ensemble).

J’ai alors demandé aux équipes de se fixer un premier objectif atteignable: le Minimum Viable Product – MVP #1. Le principe du MVP est d’une part d’apporter le plus rapidement possible de la valeur au client interne en livrant une première version du produit sur laquelle il pourra nous faire un feedback (limiter effet tunnel) et d’autre part de permettre à l’équipe d’apprendre à produire ensemble. En Lean, on parle aussi de première bonne pièce, sorte de validation que le processus imaginé fonctionne et délivre le produit attendu.

Ici notre MVP #1 est volontairement simple, il est composé d’un seul serveur Redhat hébergé sur une unique machine physique. L’objectif est de le livrer en 2 semaines soit 10 jours ouvrés.

Résultat: 1 mois plus tard le MVP #1 est livré. Un premier serveur est OK mais avec 2 semaines de retard.

Lorsque nous interviewons le client (représentant du métier) via l’outil Lean de la Voix du Client, ce dernier nous fait comprendre qu’il a trouvé cette première itération assez laborieuse ! Il a été sollicité six fois pour des plages d’arrêt/redémarrage et a dû réaliser quatre recettes différentes suites aux différentes opérations, enfin l’indisponibilité du serveur a été de quatre jours au total ce qui les a pénalisés lors d’une recette en cours.

Au niveau des équipes, le diagramme spaghetti ci-dessous met en évidence les nombreuses difficultés et obstacles que l’équipe a rencontrés (le diagramme spaghetti est un outil Lean qui permet de montrer visuellement les gaspillages vécus par les personnes lors de l’exécution d’un processus). Durant cette première étape, il y a même eu quelques tensions car certains collaborateurs n’étaient pas d’accord sur les prérequis à l’opération de mise à jour ainsi que sur le formalisme précis de ces prérequis (ex : mail versus ticket, PDF versus document Word…)

Sur le premier mois, l’équipe a tout de même résolu 37 problèmes (12 éradiqués et 25 en cours) via la technique du PDCA (Plan Do Check Act). Véritable moteur de l’amélioration continue au sein de l’obeya, le PDCA permet de développer l’expertise de l’équipe qui apprend à résoudre elle-même ses problèmes et lève un à un les obstacles rencontrés. Ces résolutions de problèmes sont partagées avec toute l’équipe : chaque porteur de PDCA le présente à l’occasion de la cérémonie hebdomadaire à la core-team.

Malgré toutes ces difficultés et un client interne moyennement satisfait, l’équipe a  réussi à livrer son premier serveur et c’est un premier succès. Certes, les pistes d’améliorations sont immenses mais l’équipe a réussi à livrer son MVP et en a tiré de nombreux apprentissages :

• une première version de son process : six grandes étapes avec une dizaine d’activités pour chacune des étapes ainsi qu’une mesure du temps passé sur quelques étapes clé, ce processus est bien entendu affiché sur le mur de l’obeya.

• quatre standards de travail sur les opérations clés : liste des prérequis (versions, date dernier redémarrage du serveur…), mode opératoire du geste de mise à jour (arrêt de la BD, backup des tablespaces, commande pour crypter les tablespaces avec une clé…
• trois checklists : comment m’assurer du cryptage des données, conditions avant de lancer les tirs de charge…
• une abaque sur l’impact du cryptage des données: impact sur les performances en lecture, en écriture, sur la taille des filesystems…

Etape 2: une première accélération du delivery

Fière de ce succès mais avec la farouche intention de s’améliorer pour la prochaine itération, l’équipe décide de se lancer dans un deuxième MVP. Ce MVP #2 comporte cette fois dix serveurs virtualisés (contre un seul pour le 1er MVP) sur deux serveurs physiques (un serveur pour le MVP #1).  Elle se fixe pour objectif un délai de deux semaines en ne sollicitant que deux fois le métier pour les plages d’intervention.

Nous commençons par construire le produit correspondant à ce MVP #2 sur le mur de l’obeya afin de que toute l’équipe soit alignée sur le scope à réussir dans deux semaines. On construit ainsi un panneau avec les différentes Virtual Machines – VM, bases de données, les serveurs physiques, les versions d’OS/Middleware, les tailles des tablespaces… A cette occasion, l’équipe découvre que deux BD installées sur l’un des quatre serveurs ne sont pas dans le scope du MVP #2. De plus ces deux BD concernent une autre application avec d’autres interlocuteurs métier. Il faudra donc veiller à les exclure et informer le métier lors d’éventuel arrêt/relance des serveurs.

Ensuite, à partir du process du MVP #1, l’équipe construit une nouvelle version du process de mise à jour des serveurs : mutualisation de certaines activités afin de moins solliciter les métiers (par exemple: sur les plages d’arrêts / relances de BD et phases de recette), suppression d’étapes inutiles (par exemple: certaines corrections peuvent être réalisées à chaud sans impact applicatif).  L’équipe a encore bien en tête les apprentissages du MVP #1: les feuilles A3 des PDCA sont encore présentes sur les murs.

Le nouveau process est prêt: une étape et de nombreuses sous-activités ont été supprimées/mutualisées.

L’équipe représente sur le panneau macro-plan de l’obeya le jalon final dans deux semaines pour livrer ce MVP #2 et s’accorde sur les opérations à réaliser dans le panneau micro-plan jour par jour en parcourant le process : préparer les scripts, fournir les prérequis techniques, préparer les tirs de charge, planifier les plages d’intervention, recette métier après l’opération… Chacun sait quel geste il doit réaliser, quel est le livrable attendu et sur quel standard ou check-list il peut s’appuyer.

Résultat : deux semaines plus tard, l’équipe a livré le MVP #2 et cette fois le client interne est satisfait !

L’équipe a donc amélioré son process et a éprouvé les différents standards et check-lists précédemment rédigés. Elle a aussi scripté certaines opérations réalisées manuellement lors du MVP  #1 : par exemple, l’opération de cryptage des données a été intégralement scriptée.

L’équipe a tout de même rencontré quelques aléas. Par exemple, le script a effacé le Wallet qui contenait certains accès à l’OS… Il a donc fallu réparer et prendre en compte la sauvegarde du Wallet dans le script. De plus, les deux serveurs hors scope ont malgré tout été partiellement impactées.

Pour cette deuxième  itération, nous n’avons pas construit le diagramme spaghetti mais l’équipe est passée de +200 échanges mails (MVP #1) à quelque dizaines de mails sans aucune escalade managériale ni tension au sein de l’équipe.

Conclusion

L’équipe a indéniablement progressé et a beaucoup appris sur son process de delivery mais elle devra encore accélérer sur le MVP #3 qui permettra d’introduire une plus grande volumétrie. En effet, il reste encore du chemin à parcourir pour être au « rythme du client ». En cible,  ils devront être en mesure de livrer plusieurs serveurs par jour !
Ce rythme ne pourra être atteint que lorsque le process sera réellement industrialisé, c’est à dire: standardisé avec le bon niveau de qualité, composé d’étapes stables et bien décrites, le tout au niveau de coût attendu. Cela nécessitera que le process soit mis en flux et qu’il délivre au takt – principe Lean qui consiste à livrer au rythme du client-. Cette mise en flux permettra de révéler les problèmes et d’éliminer les gaspillages.

Je terminerai cet article avec quelque verbatims des personnes de la core team:
« Ne pas viser la perfection tout de suite ».
« La grosse valeur ajoutée de l’obeya : la capacité à retranscrire et partager la connaissance explicite et implicite de chacun, qu’il faut extraire »
« Avec les bonnes personnes au bon moment »,
« Tous les participants sont mobilisés ensemble à l’instant T sur un sujet commun, ce qui facilite l’identification et la résolution de points et problèmes »