En cloud-strategi afgør system for system, hvor virksomhedens IT skal ligge, og hvad der skal begrunde valget. Svaret bliver sjældent, at alt skal flyttes. Standardopgaver som mail og samarbejde hører oftest til i købte cloudtjenester, tunge forretningssystemer afgøres ved næste store skifte, og systemer tæt på produktion eller særlige krav kan have grund til at blive. Multi-cloud, altså brug af flere udbydere, er for de fleste noget, der sker af sig selv, og sjældent noget, man skal stile mod. Direktionen skal godkende principperne, risikoen og den samlede økonomi. Selve planen ejer CIO’en eller IT-chefen.
Hvad strategien skal afgøre
Strategien er en kort række beslutninger:
- Hvad begrunder en flytning hos jer: forretningens behov for fleksibilitet, afskaffelse af eget datacenter, et system, der er ved at være udtjent, eller noget andet?
- Hvilke typer systemer flyttes, hvilke bliver, og hvilke afgøres ved næste skifte?
- Hvem må købe cloudtjenester, og hvilke krav skal de opfylde?
- Hvad er fælles for koncernen, og hvad må selskaberne selv vælge?
- Hvilke kompetencer skal I selv have, når driften ændrer karakter?
Virksomheder, der blot skal tage stilling til en enkelt server, finder en kortere vej i skal serveren blive på ekstern-it-chef.dk. Her er spørgsmålet, hvordan et samlet landskab skal se ud, når der er egne IT-folk og mange systemer. Det samme gælder grænsen mod virksomheder, hvor cloud er en del af selve produktet, som har deres eget valg af hosting.
Pr. systemtype
Brug jeres oversigt over applikationer som grundlag, og sortér systemerne efter type. Følgende opdeling er en god begyndelse.
Standardopgaver. Mail, samarbejde, HR og lignende købes normalt som færdige tjenester. Valget er sjældent svært, og det, der kræver ledelse, er tilpasningen af arbejdsgange og aftalerne.
Store forretningssystemer. ERP og lignende flyttes bedst som led i et planlagt skifte. En flytning alene, uden ændring af system eller processer, giver sjældent det, ledelsen håber på. Beslutningen hører derfor hjemme i ERP-programmet.
Egne systemer og ældre løsninger. Her skal I først afgøre, om systemet overhovedet skal leve videre, se legacy-systemer. Det er sjældent en god idé at flytte noget, som alligevel skal udfases.
Systemer tæt på produktion. Styringer, fabriksnære systemer og noget, der skal virke, selv om forbindelsen er nede, bliver ofte lokalt. Grænsen mellem IT og OT, altså driftsteknologien på gulvet, har sin egen ledelsesside i IT og OT i samme organisation.
Data og analyse. Rapportering og dataplatforme er ofte blandt de første, der får gavn af cloud, fordi kapaciteten kan følge behovet. Valget skal følge datastrategien.
Systemer med særlige krav. Kundekrav, regler eller følsomme data kan betyde, at placeringen skal vurderes for sig. Lad sikkerhedsansvarlig og jeres DPO se på sagen, før beslutningen træffes.
For hver kategori skrives, hvad der er standardvalget, og hvem der må gøre en undtagelse.
Hybrid cloud, cloud first og multi-cloud
Tre ord går igen i oplæggene. Hybrid cloud betyder, at noget ligger i jeres eget miljø og noget hos en cloududbyder, og at de to dele arbejder sammen. Cloud first er et princip om, at nye systemer som udgangspunkt skal i cloud, medmindre der er en begrundelse for andet. Multi-cloud betyder flere cloududbydere på samme tid.
Multi-cloud bruges om to forskellige ting, og det skaber forvirring.
Den første er det, de fleste virksomheder allerede har. Mail ligger hos én udbyder, ERP hos en anden, og en tredje leverer CRM. Det er normalt og som regel rimeligt, så længe nogen har overblikket. Det kræver styring af aftaler, adgange og integrationer, men sjældent en særskilt strategi.
Den anden er bevidst drift af samme systemer hos to udbydere for at kunne skifte eller for at sprede risiko. Det lyder trygt, men prisen er høj. I skal have kompetencer til begge platforme, I kan ikke bruge det bedste hos nogen af dem, og beredskabet skal øves. Behovet står sjældent mål med omkostningen, så overvej det kun, hvor et bestemt krav begrunder det. For den, der frygter afhængighed af én udbyder, er det ofte bedre at have en realistisk plan for at komme væk end at drive to platforme samtidig.
Økonomi og kompetencer
Cloud flytter penge fra anlæg til løbende drift, og det betyder noget for budgettet, for hvordan omkostninger behandles i regnskabet, og for skat. Det sidste er spørgsmål til revisor. Sammenlign på totalomkostninger over en årrække, inklusive egne folk og den pris, overgangen har. Nogle systemer bliver dyrere i cloud, og det kan stadig være rigtigt, hvis fleksibiliteten er noget værd.
Kompetencerne ændrer sig. Serverdrift fylder mindre, mens styring af leverandører, sikkerhedsopsætning og omkostninger fylder mere. Her er FinOps et nyttigt begreb, og det hører med i overvejelsen om, hvad I selv skal kunne. Fortæl de berørte medarbejdere tidligt, hvad det betyder. Ændrer flytningen arbejdet væsentligt, så spørg advokaten, om reglerne om information og høring af medarbejdere gælder hos jer.
Afhængighed og vejen ud
Enhver cloudbeslutning er også en beslutning om afhængighed. Spørgsmålet om, hvordan I kommer væk igen, og hvad jurisdiktion betyder, er større end denne artikel. EU’s dataforordning har desuden regler om skift mellem cloududbydere, og de er gennemgået på digital-suveraenitet.dk. Tag vejen ud med i de kritiske aftaler, før de underskrives.
Hvad I gør nu
Sortér jeres systemer i kategorierne ovenfor på et møde med IT-ledergruppen, og marker dem, der står foran en fornyelse de næste år. Skriv begrundelsen for flytning på en halv side, og læg den for direktionen. Den største fejl er at begynde med en flytning, før nogen kan sige, hvad den skal give. Står I med et datacenter, der skal lukkes, er emnet vejen ud af eget datacenter.
Det skal I lade være med
- At flytte alt, fordi det lyder moderne · hvert system skal have sin egen begrundelse.
- At vælge flere platforme for en sikkerheds skyld · regningen for to platforme er sjældent mindre end risikoen.
- At regne med besparelser uden en opgørelse · sammenlign totalomkostninger over flere år.
- At lade selskaberne købe hver for sig · aftaler og adgange bliver dyre at samle bagefter.
Det skal I kræve af dem, der leder IT
- ☐ Et standardvalg for hver type system med en begrundelse.
- ☐ En regel for, hvem der må gøre undtagelser.
- ☐ Totalomkostninger over flere år med overgangen regnet med.
- ☐ En plan for kompetencer og medarbejdere.
- ☐ En beskrivelse af vejen ud for de mest kritiske tjenester.
Kilder
- Direktiv 2002/14/EF: art. 4 om information og høring.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Sourcingstrategi · FinOps
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CIO hos Nielco IT
