Udbud af forretningssoftware: proces, tidsplan og tilbudsevaluering

Udbud af forretningssoftware: værdi og forberedelse

Når en offentlig myndighed køber forretningssoftware som økonomi-, sags- eller HR-systemer, er det som udgangspunkt en offentlig kontrakt om leverance eller tjenesteydelse. Offentlige kontrakter tildeles af ordregivere, der bruger offentlige midler, og af enheder, der opererer under særlige omstændigheder. Kontrakter af højere værdi skal normalt i udbud gennem konkurrencebaserede procedurer.

Om EU's udbudsregler gælder, afhænger først og fremmest af kontraktens værdi. Tærsklerne varierer efter, hvad der købes, og hvem der køber, og justeres jævnligt med mindre beløbsændringer. Hovedtærsklen for offentlige indkøbs- og tjenesteydelseskontrakter med statslige myndigheder er 140.000 euro.

Fra 1. januar 2026 gælder i Danmark 1.044.400 kr. for statslige myndigheder og 1.611.360 kr. for regionale/kommunale myndigheder og offentligretlige organer for almindelige tjenesteydelser og vareindkøb. Konkurrence- og Forbrugerstyrelsen offentliggør tærskelværdierne for 2026 og 2027 i oversigten »Tærskelværdier 2026 og 2027«. Brug myndighedstype og kontraktens karakter til at finde den relevante sats, før procedurevalget og tidsplanen godkendes.

Delydelser har en tærskel på 596.800 kr. for både statslige og regionale/kommunale myndigheder og offentligretlige organer. Hvis softwareanskaffelsen omfatter særskilte leverancer, bør projektgruppen kortlægge, hvilke opgaver og betalinger der hører til hver leverance. Beskriv samtidig afhængighederne mellem system, integrationer og implementering, så opdelingen ikke skjuler opgaver, der skal koordineres i det samlede forløb.

For en kommune er den relevante tærskel derfor ikke nødvendigvis den statslige sats på 140.000 euro. Tærsklen afhænger af, hvem der køber, og skal altid kontrolleres i udbudsloven. For forretningssoftware er den relevante tærskel normalt satsen for almindelige tjenesteydelser eller vareindkøb.

Tærskelværdierne for 2026 og 2027 er ændret ved Europa-Kommissionens forordning nr. 2025/2150/EU, 2025/2151/EU og 2025/2152/EU af 23. oktober 2025 samt forordning nr. 2025/2487/EU af 4. december 2025. De trådte i kraft den 1. januar 2026.

Begynd behovsafklaringen med de arbejdsgange, softwaren skal understøtte, og de problemer, anskaffelsen skal løse. Beskriv ønskede resultater som mindre manuel registrering, mere sammenhængende data eller bedre understøttelse af sagsbehandlingen. Skeln mellem nødvendige forbedringer og ønsker, så kravspecifikationen ikke bliver en samling funktioner uden forbindelse til organisationens arbejde. Lad procesejerne godkende behovene, før de omsættes til leverandørkrav.

Omsæt behovene til krav, som leverandørerne kan besvare på samme grundlag. Beskriv den relevante arbejdsgang, forventet systemadfærd og den dokumentation, der skal vise, om løsningen opfylder behovet. Hold nødvendige krav adskilt fra egenskaber, der skal indgå i kvalitetsvurderingen. Det gør både tilbudsarbejdet og den efterfølgende evaluering mere præcis.

Kortlæg systemlandskabet, før integrationskravene skrives. Angiv, hvilke oplysninger der skal udveksles, hvor de kommer fra, og hvilke arbejdsgange der afhænger af dem. Beskriv også, hvem der har ansvar for de eksisterende systemer og for afklaringer med deres leverandører. Uafklarede grænseflader bør behandles som en planlægningsrisiko, fordi de kan påvirke både tilbuddenes sammenlignelighed og implementeringen efter kontraktindgåelsen.

