Flux de travail d’une équipe data center

Le contexte

J’accompagne une équipe Data center & hardware depuis plus d’un an, en même temps que celle-ci. Et c’est loin d’être simple, car il y a quelques spécificités à prendre en compte. Le flux de travail d’une équipe data center est en partie le même que l’infra, mais plus dédié à la gestion de l’équipement matériel. Il consiste à gérer des incidents, des demandes et des projets portés par l’infra (chantiers base de données, études hardware associées à des réflexions base de données par exemple), mais également portés par l’IT plus globalement.

Cet article peut également vous interesser : Kanban pour une équipe infra office. 

Première génération de tableaux Kanban

Au démarrage de l’accompagnement, nous avions décidé de mettre en place deux tableaux kanban car deux flux de travail majeurs étaient identifiés : les incidents et le reste.

L’idée initiale était de pouvoir observer le flux des incidents et utiliser le kanban pour déterminer s’il y avait engorgement et où il se trouverait.

Pour chaque tableau, on trouvait les éléments classiques de la plupart des tableaux kanban : Backlog, Ready, WIP, Done.

Les blocages

Une des particularités de ce type d’équipe est d’être fortement dépendante d’équipes externes (fournisseurs – devis & livraison, demandeurs, autres services, …). Et donc un zoom a été mis en place pour regarder dans le détail les différentes sources d’attentes et de blocages :

• Delivery
• Externe
• Interne
• Achat
• Système
• Sécurité

Cela en fait quelques-unes à gérer !

Le réservoir

Une autre spécificité est de devoir se déplacer physiquement dans le bureau du collaborateur, ou dans un data center pour installer les machines (et donc de finir les tâches). Et cela prend du temps. Une colonne spéciale a donc été créée : le réservoir. L’objectif est d’attendre qu’il y ait assez de demandes assignées à un même endroit, lorsque cela est possible, afin d’optimiser son déplacement. Il y a autant de réservoirs que d’endroits géographiquement distants.

Retour aux tableaux Kanban

Deux tableaux, cela a généré quelques problèmes à l’usage :

• Plusieurs cases Wip effectives. Cela rend plus difficile la mise en place de limites.
• Le kanban ne reflétait plus notre gestion des tickets, et nous nous sommes, à tort, autoriser à faire des « marches arrières ».
  • Un ticket en attente, qui se débloque peut retourner dans le ready au lieu de rester bloquer dans le WIP.
• Plusieurs cases de ces deux tableaux avaient les mêmes fonctionnalités (Réservoir Datacenter, Wait constructeur et wait Externe)

Je trouve particulièrement intéressant le fait que visualiser les deux flux a amené l’équipe à mieux comprendre la nature de leur travail, c’est bien l’objectif :

Nous nous sommes aperçus que nous avions plus de flux que cela. Au final ce sont des classes de service et non des flux !

La refonte des tableaux Kanban

De leur propre initiative, les deux tableaux ont alors évolué. Et comme souvent dans ce cas, cela a contribué à plus de simplicité, à commencer par la fusion des deux tableaux en un seul tableau.

Point de vue du coach :

Un des facteurs d’échec d’une mise en place kanban est de concevoir au démarrage une usine à gaz pour essayer de visualiser l’intégralité du travail à réaliser. Un des premiers conseils à suivre est de ne chercher qu’à visualiser les demandes nominales, surtout pas les cas un peu tordus, exceptionnels, trop complexes …pour commencer. L’exceptionnel sera traité de manière exceptionnelle. Puis au fur et à mesure, le tableau kanban va évoluer pour savoir prendre en compte le plus d’items possibles.

De retour à notre équipe Datacenter. Voici les axes d’améliorations majeures qui a amené à une refonte totale des tableaux (et ce après un an à faire évoluer leur tableau par petites touches) :

• Définir ce que nous appelions flux et leur cheminement
• Merger les cases identiques
  • Réservoir, WIP, Wait des deux tableaux
• Se créer un top of backlog opportuniste (Backlog Standby)

Les tickets opportunistes sont ceux qui ne sont pas forcément urgents, mais dont la taille fait qu’ils peuvent passer facilement entre deux items plus importants. Cela fluidifie le processus.

Tableau représentant le flux de travail d’une équipe data center

La case En attente WIP est en test. Elle est mise là pour permettre de mettre des limites sur le WIP et pour éviter de remettre les tickets débloqués dans le ready.

La suite des évolutions

L’équipe part en test sur ce nouveau tableau unique. D’ores et déjà, plusieurs pistes d’amélioration sont envisagées :

• Réserver du Wip pour les sujets Prioritaires
• Déterminer une première limite pour notre wip
• Peut-être trouver une indication pour distinguer les tickets qui sont traités après le « wait »

Et voici le conseil pour bien faire vivre et évoluer le flux de travail d’une équipe data center :

 Expérimenter, expérimenter :)

Non pas pour avoir un joli tableau, mais parce qu’il représente leur manière de travailler, et qu’il permet à l’équipe de mieux comprendre la nature de leur travail et de leur process et donc d’avoir l’opportunité de le faire évoluer.

A suivre un article de cette même équipe sur les classes de services, le rôle du Product Owner ...