Leverandørvurdering uden ranglister: kriterier, referencer og risici

Hvorfor ranglister ikke er en leverandørvurdering

En leverandørvurdering uden ranglister bygger på kriterier, referencer og navngivne risici. Vægt kriterierne, efterprøv dokumentationen, og beskriv konsekvenserne af uklart ansvar, persondatabehandling og afhængighed af leverandøren. Vurder leverandøren ud fra den rolle og de ydelser, der indgår i købet.

En rangliste er ikke en leverandørvurdering. Den viser navn og placering, men sjældent kriterier, vægte og verifikationer bag placeringen. Rækkefølgen i en liste er ikke en vurdering.

Kriterierne skal passe til softwarekøbet: funktionalitet, integrationer, sikkerhed, brugervenlighed, support, vedligeholdelse, videreudvikling og samlet pris. Referencer skal kunne efterprøves, og risici skal beskrives konkret, eksempelvis afhængighed af leverandøren, uklart ansvar eller manglende dokumentation.

En liste over softwareleverandører viser ikke nødvendigvis, om vurderingen dækker platform, implementering og drift. Skeln derfor mellem selve softwaren og de ydelser, hver leverandør tilbyder, og vurder dem efter de samme kriterier. Brug kandidatnavne som udgangspunkt for undersøgelse, ikke som en rangorden.

Kandidatnavne kan være et udgangspunkt for undersøgelse, men et platformnavn er ikke i sig selv dokumentation for, at kravene er opfyldt.

Metoden er: definér leverandørrollen, byg en vægtet kriteriematrix, kræv primær dokumentation, fastlæg tildelingskriterier, og beskriv risici og beslutningsregler. Den giver konkrete kriterier, referencer og risici uden rangliste.

Når et tilbud omfatter rådgivning om CMS-valg, udvikling eller support, skal hver ydelse fremgå særskilt. Bed leverandøren beskrive, hvad der leveres, hvem der har ansvaret, og hvilken dokumentation virksomheden får. Vurder derefter tilbuddet mod de samme krav som de øvrige kandidater.

Registrér hver kandidat med den tilbudte platform, funktioner og ydelser samt ansvaret for implementering og drift. Notér også, hvilke dokumenter der underbygger hvert centralt krav. Så kan vurderingen skelne mellem leverandørens påstande og forhold, der er dokumenteret.

Gennemgå for hver kandidat, om tilbuddet beskriver support, vedligeholdelse og videreudvikling, og hvem der udfører opgaverne. Sammenhold beskrivelsen med virksomhedens krav, og markér uafklarede forhold tydeligt. Bed om svar på de åbne spørgsmål, før vurderingen afsluttes.

Hvis en platform har officiel support, eller supporten leveres af en ekstern part, bør det fremgå af vurderingen. Bed om en beskrivelse af, hvem der yder support, hvad den omfatter, og hvordan virksomheden får hjælp, hvis den nuværende leverandør udskiftes. Få også ansvarsfordelingen med i tilbuddet.

Ved softwarekøb skal vurderingen omfatte de ydelser, der faktisk indgår: platform, implementering, support, vedligeholdelse og videreudvikling. Bed leverandøren beskrive ansvar og leverancer for hvert område, og vurder oplysningerne op mod de samme kriterier for alle tilbud.

For hver softwareleverandør skal tilbuddet beskrive platform, funktioner, ansvar for implementering, support, vedligeholdelse og videreudvikling. Manglende oplysninger noteres som uafklarede. En gennemført kriteriematrix skal vise de aftalte vægte og scorer, så beslutningen kan efterprøves.

Afklar softwareleverandørens rolle og opgave

Afklar opgaven, før du sammenligner softwareleverandører. En leverandør kan stå for platform, implementering, hosting, support eller videreudvikling, og tilbuddene kan derfor dække forskellige ydelser. Beskriv først, hvilke opgaver der skal løses, og hvem der skal have ansvaret for dem.

En softwareleverandør kan levere en platform, konfigurere den og hjælpe med implementering. En anden part kan stå for drift, support eller videreudvikling. Bed om en tydelig beskrivelse af leverancer, ansvarsfordeling og grænserne mellem leverandørens ydelser og virksomhedens egne opgaver.

