“Nous avons une informatique très industrielle” m’ont souvent dit des DSI qui me recevaient pour parler Lean IT. Pendant longtemps, j’ai eu beaucoup de curiosité à aller avec eux, dans leurs équipes, pour voir la création de valeur ; on parle de genchi genbtusu en vocabulaire Lean. Immédiatement, j’ai pu constater que l’industrialisation décrit une organisation très différente dans l’usine et en informatique.
Dans l’usine, surtout Lean, le produit bouge : il va d’un point à un autre, à un rythme régulier et en continu il s’enrichit. Il atteint rapidement un quai de livraison où il trouve la place qui lui était désignée et il est expédié. Le ratio “temps de construction du produit” / “temps de passage dans l’usine” est très proche de 1. J’ai vu des pare-chocs produits en 24 heures, du granulé de plastique à l’expédition et chaque pare-chocs était différent de son prédécesseur et de son successeur.

Autant l’usine est calme, autant le département informatique est affairé, sous tension. La moindre demande y suit un process bien défini et pourtant rien ne sort, ou alors si lentement !

Lors des visites Lean IT, comme en usine, je demande à voir les derniers produits livrés : on en trouve très peu sur une semaine, qu’il s’agisse de résolution d’incidents, de livraison de poste de travail ou de construction de serveurs. Et quand on regarde la date d’ouverture de la demande, elle se compte en semaines ou en mois. J’ai vu des équipes fêter les “anniversaires” d’un incident : un an depuis leur ouverture… Le ratio “temps de travail sur la demande “ / “temps de traitement de bout en bout de la demande” est très faible :
• quelques heures pour construire un serveur contre 5 mois pour le livrer,
• quelques minutes pour ouvrir un flux CFT contre 25 jours pour le livrer.
Si on suit la construction d’une fonctionnalité, la surprise peut être totale : ajouter un champ dans un outil de business intelligence prenait près de 24 mois dans l’une de mes visites. De l’ouverture de la demande, à son intégration dans un “projet”, de sa réalisation à et sa mise en production, on parle de deux ans. On comprend mieux le désenchantement des métiers vis-à-vis de leur informatique.

Comment une organisation dite industrielle peut-elle fournir une performance aussi différente en usine et dans une DSI ?

Le Lean IT fournit une bonne piste pour répondre à cette question. Les DSI que j’ai interrogés sur leur industrialisation expliquent qu’ils définissent de façon détaillée les actes à faire à chaque étape et la nature des livrables (documents, données, etc…). On s’intéresse à la précision des échanges au niveau des interfaces et à la traçabilité des échanges. Ceci fait, il ne reste qu’à trouver des “ressources” pour faire le travail. Et rien ne se passe comme prévu. Parce que ce raisonnement oublie totalement le 1er principe de la réussite d’une industrialisation : ce n’est pas la mise sous contrôle du processus mais la maîtrise de la variabilité qui rend les processus industriels aussi robustes et efficaces.
Or la variabilité est niée dans les processus informatiques. Chacun, à son poste dans le processus, contrôle la qualité des informations / produits qu’il reçoit : en cas d’écart, la demande ou le produit est rejeté vers son émetteur dont on attend qu’il fasse les corrections ad hoc. Les bonnes pratiques du Lean IT préconisent effectivement de mettre de côté ces demandes non conformes mais, au lieu de les rejeter, de les comprendre. On n’a qu’une seule idée en tête – satisfaire complètement le client – et arriver à le livrer est une recherche permanente ; comprendre ce qui s’y oppose une nécessité.
Un exemple : l’équipe en charge de la construction des machines virtuelles d’un grand opérateur met toute la DSI dans la difficulté. Les machines ne sortent plus. Une cellule de crise est ouverte au plus haut niveau et le reporting est très clair : les clients n’envoient que des demandes irréalisables car non conformes. De quoi se plaignent-ils alors ? Une explication musclée se prépare.
Par hasard, je croise le manager de l’activité “machines virtuelles” et lui propose non pas de regarder le problème dans ses slides mais dans son équipe. Nous voilà dans les escaliers et les couloirs. La 1ère salle dans laquelle nous entrons est vide. Où est l’équipe en renfort qui doit aider à livrer plus de machines ? Nous finirons par apprendre que les membres de l’équipe n’ont toujours pas, 16 jours après leur arrivée, de poste de travail qui fonctionne et donc ils se promènent. Nous trouvons ensuite la salle dans laquelle travaille l’équipe habituelle. Le responsable de l’équipe nous montre le paquet de demandes qu’il avait renvoyé aux clients depuis une semaine. Lui et le manager me les montrent : l’affaire est entendue, la pile est épaisse : les clients se tirent une balle dans le pied en envoyant des demandes non conformes.
Oui, mais de quelles non conformités parle-t-on ? J’invite le manager à lire la première demande refusée. Il ne voit pas pourquoi elle est refusée et le responsable de l’équipe l’éclaire : le demandeur veut installer windows 8 sur la machine et demande 60 giga de disque. Il en faut 80. Fin de l’histoire. Le coach Lean IT que je suis remercie et demande à ce qu’on regarde la demande suivante. Le manager repère tout seul l’erreur : windows 8 et 60 giga de disque. Le doute s’installe : il lira le contenu d’une douzaine de demandes, toutes refusées pour le même motif. S’en suit une discussion rapide entre le manager et le responsable d’équipe : on reprend, maintenant les demandes rejetées, on remplace les 60 par 80 (le manager en prend la responsabilité) et on sort les machines. Et une fois la crise calmée, on essaiera de comprendre d’où vient cette fable des 60 giga pour la faire disparaitre. Et on se posera même la question de savoir pourquoi il faudrait demander aux Métiers d’avoir une expertise sur la taille des disques, etc, etc, etc. Voilà pourquoi l’informatique et l’industrie sont différentes : dans l’usine, on sait se battre contre la variabilité parce qu’on prend très au sérieux la nécessité de servir son client.
Bref, démarrer une démarche de Lean IT pour un DSI, ce n’est pas revoir une nouvelle fois ses processus, même lorsqu’ils sont ubuesques, mais bien au contraire installer une culture de l’amélioration continue dans laquelle chacun sait détecter la variabilité, connait les bonnes méthodes pour l’isoler et la comprendre et s’engage, en personne, à la réduire. Est-ce que ça en vaut en la peine ? Oui, si l’on cherche le sourire du client. Et des collaborateurs. Tout en divisant les délais par 10 et en multipliant la productivité par 2.