Gjere teknisk gjeld synleg: eit lettvekts scoringsmodell for porteføljebeslutningar

I mange IT-organisasjonar er teknisk gjeld allereie ein permanent tilstand: applikasjonar køyrer, prosessar fungerer, og likevel blir kvart endringsarbeid tregare, kvart release meir risikabelt og kvar feil dyrare. Problemet er sjeldan at ingen ser risikoane – men at dei ikkje er samanliknbare. Når fem system samtidig er «kritiske», blir til slutt ingen prioritert. Her kjem eit Scoring-modell for teknisk gjeld til hjelp: eit lettvekt, gjentakbart vurderingsrammeverk som avbildar tekniske risikoar, driftsinnsats og moderniseringspress slik at porteføljevedtak kan bli forsvarlege.

Dette innlegget skildrar eit lettvekt Scoring-modell som fungerer utan eit mammut-assessment, men som er nyttig i kvardagen for IT-leiing, drift, administratorar, prosjektansvarlege og fagavdelingar. Fokus er ikkje interne kode‑detaljar, men konsekvensar for drift, sikkerheit, data, grensesnitt, leveranseevne og vedlikehald. Målet er eit felles språk som dempar budsjett- og prioriteringsdiskusjonar og gjer modernisering planleggbar.

Scoring-modell for teknisk gjeld i praksis

Teknisk gjeld er ein samlebetegnelse for avgjerder og arv som sparte tid på kort sikt, men som på lang sikt gir renteutgifter. Desse «rentene» syner seg i dagleg drift som lengre gjennomløpstider, meir koordinering, høgare feiltal, tryggleiksgap, spesialkunnskap hos få personar eller avhengnader av komponentar som ikkje lenger vert støtta. Problemet er: Mange av desse effekta kjem ikkje til syne som ei klar kostnadsstad.

Typiske grunnar til at teknisk gjeld forsvinn i porteføljegjennomgangar:

• Manglande samanliknbarheit: Ein stabil, gammal monolitt, eit SaaS‑verktøy med aukande lisenspress og ei integrasjonsløysing med nattlege jobbar er vanskeleg å vurdere mot kvarandre utan eit rammeverk.
• Ujamn datagrunnlag: For system A finst det incident‑statistikkar og overvaking, for system B berre magekjensle, for system C ingenting.
• Blanda diskusjonar: Fagleg nytte, tekniske risikoar og personlege preferansar (teknologi, ønskje frå teamet) hamnar i same gryta.
• For store vurderingsmodellar: Omfattande modenheitsmodellar er nyttige – men vert ofte ikkje vedlikehaldne regelmessig. For porteføljevedtak tel gjentakbarheit.

Eit lettvekt Scoring-modell er ikkje ein perfekt sanning. Det er eit verkty for å redusere usikkerheit og gjere vedtak etterprøvbare – inkludert dei føresetnadene som ligg bak.

Prinsipp for eit lettvekt Scoring-modell

For at ein Scoring-modell ikkje skal enda som ei «Excel‑øving», bør det oppfylle nokre grunnprinsipp:

• Få dimensjonar, klare definisjonar: Snarare 6–8 vurderingsdimensjonar godt forklarte enn å samle 20 halvkriterium.
• Måleleg, men ikkje talfiksert: Ikkje alt finst som tal. Det viktigaste er at kriteriene vert brukt konsekvent.
• Portefølje‑eigna: Vurderinga må fungere på tvers av system – uavhengig av om det gjeld individuell bedriftsprogramvare, standardprodukt eller integrasjonskomponentar.
• Eksplisitte perspektiv: Drift, sikkerheit, data og fagavdeling skal vere med i modellen, slik at det ikkje berre vert ein diskusjon om «teknikk mot forretning».

I praksis har det vist seg å vere nyttig å handsame Scoren som samtalegrunnlag: Han leverer ei prioritert liste, men inga automatiske avgjerder. Portefølje-greiner står framleis ansvarlege – og dokumenterer medvite avvik.

Das Scoring-Modell: 8 Dimensionen, die im Betrieb wirklich zählen

Følgjande rutenett nyttar åtte dimensjonar som let seg hente i typiske bedriftslandskap. Kvar dimensjon blir vurdert på ei skala frå 1 til 5 (1 = ikkje kritisk/godt handsama, 5 = kritisk/akutt behov for tiltak). Viktigare enn matematisk presisjon er tydelegheita i kriteriane.