Kriterierne skal følge leverandørens rolle. En implementeringspartner vurderes blandt andet på løsningsbeskrivelse, overdragelse og dokumentation, mens en drifts- eller supportleverandør vurderes på ansvar, arbejdsgange og opfølgning. Vurder først tilbuddene, når det er klart, hvilke ydelser hver part påtager sig.

Kriterierne skal være navngivet, før leverandørerne sammenlignes. For software kan de omfatte funktionalitet, integrationer, sikkerhed, brugervenlighed, dokumentation, support og vedligeholdelse. Vurder også, om tilbuddet beskriver, hvordan løsningen kan videreudvikles, og hvem der har ansvaret for det.

Vurder løsningen ud fra virksomhedens konkrete krav til funktioner, integrationer, adgangsstyring, drift og videreudvikling. Et produktnavn er ikke dokumentation for, at kravene er opfyldt. Bed om belæg for hvert centralt punkt, og notér det, der fortsat er uafklaret.

For softwareleverandører skal rollerne præciseres: Hvem leverer CMS-platformen, hvem implementerer den, og hvem står for support og vedligeholdelse? Afklar også, om videreudvikling er med i tilbuddet. Ellers kan et tilbud se billigt ud, men mangle ydelser, virksomheden har brug for.

Lav en tydelig fordeling af opgaverne: Hvem leverer løsningen, hvem implementerer den, og hvem står for drift, support og vedligeholdelse? Beskriv også, hvem der håndterer ændringer og overdragelse. Brug den samme rollefordeling, når tilbuddene sammenlignes.

Byg en vægtet kriteriematrix til softwarevalg

Lav en vægtet matrix, hvor hvert kriterium får en vægt, før tilbuddene vurderes. Relevante kriterier for software kan være funktionalitet, integrationer, sikkerhed, brugervenlighed, implementering, support, vedligeholdelse, dokumentation og samlet pris. Tilføj kriterier, der følger af virksomhedens konkrete behov.

Definér hvert kriterium, før I vægter det, så vurderingen kan gentages: funktionalitet er de nødvendige funktioner, integrationer er samspillet med andre systemer, sikkerhed er adgangsstyring og beskyttelse af data, og samlet pris er alle betalinger over aftalens løbetid. Beskriv også, hvad support, vedligeholdelse og videreudvikling skal dække for at tælle med.

Matrixen skal navngive hvert kriterium, før vægte og scoringsregler fastlægges. Hvert kriterium får en scoringsregel, og reglerne låses, før tilbuddene åbnes. Vælg en simpel, gentagelig model, og definér vægte, der matcher forretningsmålene.

Matrixen bør have stopkriterier, der afspejler virksomhedens behov. Vurder de samlede omkostninger, ikke kun den indledende pris; medregn de ydelser og det ansvar, der følger med tilbuddet. Beskriv også, hvordan manglende dokumentation eller uafklarede leverancer påvirker vurderingen.

Sammenlign tilbuddenes prismodeller på samme grundlag. Afklar, hvad prisen omfatter, hvilke ydelser der faktureres særskilt, og hvordan ændringer eller ekstraarbejde håndteres. Hvis oplysningerne mangler, noteres det som uafklaret frem for at antage, at tilbuddene kan sammenlignes direkte.

Vurder også, om tilbuddet beskriver overgangen fra aftale til implementering, og hvilke leverancer der skal godkendes undervejs. Bed leverandøren forklare betalingsvilkår og sammenhængen mellem betaling, leverancer og dokumentation. Sammenlign først vilkårene, når tilbuddenes indhold og forudsætninger er tydelige.

Et tilbud fra en softwareleverandør bør beskrive pris, leverancer, forudsætninger og ansvar. Undersøg, om support, vedligeholdelse og videreudvikling er inkluderet, eller om de tilbydes særskilt. Sæt uafklarede forhold ind i matrixen, så de ikke forsvinder i en samlet pris.

Kriterierne bør dække levering, service, omkostninger og samlet værdi. Bed tilbudsgiverne oplyse de responstider og serviceniveauer, de tilbyder, samt hvordan eventuelle enhedspriser og samlede ejeromkostninger beregnes. Sammenlign kun oplysninger, der dækker de samme ydelser og forudsætninger.