Beskriv driftsbehov og informationssikkerhed sammen med de funktionelle krav. Leverandørerne bør kunne se, hvilke forventninger der er til adgangsstyring, håndtering af data, support og organisationens egen administration af løsningen. Afklar internt, hvilke forhold der skal dokumenteres i tilbuddet, og hvilke der skal prøves ved leverancen. Ellers risikerer projektgruppen at vurdere løfter, som senere viser sig vanskelige at kontrollere.

Alle offentlige indkøbsprocedurer i EU følger nationale regler; i Danmark gælder udbudsloven. Ved kontrakter af højere værdi bygger reglerne på de generelle EU-regler for offentlige udbud. Undtagelser og fritagelser omfatter fx køb af fast ejendom, særligt hastende tilfælde og situationer med kun én mulig leverandør.

Forretningssoftware er ikke en bygge- og anlægskontrakt. Derfor bruges tilbudsloven ikke til softwareanskaffelser; over tærsklen følger de udbudslovens regler.

I praksis bør værdien opgøres som samlet anskaffelsesværdi over den forventede kontraktperiode, ikke kun første licensregning. Typiske elementer: abonnement eller licenser, implementering og konfiguration, integration til eksisterende systemer, datamigrering, uddannelse, drift og support samt optioner om forlængelse eller flere brugere.

Til budgetarbejdet bør projektgruppen opstille de forventede betalinger for hver del af leverancen gennem kontraktperioden. Skeln mellem engangsarbejde, løbende betalinger og mulige udvidelser, og dokumentér antagelserne om brugere, datamængder og integrationsbehov. Bed økonomi og indkøb gennemgå beregningsgrundlaget sammen. Det giver et fælles udgangspunkt for værdivurderingen og for et prisbilag, hvor tilbuddenes økonomi kan sammenlignes uden skjulte forskelle i forudsætningerne.

Overstiger den samlede værdi den relevante tærskel, er anskaffelsen som udgangspunkt omfattet af udbudspligt efter EU-reglerne. Den skal annonceres gennem den valgte procedure, så interesserede leverandører får adgang til konkurrencen. Gør det samtidig tydeligt, hvordan leverandørerne skal deltage, hvilke dokumenter de skal aflevere, og hvor spørgsmål og svar håndteres. Deltagelse og tilbudsafgivelse skal passe til det valgte procedureforløb.

Adskil vurderingen af leverandøren fra vurderingen af selve softwaretilbuddet i projektgruppens arbejdsgrundlag. Referencer kan belyse erfaring med tilsvarende leverancer, mens løsningsbeskrivelsen viser, hvordan det konkrete behov tænkes opfyldt. Beskriv, hvad hver dokumenttype skal bruges til, så samme oplysning ikke ukritisk bliver afgørende flere steder. Det hjælper også leverandørerne med at levere målrettet dokumentation frem for generelt salgsmateriale.

Saml kravspecifikation, prisbilag, evalueringsbeskrivelse og kontraktudkast i et sammenhængende arbejdsgrundlag. Kontroller, at leverancens afgrænsning er den samme i dokumenterne, og at ansvar for integration, migrering og uddannelse er beskrevet konsekvent. Hvis en opgave nævnes som inkluderet ét sted og som tilkøb et andet, bliver tilbuddene vanskelige at sammenligne. Afklar sådanne forskelle, inden materialet offentliggøres.

Giv leverandørerne en ensartet struktur til deres besvarelser. For hvert relevant krav kan svarformatet bede om en forklaring af løsningen, eventuelle forudsætninger og den dokumentation, der understøtter svaret. Hold supplerende salgsmateriale adskilt fra de oplysninger, evalueringsgruppen faktisk skal bruge. En fælles svarstruktur gør det lettere at finde mangler og sammenholde tilbud uden at belønne præsentationens omfang frem for dens indhold.

Hvis demonstrationer skal understøtte kvalitetsvurderingen, bør projektgruppen forberede fælles opgaver og tydelige observationer på forhånd. Brug arbejdsgange, som afspejler den daglige anvendelse, frem for at lade leverandørernes foretrukne præsentation bestemme sammenligningen. Afklar også, hvordan observationerne skal dokumenteres og indgå i den beskrevne vurdering. En demonstration bør belyse de valgte kvalitetsforhold, ikke skabe nye vurderingskriterier undervejs.

