DSI : multiplier par dix la valeur livrée par une TMA grâce au Kaizen

Introduction

Au sein des équipes du numérique que nous accompagnons, nous sommes souvent surpris d’observer ce décalage entre, d’une part, le nombre de fois où on parle de “valeur client” lors de réunions ou de discussions informelles et, d’autre part, le peu d’énergie que ces mêmes équipes y consacrent effectivement dans leurs activités opérationnelles de tous les jours.

Un peu comme dans le livre de Jonathan Lefevre, avec le Kaizen nous sommes obsédés par la valeur client et nous développons un regard très aiguisé pour distinguer au sein des équipes, les activités qui livrent de la valeur au client de celles qui n’en n’apportent pas.

Dans cet article nous présentons une mission dans laquelle nous avons accompagné une équipe pour l'amener à changer de regard. L’objectif était qu'elle se concentre, au quotidien, sur la livraison de valeur aux clients.

Un article encore une fois détaillé pour bien montrer que le résultat n’est pas acquis par la magie d’une silver bullet mais par le travail soutenu et régulier des équipes sur les obstacles qui les empêchent d’atteindre leurs objectifs.

1. Contexte

Une équipe de TMA (Tierce Maintenance Applicative), d’une douzaine de personnes au sein d’une DSI, responsable de livrer des petites évolutions (de 15 à 40 jours de charge) sur un système mainframe de facturation. Ces évolutions concernent des corrections ou des petites modifications tactiques du système.

Cette équipe regroupe quatre activités : chefs de projet / analystes ; configuration des environnements ; développement ; infrastructure.

Ses clients sont des métiers localisés dans des call centers en région (équipes Front Office) ou au sein des équipes régionales de configuration de plateforme (Back Office).

Le système mainframe utilisé est lourd et l’objectif de ces évolutions est d’en rendre l’usage plus simple et plus efficace pour les utilisateurs, ou encore de corriger des anomalies de production qui peuvent impacter les calculs ou le déroulement des batchs de nuit qui lancent les facturations.

2. Problème

Lorsque nous commençons à travailler avec elle, cette équipe n’a pas livré d’évolution en production depuis cinq mois (6 itérations de 3 semaines). Depuis la perspective de ses clients (les métiers), elle n’a donc pas livré de valeur sur cette période.

Par ailleurs, le niveau de satisfaction des clients se situe à une note de 6,6/10 et un NPS de - 31% (3 fois plus de détracteurs que de promoteurs).

Cela résonne particulièrement avec l’objectif du sponsor qui souhaite améliorer la satisfaction des clients. La cible qu’il donne à l’équipe est d’avoir un NPS client positif et un rythme de deux évolutions livrées par sprint.

3. Impact

Du point de vue des clients finaux, cette absence de nouvelles évolutions livrées en production a plusieurs impacts. Elle crée de la frustration, l’obligation de procéder à des manipulations manuelles plutôt qu’automatiques et ce avec un très grand niveau d’attention car les erreurs ne sont pas identifiées à la saisie mais lors de l’exécution de batchs de nuit.

Certaines erreurs identifiées sur le système mettent un temps particulièrement long à être résolues. Ainsi, lors d’un entretien, un utilisateur nous explique que : ”Entre le moment où on détecte l’anomalie et où c’est pris en charge il faut 2 à 3 mois de la part de l’équipe. Conséquences du retard de l’anomalie : on doit faire appel à des acteurs de la chaîne pour faire des correctifs manuellement. Au final cela va prendre 9 mois, il faudrait la traiter en 4 fois moins.”

Les collaborateurs de l’équipe nous remontent eux une grande frustration en raison des phases de recette beaucoup plus longues que prévu et durant laquelle beaucoup de problèmes sont remontés.

Au niveau de l’entreprise, les douze personnes de cette activité (qui y travaillent à temps partiel) n’ont pas livré de valeur à leurs clients internes (les métiers). Cela représente donc un investissement financier que l’on peut estimer à un équivalent de quatre à six collaborateurs sur lequel il n'y a eu aucun retour sur investissement en cinq mois.

4. Standard

Nous avons du mal à comprendre le processus de réalisation, en partie parce que le processus existant dans JIRA (outil utilisé pour piloter le suivi) ne correspond pas à la réalité du terrain que nous observons.

En utilisant l’outil lean SIPOC (Supplier, Input, Process, Output, Customer), nous parvenons à mieux appréhender le processus complexe utilisé par l’équipe pour livrer une évolution, avec les étapes suivantes :

