Synliggjøre teknisk gjeld: En lettvekts scoringsmodell for porteføljebeslutninger

I mange IT-organisasjoner er teknisk gjeld lenge blitt en varig tilstand: applikasjoner kjører, prosesser fungerer, og likevel blir hver endring tregere, hver release mer risikabel og hver feil dyrere. Problemet er sjelden at ingen ser risikoene – det er at de ikke er sammenlignbare. Når fem systemer samtidig er «kritiske», kan ingen til syvende og sist prioriteres. Her hjelper et scoringsmodell for teknisk gjeld: et lettvekts, repeterbart vurderingsrammeverk som avbilder tekniske risikoer, driftsinnsats og moderniseringstrykk slik at porteføljeavgjørelser blir robuste.

Denne artikkelen beskriver en scoringsmodell som klarer seg uten mammut-assessment, men som fungerer i hverdagen for IT-ledelse, drift, administratorer, prosjektansvarlige og fagavdelinger. Fokus er ikke interne kode-detaljer, men konsekvenser for drift, sikkerhet, data, grensesnitt, leveranseevne og vedlikehold. Målet er et felles språk som demper budsjett- og prioriteringsdiskusjoner og gjør modernisering planlagt.

Scoringsmodell for teknisk gjeld i praksis

Teknisk gjeld er en samlebetegnelse for beslutninger og etterslep som kortsiktig sparte tid, men som på lang sikt påfører rentekostnader. Disse «rentene» viser seg i daglig virksomhet som lengre gjennomløpstider, mer koordinering, høyere feilrater, sikkerhetshull, spesialkunnskap hos få personer eller avhengigheter av komponenter som ikke lenger støttes. Poenget er: Mange av disse effektene fremstår ikke som et tydelig kostnadssted.

Typiske grunner til at teknisk gjeld drukner i porteføljerunder:

• Manglende sammenlignbarhet: En stabil gammel monolitt, et SaaS-verktøy med økende lisenspress og en integrasjonsløsning med nattkjøringer er vanskelig å veie mot hverandre uten et rammeverk.
• Uensartet datagrunnlag: For system A finnes hendelsesstatistikk og overvåking, for system B bare magefølelse, for system C ingenting.
• Blandede diskusjoner: Faglig gevinst, tekniske risikoer og personlige preferanser (teknologi, teamønsker) havner i samme gryte.
• For store vurderingsmodeller: Omfattende modenhetsmodeller er fornuftige – men blir ofte ikke vedlikeholdt regelmessig. For porteføljeavgjørelser teller repeterbarhet.

Et lettvekts scoringsmodell er ingen perfekt sannhet. Det er et verktøy for å redusere usikkerhet og gjøre beslutninger etterprøvbare – inkludert forutsetningene bak dem.

Prinsipper for et lettvekts scoringsmodell

For at et scoringsmodell ikke skal ende som en «Excel‑øvelse», bør det oppfylle noen grunnprinsipper:

• Få dimensjoner, klare definisjoner: Heller 6–8 vurderingsdimensjoner forklart presist enn å samle 20 halvkriterier.
• Målbart, men ikke tallfiksert: Ikke alt finnes som tall. Viktig er at kriteriene anvendes konsekvent.
• Porteføljeegnet: Vurderingen må fungere på tvers av systemer – uavhengig av om det er individuell virksomhetssoftware, standardprodukter eller integrasjonskomponenter.
• Eksplisitte perspektiver: Drift, sikkerhet, data og fagavdeling skal være med i modellen, slik at det ikke bare blir «teknikk mot business».

I praksis har det vist seg nyttig å behandle scoren som en samtaleplattform: Den leverer en prioritert liste, men ikke automatiske beslutninger. Porteføljekomiteer forblir ansvarlige – og dokumenterer avvik bevisst.

Scoring-modellen: 8 dimensjoner som virkelig teller i driften

Følgende rutenett bruker åtte dimensjoner som lett lar seg innhente i typiske virksomhetslandskap. Hver dimensjon vurderes på en skala fra 1 til 5 (1 = ukritisk/godt håndtert, 5 = kritisk/akutt behov for tiltak). Det viktige er ikke matematisk perfeksjon, men entydigheten i kriteriene.

