Publié le 30 septembre 2019, mis à jour le 19 décembre 2023.
Qu’est ce qu’un Kaizen ?
Un Kaizen est un outil de la méthodologie Lean qui peut être traduit du japonais par “Amélioration Continue” en français. L’objectif d’un Kaizen est simple : atteindre un objectif fixé en réalisant des petites actions au quotidien dans le but d’améliorer des processus.
L’objectif à atteindre doit absolument être mesurable au quotidien. Cela est nécessaire afin d’observer clairement l’impact de nos actions sur l’objectif. Il doit également être réalisable dans une période donnée et ne pas être trop ambitieux par rapport au délai prévu. Il ne doit pas être atteignable dès le début du Kaizen, ni être trop ambitieux par rapport au délai prévu. Il peut, par contre, être modifié au cours du Kaizen lorsque c’est judicieux (par exemple lorsqu’il est atteint) pour s’adapter à vos besoins.
Il est très important de noter qu’un Kaizen est un outil qui est là pour vous aider, il ne doit pas être une entrave. Si le Kaizen n’a plus d’utilité ou que vous n’en voyez pas l’intérêt, il faut le modifier ou l’arrêter.
Comment initier un Kaizen dans un contexte d’incidents ?
Un exemple valant mille mots, je vais vous illustrer une situation où Padok a mis en place un Kaizen et a réussi à diviser par 3 le nombre d’incidents en production. Lors d’une mission de consolidation d’infrastructure, Padok a constaté que le nombre d’incidents était important, une dizaine par semaine. Cela avait un impact sur la roadmap ops (beaucoup de temps était dépensé pour corriger ces incidents), sur les équipes de développeurs (qui devaient fix des incidents) et également sur la satisfaction des utilisateurs finaux qui se voyaient parfois privés du service. Nous avons mis en place un Kaizen avec un objectif simple et mesurable: Avoir moins de 5 incidents par semaine. Ceci est représenté par ce graphe:
Dans un premier temps, nous avons défini ce que nous entendons par incident. Est que chaque alerte envoyée par votre outil d’alerting est un incident ? Est ce qu’un problème survenant sur chacun de vos environnements en est un ? Un développeur bloqué par un problème d’ops est un incident ? Ce sont toutes des questions que vous devez vous poser car elles définissent le périmètre des problèmes sur lesquels vous voulez et allez agir. Dans le cas de notre Kaizen, était considéré incident tous les problèmes liés à l’environnement de production et ceux qui bloquaient la validation de fonctionnalités livrées par les développeurs.
Quelle routine un Kaizen engendre t-il ?
Pour traquer les incidents et s’assurer qu’ils ne surviennent plus nous avons recensé les causes des différents incidents et avons créé un pareto :
L’objectif de ce graphique est multiple :
- Définir les tâches à effectuer en priorité en fonction des incidents les plus coûteux
- Connaître les causes éradiquées et les types d’incidents qui ne surviendront plus
- Communiquer avec notre client sur nos actions pour réduire le nombre d’incidents
À l’aide de ce graphique, nous avons pu prioriser nos tâches de façon à diminuer l’impact des incidents le plus efficacement possible. L’aspect communication de ce graphique regroupé avec celui mesurant l’objectif est très important. Ils vous permettent de montrer très simplement l’avancée de vos travaux et votre impact sur le projet, sans que vos interlocuteurs aient à comprendre toute la complexité technique de vos tâches. Le graphique des causes peut aussi vous servir de support pour faire des propositions techniques, comme par exemple une montée de version d’un outil ou une migration vers un nouvel outil DevOps.
Quand adapter ou arrêter son Kaizen ?
Un Kaizen est un outil à personnaliser selon vos besoins et vos équipes. D’autres approches que celle présentée ici sont bien évidemment possibles, comme par exemple axer la mesure sur le temps de résolution d’un incident au lieu du nombre d’incident. La mise en place d’un Kaizen est une discussion que vous devez avoir avec les membres de votre équipe car ça n’est utile et ne fonctionnera que si vous en êtes le moteur. Par ailleurs, il ne faut pas hésiter à adapter son objectif à votre situation : nous avons passé de 5 à 3 le nombre d’incidents maximum que nous voulions par semaine et cela nous a permis de redynamiser notre Kaizen. Ce qui, au final, a permis de diviser par 3 le nombre d’incidents en production chez notre client.