1. Étude : qui implique les CdP/Analystes et la TMA
2. Validation avec les métiers (retours vers les métiers) : qui implique les chefs de projet, le développement et les clients
3. Réalisation (le Build) : qui implique le développement
4. Recette interne : qui comprend la préparation de la recette par l’équipe de configuration d’environnement et la recette des chefs de projet
5. Recette métiers : concerne les chefs de projets et les clients
6. La mise en production.

Dans un second temps nous regardons l’encours à chaque étape afin d’identifier les engorgements. La situation du flux d’évolutions est représentée par l’illustration ci-dessous :

Plusieurs constats sautent aux yeux :

1. aucune évolution livrées en production ;
2. embouteillage en phase de recette dû à des problèmes de coordination entre les différentes activités qui concernent sept évolutions et un total de 110 jours de développement.
3. 11 tickets pour lesquels il y a eu des estimations et qui ne sont finalement pas développés (22 jours d’analyse de perdus).
4. un flux poussé avec 15 évolutions en phases d’étude qui posent cette question : quelle pertinence lorsque l’on sait que l’on a rien livré en 5 mois ?

5. Analyse des Causes

Nous menons des entretiens avec les clients internes (équipe de chef de projet), qui sont en fin de chaîne de valeur et ils nous remontent une certaine lassitude car aucune recette n’est simple et se déroule correctement. Quelques verbatim :

“Idéalement il aurait fallu 2 semaines pour faire la RE7 => 3 demandes et une demie journée, voir une journée de travail côté appli. On a commencé début décembre et c’est pas fini => on a fait fois 5 plus en termes de durée ».

« La mise en place des environnements pour cette évolution #404 aurait dû nécessiter seulement 3 demandes à l’équipe Environnements (au lieu de 13) => tous les tickets faits en plus sont dûs à des plantages d’environnements ».

Pour illustrer l’impact de ces problèmes sur les délais de réalisation des évolutions, nous traçons la ligne de vie de certaines de ces évolutions et calculons le ratio Touch Time (temps réellement passé à travailler sur l’évolution) / Lead Time (temps de réalisation de bout en bout) qui est un bon indicateur de l’efficacité d’un processus :

Sur cette évolution on voit que le lead time a duré 335 jours pour un touch time de 9 jours. Ce qui représente un TT/LT de 2,7% et qui illustre bien le fait que la majorité de la durée de vie d’une évolution est simplement du temps d’attente.

Nous illustrons avec cet outil les grandes étapes de la vie de cette évolution, les temps d’attente (en rectangle rouge au dessus des mois), les problèmes remontés (rectangles avec le texte en rouge) et l’efficience de traitement de cette évolution.

Dans un second temps, nous faisons avec l’équipe une analyse détaillée de tous les obstacles rencontrés sur quatre évolutions spécifiques, en précisant l’étape du processus dans laquelle nous rencontrons le problème. Il s’agit d’une atelier important dans l’accompagnement du changement en ce qu’il permet à l’équipe de voir ensemble ces obstacles qui l’empêchent de livrer de la valeur.

Causes identifiées :

• Cause 1 :

Pas de standard sur la phase d'étude qui permet de définir qu’elle est bien terminée (Definition of Done). En particulier les critères de validation de la part du métier sont flous et il manque parfois des sujets qu’il aurait pu voir avec un questionnement plus précis. Lorsque le constat d’écart entre la vision métier et la réponse de l’équipe est fait beaucoup plus tard, le coût du problème est bien plus impactant pour l’équipe.

• Cause 2 :

On démarre souvent la phase de recette alors que l’environnement n’est pas finalisé (pas de Definition Of Ready), ce qui engendre des pertes de temps et de la frustration pour les CdP/analystes. Cela rend tangible le besoin d’avoir une étape de préparation de la recette.

• Cause 3:

Les rafraîchissements d’environnements sont souvent la source de problèmes. Dans l’équipe configuration d’environnement, le geste pour rafraîchir ces environnements n’est pas le même en fonction des personnes et cela est à l’origine de 5 tickets rouges car les personnes ne prennent pas le temps de valider le résultat de leur travail.

• Cause 4 :

Lors des entretiens que nous avons mené avec les clients, ils nous remontent ne pas connaître les dates de livraisons de leurs demandes, dates que nous ne trouvons pas dans le JIRA : la livraison de valeur au client n’est pas pilotée. Lors des réunions de pilotage auxquelles nous avons assisté, on parle bien plus des futurs sujets que de ceux que l’on doit livrer en production.

6. Contre-mesures

Voici les contre-mesures mises en oeuvre pour les causes correspondantes identifiées :

1. Mise en Place de DoD Phase d’étude :

