Økonomichefen spørger, hvorfor regningen fra cloududbyderen er steget igen, og udviklerne svarer, at produktet jo vokser. Begge har en pointe, og ingen af dem kan sige, hvad stigningen faktisk skyldes. Regningen kan sjældent styres fra økonomiafdelingen alene, for den er et resultat af tekniske valg, der træffes hver dag: hvem der opretter ressourcer, hvordan data gemmes, og hvor tung koden er. Vejen til en regning, I kan forklare, går gennem tre trin: overblik over forbruget, en ejer af det og arkitektur, der hænger sammen med forretningen.
Spørgsmålet, der afgør det hele
Det nyttige tal er sjældent regningens størrelse. Det nyttige tal er, hvordan den udvikler sig i forhold til det, I sælger. Er forbruget pr. kunde stabilt eller faldende, er stigningen måske helt sund. Vokser det pr. kunde, er noget galt, eller også betaler nogle kunder for lidt i forhold til, hvad de bruger.
Mange softwarehuse kan ikke besvare det, fordi regningen kommer som én lang liste af tekniske poster. Det første skridt er at få den delt op, så den kan læses af en ledelse.
Trin 1: Få overblikket
FinOps er fagordet for samarbejdet mellem økonomi og teknik om cloudforbrug. For et lille team er det et par enkle vaner.
Mærkning. Cloudplatforme lader jer sætte mærkater (tags) på ressourcer, fx miljø, team, tjeneste og gerne kunde. Uden mærkater kan ingen se, hvad der er produktion, og hvad der er en glemt test. Gør det til en regel, at nye ressourcer skal mærkes, og at det sker automatisk gennem de skabeloner, som ressourcerne oprettes med.
Opdeling af miljøer. Produktion, test og udvikling bør ligge på hver sin konto eller i hver sit abonnement. Så kan I se forskellen på en stigning i driften og en udvikler, der har glemt at slukke.
Forbrug pr. kunde og funktion. En delt database kan ikke deles op med mærkater, så her må I bruge en tilnærmelse, fx datamængde eller antal kald pr. kunde. Præcisionen er underordnet. I skal kunne se, om enkelte kunder eller funktioner fylder langt mere end resten.
En fast månedlig gennemgang. En halv times møde med den, der ejer arkitekturen, og den, der ejer økonomien. Se på de største poster, hvad der har ændret sig, og hvorfor.
Trin 2: Giv forbruget en ejer
I de fleste teams må alle udviklere oprette ressourcer, og ingen ser regningen. Det er rimeligt i starten, for hastighed er vigtig. Senere giver det spild, fordi den, der træffer valget, ikke mærker følgerne.
Tre aftaler løser det meste:
- Hvert team eller område kan se sit eget forbrug.
- Én person ejer helheden og kan stille spørgsmål. I et lille team er det ofte den, der har det tekniske ansvar.
- Automatiske varsler går til den ansvarlige, når forbruget stiger usædvanligt. Så opdager I en fejl den samme dag frem for ved næste regning.
Økonomiafdelingens rolle er at spørge og sammenholde med forretningen, mens beslutningen om, hvad der kan skæres væk, kræver teknisk forstand. Lad ikke en besparelse gå uden om dem, der ved, hvad ressourcen gør.
Trin 3: Se efter de typiske årsager
Når overblikket er der, plejer de samme poster at dukke op.
Glemte ressourcer. Testmiljøer, der kører hele natten, gamle diske, kopier af databaser og maskiner, som ingen kan huske formålet med.
For store maskiner. Ressourcer valgt rummeligt en gang for at være på den sikre side og aldrig set efter siden. Sammenlign med det reelle forbrug, og sæt ned, hvor der er luft.
Logning og overvågning. Logdata kan vokse lydløst og blive en af de største poster. Aftal, hvad der gemmes, og hvor længe.
Datatrafik. Trafik ud af platformen eller mellem regioner koster og overses ofte. Et design med mange kald frem og tilbage kan være dyrt, uden at nogen har valgt det.
Backup og opbevaring. Ingen sletter gamle kopier, hvis ingen har aftalt det. Grænsen skal dog sættes bevidst, se kan I genskabe produktet.
AI-kald. Betaling pr. forespørgsel til en sprogmodel kan vokse hurtigere end alt andet, se demoen virker.
Når arkitekturen er årsagen
Nogle stigninger kan ikke trimmes væk. Tunge forespørgsler, et mønster, hvor hver kunde har sin egen kopi af alt, eller tjenester, der kører konstant for noget, der sjældent bruges, er arkitektur. Det valg står beskrevet under multi-tenant og egne installationer, og det hænger også sammen med cloud og hosting til et SaaS-produkt.
Her er det en prioritering. En ombygning, der sænker driftsomkostningen, konkurrerer med nye funktioner i køreplanen. Læg den frem for ledelsen som en beslutning: hvad det kræver, hvad det ændrer, og hvad der må vente. En lang aftale med udbyderen om fast forbrug kan give bedre vilkår, men den binder jer, og den bør vente, til I kender jeres mønster.
Det, I skal fortælle ledelsen
Ledelsen har brug for tre svar hver måned eller kvartal: Hvordan udvikler forbruget sig i forhold til kunderne? Hvad er de tre største poster? Hvad gør vi ved dem? Hvad der er relevant for prissætningen af produktet, må I selv afgøre, men tallet for forbrug pr. kunde er et godt grundlag for den samtale.
Det skal I lade være med
· At overlade regningen til bogholderiet uden en teknisk ejer.
· At skære ressourcer ned for at spare uden at se på, hvad det gør ved kunderne.
· At binde jer til fast forbrug, før mønstret er kendt.
· At gemme alle logs for evigt, fordi ingen har taget stilling.
Det skal I kræve af den eksterne
- ☐ Et overblik over forbrug fordelt på miljø, funktion og kundetype.
- ☐ Faste regler for mærkning af ressourcer.
- ☐ En navngiven ejer og varsler ved usædvanlig stigning.
- ☐ En prioriteret liste over de største poster og hvad de skyldes.
- ☐ En vurdering af, hvad der kan trimmes, og hvad der er arkitektur.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Når kunderne bliver flere · Skat og tilskud til softwareudvikling
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
