De la résolution de problèmes au Kaizen

kaize6points

Le développement des personnes est au cœur de la démarche lean. Développer en temps et en heure des produits incroyables que les clients adorent nécessite des collaborateurs impliqués et engagés dans l’amélioration continue de leur performance, comme les sportifs de haut niveau peuvent le faire. Tous les outils fournis par le Toyota Production System ont un seul et unique objectif, aider les collaborateurs à identifier les gestes qu’ils ne maîtrisent pas totalement pour leur donner la possibilité de faire de la résolution de problèmes et ainsi améliorer eux-mêmes leurs méthodes de travail et progresser vers l’excellence.

Le lean décrit un problème comme un écart à un standard établi. En d’autres termes, le client attend quelque chose que le processus ne rend pas. Dans les services ou l’informatique, un standard de travail se traduit par un temps de cycle et une séquence de travail. Par exemple, dans un service d’expertise automobile, pour répondre à la demande client, une équipe doit sortir trois dossiers par jour. Malheureusement, avec le processus actuel, elle ne peut en traiter que deux. Afin de combler cet écart, l’équipe met en évidence les obstacles dans la mise en œuvre du processus puis identifie quelles sont les causes. Elle s’appuie pour cela sur la technique du PDCA (Plan, Do, Check, Act). Obstacle après obstacle, elle détermine les causes racines et les supprime par des actions successives d’amélioration qui sont mesurées avec précision. Après un certain nombre d’expérimentations, l’équipe progresse dans sa compréhension de son processus et dans la manière de l’exécuter. Les collaborateurs acquièrent de nouvelles compétences, il y a moins d’erreurs, la performance se stabilise autour du standard attendu.

Dans le même temps, les conditions se modifient. Les besoins des clients évoluent, la demande augmente, les délais sont raccourcis ou, tout simplement, il est nécessaire d’augmenter la performance des processus pour faire face à une concurrence nouvelle. Le niveau d’exigence est donc relevé, la barre remonte d’un cran. L’équipe se retrouve donc dans une situation où sa performance est stable mais en deçà des performances attendues par le nouveau standard.

Dans ces conditions, comment procéder ? Les obstacles ne sont plus aussi évidents. Un travail d’investigation est donc nécessaire pour déterminer si le processus actuel offre le potentiel nécessaire pour que les équipes puissent atteindre le nouvel objectif. Les équipes devront ensuite réfléchir à de nouvelles idées quelques fois non conventionnelles pour progresser. Cette manière de procéder s’appelle le Kaizen. Elle se décompose en 6 étapes :

  1. Découvrir le potentiel d’amélioration
  2. Analyser la méthode actuelle
  3. Générer des idées nouvelles
  4. Élaborer un plan de test des idées
  5. Mettre en œuvre le plan
  6. Evaluer la méthode

Découvrir le potentiel d’amélioration

La performance de l’équipe est stable mais en deçà du nouvel objectif fixé par les nouvelles conditions du marché. Prenons par exemple une équipe informatique en charge du développement d’applications télécom. La demande des clients en applications nouvelles et en modifications de l’existant ne cesse de croître. Jusqu’à ce jour l’équipe a fait face. Cependant la charge est devenue telle que le team leader demande à sa direction d’augmenter les effectifs de 2 personnes. Cette demande est refusée. Deux possibilités s’offrent à l’équipe : travailler plus ou travailler différemment.

Le team leader opte pour la seconde solution. Il s’agit donc pour lui et ses collaborateurs de découvrir quel potentiel offre le processus actuel. Cette recherche se passe sur le terrain là où le travail est effectué en observant les activités des collaborateurs. Ces observations sont effectuées en notant toutes les activités qui ne sont d’aucune valeur pour le client.

