RessourceNumérisation

Logiciel de gestion pour 10 camions : ce qui change par rapport à Excel

Avec environ 10 camions, les utilisateurs, modifications, dépendances et données augmentent. Voici ce qui doit changer par rapport à Excel : rôles, plan partagé, historique, conducteurs, KPI et continuité.

En bref

Avec une dizaine de camions, le problème n’est pas seulement d’avoir davantage de lignes dans le fichier. Les éléments suivants augmentent simultanément :

  • les commandes ;
  • les conducteurs ;
  • les véhicules ;
  • les appels téléphoniques ;
  • les modifications ;
  • les documents ;
  • les personnes qui doivent connaître le même statut ;
  • le risque que deux décisions se chevauchent.

Excel peut rester un excellent outil d’analyse et de support. Il devient fragile lorsqu’on lui demande d’être simultanément une base de données, un plan opérationnel, un système multi-utilisateur, un historique, un outil de communication et une archive.

Dix camions ne font pas « le double » de cinq

Supposons trois activités moyennes par véhicule :

  • 5 camions → environ 15 activités ;
  • 10 camions → environ 30 activités.

Mais l’augmentation de la complexité n’est pas linéaire. Avec davantage de véhicules, les éléments suivants augmentent :

  • les croisements entre disponibilités ;
  • les remplacements ;
  • les créneaux horaires ;
  • les communications ;
  • les possibilités d’erreur ;
  • les personnes impliquées.

Si deux opérateurs modifient le plan, l’entreprise doit savoir quelle information est la bonne à cet instant.

La principale limite d’Excel : la concurrence opérationnelle

Un tableur partagé moderne peut être modifié par plusieurs personnes. Le problème n’est donc pas simplement qu’« Excel n’est pas multi-utilisateur ». Le point est qu’une grille générique ne gère pas automatiquement le sens du processus.

Exemple :

  • Luca change le conducteur à la ligne 38 ;
  • Marta déplace l’horaire de la même commande ;
  • le conducteur reçoit la modification sur WhatsApp ;
  • le client appelle un troisième collègue ;
  • quelqu’un duplique la ligne pour ne pas perdre l’ancienne version.

Le fichier peut tout contenir, mais il n’applique pas nécessairement de règles sur :

  • l’identité de la commande ;
  • le statut ;
  • les rôles ;
  • les affectations ;
  • la version ;
  • les notifications ;
  • les relations entre les entités.

Un logiciel de gestion crée une structure autour de la donnée.

Le plan doit devenir un état partagé

Avec dix camions, le plan ne peut pas être seulement une représentation graphique. Il doit être la conséquence d’objets structurés.

Une commande devrait connaître :

  • qui est le client ;
  • où l’enlèvement a lieu ;
  • où la livraison a lieu ;
  • quand ;
  • quel véhicule est affecté ;
  • quel conducteur est affecté ;
  • dans quel statut elle se trouve ;
  • quelles modifications opérationnelles sont intervenues ;
  • quels documents sont liés, si le système les gère.

Le plan quotidien visualise ces relations. Il ne devrait pas être le seul endroit où elles existent.

Rôles et responsabilités

Dans une petite flotte, tout le monde peut se connaître et se parler directement. Mais à mesure que le travail augmente, il est utile de définir qui peut faire quoi.

Exemple minimal :

Opérateur

  • crée/modifie les commandes ;
  • planifie ;
  • met à jour les statuts opérationnels.

Administration

  • consulte les commandes clôturées ;
  • récupère les références et documents nécessaires ;
  • ne modifie pas nécessairement le plan de la journée.

Conducteur

  • voit ses propres activités ;
  • met à jour les statuts prévus ;
  • ne voit pas le plan complet ou les données d’autres personnes si ce n’est pas nécessaire.

Dirigeant/responsable

  • voit la situation générale ;
  • contrôle les indicateurs ;
  • gère les utilisateurs/autorisations selon le produit.

Les rôles réduisent les erreurs et contribuent aussi à respecter le principe d’accès aux données selon les besoins.

Gérer les exceptions sans perdre la version officielle

Avec dix camions, les exceptions sont normales :

  • retard au chargement ;
  • client fermé ;
  • conducteur indisponible ;
  • véhicule à l’atelier ;
  • commande urgente ;
  • changement de destination ;
  • annulation ;
  • document manquant.

Le processus doit distinguer la conversation de la décision.

Exemple :

« Le client décale peut-être à 17 h 00 » est une conversation.

« Déchargement confirmé à 17 h 00 » est une donnée opérationnelle à reporter dans la source officielle.

Si les deux restent seulement dans un chat, la personne qui prend le service suivant doit reconstruire le contexte en lisant les messages.

Communication avec les conducteurs

Davantage de camions signifie davantage de communications individuelles. Un système conducteur ou un canal structuré peut réduire les appels téléphoniques répétitifs.