1) Driftsstabilitet og forstyrrelsesprofil

Her handler det om spørsmålet: Hvor ofte forstyrrer systemet driften – og hva koster disse forstyrrelsene organisatorisk? Grunnlaget er incidents (forstyrrelser), gjentakende tickets, on-call-eskalasjoner og uplanlagt vedlikehold. Også «stille» ustabilitet teller, for eksempel når nattkjøringer ofte må etterarbeides.

Vurderingsankre (eksempler):

• 1: Sjeldne incidents, klare runbooks (driftshåndbøker), gjenstart øvd.
• 3: Regelmessige forstyrrelser eller hyppige ytelsesproblemer, men håndterbare.
• 5: Gjentakende nedetid, høy supportbelastning, midlertidige løsninger i stedet for årsaksfjerning.

2) Sikkerhets- og compliance-risiko

Denne dimensjonen vurderer hvor godt systemet er beskyttet mot sikkerhetshendelser og hvor revisjonsbart det kan drives. Dette inkluderer patchbarhet, støttede komponenter, autentisering (f.eks. SSO via SAML/OIDC – altså sentral pålogging), logging (audit-trail: etterprøvbar hendelseskjede) og beskyttelse av sensitive data.

• 1: Regelmessige oppdateringer, klare roller/rettigheter, etterprøvbare logger, ingen kjente end-of-life-komponenter.
• 3: Delvis utdaterte komponenter eller mangler i logging/reso-godkjenning, kompensasjonstiltak på plass.
• 5: Kritiske eldre versjoner, manglende patches, uklare ansvarslinjer, revisjonsrisiko.

3) Endringsbarhet og release-evne

„Hvor vanskelig er det å levere endringer sikkert?“ Dette er kjernen i mye teknisk gjeld. Det gjelder testbarhet (regresjon: repeterende tester), deploy-prosess, rollback-evne (ryddig tilbakestillingsmulighet), avhengighet av enkeltpersoner samt tiden fra krav til produksjonssetting.

• 1: Reproduserbare releaser, definerte miljøer, planbare vedlikeholdsvinduer.
• 3: Releaser er mulig, men krever manuelle steg og økt koordineringsinnsats.
• 5: Hver endring innebærer risiko, deploy kun «med de rette personene», rollback uklar.

4) Arkitektur- og integrasjonskompleksitet

Denne dimensjonen vurderer ikke om en arkitektur er „moderne“, men om den er kontrollerbar. Integrasjoner er ofte kostnadsdriveren: punkt-til-punkt-grensesnitt, spesielle filformater, tidskritisk batch-behandling, manglende versjonering av APIer (grensesnittkontrakter) eller tett kobling til andre systemer.

• 1: Tydelig dokumenterte grensesnitt, få koblingspunkter, endringer har lokal virkning.
• 3: Flere avhengigheter, endringer krever koordinerte utgivelser.
• 5: „Spaghetti“-integrasjoner, ukjente dataflyter, stor påvirkning ved små endringer.

5) Datakvalitet, dataeierskap og dataflyt

For porteføljebeslutninger er det avgjørende om data blir ført korrekt og er pålitelig brukbare. Dataeierskap betyr: Det er klart hvor „sannhetens kilde“ ligger, hvordan stamdata (f.eks. kunder, artikler, leverandører) opprettes og hvordan endringer får etterfølgende effekt. Dataflyter omfatter også eksporter, skyggekopier og manuelle korrigeringer.

• 1: Klare ansvarsforhold, sporbare dataflyter, definerte grensesnitt, konsistente nøkler.
• 3: Flere datakilder eller regelmessige oppryddinger, men likevel gjennomsiktige.
• 5: Uklar „sannhet“, hyppige korrigeringer, rapportering kun mulig med særskilt logikk.

6) Livssyklusrisiko: leverandør, plattform, kompetanse

Teknisk gjeld oppstår også gjennom utfasinger: operativsystemer, databaser, biblioteker, leverandørstøtte eller tilgjengelighet av kompetanse. Denne dimensjonen ser bevisst på den organisatoriske siden: Finnes det nok personer som bærer drift og videreutvikling? Finnes det en robust oppgraderingsvei?

