Le flux tiré est par excellence l’outil qui permet de produire au rythme du client. Son utilisation dans l’IT n’est pas exempte de contraintes ni de déconvenues.

Un exemple générique du passage en flux tiré d’une équipe dont la production est fortement cloisonnée serait le suivant :
– Poser le processus, par exemple sous forme de kanban ;
– Poser l’encours et le stock ;
– Se définir un nombre quotidien de pièces à produire en relation directe avec les attentes des clients ;
– Produire.

Inévitablement, la production se heurte à des difficultés : l’air renfrogné, chacun découvre que le nombre de pièces produites est inférieur à celui attendu !

Les causes probables – et non exhaustives – seront les suivantes :

• Il n’a pas été tenu compte du nombre de personnes présentes pour produire.
  Il a été défini que l’équipe se fixerait de sortir 10 pièces par jour. Mais personne n’a tenu compte du fait que les effectifs fluctuent d’une journée sur l’autre. Mais la quantité à produire ne dépend pas des personnes présentes dans l’équipe. Si le client demande 10 pièces par jour alors il faut en sortir 10. Nous voilà à la croisée des chemins : soit nous sommes capables de supprimer tout un tas de gaspillages et nous gagnons la capacité qu’il nous manquait, soit nous rajoutons du monde, soit nous ne faisons rien et le stock de demandes augmente.

• Les personnes font autre chose de leur journée.
  En se penchant de plus près sur l’activité de l’équipe, on découvrira un certain nombre d’activités tues jusqu’à présent. Elles ne seront pas nécessairement sans valeur ajoutée pour l’entreprise. Mais est-ce bien à cette équipe de les réaliser ? Sont-elles des gaspillages ? Naturellement, il y aura aussi des activités qui n’auront strictement aucune valeur ajoutée.

• L’environnement de travail est accidentogène.
  Jusqu’à présent, il y avait un bruit de fond au sujet des droits d’accès longs à obtenir, révoqués, inadéquats, sur les machines obsolètes, sur les environnements de tests indisponibles ou inopérables, la chaise cassée, la politique zéro papier qui oblige à se crever les yeux sur 3 écrans, etc… Tout à coup, cela devient une évidence : cela nous empêche de travailler !

• Les gestes ne sont pas maîtrisés.
  Dans la catégorie des gaspillages, voici les retouches : le team leader et le management découvriront que certains gestes à accomplir ne sont ni maîtrisés, ni documentés. Il se peut même qu’ils découvrent que leur matrice de compétence est inexistante ou obsolète, qu’elle ne sert ni à évaluer les candidats à recruter, ni à élaborer un plan de formation des membres de l’équipe.
• Il n’y a pas de stratégie de gestion des flux.
  Dans de nombreuses organisations, le secteur de l’IT privilégie le recrutement de prestataires. Il n’est pas rare d’avoir des plateaux entiers de prestataires pilotés par quelques managers internes. Sous la pression de leur commercial et pour s’assurer un avenir professionnel prometteur, il arrive que les plus hardis de ces jeunes gens se choisissent des tâches très complexes qu’ils ne maîtrisent pas. La satisfaction personnelle de monter en compétence est parfaitement légitime et doit être prise en compte dans le plan de formation des équipiers. Passer 3 jours à démêler l’écheveau d’un ticket complexe, alors qu’un expert peut y passer seulement 3 heures, contrevient très certainement aux intérêts du client.