Et gennemført eksempel: funktionalitet og integrationer vægtes højt, support og pris middel, og sikkerhed sættes som stopkriterium. Hvert kriterium scores opfyldt, delvist opfyldt, ikke opfyldt eller ikke oplyst, og hver score skal have et dokumentationsbelæg. Vægte, scoringsregler og stopkriterier låses, før tilbuddene åbnes.

Vurder hvert tilbud efter de samme funktionelle krav, integrationsbehov og krav til vedligeholdelse. Bedømmelsen bør bygge på skriftlig dokumentation, og ansvaret for support og ændringer skal fremgå. Brug de vægte, der er fastlagt på forhånd, frem for at ændre prioriteringen under evalueringen.

Underbyg hvert kriterium med troværdige kilder for at styrke scoren og reducere bias. Kilder kan blandt andet være interne systemer, indkøbs- og fakturadata, præstationsscorecards og hændelseslogfiler.

Sammenlign omkostninger ved at bede om en opdeling af engangsbetalinger, løbende betalinger og ydelser, der faktureres særskilt. Afklar også, hvordan ændringer og ekstraarbejde prissættes. Notér manglende oplysninger som uafklarede i stedet for at antage, at tilbuddenes samlede priser dækker det samme.

En gennemført kriteriematrix skal have faktiske vægte og scorer. Er vægte eller scorer ikke oplyst, noteres "ikke oplyst".

Referencer og dokumentation fra softwareleverandører

Bed leverandøren om dokumentation for de krav, der indgår i vurderingen, og notér, hvor hvert dokument underbygger et tilbud. Oplysninger, der ikke er offentligt tilgængelige eller fremlagt, markeres som "ikke oplyst" frem for at blive anslået. Kan leverandøren ikke dokumentere et krav, skal det fremgå af vurderingen.

Afhængigt af opgaven kan dokumentationen omfatte stiftelses- og ejerforhold, kontraktudkast, forsikringsforhold og referencer med kontaktmulighed. I bør også kunne dokumentere, hvor data behandles, hvem der har adgang, og hvilke databehandlere der indgår.

Til persondatadelen kan I bruge Datatilsynets vejledning om dataansvarlige og databehandlere og skabelonen til en standard-databehandleraftale (Datatilsynet). Aftalen bør blandt andet håndtere brug af underdatabehandlere, og den dataansvarlige skal føre tilsyn med, at databehandleraftaler overholdes, herunder at databehandleren har gennemført de aftalte tekniske og organisatoriske sikkerhedsforanstaltninger (Datatilsynet).

Kontrollér, at leverandørens navn og virksomhedsoplysninger stemmer på tværs af tilbud, kontraktudkast og de dokumenter, leverandøren selv har fremlagt. Notér uoverensstemmelser, og bed om en forklaring, før vurderingen afsluttes. Sørg for, at det også er klart, hvilken part der skal indgå aftalen.

Bed om dokumentation, der belyser leverandørens økonomiske forhold, når det er relevant for købet. Angiv, hvilke dokumenter I har brug for, og hvordan oplysningerne indgår i vurderingen. Hvis dokumentationen ikke leveres, noteres forholdet som uafklaret.

Ved softwarekøb kan dokumentationen omfatte løsningsbeskrivelse, sikkerhedsoplysninger, integrationsbeskrivelser, driftsvilkår og ansvarsfordeling. Bed også om materiale, der viser, hvad support og vedligeholdelse omfatter. Notér manglende dokumentation som uafklaret, så den kan indgå i vurderingen.

Brug referencer til at undersøge, om leverandøren har løst opgaver, der ligner virksomhedens behov. Spørg til leverandørens konkrete rolle, de leverede ydelser, driften i dag og håndteringen af vedligeholdelse. Stil de samme spørgsmål til hver reference, og notér svar, der kan bekræfte eller nuancere tilbuddet.

Forbered en spørgeramme til referencen med spørgsmål om leverancens omfang, ansvarsfordeling, samarbejde og eventuelle problemer. Bed referencen skelne mellem det, leverandøren selv udførte, og opgaver, der lå hos andre parter. Notér svarene, så de kan holdes op mod tilbuddet.

Referencerne bør vise, hvilken rolle leverandøren havde, og hvordan løsningen drives og vedligeholdes i dag. Spørg også, hvordan leverandøren håndterer opgraderinger og migreringer fra ældre versioner eller fra andre platforme.

