Sélectionner une page

Si les 7 gaspillages du Lean sont particulièrement connus dans le monde de l’industrie, il parait toujours peu évident de les transposer dans d’autres secteurs d’activité. Florent Fouque, du blog Excellence-Opérationnelle.TV, vous propose, à travers cet article, de découvrir quels seraient les 7 gaspillages du Lean dans un service informatique, et surtout de pouvoir les supprimer.

1- La Surproduction

En développement informatique, la surproduction consiste à démarrer le développement de fonctionnalités qui ne sont pas nécessaires immédiatement. Typiquement lorsqu’on travaille sur le l’intégration d’un ERP dans une entreprise, l’outil est tellement cher et lourd à mettre en place qu’on essai systématiquement de se projeter dans l’avenir pour que l’outil puisse permettre de répondre aux besoins de demain… Malheureusement, la réalité est souvent différente que ce que nous projetons de faire ! 😉 Résultat des courses, nous avons passé plus de temps sur une fonctionnalité inutilisée et bien souvent nous avons complexifié l’ensemble du logiciel pour introduire cette fonctionnalité qui ne sera jamais utilisée… 🙁

2 – Les Surstocks

La notion de stock est à la fois difficile et facile à transposer… Elle est difficile à transposer, car le stock fait souvent référence à la tête des gens à quelque chose de physique… Mais une fois que cette barrière de l’aspect physique du stock est dépassée alors les stocks apparaissent de partout… Dans le développement informatique, les surstocks sont par exemple un trop grand nombre de fonctionnalités dont le développement est entamé sans être finalisé. Pour éviter les surstocks, les praticiens des méthodes Agiles utilisent le scrum board (Tableau divisé en 3 grandes colonnes : les tâches à faire, celles en cours et celles finalisées) en limitant le nombre de fonctionnalités en cours de développement. Cela se traduit par la nécessité de finaliser une fonctionnalité avant de passer à une nouvelle.

3 – Transports inutiles

Dans le Lean IT, la notion de transport est remplacée par celle de transfert ou de livraison des développements version finalisée. Dans les entreprises traditionnelles, comme les développeurs et les techniciens travaillent de leur côté, les livraisons sont plus rares… Cela donne souvent lieu à des réunions spéciales chez le client… Dans le Lean IT, le développement se fait avec le client si bien que les livraisons intermédiaires ne nécessitent aucun transport supplémentaire.

4 – Surprocesser

Surprocesser consiste à développer des fonctionnalités qui correspondent à des besoins qui n’ont pas été exprimés par le client. Par exemple, cela peut consister à paramétrer un logiciel dans plusieurs langues quand une seule sera utilisée… Le cycle en V traditionnel génère nécessairement de l’extra processing car dans le temps le besoin client évolue… Et comme la livraison est éloignée de plusieurs mois du besoin exprimé, il en résulte des écarts qui se traduisent en manque de fonctionnalités, mais également en fonctionnalités inutilisées. Pour corriger ce problème, les méthodes Agiles partent des besoins du moment. Par ailleurs, les développements sont réalisés avec l’aide du client qui à tout moment peut être amené à préciser son besoin pour orienter le code.

Développement cycle en V

Cycle en V traditionnel…

5 – Mouvements

Dans le Lean IT, les gaspillages de mouvement sont souvent relatifs à une recherche d’informations. Dans les entreprises traditionnelles cela se traduit par :

  • une démultiplication des mails pour demander une information
  • de longues minutes passées à chercher l’information dans un répertoire partagé qui est rarement mis à jour
  • de longues minutes passées au téléphone pour trouver le bon interlocuteur qui aura la réponse à la problématique posée

La question est définitivement résolue par les méthodes Agiles par l’utilisation d’une salle unique pour l’équipe projet. Les murs d’information sont également une solution adéquate pour rendre accessible et visuelle l’information auprès des développeurs.

6 – Erreurs / Défectueux

Les erreurs sont des bugs non décelés lors du développement. Plus un bug est détecté proche dans le temps de son introduction dans le code, plus il est rapide de le corriger… Il est donc essentiel de les détecter au plus vite. Pour réduire les bugs non décelés, les méthodes Agiles systématisent les tests lors de l’intégration de toute nouvelle fonctionnalité. Cette industrialisation des tests fait qu’ils sont rapides à lancer… Cette souplesse dans le lancement des tests joue pour beaucoup dans leur utilisation. Dans les entreprises traditionnelles, les tests sont fait à la fin du projet avant la mise en production… Il est alors difficile de tous les cerner ! Et malgré une phase de test et des tests de montées en charge, il est rare de ne pas voir apparaître des bugs subsistants lors de la mise en production chez le client… 🙁

7 – Temps d’attente

Les temps d’attentes dans les développements informatiques concernent tous les temps de latence qui ralentissent le projet. Cela peut également intégrer les retards de livraison qui induisent des temps d’attente chez le client. Dans les entreprises traditionnelles, un projet qui ne connait pas de retard n’est pas vraiment un projet… Ah ah ah, mdr… 🙁 Dans les entreprises qui pratiquent les méthodes Agiles, la question ne se pose pas, car les livraisons se font toutes les 3 à 5 semaines suite à des « sprint » de développement qui donnent naissance à de nouvelles versions toujours plus proches du besoin final.

Les puristes s’arrêteraient aux 7 gaspillages… mais comme j’aime bien faire un peu de zèle, j’opte pour la version à 9 gaspillages… Vous pouvez donc considérer la fin de cet article comme du bonus ! 😀

8 – Gaspillage de savoir

Il arrive que l’équipe soit confrontée à un problème technique, ce qui oblige à avoir recours à un « expert »… Traditionnellement, cet expert vient débloquer la situation et repart sans nécessairement faire un transfert de compétence à l’équipe. Ainsi, il protège son savoir et l’équipe peut avoir le sentiment de ne pas perdre de temps. Dans le Lean IT, on s’interdit ce genre de chose. Si l’équipe est bloquée sur un problème et qu’elle doit faire appel à un expert, alors ce qui est fait par l’expert sera suivi de près pour que l’équipe puisse s’approprier le savoir et ne pas être de nouveau bloqué si le problème se reproduit.

9 – Gaspillage d’opportunités

De la même façon certaines fonctionnalités peuvent ne pas être utilisées si le recueil des besoins est trop éloigné de la livraison, il peut arriver que de nouveaux besoins fonctionnels surgissent lors du développement. Dans les organisations traditionnelles, cela s’appelle un dépassement du périmètre fonctionnel et se traduit la plupart du temps par une extension budgétaire… 🙁 Dans le Lean IT, c’est une opportunité de satisfaire le client ! Les développements de nouvelles fonctionnalités sont donc intégrés de manière opportune tout au long du projet…

Voilà, c’était les 9 muda du Lean IT, si vous décelez d’autres exemples de gaspillages, je suis preneur ! Alors, n’hésitez pas à les mentionner en commentaire… 😉

Florent FOUQUE  – Excellence Opérationnelle.TV

 

Crédit photo : ChEnected

Recevez gratuitement mon livre pour économiser du temps et gagner en efficacité

Dites-moi simplement à quelle adresse mail je dois vous l'envoyer.

Merci! Vous allez recevoir un mail. :-)

Pin It on Pinterest