Logiciel de dispatching pour la location : comment planifier livraisons, chauffeurs et matériel

Faire parvenir un seul équipement d'un dépôt à un seul client est un problème résolu : on choisit un chauffeur, on lui indique une adresse, et il part. Faire parvenir douze ou vingt équipements à douze ou vingt clients différents le même jour, certains en livraison, d'autres en reprise, certains déjà engagés sur un créneau matinal fixe, d'autres flexibles, est un problème d'une tout autre nature. C'est autant un exercice de séquencement que de planning : quels arrêts sont proches les uns des autres, quel chauffeur passe déjà par là, et quelles adresses sont réellement accessibles, à déterminer avant que la tournée ne soit validée, plutôt qu'à découvrir une fois la camionnette chargée et partie.

C'est justement la partie du dispatching en location qui reçoit le moins d'attention. Il y a beaucoup à dire sur ce qui se passe une fois qu'un chauffeur est parti, de l'application chauffeur qu'il utilise sur la route à l'expérience de livraison que voit le client pendant son attente, et encore plus sur la capture de preuves solides au moment de la remise. Cet article porte sur l'étape qui précède tout cela : l'écran de planification au bureau, où la tournée du jour est réellement construite, avant qu'un chauffeur ne quitte le dépôt. Si la tournée est mal construite, aucune finition d'application ni aucune preuve de remise ne rattrapera ce qui suit : un chauffeur qui traverse le même code postal trois fois dans la journée, un arrêt dont personne n'a réalisé qu'il se trouvait hors de la zone de service avant d'y être garé, ou la visite hebdomadaire d'un client récurrent oubliée parce que personne n'a reconstruit la tournée à partir de celle de la semaine précédente.

Le point de départ de la tournée du jour doit être les réservations déjà existantes, et non une liste refaite de zéro par la personne qui planifie les itinéraires ce matin-là. Une commande de location contient déjà l'adresse de livraison, les articles qui partent ou qui reviennent, le contact sur place et les dates concernées, car ces informations ont été saisies au moment de la prise de commande, pas inventées au moment du dispatching. Ressaisir l'une de ces informations dans un outil de planification distinct est précisément la source d'erreurs : un chiffre inversé dans un code postal, un numéro de contact recopié depuis la mauvaise ligne, une quantité d'articles qui s'écarte discrètement de ce qui a réellement été devisé.

Chez Renttix, les missions de livraison et de reprise sont planifiées directement sur un tableau de dispatching, en s'appuyant sur la commande elle-même plutôt que sur un tableur parallèle. Cela compte plus qu'il n'y paraît : la personne qui planifie la tournée du jour travaille à partir du même enregistrement que la commande du client, si bien qu'une modification apportée à une commande, une quantité corrigée, un contact de site différent, une date reprogrammée, est le changement qui apparaît sur le tableau, plutôt qu'une information qu'il faudrait transmettre séparément à la personne responsable de l'itinéraire.

Une fois les missions du jour créées, il reste à les organiser pour qu'un chauffeur puisse les enchaîner dans un ordre cohérent. Rien d'exotique ici : regrouper dans un même itinéraire les livraisons et reprises proches les unes des autres, plutôt que d'envoyer un chauffeur zigzaguer à travers la ville pendant qu'un second couvre trois rues plus loin, est un principe de base bien connu de la planification d'itinéraires. L'intérêt est simple : moins de kilomètres, moins de minutes perdues entre les arrêts, et une tournée qu'un chauffeur peut garder en tête plutôt que de la subir arrêt par arrêt via un GPS qui ne sait pas ce qui l'attend ensuite.

Sur le tableau de dispatching, les missions sont regroupées par itinéraire et assignées directement aux chauffeurs, de sorte que la personne qui planifie la journée voit l'ensemble de la tournée se former : quels arrêts vont ensemble, quel chauffeur a déjà une journée légère et peut en prendre un de plus, et quelles missions ne sont encore assignées à personne. Construire cette vue sur le tableau de dispatching, plutôt que de jongler entre une liste imprimée et une carte séparée, fait de la tournée un plan unique, et non plusieurs documents qui doivent tous concorder au moment où les chauffeurs partent.

L'un des problèmes les plus évitables dans la planification du dispatching est une adresse qui n'aurait jamais dû être acceptée au départ. Une réservation prise par téléphone, ou une ancienne adresse client réutilisée pour une nouvelle commande, peut se trouver en dehors de la zone qu'un dépôt peut réellement desservir, et personne ne s'en aperçoit avant qu'un chauffeur ne soit garé devant un portail, quarante minutes après son créneau prévu, au téléphone avec le bureau pour savoir quoi faire.

Renttix traite ce problème dès la phase de planification, pas sur le bord de la route. Chaque dépôt dispose d'une zone de service définie comme un polygone tracé sur une carte, et les adresses de livraison y sont comparées. Une commande passée via une boutique en ligne connectée est bloquée avant le paiement si l'adresse se situe hors de la zone du dépôt concerné, de sorte que la réservation n'est jamais acceptée au départ. Pour les commandes qui arrivent sur le tableau par une autre voie, le même contrôle s'applique au moment de la planification de la journée : un arrêt situé hors de la zone de service d'un dépôt est signalé comme hors zone sur le tableau de dispatching pendant que la tournée est encore en construction, et non après qu'une camionnette a quitté le dépôt. C'est là toute la différence : la question de savoir si une mission est réaliste se pose sur l'écran de planification, avec le temps de la réaffecter au bon dépôt ou d'interroger le client, plutôt que sur le téléphone portable de quelqu'un garé sur le bas-côté.