Tænk afslutning og leverandørskifte ind i anskaffelsen, mens krav og kontrakt stadig kan formes. Beskriv behovet for at få data ud, forstå eksportformatet og overdrage nødvendige oplysninger til en ny løsning. Afklar også, hvilke opgaver organisationen selv skal kunne udføre. Det giver et mere dækkende grundlag for at vurdere både leverancens kvalitet og de omkostninger, der kan følge efter den almindelige driftsperiode.

Fordel ansvar for beslutninger og godkendelser, inden tidsplanen låses. Procesejere bør kunne tage stilling til arbejdsgange, it-funktionen til systemafhængigheder og økonomifunktionen til beregningsforudsætninger, mens indkøb og jura gennemgår udbudsgrundlaget. Aftal, hvem der samler tilbagemeldinger og afgør uenigheder. En fase er først klar til at blive afsluttet, når de nødvendige beslutninger er truffet, ikke blot når dokumenterne er skrevet.

Brug »Evalueringsmodeller – praktisk vejledning til offentlige indkøbere« til arbejdet med sammenstillingen af pris og kvalitet. Vejledningen beskriver blandt andet procentmodeller og sammenhængen mellem prisomregning, prisspænd og vægtning. Afprøv, hvordan modellen reagerer på forskellige prisniveauer og kvalitetsvurderinger, før materialet færdiggøres. Kontrollen skal vise, om den ønskede prioritering også slår igennem i beregningen.

I vurderingen af forretningssoftware kan det være relevant at se på områder som brugervenlighed og funktionalitet, fleksibilitet og skalerbarhed samt implementering, risikostyring og projektorganisation. Omsæt områderne til konkrete vurderingsspørgsmål: Hvordan understøttes arbejdsgangene, hvordan håndteres ændrede behov, og hvordan organiseres leverancen? Knyt hvert spørgsmål til den dokumentation, leverandøren skal levere, så kvalitetsbedømmelsen får et tydeligt grundlag.

Proces for udbud af forretningssoftware: procedurevalg

Proceduretyperne for forretningssoftware omfatter offentligt udbud, begrænset udbud, udbud med forhandling, konkurrencepræget dialog, innovationspartnerskab og projektkonkurrence. Dertil kommer udbudsteknikker som rammeaftale, elektronisk dynamisk indkøbssystem og elektronisk auktion.

Saml begrundelsen for procedurevalget, før projektgruppen udarbejder den endelige tidsplan. Afklar, hvor præcist behov og leverance kan beskrives, hvilke spørgsmål der stadig kræver markedsafklaring, og hvor omfattende tilbuddene forventes at blive. Vurder derefter, hvilken arbejdsbyrde proceduren giver for både organisationen og leverandørerne. Beslutningen bør bygge på anskaffelsens behov frem for en vane med at bruge samme fremgangsmåde hver gang.

Ved offentligt udbud kan alle interesserede virksomheder indsende tilbud; det er den mest anvendte procedure. Den passer, når behovet og kravene til softwaren kan beskrives præcist i udbudsmaterialet, så tilbuddene kan sammenlignes direkte.

Ved begrænset udbud kan alle bede om at deltage, men kun forhåndsudvalgte virksomheder må indsende tilbud. Det er en fordel, når der forventes mange interesserede leverandører, og antallet af tilbud skal holdes på et håndterbart niveau.

Ved udbud med forhandling kan alle blive bedt om at deltage, men kun forhåndsudvalgte opfordres til at indsende indledende bud og forhandle. Ordregiveren kan kun bruge proceduren, når forhandlinger er nødvendige på grund af købets særlige eller komplicerede natur. Inden for forsvar og sikkerhed samt vand, energi, transport og posttjenester kan proceduren bruges som standard.

