Appliquer Kanban aux processus informatiques (5)
Auteur : Eli Weinstock-Herman
Source : Applying Kanban to IT Processes (Part 5)
Date : 30/12/2009
Traducteur : Fabrice Aimetti
Date : 14/07/2011
Traduction :
Cet article est le cinquième et dernier d’une série qui décrit les bases de Kanban et son application dans les processus informatiques :
- La première partie donnait un aperçu de Kanban et la façon dont il est utilisé dans l’industrie.
- La deuxième partie donnait un aperçu de Kanban et la façon de l’utiliser dans un service helpdesk (fictif).
- La troisième partie donnait un aperçu de Kanban et la façon de l’utiliser dans un projet de déploiement de PC (fictif).
- La quatrième partie donnait un aperçu de Kanban et la façon de l’utiliser dans un projet de développement logiciel (fictif).
Dans chacune de ces histoires, la mise en œuvre de Kanban est réussie et il y a des améliorations positives sur une période de temps assez courte. Ce dernier article aborde brièvement certains des défis auxquels il faut faire souvent face et le concept d’amélioration continue. Contrairement aux articles précédents de la série, celui-ci n’a pas d’illustrations, donc je m’excuse d’avance auprès des membres qui préfèrent lire plus d’images que de texte (George * tousse *).
Mettre en œuvre Kanban
Les histoires fictives narrées dans les articles précédents ont toutes suivi un thème commun, l’amélioration réussie du processus en faisant face à peu voire pas de défis. Toutefois, pour ceux d’entre nous qui travaillent dans le monde réel, nous sommes tous conscients qu’aucun projet ou processus ne peut être lancé sans rencontrer de difficultés. Même si s’attaquer à tous les défis potentiels – que l’on pourrait relever dans l’environnement de chaque lecteur – va bien au-delà de mes compétences et de la portée du présent article, il y a deux défis auxquels la plupart d’entre nous devront faire face dans la mise en œuvre de Kanban dans les environnements informatiques.
"Changer les habitudes"
En plus des défis qui consistent à définir nos processus et à tenter de standardiser des tâches qui sont souvent des exceptions, appliquer un processus Kanban va également nous obliger à remettre en question certaines habitudes bien ancrées. L’idée de limiter la quantité de travail en cours (WIP) dans une étape peut sembler bonne lorsque vous la lisez dans un article, mais en fait se soumettre à des limites est très difficile au début. Les divers styles de management ont tendance à se concentrer sur le temps passé à travailler ou sur le nombre de tâches qu’une personne a terminées et, dans ce cas, s’arrêter de travailler pendant une étape est apparenté à croiser ses pieds sur son bureau et faire une sieste.
Kanban nous oblige à faire face à ces systèmes de mesure et à corriger certains des défauts auxquels ils mènent dans nos processus. Plutôt que de mesurer à quel point une personne travaille dur pendant une étape, nous allons mesurer la façon dont nous livrons à travers le processus entier. Plutôt que de mesurer le nombre d’heures travaillées par une personne, on peut mesurer le nombre d’heures de travail que nous avons gagnées dans le processus. Là où l’ancien système de mesures se demande pourquoi nous n’empilons pas plus de travail entre les étapes de Développement et de QA, Kanban nous oblige à remettre en question la façon dont nous pouvons améliorer le débit ou diminuer le taux de rework (NdT : rework = du travail à refaire.). Des habitudes bien ancrées sont difficiles à changer. Au lieu de directement remettre en cause ces croyances, nous allons commencer par modéliser le processus et les tâches qui y circulent. Il y a quelques défis à relever dans ce processus de modélisation, mais une fois que la visualisation est en place et que vous commencez à impliquer les autres dans le fait d’améliorer cette visualisation et donc le suivi des tâches, beaucoup de ces défis vont disparaître. La capacité à voir le flux des tâches s’écouler à travers le processus répond au besoin de nombreuses personnes, en offrant une visibilité et un aperçu du processus qui, auparavant, étaient dirigés par l’estimation et des conjectures occasionnelles.
"L’informatique ce n’est pas une chaîne de fabrication industrielle"
Un autre défi fréquent que l’on rencontre avec Kanban c’est que, tirant son origine de l’industrie (NdT : Kanban a été déployé à la fin des années 50 dans les usines Toyota.), on considère du coup qu’il n’est pas approprié pour un environnement informatique. C’est un argument très largement opposé à Kanban (et aux principes du Lean en général), et il a été solidement réfuté dans un grand nombre d’industries. L’idée que des pratiques ou des connaissances d’une industrie ne peuvent pas être utilisées pour améliorer notre compréhension dans d’autres types d’industrie, semble un peu égoïste, surtout lorsqu’on ajoute qu’un domaine est trop spécialisé pour apprendre quelque chose des autres. Si tel était vraiment le cas, les progrès médicaux réalisés grâce au programme spatial n’auraient jamais eu lieu, pas plus que des centaines d’autres concepts et idées qui ont traversé les frontières de l’industrie pour générer de nouvelles idées ou produits dans d’autres types d’industrie.
Parfois l’argument est formulé de manière plus nuancé, en citant la différence entre les usines de fabrication produisant des pièces identiques et en série et les tâches en constante évolution dans un environnement informatique. Passez quelques minutes sur votre moteur de recherche préféré et vous trouverez des exemples dans un certain nombre d’industries, y compris le développement logiciel, où Kanban a non seulement été mis en œuvre avec succès, mais a montré le chemin vers l’amélioration continue et d’autres pratiques ayant des racines dans les chaînes de fabrication industrielles. Bien que cela ne soit pas une réponse formelle ou philosophique, je ne vois pas pourquoi on passerait du temps à formuler une preuve logique pour quelque chose de si facilement observable.
Appliquer Kanban n’est pas sorcier, mais il exige de la réflexion et du temps. Heureusement, il y a des communautés entières de gens qui sont prêts à répondre à vos questions, à faire appel à des experts et à proposer de bons livres.
Pourquoi Kanban
Les articles précédents ont illustré la mise en œuvre de Kanban dans des environnements fictifs, mais nous n’avons pas passé beaucoup de temps à expliquer comment ou pourquoi il fonctionnait comme cela. Les articles n’ont pas donné de détails sur les méthodes utilisées par les équipes pour identifier des zones d’amélioration ou la façon dont ces améliorations ont été traitées. Opérer des changements dans des processus réels peut être aussi simple que nos histoires mais parfois un peu plus difficile. Ce que Kanban nous offre, c’est un outil qui nous aide à localiser les points chauds (NdT : en Agile on dit "faire émerger les problèmes.") sur lesquels concentrer nos efforts pour obtenir le plus grand effet de levier.
Au fur et à mesure que nous mettons en œuvre Kanban, nous commençons à réaliser les tâches d’une manière cohérente. Cette cohérence améliore notre vitesse d’exécution parce que nous pouvons faire des hypothèses sur les tâches que nous recevons ; elles répondent à un certain niveau de conformité et partagent un certain ensemble d’exigences et de caractéristiques. Cela réduit le nombre de fois où nous étions amenés à retourner sur les étapes amonts, à router les tâches vers de nouvelles étapes exceptionnelles, ou à inventer des processus à la volée. L’acte en lui-même de créer le tableau Kanban nous aide à trouver ou à construire cette cohérence, et réduit encore davantage le temps perdu à déterminer où les tâches devaient être routées ou à connaître leurs statuts actuels. Le tableau fournit une vue haut niveau des tâches ou des groupes de tâches se déplaçant à travers le processus, faisant clairement apparaître les goulots d’étranglement et les remous dans le flux, ceux-là même qui ne sont pas visibles de l’intérieur du processus. L’analyse des causes racines des goulots d’étranglement nous montre les endroits où mener une amélioration locale sur une étape qui peut directement entraîner une amélioration du processus dans son ensemble.
"Amélioration continue"
Le terme « Amélioration Continue » est apparu dans plusieurs articles et le concept est présent dans chacun d’eux. Le principe de l’amélioration continue est de faire de petites et progressives améliorations à un processus qui, sur le long terme, permettront d’obtenir de grosses économies et des améliorations sur la qualité. Des améliorations individuelles sont obtenues par la recherche et l’analyse d’un gaspillage dans le processus (tels que le gaspillage de matériel, le mouvement et les risques de sécurité) ou de plusieurs gaspillages dans une seule étape du processus (tels que la détection des défauts dans l’article concernant le développement de logiciels). En déterminant la cause racine de ce(s) gaspillage(s), et en effectuant des petits ajustements sur le processus pour réduire ou éliminer ce gaspillage, les objectifs ou les méthodes d’amélioration deviennent utilisables. En éliminant lentement mais sûrement les gaspillages dans nos processus, nous améliorons la qualité, les coûts et le rythme de notre processus.
Kanban soutient ces efforts d’Amélioration Continue en fournissant un flux cohérent et la visualisation de notre processus. La visualisation et la standardisation du processus permet de rendre davantage visible les exceptions et les goulets d’étranglement, nous donnant des pistes claires d’amélioration. Une fois que les améliorations ont été réalisées, le tableau Kanban peut alors nous montrer la manière dont ces changements ont affecté et amélioré le processus dans son ensemble, si ces améliorations ont permis de découvrir de nouveaux problèmes, ou si elles ont échoué à résoudre le problème à la racine.
"Coûts et Qualité"
Bien que Kanban nous fournisse la capacité à localiser les problèmes et à améliorer le processus, ce qui permet de réduire nos délais de livraison, il ne fournit pas nécessairement des outils pour réduire les coûts ou améliorer la qualité. Bien que nous ayons vu la qualité et les coûts améliorés dans nos articles fictifs, cela a été souvent été une conséquence de l’amélioration du temps de cycle en éliminant un goulot d’étranglement. Cependant, Kanban nous fournit quelques indications qui peuvent être réutilisées. Comme avec le temps de cycle, si nous voulons améliorer la qualité ou les coûts, nous devons utiliser notre processus et localiser où nos problèmes de coûts et de qualité apparaissent et nous concentrer sur ces zones.
Exemple d’amélioration continue
Par exemple, si nous souhaitons nous concentrer sur la qualité, nous pouvons créer des standards définissant le niveau de qualité dans notre produit final et commencer à tester leur respect. Pendant les tests, nous pouvons suivre les cartes (ou lots) qui échouent sur le test de qualité et qui génèrent du rework (article 3) ou qui sont abandonnées et ensuite remplacées suite à un travail supplémentaire. En utilisant la fréquence d’apparition des problèmes et les coûts générés pour produire une tâche avant que chaque problème de qualité soit trouvé, nous pouvons créer une répartition des coûts assez simple pour déterminer nos plus grosses opportunités d’amélioration. Dans certains cas, nous pouvons constater les problèmes de qualité en dehors de notre processus, dans d’autres processus, et nous devons donc conduire les tests le plus tôt possible dans notre processus pour réduire les efforts investis avant que les problèmes soient découverts.
Qualité / Délais / Coûts : le tout ensemble, svp
En informatique, nous citons souvent le triangle coûts / qualité / délais aux personnes qui s’attendent à avoir les trois ensemble sans aucun travail ou investissement supplémentaire. En utilisant l’exemple ci-dessus, on pourrait facilement remplacer la qualité par les coûts et construire une méthode simple pour trouver les meilleures opportunités de réduction des coûts. Mais étant donné que les gaspillages impactent souvent plus d’un sommet du triangle, on peut choisir d’améliorer nos temps de cycle, la qualité ou les coûts et du coup améliorer les autres.
Il n’est pas rare dans le monde de l’industrie de diminuer les problèmes de qualité, de délais et de coûts suffisamment pour améliorer la capacité de 25 à 50%, et ceci sans embaucher de nouveaux employés ou acheter de nouveaux équipements. En informatique, on compte souvent sur la technologie pour améliorer les choses, mais la technologie est quelque chose que n’importe lequel de nos concurrents peut acheter et la disponibilité est dictée par le marché, et non par nos besoins. Pour prendre de l’avance sur nos délais et nos concurrents, pour passer des vacances tranquilles ou pour obtenir des augmentations qui soient au-dessus du taux d’inflation annuel, nous devons aller au-delà de ce que les fournisseurs offrent et créer une meilleure qualité de service et un meilleur engagement de l’entreprise. Réduire les coûts, améliorer la qualité et réduire les délais de livraison impactent la dernière ligne du bilan de fin d’année et améliorent l’efficacité du reste de l’entreprise. Et dans le cas où une entreprise est moins intéressée par l’efficacité et plus intéressée par le nombre d’heures sur l’horloge, des améliorations successives peuvent aussi constituer d’excellentes expériences sur les CVs.
Plus d’opportunités
Il y a beaucoup d’autres possibilités pour Kanban que celles décrites dans mes autres articles, et il existe de nombreux autres articles de fond. Les trois exemples contenus dans les articles précédents ont été choisis pour exposer une grande variété de problèmes :
- Un helpdesk qui gère un nombre inconnu de tâches à la demande, chacune composée d’un ensemble complètement différent de sous-tâches
- Un processus de déploiement de PC semblable à une chaîne de fabrication, mais nécessitant deux personnes pour s’occuper des multiples étapes d’un processus qui n’est utilisé que tous les 1 ou 2 ans.
- Un processus de développement logiciel qui définit ses propres tâches à partir d’un sous-ensemble de features.
On peut espérer que ces trois exemples soient assez proches de nos contextes respectifs pour que nous puissions avoir des idées sur la façon d’y appliquer Kanban. Je vous donne d’autres idées :
- Un concepteur de rapports peut définir un processus commun de conception, développement, modification et déploiement de rapports et commencer à traquer les inefficacités qui enlisent le processus.
- Un administrateur de base de données peut commencer à regarder les mécanismes de file d’attente des transactions et créer une visualisation de type Kanban du processus pour aider à éliminer les goulots d’étranglement en concentrant ses efforts d’amélioration du processus dans son ensemble.
- Un administrateur système peut concevoir un processus de mise à jour de la planification de chacun des domaines fonctionnels et commencer à boucler sur la liste complète des domaines à travers ce processus, chaque fois qu’il réduit le travail ou le temps mis en œuvre dans l’évaluation de nouvelles options technologiques ou dans la mise en œuvre des correctifs et de la maintenance.
Remerciements
Je tiens à remercier tous ceux qui m’ont aidé à relire et modifier ces articles. Au cours de leur publication, j’ai pris à chaque fois un peu d’avance pour finir la rédaction de l’article avant qu’il soit publié et l’aide de plusieurs membres a été inestimable :
- Tim (Riverguy) et David (Thirster), qui ont détecté quelques erreurs critiques dans les tout premiers articles
- Erik (Emtucifer), qui a relu de façon très approfondi le premier article
- Fionnuala (Remou) qui a relu les articles suivants, et a sauvé l’un de mes articles de la mort
- Ted (onpnt) pour avoir relu (ou avoir fait semblant de relire) chaque article et avoir régulièrement fourni des retours positifs.
A propos de l’auteur
Eli Weinstock-Herman : Eli a plus d’une dizaine d’années d’expérience dans les architectures logicielle et système, le développement web, la programmation sur bases de données, l’administration de bases de données, l’architecture et l’intégration de systèmes industriels, l’administration de systèmes, … dans plusieurs secteurs industriels, en passant par l’éducation et l’industrie pour aller jusqu’au consulting et le développement SaaS. Ses billets reflètent cette diversité, en visitant une variété de sujets, notamment l’amélioration des processus, le codage, la qualité, l’administration de systèmes, les pratiques de développement et l’architecture logicielle.