Aftal med leverandøren, at referencen må kontaktes, og få kontaktmuligheden, før den bruges i vurderingen. Kontakt referencen direkte, stil de samme centrale spørgsmål, og notér, hvem der svarede, og hvilke oplysninger der blev bekræftet. Hvis kontakt ikke kan etableres, markeres det som "ikke oplyst".

En leverandørs beskrivelse af erfaring med en platform, rådgivning eller vedligeholdelse er et udgangspunkt for opfølgende spørgsmål. Bed om konkrete oplysninger om leverandørens rolle og de leverede ydelser, og sammenhold dem med en kontaktbar reference. Leverandørens egen beskrivelse erstatter ikke denne efterprøvning.

Afklar, hvem der yder support, hvilke henvendelser tilbuddet omfatter, og hvordan leverandøren beskriver sine svartider. Bed om at få vilkårene og ansvarsfordelingen på skrift, også hvis en anden part står for supporten. Sammenhold oplysningerne med kravene i kriteriematrixen.

Sammenhold hvert krav med skriftlig dokumentation eller en note om, at det ikke er oplyst. Indhent tilladelse til at kontakte referencerne, stil dem ensartede spørgsmål, og notér hvilke ydelser de kan bekræfte. Markér forskelle mellem referencens svar og leverandørens tilbud til opfølgning.

Dokumentér gennemgange, godkendelser og opfølgende handlinger, så beslutningen kan forsvares i en revision. Det understøtter lovgivningsmæssige, kunde- og interne krav.

Bed om adgang til en test- eller prøveversion, så funktioner og integrationer kan efterprøves, før I beslutter jer. Notér, hvad der ikke kunne testes, som uafklaret i vurderingen.

Hvis leverandøren fremhæver en bestemt softwareversion eller et længere supportbehov, så bed om dokumentation for, hvilke versioner der understøttes, og hvilke vilkår der gælder. Notér oplysningerne i vurderingen, og undersøg, om de dækker virksomhedens planlagte brug. Behandl en anbefaling som et spørgsmål, der skal efterprøves.

Tilpas dokumentationskravet til leverancen. Bed om skriftligt belæg for løsningens funktioner, ansvar for implementering og drift, indholdet af support og vedligeholdelse samt håndtering af videreudvikling. Sammenhold hvert svar med kravene i kriteriematrixen.

Sammenhold leverandørens virksomhedsoplysninger med tilbuddet og kontraktudkastet. Kræv også belæg for løsning, support, vedligeholdelse og videreudvikling. Hvis et centralt forhold ikke er dokumenteret, skal det fremgå som uafklaret i vurderingen.

Tildelingskriterier ved offentlige og private softwarekøb

Ved et offentligt softwarekøb bør du afklare, om indkøbet gennemføres som et udbud efter Udbudsloven. Brug i så fald kravene og evalueringsmodellen i udbudsmaterialet som vurderingsgrundlag. Ved private køb kan virksomheden fastlægge en tilsvarende model internt (retsinformation.dk).

Efter de medsendte kilder opgøres tærskelværdierne i danske kroner. Tilbudsloven gælder for bygge- og anlægsopgaver, hvor kontraktens samlede værdi ikke overskrider EU's gældende tærskelværdi, og hvis ordreværdien overstiger denne tærskel, træder Udbudsloven i kraft; opgaven skal da sendes i EU-udbud, så virksomheder i hele unionen har lige muligheder for at byde ind (byggefakta.dk).

Fastlæg kriterierne ud fra virksomhedens behov, og brug dem konsekvent, når tilbuddene vurderes. Beskriv derfor de behov, kriterierne skal afspejle, og brug dem konsekvent, når tilbuddene vurderes.

Tilbudsgivere skal opfylde kravene til udelukkelse og egnethed (retsinformation.dk).

Tildelingskriteriet og eventuelle øvrige kriterier skal oplyses. Skeln mellem obligatoriske krav og forhold, der vurderes som en del af tilbuddet. For private indkøb er det også nyttigt at fastlægge vurderingsgrundlaget, før tilbuddene sammenlignes.

