IT-udbud: sådan gør du det rigtigt første gang

IT-udbud: hvorfor det går galt – og hvad der skal til for at lykkes

Mange IT-udbud starter med en presset tidsplan, nogle løse slides om behov – og ender med en kontrakt, man skal leve med i 5-10 år. Det er en dyr måde at finde ud af, hvad man skulle have gjort anderledes.

Et IT-udbud er ikke bare et juridisk forløb frem mod tildeling. Det er en samlet beslutningsproces fra første behovsafklaring til den dag, du skifter leverandør igen. Fejl i de tidlige faser forplanter sig direkte til krav, evaluering, kontrakt – og din hverdag i driften.

I praksis handler et godt IT-udbud om fire ting, der skal hænge sammen:

• Krav: hvad du faktisk har brug for – funktionelt, teknisk og forretningsmæssigt
• Evaluering: hvordan du objektivt vælger den rigtige løsning og leverandør
• Kontrakt: hvordan du fordeler ansvar, risiko og forventninger
• Leverandørstyring: hvordan du styrer samarbejdet i drift og udvikling

Når de fire discipliner tænkes samlet, får du et udbud, der både kan holde juridisk, organisatorisk og økonomisk. Resten af artiklen går systematisk gennem, hvordan du gør det i praksis.

Overblik: sådan planlægger du et IT-udbud fra start til slut

Det mest oversete værktøj i IT-udbud er en simpel, realistisk procesplan. Ikke en pyntet Gantt i PowerPoint, men en kæde af beslutninger, aktiviteter og leverancer, der hænger logisk sammen.

En praktisk måde at tænke forløbet på er i tre faser:

1. Forberedelse: fra behov til udbudsmateriale

• Behovsafklaring: Hvilke forretningsproblemer skal løses? Hvilke processer, brugere og data er berørt? Her er det ofte relevant at koble til din samlede digitaliserings- eller transformationsstrategi, fx med inspiration fra guides om digital transformation.
• Systemlandskab og arkitektur: Hvad skal løsningen integrere til? Hvad skal på sigt udfases? Her kan artikler om IT-arkitektur og systemlandskab være nyttige som supplement.
• Risiko og regulering: Er der særlige krav til informationssikkerhed, NIS2, GDPR, evt. AI-regulering? (mere om det under krav).
• Markedsdialog: Hvordan ser markedet ud, og hvad er realistisk inden for din økonomi og tidsramme?
• Kravspecifikation og udbudsstrategi: Hvad skal du efterspørge, og hvilken udbudsform er passende (særligt vigtigt i det offentlige)?

Målet med forberedelsen er et konsistent udbudsmateriale: kravspecifikation, evalueringsmodel, udkast til kontrakt og en plan for, hvordan udbudsprocessen skal gennemføres og bemandes.

2. Gennemførelse: fra offentliggørelse til tildeling

• Offentliggørelse og spørgsmål/svar: Udbudsmaterialet deles, leverandører stiller afklarende spørgsmål, og du sikrer, at alle får samme information.
• Tilbudsmodtagelse og formel kontrol: Er alle mindstekrav opfyldt? Er tilbuddene konditionsmæssige (altså gyldige)?
• Evaluering: Pris og kvalitet vurderes efter den beskrevne model. Her er det altafgørende, at modellen ikke justeres undervejs.
• Beslutning og tildeling: Valg af vinder, tildelingsbesked og evt. klagefrist.

Målet her er en sporbar, gennemsigtig beslutning, hvor du kan dokumentere, hvorfor vinderen blev valgt – og hvorfor andre ikke gjorde.

3. Implementering og drift: fra kontrakt til hverdag

• Implementering: Projektorganisation, milepæle, test, migrering og idriftsættelse. Her kan det være nyttigt med en implementerings-tjekliste som supplement til kontrakten.
• Governance og leverandørstyring: Mødefora, roller, rapportering, incident management og ændringshåndtering.
• Performance og udvikling: Opfølgning på SLA’er og KPI’er og evt. videreudvikling. Artikler om performance og målstyring kan hjælpe med at definere de rigtige målepunkter.
• Exit og leverandørskifte: Plan for, hvordan du kan skifte leverandør igen uden kaos. Se evt. indhold om leverandørskifte for konkrete perspektiver.