Informations utiles :

  • séquence des activités ;
  • adresses ;
  • références ;
  • horaires ;
  • notes opérationnelles ;
  • modifications ;
  • statut de l’activité.

L’objectif n’est pas d’éliminer le téléphone. Un problème complexe nécessitera toujours une conversation. L’objectif est de ne pas utiliser l’appel téléphonique comme base de données.

Si l’application traite des données personnelles ou de la géolocalisation, le RGPD, les principes de minimisation et, lorsque cela est pertinent, le droit du travail relatif au contrôle à distance doivent être évalués. Ces évaluations ne dépendent pas du nombre de camions.

Données et reporting qui deviennent utiles

Avec dix véhicules, des schémas qui sont difficiles à voir de mémoire commencent à apparaître.

Indicateurs simples :

Commandes par client

Aide à comprendre les dépendances commerciales et les volumes.

Commandes par jour/semaine

Montre les pics et la capacité organisationnelle.

Activités replanifiées

Si trop d’activités sont déplacées chaque jour, il peut y avoir un problème de données initiales, de capacité ou de processus.

Exceptions

Classer quelques motifs aide à comprendre si les problèmes récurrents sont « attente client », « véhicule », « commande incomplète », « variation client », etc.

Documents manquants

Si le workflow comprend des POD/pièces jointes, savoir ce qui manque évite des recherches en fin de mois.

Ces données ne remplacent pas la comptabilité, le contrôle des coûts ou les vérifications réglementaires, mais elles améliorent la gestion opérationnelle.

Continuité opérationnelle et dépendance aux personnes

Une question très utile :

Si demain la personne qui gère le fichier ne vient pas travailler, un collègue peut-il comprendre la journée en 10 minutes ?

Si la réponse est non, l’entreprise présente un risque organisationnel.

La numérisation devrait réduire la connaissance qui est « seulement dans la tête » grâce à :

  • des référentiels communs ;
  • des règles simples ;
  • des statuts partagés ;
  • un historique ;
  • des accès individuels ;
  • des procédures minimales documentées.

Il ne faut pas bureaucratiser. Quelques règles répétables suffisent.

Quand Excel peut encore rester

Passer à un logiciel de gestion ne signifie pas interdire Excel.

Excel reste excellent pour :

  • les analyses ponctuelles ;
  • les budgets ;
  • les simulations ;
  • les tableaux temporaires ;
  • les rapprochements ;
  • les exports et contrôles ;
  • les rapports personnalisés.

La distinction utile est la suivante :

Logiciel de gestion : source opérationnelle actuelle. Excel : outil d’analyse/de support.

Le problème revient lorsqu’un export modifié manuellement devient de nouveau la « vraie version » du plan.

Plan de transition sur 4 semaines

Semaine 1 — cartographie et nettoyage

  • lister les processus ;
  • choisir les champs nécessaires ;
  • nettoyer clients et sites ;
  • nettoyer conducteurs et véhicules ;
  • définir quelques statuts.

Semaine 2 — configuration et essai

  • importer les référentiels ;
  • créer de vraies commandes de test ;
  • tester les modifications et annulations ;
  • tester les utilisateurs et les autorisations ;
  • vérifier les exports.

Semaine 3 — groupe pilote

  • 2 à 3 camions ou une partie de l’activité ;
  • recueillir les problèmes ;
  • corriger les procédures ;
  • éviter les personnalisations non indispensables.

Semaine 4 — date de bascule

  • toutes les nouvelles commandes entrent dans le nouveau système ;
  • l’ancien fichier devient une archive/sauvegarde opérationnelle temporaire, pas une source concurrente ;
  • bref contrôle quotidien pendant une semaine.

Les délais sont indicatifs : la complexité, les intégrations et la qualité des données peuvent exiger bien plus de temps.

Checklist : les 10 camions ont-ils dépassé Excel ?

  • Plusieurs personnes modifient-elles le plan ?
  • Existe-t-il des versions concurrentes ?
  • Les affectations sont-elles écrites en texte libre ?
  • Les modifications destinées aux conducteurs restent-elles dans les chats ?
  • Est-il difficile de savoir quelles commandes sont ouvertes ?
  • Le dirigeant est-il la seule personne qui comprend le fichier ?
  • Faut-il appeler les conducteurs pour chaque détail ?
  • Les rôles et autorisations manquent-ils ?
  • Reconstruire l’historique demande-t-il des heures ?
  • N’existe-t-il pas d’export/archive cohérent par client ?
  • Les exceptions récurrentes ne sont-elles pas mesurées ?

Si de nombreuses réponses sont « oui », le problème n’est pas le nombre 10 en soi : la complexité a dépassé la structure du tableur.

Sources et références

Les sources constituent un point de départ pour les vérifications. Pour un cas précis, consultez les textes en vigueur et des professionnels compétents.