Ved komplekse softwaresetups kan løsningen og integrationsbehovet ikke altid fastlægges fuldt ud på forhånd. Kravet om, at købet har særlig eller kompliceret karakter, skal derfor kunne begrundes.

Konkurrencepræget dialog kan bruges, når ordregiveren har defineret et behov, men endnu ikke kender metoden til at opfylde det – typisk ved større systemlandskaber, hvor løsningsmodellen skal udvikles i samarbejde med markedet.

Innovationspartnerskab kan bruges, når der er behov for at købe et produkt eller en tjenesteydelse, der endnu ikke findes på markedet. Projektkonkurrence anvendes til at finde frem til et udkast til et design.

Udbudsteknikker kan kombineres med procedurevalget. Ordregiveren kan indgå rammeaftale med en eller flere virksomheder om udbud med gentagne indkøb.

Ordregiveren kan godkende et elektronisk dynamisk indkøbssystem ved gentagne indkøb under begrænset udbud. Den kan også beslutte, at den endelige tildeling sker gennem en elektronisk auktion for at få det bedst mulige tilbud.

Et præcist beskrevet softwarebehov gør det lettere at sammenligne tilbud direkte ved offentligt udbud. Begrænset udbud kan være relevant, når projektgruppen vil arbejde videre med forhåndsudvalgte leverandører. Ved behov for forhandling om en særlig eller kompliceret anskaffelse skal begrundelsen for procedurevalget være klar. Dokumentér derfor både de afklarede krav og de løsningsspørgsmål, som stadig har betydning for valget.

Valget bør styres af behovets kompleksitet og kontraktens art. Kan kravene formuleres entydigt, og er prisen den afgørende faktor, peger det typisk mod offentligt udbud. Skal løsninger, integrationer eller leverancemodel drøftes med markedet, peger det mod dialog- eller forhandlingsprocedurer – men kun inden for reglernes betingelser.

Processen begynder med behovsafklaring, værdivurdering og procedurevalg, hvorefter kravspecifikation, tildelingskriterier og kontraktudkast færdiggøres. Efter offentliggørelsen håndteres spørgsmål og svar, og tilbuddene modtages inden tilbudsfristen. Evalueringsgruppen anvender den offentliggjorte model og dokumenterer grundlaget for tildelingsbeslutningen. Derefter underrettes tilbudsgiverne, standstill-perioden håndteres, og kontrakten indgås, før implementeringen sættes i gang som kontraktligt leveranceforløb.

Fordeler og ulemper ved forskellige udbudsteknikker

Tidsplan for forretningssoftware: milepæle og standstill

Byg tidsplanen som en række arbejdsperioder med klare afslutningsbetingelser: behovsafklaring, markedsundersøgelse, udbudsmateriale, tilbudsperiode og evaluering. Derefter følger tildeling, standstill og kontraktindgåelse før implementering. Fastlæg de interne perioders varighed ud fra opgaverne, de tilgængelige medarbejdere og behovet for godkendelser. For hver periode bør planen vise en ansvarlig, en slutdato og den beslutning eller leverance, som gør næste fase mulig.

Afslut behovsafklaringen, når procesejerne har godkendt behov, afgrænsning og beregningsforudsætninger. Afslut markedsundersøgelsen, når centrale spørgsmål om løsningsmuligheder og leveranceansvar er afklaret. Lad derefter perioden til udbudsmateriale rumme både skrivning, faglig gennemgang og samlet godkendelse af krav, prisbilag, model og kontrakt. Offentliggørelsen placeres efter denne godkendelse, så tilbudsperioden ikke begynder med et arbejdsgrundlag, projektgruppen endnu ikke er enig om.

Planlæg spørgsmål og svar som en selvstændig aktivitet i tilbudsperioden med en spørgefrist og interne svarfrister, der giver tid til faglig afklaring og godkendelse. Supplerende oplysninger om udbudsmaterialet skal være meddelt senest 6 dage før udløbet af fristen for afgivelse af ansøgning eller tilbud, jf. udbudsloven § 134, stk. 1. Frister i dage beregnes efter fristforordningen, Rådets forordning nr. 1182/71 af 3. juni 1971, hvor dagen for begivenheden ikke tælles med. Udpeg en ansvarlig for at samle spørgsmålene og kontrollere svarenes sammenhæng med materialet.