Planlægningen bør starte før nogen skriver det første krav. Det er billigere at rette kursen på whiteboardet end i en kontraktforhandling.

De rigtige roller: hvem skal være med – og hvorfor?

IT-udbud fejler ofte, fordi projektet enten er for jurist-tungt eller for fagligt drevet uden juridisk styring. Kombinationen er nødvendig. Et minimums-hold i et typisk IT-udbud vil ofte bestå af:

• Projektleder
• Product owner / forretningsansvarlig
• Udbudsjurist
• IT-arkitekt
• Test manager / kvalitetsansvarlig

Projektleder: holder kæden samlet

Projektlederen sikrer fremdrift, møder, beslutninger og dokumentation på tværs af faserne. Uden en stærk projektleder bliver tidsplanen urealistisk, afklaringer hænger i luften, og du ender med forhastede beslutninger tæt på tilbudsfristen.

Product owner: kobler udbud til forretningen

Product owner eller den forretningsansvarlige er stemmen for brugere og forretning. Vedkommende:

• prioriterer funktionelle krav
• sikrer, at løsningen understøtter processer og mål
• hjælper med at definere, hvad der er “need to have” versus “nice to have”.

Hvis denne rolle er svag, får du ofte en løsning, der er teknisk flot, men dårligt forankret i hverdagen.

Udbudsjurist: sikrer lovlighed og sporbarhed

Udbudsjuristen oversætter jura til praksis: udbudsform, ligebehandling, gennemsigtighed, evalueringsmodel og kontrakt. Uden denne rolle risikerer du:

• uklare eller ulovlige evalueringsmodeller
• forhandlinger og ændringer, som strider mod udbudsretten
• øget risiko for klagesager og forsinkelser.

IT-arkitekt: tænker systemlandskab og tekniske afhængigheder

IT-arkitekten sikrer, at kravene passer ind i dit nuværende og fremtidige systemlandskab: integrationer, dataflows, sikkerhed, performance og skalerbarhed. Uden arkitekt ender du ofte med krav, der er svære at implementere eller meget dyre at integrere.

Test manager: tænker kvalitet og verificering

Test manageren eller den kvalitetsansvarlige tænker i testbarhed allerede ved kravskrivning: Hvordan kan vi se, at kravet er opfyldt? Hvilke scenarier skal være på plads, før løsningen går i drift? Uden testfokus bliver kravene ofte for vage, og du opdager først hullerne efter idriftsættelse.

Derudover involverer mange også informationssikkerhed, databeskyttelse (DPO), økonomi og repræsentanter for drift og support. Pointen er ikke at lave et kæmpe set-up, men at få de nødvendige kompetencer med tidligt – ikke først, når kontrakten er klar.

Kravspecifikation: sådan skriver du krav, der kan bruges i et udbud

Kravspecifikationen er fundamentet under både evaluering og kontrakt. Hvis den er uklar, bliver resten det også.

Funktionelle vs. ikke-funktionelle krav

• Funktionelle krav beskriver, hvad systemet skal kunne set fra brugerens og forretningens perspektiv. Eksempel: “Systemet skal understøtte oprettelse, godkendelse og arkivering af kontrakter med versionsstyring.”
• Ikke-funktionelle krav beskriver kvalitetsegenskaber og rammer: sikkerhed, performance, tilgængelighed, skalerbarhed, brugervenlighed mv. Eksempel: “Systemet skal kunne håndtere 500 samtidige brugere uden svartid over 2 sekunder for standardsøgninger.”

I et IT-udbud skal begge typer krav være:

• tilstrækkeligt præcise til at kunne evalueres
• tilstrækkeligt åbne til ikke at låse dig til én bestemt løsning eller leverandør.

Centrale ikke-funktionelle krav i IT-udbud

Nogle krav går igen i næsten alle IT-udbud og bør behandles systematisk:

• Informationssikkerhed og cybersikkerhed: krav til adgangsstyring, logging, kryptering, netværksadskillelse, beredskab osv. Her kan indhold om cyber- og informationssikkerhed give supplerende dybde.
• GDPR og databeskyttelse: rollefordeling (dataansvarlig/databehandler), behandlingshjemler, opbevaringsperioder, sletning/anonymisering, dataeksport uden for EU mv. Ved AI-løsninger kan du med fordel orientere dig i guides til EU’s AI-forordning, fx kortlægning ift. EU AI Act.
• SLA (Service Level Agreements): konkrete mål for oppetid, svartid, fejlrettelse (fx P1-P3), svartid på support, tilgængelighed uden for normal arbejdstid mv.
• Performance: svartider, databehandlingsvolumen, batchkørsler, rapportgenerering osv.
• Tilgængelighed: krav til brugere med funktionsnedsættelse, eventuelt WCAG-niveauer.
• Logning og sporbarhed: hvem har gjort hvad, hvornår – og hvor længe skal logdata gemmes.

Det kan være en fordel at tænke data-struktur og ansvar eksplicit, fx inspireret af simple “data contracts” mellem teams, som beskrevet i artiklen om data contracts. Den logik kan også bruges mellem kunde og leverandør: Hvem ejer hvilke data, og hvem må ændre hvad?

Gør krav testbare og målbare

En tommelfingerregel: Hvis du ikke kan se eller måle, om kravet er opfyldt, er det for vagt. Skriv derfor kravene, så de kan testes:

• “Systemet skal være brugervenligt” er ubrugeligt i evaluering.
• “90 % af testbrugere skal kunne gennemføre tre definerede kerneopgaver uden træning og uden fejl” kan vurderes.

Her er det en fordel at koble krav til konkrete KPI’er og mål, så det også giver mening senere i kontrakt og drift. Se fx artiklen om hvordan dine KPI’er hænger sammen som inspiration.

Kravtyper: mindstekrav, funktionskrav, sikkerhedskrav og “nice to have”

En stor del af faldgruberne i IT-udbud handler om, at kravene er blandet sammen. Du kommer langt ved at skelne tydeligt mellem disse kategorier:

Mindstekrav

Mindstekrav er absolutte krav, som skal være opfyldt for, at et tilbud overhovedet kan tages i betragtning. De bruges til at sortere ikke-egnede løsninger fra tidligt.

Eksempler:

• “Løsningen skal kunne integrere med NemLog-in” (hvis det er forudsætning for brug)
• “Leverandøren skal have dokumenteret ISMS (Informationssikkerhedsledelsessystem)”
• “Data skal opbevares inden for EU/EØS”.

Fejltype 1: Mindstekrav, der er for stramme eller detaljerede, så kun en leverandør reelt kan byde. Det kan give juridiske problemer og begrænser konkurrencen.

Funktionskrav

Funktionskrav beskriver, hvad løsningen skal kunne – uden at diktere præcis, hvordan leverandøren skal løse det. Det giver plads til innovation og forskellige tekniske tilgange.

Eksempel: “Systemet skal understøtte workflow for godkendelse i op til 5 niveauer, inkl. mulighed for delegationsregler og krydsende godkendelsesveje.”

Fejltype 2: Funktionskrav, der i praksis er designmanualer med meget detaljerede skærmbilleder og teknisk arkitektur. Det kan låse dig til bestemte produkter og begrænse konkurrencen unødigt.

Sikkerheds- og compliancekrav

Det er ofte en blanding af mindstekrav og funktionskrav. For eksempel:

• Mindstekrav: “Leverandøren skal kunne dokumentere efterlevelse af relevante NIS2-krav for tjenesten.”
• Funktionskrav: “Løsningen skal understøtte differentieret adgangsstyring baseret på roller og grupper.”

Her kan du hente konkrete leverancer og tjekpunkter fra fx NIS2-guides som NIS2 uden panik og om nødvendigt bruge en hurtig gap-analyse som beskrevet i NIS2 sprint vs. storladent program.

Juridiske krav

Det kan være krav til kontraktgrundlag (fx K-kontrakter i det offentlige), databehandleraftale, ansvarsbegrænsning, forsikringer, tavshedserklæringer osv. De bør være gennemtænkt sammen med udbudsjurist og kontraktrådgiver, så de både er realistiske og beskytter organisationen.

“Nice to have”-ønsker

Denne kategori er undervurderet. Hvis alt er krav, bliver intet prioriteret. Ved at markere “nice to have” får du:

• plads til at se, hvor leverandørerne differentierer sig
• fleksibilitet i forhandling og implementering
• mulighed for at udbygge senere uden at bryde kontrakten.

En god praksis er at lade “nice to have” indgå i kvalitetsvurderingen med en lavere vægt – de må ikke ændre ved opgaven, men kan være tie-breaker mellem ellers jævnbyrdige tilbud.

Markedsdialog: brug leverandørerne – uden at bryde spillereglerne

Markedsdialog før udbuddet kan være forskellen på realistiske krav og skrivebordskrav. Men den skal gennemføres struktureret.

Hvad vil du typisk undersøge?

• Hvilke løsningsmodeller findes i markedet (standardprodukt, platform, brancheløsning, modul-kombination)?
• Hvad er typiske implementeringstider og -omkostninger?
• Hvilke integrations- og migreringsløsninger bruges oftest?
• Hvilke sikkerheds- og compliancekrav kan leverandører normalt efterleve?
• Hvordan ser standardkontrakter ud – og hvor ligger typiske konfliktpunkter?

Det kan ske via:

• RFI (Request for Information)
• åbne leverandørmøder eller workshops
• skriftlige høringer af udkast til krav.

Sådan holder du dig inden for reglerne

Grundprincipperne om ligebehandling og gennemsigtighed betyder i praksis:

• Alle relevante leverandører skal have samme mulighed for at bidrage, hvis du bruger markedsdialog som grundlag for udbuddet.
• Ingen leverandør må få særinformation, der ikke kan deles med andre.
• Vigtige indsigter skal dokumenteres og så vidt muligt komme til udtryk i det endelige udbudsmateriale.

En god huskeregel: Forestil dig, at en tabende leverandør beder om aktindsigt i dit forarbejde. Ser det fair, gennemsigtigt og sagligt ud? Hvis ja, er du typisk på sikker grund.

Evalueringsmodel: sådan designer du en model, der holder

Evalueringsmodellen er din “regnemaskine” for, hvordan du vælger vinderen. Den skal være:

• fuldt beskrevet i udbudsmaterialet
• forståelig for både ordregiver og tilbudsgivere
• robust juridisk – den må ikke ændres efter åbning af tilbud.

Del pris og kvalitet – og gør vægtning tydelig

De fleste modeller bygger på en vægtning mellem pris og kvalitet, fx 40/60 eller 30/70. Nogle hovedprincipper:

• Pris og kvalitet skal vurderes uafhængigt. Først tildeles point for pris, så for kvalitet – derefter lægges de sammen efter vægtning.
• Vægtningen skal give mening i forhold til opgaven. Til komplekse løsninger (fx fagsystemer, integrationsplatforme, sikkerhedstjenester) vil kvalitet ofte fylde mere end pris.
• Beskriv, hvordan point gives – ikke bare vægtningen. Tilbudsgiver skal kunne forstå, hvad der giver fx 5 vs. 8 point.

Lineær pointmodel for pris

En udbredt og relativt enkel model er lineær pointmodel for pris:

• Det billigste konditionsmæssige tilbud får maksimumpoint (fx 10 point).
• De øvrige tilbud får point i forhold til, hvor meget dyrere de er, efter en lineær formel.

Det gør det gennemsigtigt for tilbudsgiver, hvordan deres pris påvirker chancen for at vinde. Samtidig undgår du, at meget lave priser får uforholdsmæssig stor effekt, hvis modellen er skævt indrettet.

Kvalitetskriterier: fra subjektiv mavefornemmelse til struktureret vurdering

Kvalitet kan fx vurderes på:

• løsningsforståelse og metode
• brugervenlighed og procesunderstøttelse
• arkitektur og teknisk løsning
• implementeringsplan og risikohåndtering
• organisation, kompetencer og erfaring hos leverandørens team.

For hvert kriterium bør du definere:

• hvad der vurderes (fx “fordele/ulemper ved foreslået arkitektur”)
• hvilke elementer der lægges vægt på (fx skalerbarhed, driftsstabilitet, integrationsmuligheder)
• hvordan point skaleres (fx 0-10 point med beskrivelse af niveauer).

