Appliquer Kanban aux processus informatiques (3)

Auteur : Eli Weinstock-Herman
Source : Applying Kanban to IT Processes (Part 3)
Date : 08/12/2009

---

Traducteur : Fabrice Aimetti
Date : 09/07/2011

---

Traduction :

Cet article est le troisième d’un ensemble d’articles 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).

"Les articles qui suivent explorent différents scénarios pour vous aider à trouver des idées s’appliquant à votre propre contexte."

Dans la troisième partie de cette série "Appliquer Kanban aux processus informatiques", nous explorons l’utilisation de Kanban pour gérer un projet fonctionnel court terme. Cet exemple se concentre sur l’utilisation de Kanban pour créer un processus transparent pour suivre le flux des équipements à travers un certain nombre d’étapes complexes, sans générer de coûts supplémentaires pour le logiciel de suivi, de processus complexes et de formation, ou même d’efforts en double. Une meilleure uniformité et qualité des processus de déploiement permettront également d’améliorer l’efficacité et les délais de dépannage mais aussi d’assurer un niveau de documentation élevé par rapport aux standards en termes de gestion de logiciels et de licences.

Bienvenue sur le projet annuel de déploiement des PC de la société DEF

La société DEF est une PME disposant actuellement d’environ 1000 PC et portables déployés. Son service informatique fonctionne comme la plupart des services de cette taille, c’est-à-dire avec un haut niveau de management individuel, des liens solides dans l’équipe et un personnel relativement restreint pour couvrir une grande variété de rôles. Sur les 15 personnes, seulement deux vont travailler sur le déploiement des PC et on leur a donné toute liberté pour s’organiser et effectuer leur travail. L’équipe exige un reporting sur l’état d’avancement qui soit clair et simple afin d’éviter que leur travail acharné devienne un projet invisible. Par ailleurs, il y a un espace de stockage limité pour les équipements non déployés, l’équipe aura donc besoin de bien gérer le nombre d’équipements non déployés ainsi que les commandes de nouveaux équipements.

"L’équipement et les tâches"

Le déploiement annuel de PC doit tenir compte de l’équipement suivant :

• 160 nouveaux PC à déployer
• 40 nouveaux portables à déployer
• 120 PC et 10 portables à mettre à jour et à redéployer

Une image logicielle est disponible pour installer de base un système d’exploitation et un ensemble de pilotes sur chaque PC, en réduisant la variabilité de la procédure d’installation initiale. Des tâches comme l’enregistrement sur le domaine réseau, l’installation de logiciels utilitaires,bureautiques, … doivent devenir le standard d’installation, mais il y aura bien sûr également quelques installations personnalisées de logiciels selon l’utilisateur final ou son rattachement à une entité. Mettre à jour un PC existant passe par les mêmes étapes, avec cependant l’ajout d’une tâche d’audit pour vérifier le passage d’un ancien mode d’utilisation à un nouveau. Si on se base sur l’historique, il est clair que l’un des problèmes les plus perturbants est lorsque l’on doit repasser sur un système (rework*) pour installer un logiciel manquant ou modifier une mauvaise configuration, l’équipe a donc décidé d’ajouter certaines vérifications au processus pour limiter ces risques.

• "Le rework est le nom du processus qui consiste à terminer un élément et le renvoyer à travers une partie du processus pour corriger une étape de production incomplète ou ratée. Dans le cas du déploiement d’un PC, cela pourrait être un logiciel non installé pendant le processus de configuration, de mauvaises permissions allouées, ou toute une douzaine d’autres éléments qui nécessiteraient qu’un technicien revienne sur un PC déjà déclaré "déployé" afin de finir le travail. Les coûts de rework comprennent les coûts liés au fait d’exécuter une seconde fois une étape, de ré-exécuter les étapes suivantes une seconde fois, de basculer de son travail actuel sur l’élément qui nécessite un rework, et les retards liés au fait de terminer les travaux en cours par rapport à l’estimation initiale ou au délai initial."
  

"Première version du tableau visuel"

Après avoir discuté des exigences et des étapes du processus, les techniciens ont créé un processus commun à tous les équipements :

• Réception : le nouvel équipement et l’équipement à redéployer qui n’ont pas encore été "étiquetés"
• Stock : le nouvel équipement et l’équipement à redéployer qui ont été "étiquetés"
• Image : installer l’OS de base, les pilotes et l’image logicielle
• Analyse personnalisée : construire une liste des logiciels client et/ou des paramètres spécifiques pour l’utilisateur final concerné
• Bureautique : installation et configuration initiale des logiciels bureautiques et installation des templates spécifiques à la société
• Utilitaires : installation d’un ensemble standardisé d’utilitaires pour le dépannage informatique et l’audit
• Installation personnalisée : installation des configurations personnalisées
• Audit : exécution du premier audit du PC et mise à jour des liens d’affectation pour un PC redéployé
• Déploiement : déploiement de l’équipement pour l’utilisateur final

