Belangrijkste punten
- Beoordeel het genoemde product, de implementatie en het land, niet de marketing van de leverancier als geheel.
- Gebruik toelatingscriteria vóór de gewogen beoordeling.
- Laat leveranciers zowel normale als uitzonderingsworkflows demonstreren.
- Vraag bewijs voor API's, beveiliging, lokalisatie, migratie en uitkomsten.
- Houd de status van publiek bewijs gescheiden van de definitieve verificatie tijdens de inkoop.
1. Stel het besluitvormingsteam en de scope vast
De selectie van een DMS raakt verkoop, occasions, werkplaats, onderdelen, financiën, IT, privacy en groepsrapportage. Stel een besluitvormingsteam samen met verantwoordelijke operationele eigenaren, niet alleen vertegenwoordigers. Wijs een executive sponsor, producteigenaar, dataverantwoordelijke, integratieverantwoordelijke, verantwoordelijke voor beveiliging en privacy, financial controller en verandermanager aan. Leg vast wie adviseert, wie goedkeurt en wie een verplichte eis kan afwijzen.
Documenteer juridische entiteiten, vestigingen, merken, landen, talen, gebruikers, transactievolumes en kritieke perioden. Scheid de huidige scope van een plausibele routekaart voor drie jaar. Een eis voor elke hypothetische toekomstige markt kan de beslissing vertekenen, terwijl het negeren van waarschijnlijke uitbreiding tot een volgende vervanging kan leiden.
2. Vertaal behoeften naar toetsbare vereisten
Een vereiste moet actor, trigger, gegevens, actie, resultaat en acceptatie benoemen. Vervang ‘sterk CRM’ door: ‘een aanvraag via web, OEM of telefoon wordt gematcht of aangemaakt, toestemming wordt vastgelegd, de lead wordt op merk en regio gerouteerd, een eigenaar en SLA zijn zichtbaar, communicatie wordt vastgelegd en een afgeronde deal geeft een status terug zonder dubbele klant.’
Maak een matrix van landen en OEM's. Leg per cel vereisten vast voor boekhouding, belasting, facturen, betalingen, registratie, garantie, onderdelen, campagnes, rapportage, identiteit en taal. De Europese context verschilt wezenlijk per land. De gegevens van Eurostat over personenauto's tonen grote verschillen in leeftijd en aandrijflijn van het wagenpark, terwijl EU-regels voor privacy, toegang tot gegevens en e-facturatie nog steeds om lokale implementatie vragen.[1]
3. Gebruik toelatingscriteria, gewogen criteria en bewijsniveaus
Toelatingscriteria voorkomen dat een hoge totaalscore een fataal tekort verbergt. Voorbeelden zijn productiesupport voor een vereist land, een benoemde OEM-interface, een wettelijke boekhoudkundige uitvoer, een grens voor dataresidentie of een migratiedeadline. Een niet-behaalde poort kan alleen worden opgelost met goedgekeurde herstelmaatregelen met een datum, eigenaar, kosten en contractuele toezegging.
| Dimensie | Illustratieve weging | Vereist bewijs |
|---|---|---|
| End-to-endfunctionele workflows | 25% | Gescripte demonstratie in het voorgestelde product |
| Passend bij land en OEM | 15% | Benoemde productiereferenties en specificaties |
| Gegevens, API en ecosysteem | 15% | Catalogus, sandbox, limieten, eigenaarschap, wijzigingsbeleid |
| Migratie en implementatie | 15% | Plan, middelen, acceptatie, terugval, referenties |
| Beveiliging, privacy en weerbaarheid | 10% | Rapporten, architectuur, DPA, DR-test en beheersmaatregelen |
| Gebruikerservaring en adoptie | 10% | Taaktesten op basis van rollen en opleidingsplan |
| Vijfjarige TCO en contract | 10% | Prijsmodel, indexatie, wijzigingen, ondersteuning en exit |
4. Script demonstraties in plaats van productrondleidingen te accepteren
Lever representatieve maar veilige gegevens en vaste scripts. Vraag de leverancier om een lead te tonen van offerte via inruil tot order; een occasion van taxatie, inspectie en voorbereiding via media en publicatie tot prijsstelling en verkoop; een reparatieorder van afspraak via werk van de monteur en onderdelen tot aanvullende goedkeuring en factuur; en een proces voor periodeafsluiting of managementrapportage.
Voeg uitzonderingen toe: dubbele klant, fout VIN, geannuleerde deal, niet-beschikbaar onderdeel, mislukte interface, offline inspectie, teruggedraaide factuur en een gebruiker die het proces tussentijds verlaat. Tel systemen, klikken, opnieuw ingevoerde waarden, handmatige exports en onzichtbare afhankelijkheden op de achtergrond. Leg de getoonde versie en markt vast.
Standaarden kunnen interoperabiliteit verbeteren, maar vervangen geen demonstratie. STAR publiceert API's voor automotive leads, deals en retaillevering, plus een domeinmodel voor retail.[2] Vraag of en hoe een leverancier relevante standaarden implementeert en test vervolgens de werkelijk voorgestelde interface.
5. Valideer claims over cloud, API, beveiliging en gegevens
Bepaal voor cloud of het om SaaS, dedicated hosting of gehoste legacyarchitectuur gaat. Vraag definities van beschikbaarheid, incidenthistorie, RPO, RTO, bewijs van back-up- en hersteltests, onderhoudsregels en een capaciteitsmodel. Vraag voor API's objecten, velden, gebeurtenissen, schrijfoperaties, authenticatie, sandbox, ratelimieten, overschrijdingen, versiebeheer, monitoring en rechten op gegevensexport op.
Beoordeel voor privacy en beveiliging rollen, minimale rechten, MFA, logging, versleuteling, kwetsbaarhedenbeheer, subverwerkers, doorgiftemechanisme, bewaartermijnen, verwijdering, melding van incidenten en onafhankelijke assurance. De AVG vereist op risico afgestemde maatregelen en privacy by design, maar een certificering of cloudprovider maakt het dealerbedrijf niet automatisch compliant.[3] Richtlijnen van ENISA kunnen bewijsverzoeken structureren, al moet de reikwijdte van NIS2 afzonderlijk worden beoordeeld.[4]
6. Hanteer eerlijke statussen voor publiek bewijs
| Benoemd product/markt | Bewijs voor openheid/API | Bewijs voor beveiliging | Interpretatie |
|---|---|---|---|
| Nextlane Platform, Europa | Bevestigd: officiële positionering voor open API's | Bevestigd: AWS-transformatie en aangegeven doel voor dataresidentie in de EU | Exacte DMS- en migratiestatus vereisen validatie van het voorstel |
| Pinewood-platform, wereldwijd/Europa | Bevestigd: verklaring over DMS-API en een benoemde integratie | Bevestigd: publieke ISO-verklaringen | Scope, rapporten en commerciële API-toegang vereisen validatie |
| Tekion ARC, VK | Bevestigd: er bestaat een API-overeenkomst | Bevestigd: trustportaal vermeldt certificeringen en versleuteling | Volwassenheid in continentaal Europa Niet beoordeeld |
| Omnetic, Europese publieke site | Niet publiek bevestigd: geen beoordeelde technische catalogus | Niet publiek bevestigd: geen beoordeelde matrix voor certificering/dataresidentie | Vraag bewijsmateriaal voor het voorstel; leid geen afwezigheid af |
| bee2link OpenFlex, Europa | Niet publiek bevestigd: geen beoordeelde algemene catalogus | Niet publiek bevestigd | Productspecifiek due diligence-onderzoek vereist |
De publieke status is een oriëntatiemiddel. Bewijs in het inkoopproces kan die wijzigen. Een leverancier moet de kans krijgen feitelijke fouten te corrigeren en binnen een passend proces actueel vertrouwelijk bewijs te leveren.
7. Rond af met implementatie, referenties en contract
Referentiegesprekken moeten passen bij land, grootte van het dealerbedrijf, OEM-complexiteit en scope. Vraag wat er na het contract veranderde, waarvoor workarounds nodig waren, welke gegevens faalden, hoe lang adoptie duurde, hoe incidenten zijn behandeld en wat de referentie anders zou doen. Vraag niet alleen of gebruikers het product waarderen.
Leg acceptatiecriteria contractueel vast. Behandel volledigheid en afstemming van gegevens, kritieke workflows, integraties, prestaties, beveiliging, training, omschakeling en ondersteuning. Begroot migratie-iteraties, omgevingen, API-gebruik, berichten, opslag, rapportagewerk, reizen, indexatie en wijzigingsverzoeken. Definieer serviceniveaus, escalatie, export bij exit, ondersteuning bij overgang, verwijdering en behouden toegang tot wettelijke registraties.
8. Waar Omnetic past
Omnetic moet op de shortlist staan wanneer de RFP gedeelde klant- en voertuigcontext, CRM voor verkoop en aftersales, diepgang in de levenscyclus van occasions, prijs- en voorraadacties en gestructureerde mobiele inspectie waardeert. Het verdedigbare onderscheid is continuïteit van inzicht of bewijs naar een operationele actie met een duidelijke eigenaar.
Een eerlijk voorstel van Omnetic moet nog steeds elke poort voor de genoemde landen, OEM's en modules aantonen. Publieke claims over schaal, certificeringen en het aantal native modules hebben actuele definities nodig. Bewijs over beveiliging, architectuur, API, SLA en migratie moet met dezelfde standaard worden beoordeeld als bij elke leverancier.
Beperkingen
De wegingen zijn illustratief en mogen niet zonder de prioriteiten van het dealerbedrijf worden gekopieerd. De publieke vergelijking is selectief en beoordeelt geen implementatiekwaliteit. Niet publiek bevestigd betekent nooit afwezig. Juridische vereisten en vereisten voor beveiliging, belasting en boekhouding vragen specialistische validatie.