Lean IT : et si l’on faisait confiance aux équipes de terrain ?

Créé le

22.05.2012

-

Mis à jour le

30.05.2012

Philosophie de management datant du milieu du XXe siècle, le Lean management devient Lean IT lorsqu’il s’applique aux services informatiques. Souvent expérimenté par les équipes, vanté par différents cabinets d’études, que faut-il en penser ? Serait-ce la nouvelle solution miracle pour la DSI ?

« L’informatique de gestion est le seul métier dont la productivité diminue avec le temps, c'est-à-dire avec la complexité du système d'information. » « Si les méthodes marchaient, il n’y en aurait pas autant : méthode en V, en cascade, etc. » Ces deux constats émanent de Pierre Pezziardi, qui fut DSI de la BRED de juin 2010 à septembre 2011, avant de fonder Notrebanque.com. Amers ? Pas vraiment. Ce spécialiste de l’agilité informatique et du Lean IT pointe juste du doigt le principal problème de l’informatique actuelle, bancaire ou non, et met en garde contre l’application bête et méchante d’une recette miracle : le Lean IT. En effet, comme d’autres termes informatiques courants – cloud computing, consumérisation de l’IT, méthodes agiles –, le Lean IT est mis depuis quelques années à toutes les sauces et vendu comme l’outil idéal pour réformer ses services informatiques. En effet, quand cette façon de manager les équipes est mise en place correctement, les résultats sont visibles très rapidement (dans les 3 à 5 mois après le lancement).

Chercher l’amélioration permanente

De quoi s’agit-il au juste ? Pour Marie-Pia Ignace, Senior Advisor à l’institut Lean France et fondatrice d’Operae partners, « le Lean travaille sur quatre sujets complémentaires : satisfaire complètement le client, travailler juste à temps, construire de la qualité à l’intérieur du processus en faisant les choses correctement du premier coup et passer par le développement des collaborateurs et que chacun soit autonome et proactif dans les trois points précédents. » Dans un département informatique, le Lean va avoir plusieurs actions :

  • dans la maintenance, il cherche à réduire le temps de traitement des incidents et à en éliminer le plus possible les causes ;
  • dans la conduite de projet, il s’agit de renforcer le travail en équipe pour être plus rapide et plus fiable et chercher l’amélioration permanente ;
  • dans la production, il vise à améliorer les processus.
Pour Xavier Muller, Lean Master Black Belt chez Deloitte, «  il y a trois grands secteurs où le Lean IT serait bénéfique à une DSI bancaire : les nouveaux grands chantiers IT, l’amélioration de la performance des supports informatiques internes, et la résultante des deux, une réduction des investissements en IT. » Comme exemple, Xavier Muller cite le cas d’un de ses clients, une grande banque anglaise : «  Elle devait refondre sa plate-forme opérationnelle, et l’une des conséquences était la mise en place d’une solution BPM [1] . Au départ, l’idée était de reproduire la façon de travailler en place dans le système d’information, mais celui-ci a généré de nombreuses exceptions et erreurs à résoudre. Il a fallu multiplier par deux les investissements en infrastructure IT. Mon rôle a été de les aider à faire le tri entre les 13 millions d’exceptions générées et de les résoudre en changeant les processus clés au départ [2] . » Chez Wells Fargo, l’approche Lean a facilité le passage au zéro papier dans le back-office de la banque américaine. L’établissement est ainsi passé d’un million de documents numérisés et traités par mois en 2002 à un milliard en 2010.

Une équipe informatique « responsable de bout en bout »

