Hvad er total cost of ownership for et digitalt produkt?
Total cost of ownership, de samlede ejeromkostninger for et digitalt produkt, omfatter alt fra udvikling til udfasning. Selve udviklingen står typisk for 40–60 procent af omkostningen over tre år. Resten er drift, vedligeholdelse, videreudvikling, licenser og support. Et produkt der er billigst at bygge, kan derfor blive dyrest at eje hvis kvaliteten skaber ekstra omkostninger efter lanceringen.
Tilbuddet viser hvad produktet koster at bygge. Hvad det koster at eje, er et andet og større tal, som få leverandører viser af sig selv. Regner du på tre år i stedet for på leveringsdagen, træffer du bedre beslutninger i næsten alle de valg du står over for.
Udviklingen er kun 40–60 procent af omkostningen
Over en periode på tre år står selve udviklingen typisk for 40–60 procent af de samlede ejeromkostninger. Resten fordeler sig på drift, vedligeholdelse, videreudvikling, licenser, support og jeres egen interne tid. Det betyder at det tal de fleste forhandler hårdest om, byggeprisen, kun er omkring halvdelen af sandheden.
Beregningsskabelon: posterne der skal med
| Omkostningspost | Typisk niveau |
|---|---|
| Udvikling (engangsomkostning) | 40–60 % af omkostningen over tre år |
| Drift og hosting | Varierer med belastning og krav til oppetid; fra nogle tusinde DKK om måneden |
| Vedligeholdelse (fejlrettelser, opdateringer, support) | 15–25 % af byggeomkostningen om året |
| Videreudvikling (nye funktioner) | 20–40 % af byggeomkostningen om året, afhængigt af ambitionen |
| Licenser og tredjepartstjenester | Betalinger, kortvisning, e-mail, analyse; vokser ofte med brugen |
| Support og intern tid | Ofte glemt: jeres egen administration og tid til bestilling og test |
Gennemgå rækkerne med hver leverandør I vurderer, og bed om estimater pr. post. Den der ikke kan ræsonnere om årene efter lanceringen, har ikke tænkt hele vejen.
Regneeksempel: billigst at bygge, dyrest at eje
To tilbud på det samme produkt: A på 740.000 DKK og B på 1,1 mio. DKK. B’s højere pris køber testautomatisering, dokumentation og en mere gennemarbejdet arkitektur. Tallene nedenfor er illustrative, men mekanismen er reel.
Produkt A kræver hyppige fejlrettelser. Vedligeholdelsen ligger i den øvre ende, 25 procent af byggeprisen om året. Videreudviklingen går trægt i den uoverskuelige kodebase: 320.000 DKK om året for et moderat udviklingstempo. Efter tre år: 740.000 + 555.000 + 960.000 = ca. 2,26 mio. DKK.
Produkt B vedligeholdes for 15 procent, ca. 165.000 DKK om året, og det samme udviklingstempo koster 210.000 DKK om året. Efter tre år: 1.100.000 + 495.000 + 630.000 = ca. 2,23 mio. DKK.
Det “dyrere” produkt er allerede efter tre år samlet set billigere, og afstanden vokser for hvert år produktet lever, fordi forskellen ligger i de tilbagevendende poster. Læg drift og licenser til, som er omtrent lige store i begge tilfælde, og konklusionen holder stadig.
Derfor bliver billig udvikling dyr
- Genveje i arkitekturen gør hver ny funktion dyrere at tilføje.
- Manglende tests gør hver ændring risikabel, og forsigtighed koster timer.
- Tynd dokumentation binder jer til den leverandør der byggede produktet, med den prissætning det medfører.
- Sparsom test før lanceringen flytter fejlene til produktion, hvor de er dyrest at finde og rette.
Intet af dette kan ses i tilbuddet. Alt kan ses i TCO.
Glem ikke jeres egen tid
Den mest undervurderede post i beregningen er intern tid: Nogen hos jer skal prioritere backloggen, svare på leverandørens spørgsmål, teste leverancer og tage sig af brugernes feedback. For et aktivt produkt drejer det sig ofte om en betydelig del af en fuldtidsstilling. Den tid kommer aldrig på en faktura, men den er en omkostning, og uden den leverer selv den bedste leverandør de forkerte ting.
Regn til sidst med en post der næsten aldrig bliver budgetteret: udfasning eller udskiftning. Data skal eksporteres, integrationer kobles fra og brugere flyttes den dag produktet bliver skiftet ud. Det behøver ikke at koste meget hvis eksportmuligheder og ejerskab var med i kravene fra starten.
Sådan bruger du TCO når du køber udvikling
- Bed hver leverandør om en beregning over tre år, ikke kun en byggepris.
- Sammenlign tilbud på den samlede omkostning inklusive vedligeholdelse og drift.
- Budgetter med år to allerede når I bestiller. Produktet er ikke færdigt fordi det er lanceret.
- Spørg hvad der bliver gjort i udviklingen for at holde ejeromkostningerne nede: tests, standardteknologi, dokumentation.
Vi hos Weapp viser gerne hele billedet over tre år i vores tilbud. Det er den beregning vi selv ville kræve som kunde. Vil du se hvordan den ser ud for jeres produkt? Kontakt os, eller læs mere om vores ydelser.
Ofte stillede spørgsmål
Hvor mange år skal en TCO-beregning dække?
Tre år er en almindelig og overskuelig horisont for digitale produkter. Den er lang nok til at driftsomkostningerne bliver synlige, og kort nok til at de kan estimeres seriøst. For kernesystemer med lang levetid regner mange i stedet på fem år.
Hvordan sænker jeg ejeromkostningerne uden at sænke kvaliteten?
Vælg standardteknologi som mange udviklere behersker, brug cloudtjenester i stedet for egen drift, kræv automatiserede tests og løbende dokumentation, og undgå leverandørlåsning. Alt dette sænker omkostningen i årene efter lanceringen, og det er dér hovedparten af pengene ligger.
Er høje vedligeholdelsesomkostninger altid et dårligt tegn?
Nej. Et produkt med mange brugere og et højt forandringstempo koster naturligvis mere at holde i topform, og det kan være særdeles godt givet ud. Advarselstegnet er høje vedligeholdelsesomkostninger uden en tilsvarende værdi, altså når pengene går til at holde noget oven vande frem for at gøre det bedre.
Hvad koster driften af en app eller webtjeneste om måneden?
Det varierer med belastning og krav til oppetid: Enklere produkter klarer sig ofte med nogle tusinde DKK om måneden i cloudomkostninger mens forretningskritiske tjenester med redundans, høj trafik og skarpe krav koster betydeligt mere. Bed leverandøren om et estimat pr. miljø allerede i tilbuddet.
Hvordan påvirkes TCO hvis produktet bygges med no-code?
Startomkostningen falder, men platformsgebyrerne, som ofte skalerer pr. bruger, erstatter dele af udviklings- og driftsomkostningen. Læg desuden en exitomkostning ind i beregningen: Logikken bor i platformen og skal bygges om den dag I vokser ud af den.