Au terme de la phase d’étude : mise en place d’un point de synchronisation CdP / Développement / Métier pour valider la bonne compréhension du sujet à traiter et la pertinence de la solution proposée. Le questionnement employé alors est spécifique et précis et rend visibles les écarts de compréhension.

À titre d’exemple : les métiers souhaitaient sur une évolution changer une règle métier pour une population donnée (les nouveaux inscrits). Ceux-ci peuvent avoir un code interne A1, A2 ou A3 en fonction de sous-critères (régions, nature de contrat etc …). Dans l’esprit de l’équipe de développement, il était clair que l’on parlait de toute la population. En revanche, dans l’esprit des métiers, il était implicite que l’on ne visait que la population A1 et A2. En raison de la lourdeur du système, la correction de cette incompréhension a représenté 5 jours de charge et une douzaine de jours de délai. L’ensemble des parties prenantes a donc décidé d’utiliser le code interne (e.g A1, A2 dans ce cas spécifique) pour qualifier les publics cibles visés plutôt qu’un intitulé verbal.

2. Definition of Ready pour les environnements :

Mise en place d’une Definition of Ready pour les environnements, ce qui permet aux ingénieurs de l’équipe de configuration des environnements de valider que leurs actions correspondent bien aux attentes des CdP/Analystes. De plus, l’équipe a défini un interlocuteur unique de l’équipe de configuration des environnements pour la durée de vie de chaque évolution afin de fluidifier son support technique.

3. Standard de Rafraîchissement :

De nombreux rafraîchissements sont incorrects car les données ne sont pas à la date attendue par l’équipe demandeuse (TMA). Cela induit des aller-retours et des pertes de temps. En permettant aux deux équipes (Environnements et TMA) de travailler ensemble sur le sujet, celles-ci se sont rendues compte qu’il était nécessaire de mieux préciser les informations en entrée, en donnant l’info système SSJ (Semaine et Jour dans la semaine) de rafraîchissement en fonction du jeu de données que l’on veut rejouer. Le SSJ que l'on va donner sera celui de la veille de la mise à jour du traitement (erreur fréquente ainsi évitée).

4. Mise en place d’un Flux Tiré

Mise en place d’objectif par sprint : on s’engage sur les deux évolutions à mettre en production au terme des trois semaines du sprint. C’est le flux tiré : on s’organise pour livrer au rythme du client, en se concentrant sur ce qui sort. L’objectif au travers de cette action est double :

• Aider l’équipe à se concentrer sur les deux évolutions spécifiques afin de se mettre en situation de les livrer. À chaque sprint la priorité est ainsi clairement circonscrite et l’équipe revient inlassablement à cet objectif principal pour éclairer ses décisions et anticiper les problèmes  ;
• Indépendamment de l’alignement de l’équipe sur des objectifs clairs et à court terme, le flux tiré présente l’avantage de rendre visibles les problèmes et ainsi des opportunités d’apprentissage pour l’équipe.

Exemple du sprint 8 :

Identifier des problèmes spécifiques, sur des sujets encore frais dans l’esprit de l’équipe, lui permet de mettre rapidement des contre-mesures actionnables en place et d’améliorer, de façon itérative et incrémentale, son processus de livraison.

5. Mise en place d’un management visuel

Afin d’aligner l’ensemble des parties prenantes sur la valeur et les problèmes qui nous empêchent de livrer, l’équipe a mis en place d’un management visuel pour piloter la phase de recette. Cela présente plusieurs vertus :

1. préciser de façon claire et explicite les dates de livraisons ;
2. rendre tangible les problèmes rencontrés en cours de recette ;
3. permettre de concentrer les efforts sur les échéances proches et aider les personnes qui sont bloquées et ont besoin d’aide.

Ce visuel a aidé à changer le regard des personnes lors des points de pilotage en concentrant leur attention sur ce que nous devions sortir. Nous sommes ainsi passés d’un mode poussé (on entre de nouveaux sujets en phase d’étude) à un système tiré (on livre en production des évolutions).

Ce visuel nous permet également de limiter l’en-cours. Lors d’un point de pilotage l’équipe s’est rendu compte que Benjamin, un développeur, était pris sur quatre (!) évolutions en parallèle, avec des problèmes d’étude et de recette sur chacun. Il passait ses journées en réunion et il n’avait plus le temps d’avancer : ce n’est pas le mettre en situation de réussite. L’équipe a donc décidé de demander à Benjamin de donner la priorité aux actions les plus proches de la livraison. On retrouve ainsi un des principes du Flux tiré : on traite le Kanban de droite (le plus proche du client) à gauche, lors du pilotage. Aujourd'hui l'équipe n'a plus que six évolutions dans son tableau celle du sprint en cours et celles des deux à venir.

