Sådan vælger du et DMS: RFP og scorecard for europæiske forhandlere

1. Sammensæt beslutningsteamet og afgræns omfanget

Valg af DMS påvirker salg, brugte biler, værksted, reservedele, økonomi, IT, privatliv og koncernrapportering. Opret et beslutningsteam med ansvarlige operationelle ejere, ikke kun repræsentanter. Udpeg en ledelsessponsor, produktejer, dataansvarlig, integrationsansvarlig, ansvarlig for sikkerhed og privatliv, økonomicontroller og forandringsansvarlig. Definér, hvem der anbefaler, hvem der godkender, og hvem der kan afvise på et ufravigeligt krav.

Dokumentér juridiske enheder, lokationer, mærker, lande, sprog, brugere, transaktionsvolumener og kritiske perioder. Adskil nuværende omfang fra en realistisk treårig roadmap. Et krav for ethvert hypotetisk fremtidigt marked kan fordreje beslutningen, mens ignorering af sandsynlig udvidelse kan skabe endnu et systemskifte.

2. Omsæt behov til testbare krav

Et krav bør angive aktør, udløser, data, handling, output og accept. Erstat ‘stærkt CRM’ med: ‘en henvendelse fra web, OEM eller telefon matches eller oprettes, samtykke registreres, leadet dirigeres efter mærke og geografi, en ansvarlig og SLA er synlige, kommunikation indfanges, og en afsluttet handel returnerer status uden en dubletkunde.’

Byg en land- og OEM-matrix. Registrér for hver celle krav til regnskab, skat, faktura, betaling, registrering, garanti, reservedele, kampagne, rapportering, identitet og sprog. Den europæiske kontekst varierer væsentligt. Eurostats data om personbiler viser store forskelle mellem lande i vognparkens alder og drivlinje, mens EU-regler om privatliv, dataadgang og e-fakturering stadig kræver lokal implementering.^[1]

3. Brug porte, vægtede kriterier og dokumentationsniveauer

Kvalifikationsporte forhindrer, at en høj samlet score skjuler et fatalt hul. Eksempler er produktionssupport for et påkrævet land, en navngivet OEM-grænseflade, lovpligtigt regnskabsoutput, grænse for dataresidens eller migrationsfrist. En fejlet port kan kun løses ved godkendt afhjælpning med dato, ansvarlig, pris og kontraktlig forpligtelse.

4. Skriv demonstrationsscripts frem for at acceptere produktture

Lever repræsentative, men sikre data og faste scripts. Bed leverandøren vise et lead gennem tilbud, byttebil og ordre; en brugt bil gennem vurdering, inspektion, klargøring, medier, publicering, prissætning og salg; en reparationsordre gennem booking, teknikerarbejde, reservedele, ekstra godkendelse og faktura; samt en vej for periodelukning eller ledelsesrapportering.

Tilføj undtagelser: dubletkunde, forkert VIN, annulleret handel, utilgængelig reservedel, fejlet grænseflade, offline-inspektion, krediteret faktura og bruger, der forlader processen undervejs. Tæl systemer, klik, genindtastede værdier, manuelle eksporter og usynlige baggrundsafhængigheder. Registrér den demonstrerede version og det demonstrerede marked.

Standarder kan forbedre interoperabiliteten, men erstatter ikke en demonstration. STAR offentliggør API'er for automotive leads, handler og detaillevering samt en domænemodel for detailhandel.^[2] Spørg, om og hvordan en leverandør implementerer relevante standarder, og test derefter den faktisk foreslåede grænseflade.

5. Validér påstande om cloud, API, sikkerhed og data

For cloud skal du identificere SaaS, dedikeret hosting eller hostet legacy-arkitektur. Anmod om definitioner af tilgængelighed, hændelseshistorik, RPO, RTO, dokumentation for backup- og gendannelsestest, vedligeholdelsesregler og kapacitetsmodel. For API'er skal du anmode om objekter, felter, hændelser, skrivehandlinger, autentificering, sandbox, rate limits, merforbrug, versionsstyring, overvågning og rettigheder til dataeksport.

For privatliv og sikkerhed skal du vurdere roller, mindste privilegium, MFA, logning, kryptering, sårbarhedshåndtering, underdatabehandlere, overførselsmekanisme, opbevaring, sletning, underretning om hændelser og uafhængig sikkerhed. GDPR kræver risikopassende kontroller og databeskyttelse gennem design, men en certificering eller cloudleverandør gør ikke automatisk forhandleren compliant.^[3] ENISA-vejledning kan strukturere anmodninger om dokumentation, selv om NIS2-omfang skal vurderes separat.^[4]

6. Brug retfærdige statusser for offentlig dokumentation

Offentlig status er et orienteringsværktøj. Dokumentation i indkøbsprocessen kan ændre den. En leverandør bør inviteres til at rette faktuelle fejl og levere aktuel fortrolig dokumentation gennem en passende proces.

7. Afslut med implementering, referencer og kontrakt

Referencesamtaler bør matche land, forhandlerstørrelse, OEM-kompleksitet og omfang. Spørg, hvad der ændrede sig efter kontrakten, hvad der krævede løsninger, hvilke data der fejlede, hvor længe anvendelsen tog, hvordan hændelser blev håndteret, og hvad referencen ville gøre anderledes. Spørg ikke kun, om brugere kan lide produktet.

Gør acceptkriterier kontraktlige. Dæk datakomplethed og afstemning, kritiske workflows, integrationer, ydeevne, sikkerhed, uddannelse, overgang og support. Prissæt migrationsiterationer, miljøer, API-forbrug, beskeder, lagring, rapportarbejde, rejser, indeksregulering og ændringsanmodninger. Definér serviceniveauer, eskalering, exit-eksport, overgangssupport, sletning og bevaret adgang til lovpligtige poster.