• 1: Aktive support-sykluser, oppgradering planlagt, kompetanse bredt tilgjengelig.
• 3: Oppgradering står for tur, kompetansesituasjonen anstrengt, avhengighet av noen få nøkkelpersoner.
• 5: End-of-Life, ingen roadmap, kunnskap konsentrert, leverandørrisiko høy.

7) Kostnads- og arbeidsdrivere i løpende drift

Her vurderes ikke bare infrastrukturkostnader, men først og fremst variable kostnader: supportinnsats, manuelle oppgaver, særprosesser, lisensvekst, avhengighet av eksterne tjenesteleverandører eller kostbare vedlikeholdsvinduer. Spesielt for forretningssystemer er disse indirekte kostnadene ofte viktigere enn serverpriser.

• 1: Stabil drift, få manuelle oppgaver, kostnader forutsigbare.
• 3: Økt driftsinnsats eller stigende lisenskostnader, men håndterbart.
• 5: Driften „spiser“ kapasitet, mange manuelle korreksjoner, kostnader vanskelig å prognostisere.

8) Forretningskritikalitet og prosessavhengighet

Teknisk gjeld blir relevant for porteføljebeslutninger først når den kombineres med prosessrisiko. Denne dimensjonen vurderer hvor mye systemet bærer kjerneeprosesser og hvor stor skaden er ved svikt eller feil. Viktig: Kritikalitet er ikke fribillett for „aldri rør“, men et argument for målrettet stabilisering og modernisering.

• 1: Støtteprosess, svikt tålelig, midlertidig løsning tilgjengelig.
• 3: Viktig prosess, svikt medfører kostnader, men kan begrenses.
• 5: Kjerneprosess, svikt stopper verdiskaping eller fører til samsvarsrisiko.

Hvordan scores blir til porteføljebeslutninger (uten falsk presisjon)

En score er først nyttig når den forbereder en beslutning. Det krever to trinn: vekting og beslutningskategorier.

Vekting: ikke alle kriterier teller likt

Mange organisasjoner starter med lik vektlegging for å unngå diskusjoner. Senere lønner det seg med en enkel vektlegging etter porteføljemål, for eksempel:

• Sikkerhet først (f.eks. etter revisjonsfunn): Sikkerhets- og compliance-risiko vektes dobbelt.
• Øke leveranseevne (f.eks. ved høy change-backlog): Endringsbarhet/release-evne vektes sterkere.
• Stabilisere kostnader (f.eks. ved økende support): Driftsrelaterte kostnadsdrivere vektlegges sterkere.

Det er viktig å dokumentere vektleggingen åpent og endre den sjelden. Ellers fremstår endringer i score som «politiske» i stedet for reelle forbedringer.

Beslutningskategorier: fire klare handlingsalternativer

Fra dimensjonene kan man utlede fire pragmatiske kategorier som er enkle å diskutere i porteføljestyret:

• Stabilisere: Høye drifts-/sikkerhetsrisikoer, men ingen kortsiktig utskifting mulig. Fokus på runbooks, overvåking, patch‑rutiner, teknisk hygiene.
• Modernisere: Høy endrings- eller livssyklusrisko samtidig som kritikaliteten er høy. Fokus på modulær fornyelse, løsriving av grensesnitt, konsolidering av datamodeller.
• Konsolidere/Erstatte: Doble funksjoner, høy innsats, liten differensiering. Fokus på avvikling, datamigrasjon, standardisering av prosesser.
• Bevisst akseptere: Lav kritikalitet eller forutsigbar gjenværende levetid. Fokus på risikokontroller, minimal vedlikehold, klar exit‑opsjon.

For at dette ikke skal forbli teoretisk, bør hver applikasjon i tillegg få et neste fornuftige steg – maksimalt 1–2 konkrete tiltak som er realistiske å gjennomføre på 4–12 uker. Slik blir porteføljestyring en løpende forbedringsprosess i stedet for en årlig workshop.

Bygg datagrunnlaget pragmatisk: Hvilke kilder er vanligvis tilstrekkelige

Et lettvektsmodell forutsetter at datainnhenting ikke blir dyrere enn de første tiltakene. For mange selskaper er fire datakilder tilstrekkelig for å gi seriøse scorer:

• Ticket-/incidentdata: Hyppighet, gjentakelser, behandlingstider, eskaleringer. Hvis det ikke finnes en klar kategorisering, holder det i starten med en grov inndeling (feil, forespørsel, change).
• Overvåking/tilgjengelighet: Ikke bare «uptime», men også ytelsestopper, kjøringstider for jobber, feilrater, minne-/diskvekst.
• Sikkerhets- og livssyklusinfo: Patchnivå, end-of-life-datoer, avhengigheter (f.eks. databaseversjon, operativsystem, autentisering), kjente unntak.
• Arkitektur-/integrasjonsoversikt: Et enkelt applikasjonskart (systemkart) med dataflyt og grensesnitt. Fullstendighet er sekundært, aktualitet teller.

Hvis tall mangler, bør det være synlig i scoren: «Vurdering 4 på grunn av manglende dokumentasjon» er ærligere enn et tilfeldig gjennomsnitt. Ukjent er i drift ofte mer risikabelt enn dårlig, som man i det minste kjenner til.

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

En vanlig feil er å gjennomføre scoring som individuelt arbeid. Da blir det enten for teknisk eller for politisk. Bedre er en kort workshop per system, moderert og med klare roller. 90 min. er nok for en første robust vurdering dersom basisdata foreligger.

Deltakere (få, men fullstendige)

• Systemansvarlig IT: kjenner roadmap, endringer, tekniske flaskehalser.
• Drift/Administration: kjenner feil, vedlikeholdsvinduer, overvåking, backup/RESTore.
• Faglig eier eller nøkkelbruker: kjenner prosesskritikalitet, workarounds, aksept, topptider.
• Moderering: sørger for definisjonstrehet og dokumenterer antagelser.

Gjennomføring (kompakt, repeterbar)

1. Kontekst (10 min.): formål med systemet, brukergrupper, hovedgrensesnitt, driftsmodell (On-Prem/Cloud/Hybrid).
2. Score per dimensjon (45 min.): per kriterium 3–5 minutter, med korte belegg (antall tickets, patchnivå, kjente avhengigheter).
3. Identifisere hotspots (15 min.): Hvilke 2 dimensjoner driver risiko/kostnader sterkest?
4. Fastsette tiltak (15 min.): 1–2 konkrete neste steg, pluss eier og målfrist.
5. Portefølje-etikett (5 min.): Stabilisere / Modernisere / Konsolidere / Akseptere.

Som resultat er tre artefakter tilstrekkelig: score-tabell, kort begrunnelse per dimensjon og et tiltakssnutt. Alt annet er valgfritt.

Typiske fallgruver – og hvordan man fanger dem i modellen

Et scoringsmodell kan gi feil insentiver hvis det ikke er tydelig avgrenset. Basert på prosjekterfaring er dette de vanligste snublefellene:

Fallgruve 1: “Vi straffer team for åpenhet”

Hvis team med god dokumentasjon får dårligere scorer fordi de synliggjør problemer, er modellen ødelagt. Motmiddel: Behandle ukjent (manglende data) som egen risiko og anerkjenn åpenhet uttrykkelig som et pluss, f.eks. i kriteriet endringsbarhet (rollbacks, runbooks, overvåking).

Fallgruve 2: Scoren blir et verktøy for budsjettkutt

Hvis høye scorer automatisk fører til “prosjektstopp”, blir modellen politisk. Bedre: Høye scorer fører til en beslutningssak med alternativer (f.eks. stabilisering vs. modernisering) og klare konsekvenser. Budsjettet følger beslutningen – ikke scoren alene.

Fallgruve 3: Blanding av nytte og risiko

Faglig nytte (f.eks. omsetningspotensial) er viktig, men en egen akse. Et etablert tilnærming: vurder nytte i et eget rutenett og slå det sammen i en porteføljematrise (nytte høy/lav vs. risiko/gjeld høy/lav). På den måten diskuteres det ikke om en sikkerhetsrisiko “kompenseres av omsetning”.

Fallgruve 4: “Modernisering” forstås som et stort prosjekt

Porteføljebeslutninger mislykkes ofte på grunn av den implisitte antakelsen om at modernisering bare kan skje som et Big Bang. I realiteten er en modulær modernisering ofte mer fornuftig: stabilisere grensesnitt, standardisere dataaksesser, kapsle ut enkelte delprosesser, styre parallelldrift på en ryddig måte. En score hjelper med å finne rekkefølgen, ikke å tvinge frem en sluttstilstand.

