Digital suverænitet

Trin 5 i exit‑planen: et overslag over, hvad det koster i tid og penge at komme ud af hvert system

Trin 5 i exit-planen: et overslag over, hvad det koster i tid og penge at komme ud af hvert system

En afhængighed, der aldrig er regnet på, bliver typisk undervurderet, indtil den skal betales. Trinnet hviler på et overslag pr. system, der tæller alt det arbejde med, som et skifte kræver, og ikke blot forskellen i licenspris.

Vurderingerne fra → Trin 4 viser, hvilke systemer der er mest udsatte. Her får de samme systemer et tal for tid og et tal for penge, så ledelsen kan sammenligne dem.

Licensprisen er sjældent den største post

Aarhus Kommune er et af de få steder, hvor tallene er offentlige. I kommunens oplæg fra 29. oktober 2025 beskriver chefen for kommunens IT-afdeling flytningen af afdelingens løsninger fra en amerikansk til en europæisk cloudleverandør, som blev afsluttet i foråret 2025.

Oplægget opgør besparelsen til to tredjedele af prisen. Samme oplæg viser, hvad der fulgte med. Kommunen vedligeholder nu selv Kubernetes og databaser, overvåger selv forbruget og har erstattet udbyderens nøgleopbevaring med en open source-løsning.

Budgetforliget for 2026 afsatte ifølge oplægget 3 mio. kr. årligt i 2026 til 2029 til kontorpakkeområdet. Indsatsen forudsættes at give besparelser og effektiviseringer på 5 mio. kr. i 2028, stigende til 7 mio. kr. årligt fra 2029. Det samlede forløb gennemgås i → Aarhus Kommune.

Fremgangsmåden

  1. Afgræns systemet · Brug rækken fra Trin 1 med data, koblinger og administratorer som udgangspunkt.
  2. Opdel arbejdet i poster · Gå listen over omkostningsposter igennem, og skriv et skøn for hver.
  3. Skøn tiden i dage · Angiv interne og eksterne arbejdsdage hver for sig, og angiv kalendertiden fra beslutning til lukning.
  4. Sæt kroner på · Brug organisationens egne satser for intern tid og de tilbud eller prislister, der findes for ekstern hjælp og nye licenser.
  5. Angiv usikkerheden · Giv et lavt og et højt skøn, og skriv, hvad forskellen afhænger af.
  6. Lad systemejeren læse med · Systemejeren kender arbejdsgange, som IT ikke ser.
  7. Dater overslaget · Priser, vilkår og systemlandskab ændrer sig.

Omkostningsposterne

  • Dataudtræk · eksport af alle data, også historik, vedhæftninger og metadata, og kontrol af at intet mangler.
  • Konvertering · omsætning til formater, det nye system kan læse, se → Dokumentformater som binding.
  • Integrationer · hver kobling til et andet system skal genopbygges eller erstattes.
  • Login og rettigheder · brugere, grupper og adgange skal flyttes, og afhængige tjenester skal tilknyttes på ny.
  • Nye driftsopgaver · opgaver, som udbyderen før løste, og som nu skal løses internt eller købes.
  • Uddannelse og support · tid til at lære det nye system og ekstra support i overgangen.
  • Parallel drift · perioden, hvor begge systemer kører og betales, se → Trin 9.
  • Kontraktoverlap · opsigelsesvarsel og binding i den gamle aftale.
  • Gebyrer · eventuelle gebyrer for udtræk eller skifte i den gamle aftale.

Login og to-faktor: arbejdet tælles pr. tjeneste

Nogle omkostninger vokser med antallet af tjenester og ikke med antallet af brugere. Microsoft oplyser i sin vejledning om backup i Microsoft Authenticator, at backup og gendannelse kun virker inden for samme type enhed. Ved arbejds- og skolekonti bevarer appen alene navnet på kontoen, så brugeren skal logge ind og tilknytte kontoen forfra.

Vejledningen beskriver ingen samlet eksport af koderne til en anden app. Et skifte af to-faktor-app betyder derfor i praksis, at hver tjeneste skal tilknyttes på ny. Tæl tjenesterne, og gang med den tid, det tager for hver. Regn også med den tid, brugerne skal bruge, og med supportopkald fra dem, der bliver låst ude undervejs.

Samme logik gælder identitetstjenesten. Hvis mange systemer logger ind gennem den, er skiftet af identitetstjeneste et projekt i sig selv og bør have sin egen række i overslaget.

Fagsystemerne holder fast

Kontorpakker og mail har mange alternativer. Fagsystemer har ofte få, og nogle af dem virker kun sammen med ét styresystem, én kontorpakke eller én browser.

Aarhus Kommune angiver i det nævnte oplæg en analyse af bindinger og afhængigheder som første skridt i det næste projekt, før en hybrid løsning etableres. Rækkefølgen kan bruges af alle. Spørg leverandøren af hvert fagsystem, hvilke platforme systemet understøtter, og notér svaret med dato.