Overvej også, hvordan du kombinerer skriftlige beskrivelser, bilag og evt. præsentationer eller demoer. Og husk, at demos har begrænsninger – især ved komplekse platforme og AI-løsninger, som beskrevet i artiklen om hvorfor man ikke skal stole for meget på demos. Hvis du bruger demoer, skal deres rolle i evalueringen være klart beskrevet.

Evalueringsfejl du bør undgå

De fleste evalueringsproblemer kan føres tilbage til nogle få klassiske fejl.

1. Uklare eller ulogiske vægtninger

Hvis det ikke er tydeligt, hvor meget pris versus kvalitet tæller, eller hvis vægtningen ikke stemmer med opgavens karakter, skaber det usikkerhed – og kan give grundlag for klager.

2. Ændring af modellen undervejs

Det er ikke lovligt at ændre evalueringsmodellen efter åbning af tilbud. Alligevel sker det i praksis, når ordregivere “justerer” skalaer eller tolkninger, fordi modellen viser sig at give uventede resultater.

Løsning: stresstest modellen før offentliggørelse. Brug fiktive tilbud med forskellige styrker/svagheder og se, om modellen faktisk vælger det tilbud, I anser som bedst.

3. Modeller der blander pris og kvalitet forkert

Nogle korrektionsmodeller eller “pris pr. kvalitetspoint” kan i praksis sammenblande pris og kvalitet på en måde, der er svært gennemsigtig. Det kan gøre det umuligt for tilbudsgivere at forstå, hvordan de skal optimere deres tilbud, og svækker gennemsigtigheden.

4. Subjektive vurderinger uden fælles ramme

Hvis evaluatorer ikke har en fælles forståelse af, hvad der udgør fx “meget tilfredsstillende” vs. “tilfredsstillende”, bliver kvalitetsvurderingen vilkårlig. Afhjælp det ved:

• fælles kick-off for evalueringsteamet
• eksempler på svar, der typisk vil ligge højt, middel og lavt
• tydelige rubrikker eller skala-beskrivelser.

Kontrakten: sådan bygger du en aftale, du kan leve med

Et udbud er kun så godt som den kontrakt, der følger efter. Og kontrakten er ikke kun jura – det er din styringsmodel for samarbejdet de næste mange år.

Kontraktens centrale byggesten

• Ydelsesbeskrivelse: hvad leveres hvornår (projektleverancer, drift, support, videreudvikling).
• Sikkerhed og compliance: krav til informationssikkerhed, NIS2, GDPR, logning, audits mv. Her kan du med fordel læne dig op ad principper og leverancer fra guides om cybersikkerhed og data governance som i artiklen data governance uden teatertorden.
• Databehandleraftale: rollefordeling, underdatabehandlere, overførsler til tredjelande, sikkerhedsforanstaltninger osv.
• Implementering: faser, milepæle, acceptkriterier, testtyper og -ansvar, håndtering af forsinkelser.
• Drift og support: SLA’er, tilgængelighed, svartider, prioritering af fejl, planlagt nedetid.
• Ændringshåndtering: hvordan håndteres nye behov, lovændringer, teknologisk udvikling og skalering.
• Pris og betalingsmodel: licens, abonnement, timepriser, faste ydelser, variable elementer, indeksregulering.
• Ansvar og begrænsninger: erstatningsansvar, bodsmodeller, forsikringer.
• Varighed, forlængelse og exit: opsigelsesbestemmelser, dataudlevering, bistand ved leverandørskifte.

Hvis du arbejder meget med IT-kontrakter, kan du finde yderligere perspektiver på typiske faldgruber og tjekpunkter i indholdet om IT-kontraktpraksis.

Kontrakten skal spejle krav og evaluering

Det er en klassisk fejl, at kontrakten lever sit eget liv løsrevet fra krav og evaluering. Det giver problemer, når noget, der blev vurderet højt i evalueringen, slet ikke er reguleret i kontrakten.

Sikr derfor, at:

• vigtige kvalitetskriterier fra evalueringen afspejles som konkrete kontraktkrav
• de KPI’er og SLA’er, der skal styre driften, er forankret i både kravspecifikation og kontrakt
• ændringsmekanismerne understøtter den udviklingshorisont, I reelt har for løsningen.

Pris og økonomi: hvad koster et godt udbud?

