En logistique, les données sont partout mais rarement au même endroit. Le système de transport sait quand un camion est parti, l’entrepôt connaît l’état de la préparation, la télématique enregistre l’itinéraire et les heures du conducteur, et les tableurs du contrôle de gestion comptent les coûts à leur manière. Le directeur des opérations se retrouve avec quatre vérités différentes et aucune certitude. Le problème n’est pas le manque de données, mais l’absence d’une couche unique qui les transforme en KPI comparables et en décisions concrètes.
D’après notre expérience, le difficile n’est pas la visualisation mais de s’accorder sur ce que l’on mesure exactement et sur la provenance de chaque chiffre. Sur les projets d’analytique, nous commençons donc par les définitions des métriques et des sources, et seulement ensuite par les graphiques. Notre compétence data et BI puise dans tout le groupe RITS, y compris nos équipes Big Data et IA/data, et notre expérience dans le transport et la travel tech s’est construite en partie sur des travaux Data et Analytics. Même si nous n’avons pas mené votre scénario exact, nous fournissons les personnes qui ont conçu et maintenu ce type de solution.
Pourquoi les données logistiques sont-elles aussi fragmentées ?
La fragmentation n’est la faute de personne ; elle vient de l’histoire des systèmes. Chaque outil a été construit pour résoudre un problème opérationnel différent, et chacun conserve les données dans son propre format, avec sa propre définition d’une « livraison », d’une « commande » ou d’un « statut ». Un TMS pense en ordres de transport, un WMS en lignes de préparation, et la télématique en événements GPS toutes les quelques secondes.
S’y ajoutent les signaux venus de l’extérieur de l’organisation : statuts des transporteurs, notifications de réservation des clients, fichiers EDI de plusieurs variantes. Résultat : le même envoi porte un identifiant différent à trois endroits, et son délai de livraison dépend de la personne à qui l’on demande. Avant de calculer la moindre métrique, il faut marier ces mondes et s’accorder sur un vocabulaire commun. C’est un travail ingrat mais décisif, car tout KPI construit sur des données mal reliées relève de la fiction.
Comment construire des dashboards de KPI opérationnels en logistique ?
Un bon dashboard ne montre pas tout ; il montre ce sur quoi son lecteur peut agir. Nous le concevons par rôle : l’écran d’un dispatcheur ne ressemble en rien au cockpit d’un directeur des opérations. L’ensemble de KPI transport qui fonctionne le plus souvent est :
- la ponctualité (OTD/OTIF) ventilée par transporteur, région et type de client,
- le coût par envoi et au kilomètre, en séparant les tournées propres des sous-traitants,
- l’utilisation de la flotte et le taux de remplissage des véhicules (charge utile, kilomètres à vide),
- le temps de cycle des commandes, de la prise en charge à la livraison,
- la qualité des données comme KPI à part entière, c’est-à-dire combien d’événements arrivent à temps et complets.
Chaque chiffre est relié à un chemin pour entrer dans le détail, de la valeur agrégée jusqu’à une seule tournée, car sans cela un KPI est une curiosité plutôt qu’un outil de décision.
Comment calculer le coût réel par envoi ?
Le coût par envoi semble simple jusqu’au moment où l’on essaie de le calculer. L’ennui, c’est que les coûts résident dans des systèmes différents et à des granularités différentes : les factures des transporteurs arrivent en masse, le carburant se règle par véhicule et la main-d’œuvre d’entrepôt par équipe, pas par colis. Pour obtenir un chiffre honnête, nous décomposons le coût total en inducteurs et le réaffectons aux envois selon des clés sensées comme le poids, le volume ou le nombre de lignes.
Cela fait apparaître ce qu’une facture globale masque : qu’un axe tourne structurellement à perte, que les petits colis érodent la marge malgré une tarification correcte, ou que le coût des trajets à vide l’emporte sur l’économie d’un transporteur bon marché. À ce moment-là, le coût cesse d’être une ligne dans un rapport et devient un argument de négociation et une base pour réorienter les flux.
Comment rendre compte de la ponctualité (OTD) ?
Le reporting de ponctualité semble trivial, et pourtant tout dépend de la définition de « à l’heure ». Compte-t-on depuis la réservation ou depuis la confirmation ? La tolérance est-elle une fenêtre horaire ou une minute exacte ? Une livraison partielle compte-t-elle comme tenue ? Fixer ces règles compte davantage que le graphique lui-même, car elles décident si un OTD à 95 % est un succès ou un problème balayé sous le tapis.
Une fois les règles claires, nous concevons le rapport de ponctualité pour qu’il montre non seulement le résultat mais aussi la cause :
- la tendance de l’OTD dans le temps, ventilée par transporteur et par agence,
- les motifs de retard, catégorisés de façon cohérente plutôt qu’en texte libre,
- les envois à risque, signalés avant l’échéance plutôt qu’après.
Ce dernier élément fait passer le reporting d’un mode comptable à un mode opérationnel, car il permet à l’équipe de réagir tant que quelque chose peut encore être sauvé.
Comment prévoir le débit et l’utilisation ?
Une fois les données historiques en ordre, regarder vers l’avant est l’étape naturelle suivante. Nous construisons des modèles qui prévoient le volume d’envois et la charge de l’entrepôt à l’échelle hebdomadaire et saisonnière, pour planifier les effectifs par équipe et l’affectation des véhicules avant l’apparition d’un goulet d’étranglement. Ce n’est pas de la lecture dans le marc de café ; c’est ancrer les décisions de capacité dans les motifs qui reviennent chaque année de toute façon.
Nous traitons la couche de prévision comme une extension de l’analytique, pas comme un monde à part. Ce n’est qu’une fois la fondation de données propres et de métriques convenues en place que nous ajoutons des modèles prédictifs et, là où cela a du sens, une composante IA. Cette compétence existe réellement au sein du groupe RITS, nous l’activons donc quand elle apporte de la valeur, pas parce qu’elle sonne bien.
Comment concevoir l’entrepôt de données et la couche de métriques ?
Sous chaque dashboard, il doit y avoir une fondation reproductible, sinon les chiffres divergent dès qu’une source change. Nous la construisons comme un entrepôt de données avec une couche de métriques explicite, alimenté par des pipelines qui puisent régulièrement dans les systèmes opérationnels :
- des pipelines depuis le TMS, le WMS et la télématique, résistants aux événements manquants et dupliqués,
- une couche de modélisation qui transforme les tables brutes en entités cohérentes (envoi, tournée, commande),
- une définition centrale des métriques, pour que l’OTD ou le coût par envoi soit calculé à l’identique dans chaque rapport,
- des contrôles de qualité des données intégrés au pipeline, avec une alerte quand une source cesse de livrer un jeu complet.
Cette architecture fait qu’une nouvelle métrique arrive en quelques jours plutôt qu’en semaines, et que tout le monde dans l’entreprise regarde les mêmes chiffres.
Quelles compétences apportons-nous à l’analytique logistique ?
Nous façonnons l’équipe autour de l’étape et du périmètre de travail précis, pas « au cas où ». Sur les projets data, nous pourvoyons le plus souvent ces rôles :
- un data engineer qui construit et maintient les pipelines et l’entrepôt,
- un analyste BI / développeur de dashboards qui traduit les métriques en écrans lisibles,
- un architecte data responsable du modèle et de la couche de métriques,
- un spécialiste ML / data scientist quand les prévisions et une composante IA entrent en jeu.
Une telle équipe peut travailler comme une extension de votre département data ou comme une équipe dédiée qui mène le sujet de bout en bout. Nous avons exposé les différences entre ces modèles dans notre article sur les modèles de collaboration IT.
Comment procédons-nous chez RITS ?
Nous travaillons comme partenaire nearshore depuis la Pologne qui combine compétence data et expérience des projets de transport :
- nos compétences Data et BI puisent dans le groupe RITS, y compris nos équipes Big Data et IA/data,
- dans le secteur du transport et de la travel tech, nous avons livré des travaux Data et Analytics,
- nous partons des définitions de métriques et de la qualité des données, pas d’un joli graphique,
- nous vérifions les compétences avant le démarrage et faisons grandir l’équipe à mesure que le projet mûrit.
Le plus souvent, nous le faisons en logiciel d’analytique sur mesure construit par notre équipe et, quand des manques doivent être comblés vite, en renfort d’équipe.
Par où commencer avec l’analytique logistique ?
Partez d’une décision que vous voulez mieux prendre, par exemple quel transporteur réduire ou quel axe renégocier. Cette décision définit les métriques nécessaires, et les métriques définissent les sources et l’architecture. C’est un point de départ bien plus sain que d’essayer de tout mesurer d’un coup, car il livre un résultat visible immédiatement dans l’exploitation.
Vous voulez transformer les données du TMS, du WMS et de la télématique en KPI et en décisions ? Parlons-en - nous ajusterons une équipe et une architecture à votre logistique.