Synliggøre teknisk gæld: en letvægts scoringsmodel til porteføljebeslutninger

I mange it-organisationer er teknisk gæld længe blevet en permanent tilstand: applikationer kører, processer fungerer, og alligevel bliver hver change mere trægt, hver release mere risikabel, og hver fejl dyrere. Problemet er sjældent, at ingen ser risiciene – men at de ikke er sammenlignelige. Hvis fem systemer samtidig er “kritiske”, kan ingen i sidste ende prioriteres. Netop her hjælper et scoringmodel for teknisk gæld: et letvægts, gentageligt vurderingsraster, som afbilder tekniske risici, driftsindsats og moderniseringstryk, så porteføljeafgørelser bliver robuste.

Denne artikel beskriver et scoringmodel, der klarer sig uden et mammut-assessment, men som i dagligdagen fungerer for IT-ledelse, drift, administratorer, projektansvarlige og fagområder. Fokus er ikke interne kodedetaljer, men konsekvenser for Drift, Sikkerhed, Data, Interfaces, Leveringsevne og Vedligeholdelse. Målet er et fælles sprog, der afdramatiserer budget- og prioriteringsdiskussioner og gør modernisering planbar.

Scoringmodel for teknisk gæld i praksis

Teknisk gæld er en paraplybetegnelse for beslutninger og historiske belastninger, som kortsigtet har sparet tid, men som på lang sigt medfører renteomkostninger. Disse “renter” viser sig i virksomhedens hverdag som længere gennemløbstider, mere koordinering, højere fejlrate, sikkerhedshuller, specialviden hos få personer eller som afhængigheder af komponenter, der ikke længere understøttes. Problemet: Mange af disse effekter fremtræder ikke som en klar omkostningspost.

Typiske grunde til, at teknisk gæld drukner i porteføljerunder:

• Fejlende sammenlignelighed: En stabil ældre monolit, et SaaS-værktøj med voksende licenstryk og en integrationsstrækning med natkørsler er uden et raster svære at veje op mod hinanden.
• Uensartet datagrundlag: For system A findes incident-statistikker og monitoring, for system B kun mavefornemmelse, for system C slet intet.
• Blandede diskussioner: Faglig værdi, tekniske risici og personlige præferencer (teknologi, teamønsker) ender i samme gryde.
• Alt for omfattende vurderingsmodeller: Omfattende modenhedsmodeller giver mening – men vedligeholdes ofte ikke regelmæssigt. Til porteføljeafgørelser tæller gentagelighed.

Et letvægts scoringmodel er ikke en perfekt sandhed. Det er et instrument til at reducere usikkerhed og gøre beslutninger efterprøvelige – inklusive de antagelser, der ligger bag.

Principper for et letvægts scoringmodel

For at et scoringmodel ikke ender som en „Excel-øvelse“, bør det opfylde et par grundprincipper:

• Få dimensioner, klare definitioner: Hellere 6–8 vurderingsdimensioner klart definere end at samle 20 halvkriterier.
• Målbar, men ikke talfikseret: Ikke alt er tilgængeligt som tal. Det væsentlige er, at kriterierne anvendes konsistent.
• Porteføljeegnet: Vurderingen skal fungere på tværs af systemer – uanset om der er tale om individuel virksomhedssoftware, standardprodukter eller integrationskomponenter.
• Eksplicitte perspektiver: Drift, Sikkerhed, Data og fagafdelingen bør indgå i modellen, så der ikke blot diskuteres „teknik mod forretning“.

I praksis har det vist sig hensigtsmæssigt at behandle scoren som udgangspunkt for dialog: Den leverer en prioriteret liste, men ingen automatiske beslutninger. Porteføljeudvalg forbliver ansvarlige – og dokumenterer bevidst afvigelser.

Scoringsmodellen: 8 dimensioner, der virkelig tæller i driften

Det følgende skema anvender otte dimensioner, som kan fastlægges i typiske virksomhedslandskaber. Hver dimension vurderes på en skala fra 1 til 5 (1 = uproblematisk/godt kontrolleret, 5 = kritisk/akut behov for handling). Vigtigt er ikke matematisk perfektion, men entydigheden af kriterierne.