1) Betriebsstabilität und Störungsprofil

Her dreier det seg om spørsmålet: Kor ofte forstyrrar systemet drifta – og kor kostbare er desse forstyrringane organisatorisk? Basis er Incidents (støringar), tilbakevendande saker, on-call-eskaleringar og uplanlagde vedlikehald. Også «stille» ustabilitet tel, til dømes når nattkøyringar ofte må etterarbeidast.

Vurderingsanker (døme):

• 1: Sjeldne Incidents, klare Runbooks (driftshandbøker), gjenstart øvd.
• 3: Jamlege feilhendingar eller hyppige ytingsproblem, men handterbare.
• 5: Tilbakevendande utfallet, høg supportbelastning, midlertidige løysingar i staden for rotårsaksløysing.

2) Sicherheits- und Compliance-Risiko

Denne dimensjonen vurderer kor godt systemet er sikra mot sikkerheitshendingar og kor revisjonsvennleg drifta er. Det omfattar patch-evne, støtta komponentar, autentisering (t.d. SSO over SAML/OIDC – altså sentral pålogging), loggføring (Audit-Trail: etterprøvbar hendingrekke) og vern av sensitive data.

• 1: Jamlege oppdateringar, klare roller/rettar, etterprøvbare loggar, inga kjende «End-of-Life»-komponentar.
• 3: Delvis utdaterte komponentar eller manglar i protokollering/resertifisering, kompensasjonstiltak finst.
• 5: Kritiske etterslep, manglande patchar, uavklarte ansvar, revisjonsrisiko.

3) Änderbarkeit und Release-Fähigkeit

«Kor vanskeleg er det å levere endringar på ein sikker måte?» Det er kjernen i mykje teknisk gjeld. Her meiner ein testbarheit (regresjon: repeterbare testar), deploy-prosess, rollback-evne (tydeleg tilbakefallsmekanisme), avhengigheit av enkeltpersonar og tida frå krav til produksjon.

• 1: Reproduserbare Releases, definerte miljø, planbare vedlikehaldsvindauge.
• 3: Releases mogleg, men med manuelle steg og auka koordineringsbehov.
• 5: Kvar endring er risiko, Deploy berre «med dei rette folka», Rollback uklart.

4) Architektur- und Integrationskomplexität

Denne dimensjonen fangar ikkje om ei arkitektur er «moderne», men om ho er handterbar. Integrasjonar er ofte kostnadsdrivarar: punkt-til-punkt-grensesnitt, spesielle filformat, tidskritisk batchbehandling, manglande versjonering av API-ar (grensesnittkontraktar) eller tett kopling til andre system.

• 1: Klart dokumenterte grensesnitt, få koplingspunkt, endringar verkar lokale.
• 3: Fleire avhengigheiter, endringar krev koordinerte releases.
• 5: «Spaghetti»-integrasjonar, ukjende dataflyt, stor påverknad ved små endringar.

5) Datakvalitet, dataeierskap og dataflyt

For porteføljeavgjerder er det avgjerande om data blir halde reine og kan nyttast påliteleg. Dataeierskap tyder: Det er klart kvar «sanninga» ligg, korleis stamdata (t.d. kundar, artiklar, leverandørar) oppstår og korleis endringar verkar nedstraums. Dataflyt omfattar òg eksportar, skuggekopiar og manuelle korrigeringar.

• 1: Klare ansvar, ettersporelege datavegar, definerte grensesnitt, konsistente nøkkelverdiar.
• 3: Fleire datakjelder eller regelmessige ryddingar, men transparente.
• 5: Uklar sanning, hyppige korrigeringar, rapportering berre mogleg med særlogikk.

6) Livsløpsrisiko: leverandør, plattform, kompetanse

Teknisk gjeld oppstår òg ved avviklingar: operativsystem, databasar, bibliotek, produsentstøtte eller tilgjenge på kompetanse. Denne dimensjonen ser medvite på den organisatoriske sida: Finst det nok personar som kan halde drift og vidareutvikling? Finst det ein robust oppgraderingsveg?

