Logiciel de transport : comparer deux démonstrations

Après plusieurs démonstrations de logiciels, les souvenirs se mélangent : un écran apprécié, une réponse rapide, une question restée ouverte. Pour choisir un outil adapté à une entreprise de taxis conventionnés, d’ambulances ou de VSL, il faut pouvoir rapprocher ces impressions des tâches à réaliser.

Une grille commune aide l’équipe à garder une trace de ce qui a été observé. Voici une méthode pour comparer les parcours présentés, préciser les conditions nécessaires et organiser les vérifications avant la décision.

1. Partir des situations que l’équipe doit résoudre

Réunissez une personne de la régulation, une du terrain et une de l’administration. Demandez à chacune de décrire une difficulté concrète : retrouver une demande modifiée, savoir quelle information manque ou suivre une transmission entre deux rôles. Retenez quelques situations représentatives de votre activité.

Pour chaque situation, écrivez le résultat attendu. Par exemple : « Après un changement d’horaire, les personnes concernées doivent retrouver l’horaire retenu et identifier ce qui attend encore une confirmation. » Cette formulation donne un point à vérifier pendant la démonstration.

Classez ensuite les besoins selon leur importance pour le démarrage. Un besoin indispensable mérite une vérification complète avant la décision. Une amélioration utile peut faire l’objet d’un essai complémentaire. Les sujets à traiter plus tard restent dans une liste séparée, avec leur raison d’être.

2. Préparer une même trame pour chaque rendez-vous

Envoyez vos situations à l’interlocuteur avant la démonstration, avec des données entièrement fictives. Précisez les rôles concernés et le résultat recherché. Laissez l’éditeur expliquer son parcours, puis revenez aux points que vous voulez examiner.

Gardez le même point de départ d’une démonstration à l’autre. Si une mission fictive comporte une information manquante, conservez ce détail dans les deux présentations. Une comparaison perd de son utilité lorsque chaque outil répond à un exercice différent.

Prévoyez un temps pour les questions de l’équipe. Les tâches peuvent être réalisées dans un ordre différent selon le logiciel : observez le résultat, les informations nécessaires et les passages entre rôles. Notez les conditions de l’essai, notamment les droits utilisés, le paramétrage présenté et les éventuelles options.

3. Remplir une fiche courte pour chaque besoin

Une fiche peut tenir dans un document partagé autorisé par l’entreprise. Inscrivez d’abord le besoin et son niveau de priorité. Ajoutez le scénario demandé, puis le résultat observé pour chaque solution. Décrivez les actions avec des mots simples, assez précis pour qu’un collègue absent comprenne ce qui a été montré.

Ajoutez les conditions nécessaires : intervention d’un autre rôle, réglage préalable, équipement ou option à confirmer. Une fonction présentée dans une démonstration doit être rapprochée du périmètre proposé à votre entreprise.

Terminez par un état explicite : « observé sur le scénario », « à vérifier » ou « hors du périmètre présenté ». Pour chaque point ouvert, notez la question exacte, la personne chargée d’obtenir la réponse et le prochain échange prévu. Un champ vide doit rester un point à traiter ; il ne vaut ni validation ni constat d’absence.

4. Distinguer les observations des réponses à confirmer

Lorsqu’un parcours est montré, décrivez ce qui a réellement été constaté. Si l’interlocuteur annonce qu’un autre cas est possible, gardez cette réponse avec la vérification attendue. Demandez un complément adapté : nouvelle démonstration, essai convenu avec l’éditeur ou confirmation écrite du périmètre.

Évitez de résumer trop tôt l’ensemble par une note globale. Un résultat favorable sur plusieurs fonctions secondaires ne règle pas une incertitude sur une tâche indispensable. Relisez d’abord ces tâches une par une, puis examinez le confort d’utilisation avec les futurs utilisateurs.

Conservez aussi les désaccords utiles. La régulation peut apprécier un parcours que l’administration trouve incomplet. Faites préciser à chaque personne l’étape concernée et l’information qu’elle attend. Vous obtenez ainsi une question vérifiable à poser au prochain rendez-vous.

5. Exemple fictif : comparer une correction d’horaire

Exemple entièrement fictif, sans donnée réelle de patient, de client ou d’entreprise. Les solutions A et B sont imaginaires.

L’entreprise Démo utilise la mission TEST-A pour ses deux rendez-vous. Le scénario prévoit une modification d’horaire après affectation. Le résultat attendu est de retrouver l’horaire retenu au bureau et sur le parcours présenté au terrain, puis de comprendre comment la prise en compte du changement est suivie.

Pendant la présentation A, le bureau et le terrain sont montrés. L’équipe note les étapes observées, mais n’a pas encore vérifié le parcours avec les droits prévus pour ses chauffeurs. Elle conserve ce point « à vérifier ».

Pendant la présentation B, seul le bureau est montré. La partie terrain reste également « à vérifier », avec une demande de présentation complémentaire. La grille conserve la différence entre les deux observations sans conclure qu’une fonction manque. Le prochain échange peut ainsi porter précisément sur ce qui reste à voir.

6. Décider avec une liste de points résolus et ouverts

Après les rendez-vous, relisez la grille ensemble. Pour chaque besoin indispensable, vérifiez que le résultat observé correspond au périmètre proposé et que les conditions de mise en service sont comprises. Gardez une trace des réponses obtenues et de leur date.

Terminez par un court relevé de décision : ce qui convient à l’équipe, ce qui nécessite encore un essai et ce qui doit être confirmé avant de fixer le démarrage. Cette synthèse servira aussi de base à la préparation du changement et à la prise en main.

Pour organiser votre découverte de DriveSoft autour de vos situations métier : drivesoft.fr/demo

Retrouvez les points à préparer pour votre changement de logiciel : drivesoft.fr/changer-de-logiciel