Fra score til veikart: hvordan tiltakspakker tilpasses hensiktsmessig

Når modellen er på plass begynner det egentlige arbeidet: skjære tiltak slik at de fungerer i hverdagen ved siden av prosjektvirksomheten. Tre regler hjelper med å gjøre «vi burde» til konkrete veikartelementer:

1) Først dempe de kostbarste risikoene

I mange porteføljer er sikkerhets- og driftsrisikoer de største løftestengene, fordi de har eksterne frister (audit, end-of-life) og høye følgekostnader. Typiske tiltak for å dempe risikoene er: etablere en oppdateringsvei, supplere logging/audit-trail, teste backup/RESTore, redusere Single Point of Failure, verifisere tilgangsrettigheter.

2) Stabiliser integrasjonsknutepunkter før funksjonsutvidelse

Systemer med mange grensesnitt er multiplikatorer for endringskostnader. Her lønner det seg ofte å gjøre følgende først: definere grensesnittkontrakter (versjonering, dataformater, feilbehandling), legge til overvåkning for dataflyt, løsrive jobb-kjeder, innføre retry-strategier (gjenforsøk ved feil). Dette er sjelden synlig for fagavdelingen, men det reduserer nedetid og release-stress målbart.

3) Gjøre tiltak planbare som «driftsforbedringer»

Mange tekniske gjeldsposter kan gjennomføres som operative forbedringer i små pakker: runbooks, alarmregler, kapasitetsplanlegging, standardisering av miljøer, regelmessige patchvinduer. Det er ingen glamorøse prosjekter, men de øker pålitelighet – og skaper tidsrom for større moderniseringstiltak.

Slik blir scoringen varig: styring uten byråkrati

En modell er kun verdifull hvis den ikke faller i søvn etter to kvartaler. Derfor trengs en enkel prosess som passer inn i drift- og prosjekthverdagen:

• Eier per applikasjon: En navngitt person som vedlikeholder score og status for tiltakene (ikke implementerer dem alene).
• Trigger i stedet for kalenderplikt: Score-gjennomgang etter incident-klynge, major release, audit-funn eller plattformoppgradering.
• Porteføljerytme: Månedlig/annenhver måned 60 minutter for topp-risikoene, ikke for alle systemene.
• Beslutningslogg: Kort dokumentasjon på hvorfor en risiko ble akseptert eller utsatt. Det forhindrer senere skyldfordelinger og gjør antakelser synlige.

Viktig er koblingen til reell styring: Minst en del av kapasiteten (budsjett eller teamets tid) bør være eksplisitt avsatt til stabilisering/modernisering. Ellers produserer modellen bare innsikt uten effekt.

Konklusjon: Gjør teknisk gjeld synlig uten å overbelaste organisasjonen

En lettvekts scoringsmodell for teknisk gjeld erstatter ikke detaljert arkitekturarbeid – men den skaper noe som ofte mangler i porteføljer: sammenlignbarhet. Med åtte klare dimensjoner, etterprøvbare vurderingsankre og et kort workshopformat kan risikoer, driftsinnsats og press for modernisering fremstilles slik at IT, fagavdeling og ledelse fører samme diskusjon.

Den viktigste effekten er sjelden den eksakte tallverdien. Det er transparensen om hvor teknisk gjeld oppstår, hvordan den belaster driften og hvilke neste skritt som er realistiske. Når score regelmessig gjennomgås og knyttes til små, konkrete tiltak, oppstår en moderniseringsplan som ikke lever på tegnebrettet, men bærer i det daglige arbeidet.

Hvis du vil sette opp scoringsmodellen for applikasjonsporteføljen din eller gjennomføre de første vurderingene i et moderert format, finner du her et passende utgangspunkt: ta kontakt.

For dette temaet er også Vurdering av teknisk gjeld og IT-porteføljebeslutninger viktige. Artikkelen plasserer disse aspektene i en forståelig kontekst og viser hva som gjelder i praksis.

Diskuter prosjekt eller moderniseringsprosjekt med Net-Base.