• 1: Aktive støtte-syklusar, oppgradering planlagd, kompetanse breitt tilgjengeleg.
• 3: Oppgradering står for døra, press på kompetanse, avhengigheit av nokre få nøkkelpersonar.
• 5: End-of-Life, ingen roadmap, kunnskap konsentrert, høgt vendor-risiko.

7) Kostnads- og innsatsdrivarar i løpande drift

Her blir ikkje berre infrastrukturkostnader vurderte, men først og fremst variable kostnader: supportinnsats, manuelle oppgåver, særskilde prosessar, lisensvekst, binding til eksterne tenesteleverandørar eller dyre vedlikehaldsvindauge. Særleg for forretningsprogramvare er desse indirekte kostnadene ofte viktigare enn serverprisane.

• 1: Stabil drift, få manuelle oppgåver, kostnader planbare.
• 3: Aukande driftsinnsats eller stigande lisenskostnader, men handterbart.
• 5: Drift «et» kapasitet, mange manuelle korrigeringar, kostnader vanskelege å forutsi.

8) Forretningskritikalitet og prosessavhengigheit

Teknisk gjeld blir først relevant for porteføljeavgjerder når han møter prosessrisiko. Denne dimensjonen vurderer kor sterkt systemet ber kjerneprosessar og kor stor skaden er ved svikt eller feil. Viktig: Kritikalitet er ikkje ei fripass for «aldri røre», men eit argument for grundig stabilisering og modernisering.

• 1: Støtteprosess, svikt er tolererbar, omveg finst.
• 3: Viktig prosess, svikt medfører kostnader, men avgrenselege.
• 5: Kjerneprosess, svikt stoppar verdiskaping eller fører til compliance- og regelverksriskar.

Korleis score blir til porteføljeavgjerder (utan falsk presisjon)

Ein score er først nyttig når han legg til rette for ei avgjerd. Det krev to steg: vekting og beslutningskategoriar.

Vekting: ikkje alle kriterium tel likt

Mange organisasjonar startar med lik vekting for å unngå diskusjonar. Seinare lönar det seg med ei enkel vekting etter porteføljemål, til dømes:

• Sikkerheit først (f.eks. etter funn i revisjon): sikkerheits- og samsvarsrisiko vert vektlagde dobbel.
• Auke leveranseevne (f.eks. ved stor endringsbacklogg): endringsbarheit/release-evne vert vektlagd sterkare.
• Stabilisere kostnadene (f.eks. ved aukande support): innsatsdrivarar i drift vert vektlagde sterkare.

Viktig er å dokumentere vektinga transparent og berre endre han sjeldan. Elles vil score-endringar oppfattast som «politiske» i staden for som reelle forbetringar.

Beslutningskategoriar: fire klare handlingsalternativ

Frå dimensjonane kan ein avleiast fire pragmatiske kategoriar som let seg diskutere i porteføljebordet:

• Stabilisere: Høge drifts-/sikkerheitsrisikoar, men ingen kortsiktig utskifting mogleg. Fokus på runbooks, overvaking, patchvegar, teknisk hygiene.
• Modernisere: Høg endrings- eller livssyklusrisko samstundes med høg kritikalitet. Fokus på modulær fornying, å avkople grensesnitt, konsolidere datamodellar.
• Konsolidere/Erstatte: Doble funksjonar, høg innsats, låg differensiering. Fokus på avvikling, datamigrasjon, standardisering av prosessar.
• Bevisst akseptere: Låg kritikalitet eller forventa RESTlevetid. Fokus på risikokontrollar, minimalt vedlikehald, klar exit-moglegheit.

For at dette ikkje skal bli teoretisk, bør kvar applikasjon i tillegg få eit neste fornuftige steg – maksimum 1–2 konkrete tiltak som er realistiske å utføre på 4–12 veker. På den måten blir porteføljestyring ein løpande forbetringsprosess i staden for ein årleg workshop.

Bygg datagrunnlaget pragmatisk: kva kjelder held som regel

Eit lettvektig modellliv krev at innhenting av data ikkje er dyrare enn dei fyrste tiltaka. For mange selskap held følgjande fire kjelder for å kunne gi pålitelege scorar:

• Ticket-/incident-data: Hyppigheit, gjentakingar, handteringstider, eskalasjonar. Finnst det ingen ryddig kategorisering, held ei grov inndeling i starten (feil, førespurnad, endring).
• Overvaking/tilgjengelegheit: Ikkje berre oppetid, men òg ytelsestoppar, jobbkøyringstider, feilsatsar, minne-/lagringsvekst.
• Sikkerheits- og livsløpsinformasjon: Patchnivå, datoar for End-of-Life, avhengigheiter (f.eks. databaseversjon, operativsystem, autentisering), kjende unntak.
• Arkitektur-/integrasjonsoversikt: Eit enkelt applikasjonskart (systemkart) med dataflyt og grensesnitt. Fullstendeheit er sekundært, aktualitet tel.

Når tal manglar, bør det vere synleg i scoren: «Vurdering 4 på grunn av manglande dokumentasjon» er ærlegare enn eit tilfeldig gjennomsnitt. Ukjend informasjon er i drift ofte meir risikofylt enn dårleg informasjon som ein i det minste kjenner til.

Scoring-Workshop på 90 Minuten: Ablauf, Rollen, Ergebnisartefakte

Eit vanleg feil er å utføre scoring som enkeltarbeid. Då blir det anten for teknisk eller for politisk. Bedre er ein kort workshop per system, moderert og med klare roller. 90 minutt held til ei første robust vurdering dersom basisdata ligg føre.

Deltakarar (små, men fullstendige)

• Systemansvarleg IT: kjenner til Roadmap, endringar, tekniske flaskehalsar.
• Drift/Administrasjon: kjenner til driftsstansar, vedlikehaldsvindauge, overvaking, backup/RESTore.
• Fagleg eigar eller nøkkelbrukar: kjenner til prosesskritikalitet, arbeidsomgåingar, aksept, toppbelastningstider.
• Moderasjon: sørgjer for at definisjonar blir følgde og dokumenterer føresetnader.

Fremgangsmåte (kompakt, gjentakbar)

1. Kontext (10 min.): føremål med systemet, brukargrupper, hovudgrensesnitt, driftsmodell (On-Prem/Cloud/Hybrid).
2. Score per dimensjon (45 min.): per kriterium 3–5 minutt, med korte bevis (tal på ticketar, patch-nivå, kjende avhengigheiter).
3. Identifisere hotspots (15 min.): Kva to dimensjonar driv risiko og kostnader mest?
4. Fastsetje tiltak (15 min.): 1–2 konkrete neste steg, pluss eigar og målfrist.
5. Portfolio-Label (5 min.): Stabilisere / Modernisere / Konsolidere / Akseptere.

Som resultat held tre artefaktar: score-tabell, kort grunngjeving per dimensjon og eit tiltakssnutt. Alt anna er valfritt.

Typiske fallgruver – og korleis ein handterer dei i modellen

Eit scoring-modell kan skape feil insentiv om det ikkje er klart avgrensa. Frå prosjekt-erfaring er dette dei vanlegaste snubletråda:

Fallgruve 1: «Vi straffar team for transparens»

Om team med god dokumentasjon får dårlegare scores fordi dei gjer problem synlege, er modellen øydelagd. Motmiddel: handsame ukjend (manglande data) som eiga risiko og uttrykkjeleg erkjenne transparens som eit pluss, t.d. i kriteriet endringsbarheit (Rollbacks, Runbooks, Monitoring).

Fallgruve 2: Score blir eit verktøy for budsjettkutt

Om høge scores automatisk fører til «prosjektstopp», blir modellen politisk. Betre: høge scores fører til ei beslutningssak med alternative løysingar (t.d. stabilisering vs. modernisering) og klare konsekvensar. Budsjettet følgjer avgjerda – ikkje berre scoren.

Fallgruve 3: Samblanding av nytte og risiko

Fagleg nytte (t.d. omsetningspotensial) er viktig, men er ei anna akse. Eit godt prøvd framgangsmåte: vurder nytte i eit eige rutenett og før det saman i ei porteføljematrise (nytte høg/låg vs. risiko/gjeld høg/låg). Slik blir det ikkje diskutert om ein sikkerheitsrisiko kan «kompenserast av omsetning».

Fallgruve 4: «Modernisering» blir forstått som eit storprosjekt

Porteføljebeslutningar mislykkast ofte på grunn av den implisitte føresetnaden om at modernisering berre kan skje som ein Big Bang. I praksis er ofte ein modulær modernisering meir hensiktsmessig: stabilisere grensesnitt, standardisere dataåtkomst, løyse ut enkelt delprosessar, styre parallell drift på ein ryddig måte. Ein Score hjelper med å finne rekkjefølgja, ikkje å tvinge fram sluttstaten.