Erhvervsministeren kan fastsætte regler om, at en ordregiver, der ikke inddrager miljø- eller klimahensyn i et udbud, skal oplyse om baggrunden i udbudsmaterialet (retsinformation.dk). Erhvervsministeriets vurdering var, at udbudsloven bør ændres, så der efter et mislykket udbud uden antagelige tilbud kan gives mulighed for udbud med forhandling eller konkurrencepræget dialog, hvis proceduren alene omfatter de tilbudsgivere, som i det foregående mislykkede udbud afgav tilbud i overensstemmelse med de formelle krav og opfylder kravene til udelukkelse og egnethed (retsinformation.dk).

Beskriv, hvilke krav der gælder for opgaven, hvilke tilbud der vurderes, og hvordan hvert kriterium anvendes. Hold krav og vurderingskriterier adskilt, så det er tydeligt, hvad leverandøren skal opfylde, og hvad der sammenlignes mellem tilbuddene.

Overfør princippet til private leverandørvurderinger. Beslut på forhånd, om du konkurrerer på pris alene eller på pris plus kvalitet, service, dokumentation og risiko. Vægtene og evalueringsmetoden skal være fastlagt, før tilbuddene åbnes. Ellers bliver "det bedste tilbud" en efterrationalisering.

Retten til aktindsigt i tilbud og oplysninger gælder alene for den, der har retlig interesse i at klage til Klagenævnet for Udbud, og for massemedier (retsinformation.dk). Planlæg derfor, hvordan vurderingen dokumenteres internt, så den kan fremlægges efterfølgende.

Gør evalueringsmodellen forståelig for dem, der skal bruge den: Angiv, hvilke oplysninger der tæller som dokumentation, hvordan kriterierne vurderes, og hvordan uafklarede forhold noteres. Offentliggørelse af evalueringsmodellen knytter sig til gennemsigtighedsprincippet.

Ved softwarekøb fastlægges vægte for funktionalitet, integrationer, support, vedligeholdelse og videreudvikling, før tilbuddene vurderes. Evalueringsmetoden skal forklare, hvordan hvert punkt bedømmes, og hvilken dokumentation der tæller som belæg.

Ved private indkøb er det nyttigt at fastlægge beslutningsgrundlaget skriftligt, før tilbuddene åbnes. Beskriv kriterier, vægte og evalueringsmetode, så det efterfølgende kan forklares, hvordan vurderingen førte til den valgte leverandør.

Risici ved softwareleverandører: GDPR, ansvar og exit

Når en softwareleverandør behandler personoplysninger på virksomhedens vegne, skal rollefordelingen afklares efter databeskyttelsesforordningen (GDPR). Datatilsynet skelner mellem dataansvarlig og databehandler og peger på risikoen for uklart ansvar, hvis rollerne ikke er tydelige (Datatilsynet). Gennemgå databehandleraftalen, og dokumentér, hvor data behandles, hvem der har adgang, og hvilke databehandlere der indgår.

Datatilsynet peger på, at usikkerhed om rollerne kan føre til, at ingen af parterne påtager sig ansvaret, eller at en part påtager sig et ansvar, den reelt ikke har (Datatilsynet). En dataansvarlig kan heller ikke altid skifte til en anden leverandør, selv om behandlingen ikke er tilfredsstillende eller lovlig (Datatilsynet).

En central softwaremæssig risiko er, at tilbuddet ikke gør ansvar og leverancer tydelige. Undersøg, hvem der står for implementering, drift, support, vedligeholdelse og ændringer. Hvis ydelser eller omkostninger ligger uden for aftalen, skal det fremgå, før tilbuddene sammenlignes.

Datatilsynet godkender som udgangspunkt ikke behandlinger på forhånd; det er den dataansvarliges opgave at leve op til reglerne (Datatilsynet). Datatilsynet fører tilsyn med, at reglerne om databeskyttelse bliver overholdt (Datatilsynet).

En anden risiko er uklarhed om adgang til og videreførelse af løsningen, hvis samarbejdet ophører. Aftalen bør beskrive, hvem der har ansvar for dokumentation, overdragelse og nødvendig bistand ved et leverandørskifte. Afklar også, hvilke leverancer der skal være til rådighed for virksomheden.

En leverandør kan oplyse, at den rådgiver om CMS-valg og tilbyder udvikling, support og løbende vedligeholdelse. Hvis sådanne ydelser indgår i tilbuddet, skal leverancer og ansvarsfordeling fremgå tydeligt. Brug leverandørens egne beskrivelser som udgangspunkt for spørgsmål, ikke som dokumentation for det konkrete tilbud.