Concrètement, comment mettre en place une approche Lean IT qui fonctionne ? « L’essence même du Lean, c’est la débureaucratisation au sens large de l’informatique, estime Pierre Pezziardi, c ’est-à-dire le décloisonnement des équipes. En particulier, le décloisonnement entre études et productions pour arriver à du “ devops [3] ». Il préconise la mise en place d’équipes « devops » par produit – poste client, moteur d’épargne, risque, etc. –, tout en reconnaissant qu’il est difficile de changer les habitudes. Pour cela, il part de la base. « Je vais semer des graines en cherchant les “indignés”. Je vais donner du pouvoir et du temps à des gens qui n’en ont pas forcément, mais qui sont sur le terrain et sont indignés par les problèmes que rencontre la structure actuelle . » N’ayant pas voulu attaquer tous les chantiers à la fois, lors de son passage à la BRED, Pierre Pezziardi s’est intéressé aux problèmes récurrents. Pendant que le « top-down » des grands projets de la DSI continue, il négocie une enveloppe de 500 jours/hommes par an, avec une petite équipe de trois équivalents temps pleins – les ingénieurs changeant en fonction de leur « indignation » et des besoins – dédiée à la résolution au jour le jour des problèmes des agences avec des cycles de développement beaucoup plus rapide, se comptant en jours ou semaines et non en mois. « Cette solution s’autofinance rapidement. Si, pour un problème donné, vous faites perdre 5 minutes par jour à 2 000 collaborateurs en agences, en le résolvant, vous faites gagner 4 000 jours de travail à l’entreprise. Pour parvenir à répéter à l'infini ces microaméliorations, l’équipe informatique doit être responsable du problème de bout en bout. »

Des résultats en moins de trois mois

Pour autant, la mise en place du Lean IT n’est pas instantanée. « Il y a une dimension humaine du Lean très forte », constate Xavier Muller. « Au niveau de la DSI, il y a une déconnexion entre les managers et les équipes de développement ou de production. Une des grandes difficultés du Lean IT est que c’est une méthode bottom-up, alors que les DSI ont souvent une approche top-down pour donner les grands objectifs de stratégie et de performance, et il faut réussir à faire la coordination des deux. » Pour faire du Lean, il ne suffit donc pas de plaquer quelques méthodes qui en sont issues. « Il faut opposer le Lean-outil, qui ne change pas la culture de l’entreprise, et le Lean-culture, qui va la modifier, mais prend plus de temps et n’est pas forcément simple à implanter » prévient Pierre Pezziardi, qui précise que « si l’on vous parle de schéma directeur Lean, de responsable Lean, ce sont des signaux faibles du déploiement total de la méthode, c’est le signe de l’échec. P ar contre, si on parle de valeur pour le client, de cycle court, d’autonomie, nous sommes dans le Lean-culture. Un autre bon signal est la confrontation la plus rapide à l’usager. Tous les résultats ont été obtenus en moins de trois mois. »

Marie-Pia Ignace propose des indices complémentaires pour reconnaître un bon consultant qui vous aidera à installer du Lean chez vous. « Déjà, si un cabinet n’est pas capable de tenir les délais et les budgets sur ses propres projets, il n’est pas à consulter pour du Lean. S’ils savaient en faire, ils commenceraient par l’appliquer chez eux. De même, il faut regarder l’atmosphère salariale chez le prestataire. Si elle est mauvaise chez eux, c’est que le Lean est mal fait. Une fois installé chez vous, y a-t-il transfert de compétence Lean vers vos équipes ? Des premiers résultats sont-ils visibles rapidement ? » Elle rappelle également que l’expert Lean doit être compétent en informatique. Une difficulté réelle, car le Lean reste pour l’instant bien ancré dans le monde industriel.

1 Business process management. 2 Au niveau des équipes en place, et non pas simplement avec des lignes de code, NDLR. 3 De l'anglais « development » (développement) et « operations » (exploitation), le Devops vise à aligner le système d'information sur les besoins de l'entreprise, NDLR.

À retrouver dans la revue
Revue Banque Nº749
Notes :
1 Business process management.
2 Au niveau des équipes en place, et non pas simplement avec des lignes de code, NDLR.
3 De l'anglais « development » (développement) et « operations » (exploitation), le Devops vise à aligner le système d'information sur les besoins de l'entreprise, NDLR.