• Les entrants sont de mauvaise qualité.
  Non, le client ne sait pas ce qu’il veut, ne sait pas comment dire où il a mal, et cela se ressent très clairement dans la qualité du contenu de la demande reçue par l’équipe. Sans le savoir, les équipiers pèchent par modestie. Lorsque nous allons chez le médecin, nous arrivons avec notre douleur. Par une série de questions et d’auscultations stratégiquement ordonnées, le médecin parviendra à un diagnostic. A défaut il ordonnera des examens complémentaires à réaliser pour valider ou invalider des hypothèses et, enfin, à un soin de la cause du mal. Entre temps, il aura au moins prescrit quelques médications pour rendre supportables les symptômes. Lorsque nous voulons faire construire une maison sur plan, l’architecte est là pour nous aider à faire émerger le projet qui est parfois assez éloigné de ce que nous imaginions au départ. L’excès de modestie des membres de l’équipe consiste à agir comme de simples aides-soignantes ou maçons là où ils devraient se comporter comme des médecins ou des architectes. Les entrants de mauvaise qualité ne sont pas la justification d’une fin de non-recevoir, ils sont le point de départ d’une analyse en commun et des améliorations qui suivront.

Nous l’avons compris, avant de tirer la production, le flux tiré tire les problèmes. Cette méthode recèle un certain nombre de savoir-faire secrets. Par contre, là où il n’y a pas de secret, c’est qu’il faut se libérer du temps pour résoudre les problèmes. Oui, cela va ralentir la production. Soyons un brin cyniques : comme auparavant rien ne sortait bon du premier coup à la date attendue par le client, cela va passer quasiment inaperçu, sauf pour ceux qui, à la faveur de KPI parfaitement léchés, n’avaient pas conscience que rien ne sortait.

Gérer les problèmes, ce n’est pas les résoudre. Si la gestion des problèmes au sein de l’organisation est nécessaire au maintien du seuil de tension sous le niveau de déclenchement du cannibalisme, le réflexe pavlovien de la multiplication des réunions de crises n’est pas à prendre à la légère. Attention de bien veiller à préserver ceux qui résolvent les problèmes des interférences des clients et parfois des sponsors eux-mêmes. Le team leader de l’équipe qui passe en flux tiré va donc porter sur ses épaules à la fois :
– le relationnel avec l’extérieur qui n’éprouve pas le besoin de changer ;
– la conduite du changement dans son équipe.

Au bout de quelques semaines, voire quelques mois, l’équipe touche enfin son objectif :

L’équipe va devoir résoudre les problèmes au fur et à mesure qu’ils arrivent : d’abord la maîtrise de son environnement de travail et de ses gestes, puis les contributions externes. A mesure qu’elle tire et résout ses problèmes, elle libère sa capacité de production et sort plus de pièces. Elle va presque inconsciemment passer d’une à cinq minutes de valeur ajoutée produite par heure. Si en plus elle parvient à limiter les temps d’attente entre 2 étapes de production d’une pièce, les résultats sont spectaculaires :
– Le temps de traitement des tickets d’assistance passe d’un mois à un jour ;
– Le stock de tickets incompressible depuis plusieurs années disparaît ;
– Le temps de déploiement d’un composant applicatif est divisé par 20 ;
– La satisfaction des clients passe de la défiance à la recommandation ;
– La productivité est multipliée par 4.

Nous voilà donc avec 2 nouveaux problèmes résumés en 5 mots : quel est le coup suivant ?
– Nous avons amélioré la productivité et l’équipe va rapidement arriver en surcapacité. –
Il est évident que la seule réduction de la taille de l’équipe risque de limiter à l’avenir la collaboration des personnes d’autres équipes qui se sentiraient menacées par ladite réduction. Penser rapidement au coup d’après permettra par exemple d’aboutir la réflexion sur l’augmentation du périmètre traité par l’équipe, qu’il s’agisse de RUN applicatif ou d’une business unit.
– Nous avons une belle vitrine dans l’entreprise, quid du reste ? –
La tentation de passer à l’échelle peut se faire en mode « big-bang ». La littérature managériale ne regorge pas d’expériences réussies. Elle peut également se faire en entreprenant la mise en flux tiré d’équipes dont la production est plus intégrée dans l’organisation.
Ces équipes intégrées dans une organisation matricielle posent de nouveaux problèmes d’une nature radicalement différente :

Synchroniser une organisation par essence asynchrone