7. Résultats

Le diagramme suivant illustre l’évolution du nombre d’évolutions livrées chaque sprint :

On peut apprécier la profondeur des problèmes rencontrés au temps qui a été nécessaire pour enfin entrer dans le cercle vertueux de livraison régulière de valeur.

En synthèse, sur les 7 premiers sprints, l’équipe a sorti 1 evolutions contre 10 pour sur les sept suivantes. Pour ce qui est à la main de l’équipe, à savoir livrer des évolutions en production, la valeur livrée au client a donc été multipliée par 10 sur une période identique grâce à la mise en œuvre de cette démarche d’amélioration continue.

Un des impacts business de la mise en production de trois évolutions parmi ces dix a été leur contribution à la réduction du nombre d’incidents batchs durant la phase de pic de facturation. Nous sommes ainsi passé de vingt problèmes en 2020 à quatre problèmes en 2021 (après la mise en oeuvre du Lean). Chacun de ces problèmes nécessite de relancer le batch le lendemain - on perd ainsi une journée de trésorerie - plusieurs milliers de clients pour quelques centaines d’euros.

En outre, sur les vingt problèmes de 2020, neuf ont causé un retard dans l’accès au service pour les équipes régionales de service client : neuf arrêts de deux heures concernant une population moyenne de 200 personnes - soit 3600 heures/homme ou 450 J/H en tout). En 2021 il n’y en a eu aucun.

Le niveau de satisfaction client montre un NPS de 20 (deux fois plus de promoteurs que de détracteurs) et une note moyenne de 8/10.

Le niveau de satisfaction des équipes (au sortir de la semaine 9) montre quant à lui un NPS de 7% et une note moyenne de 7/10.

8. Enseignements

L’équipe

Bill, le Scrum Master en charge des évolutions a appris à piloter sa production (plutôt que son planning) grâce aux principes du flux tiré. Il a aussi appris à utiliser le management visuel pour aligner l’ensemble de l’équipe sur les bons sujets (les deux évolutions du sprint), rendre visibles les problèmes et inciter les parties prenantes à les traiter ensemble aussitôt pour atteindre les objectifs du sprint en cours.

Chacun, à son étape du processus, a appris à livrer bon du premier coup. Cela passe par de la rigueur personnelle (avec les checklist Definition of Done ou Definition of Ready) mais aussi par un travail avec les autres parties prenantes sur les “pièces” défectueuses pour mieux comprendre les attentes des uns et des autres.

La mise en oeuvre des outils lean (standard, checklist, flux tiré, management visuel) a permis à l’équipe de passer d’une situation confuse et insaisissable (nombreux problèmes récurrents, à chaque étapes du processus, découragement des collaborateurs) à une situation dans laquelle les parties prenantes ont développé leur capacité d’agir, avec des actions concrètes, qui leur ont permis, ensemble, d’améliorer le processus de livraison des évolutions.

Les coachs

Pour dire la vérité, au terme de notre accompagnement (à la fin du sprint 8), nous avions comme un goût d’inachevé. Malgré les efforts consentis, les nombreux ateliers de résolution de problème avec l’équipe, celle-ci avait toujours du mal à livrer.

Nous restions confiants sur le fait que c’était là le bon moyen d’y arriver mais nous avions un petit doute sur la capacité de l’équipe à conserver cette dynamique d’amélioration face à un système lourd et ingrat. Le facteur clef a été que Bill (le Scrum Master évolutions) et Chris (son manager) restaient tous deux confiants et déterminés à faire des résolutions de problème chaque jour.

Par la suite, au fil de nos journées mensuelles de suivi, nous avons pu constater qu’ils conservaient leur optimisme à mesure que l’équipe se mettait à livrer régulièrement. Lorsque nous avons vu qu’au terme du Sprint 12 ils venaient à nouveau de livrer deux évolutions nous savions que les pratiques d’amélioration étaient assimilées.

Notre enseignement est donc celui que me répète sans cesse la Sensei Marie-Pia Ignace : “Faites confiance à la méthode : si les collaborateurs améliorent, ensemble, régulièrement le processus, cela va finir par payer.”

Un conseil qui illumine comme un soleil la grande joie de constater ainsi le chemin parcouru par l’équipe.

Retrouvez Cecil et Théo, les auteurs de ce retour d'expérience, pour vivre l'apport du Kaizen dans le numérique lors de la Masterclass Digital Kaizen, organisée dans les locaux d'OCTO le 14 décembre 2021.