Vi bruger cookies

Vi bruger nødvendige cookies til at få hjemmesiden til at fungere. Med dit samtykke bruger vi også cookies til statistik, præferencer og eventuel markedsføring. Du kan acceptere alle, afvise ikke-nødvendige cookies eller tilpasse dit valg.

Cookiepolitik Privatlivspolitik

KHALEGI DIGITAL

DIGITALISERING I PRAKSIS

FAQ

Velkommen til KHALEGI DIGITAL FAQ

FAQ’en samler mine erfaringer, observationer og spørgsmål inden for IT, teknologi, indkøb, kontrakter og rådgivning.

Brug søgefeltet til at søge efter konkrete spørgsmål eller nøgleord. Du kan også indsnævre resultaterne ved at filtrere på hovedområde, emne og målgruppe, så det bliver lettere at finde de svar, der er relevante for din situation.

FAQ’en indeholder aktuelt 200 spørgsmål og svar fordelt på ni hovedområder:

  • Cloud: Cloudstrategi og udbud, pris og økonomi, governance og compliance, service level agreements (SLA), leverandørvalg samt forandring og exit-strategi.
  • IT-udbud: Strategi, leverandørskifte, evaluering, kontrakt, governance, compliance og konkurrence i forbindelse med IT-udbud.
  • IT-sikkerhed: NIS2 og øvrige krav, lovgivning og certificering, data og lokation, internationale overførsler, myndigheder og roller, kravspecifikationer, kontraktforhold, dokumentation, standarder, governance og modenhed.
  • IT-kontrakter: Procedure og evaluering, krav og specifikationer, kontraktændringer, økonomi og forhandling, kontrakthåndtering samt compliance og samfundsansvar.
  • IT-strategi: Strategiske valg og prioritering, gennemførelse af strategien, portefølje- og produktansvar samt cloud, data og sikkerhed.
  • Ledelsesrådgivning: Ledelsesbeslutninger og mandat, gevinstrealisering og samarbejde, forankring og rådgivning samt beredskab og ledelsesstyring.
  • Analyser: Behov og datagrundlag, analysemetoder og beslutningsstøtte, alternativer og økonomi samt analyseleverancer og opfølgning.
  • Bid management: Tilbudsbeslutninger og strategi, tilbudsteam og dokumentation, tilbudsleverance og kvalitet samt læring og tilbudsstyring.
  • Market entry: Markedsvalg og kunder, markedstest og pipeline, adgang og lokal levering samt markedsstyring og skalering.

FAQ’en er lavet som et praktisk opslagsværk og bliver løbende udbygget og opdateret med nye spørgsmål, svar og emner.

Hvis du har forslag til nye spørgsmål eller emner, er du velkommen til at kontakte mig.

Nulstil

80 svar fundet · side 3 af 7

Hvordan begrænses leverandørafhængighed i et IT-udbud?

Leverandørafhængighed reduceres ved at sikre anvendelige alternativer og kendte skifteomkostninger. Standardformater, dokumenterede integrationer og adgang til nødvendige data kan hjælpe, men ingen enkelt klausul fjerner alle afhængigheder.

Kortlæg de dele, hvor leverandøren har særlig kontrol: dataformat, licenser, nøglekompetencer, drift og integrationer. Prioritér krav og tests efter den reelle konsekvens ved et skifte. Indregn exit og overtagelse i økonomien, og afprøv centrale eksportmuligheder. Accepterede bindinger bør være bevidste beslutninger med en ejer og en plan, hvis samarbejdet eller behovet ændrer sig.

Kilder og faglig baggrund: Digitaliseringsstyrelsen: K04 – IT-drift

Hvordan beregnes værdien af et offentligt IT-indkøb?

Værdien skal beregnes efter udbudsreglerne på et sagligt grundlag og omfatte de relevante betalinger, optioner og forlængelser. Det er ikke tilstrækkeligt at se på første års licenspris eller opdele et sammenhængende indkøb for at undgå reglerne.

Dokumentér periode, mængder, usikkerheder og hvilke dele der er medregnet. Anvend den aktuelle tærskelværdi for kontrakttype og ordregiver; beløbene reguleres, så et gammelt kontraktbilag er ikke en sikker kilde. En værdi under EU-tærsklen betyder heller ikke automatisk frit indkøb, da andre regler kan gælde.