Comme pour une usine de voitures, le long de la chaîne vont avoir lieu des rendez-vous avec chacun des éléments à ajouter jusqu’à la complétion du véhicule. Ces rendez-vous ne peuvent pas être manqués, faute de quoi la chaîne de montage sera paralysée. Mais dans l’IT, seul le produit attend. Pour peu que le management visuel soit vraiment visuel, nous verrons s’accumuler des encours à certaines étapes du processus pendant que d’autres resteront vides. Tout le monde se trouvera du travail et fournira en même temps une explication qui sera toujours la même – j’attends quelque chose de la part de quelqu’un d’autre –. Allant jusqu’au bout de l’institutionnalisation de cette production asynchrone, nous verrons fleurir des statuts « en attente de… » dans les outils de suivi tels que JIRA ou Service Now. Le côté pratique de cette dématérialisation de l’encours est que la taille des murs ne limite aucunement son ampleur. Voilà pour le plus petit problème.

Il y a autant de silos, de chefs et de KPI que de contributeurs

Une difficulté bien plus grosse est qu’autour de ces encours se sont créées différentes instances de gestion et de priorisation des stocks à tous les niveaux. Cela va du comité qui valide la mise en production d’une nouvelle chose en fonction de ce qui est déjà dans les tuyaux, jusqu’aux différents micro-comités qui gèrent les états/silos intermédiaires. Ces instances, leurs créateurs et leurs animateurs ne vont pas se laisser faire. Cette résistance-là ne vit pas cachée dans le maquis : elle remplit l’agenda de tout manageur respectable. Certains sont même recrutés spécifiquement pour cela dans l’espoir de libérer des tâches de gestions ceux dont la fonction est de produire. Dès lors, on conçoit que l’effort d’alignement de l’organisation sur le changement est d’une toute autre ampleur qu’avec une équipe cloisonnée. Souvent, le sponsor doit mettre un pied dans la porte des managers des autres silos hors de tout lien hiérarchique. Une des façons les plus policées d’avancer est d’obtenir, pour chacune des parties prenantes, une dérogation au processus actuel pour une liste parfaitement délimitée de fabrications « pilotes » avec une clause de revoyure au terme de l’expérimentation.

What is your definition of « done » ?

Contrairement à une usine de voitures, pour une équipe IT l’état « terminé » des pièces détachées fournies le long de la chaîne de production est variable en fonction desdites pièces. Quelques exemples : « Mon travail consiste à ouvrir un ticket pour vous obtenir des droits d’accès, pas de vous donner ces droits. J’ai donc fait mon travail ». « Mon travail est de fournir un environnement de test. Les droits d’accès n’entrent pas dans mes attributions. J’ai donc fait mon travail ». « J’ai terminé la correction, mais je ne la livre pas tant que mon chef n’a pas validé. Il revient de congés lundi prochain ». Lorsqu’on lit ce genre d’anecdotes, cela fait sourire. Lorsqu’on les vit tous les jours, c’est démoralisant pour celui qui fait et c’est révoltant pour le client. Mais nous sommes sauvés car le sponsor a obtenu une dérogation : chaque entité contributrice à la valeur a envoyé une ou deux personnes pour constituer la cellule qui, entre autres, va décrire pour chaque élément sa definition of done. Une telle définition dans l’IT pourrait donner « est utilisable et sécuritaire en l’état ».

Notre cible, est d’obtenir un système décorrélé synchrone qui produise au rythme du client. Voyez comme il est aisé de conceptualiser des préoccupations de terrain en une élégante conversation de cocktail. Aussi, n’oublions pas que mettre en œuvre le flux tiré (redoutable outil du lean management) sur une organisation complexe nécessite de la constance dans les buts, et l’alignement des parties prenantes pour se donner le temps d’une parfaite maîtrise d’un processus au service de nos clients et non au service de lui-même.

Naturellement, cela nécessite une forte interaction avec nos clients pour comprendre en temps réel la nature, les délais et les coûts qui collent au plus près de leurs attentes.