Ved offentlige udbud skal ordregiveren angive fristen for modtagelse af tilbud i udbudsbekendtgørelsen. Planlæg tilbudsvinduet fra offentliggørelsen frem til tilbudsfristen som en særskilt periode. Brug leverancens kompleksitet til at vurdere arbejdsbehovet: Leverandørerne skal kunne gennemgå krav, afklare forudsætninger og sammensætte løsningsbeskrivelse og pris.

Når ordregiveren har besluttet at tildele kontrakten, må kontrakten tidligst indgås efter en standstill-periode på 10 kalenderdage regnet fra dagen efter afsendelsen, hvis underretningen er sendt elektronisk, og 15 kalenderdage, hvis den er sendt pr. brev. Perioden følger lov om Klagenævnet for Udbud § 3, stk. 1, der henviser til udbudsloven § 173, stk. 1, og § 188, stk. 3. Ordregiveren kan fastsætte en længere standstill-periode.

Standstill gælder ikke, når en kontrakt tildeles ved udbud uden forudgående udbudsbekendtgørelse, ved en rammeaftale med eller uden genåbning af konkurrencen, inden for et dynamisk indkøbssystem, eller når den eneste berørte tilbudsgiver er den leverandør, der tildeles kontrakten, og der i øvrigt ikke er nogen berørte ansøgere. Ellers bør standstill-perioden indgå som en selvstændig milepæl i tidsplanen. Projektgruppen bør kende udløbsdatoen og have en plan for, hvordan eventuelle klager og spørgsmål håndteres efter de gældende regler, før kontrakten indgås.

Estimér evalueringsperioden ud fra arbejdsmængden frem for at lade den være resttid før kontraktunderskrift. Afsæt plads til gennemgang af tilbud, kvalitetsbedømmelse, prisberegning, fælles afstemning og udarbejdelse af begrundelser. Reserver evaluatørernes tid, før tilbudsfristen fastlægges, og indlæg buffer til afklaringer og kontrol. Perioden afsluttes først, når vurderinger, beregninger og beslutningsgrundlag er kontrolleret og klar til godkendelse.

Ved softwareanskaffelser er udarbejdelsen af udbudsmaterialet ofte den mest ressourcekrævende fase. Afsæt tid til at inddrage fagpersoner, it-arkitektur, informationssikkerhed, jura og indkøb, til at beskrive integrations- og datakrav og til at besvare leverandørspørgsmål og eventuelt korrigere materialet inden tilbudsfristen.

Kontroller tidsplanen baglæns fra den ønskede implementeringsstart. Der skal være plads til kontraktindgåelse, standstill, godkendelse af tildelingsbeslutningen og den samlede evaluering før dette tidspunkt. Hvis planen ikke hænger sammen, flyttes milepælene eller bemandingen justeres, frem for at evalueringen presses sammen. Hold samtidig den kontraktlige implementeringsplan adskilt fra udbudsplanen, så leverandørens mobilisering og organisationens egen forberedelse bliver synlige.

Placér markedsafklaringen og arbejdet med evalueringsmodellen før offentliggørelsen. Brug »Evalueringsmodeller – praktisk vejledning til offentlige indkøbere« til at afklare modeltype, prisomregning og vægtning, mens der stadig er tid til intern gennemgang. Lad evalueringsgruppen prøve arbejdsformen på forhånd og vurdere sit tidsbehov. Det gør det lettere at reservere en realistisk evalueringsperiode og undgå modelafklaringer, efter at tilbuddene er åbnet.

Tilbudsevaluering af forretningssoftware: kriterier og modeller