1) Driftsstabilitet og forstyrrelsesprofil

Her handler det om spørgsmålet: Hvor ofte forstyrrer systemet driften – og hvor kostbare er disse forstyrrelser organisatorisk? Grundlaget er Incidents (forstyrrelser), tilbagevendende tickets, on-call-eskalationer og uplanlagte vedligeholdelser. Også „stille“ ustabilitet tæller, f.eks. når natkørsler ofte må efterarbejdes.

Vurderingsanker (eksempler):

• 1: Sjældne Incidents, klare Runbooks (driftshåndbøger), genstart øvet.
• 3: Regelmæssige forstyrrelser eller hyppige performance-problemer, men håndterlige.
• 5: Tilbagevendende nedbrud, høj supportbelastning, workarounds i stedet for årsagsafhjælpning.

2) Sikkerheds- og compliance-risiko

Denne dimension vurderer, hvor godt systemet er sikret mod sikkerhedshændelser, og hvor auditérbart (kontrollerbart) det kan drives. Det omfatter patchbarhed, understøttede komponenter, autentificering (fx SSO via SAML/OIDC – altså central login), logning (audit-trail: efterprøvbar hændelseskæde) og beskyttelse af følsomme data.

• 1: Regelmæssige opdateringer, klare roller/rettigheder, efterprøvbare logs, ingen kendte „End-of-Life“-komponenter.
• 3: Delvist forældede komponenter eller mangler i logning/recertificering, kompensationsforanstaltninger til stede.
• 5: Kritiske forældede komponenter, manglende patches, uklare ansvarsforhold, audit-risici.

3) Ændringsvenlighed og release-parathed

„Hvor svært er det at levere ændringer sikkert?“ Det er kernen i mange tekniske gældsforhold. Der tænkes på testbarhed (regression: gentagne tests), deploy-proces, rollback-funktionalitet (ren fallback-mulighed), afhængighed af enkeltpersoner samt tiden fra krav til idriftsættelse.

• 1: Reproducerbare Releases, definerede miljøer, planlæggelige vedligeholdelsesvinduer.
• 3: Releases mulige, men med manuelle trin og øget koordineringsarbejde.
• 5: Enhver ændring er en risiko, Deploy kun „med de rigtige folk“, Rollback uklar.

4) Arkitektur- und Integrationskomplexität

Denne dimension vurderer ikke, om en arkitektur er „moderne“, men om den er håndterbar. Integrationer er ofte omkostningsdriveren: punkt-til-punkt-grænseflader, specifikke filformater, tidskritisk batchbehandling, manglende versionering af API’er (grænsefladekontrakter) eller tæt kobling til andre systemer.

• 1: Klart dokumenterede grænseflader, få koblingspunkter, ændringer virker lokalt.
• 3: Flere afhængigheder, ændringer kræver koordinerede releases.
• 5: „Spaghetti“-integrationer, ukendte dataforløb, stor indvirkning ved små ændringer.

5) Datakvalitet, dataherredømme og dataflow

For porteføljeafgørelser er det afgørende, om data føres ordentligt og kan anvendes pålideligt. Dataherredømme betyder: Det er klart, hvor „sandhedens kilde“ ligger, hvordan stamdata (f.eks. kunder, artikler, leverandører) opstår, og hvordan ændringer virker nedstrøms. Dataflow omfatter også eksporter, skyggekopier og manuelle korrektioner.

• 1: Klare ansvarsfordelinger, sporbare dataveje, definerede grænseflader, konsistente nøgler.
• 3: Flere datakilder eller regelmæssige oprydninger, men transparente.
• 5: Uklar „sandhed“, hyppige korrektioner, rapportering kun mulig med speciallogik.

6) Lifecycle-Risiko: Hersteller, Plattform, Skills

Teknisk gæld opstår også ved udfasninger: operativsystemer, databaser, biblioteker, producent-support eller tilgængelighed af knowhow. Denne dimension ser bevidst på den organisatoriske side: Er der nok personer, der kan varetage drift og videreudvikling? Findes der en robust opgraderingssti?

• 1: Aktive supportcyklusser, planlagt opgradering, kompetencer bredt tilgængelige.
• 3: Opgradering står for døren, knappe kompetencer, afhængighed af få nøglepersoner.
• 5: End-of-Life, ingen roadmap, viden koncentreret, høj leverandørrisiko.

