Points clés
- Notez le produit, le déploiement et le pays nommés, pas le marketing au niveau éditeur.
- Utilisez des portes d'éligibilité avant la notation pondérée.
- Faites démontrer aux éditeurs à la fois les flux de travail normaux et d'exception.
- Exigez des preuves pour API, sécurité, localisation, migration et résultats.
- Gardez le statut de preuve publique séparé de la vérification finale des achats.
1. Formez l'équipe de décision et le périmètre
La sélection du DMS affecte vente, véhicules d'occasion, atelier, pièces, finance, IT, confidentialité et reporting de groupe. Créez une équipe de décision avec des responsables opérationnels imputables, pas seulement des représentants. Nommez un sponsor exécutif, un responsable produit, un responsable données, un responsable intégration, un responsable sécurité/confidentialité, un contrôleur financier et un responsable du changement. Définissez qui recommande, qui approuve et qui peut rejeter sur une exigence obligatoire.
Documentez entités juridiques, sites, marques, pays, langues, utilisateurs, volumes de transactions et périodes critiques. Séparez le périmètre actuel d'une feuille de route plausible à trois ans. Une exigence pour chaque marché futur hypothétique peut fausser la décision, tandis qu'ignorer une expansion probable peut créer un autre remplacement.
2. Convertissez les besoins en exigences testables
Une exigence devrait nommer acteur, déclencheur, données, action, sortie et acceptation. Remplacez « CRM solide » par « une demande web, constructeur ou téléphonique est appariée ou créée, le consentement est enregistré, le lead est acheminé par marque et géographie, un responsable et un SLA sont visibles, la communication est capturée, et une transaction complétée renvoie le statut sans client dupliqué ».
Construisez une matrice pays et constructeur. Pour chaque cellule, enregistrez les exigences de comptabilité, fiscalité, facture, paiement, immatriculation, garantie, pièces, campagne, reporting, identité et langue. Le contexte européen est matériellement varié. Les données de voitures particulières d'Eurostat montrent de grandes différences d'âge du parc et de motorisation par pays, tandis que les règles UE sur la confidentialité, l'accès aux données et la facturation électronique nécessitent encore une implémentation locale.[1]
3. Utilisez portes, critères pondérés et niveaux de preuve
Les portes d'éligibilité empêchent qu'un score total élevé cache une lacune fatale. Les exemples incluent le support en production pour un pays requis, une interface constructeur nommée, une sortie comptable légale, une frontière de résidence des données ou une échéance de migration. Une porte échouée ne peut être résolue que par une remédiation approuvée avec date, responsable, coût et engagement contractuel.
| Dimension | Poids illustratif | Preuve requise |
|---|---|---|
| Flux de travail fonctionnels de bout en bout | 25% | Démonstration scriptée dans le produit proposé |
| Adéquation pays et constructeur | 15% | Références de production nommées et spécifications |
| Données, API et écosystème | 15% | Catalogue, bac à sable, limites, propriété, politique de changement |
| Migration et implémentation | 15% | Plan, ressources, acceptation, retour arrière, références |
| Sécurité, confidentialité et résilience | 10% | Rapports, architecture, DPA, test de reprise et contrôles |
| Expérience utilisateur et adoption | 10% | Test de tâches basé sur les rôles et plan de formation |
| TCO à cinq ans et contrat | 10% | Modèle de prix, indexation, changement, support et sortie |
4. Scriptez les démonstrations au lieu d'accepter des visites produit
Fournissez des données représentatives mais sûres et des scripts fixes. Demandez à l'éditeur de montrer un lead à travers devis, reprise et commande ; un véhicule d'occasion à travers évaluation, inspection, préparation, médias, publication, pricing et vente ; un ordre de réparation à travers réservation, travail du technicien, pièces, approbation supplémentaire et facture ; et un chemin de clôture de période ou de rapport de gestion.
Ajoutez des exceptions : client dupliqué, mauvais VIN, transaction annulée, pièce indisponible, interface en échec, inspection hors ligne, facture extournée et utilisateur quittant en cours de processus. Comptez systèmes, clics, valeurs ressaisies, exports manuels et dépendances invisibles en arrière-plan. Enregistrez la version et le marché démontrés.
Les normes peuvent améliorer l'interopérabilité, mais ne remplacent pas une démonstration. STAR publie des API automobiles pour lead, transaction et livraison retail, et un modèle de domaine retail.[2] Demandez si et comment un éditeur implémente les normes pertinentes, puis testez l'interface réellement proposée.
5. Validez les affirmations de cloud, API, sécurité et données
Pour le cloud, identifiez SaaS, hébergement dédié ou architecture legacy hébergée. Demandez définitions de disponibilité, historique des incidents, RPO, RTO, preuves de tests de sauvegarde et de reprise, règles de maintenance et modèle de capacité. Pour les API, demandez objets, champs, événements, opérations d'écriture, authentification, bac à sable, limites de fréquence, dépassements, versionnement, monitoring et droits d'export de données.
Pour confidentialité et sécurité, évaluez rôles, moindre privilège, MFA, journalisation, chiffrement, gestion des vulnérabilités, sous-traitants, mécanisme de transfert, conservation, suppression, notification d'incident et assurance indépendante. Le RGPD exige des contrôles adaptés au risque et la protection dès la conception, mais une certification ou un fournisseur cloud ne rend pas automatiquement la concession conforme.[3] Les lignes directrices d'ENISA peuvent structurer les demandes de preuves, bien que le périmètre NIS2 doive être évalué séparément.[4]
6. Appliquez des statuts de preuve publique équitables
| Produit/marché nommé | Preuve d'ouverture/API | Preuve de sécurité | Interprétation |
|---|---|---|---|
| Nextlane Platform, Europe | Confirmé : positionnement officiel API ouverte | Confirmé : transformation AWS et objectif déclaré de résidence UE | Le DMS exact et le statut de migration nécessitent une validation de la proposition |
| Pinewood platform, mondial/Europe | Confirmé : déclaration d'API DMS et une intégration nommée | Confirmé : déclarations ISO publiques | Périmètre, rapports et accès API commercial nécessitent validation |
| Tekion ARC, Royaume-Uni | Confirmé : un accord API existe | Confirmé : le portail de confiance liste certifications et chiffrement | Maturité en Europe continentale Non évalué |
| Omnetic, site public européen | Non confirmé publiquement : pas de catalogue technique examiné | Non confirmé publiquement : pas de matrice de certification/résidence examinée | Demandez des preuves dans la proposition ; ne déduisez pas une absence |
| bee2link OpenFlex, Europe | Non confirmé publiquement : pas de catalogue général examiné | Non confirmé publiquement | Une diligence spécifique au produit est requise |
Le statut public est un outil d'orientation. Les preuves d'achat peuvent le changer. Un éditeur devrait être invité à corriger les erreurs factuelles et à fournir des preuves confidentielles actuelles selon un processus approprié.
7. Terminez par implémentation, références et contrat
Les appels de référence devraient correspondre au pays, à la taille de la concession, à la complexité constructeur et au périmètre. Demandez ce qui a changé après le contrat, quels contournements ont été nécessaires, quelles données ont échoué, combien de temps l'adoption a pris, comment les incidents ont été gérés et ce que la référence ferait différemment. Ne demandez pas seulement si les utilisateurs aiment le produit.
Rendez les critères d'acceptation contractuels. Couvrez complétude et rapprochement des données, flux de travail critiques, intégrations, performance, sécurité, formation, bascule et support. Tarifez itérations de migration, environnements, usage d'API, messages, stockage, travail de rapport, déplacements, indexation et demandes de changement. Définissez niveaux de service, escalade, export de sortie, support de transition, suppression et accès conservé aux enregistrements légaux.
8. Où se situe Omnetic
Omnetic devrait être présélectionné là où l'appel d'offres valorise le contexte partagé client et véhicule, le CRM vente et après-vente, la profondeur du cycle de vie véhicules d'occasion, les actions de pricing et de stock, et l'inspection mobile structurée. Sa distinction défendable est la continuité de l'insight ou de la preuve vers une action opérationnelle attribuée.
Une proposition Omnetic équitable doit encore prouver chaque porte pour les pays, constructeurs et modules nommés. Les affirmations publiques comme l'échelle, les certifications et le nombre de modules natifs nécessitent des définitions actuelles. Les preuves de sécurité, architecture, API, SLA et migration devraient être évaluées avec le même standard appliqué à chaque éditeur.
Limites
Les poids sont illustratifs et ne doivent pas être copiés sans les priorités de la concession. La comparaison publique est sélective et ne note pas la qualité d'implémentation. Non confirmé publiquement ne signifie jamais absent. Les exigences légales, de sécurité, fiscales et comptables nécessitent une validation spécialisée.