L’équipe commence par dessiner son processus sur un tableau blanc. Il n’est pas très compliqué et se découpe en 4 étapes : Analyse, Développement, Test d’intégration et packaging. Elle découvre de l’attente à chacune des étapes. Le développement ne débute que si toutes les spécifications sont écrites complètement. Ce mode de fonctionnement provoque deux types d’attente. La rédaction des spécifications nécessite des précisions des clients qui tardent à arriver. Sur le précédent projet au moins 10 jours ont été perdus à attendre l’information du chargé de clientèle. Le team leader et le leader technique constatent d’autre part qu’il n’est pas du tout nécessaire d’attendre avant de commencer à coder. Finalement une grande partie des spécifications attend dans le backlog des développeurs. La phase d’intégration est aussi très lente. Par exemple tester les modifications du serveur d’authentification prend à chaque fois une quinzaine de jours. Or chaque projet touche à cette partie du système. La multi compétence de l’équipe sur cette partie des tests ne suffit plus. La phase de packaging est aussi sensible. Elle est manuelle et malgré des standards de travail très élaborés pour éviter les erreurs, cette étape prend un à deux jours de travail. Après analyse l’équipe identifie un potentiel d’amélioration de 1,7 ETP en gaspillages divers qui, si elle les adresse, lui permettrait d’absorber la nouvelle demande client.

Analyser la méthode actuelle

Une fois le potentiel établi, il s’agit pour l’équipe de repartir du processus actuel et de montrer à chaque étape ce qui pourrait être amélioré :

  1. Les problèmes de qualité
  2. Les problèmes de synchronisation sous forme d’attente multiples
  3. Les gaspillages

L’équipe décide lors d’un point technique de s’adresser à ce qu’elle estime apporter le plus gros potentiel : le processus de rédaction des spécifications et les tests du serveur d’authentification. Elle commence par les tests car c’est de son point de vue ce qui est le plus rapide à mettre en œuvre. L’expert du serveur explique qu’il y a 1500 tests dans le plan de tests. C’est un composant critique du système. Il est donc inenvisageable de ne pas tous les passer. En revanche si on regarde bien le plan il est possible de classer les tests en 3 catégories en fonction de leur complexité. La catégorie des tests simples représente 55 % du volume. Les tests un peu plus techniques qui nécessitent des connexions avec les différents composants du système représentent 25 % du volume et les tests complexes 20 %.

Lors d’un second point l’équipe se réunit avec le chargé de clientèle et un architecte afin d’étudier le processus actuel. Les spécifications sont écrites en partie par le client. Elles sont remises ensuite à l’architecte qui les complète. Elles sont ensuite revalidées par l’architecte du client. En parallèle l’architecte et le chargé de clientèle estiment la charge de travail. Il y a beaucoup d’allers-retours avec le client et surtout beaucoup d’attente. Le leader technique fait remarquer d’autre part qu’aucune personne de l’équipe de développement ne participe à la conception des spécifications. A ce stade, personne ne sait comment s’y prendre mais un consensus s’établit avec chacun sur le fait qu’attendre que les spécifications soient complètement décrites n’est pas une solution efficace et que l’équipe de développement devra être représentée : c’est une idée nouvelle.  Il est décidé de faire un premier test de cette idée avec la prochaine application.

Générer des idées nouvelles

A partir de ce bilan, l’équipe peut commencer à réfléchir aux idées d’amélioration qu’elle pourrait apporter pour supprimer les obstacles identifiés précédemment. Au cours de cette phase, la réflexion est très ouverte. Une façon de faire, observée dans différentes équipes, est de se confronter à l’état de l’art, de rechercher ce que les meilleurs font et de s’en inspirer.

Revenons à notre exemple. L’idée qui vient immédiatement à l’esprit de chacun est d’automatiser les tests simples. Le team leader objecte que pour automatiser le système il faudrait développer un client pour se connecter au serveur. Or les tests se font à partir d’un téléphone mobile qui accède à une passerelle qui, elle, dispose du client qui se connecte au serveur d’authentification. Le leader technique répond qu’il connaît l’équipe qui développe la passerelle et qui dispose d’une bibliothèque de code. Il suffit de leur demander. L’équipe réfléchit ensuite à la manière de traduire le plan de tests dans un langage simple et interprétable pour une automatisation. Les premières idées émergent :

  • Récupérer les sources du client du serveur d’authentification
  • Ecrire un premier langage de tests de haut niveau
  • Ecrire le moteur d’interprétation du test
  • Ecrire le module de rendu des résultats de test

Concernant les spécifications, l’équipe décide de tester deux choses :

  1. de créer une core team entre le chargé de clientèle, l’architecte et le leader technique ;
  2. de tester un premier découpage en petites fonctionnalités ;
  3. de changer le management visuel pour suivre l’avancement de chaque fonctionnalité afin de pouvoir réagir au plus vite avec le client en cas de manque d’information.