7) Kosten- und Aufwandstreiber im laufenden Betrieb

Her vurderes ikke kun infrastrukturudgifter, men især variable omkostninger: supportindsats, manuelle opgaver, specialprocesser, licensvækst, binding af eksterne leverandører eller dyre vedligeholdelsesvinduer. Især forretningssoftware er disse indirekte omkostninger ofte mere afgørende end serverpriser.

• 1: Stabil drift, få manuelle opgaver, omkostninger planlæggelige.
• 3: Øget driftsindsats eller stigende licensomkostninger, men håndterbart.
• 5: Drift „spiser“ kapacitet, mange manuelle korrektioner, omkostninger vanskelige at forudsige.

8) Business-Kritikalität und Prozessabhängigkeit

Teknisk gæld er først relevant for porteføljeafgørelser, når den kombineres med procesrisiko. Denne dimension vurderer, hvor stærkt systemet understøtter kerneprocesser, og hvor stor skaden er ved fejl eller nedbrud. Vigtigt: Kritikalitet er ikke en fribillet til „aldri røre“, men et argument for ordentlig stabilisering og modernisering.

• 1: Understøttende proces, nedbrud håndterbart, workaround tilgængelig.
• 3: Vigtig proces, nedbrud giver omkostninger, men kan begrænses.
• 5: Kerneproces, nedbrud stopper værdiskabelse eller fører til compliance-risici.

Hvordan scores bliver til porteføljeafgørelser (uden falsk præcision)

En score er først brugbar, når den forbereder en beslutning. Det kræver to trin: vægtning og beslutningskategorier.

Vægtning: ikke hvert kriterium tæller lige meget

Mange organisationer starter med ens vægtning for at undgå diskussioner. Senere kan det betale sig at anvende en enkel vægtning efter porteføljemål, f.eks.:

• Sikkerhed først (f.eks. efter auditfund): sikkerheds- og compliance-risiko vægtes dobbelt.
• Forbedre leveringssikkerhed (f.eks. ved stort change-backlog): ændrings- og release-evne vægtes højere.
• Stabilisere omkostninger (f.eks. ved stigende support): driftsomkostningsdrivere vægtes stærkere.

Det er vigtigt at dokumentere vægtningen transparent og kun ændre den sjældent. Ellers fremstår score-ændringer som „politiske“ i stedet for som reelle forbedringer.

Beslutningskategorier: fire klare handlemuligheder

Ud fra dimensionerne kan man aflede fire pragmatiske kategorier, som egner sig til diskussion i porteføljebestyrelsen:

• Stabilisere: Høje drifts-/sikkerhedsrisici, men ingen kortsigtet udskiftning mulig. Fokus på runbooks, overvågning, patchrutiner og teknisk hygiejne.
• Modernisere: Høj ændrings- eller livscyklusrisiko samtidig med høj kritikalitet. Fokus på modulær fornyelse, frakobling af grænseflader og konsolidering af datamodeller.
• Konsolidere/Erstatte: Dublette funktioner, højt arbejdsomfang, lav differentiering. Fokus på nedlukning, datamigrering og procesharmonisering.
• Bevidst acceptere: Lav kritikalitet eller forudsigelig RESTlevetid. Fokus på risikokontrol, minimal vedligeholdelse og klar exit-mulighed.

For at det ikke forbliver teoretisk bør hver applikation desuden have et næste fornuftige skridt – maks. 1–2 konkrete tiltag, som er realistiske at gennemføre på 4–12 uger. På den måde bliver porteføljestyring en løbende forbedringsproces fremfor en årlig workshop.

Byg datagrundlaget pragmatisk op: Hvilke kilder er som regel tilstrækkelige

En letvægtsmodel lever af, at indhentning af data ikke er dyrere end de første tiltag. For mange virksomheder er fire datakilder tilstrækkelige til at give seriøse scores:

• Ticket-/incident-data: Hyppighed, gentagelser, behandlingstider, eskalationer. Hvis der ikke er en ren kategorisering, er en grov inddeling i starten tilstrækkelig (fejl, forespørgsel, change).
• Overvågning/tilgængelighed: Ikke kun „uptime“, men også performance-spidser, jobkørsler, fejlrater, vækst i hukommelse/disk.
• Sikkerheds- og livscyklusinformation: Patch-niveau, end-of-life-datoer, afhængigheder (fx databaseversion, operativsystem, autentificering), kendte undtagelser.
• Arkitektur-/integrationsoversigt: Et enkelt Application-Map (systemkort) med dataflow og grænseflader. Fuldstændighed er sekundær; aktualitet tæller.

Hvis tal mangler, bør det være synligt i scoren: „Vurdering 4 på grund af manglende dokumentation“ er ærligere end et tilfældigt gennemsnit. Ukendt er i drift ofte mere risikabelt end dårligt, som man i det mindste kender til.

Scoring-workshop på 90 minutter: forløb, roller, resultatartefakter

En almindelig fejl er at udføre Scoring som individuelt arbejde. Så bliver det enten for teknisk eller for politisk. Bedre er en kort workshop pr. system, modereret og med klare roller. 90 minutter er nok til en første pålidelig vurdering, hvis grunddata foreligger.

Deltagere (få, men fuldstændige)

• Systemansvarlig IT: kender roadmap, ændringer, tekniske flaskehalse.
• Drift/Administration: kender driftsforstyrrelser, vedligeholdelsesvinduer, overvågning, backup/RESTore.
• Faglig ejer eller nøglebruger: kender proceskritikalitet, workarounds, accept, peak-tider.
• Moderation: sikrer overholdelse af definitioner og dokumenterer antagelser.

Forløb (kompakt, gentageligt)

1. Kontext (10 Min.): Systemets formål, brugergrupper, hovedgrænseflader, driftsmodel (On-Prem/Cloud/Hybrid).
2. Score pr. dimension (45 Min.): For hvert kriterium 3–5 minutter, med korte belæg (antal Tickets, Patchstand, kendte afhængigheder).
3. Identificere Hotspots (15 Min.): Hvilke to dimensioner driver risiko/omkostninger mest?
4. Fastlægge tiltag (15 Min.): 1–2 konkrete næste skridt, plus ansvarlig og måltermin.
5. Portfolio-Label (5 Min.): Stabilisere / Modernisere / Konsolidere / Acceptere.

Som resultat er tre artefakter tilstrækkelige: Score-Tabelle, kort begrundelse per dimension og et kort udtræk med tiltag. Alt andet er valgfrit.

Typiske faldgruber – og hvordan man fanger dem i modellen

Et Scoring-Modell kan sætte forkerte incitamenter, hvis det ikke er klart indrammet. Ud fra projekterfaring er dette de hyppigste faldgruber:

Faldgrube 1: „Vi straffer teams for transparens“

Hvis teams med god dokumentation får dårligere Scores, fordi de gør problemer synlige, er modellen ødelagt. Modmiddel: Behandle ukendt (manglende data) som en selvstændig risiko og anerkend transparens udtrykkeligt som et plus, f.eks. i kriteriet Änderbarkeit (Rollbacks, Runbooks, Monitoring).

Faldgrube 2: Score bliver et budgetnedskæringsinstrument

Hvis høje Scores automatisk fører til „Projektstopp“, bliver modellen politisk. Bedre: Høje Scores fører til en beslutningsoplæg med muligheder (f.eks. Stabilisierung vs. Modernisierung) og klare konsekvenser. Budgettet følger beslutningen – ikke scoren alene.

Faldgrube 3: Sammenblanding af nytte og risiko

Faglig nytte (f.eks. Umsatzpotenzial) er vigtig, men en anden akse. En afprøvet fremgangsmåde: Vurdér nytten i et separat raster og kombiner det derefter i en Portfolio-Matrix (Nutzten hoch/niedrig vs. Risiko/Schulden hoch/niedrig). Så diskuterer man ikke, om en sikkerhedsrisiko „durch Umsatz“ kompenseres.

Faldgrube 4: „Modernisierung“ wird als Großprojekt verstanden