Kilder og faglig baggrund: Udbudsloven, LBK nr. 116 af 3. februar 2025 · KFST: Lovoversigt

Hvordan beskrives optioner i en offentlig IT-kontrakt?

En option bør gøre det muligt at forstå, hvad kunden kan tilkøbe, på hvilke vilkår og inden for hvilken ramme. En bred formulering om ”yderligere ydelser efter behov” giver ikke nødvendigvis et tilstrækkeligt grundlag for fremtidige ændringer.

Beskriv ydelse, omfang, pris eller prisberegning, udnyttelsesfrist og eventuelle afhængigheder. Medtag relevante optioner i beregningen af kontraktens anslåede værdi. Afstem optionerne med den tekniske plan og finansieringen. Vurder ved udnyttelse, om det faktisk bestilte ligger inden for den offentliggjorte ramme; navnet ”option” gør ikke en ny leverance lovligt omfattet.

Kilder og faglig baggrund: Udbudsloven, LBK nr. 116 af 3. februar 2025

Hvordan bliver cloudbudgettet mere forudsigeligt?

Et forudsigeligt cloudbudget kræver både en teknisk forbrugsprognose og en ejer af de økonomiske afvigelser. Budgettet bør følge de tjenester og teams, som skaber forbruget, så ekstra omkostninger kan forklares og påvirkes.

Start med en månedlig baseline, fordel udgifter på produkter eller afdelinger, og aftal budgetalarmer med konkrete modtagere. Sammenhold forbruget med en relevant aktivitet, eksempelvis antal transaktioner. Undersøg store udsving, før der købes lange kapacitetsbindinger. Budgetalarmer stopper normalt ikke forbruget i sig selv; automatisk begrænsning kræver en særskilt beslutning om driftsrisiko.

Kilder og faglig baggrund: FinOps Foundation: Forecasting · FinOps Foundation: Allocation

Hvordan bør pristrapper og cloudrabatter vurderes?

En pristrappe er kun attraktiv, hvis den passer til det forventede forbrug og ikke skaber uhensigtsmæssige bindinger. Skeln mellem rabat på hele volumen og rabat alene på forbruget over en grænse. De to modeller kan give meget forskellig slutpris.

Beregn prisen lige under og over hvert trin samt ved faldende forbrug. Undersøg, om rabatten kræver forudbetaling, minimumsforbrug eller bestemte produkter, og om uudnyttet kapacitet bortfalder. Lad økonomi og teknik godkende samme mængdeforudsætninger. Beslut derefter, hvor meget fleksibilitet organisationen vil bytte for en lavere pris.

Kilder og faglig baggrund: FinOps Foundation: Forecasting

Hvordan bør uenigheder om en IT-kontrakt eskaleres?

Eskalation bør bringe uenigheden til det niveau, som kan træffe den nødvendige beslutning. Det kræver en klar beskrivelse af problem, dokumentation, konsekvens og ønsket løsning, så næste møde ikke blot gentager den forrige drøftelse.

Aftal kontaktpersoner, frister og trin fra operationel dialog til ledelse og eventuel tvistløsning. Registrér, hvad parterne er enige og uenige om, og hvordan driften håndteres imens. Følg kontraktens regler og relevante frister. Mægling, voldgift eller domstole skal vurderes efter aftalen og sagen; en eskalationsmodel bør ikke utilsigtet afskære nødvendige rettidige skridt.

Kilder og faglig baggrund: Digitaliseringsstyrelsen: K04 – IT-drift

Hvordan bruges bod og incitamenter i en cloud-SLA?

Bod og incitamenter bør understøtte den adfærd, kunden har brug for, eksempelvis hurtig genetablering og varig fejlretning. De erstatter ikke en plan for kritiske hændelser eller en vurdering af leverandørens faktiske kapacitet.

Sammenhold beløb, lofter, gentagelser og undtagelser med konsekvensen af fejl. Afklar, hvordan bod påvirker andre misligholdelsesbeføjelser, og om servicekreditter kræver en aktiv anmodning. Brug scenarier til at teste, om modellen belønner kosmetiske forbedringer eller reel servicekvalitet. Den konkrete klausul bør tilpasses kontrakten og vurderes juridisk før anvendelse.

Kilder og faglig baggrund: Digitaliseringsstyrelsen: K04 – IT-drift