Kontrakten tildeles ud fra tildelingskriterierne i udbudsmaterialet. Hovedkriteriet er typisk det bedste forhold mellem pris og kvalitet, eventuelt suppleret med underkriterier; enkelte udbud tildeles efter laveste pris. Uanset valget skal kriterierne og deres indbyrdes vægtning fremgå tydeligt, så leverandørerne kan vurdere, hvad der prioriteres.

Sådan bygges evalueringsmodellen for forretningssoftware: Vælg tildelingskriterium. Fastlæg underkriterier og vægtning. Vælg om der bruges pointmodel eller minimumskrav kombineret med kvalitative vurderinger og pris. Beskriv dokumentationskrav. Afklar evalueringsgruppe og håndtering af supplerende oplysninger.

Reglerne om ordregivers evaluering blev præciseret ved lov om ændring af udbudsloven fra marts 2019, der stiller krav om at offentliggøre alle dele af evalueringsmodellen og om at evaluere kvalitet uden kendskab til pris ved større bygge- og anlægskontrakter.

Evalueringsmodellen beskriver, hvordan tilbuddene måles op mod kriterierne. Der findes fx pointmodeller med vægtning af underkriterier og modeller, hvor minimumskrav og kvalitative vurderinger kombineres med pris.

Der skelnes mellem en relativ og en absolut evalueringsmodel. Ved en absolut model vurderes hvert tilbud for sig i forhold til, i hvor høj grad det opfylder de fastsatte krav; ved en relativ model vurderes tilbuddene i forhold til hinanden. Pointmodeller og procentmodeller er de typiske værktøjer, og vægtningen af pris og kvalitet skal fremgå af udbudsmaterialet.

Vægtningen skal fremgå klart, også når delkriterier vægtes forskelligt. I »Evalueringsmodeller – praktisk vejledning til offentlige indkøbere« bedømmes kvaliteten i et eksempel fra 0 til 8 point og omregnes til procentvise forskelle fra tilbuddet med bedste kvalitet. Priserne omregnes til procentvise forskelle fra tilbuddet med laveste pris og ganges med 55 pct. Ved softwareudbud skal de valgte kvalitetskriterier forbindes med en tydelig bedømmelsesbeskrivelse.

Modellerne bør vælges, så de passer til det konkrete behov og til den dokumentation, markedet realistisk kan levere.

Ved forretningssoftware vil kvalitative underkriterier ofte være afgørende: opfyldelse af funktionelle krav, integrationsmuligheder, sikkerhed og databehandling, implementerings- og migreringsplan, support og serviceniveau, kompetencer og referencer samt forhold omkring afslutning og overdragelse af data.

På prissiden bør man sammenligne den samlede omkostning over kontraktperioden frem for den enkelte licens- eller abonnementspris – typisk licenser eller abonnement, implementering, integration, migrering, uddannelse, drift og support samt eventuelle optioner.

Registrér først tilbuddenes besvarelser og dokumentation i et fælles vurderingsgrundlag. Bedøm derefter de kvalitative underkriterier efter den beskrevne model, beregn prisresultaterne, og sammenstil dem med den offentliggjorte vægtning. Kontroller beregninger og begrundelser, så resultatet kan forklares ud fra tilbuddenes indhold. Underretningen om tildeling bør udformes i overensstemmelse med udbudsreglerne, så de berørte tilbudsgivere får den nødvendige begrundelse og information om klagemuligheder.

Klagenævnet for Udbud har tilkendegivet, at ordregiveren skal oplyse vægtningen, hvis ordregiveren lader delkriterier vægte forskelligt under evalueringen.

Afklar i god tid, hvem der vurderer hvad, og hvordan uenighed og supplerende oplysninger håndteres. Det understøtter en systematisk og ensartet vurdering.

Evalueringen af forretningssoftware gennemføres trin for trin: Vælg tildelingskriterium. Fastlæg underkriterier og vægtning. Vælg pointmodel eller minimumskrav kombineret med kvalitative vurderinger og pris. Beskriv dokumentationskrav. Nedsæt evalueringsgruppe. Vurder tilbuddene systematisk og ensartet. Begrund tildelingsbeslutningen.