Une grande partie de l'activité de location est une activité récurrente : le même client qui prend les mêmes articles le même jour chaque semaine, ou un contrat qui s'étend sur plusieurs mois avec des livraisons et reprises à intervalles fixes. Planifier une tournée à partir d'une page blanche chaque jour, même pour des clients dont le schéma ne change jamais, est un effort inutile, et c'est aussi un risque de fiabilité. Si la construction de la tournée de demain dépend du fait que quelqu'un se souvienne qu'un client donné attend sa visite hebdomadaire, tôt ou tard, quelqu'un l'oubliera.

Les plannings récurrents résolvent ce problème en générant eux-mêmes les missions de dispatching. Le motif est défini une seule fois, et à partir de là, les livraisons et reprises concernées apparaissent automatiquement sur le tableau aux bons jours, déjà rattachées à leur itinéraire habituel. Un dépôt qui planifie la semaine suivante ne part pas de rien : les visites récurrentes sont déjà positionnées aux jours concernés, et le travail de planification consiste surtout à traiter les missions nouvelles ou ponctuelles, et à les intégrer autour du planning déjà en place.

Un cas voisin, mais distinct, est celui d'une location qui comprend son propre volet d'entretien récurrent, plutôt qu'une simple livraison suivie d'une reprise éventuelle. Une toilette portable en location longue durée nécessitant un entretien chaque semaine en est l'exemple le plus parlant : l'unité part une seule fois, mais un chauffeur doit revenir sur site selon un cycle fixe pendant toute la durée de la location, et chacune de ces visites constitue sa propre mission, avec son propre enregistrement.

Ajouter une ligne de service à une commande traite directement ce cas : Renttix génère alors le calendrier des visites pour toute la durée de la location, et chaque visite est suivie tout au long de son propre cycle de vie, de planifiée à terminée, jusqu'à prête à facturer. Cette dernière étape compte autant pour la planification que pour la facturation : une visite terminée classée en prête à facturer est un signal visible que la mission a bien eu lieu et a été correctement clôturée, plutôt qu'un élément à relancer séparément en fin de mois.

Bien planifier la tournée ne représente que la moitié du travail ; savoir comment elle se déroule réellement une fois les chauffeurs partis en est l'autre moitié. Une fois qu'une mission a été assignée et qu'un chauffeur la traite, son statut est visible par le bureau en temps réel. Une mission en cours, en attente ou terminée apparaît sur le même tableau où elle a été planifiée, plutôt que d'être connue seulement lorsque le chauffeur revient au dépôt en fin de journée.

Pour un dispatcheur, c'est la différence entre réagir à un problème tant qu'il est encore temps d'agir, et le découvrir après coup. Si une mission plus loin sur un itinéraire va prendre du retard parce qu'un arrêt précédent a duré plus longtemps que prévu, cela se voit pendant qu'il est encore possible d'ajuster le reste de la journée. L'expérience du chauffeur lui-même sur la mission, la capture des signatures, des photos et le reste, est un sujet qui mérite son propre article ; du côté de la planification, ce qui compte, c'est que le tableau de dispatching et l'application chauffeur s'appuient sur la même mission sous-jacente, et non sur deux systèmes séparés qu'il faudrait réconcilier à la main.

Prenons, à titre d'illustration, un dépôt qui planifie les livraisons et reprises du lendemain sur une tournée mixte : quelques nouvelles commandes ponctuelles reçues dans la semaine, plusieurs locations de longue durée dont la visite d'entretien hebdomadaire arrive à échéance, et deux reprises pour des locations qui se terminent. Rien de tout cela n'a besoin d'être assemblé à partir de listes séparées. Les commandes ponctuelles figurent sur le tableau parce qu'elles ont été réservées en tant que commandes dès le départ ; les visites d'entretien hebdomadaires y sont déjà parce qu'elles ont été générées par leurs lignes de service ; et les reprises apparaissent sur le tableau parce que la date de fin de leur location les a déclenchées. Le vrai travail du planificateur ce matin-là consiste à vérifier toute adresse signalée comme hors zone, à regrouper les arrêts restants en itinéraires cohérents par secteur, et à les assigner aux chauffeurs en service, non à réinventer une tournée qui était déjà presque entièrement là, en attente d'être organisée.

C'est précisément pour cela que la planification du dispatching mérite d'être traitée comme une discipline à part entière, distincte de l'application chauffeur ou de l'enregistrement de livraison : c'est l'étape où une journée devient soit un plan réaliste et bien séquencé, soit une liste de bonnes intentions qui s'effondre en milieu de matinée. Si vous voulez voir à quoi ressemblerait une tournée mixte comme celle-ci sur votre propre tableau de dispatching, avec vos propres dépôts, zones de service et clients récurrents, réservez une démonstration et nous vous ferons une visite guidée.