Portfolio-beslutninger fejler ofte på den implicitte antagelse, at modernisering kun kan ske som et Big Bang. I realiteten er en modulær modernisering ofte mere fornuftig: stabilisere grænseflader, standardisere dataadgang, udkoble enkelte delprocesser, styre paralleldrift ordentligt. Et Score hjælper med at finde rækkefølgen, ikke at tvinge en sluttilstand.

Fra Score til Roadmap: hvordan tiltagspakker tilpasses hensigtsmæssigt

Når modellen er på plads, begynder det egentlige arbejde: skære tiltagene, så de kan fungere i hverdagen sideløbende med projektarbejdet. Tre regler hjælper med at gøre et „vi burde“ til konkrete roadmap-elementer:

1) Afbød først de dyRESTe risici „entschärfen“

I mange porteføljer er sikkerheds- og driftsrisici de største løftestænger, fordi de har eksterne deadlines (audit, end-of-life) og høje følgeomkostninger. Typiske afbødninger er: etablere en opdateringssti, supplere logging/audit-trail, teste backup/RESTore, reducere enkelt fejlpunkt, validere adgangsrettigheder.

2) Stabilisere integrationsknudepunkter før funktionsudvidelse

Systemer med mange grænseflader multiplicerer change-omkostninger. Her lønner det sig ofte først at: definere grænsefladekontrakter (versionering, dataformater, fejlbehandling), tilføje monitoring af dataflow, løsne koblinger i jobkæder, indføre retry-strategier (gentagne forsøg ved fejl). Det er sjældent „synligt“ for fagområdet, men det reducerer nedetid og release-stress målbart.

3) Gør tiltag planlæggelige som „driftsforbedring“

Mange tekniske gældsforpligtelser kan gennemføres som driftsforbedringer i små pakker: Runbooks, alarmregler, kapacitetsplanlægning, standardisering af miljøer, regelmæssige patchvinduer. Det er ikke glamourøse projekter, men de øger pålideligheden – og skaber tidsrum til større moderniseringstrin.

Så bliver Scoring varig: Governance uden bureaukrati

En model er kun værdifuld, hvis den ikke går i dvale efter to kvartaler. Det kræver en enkel proces, der passer til drifts- og projektdagligdagen:

• Owner pro Anwendung: En navngiven person, der vedligeholder Score og tilstandsstatus for tiltagene (implementerer dem ikke alene).
• Trigger statt Kalenderpflicht: Score-review efter incident-klynger, Major-Release, Audit-Fund eller platformopgradering.
• Portfolio-Rhythmus: Månedligt/hver anden måned 60 minutter til top-risici, ikke til alle systemer.
• Entscheidungslog: Kort dokumentation om, hvorfor en risiko blev accepteret eller udsat. Det forhindrer senere bebrejdelser og gør antagelser synlige.

Det er vigtigt at koble det til reel styring: Mindst en del af kapaciteten (budget eller team-tid) bør eksplicit reserveres til stabilisering/modernisering. Ellers producerer modellen kun indsigter uden effekt.

Konklusion: Synliggøre teknisk gæld uden at overbelaste organisationen

En letvægts scoringmodel for teknisk gæld erstatter ikke detaljeret arkitekturarbejde – men den skaber noget, som ofte mangler i porteføljer: sammenlignelighed. Med otte klare dimensioner, efterviselige vurderingsankre og et kort workshopformat kan risici, driftsindsats og moderniseringspres fremstilles, så IT, fagafdeling og ledelsen fører den samme diskussion.

Den vigtigste effekt er sjældent den præcise talværdi. Det er gennemsigtigheden om, hvor teknisk gæld opstår, hvordan den belaster driften, og hvilke næste skridt der er realistiske. Når scores regelmæssigt gennemgås og kobles til små, konkrete tiltag, opstår en moderniserings-roadmap, der ikke kun lever på tegnebrættet, men bærer i daglig drift.

Hvis du vil opsætte scoringmodellen for dit applikationsportefølje eller gennemføre de første vurderinger i et modereret format, finder du her det passende indgangspunkt: Kontakt os.

I denne sammenhæng er også „Vurdering af teknisk gæld“ og „Portefølje-beslutninger It“ vigtige. Indlægget sætter disse aspekter i forståelig kontekst og viser, hvad der er vigtigt i hverdagen.

Drøft projekt eller moderniseringsprojekt med Net-Base.