Voir la source de Appliquer Kanban aux processus informatiques (2)

[[Category: Portail Lean]]
[[Category: Kanban]]
[[Category: Eli Weinstock-Herman]]
Auteur : Eli Weinstock-Herman<br/>
Source : [https://blogs.lessthandot.com/index.php/itprofessionals/itservicemanagement/applying-kanban-to-it-processes-part-2/ Applying Kanban to IT Processes (Part 2)]<br/>
Date : 08/12/2009<br/>
----
Traducteur : Fabrice Aimetti<br/>
Date : 09/07/2011
----
Traduction :<br/>
<br/>
Cet article est le deuxième d’un ensemble d’articles qui décrit les bases de Kanban et son application dans les processus informatiques. La [[Appliquer_Kanban_aux_processus_informatiques_(1)|première partie]] donnait un aperçu de Kanban et la façon dont il est utilisé dans l’industrie. Les articles qui suivront explorent différents scénarios pour vous aider à trouver des idées s’appliquant à votre propre contexte.<br/>
<br/>
Dans cette deuxième partie de cette série "Appliquer Kanban aux processus informatiques", nous explorons un helpdesk et la manière dont Kanban peut aider à améliorer son image, ses métriques, son moral, sa réactivité et ses délais d’exécution. Les exemples de tableaux et de processus donnés dans cet article ne sont pas destinés à être pris tel quel dans vos processus d’entreprise, mais plutôt pour créer un système basé sur Kanban et l’appliquer dans un cadre fictif. Kanban est une philosophie et non pas un ensemble figé de processus, donc s’il vous plaît rappelez-vous que ce n’est qu’un exemple de la façon dont il pourrait être appliqué dans les cas fictifs décrits.<br/>
<br/>
'''Bienvenue au helpdesk de l’entreprise ABC'''<br/>
<br/>
Je raconte l’histoire fictive d’un helpdesk de l’entreprise ABC qui a décidé de mettre en place un système Kanban pour définir et améliorer ses processus. Les détails de leur processus, les décisions qui furent prises au fur et à mesure et les méthodes utilisées pour communiquer et mesurer l’atteinte de leurs objectifs, doivent être considérés comme des exemples et non des règles. Alors que certaines entités peuvent procéder en une seule étape pour passer de leur processus actuel à Kanban, ce type de transformation instantanée est risqué, surtout si l’entité en question ne dispose pas d’un processus réaliste et bien défini.<br/>
<br/>
"L’année dernière"<br/>
<br/>
L’année dernière, le département informatique de l’entreprise ABC a commencé à être en sous-effectif et à prendre du retard dans ses travaux. La pression financière a forcé la société à retarder les nouvelles embauches pendant plusieurs mois. Malgré ses efforts, le helpdesk a accumulé les retards sur les demandes de support. Grâce au travail acharné et aux heures supplémentaires, l’équipe a réussi à maîtriser son travail et a cessé de prendre du retard, mais le délai moyen entre une nouvelle demande et la tâche associée terminée a continué à être mesuré en semaines. L’augmentation du nombre de demandes de statut et des tâches signifiait que les gens étaient souvent en train de travailler sur dix à quinze tâches simultanément, ils jonglaient même avec des tâches basiques comme la connexion de nouveaux téléphones ou la commande de nouveaux équipements si bien que les utilisateurs finaux estimaient que le département informatique ne se souciait tout simplement pas de leurs problèmes.<br/>
<br/>
"État courant"<br/>
<br/>
Quelques mois plus tard, l’entreprise ABC a effectué de bons recrutements et les heures supplémentaires ont commencé à diminuer. Les membres du département informatique font de nouveau des horaires réguliers et ils sont fiers de la façon dont ils ont réussi à résister. Malheureusement, ce sentiment de fierté ne dépasse pas les murs du département informatique, et les utilisateurs ont une vue très différente. Les utilisateurs finaux croient encore que le département informatique prend trop de temps pour traiter les demandes et que "ne pas prendre de retard" est différent de "traiter la demande le jour même" et l’équipe de direction se demande si les nouvelles embauches ont été efficaces ou même nécessaires, car ils ne voient pas d’améliorations dans les délais ou la qualité de résolution. L’entreprise ABC a une bonne équipe, ils vont donc probablement regagner leur réputation, le temps de résolution des demandes va un peu diminuer, les utilisateurs vont commencer à oublier cette mauvaise période et les dirigeants pourraient même considérer que les embauches ont servi la performance de l’équipe. Cependant, puisque nous sommes des « étudiants » de l’amélioration, nous ne pouvons pas permettre à l’équipe de se contenter de penser qu’elle n’est "pas aussi en retard que par le passé" ou "pas aussi mauvaise que par le passé".<br/>
<br/>
'''Définir l’état courant'''<br/>
<br/>
Avant de tenter d’améliorer le processus, nous devons savoir quel est le processus et déterminer comment il fonctionne. Notre objectif initial sera de définir comment le processus du département informatique fonctionne, y compris les étapes qu’il suit pour terminer le travail et surtout quelle est l’unité de ‘travail’ réelle. A ce stade, nous n’essayons pas de comprendre comment résoudre leurs problèmes ou de déterminer où se situe les goulots d’étranglement, nous essayons simplement de décrire et de définir les processus et les tâches. Dès le départ, nous allons donner aux membres de l’équipe un rôle de supervision, ainsi nous nous ferons sûrement une idée précise du processus.<br/>
<br/>
Après avoir analyser les processus, nous avons constaté que :<br/>
L’entreprise ABC accepte des demandes des clients venant de plusieurs origines différentes, email, téléphone, conversations et une application de gestion de tâches sur le web. Une fois ces demandes reçues, trois choses peuvent arriver : soit la demande est saisie dans l’appli. web, soit la personne qui prend l’appel/l’email/etc. traite immédiatement la demande, soit elle est enregistrée de façon temporaire (post-it, liste de choses à faire dans un email client). Lorsqu’une tâche est terminée, il n’y a pas de processus de suivi afin de s’assurer qu’elle répond aux besoins du demandeur et on ne prend pas le temps de créer la tâche dans l’appli. web si cela n’avait pas été fait préalablement.<br/>
<br/>
"Tableau visuel 1"<br/>
<br/>
Après avoir défini les processus avec l’équipe, nous avons suffisamment d’informations pour partager notre premier tableau visuel. D’après nos observations ci-dessus, nous savons qu’il y a déjà un certain nombre de processus suivis par les gens, nous voulons donc faire aussi simple que possible pour commencer. Notre objectif initial est d’amener les gens à commencer à utiliser ce nouveau processus et qu’ils soient à l’aise avec. Si nous essayons d’élaborer un nouveau processus qui résout tous les problèmes avec de nombreux niveaux de reporting, nous finirons avec quelque chose qui ressemble au système informatique déjà en place et manifestement pas utilisé de façon cohérente. En démarrant simplement, nous pouvons faire évoluer le tableau et le nouveau processus pour mieux répondre aux besoins de l’équipe, plutôt que d’essayer de créer un processus détaillé et « tordre » l’environnement pourqu’il soit conforme au processus.<br/>
<br/>
Dans l’esprit de garder les choses simples, nous avons bâti ensemble notre premier tableau Kanban en utilisant un tableau blanc, un peu de ruban et quelques post-its.<br/>
<br/>
[[Fichier:KanbanPt2 VisBoard 1.png]]<br/>
<br/>
Premier tableau visuel de l’entreprise ABC complété avec les post-its des tâches actuelles<br/>
<br/>
"Note : un autre choix fréquent est d’utiliser des tableaux magnétiques, expérimentez et ne vous enfermez pas dans une seule idée de solution."<br/>
<br/>
"Créer une demande"<br/>
<br/>
Lorsqu’un membre de l’équipe reçoit une nouvelle demande, il doit remplir un post-it et le placer dans la file d’attente « Travail en attente ». Un exemple est placé sur le tableau, avec plusieurs piles de post-its vides et des fournitures pour écrire. L’exemple comporte des champs pour le nom du demandeur, la date à laquelle la tâche a été reçue, la personne qui a pris la demande et une brève description de la demande ou de la tâche. Nous avons maintenant suffisamment d’informations pour identifier des tâches distinctes sur le tableau, déterminer combien de temps il a fallu pour les terminer, trouver la bonne personne si nous avons des questions au sujet de la demande initiale et communiquer avec l’utilisateur final à propos de sa demande. Le processus de création de la demande doit prendre moins d’une minute et le point d’entrée (post-it) est assez simple pour être rédigé tout en parlant au demandeur.<br/>
<br/>
"Traiter une demande"<br/>
<br/>
Lorsqu’un membre de l’équipe commence à travailler sur une demande, il déplace le post-it correspondant de la colonne "Travail en attente" vers la colonne "Travail en cours". Chaque membre de l’équipe a son couloir sur le tableau pour organiser les post-its et montrer clairement qui travaille actuellement sur une tâche donnée. Une fois la tâche terminée, elle est déplacée vers la colonne « En attente retour client » pour indiquer que le membre de l’équipe tente de contacter l’utilisateur final afin de s’assurer que celui-ci est satisfait ou pour lui communiquer de nouvelles modifications ou instructions. Une fois que c’est fait, la tâche est déplacée vers la colonne « Terminé ». Lorsque l’utilisateur final est présent lors du traitement de la demande, par exemple lors de l’installation d’un logiciel ou la mise en place d’un projecteur, la tâche peut passer directement de la colonne « Travail en cours » vers la colonne "Terminé". Quand un membre de l’équipe termine une tâche, il écrit la date de fin sur le post-it de la tâche.<br/>
<br/>
A partir de là, nous laissons un peu de temps à l’équipe pour s’habituer à ce nouveau processus. Chaque matin, nous vérifions le tableau et l’après-midi nous observons la manière dont l’équipe procède et si quelqu’un a éventuellement besoin d’aide pour utiliser le tableau (ou de façon moins passive, nous circulons pour rappeler aux gens d’utiliser le tableau). A la fin de la semaine, nous récupérons les tâches dans la colonne « Terminé » et nous saisissons les dates de début et de fin dans un tableur. En nettoyant la colonne "Terminé" à intervalles réguliers, nous donnons également à l’équipe une mesure visuelle et même un objectif pour la semaine à venir.<br/>
<br/>
Un peu plus tard, on peut proposer d’autres idées concernant le moment opportun pour supprimer des tâches de la dernière colonne. Le but est d’obtenir une vision claire à un niveau élevé de la façon dont les choses fonctionnent correctement ou non. Un autre choix serait donc de supprimer chaque jour les tâches qui datent de plus de sept jours, de sorte que la colonne "Terminé" montre la valeur du travail effectué sur la semaine.<br/>
<br/>
'''Modifications du processus et limites de Kanban'''<br/>
<br/>
Après plusieurs semaines d’utilisation du tableau, l’équipe a pu recueillir les réactions des gens et commencer à travailler sur les prochaines étapes. A présent, l’équipe a pris l’habitude de ce processus et doit normalement l’utiliser de manière cohérente. L’équipe a commencé à utiliser le tableau pour rechercher de nouvelles tâches à traiter, répondre à une question d’un utilisateur final sur le statut d’une demande, et les dates de début et de fin vont commencer à donner une image claire des délais de résolution actuels.<br/>
<br/>
Jusqu’à maintenant, l’objectif a été que l’équipe utilise le tableau et nous n’avons pas mis de limites sur la façon dont les tâches sont sélectionnées, sur le nombre de tâches parallèles sur lequel travaille quelqu’un, etc. Cela a permis à l’équipe de s’engager et de visualiser sa situation actuelle, même si c’est la pagaïe. C’est le bon moment pour commencer à améliorer le tableau et introduire des améliorations au processus.<br/>
<br/>
"Revoir les étapes du processus"<br/>
<br/>
Après avoir parlé à l’équipe et examiné les post-its sur notre tableau actuel, l’équipe a décidé de modifier le tableau en ajoutant un endroit pour les « Tâches escaladées ». Cette modification a été une idée de l’un des membres de l’équipe pour nous aider à mieux suivre les tâches qui ont été escaladées aux Administrateurs systèmes et au Développement afin qu’ils ne prennent pas de place dans la colonne "Travail en cours", nous ne voulions pas les perdre en les sortant complètement du tableau. Pour l’équipe de l’entreprise ABC, cette demande avait du sens, nous l’avons donc ajouter au tableau.<br/>
<br/>
[[Fichier:KanbanPt2 VisBoard 2.png]]<br/>
<br/>
"Tableau visuel de l’entreprise ABC avec une nouvelle étape d’escalade des tâches"<br/>
<br/>
Le helpdesk de l’entreprise ABC utilise un tableau qui définit les processus en termes de statut de la tâche. Bien que ce soit une méthode commune, ce n’est pas le seul moyen de prendre en considération les tâches. Vous pouvez essayer d’autres choses qui peuvent correspondre au cycle de vie des tâches à travers les compétences fonctionnelles (développeur, technicien, administrateurs systèmes), les départements ou les phases (analyse, conception, réalisation, qualification, tests utilisateurs, fin). Il y a toutes sortes de départements informatiques organisés de manière différente et ce qui fonctionne pour l’entreprise ABC peut ne peut être la solution pour vous.<br/>
<br/>
"Les limites de Kanban"<br/>
<br/>
L’une des caractéristiques importantes d’un tableau Kanban, c’est l’idée de limiter la quantité de travail en cours dans le processus. Dans un environnement industriel, nous pourrions utiliser les capacités des équipements pour nous aider à calculer des chiffres pour chaque étape du processus, mais dans notre environnement informatique nous n’avons rien d’aussi évident. Nous pourrions passer des semaines à essayer de trouver des équations ou des chiffres parfaits, mais nous allons simplement choisir arbitrairement quelques chiffres fondés sur le nombre de personnes de l’équipe. Si ces chiffres ne fonctionnent pas parfaitement, alors nous pourrons les ajuster un peu plus tard et expérimenter de nouveau pour trouver notre zone de confort.<br/>
<br/>
Nous allons également attribuer à chaque membre une colonne « principale » où ils ont l’habitude de travailler. Puisque les limites de Kanban imposent un nombre maximal de tâches autorisées dans chaque étape du processus, il y aura des moments où des pans entiers du tableau seront bloqués. Par exemple, si la personne responsable de la colonne "En attente retour client" est surchargée ou en congé maladie, l’ensemble du département sera bloqué parce que la colonne « En attente retour client » est pleine. Lorsque cela arrive, les gens quitteront leur colonne "principale" pour aider à éliminer les goulots d’étranglement.<br/>
<br/>
[[Fichier:KanbanPt2 VisBoard 3.png]]<br/>
<br/>
Tableau visuel de l’entreprise ABC avec des limites définies<br/>
<br/>
"Traitement des tâches"<br/>
<br/>
Le dernier changement sur notre processus concernera la manière de répartir les tâches et la manière dont elles se déplacent à travers le tableau. Jusqu’à présent, nous n’avons pas contraint la manière ou le moment auquel les gens choisiront de travailler sur certaines tâches plutôt que d’autres, ou comment prioriser les nouvelles tâches. Un des concepts importants de Kanban est de tirer les tâches à travers le processus au lieu de les pousser. A chaque étape, les membres de l’équipe choisissent une tâche de l’étape précédente pour travailler dessus et ceci dans les limites imposées par la colonne concernée. Pour permettre d’identifier les tâches qui sont prêtes à être sélectionnées, nous avons ajouté une sous-colonne ombrée à chaque colonne. Pour la colonne "Travail en attente", la sous-colonne ombrée contient les prochaines tâches prioritaires, et pour les autres colonnes il s’agit plutôt d’une sous-colonne "Terminé".<br/>
<br/>
Les tâches terminées comptent systématiquement dans les limites affectées à chaque colonne, donc si le processus se détraque alors le flux de tâches va progressivement se transformer en embouteillage. Au fur et à mesure que les membres de l’équipe vont remplir leurs colonnes amont, ils devront basculer sur les colonnes avales pour aider à résoudre le problème. Ceci garantit que lorsque survient une situation complexe, elle est immédiatement traitée au lieu d’autoriser que tout le monde soit mis sur la touche. Cela garantit également que même les pires situations sont traitées d’une manière opportune et que les délais de résolution sont constamment améliorés.<br/>
<br/>
'''Analyse finale'''<br/>
<br/>
L’équipe a un fait un certain nombre de gains grâce à ce nouveau processus, ce qui a également ouvert la porte à l’amélioration continue et au fait de restaurer une bonne image de l’équipe au sein de l’entreprise.<br/>
<br/>
"Flux de processus"<br/>
<br/>
Initialement, les personnes travaillaient sur plusieurs tâches à la fois, diluant leur concentration et perdant à chaque fois du temps quand ils passaient d’une tâche à l’autre. En l’absence de priorisation, il n’y avait aucune garantie sur l’instant où une tâche serait sélectionnée par un membre de l’équipe, les tâches pouvaient même être égarées ou complètement oubliées. La communication à l’utilisateur final était incohérente et les tâches escaladées étaient rarement communiquées ou suivies, les solutions complexes mises en œuvre n’étaient généralement pas expliquées et généraient des tâches supplémentaires à traiter.<br/>
<br/>
[[Fichier:KanbanPt2 VisBoard 4.png]]<br/>
<br/>
Progression dans le temps du tableau visuel de l’entreprise ABC<br/>
<br/>
Un membre de l’équipe a été affecté à la gestion de la communication avec les utilisateurs finaux. Ce membre de l’équipe est responsable du suivi des demandes avec les utilisateurs finaux, de vérifier le statut des tâches escaladées, de répondre aux demandes de mise à jour des statuts des tâches en attente et d’accompagner les utilisateurs sur des changements ou des solutions complexes. Les nouvelles tâches sont priorisées en fonction du niveau de gravité et de la durée passée dans la file d’attente, elles sont empilées dans une file d’attente dédiée pour que le prochain technicien disponible les traite. Les membres de l’équipe se concentrent sur l’exécution d’une tâche unique à la fois et lorsqu’elle est terminée, ils la transmettent immédiatement à des fins de reporting et sélectionnent la prochaine tâche de plus haute priorité dans la file d’attente. Un calcul statistique de distribution est réalisé chaque semaine pour obtenir le nombre de jours écoulés entre la réception et la résolution des tâches, ce résultat est utilisé comme une métrique par l’équipe et pour les objectifs hebdomadaires.<br/>
<br/>
L’équipe a réalisé des gains sur leurs tâches en attente avec moins d’interruptions, moins d’allers-retours coûteux entre les tâches, et en étant capable de dédier un membre de l’équipe pour la communication avec les utilisateurs finaux. Les utilisateurs finaux reçoivent des communications plus régulières et les estimations de délais sont à la fois plus constantes et plus précises. Le reporting à la direction indique que le nombre total de tâches en suspens diminue alors que le délai total entre la réception et la résolution des tâches a été réduit en termes de variabilité et de durée.<br/>
<br/>
'''Succès'''<br/>
<br/>
Voici quelques-uns de nos succès :<br/>
* Résultats mesurables : nous avons réduit le délai entre la réception et la résolution des tâches, et pour les prochains mois ce délai va continuer à se raccourcir jusqu’à ce que le backlog ait été traité et que nous ayons trouvons notre nouveau rythme.
* Améliorations mesurables : nous avons non seulement mesuré les résultats, mais nous avons pris une photo avant de changer le processus, ce qui signifie que nous avons maintenant des chiffres précis sur la façon dont nous avons amélioré les choses jusqu’ici.
* Statut en un coup d’œil : le tableau visuel permet d’évaluer rapidement l’état d’avancement du département, les problèmes potentiels, l’ensemble du flux de travail ou le rythme.
* Objectifs du département : des mesures précises sur les délais de résolution servent de bon indicateur clé sur la performance du département et fournissent une excellente mesure pour les objectifs annuels.
* Estimations rigoureuses : davantage de données et un processus lissé ont permis de réduire la variation dans les temps de résolution et d’estimer les tâches de façon beaucoup plus précise.
* Moral : faire participer les membres de l’équipe dans la définition de leur propre processus, essayer des idées qu’ils proposent, leur permettre d’expérimenter participent à l’augmentation du moral et du respect, ce qui augmente à terme la productivité, réduit le turnover et rend l’environnement de travail beaucoup plus agréable.
* Productivité accrue : le travail est maintenant exécuté plus efficacement en raison de la réduction des allers-retours entre les tâches, des recherches d’information, des interruptions pour mise à jour du statut et du manque de priorisation.
<br/>
Les avantages décrits ci-dessus sont directement liés à l’application de Kanban dans un environnement général. Dans le cas de l’entreprise ABC, nous pourrions probablement ajouter d’autres gains plus spécifiques à leur environnement, si ce n’était pas une société fictive. Peut-être le plus gros gain est-il que le département fonctionne maintenant à partir d’un tableau blanc. Quelqu’un a récemment déclaré que les tableaux blancs, de par leur nature, invitaient les gens à écrire dessus ou à modifier leur contenu, tandis qu’un papier imprimé invite plutôt à la lecture seule. En quoi est-ce pertinent ? Aucun processus n’est parfait et un processus figé dans la marbre est un processus qui ne se développe pas pour répondre au mieux aux besoins de leur entreprise. En engageant les membres de l’équipe, en expérimentant et en définissant le processus sur un support modifiable, on encourage l’équipe à continuer de faire des suggestions et à continuer à essayer d’améliorer le processus et le département.<br/>
<br/>
Dans le prochain article, nous explorerons l’utilisation d’un processus Kanban temporaire pour gérer un projet fonctionnel court terme. Alors que Kanban est souvent appliquée aux grands processus comme une ligne de fabrication ou un département entier, il y a des avantages à également l’utiliser pour des projets de petites tailles voire jetables. Dans cette prochaine histoire, nous examinerons l’utilisation d’un tableau kanban pour aider à gérer un projet annuel de réapprovisionnement de PC.<br/>
<br/>
'''A propos de l’auteur'''<br/>
<br/>
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.