Pour gérer les PC à travers ce processus, l’équipe a inventé un « système d’étiquetage » de l’équipement. Les techniciens ont conçu un formulaire check-list copié et mis à jour pour chaque PC. Le coin supérieur droit du document devient la carte Kanban, tandis que le reste est une check-list qui sera utilisée pour vérifier l’étape précédente de chaque étape du déploiement au fur et à mesure que l’équipement progresse dans le processus. Par le passé, l’équipe avait déterminé qu’il y avait en moyenne 5% de rework nécessaire pour pallier une configuration ou un logiciel manquant.



Exemple de formulaire avec carte Kanban prête à détacher

Au lieu d’inclure une étape de QA à la fin de son processus de déploiement, l’équipe a choisi de commencer par vérifier la tâche de chaque étape précédente. En vérifiant le plus tôt possible, l’équipe espère réduire le besoin d’un long processus de QA, réduire la quantité de rework, détecter et corriger le plus tôt possible pour prévenir la répétition tardive des tâches (par exemple exécuter le logiciel d’audit). Des cases à cocher « Fait » et « Vérifié » sont mises à disposition sur chaque ligne du formulaire.

Maintenant que les tâches ont été définies, l’équipe initialise son premier tableau visuel avec du ruban et des étiquettes sur un tableau de liège. Les punaises seront utilisées pour positionner les cartes Kanban liées à chaque pièce d’équipement dans l’étape appropriée du tableau.



Tableau Kanban avec quelques cartes

Les limites Kanban à chaque étape sont basées sur l’espace de travail disponible et sur le souhait de conserver un flux lissé de l’équipement dans le processus. L’équipe a décidé que, pour trouver un juste équilibre entre la régularité du flux (petites limites) et l’efficacité des installations menées en parallèle (grandes limites), elle définirait des limites basées sur les temps d’installation des logiciels pour s’assurer que les étapes les plus longues soient correctement dimensionnées et ne génèrent pas de retards pour les étapes ultérieures. Copier l’image, installer les logiciels bureautiques et exécuter l’audit nécessitent peu d’intervention humaine mais beaucoup de temps, tandis que l’Analyse personnalisée, le Déploiement et les deux étapes restantes d’installation des logiciels nécessitent un niveau élevé de participation et d’attention de la part de l’installateur.

"Créer un reporting"

Il y a un certain nombre d’exigences et de facteurs à prendre en compte pour établir le reporting lié à ce processus. En se basant sur les exigences et les souhaits exprimés par le responsable informatique, l’équipe a produit la liste suivante des points devant faire l’objet d’un reporting :

• Avancement : basé sur le concept d’un burndown, le tableau d’avancement affiche les progrès réels et une date de fin prévisionnelle
• Délai déstocké -> déployé : un graphique simple pour montrer le temps de déploiement réel par rapport à la moyenne et aux années précédentes
• Satisfaction des utilisateurs : un couple de barres horizontales qui affiche le nombre de livraisons réussies à la date prévue et le nombre de déploiements incomplets (rework)

Feuille de calcul et graphiques associés pour le reporting hebdomadaire

Pour générer ce rapport, il faudra mettre à jour la feuille de calcul chaque fin de semaine avec le nombre de PC réellement terminés, incrémenter (le cas échéant) la quantité totale dans une deuxième cellule et indiquer le nombre de PC qui n’ont pas respecté la date de livraison cible dans une troisième cellule. Les projections sont automatiquement mises à jour sur la base d’une équation définie dans le tableur et l’information réactualisée dans les graphiques. Un simple copier/coller des graphiques dans les documents en fin de semaine permet de produire le nouveau reporting hebdomadaire.

Analyse finale

Pendant l’exécution du processus de déploiement, l’équipe a légèrement modifié les limites Kanban ainsi que le mécanisme de reporting, mais elle n’a pas eu d’importants changements à apporter à son processus. Compte tenu de la transparence des travaux, elle a pu rester sur la bonne voie et déployer les équipements à un rythme régulier. Au fur et à mesure qu’elle a ajusté le rythme du processus, elle a commencé à planifier les commandes de nouveaux PC pour que cela coïncide mieux avec la consommation des stocks, lui permettant d’augmenter la taille de ses commandes, de bénéficier de meilleurs devis concernant l’achat des équipements, sans pour autant manquer de travail entre les commandes. Un reporting final a été réalisé à partir des graphiques tirés des rapports hebdomadaires et des informations supplémentaires concernant la réduction des dépenses et du travail.