L’idée est de pouvoir commencer les développements au plus tôt sans attendre que tout soit spécifié.

A ce stade, l’équipe dispose d’une liste d’idées couchées sur le papier qu’il va falloir tester.

Élaborer un plan de test des idées

L’équipe doit ensuite élaborer un planning et une méthode de test pour chaque idée. La méthode de test est très importante car c’est elle qui permettra de confirmer si la solution proposée contribue à améliorer la performance du processus ou pas.

Le team leader expose les idées de son équipe au management. Son objectif est de dégager du temps pour mettre en œuvre les idées de l’équipe. Sa présentation est un succès. L’analyse chiffrée et les actions proposées pour augmenter la capacité de l’équipe ont séduit le management qui accepte de donner un jour par semaine à l’équipe pour l’amélioration continue. Un plan d’action est établi pour l’automatisation des tests et le nouveau processus de conception.

Mettre en œuvre le plan

La mise en œuvre du plan consiste à réaliser les différentes actions et les mesures de performance en même temps.

Le team leader décide avant de lancer les actions de mettre en place un certain nombre d’indicateurs de performance. Il a besoin de savoir si les expérimentations vont bien donner leurs fruits. Il installe les indicateurs suivants :

  • Un indicateur de délais pour mesurer la durée des tests du serveur d’authentification
  • Un indicateur de délais pour mesurer le respect des dates de livraison des applications et des modifications
  • Un indicateur de productivité pour mesurer l’efficacité des actions entreprises

L’équipe s’organise ensuite rapidement pour faire fonctionner le plan. Très vite, l’équipe obtient ses premiers résultats.

Evaluer la nouvelle méthode

Il s’agit de tirer les bons enseignements de la nouvelle méthode. Où en sommes-nous par rapport au standard ? Nous sommes nous rapproché de l’objectif ? Qu’est ce qui a bien fonctionné ? Que doit-on garder ou abandonner ? Quelles sont les prochaines étapes ?

Au bout d’une semaine, un premier test est écrit et exécuté avec succès ce qui permet de valider le principe de l’automatisation. La semaine suivante, les fondations du langage d’écriture des tests sont prêtes. En parallèle, une première version de l’interpréteur est mise à disposition.

Le premier plan de test automatisé est prêt à être écrit. Chaque jour, de nouveaux tests sont intégrés. Un des développeurs a créé un script qui permet désormais de lancer les tests chaque nuit. Ce procédé a permis à l’équipe de découvrir très rapidement des erreurs de codage qui ont été corrigées immédiatement, d’une part, et d’autre part de dégager du temps pour alimenter plus rapidement le plan.

Après 6 mois, l’équipe fait son bilan. La plateforme de test est bien avancée. 80% des tests simples ont été codés. Quelques obstacles ont ralenti l’équipe sur certains tests ce qui explique l’écart. Cependant, devant ces bons résultats le management a proposé de faire intervenir un prestataire pour un mois pour accélérer le développement des tests restants. Pour l’instant l’équipe a gagné 4,5 jours sur chaque campagne de test.

D’autre part la core team a développé de nouvelles compétences lui permettant de découper les spécifications en petites fonctionnalités qui sont mises à disposition de l’équipe de développement en juste à temps.  Le management visuel a été d’un grand secours et a permis à l’équipe de réagir très rapidement et de réduire considérablement les temps d’attente avec le client.

Le team leader est très content. Ses indicateurs de performance montrent une nette amélioration de la situation. L’objectif fixé par le management est en passe d’être atteint sans que l’équipe n’ait souffert d’une surcharge de travail.  Au contraire le fait de développer ses propres méthodes de travail a motivé considérablement l’équipe. Son processus de développement logiciel est totalement différent d’il y a 6 mois. Les nouvelles pratiques expérimentées par l’équipe offrent de nouvelles perspectives totalement hors de portée il y a 6 mois. L’augmentation de capacité est de plus ou moins 1,5 ETP. Le standard est sur le point de changer une nouvelle fois.

Une réflexion sur “De la résolution de problèmes au Kaizen

Répondre

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l'aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s