Aftalen bør beskrive, hvem der ejer koden og rettighederne til løsningen, hvordan ændringer håndteres, og hvordan test og godkendelse foregår undervejs. Betaling bør knyttes til leverancer og verificeret kvalitet, ikke til løfter.

En risiko er afhængighed af én leverandør: Kan virksomheden få adgang til nødvendig dokumentation og hjælp til at videreføre løsningen ved et skifte? Afklar, hvordan overdragelse foregår, hvilke opgaver der kræver bistand, og hvem der har ansvar for dem.

Knyt betaling til tydeligt beskrevne leverancer og aftalte kontroller. Aftalen bør angive, hvornår leverancer kan godkendes, hvordan mangler håndteres, og hvad der sker, hvis dokumentation eller aftalte ydelser udebliver.

Navngiv risici som uklart ansvar mellem flere parter, manglende dokumentation for support og videreudvikling samt afhængighed ved exit. For hver risiko skal aftalen beskrive, hvem der har ansvaret, hvilken dokumentation virksomheden får, og hvordan overdragelsen håndteres. Notér også, hvordan afvigelser følges op.

Undersøg særskilt, om tilbuddet beskriver adgang til nødvendig dokumentation og hjælp ved et leverandørskifte. Afklar, hvem der ejer og vedligeholder løsningen, hvem der tester ændringer, og hvem der håndterer afvigelser. Hvis ansvaret deles mellem flere parter, skal grænserne mellem deres opgaver fremgå.

Registrér hver risiko sammen med dens mulige konsekvens, det ansvarlige kontaktpunkt og den handling, der skal afklare eller begrænse risikoen. Gennemgå registreringen, før aftalen indgås, og opdatér den, når leverancer, ansvar eller vilkår ændres.

Et eksempel på en post i registret: usikkerhed om rollerne indebærer risiko for, at ingen af parterne påtager sig ansvaret, eller at en part påtager sig et ansvar, den reelt ikke har (Datatilsynet). Registrér den dataansvarlige som ansvarlig for opfølgningen, og angiv en databehandleraftale med tydelig rollefordeling som handling.

Fra score til beslutning og opfølgning

Saml kriterier, referencer og risici i en beslutningsmodel. Vægt kriterierne, kræv primær dokumentation, og fastsæt stopkriterier.

Stopkriterier kan være, at leverandøren ikke vil beskrive løsningens funktioner, ansvar for support eller vilkår for vedligeholdelse. Et andet stopkriterium kan være manglende dokumentation for en central integration eller for den tilbudte platform. Beslut på forhånd, hvilke mangler der udelukker et tilbud.

Overvej en afgrænset prøveperiode eller et mindre første projekt. Test kommunikation, respons på fejl, dokumentation og leverancer, før I binder jer til hele aftalen.

Ingen rangliste kan erstatte egne verificerede data og en plan for, hvad der sker, når noget går galt.

Følg op på de mål, der er aftalt for kvalitet, responstid, afvigelser og omkostninger. Registrér, hvem der gennemgår resultaterne, og hvordan problemer håndteres. Hold samtidig exitplanen ajour, så virksomheden ved, hvilken dokumentation og bistand der skal være til rådighed ved et leverandørskifte.

Beslutningsmodellen samler kriterierne fra matrixen, dokumentationskravene og de identificerede risici. Scoren bør suppleres med en gennemgang af uafklarede forhold, før kontrakten underskrives. Beskriv også, hvem der godkender løsningen, og hvordan opfølgning på aftalen skal foregå.

Brug kriteriematrixen til at samle krav, dokumentation og risici i én beslutning. Sammenlign tilbuddene efter de samme regler, og forklar, hvordan vægte og scorer fører til den valgte løsning. En begrundet beslutning gør det lettere at følge op på aftalen og vurdere ændringer senere.

Hos softwareleverandører kan et stopkriterium være manglende dokumentation for platform, support, vedligeholdelse eller videreudvikling. Følg op på leverancer, afvigelser og exitvilkår, og afklar, hvordan løsningen kan overdrages ved et leverandørskifte. En leverandør kan beskrive support og løbende vedligeholdelse som dele af sine ydelser.