Markedet giver kun få åbne prisdata, men vejledende estimater fra research peger på, at specialiserede udbudsadvokater ofte tager omkring 1.800-2.800 kr. i timen, mens IT- og managementkonsulenter typisk ligger omkring 1.400-2.400 kr. i timen. Et komplekst IT-udbud kan kræve alt fra 200 til 800 konsulenttimer – svarende til cirka 300.000-1.500.000 kr. ekskl. moms.

Det er kun estimerede intervaltal og ikke officielle listepriser. Poen­ten er ikke det præcise tal, men proportionen: et dårligt udbud til mange millioner i kontraktværdi bliver sjældent billigere af at spare 100 timer i forberedelsen.

Leverandørstyring: sådan ser god styring ud i praksis

Efter tildeling starter den del, du skal leve med: samarbejdet. Leverandørstyring er den løbende styring af performance, risiko og udvikling.

Governance og mødefora

Etabler en enkel, men klar governance-struktur:

• Operationelle møder: fx ugentlige drifts- eller projektmøder, fokus på incidents, mindre ændringer, planlagte leverancer.
• Taktiske møder: fx månedlige eller kvartalsvise statusmøder med fokus på SLA’er, KPI’er, roadmap, økonomi.
• Strategiske møder: 1-2 gange årligt med fokus på langsigtede behov, kontraktforlængelse, større ændringer eller eventuelt leverandørskifte.

Her hænger det naturligt sammen med virksomhedens overordnede governance. Se fx kategorien om organisering og governance for bredere perspektiv.

SLA’er og KPI’er i drift

SLA’er og KPI’er skal være:

• få og vigtige – hellere 5 gode end 50 ingen kigger på
• tydeligt definerede (målemetode, datakilde, periodelængde)
• koblet til incitamenter (fx bod, bonus, eskalation) hvor det giver mening.

Det kræver, at de er gennemtænkt allerede i udbud og kontrakt – ikke opfundet senere.

Incident management og ændringshåndtering

Gode aftaler om håndtering af fejl og ændringer er afgørende:

• tydelig prioritering af fejl (P1-P3/P4) og responstider
• klare snit mellem fejlrettelse og bestilte ændringer
• fælles ændringsproces (Change Advisory Board, backlog, releaseplan).

Ved større AI- og automationsløsninger kan det også være relevant at automatisere dele af indkøb og styring, som beskrevet i artiklen om at bruge generativ AI i indkøb.

Exit-plan: tænk leverandørskifte fra dag 1

Lock-in er en reel risiko: teknisk, kontraktmæssigt og organisatorisk. En god exit-plan omfatter:

• rettigheder til data og formater for udlevering
• bistand fra leverandøren ved migration til ny løsning
• tidsfrister og prisprincipper for exit-arbejde.

Det virker abstrakt ved kontraktstart, men er typisk det, der afgør, om et leverandørskifte bliver en kontrolleret proces eller et brandudryk.

Typiske faldgruber i IT-udbud – og hvordan du undgår dem

Når man ser på fejl på tværs af mange udbud, går de samme mønstre igen.

1. Urealistisk tidsplan

Tegn på problemet:

• kravspecifikation skrives på få uger uden reel involvering
• ingen tid til markedsdialog eller stresstest af evalueringsmodel
• implementering planlægges som “big bang” tæt på en kritisk deadline.

Modtræk: Læg en plan med realistiske buffere – særligt i forberedelse og implementering.

2. Manglende involvering af slutbrugere

Hvis brugerne ikke er med i behovsafklaring og krav, risikerer du et system, der ser fint ud på papiret, men ikke virker i praksis. Involver nøglebrugere i:

• kortlægning af nuværende processer
• prioritering af krav
• test og accept af løsningen.

3. Uklare eller modstridende krav

Når forskellige forretningsområder har skrevet hvert sit kapitel uden fælles redaktion, ender du med modsatrettede krav. Løsning:

• udpeg en redaktør (ofte product owner eller projektleder), der har mandat til at rydde op
• gennemfør en samlet kravreview med arkitekt, test og jura.

4. Svag evalueringsmodel

Enten for simple modeller (“laveste pris vinder”) til komplekse løsninger eller uigennemsigtige modeller, ingen forstår. Udbuddet bliver reelt afgjort af tilfældigheder i stedet for gennemskuelige kriterier.

