Le management visuel regroupe un ensemble de techniques permettant de « visualiser » la situation pour des en-cours de production, des stocks, un flux de produits.

Il s’appuie sur un marquage direct des éléments du processus (par exemple un niveau vert ou rouge de stock de produits empilés) ou sur des tableaux de bord regroupant des indicateurs. Le management visuel est d’autant plus efficace que les rituels de management de proximité (réunion opérationnelle) commentent et font vivre l’affichage visible par tous à tout moment.

Qu’en est-il dans le secteur tertiaire ? Lorsque le flux est immatériel, que chacun répond à des requêtes à l’aide de son téléphone ou de son ordinateur, y a-t-il encore quelque chose à voir ? Deux exemples peuvent aider à comprendre comment l’utiliser.  

• Le premier concerne les centres d’appel.

Pour réguler au mieux le flux des demandes, il faut pouvoir superviser le flux. Bien sûr, on peut toujours mettre un « garde-chiourme » pour superviser la plateforme du centre d’appel, mais ceci est vite ressenti comme du « flicage » par les « hotliners », qui se sentent surveillés et plus stressés. Est-il finalement nécessaire de procéder ainsi, avec une supervision centrale ? Une bonne application des principes du Lean – dont fait partie l’appropriation collective – est de mettre en place une visualisation de l’ensemble des appels sur un affichage visible de tous, permettant au premier « hotliner » libre de prendre l’appel le plus ancien en attente. OK, OK, on va se dire que certains prendront du bon temps en se laissant vivre aux dépens des autres, mais s’il y a par ailleurs un intéressement du « hotliner » en fonction du nombre de clients qu’il traite (en tenant compte aussi de la qualité de service)… ça peut fonctionner !  

• Le deuxième exemple concerne les projets de développement de logiciel. Quoi de plus immatériel ?

Dans le cadre d’une méthodologie agile (comme Scrum, par exemple), chaque « sprint » (effort de production d’une semaine à un mois ») donne lieu à un « backlog » (livraison) au client. Et on procède ainsi de manière incrémentale. Bien sûr, chacun peut avoir sur Intranet ou dans un fichier Excel la liste des bugs prioritaires à corriger dans le prochain « backlog »… mais trop d’info tue l’info ! Comment rendre cette information plus visuelle, et favoriser l’effort collectif de production au cours du « sprint » ?

Une solution consiste à re-matérialiser le processus immatériel, en utilisant un « paper board » placé au bon endroit, et en y organisant chaque matin une « réunion opérationnelle 5 minutes », debout, pour identifier par post-it les principaux bugs, et pour définir les priorités. Au fur et à mesure de la journée, chaque développeur vient enlever ou annoter les post-it qu’il a traités : chacun voit ainsi la progression du travail. Le lendemain matin, la réunion opérationnelle suivante procède de la même manière, avec les post-it qui restent et ceux qui se rajoutent suite aux échanges avec le client, aux opérations d’intégration, etc.  

Dans ces deux exemples, on a rendu « visuel » un processus qui ne l’était pas du tout, et on a ainsi rendu plus concret l’avancement du travail de l’équipe.