Hvor et fagsystem binder hele platformen, skal overslaget for platformen omfatte enten en erstatning af fagsystemet eller en særskilt løsning for de brugere, der er bundet. Offentlige erfaringer med netop den udfordring samles i → Linux-arbejdspladser i offentlige piloter.

Driftsopgaver, der flytter hjem

En besparelse på licensen kan blive spist af nye opgaver. Aarhus-oplægget er åbent om det. Administrerede tjenester som Kubernetes og databaser skal nu vedligeholdes af kommunen selv, og automatisk skalering er erstattet af egen overvågning.

Skriv derfor for hvert system, hvilke opgaver udbyderen i dag løser, og hvem der skal løse dem efter et skifte. Typiske eksempler er opdateringer, sikkerhedskopiering, overvågning, kapacitetsstyring og håndtering af certifikater og nøgler. Kræver opgaverne nye kompetencer, er rekruttering eller ekstern hjælp en del af overslaget. Opgaver uden en navngiven ansvarlig hører med i overslaget som en risiko.

Hvad loven ændrer for skiftegebyrer

EU’s dataforordning, forordning 2023/2854, afvikler gebyrerne for skifte mellem udbydere af databehandlingstjenester. Ifølge artikel 29 må der fra 12. januar 2027 ikke opkræves skiftegebyrer, og indtil da må de højst svare til udbyderens direkte omkostninger.

Artikel 29, stk. 5, pålægger samtidig udbyderne at oplyse kunden om tjenester, hvor et skifte er meget komplekst eller dyrt. Den oplysning er værd at bede om og lægge ved overslaget. Retten til at skifte fjerner dog ikke arbejdet med konvertering, integrationer og uddannelse. Reglerne og deres undtagelser gennemgås i → Data Act: skiftegebyrerne forsvinder, bindingen gør ikke.

Tid er også en omkostning

Overslaget skal sammenholdes med varslet fra Trin 4. Microsoft oplyser i sin dokumentation om sletning i Microsoft 365, at data bevares i 90 dage efter, at et betalt abonnement ophører. Google angiver i sin vejledning til eksport, at en fuld eksport fra Google Workspace kan tage op til 14 dage.

Tager det et halvt år at komme ud, og er vinduet efter ophør 90 dage, er forskellen den reelle risiko. Den forskel skal stå tydeligt i exit-planen, så ledelsen kan se den. Kalendertiden afhænger ofte mere af leverandører, beslutninger og test end af selve flytningen, og den bør derfor skønnes særskilt.

Typiske fejl

  • Kun licensprisen sammenlignes · arbejdet med data, integrationer og uddannelse udelades.
  • Intern tid regnes som gratis · medarbejdernes tid er en omkostning, også når den ikke faktureres.
  • Ét tal uden usikkerhed · et enkelt beløb giver en falsk præcision.
  • Driftsopgaver glemmes · opgaver, udbyderen løste i stilhed, skal løses af nogen bagefter.
  • Overslaget laves uden systemejeren · arbejdsgange i forretningen overses.
  • Exit-vilkårene kendes ikke · format, frist og pris for udlevering af data står ofte uklart i kontrakten. Hvordan de skrives ind, gennemgås i → Trin 8.

Hvad trinnet kan og ikke kan vise

Trinnet viser, hvad det koster i tid og penge at forlade hvert system, og hvor usikkert skønnet er. Det gør det muligt at sammenligne systemer og at se, hvor vinduet efter et ophør er kortere end den tid, et skifte tager.

Trinnet kan ikke forudsige de præcise omkostninger ved et skifte, der endnu ikke er planlagt i detaljer. Det kan heller ikke vurdere alternativerne. Det sker i → Trin 7, og overslaget skal opdateres, når et konkret alternativ er valgt.

Tjekliste

  • ☐ Alle omkostningsposter er gennemgået for hvert kritisk system.
  • ☐ Intern og ekstern tid er skønnet hver for sig.
  • ☐ Kalendertiden fra beslutning til lukning er angivet.
  • ☐ Antallet af tjenester knyttet til login og to-faktor er talt.
  • ☐ Fagsystemernes platformskrav er afklaret med leverandørerne.
  • ☐ Driftsopgaver, der flytter hjem, har en navngiven ansvarlig.
  • ☐ Overslaget har et lavt og et højt skøn med begrundelse.
  • ☐ Overslaget er sammenholdt med varslet fra Trin 4.

Næste trin

Med tid og penge opgjort prioriteres de systemer, hvor et stop eller et skifte betyder mest, i → Trin 6: Prioritér de systemer, der betyder mest.

En uvildig exit-vurdering pr. system kan give et overslag, der ikke er farvet af en leverandørs interesse. Skal overslaget bruges til at planlægge vejen ud, omfatter Nielco IT’s rådgivning om exit-planen en plan pr. kritisk system med omkostning og rækkefølge.

Kilder

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

John Nielsen, Nielco IT

Skal afhængigheden kortlægges?

Skriv kort, hvilke systemer eller leverandører det drejer sig om, og hvad anledningen er. Så vender jeg tilbage. Rådgivningen er uvildig og uafhængig, og Nielco IT har ikke indgået forhandleraftaler med leverandører.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.