Réunissez quatre collègues autour d’une table et demandez-leur comment un nouveau client arrive chez vous. Vous obtiendrez quatre réponses différentes. Pas parce que quelqu’un s’y prend mal, mais parce que le processus n’est écrit nulle part.
Tant que c’est le cas, vous ne pouvez pas faire grand-chose pour l’améliorer. On ne peut pas s’attaquer à ce qu’on ne voit pas.
Le journey mapping, c’est quoi ?
Le journey mapping consiste à dessiner un processus tel qu’il se déroule aujourd’hui, du début à la fin, sur une seule feuille. Pas du point de vue de votre logiciel, mais de celui de la personne qui fait le travail.
En haut du dessin figure l’objectif de cette personne, avec ses propres mots : « je veux pouvoir démarrer un nouveau client ». En dessous, la carte se lit de gauche à droite, sur quatre lignes. Les étapes qu’elle parcourt. Ce qu’elle fait concrètement à chaque étape. Où cela se passe : quel système, quel écran, quelle boîte mail. Et tout en bas, là où ça coince.
C’est tout. Pas de logiciel, pas de méthode avec un certificat à la clé. Un dessin sur un mur ou sur une grande feuille de papier, fait en quelques heures avec les personnes qui font vraiment le travail.
Image : illustration d’une carte du parcours pour une entreprise de recrutement.
Qu’est-ce que vous en retirez ?
D’abord, tout le monde voit enfin la même chose. Dans une PME, trois personnes font le même travail chacune un peu différemment, et cela n’apparaît que lorsque tout est posé côte à côte sur une même feuille. Cette conversation-là vaut déjà de l’or.
Ensuite, on voit où le temps se perd. Surtout le travail qui se fait en dehors de vos systèmes — le coup de fil, l’e-mail à un collègue, le fichier Excel sur le bureau de quelqu’un. Ce sont en général les plus gros dévoreurs de temps. Ce travail naît rarement par hasard : c’est presque toujours le détour autour d’un outil qui ne correspond pas à la façon dont les gens travaillent vraiment.
Si vous numérotez ces points de friction (P1, P2, P3), la conversation qui suit change complètement. Au lieu de « il nous faut quelque chose de nouveau », vous entendez « P3 nous coûte vingt minutes par dossier et arrive trente fois par semaine ». Vous pouvez alors choisir en connaissance de cause d’y remédier, et expliquer après coup pourquoi l’argent est allé à cet endroit-là.
Parfois, la conclusion est que vous n’avez besoin d’aucun nouveau logiciel. Qu’un outil existant suffit, ou que le problème ne se résout pas avec un logiciel.
Quelle différence avec un logigramme ?
Un logigramme part du processus tel que le système le voit : par quels statuts passe un dossier, quelles décisions il contient, qui doit valider. Un parcours part d’une personne qui a un objectif.
Cela détermine ce que vous allez voir. Un logigramme montre ce qui se passe dans votre logiciel. Un parcours montre aussi tout ce qu’il y a autour : le détour, le travail en double, le moment où quelqu’un passe quand même un coup de fil pour vérifier. C’est précisément là que se trouve le problème, la plupart du temps.
Un logigramme n’est donc pas mauvais, il répond simplement à une autre question. « Comment se déroule ce processus ? » est une question de logigramme. « Où est-ce que ça coince, et pourquoi ? » est une question de parcours. Pour la plupart des PME, la seconde est la plus utile, parce que sa réponse détermine où va votre argent.
Il y a une autre différence pratique. Comme un parcours est écrit dans la langue de l’utilisateur, il reste utilisable quand vous changez d’outil. Les étapes pour démarrer un client restent les mêmes. Seuls les écrans changent.
Comment s’y prendre en pratique ?
N’essayez pas de cartographier toute votre entreprise. « Cartographier nos processus », c’est trop vaste, et cela donne un plat de spaghettis dont plus personne ne fait rien. « Démarrer un nouveau client » ou « préparer une facture », ça marche. Un objectif, une feuille. S’il vous en faut davantage, vous en dessinez une deuxième.
Veillez aussi à réunir les bonnes personnes. Pas seulement le dirigeant et le chef d’équipe, mais surtout la personne qui fait ces étapes tous les jours. C’est elle qui connaît les détours.
Chez Tandem, c’est toujours la première étape. Nous dessinons d’abord comment ça se passe aujourd’hui, puis comment ça devrait se passer, et ce n’est qu’ensuite que le logiciel entre en jeu. Cet ordre — d’abord le modèle du fonctionnement de votre entreprise, ensuite le code — est au cœur de notre façon de construire. Vous voulez savoir où votre entreprise perd du temps ? Envoyez-nous un message, nous y réfléchirons volontiers avec vous.