Hvordan bruges referencer og erfaring korrekt i et IT-udbud?

Referencer kan bruges til at undersøge relevante leverancer, men formål og anvendelse skal være klare. Virksomhedens egnethed og kvaliteten af det konkrete tilbud er forskellige spørgsmål og skal behandles efter de regler, der gælder for hver vurdering.

Definér, hvilken erfaring der er relevant, og hvilke oplysninger der skal indsendes. Undgå krav, som uden saglig grund kun etablerede eller lokale virksomheder kan opfylde. Hvis nøglepersoners erfaring indgår i tildelingen, skal koblingen til kontraktens udførelse være relevant. Referencetjek bør følge en ensartet spørgeramme og dokumenteres, så uformelle præferencer ikke styrer resultatet.

Kilder og faglig baggrund: Udbudsloven, LBK nr. 116 af 3. februar 2025

Hvordan evalueres sikkerhedsmodenhed uden at belønne flotte formuleringer?

Bed om dokumentation for udført arbejde og sammenhængende processer. En beskrivelse af en kontrol er mindre overbevisende, hvis der ikke kan vises ansvar, anvendelse, resultater og opfølgning på afvigelser.

Brug konkrete scenarier og efterspørg eksempelvis en anonymiseret efteranalyse, en gendannelsestest eller en proces for adgangslukning. Vurder bevisernes relevans for den tilbudte leverance. I offentlige udbud skal kriterier og fremgangsmåde være offentliggjort og anvendes ensartet. Skeln mellem minimumsniveau og kvalitet ud over dette, så certificering, modenhed og løsningskvalitet ikke blandes sammen i et uklart helhedsindtryk.

Kilder og faglig baggrund: Udbudsloven, LBK nr. 116 af 3. februar 2025 · NIST: Cybersecurity Framework 2.0

Hvordan evalueres tekniske IT-tilbud så objektivt som muligt?

Teknisk kvalitet kræver ofte fagligt skøn, men skønnet skal være bundet til tydelige kriterier og dokumentation. Målet er en begrundet, konsistent vurdering, ikke at gøre enhver kvalitetsforskel til en mekanisk beregning.

Beskriv, hvad en god besvarelse skal belyse, og hvordan demonstrationer eller test indgår. Brug samme scenarier, datagrundlag og vilkår for tilbudsgiverne. Notér konkrete styrker og svagheder med henvisning til materialet. Hold kontrol af minimumskrav adskilt fra kvalitetsevaluering, og undgå at belønne funktioner, som ikke har forbindelse til de offentliggjorte kriterier.

Kilder og faglig baggrund: Udbudsloven, LBK nr. 116 af 3. februar 2025 · KFST: Evalueringsmodeller

Hvordan fastlægges krav til patch management?

Patchkrav bør følge sårbarhedens risiko, systemets eksponering og muligheden for at rette uden uacceptable driftskonsekvenser. Samme faste frist for alle opdateringer kan være både for langsom ved kritiske fejl og unødigt belastende ved små ændringer.

Definér ansvar for overvågning, klassifikation, test, udrulning og dokumentation. Beskriv akutte undtagelser, midlertidige beskyttelsesforanstaltninger og godkendelse af udsættelser. Medtag software, operativsystemer, biblioteker og relevante underleverancer. Følg op på faktisk dækningsgrad og forældede komponenter. Et system uden leverandørsupport kræver en særskilt beslutning om udskiftning eller risikobehandling.

Kilder og faglig baggrund: NIST: Cybersecurity Framework 2.0

Hvordan fastsættes en proportional bod i en IT-kontrakt?

En bod bør stå i rimeligt forhold til den forpligtelse og adfærd, den skal understøtte. For lave beløb kan være uden virkning, mens meget høje eller uklare sanktioner kan give risikopriser og vanskeligere samarbejde.

Test modellen på en mindre forsinkelse, en langvarig fejl og gentagne hændelser. Afklar beregning, maksimum, overlap og forholdet til øvrige beføjelser. Overvej også dokumentationskrav og hvem der foretager opgørelsen. Beløbene kan ikke vælges meningsfuldt uden kendskab til leverancen og konsekvensen af svigt; den endelige klausul kræver kontraktmæssig og juridisk sammenhæng.

Kilder og faglig baggrund: Digitaliseringsstyrelsen: K04 – IT-drift