Frå Score til Roadmap: korleis tiltakspakkar blir fornuftig tilpassa

Når modellen er på plass, byrjar det eigentlege arbeidet: å dele tiltak slik at dei fungerer i kvardagen ved sida av prosjektverksemd. Tre reglar hjelper med å omforme «vi burde» til konkrete Roadmap-element:

1) Først redusere dei dyRESTe risikoane

I mange porteføljer er sikkerheits- og driftsrisikoar dei største løftestangane, fordi dei har eksterne fristar (Audit, End-of-Life) og høge følgjekostnader. Typiske tiltak er: etablere ein oppdateringsveg, supplere logging/audit-trail, teste Backup/RESTore, redusere einskild feilpunkt, verifisere tilgangsrettar.

2) Integrasjonsknutar før funksjonsutviding stabilisere

System med mange Schnittstellen er multiplikatorar for endringskostnader. Her løner det seg ofte å gjere følgjande først: definere Schnittstellen-Verträge (Versionierung, Datenformate, Fehlerbehandlung), supplere overvaking for dataflyt, løyse opp jobbkjedar, innføre Retry-Strategien (omprøvingsforsøk ved feil). Dette er sjeldan synleg for fagavdelinga, men det reduserer nedetid og release-stress målbart.

3) Gjere tiltak planleggbare som driftsforbetring

Mange tekniske gjeld kan gjennomførast som driftsforbetringar i små pakkar: Runbooks, Alarmregeln, Kapazitätsplanung, standardisering av miljø, regelmessige Patchfenster. Det er inga glamorøse prosjekt, men dei aukar pålitelegheita – og skaper tidsrom for større moderniseringstiltak.

Slik blir Scoringa varig: Governance utan byråkrati

Eit modell er berre verdifullt dersom det ikkje sovnar inn etter to kvartal. Det krev ein enkel prosess som passar inn i drifts- og prosjektkvardagen:

• Eigar per applikasjon: Ein namngjeven person som held Score og tiltaksstatus ved like (ikkje gjennomfører det åleine).
• Trigger i staden for kalenderplikt: Score-Review etter Incident-Cluster, Major-Release, Revisjonsfunn eller Plattform-Upgrade.
• Porteføljerytmus: Månadleg/annan-månadleg 60 minutt for topp-risikoane, ikkje for alle system.
• Beslutningslogg: Kort dokumentasjon av kvifor ein risiko vart akseptert eller utsett. Det hindrar seinare klandringar og gjer føresetnader synlege.

Det er viktig å kopla til reell styring: Minst ein del av kapasiteten (budsjett eller team-tid) bør uttrykkjeleg reserverast til stabilisering/modernisering. Elles produserer modellen berre innsikt utan effekt.

Konklusjon: Gjer teknisk gjeld synleg utan å overvelda organisasjonen

Eit lettvekts scoringsmodell for teknisk gjeld erstattar ikkje detaljert arkitekturarbeid – men det skapar noko som ofte manglar i porteføljar: samanliknbarheit. Med åtte klare dimensjonar, etterprøvbare vurderingsankrar og eit kort workshop-format kan ein visa risikoar, driftsinnsats og moderniseringspress på ein måte som gjer at IT, fagavdeling og leiing har den same diskusjonen.

Den viktigaste effekten er sjeldan den eksakte talverdien. Det er transparensen om kor teknisk gjeld oppstår, korleis ho belastar drifta og kva neste steg som er realistiske. Når scorar blir regelmessig gjennomgått og knytte til små, konkrete tiltak, oppstår ei moderniseringsroadmap som ikkje berre finst på reknebrettet, men som blir burd av det daglege arbeidet.

Dersom du ønskjer å setje opp scoringsmodellen for applikasjonsporteføljen din eller gjennomføre dei første vurderingane i eit fasilitert format, finn du her eit eigna inngangspunkt: Ta kontakt.

For dette temaet er òg vurdering av teknisk gjeld og porteføljeavgjerder i IT viktige. Innlegget set desse aspekta inn på ein forståeleg måte og viser kva som tel i det daglege.

Drøfte prosjekt eller moderniseringsprosjekt med Net-Base.