5. For tung eller urealistisk kontrakt

Kontrakter, der forsøger at gardere sig mod enhver tænkelig risiko, ender ofte med:

• højere priser (leverandøren prissætter risikoen)
• lavere fleksibilitet (hver ændring kræver store forhandlinger)
• forhandlingsspændinger fra start.

Det handler om balance: tilstrækkelig beskyttelse – uden at gøre samarbejdet ufleksibelt.

6. Mangelfuld leverandørstyring

Udbuddet er gennemført, kontrakten underskrevet – og så overlades det til “driften” uden klar governance. Konsekvensen er typisk:

• SLA’er, der aldrig følges op på
• ændringer, der kryber ind uden struktur
• uklarhed om ansvar ved fejl.

Modtræk: Tænk leverandørstyring som en integreret del af udbuddet – ikke som noget, man finder på bagefter.

Hvornår skal et IT-system i udbud?

Spørgsmålet dukker især op i offentlige organisationer. Svaret afhænger af:

• om du er en offentlig myndighed omfattet af udbudsloven eller tilsvarende regler
• kontraktens karakter og forventede værdi (tærskelværdier mv.)
• om der allerede findes rammeaftaler eller indkøbsaftaler, du er forpligtet til at bruge.

Generelt vil større offentlige IT-anskaffelser skulle i udbud, hvis de overskrider relevante tærskler og ikke kan dækkes af eksisterende aftaler. De præcise tærskelværdier ændrer sig over tid og afhænger af type og indkøber, så her bør man altid tjekke de gældende regler og evt. søge juridisk rådgivning.

Pointen er, at så snart du bevæger dig op i beløb og tidsmæssig horisont, hvor kontrakten får strategisk betydning, bør du under alle omstændigheder tænke og planlægge det som et struktureret udbud – også hvis der ikke formelt er udbudspligt.

Hvornår skal noget i udbud i en kommune?

Kommuner er offentlige myndigheder og som udgangspunkt omfattet af udbudslovens grundlæggende principper: ligebehandling, gennemsigtighed, proportionalitet og ikke-diskrimination.

Om en konkret IT-anskaffelse skal i udbud afhænger af:

• anskaffelsens samlede værdi over kontraktens løbetid
• om der findes relevante SKI- eller andre fællesoffentlige aftaler, som skal bruges
• om indkøbet kan ske som mindre køb under terskelreglerne.

I praksis betyder det, at kommuner typisk laver udbud ved større systemanskaffelser, nyudvikling eller konsolidering af systemporteføljen – også fordi de efterfølgende skal kunne dokumentere, at valget af leverandør og løsning er sagligt begrundet.

Her er de principper, vi har gennemgået om behovsafklaring, krav, evaluering, kontrakt og leverandørstyring direkte anvendelige som metode, uanset præcis udbudsform.

Afgrænsning: hvad med byggeprojekter?

Spørgsmålet “hvornår skal et byggeprojekt i udbud?” dukker ofte op i samme søgninger, men bygge- og anlægsudbud følger andre regelsæt, tærskler og markedslogikker end IT-udbud.

Denne artikel handler udelukkende om IT-udbud – altså udbud af software, infrastruktur, driftstjenester, konsulentydelser mv. Hvis du står med et bygge- eller anlægsprojekt, skal du se på de specifikke regler for den type anskaffelser.

Hvad gør du nu? Tre næste skridt

Hvis du står over for et IT-udbud, kan du med fordel gøre tre ting tidligt:

1. Tegn din proceskæde fra behov til drift, og marker hvor de vigtigste beslutninger ligger.
2. Sammensæt det rigtige hold (projektleder, product owner, udbudsjurist, arkitekt, test) og aftal roller og ansvar.
3. Start på krav og evalueringsmodel i parallel – så det, du efterspørger, faktisk kan vurderes fair og målbart og senere forankres i kontrakten.

Resten er håndværk og disciplin. Men med en klar struktur og de rigtige kompetencer sat i spil tidligt, øger du markant chancen for, at dit IT-udbud bliver noget, du er glad for om fem år – ikke bare den dag, kontrakten bliver underskrevet.