"Flux du processus"

Tout nouvel équipement ou équipement remasterisé était affecté à un utilisateur et étiqueté avant de démarrer quoique ce soit. Ceci a empêché qu’apparaissent les problèmes survenus au cours des années antérieures, tels que les mauvaises affectations, les doubles affectations et les réaffectations avec les mauvais logiciels. Le processus a également fourni un inventaire précis des équipements disponibles à tout moment, permettant ainsi de répondre aux questions immédiatement plutôt que de demander à quelqu’un de se rendre dans l’espace de stockage et d’effectuer un inventaire. Une communication au plus tôt avec l’utilisateur final sur la date à laquelle l’équipement serait disponible, a réduit la difficulté à déployer les PC qui étaient prêts, les utilisateurs finaux étant préalablement avertis, ceux-ci pouvaient aider à mieux définir leur disponibilité, avec comme conséquence de réduire la replanification des installations comparativement aux années antérieures. La vérification immédiate des étapes antérieures et les limites Kanban ont favorisé un flux lissé des équipements dans le processus, en fournissant les bases d’un temps de cycle plus cohérent et reproductible. Une meilleure estimation de la durée du processus de déploiement (disponibilité des stocks) a permis de réaliser des économies budgétaires directes, tout en permettant à l’équipe d’augmenter la taille de ses commandes et de profiter de meilleures économies pour la même quantité d’équipements. Enfin, le mécanisme de reporting créé par l’équipe était assez simple pour que le responsable informatique soit capable de l’utiliser lors de chaque réunion de département, sans devoir passer la nuit précédente dessus pour tout préparer.

"Succès"

Voici quelques-unes des succès de l’équipe :

• Visibilité 100% : visibilité dans le processus et l’inventaire à tout moment, sans effort supplémentaire consacré au suivi des techniciens ou au comptage à la volée de l’équipement
• Moral amélioré : réduction de la confusion et de la négativité des utilisateurs finaux dans l’attribution des équipements en se basant sur des communications claires et un véritable processus d’affectation
• Gains de temps : aucun rework est synonyme de gain de temps dans le processus de déploiement, ainsi que dans la suppression des interruptions que causaient le rework
• Gains financiers : une meilleure estimation et une meilleure gestion des stocks a permis d’augmenter la taille des commandes sans nuire aux délais de réalisation
• Marketing bon et peu onéreux : le processus simple pour générer les rapports a non seulement apporté un gain de temps, mais a aussi produit des métriques assez simples pour qu’elles soient réutilisées lors des réunions managériales avec une publicité positive sans pour autant exiger plus de temps et d’efforts de la part du responsable informatique
• Productivité accrue : en se fondant sur la cohérence du processus, l’amélioration des estimations, la réduction du niveau d’interruption constatée sur les précédentes années, l’ensemble du processus prenait moins d’heures de travail à dérouler
• Amélioration mesurable : les statistiques identiques sont suivies attentivement pendant l’exécution du processus et permettent de constater en fin d’année les améliorations au niveau de l’équipe et du département.

Les succès énumérés ici couvrent aussi bien des aspects durs (financier) que mous (moral) et ne couvrent probablement pas l’ensemble des succès qui auraient pu être obtenus dans une version non-fictive de cette histoire. En un mot, le processus a pu s’exécuter de façon plus facile, plus efficace et plus prévisible, ce qui a généré au niveau de l’équipe un certain nombre d’améliorations mesurables par rapport aux années antérieures. Ce même processus sera réutilisable dans les années à venir, et peut désormais être utilisé comme une base pour de nouvelles améliorations ou pour permettre de porter les efforts sur l’amélioration d’autres processus puisque celui-ci se déroule simplement et en douceur. Même si utiliser un système Kanban pour un processus temporaire n’est pas fréquent, il démontre sous un autre angle la façon dont il peut être utilisé pour « apprivoiser » des processus de travail complexes et promouvoir l’amélioration globale du processus.

Dans le prochain article, nous explorerons l’utilisation de Kanban par une équipe de développement logiciel qui cherche à livrer et maintenir un ensemble de produits. Bien qu’il existe déjà beaucoup de comptes-rendus réels de la part de personnes appliquant Kanban au processus de développement logiciel, le développement est une activité notoire d’un département informatique et je serais négligent si je n’apportais pas ma touche personnelle sur la façon dont Kanban peut être utilisé par une équipe de développement.

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.